本地部署大模型工具链全景解析：从Ollama到vLLM的29个工具选型指南

“本地部署大模型”，现在随便一搜，能冒出来三十多个工具名：Ollama、LM Studio、vLLM、Dify、Open WebUI、RAGFlow、LLaMA Factory……最让人头疼的不是它们多，而是这些名字根本不是一个层面的东西。有人告诉你用Ollama跑模型，有人推荐LM Studio，有人上来就让你上vLLM做服务，还有人让你部署Dify做应用——如果你刚接触，很容易被搅晕，甚至以为它们是竞争关系，只能选一个。

我最初也干过这种傻事：先装了Ollama，又听人说Dify好用，于是去研究Dify，发现它还要接一个模型后端，绕了一圈又回到Ollama。折腾多了才真正明白，本地部署大模型的工具链是一条流水线，每个工具负责一个环节。这篇文章我就把这些年在本地跑模型、搭服务、做应用过程中接触过的29种工具平台，按它们在这条流水线上的位置分好类，讲清楚每个是干什么的、适合谁、和谁搭配用，最后给你一套可以直接抄作业的选型方案。

1. 先搞清楚一件事：这些工具根本不在同一个层级

很多人把本地部署工具放在一起对比，越比越乱，就是因为没先做“分层”。我总结下来的经验是，一套完整的本地大模型工具链，至少分五个层级：

• 模型运行层：负责把模型权重加载到内存或显存里，执行推理，对外提供调用接口。Ollama、llama.cpp、vLLM都属于这层。
• 前端界面层：给模型加一个能聊天的图形界面，解决“我不会写代码、不想用命令行”的问题。Open WebUI、Chatbox、Cherry Studio在这里。
• 应用编排层：在模型之上做RAG知识库、Agent、工作流，让你能搭出“一个产品”，而不只是“一个聊天框”。Dify、FastGPT、RAGFlow、Flowise是典型。
• 训练微调层：面向更进阶的需求，用领域数据把模型再训练一轮，让它变“专才”。LLaMA Factory、Unsloth、Axolotl属于这层。
• 多模态与特化层：处理图片生成、视频生成、语音识别等特定任务，和纯文本大模型的工具链有交叉但也有明显区别，比如ComfyUI。

打个比方：模型运行层像发动机，界面层是仪表盘和驾驶座，应用编排层是整车的电子控制系统，训练微调层是改装厂。你不能说“发动机和改装厂哪个好用”，因为它们解决的问题根本不是一回事。

所以这篇文章的分类，全部按这个逻辑走。以下提到的29个工具，我会在对应层级中逐个说明，最后也放一张完整速查表。

2. 个人桌面级客户端：从安装到聊天，十分钟搞定

这一层适合绝大多数个人用户。目标很朴素：把模型下载下来，能聊天、能跑通API，别让我折腾环境。我接触过的这类工具里，有5个值得单独说。

2.1 Ollama：本地部署大模型事实上的入口

Ollama 现在基本是本地部署的默认选择，原因就一个：它把“下载模型—启动服务—调用接口”压缩成了三行命令的事。安装完成后，终端里执行一条命令就能拉模型并跑起来：

ollama run qwen2.5:7b

模型文件会自动从仓库拉到本地，用完不用了可以随时删，整个体验非常像Docker——这也是Ollama最聪明的地方。它背后做的几件事值得了解：

• 内置模型仓库，一条命令下载、更新、删除模型；
• 默认跑在11434端口，并且自带一个OpenAI兼容的API端点；
• 模型文件统一管理，不会把磁盘搞得乱七八糟；
• 支持CPU、Apple Silicon、NVIDIA GPU，也支持把模型部分层放到显存、部分放内存跑。

很多人觉得Ollama只是个“下载器”，这个理解太窄了。它的真正价值是统一了本地模型的管理和调用规范。你可以用Python请求它：

from openai import OpenAI client = OpenAI( base_url="http://localhost:11434/v1", api_key="ollama" ) resp = client.chat.completions.create( model="qwen2.5:7b", messages=[{"role": "user", "content": "用一句话解释什么是RAG"}] ) print(resp.choices[0].message.content)

Ollama缺点也很明显：并发性能一般，不适合生产级高并发场景，而且对底层推理参数的控制不够细。它更像“个人开发者的瑞士军刀”，而不是“企业的推理服务器”。

2.2 LM Studio：不喜欢命令行的，直接用这个

如果你看到命令行就头疼，LM Studio可能是比Ollama更顺手的入口。它有完整的图形界面，可以在应用内浏览模型、搜索下载、开始聊天，还能直接启动一个本地服务器，兼容OpenAI API。

LM Studio底层走的是llama.cpp的推理路径，所以对GGUF格式的量化模型支持很好。它在Windows和macOS上的体验都很流畅，特别适合把模型下载下来“先看看效果”的场景。我个人最常用它的“本地服务器”功能——启动后其他应用可以直接连http://localhost:1234/v1，体验和连一个远程API几乎一模一样。

2.3 Jan：彻底离线的“隐私优先”客户端

Jan的定位和LM Studio很像，但更强调离线。它的理念是“就算没有网络，也能在自己的电脑上跑模型”。

Jan底层用的是自家的Cortex引擎，支持多种推理后端。界面做得干净，模型管理、聊天、本地API一个不少。如果你是那种数据敏感、所有对话都不想出本机的用户，Jan会比Ollama更贴合你的需求。

2.4 GPT4All：老牌轻量选手

GPT4All在早期阶段几乎是本地大模型的代名词，很多人的第一次本地运行体验就是它。它的特点是对硬件要求低，普通的Windows/Mac电脑也能流畅运行小模型，内置大量可以直接下载的量化模型。

不过这两年它的生态有点被Ollama和LM Studio反超的趋势。我现在的建议是：如果你的电脑配置很老，或者只需要一个极简的本地问答工具，GPT4All依然是个好选择；但如果你打算后面往API、应用方向走，还是从Ollama入手更划算。

2.5 Oobabooga Text Generation WebUI：折腾党的心头好

这是本地文本生成圈子里资历最老、功能最全的Web界面之一。它支持极多的推理后端，从Transformers、ExLlama到llama.cpp都往里接，还内置了Chat模式、Instruction模式、微调脚本、训练插件等一堆东西。

Oobabooga的问题是太复杂。新手上路容易在安装依赖、切换后端、配置参数这些环节直接劝退。但只要折腾通了，它能做到的事情远超上面几个傻瓜化工具。我的评价是：不是人人都需要它，但在本地部署这个圈子里，它是一面绕不开的旗帜。

这一层我做一个直观对比：

3. 推理引擎与服务化框架：决定模型跑多快、并发多高

这一层是整个工具链的技术核心。Ollama和LM Studio只是把这一层的引擎包上了一层好用的壳。真正到了生产环境，或者你手里有几块GPU、要同时服务几十上百个用户时，你需要的就不是壳，而是底层的推理框架本身。

3.1 llama.cpp：GGUF量化体系的源头

llama.cpp最初是用C++重写LLaMA推理过程的一个项目，目标就一个：让大模型不靠GPU也能在普通CPU上跑起来。它后来做的一件事影响了整个本地部署生态——定义了GGUF量化格式。

量化可以这么理解：单个参数用一个2字节或4字节的小数保存，叫半精度/单精度；但如果把精度降下来、用整数近似表达权重，文件体积和内存占用都会大幅下降。llama.cpp提供了一系列量化等级，常见的有：

• Q4_K_M：效果与速度的平衡点，个人部署最常用；
• Q5_K_M：比Q4更接近原版效果，体积略大；
• Q8_0：几乎无损，但占用也高。

比如一个7B模型，FP16精度大约占14GB显存/内存，换成Q4_K_M量化后只有约4.4GB，普通电脑也能跑。这让很多人第一次在笔记本上体验到了70亿参数模型的效果。

llama.cpp本身没有图形界面，它是命令行工具，也提供Python绑定和server模式。很多上层工具（包括Ollama、LM Studio）的底层推理都靠它。

3.2 vLLM：高并发场景的默认首选

如果你跑模型不只是自己聊聊天，而是要部署成API服务，vLLM基本是目前最优解。它来自UC Berkeley，核心创新是PagedAttention——思路和操作系统的虚拟内存分页非常像，把KV Cache切块管理，大幅减少了显存浪费，从而带来两三个数量级的吞吐提升。

vLLM的用法也很直接：

python -m vllm.entrypoints.openai.api_server \ --model Qwen/Qwen2.5-7B-Instruct \ --tensor-parallel-size 1 \ --host 0.0.0.0 \ --port 8000

启动后同样提供OpenAI兼容接口。它的适用场景非常明确：并发高、请求多、要稳定。如果你只是本地一台Mac跑着玩，用不上它；但一旦你要做一个团队能用的服务，vLLM是绕不开的。

3.3 SGLang：结构化输出的加速专家

SGLang背后是英伟达、斯坦福等机构的贡献，主打“结构化生成”加速。它有个核心技术叫RadixAttention，在带有系统提示词、Few-shot示例、JSON Schema约束等场景里，能复用大量KV Cache，效果很惊艳。

如果你们要做的产品需要模型按固定JSON结构输出、频繁调用工具函数、或者要处理大量带有公共前缀的提示词，SGLang很可能是比vLLM更合适的选择。它同样支持OpenAI兼容API。

3.4 LMDeploy：国产开源推理套件

LMDeploy是上海人工智能实验室开源的项目，核心引擎叫TurboMind，对国产模型（尤其Qwen系列、LLaMA等）做了大量针对性优化。它的小体积量化方案叫AWQ，结合KV Cache的INT8量化，让单卡能塞下更大模型的可用上下文。

如果你在国内服务器上部署，LMDeploy有个很实用的点：内置了兼容OpenAI的RESTful API和命令行客户端，同时和HF生态的模型转换做得比较顺。配置思路和vLLM有点像：

lmdeploy serve api_server \ /path/to/your-model \ --server-port 23333 \ --tp 1

3.5 TensorRT-LLM：NVIDIA生态下的性能天花板

TensorRT-LLM是NVIDIA官方出的推理框架，底子是他们深耕多年的TensorRT，推理性能做到极致，但前提是你用的是NVIDIA的GPU。它支持FP8、INT8、INT4多种量化，还带运行时优化和模型并行。

好处是性能最强，坏处是学起来最费劲。它对模型的编译流程、依赖环境要求比较高，不是一条命令就能跑通的。我的判断是：如果你做的是纯内部系统、公司正好有A100/H100这类卡，而且你有一定工程能力，值得为了性能去折腾TensorRT-LLM；否则，vLLM/LMDeploy已经足够好。

3.6 TGI、LocalAI、llama-cpp-python：各自补位的三个工具

TGI（Text Generation Inference）是Hugging Face官方推出的推理服务器。和vLLM定位重叠，但TGI更“原生HF”——直接从Hub拉模型就能起来。它的优势是对Hugging Face生态兼容性最好，如果你所有模型都是从HF下载的，TGI会让你非常省心。

LocalAI是一个很特别的项目，定位是“OpenAI API的本地替代品”。它用Go语言编写，思路是把各种开源引擎（llama.cpp、whisper.cpp等）封装成一个符合OpenAI接口规范的服务。也就是说，你原来代码里写的api.openai.com，只要把BaseURL换成LocalAI，就能在本地跑开源模型。它其实不止支持文本，也支持语音转文字、图片生成，是统一API的好选择。

llama-cpp-python是把llama.cpp封装成Python库的项目。开发人员可以在Python里直接加载模型、传参推理，或者启动一个内置的OpenAI兼容服务器。它体积小、依赖少，适合写一些轻量的自动化脚本，也是我用过的几个LangChain离线应用中常见的底层组件。

这一层的选型逻辑，我也给个直接建议：

4. Web界面与应用前端：给模型加一张“脸”

引擎有了，模型能跑了。但如果没有界面，每次都得写Python脚本或curl命令，体验实在太原始。这一层解决的是“怎么舒服地和模型交互”的问题。

4.1 Open WebUI：自己搭一个“本地ChatGPT”

Open WebUI是我在本地部署中最推荐的Web界面，没有之一。它最早只是Ollama的配套界面，后来扩展支持OpenAI API扩展，现在也可以接各种兼容OpenAI的服务。

它能做的事情，远远超过一个聊天框：

• 多模型管理：同时在列表里切换多个已部署模型；
• RAG知识库：上传文档，对话时自动检索；
• 多用户：可以开账号、分权限，适合小团队共用一台服务器；
• 模型参数调节：温度、Top-P、上下文长度都能在界面里改；
• 对话分享：像ChatGPT一样生成分享链接。

部署也方便，Docker一条命令就能拉起来：

docker run -d -p 3000:8080 \ -v open-webui:/app/backend/data \ -v /path/to/ollama:/root/.ollama \ --name open-webui \ ghcr.io/open-webui/open-webui:main

然后浏览器打开http://localhost:3000，注册账号，进去后在设置里填上Ollama或任意OpenAI兼容地址，就能开始聊了。Open WebUI给人的感觉，就是你在本地认认真真复刻了一个ChatGPT。

4.2 Chatbox、Cherry Studio、LobeChat、NextChat：桌面和Web聊天客户端的四种风格

这四个工具解决的问题相同：用好看的界面连不同的大模型后端。区别在于体验细节和适用场景。

Chatbox是我电脑上装了最久的桌面聊天工具。它支持OpenAI、Ollama、Azure等多后端，界面干净，单机使用完全够。适合只是“想找个地方和模型对话”的人。

Cherry Studio是近两年很火的国产桌面客户端，定位偏“生产力”。它内置了多模型同时管理、知识库、翻译、润色等工具，比较适合把聊天、写作、翻译需求合在一起处理的人。

LobeChat则是Web端的花活担当。它支持插件体系，界面非常现代，还能以Docker方式一键部署。它的插件系统很强，可以让模型调用各种外部能力，如果你喜欢“折腾前端体验”，LobeChat会让你玩得很开心。

NextChat（ChatGPT-Next-Web）早期因为“用Vercel一键部署”火过一阵，现在也支持接Ollama等本地后端。我一般建议想快速在公司内网搭一个聊天入口、又不想引入复杂平台的同学用这个。

4.3 AnythingLLM：把“文档问答”做成最简单

AnythingLLM不是单纯的聊天界面，它把重点放在了个人知识库+RAG上。它有Workspace概念，每个工作区可以上传文档，对话时会自动检索对应内容。而且它支持Ollama、LocalAI、LM Studio等几乎一切本地模型后端，同时内置嵌入模型能力，整体体验用一个字形容：顺。

如果你没有任何代码基础，只是希望“把公司一堆PDF变成一个能问答的机器人”，AnythingLLM可能是你两天内就能做出来的方案。

4.4 ComfyUI：多模态特化的节点式工作流

严格来说，ComfyUI主要面向图像生成（Stable Diffusion、Flux这类模型），但它也是“本地部署大模型”工具链里异常重要的一环。它是节点式工作流操作界面，把加载模型、采样、提示词、图像保存都拆成节点，可以自由连线组合。虽然学习曲线陡，但一旦掌握，做批量出图、多模型组合、局部重绘等任务的灵活度，是其他图形工具没法比的。

对于多模态大模型（比如需要本地跑图像理解模型的场景），ComfyUI也能通过自定义节点接进来做一些可视化调试。所以它在这个分类里，是一个“从文本走向多模态”的桥梁工具。

5. 应用编排平台：从“能聊天”到“做出产品”

前面几层解决的是“模型通了、能聊了”。但真实业务场景往往更复杂：需要让模型回答问题时引用公司文档里的内容，需要把模型接入工作流，需要让Agent调用工具去订会议室、查数据库。这些需求，就要靠应用编排平台来处理了。

我判断你是否需要这层工具的标准很朴素：如果只是自己用，不用；如果要做成产品给同事或客户用，必须用。

5.1 Dify：一站式应用编排，当前最主流

Dify现在是开源LLM应用开发平台里最火的项目。它把大模型应用的核心组件都做成了可视化模块，不需要写太多代码就能搭出一个完整的应用。它的核心能力包括：

• 模型管理：集中配置Ollama/vLLM/OpenAI等多个模型提供商；
• RAG管道：上传文档、自动切片、选嵌入模型、建知识库，全程可视化；
• Agent编排：配置工具调用，比如搜索、计算器、HTTP请求；
• 工作流：用拖拽节点把提示词、问题分类、多轮对话串起来；
• 应用发布：生成Web App、嵌入iframe、发布API供外部调用。

我最常用的一个场景是“内部知识库问答机器人”：在Dify里上传部门文档，接上Ollama的Qwen模型（检索用嵌入模型也本地化），然后在Web界面里发布，同事直接扫码用手机访问。整个流程不用写一行代码。

Dify的折中设计我认为做得很好：不是纯拖拽，也不是纯代码。复杂的逻辑可以写Python内置函数，普通逻辑用画布拖就行，非常适合工程能力有限但又想快速做原型/内部工具的团队。

5.2 FastGPT：知识库问答场景的优等生

FastGPT也是国内社区很活跃的开源项目，主打知识库问答+可视化工作流。和Dify相比，它更侧重于“检索问答”这个场景：文档管理、分段检索、引用来源标注这些功能做得更细。

体验上FastGPT的编排界面也挺直观，适合做客服机器人、政策问答、产品FAQ这类“检索增强型”应用。如果你的核心需求就是“文档多、要精准引用、要有引用来源”，FastGPT值得优先看一眼。

5.3 RAGFlow：文档解析能力的长板选手

RAGFlow的团队来自英飞流，主打的是深度文档理解。普通RAG工具对PDF里复杂的表格、版面、公式处理得往往很糟糕，RAGFlow则专门优化了“把文档解析成结构化数据”这一步，支持OCR、版面分析、表格解析。

我自己在做一个合同问答机器人时，用Dify解析合同PDF经常出现段落错乱，换成RAGFlow之后效果好了非常多。所以我的建议是：如果你的知识库文档以“复杂扫描件、带表格的报表、书籍排版”为主，用RAGFlow做解析层，再配合其他平台做问答编排，是比较稳妥的组合。

5.4 Flowise与LangFlow：低代码画布上的LangChain体验

这两个工具定位几乎完全一样：把LangChain的组件做成可视化节点，让你用连线的方式搭建Agent、链式调用、RAG流程。它们适合快速验证想法——比如“我想让模型先做意图识别，再决定调哪个知识库”，拖几个节点连起来就能测。

但说实话，我的个人体验是：低代码画布在流程简单时很爽，流程一复杂就变得难以维护。如果只是做原型验证，Flowise/LangFlow可以通过拖拽快速试错；一旦要生产化，我还是会回到Dify这类更完整的平台或直接写代码。所以这两个工具我归类为“原型验证工具”，不要指望它们承担太重的生产职责。

6. 微调与训练工具：让模型从“通用”变“专才”

如果你所在领域术语非常专业，或者对输出格式有固定要求，提示词和RAG都做不到满意，那就要考虑微调了。微调就是用一批标注好的数据，在预训练模型的基础上再做一轮“专项训练”。但本地机器做微调，门槛比纯推理高很多，所以工具的选择就格外重要。

6.1 LLaMA Factory：低门槛微调的首选

LLaMA Factory是国产开源项目，目前已经是本地微调领域事实上的标准工具之一。它支持LLaMA、Qwen、DeepSeek、GLM等大量模型，支持LoRA、QLoRA、全参微调等多种训练方式，并且提供了一个完整的Web界面，新手不用写训练脚本也能完成一次微调。

实际使用流程大致是：

1. 准备好数据，格式通常是JSON，每行是“指令+输入+输出”的对话结构；
2. 选择基础模型，比如Qwen2.5-7B-Instruct；
3. 选择训练方式，显存有限就选LoRA或QLoRA；
4. 设置学习率、批次大小等参数，启动训练；
5. 训练完成后导出LoRA权重，合并进原模型。

以7B模型用LoRA微调为例，24GB显存基本够用，QLoRA甚至只要12GB左右就能跑。这个门槛已经低到个人开发者在自己的单卡工作站上完全可以接受。

LLaMA Factory还支持DPO（用偏好数据做对齐训练）、支持导出GGUF格式给Ollama使用，这让“微调—量化—本地部署”整条链路能在同一个工作流里完成。我现在做行业垂直模型的流程基本都是：LLaMA Factory做微调 → 导出Q4量化 → 放到Ollama/vLLM里跑服务。

6.2 Unsloth：让微调速度和显存同时“开挂”

Unsloth是我见过对个人开发者最友好的微调加速库。它通过自己优化的内核，让LoRA训练速度提升2~5倍，同时显存占用最多能降低约80%。意味着原本24GB显存里跑不动的训练，在Unsloth里可以轻松跑起来。

我最初不太相信它“免费开源版就能白嫖性能”的说法，实测发现训练速度确实显著快于LLaMA Factory默认配置下的同参数任务。Unsloth还集成了Hugging Face生态，训练完直接推送到模型库或转成GGUF，设计得很顺。如果你经常微调模型，Unsloth几乎是必装。

6.3 Axolotl：配置驱动的进阶微调框架

Axolotl和LLaMA Factory的思路不太一样。它没有花哨的界面，而是用一份YAML配置文件描述所有训练参数，适合那些“有工程能力、口味偏代码化”的进阶用户。

我在折腾Axolotl时最大的体会是它灵活度极高：数据集支持各种采样方式，支持同时混入多个数据集，对多GPU并行训练的支持也成熟。缺点是学习成本较高，你需要对训练参数有足够理解，否则配置文件里的几十个字段足够让人无所适从。

6.4 魔搭ModelScope与Swift：阿里生态的一站式方案

最后是魔搭社区。国内开发者接触它很大程度是因为模型下载方便——很多国产模型的权重发布在魔搭上比HF更快更稳。魔搭本身不仅是个模型仓库，它也提供了在线推理体验、部署工具以及Swift微调框架。

Swift是阿里系开源的轻量微调工具，对Qwen、DeepSeek等国产模型优化很到位，支持LoRA/QLoRA和全参训练。如果你主要玩国产模型、又不想在外网模型平台之间来回搬运文件，可以优先试魔搭+Swift的组合。

微调这一层我想额外多说一句：不是所有问题都值得微调。我在实际项目里见过太多人把“模型答不准”归因于需要微调，结果微调完又是一堆新问题。如果你的目标是让模型更懂某个知识领域，优先考虑RAG；如果模型输出格式始终不稳定，优先考虑提示词约束或结构化生成；只有当这些手段都试过且确实无效、或者你有大量高质量的特定领域数据时，再启动微调。

7. 29个工具速查表与三套直接可用的选型方案

上面讲了五个层级，对应的工具也基本列完了。这里我统一整合一张速查表，把29个工具按层级归类，并给出“一句话定位”和“适合谁用”，方便你收藏。

表看完，怎么选？如果还是有点懵，直接参考我给出的三套组合方案：

方案一：纯个人学习，零成本起步

Ollama跑一个7B模型 + Open WebUI做聊天界面。想加文档问答，再补一个AnythingLLM。这套组合在16GB内存、8GB显存的机器上都能流畅跑，适合学习API调用、体验本地部署流程、做个人笔记助手。

方案二：小团队内部知识库/应用

Dify做主平台，接Ollama或者vLLM的本地模型服务，文档解析用RAGFlow处理。如果有GPU服务器，推理后端用vLLM跑13B~32B模型；没有GPU，Ollama+量化模型+CPU运行也可以应付低并发。这套组合非常适合“公司内部工具”场景，几乎所有需求都能在可视化界面里完成。

方案三：生产级API服务型

模型服务用vLLM或SGLang，量化方案视卡型而定（A100/H100考虑FP8，消费级卡用AWQ/GPTQ），微调用LLaMA Factory或Unsloth训练领域模型，训练完合并权重再部署到vLLM，应用层用Dify或直接写FastAPI调用。这套适合真正对并发、稳定性有要求的场景。

8. 我在本地部署中踩过的几个坑

最后聊几个实操中踩过的坑。这些不是从文档里看来的，是真正烧过时间才总结出来的。

第一个坑：模型格式和推理引擎不匹配。

GGUF模型不能直接塞进vLLM跑，vLLM要的是HF格式；反过来llama.cpp也跑不了GPTQ模型。很多新手在HF上看到一个模型，用Ollama拉取后没问题，等换到vLLM时就报格式错误，其实就是格式不兼容。这个问题的撞法非常统一：下载模型前先确认你的引擎支持什么格式。Ollama和LM Studio通常自动处理，但一旦自己用vLLM/llama.cpp，就绕不开这个规则。

第二个坑：OpenAI兼容API只是“接口兼容”，不是“行为兼容”。

我最初以为所有OpenAI兼容端点都一样，后来发现不同引擎对temperature、max_tokens等参数的解释有细微差别，部分引擎对stream模式的处理也不够成熟，个别版本还出现过中文乱码。调试这类问题时，建议先用curl直接打API看原始返回，别一上来就怀疑业务代码。

第三个坑：显存估算永远要比理论值多留一点。

一个7B FP16模型权重约14GB，很多人认为16GB显存就稳了。实际上运行时还有KV Cache、CUDA context、激活值等额外开销，16GB卡跑7B模型时往往只能勉强塞下很短的上下文。实测经验是：7B模型建议至少12GB可用显存，13B模型建议24GB，70B量化模型建议48GB起步。显存不够时，优先考虑更小模型或更低量化精度，而不是盲目开大上下文。

第四个坑：用Docker部署多个平台时，端口和镜像版本冲突。

Dify、Open WebUI、RAGFlow这几个平台默认都带一堆子服务，Docker Compose起来后如果端口没规划好，很容易撞在一起。我遇到过最头疼的一次是多个容器都向同一个向量数据库写入，导致知识库数据串了。现在的习惯是：每套平台用独立的Compose配置文件，指定不同的网络和数据目录，外部端口统一做个映射表记下来。

第五个坑：没有GPU时盲目追求“部署个大模型”。

CPU虽然能跑，但速度体验天差地别。7B量化模型在Apple M系列芯片上能跑到每秒十几token，听着还行；但在普通台式机CPU上可能只有每秒2~3token，给人一种“卡死了”的错觉。我的建议是：没GPU或不是苹果M系芯片的话，先把目标定为“跑通流程”，不要期望它能承担实际工作负载；真要跑得动，可以从3B以下的小模型开始，或者上一台二手带8G显存的卡，体验立刻不一样。

把这些坑写下来，不是劝退，而是想让你少走点弯路。本地部署大模型的工具链看似杂乱，其实一旦理清了层级、认准了自己所处的阶段，选型就变得很直接。按“先从Ollama+Open WebUI跑通，再根据需求往上层加”这个思路走，基本不会迷路。