“本地部署大模型”现在随便一搜能冒出来三十多个工具名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_urlhttp://localhost:11434/v1, api_keyollama ) resp client.chat.completions.create( modelqwen2.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的问题是太复杂。新手上路容易在安装依赖、切换后端、配置参数这些环节直接劝退。但只要折腾通了它能做到的事情远超上面几个傻瓜化工具。我的评价是不是人人都需要它但在本地部署这个圈子里它是一面绕不开的旗帜。这一层我做一个直观对比工具界面类型核心卖点适合人群API能力Ollama命令行API安装最简、模型管理出色开发者、想学习API调用的人完整OpenAI兼容APILM Studio桌面图形化下载即用、无需命令行新手、Windows/macOS用户内置OpenAI兼容服务器Jan桌面图形化完全离线、隐私优先隐私敏感用户支持本地APIGPT4All桌面图形化极低硬件门槛老机器用户、极简需求较弱OobaboogaWeb图形化功能全面、后端可换喜欢深度配置的发烧友较弱3. 推理引擎与服务化框架决定模型跑多快、并发多高这一层是整个工具链的技术核心。Ollama和LM Studio只是把这一层的引擎包上了一层好用的壳。真正到了生产环境或者你手里有几块GPU、要同时服务几十上百个用户时你需要的就不是壳而是底层的推理框架本身。3.1 llama.cppGGUF量化体系的源头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 13.5 TensorRT-LLMNVIDIA生态下的性能天花板TensorRT-LLM是NVIDIA官方出的推理框架底子是他们深耕多年的TensorRT推理性能做到极致但前提是你用的是NVIDIA的GPU。它支持FP8、INT8、INT4多种量化还带运行时优化和模型并行。好处是性能最强坏处是学起来最费劲。它对模型的编译流程、依赖环境要求比较高不是一条命令就能跑通的。我的判断是如果你做的是纯内部系统、公司正好有A100/H100这类卡而且你有一定工程能力值得为了性能去折腾TensorRT-LLM否则vLLM/LMDeploy已经足够好。3.6 TGI、LocalAI、llama-cpp-python各自补位的三个工具TGIText 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离线应用中常见的底层组件。这一层的选型逻辑我也给个直接建议场景首选理由个人电脑CPU/单卡跑量化模型llama.cpp / Ollama部署简单、硬件要求低单卡跑7B/13B个人开发测试LLama.cpp / TGI折腾成本低、生态稳多用户高并发API服务vLLM / LMDeploy吞吐量高、OpenAI兼容结构化输出/函数调用频繁SGLang结构化场景加速明显NVIDIA系生产环境极致优化TensorRT-LLM官方性能天花板让老项目无缝对接本地模型LocalAIAPI完全兼容OpenAI4. 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会让你玩得很开心。NextChatChatGPT-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界面新手不用写训练脚本也能完成一次微调。实际使用流程大致是准备好数据格式通常是JSON每行是“指令输入输出”的对话结构选择基础模型比如Qwen2.5-7B-Instruct选择训练方式显存有限就选LoRA或QLoRA设置学习率、批次大小等参数启动训练训练完成后导出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本地模型安装/运行/API管理入口所有本地部署用户首选桌面客户端LM Studio图形化聊天本地服务器的桌面端怕命令行的人桌面客户端Jan完全离线的隐私优先客户端隐私敏感用户桌面客户端GPT4All低门槛的轻量本地运行工具老机器、极简需求桌面客户端Oobabooga WebUI老牌全能文本生成Web界面折腾党、深度配置控推理引擎llama.cppGGUF量化与CPU/GPU混合推理源头开发者、工具链爱好者推理引擎vLLM高吞吐OpenAI兼容推理服务生产级API服务推理引擎SGLang结构化生成与KV Cache复用高并发复杂Prompt场景推理引擎LMDeploy国产推理套件极致量化国内服务器/国产模型推理引擎TensorRT-LLMNVIDIA生态性能天花板NVIDIA卡、重度优化需求推理引擎TGIHugging Face官方推理服务器HF生态重度用户推理引擎LocalAIOpenAI API一换BaseURL就能用老项目无缝迁移推理引擎llama-cpp-pythonllama.cpp的Python封装Python开发/脚本调用Web/前端UIOpen WebUI本地“ChatGPT”Web界面搭建团队共用入口Web/前端UIChatbox极简多后端桌面聊天客户端只想聊天的人Web/前端UICherry Studio生产力向的多模型桌面客户端写文章、翻译、知识管理Web/前端UILobeChat现代插件化Web聊天UI喜欢折腾前端体验Web/前端UINextChat一键部署的Web聊天界面快速搭内网聊天入口Web/前端UIAnythingLLM知识库RAG最简Docker方案无代码基础的非技术用户Web/前端UIComfyUI多模态图像生成的节点式工作流玩图、做影像生成应用编排Dify可视化LLM应用开发平台做产品/内部工具的团队应用编排FastGPT知识库问答可视化工作流客服FAQ、文档问答应用编排RAGFlow深度文档理解的知识库引擎复杂PDF/表格/扫描件应用编排FlowiseLangChain组件拖拽式低代码原型验证、快速试错应用编排LangFlowFlowise同类的LangChain画布原型验证、学习LangChain训练微调LLaMA Factory一站式低门槛微调平台个人微调首选训练微调Unsloth极速低显存LoRA微调加速常跑微调的开发者训练微调AxolotlYAML配置驱动的进阶微调工程能力强、自定义需求训练微调魔搭Swift阿里系模型仓库轻量微调国产模型主力用户表看完怎么选如果还是有点懵直接参考我给出的三套组合方案方案一纯个人学习零成本起步Ollama跑一个7B模型 Open WebUI做聊天界面。想加文档问答再补一个AnythingLLM。这套组合在16GB内存、8GB显存的机器上都能流畅跑适合学习API调用、体验本地部署流程、做个人笔记助手。方案二小团队内部知识库/应用Dify做主平台接Ollama或者vLLM的本地模型服务文档解析用RAGFlow处理。如果有GPU服务器推理后端用vLLM跑13B~32B模型没有GPUOllama量化模型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模型建议24GB70B量化模型建议48GB起步。显存不够时优先考虑更小模型或更低量化精度而不是盲目开大上下文。第四个坑用Docker部署多个平台时端口和镜像版本冲突。Dify、Open WebUI、RAGFlow这几个平台默认都带一堆子服务Docker Compose起来后如果端口没规划好很容易撞在一起。我遇到过最头疼的一次是多个容器都向同一个向量数据库写入导致知识库数据串了。现在的习惯是每套平台用独立的Compose配置文件指定不同的网络和数据目录外部端口统一做个映射表记下来。第五个坑没有GPU时盲目追求“部署个大模型”。CPU虽然能跑但速度体验天差地别。7B量化模型在Apple M系列芯片上能跑到每秒十几token听着还行但在普通台式机CPU上可能只有每秒2~3token给人一种“卡死了”的错觉。我的建议是没GPU或不是苹果M系芯片的话先把目标定为“跑通流程”不要期望它能承担实际工作负载真要跑得动可以从3B以下的小模型开始或者上一台二手带8G显存的卡体验立刻不一样。把这些坑写下来不是劝退而是想让你少走点弯路。本地部署大模型的工具链看似杂乱其实一旦理清了层级、认准了自己所处的阶段选型就变得很直接。按“先从OllamaOpen WebUI跑通再根据需求往上层加”这个思路走基本不会迷路。