1. 先想清楚为什么要在本地跑大模型这几年“AI本地部署”被提得越来越频繁差不多已经到了程序员茶余饭后必聊的程度。很多人一看到 Ollama、LM Studio、Dify 这些名字就跟着下载结果装完发现要么跑不起来要么跑起来了不知道自己该拿它做什么。我身边就有同事折腾了一个周末最后停在“模型能聊天”这一步然后就没了下文。如果要给“AI本地部署”下个通俗定义其实就一句话把大语言模型LLM的推理过程从云端 API 搬到你自己的电脑或服务器上让模型的权重文件、上下文数据、生成结果全部只经过你手里的硬件。听起来很酷但真正动手之前得先想明白“为什么”。我自己的经验是适合本地部署的场景大概有三类。第一类是数据敏感场景。比如企业内部的合同、代码、客户资料这些内容本身不适合发送到外部 API。本地部署之后所有请求都在内网完成至少在数据出域的环节上少了一个风险点。第二类是长期使用比较在意成本的情况。高频调用商业 API 的账单会很难看尤其是做批量生成、批量总结、跑 Agent 循环时token 消耗跟流水一样。本地部署虽然要买硬件、花电费但跑熟了之后边际成本确实更低。第三类是稳定性和自由度。没有网络依赖、不受 API 限流影响、可以随便换模型、可以改采样参数这些对做技术研究和做产品原型的人来说都是实打实的好处。不过也要泼一盆冷水本地部署不等于万能。它受显卡显存、内存带宽、供电散热的限制非常明显7B 级别的模型在消费级显卡上表现尚可70B 级别就需要多卡或量化方案了。所以这篇文章不是一个“无脑推荐”而是一份从实际使用出发的横向对比帮你判断“我这个需求到底该用哪一款”。适合读这篇文章的是有一定动手能力、想把大模型真正落到本机的开发者、算法工程师、产品原型爱好者以及所有对数据隐私有要求的人。2. 7款热门工具大盘点各自想吃哪碗饭2.1 一句话定位速览表先给一张速览表把7款工具按“它本质上是什么东西”来分个类。很多人选错工具是因为根本没搞清楚自己需要的是“模型运行器”还是“应用开发平台”。工具本质定位最擅长的事典型使用人群Ollama模型运行器/模型管理 CLI快速拉起 Llama、Qwen、DeepSeek 等开源模型提供 OpenAI 兼容 API开发者、刚入门本地部署的用户LM Studio图形化桌面客户端可视化下载、加载、测试模型上手零门槛没有编程经验、想用本地 AI 聊天或做实验的用户DifyLLM 应用开发平台把模型接入知识库、工作流、Agent快速做应用产品经理、后端开发者、想做完整应用的人AnythingLLM私有知识库问答应用本地文档导入 向量化 聊天问答的开箱方案企业知识管理、个人资料库用户OpenClaw多智能体自动化框架用自然语言指挥多个 AI 工具协作完成复杂任务AI Agent 玩家、技术探索型用户MinerU文档解析/内容提取工具把 PDF、扫描件转成结构化 Markdown保障 RAG 质量做资料库、RAG 管线、内容中台的人vLLM高性能推理引擎高吞吐、高并发的模型推理服务支持 PagedAttention把模型做成在线服务、对性能有要求的工程师这7款工具不是同一个赛道的竞品更多是“本地部署生态里的不同环节”。理解这一点才能看明白后面的横向对比表。2.2 选型前先搞懂三类“部署工具”我发现很多人在本地部署时卡住不是因为电脑不够好而是脑子里没有分类概念。本地部署工具大致分三层。最底层是“模型推理引擎”。它负责把模型权重加载进显存处理输入输出核心指标是吞吐量、显存占用、并发能力。Ollama 和 vLLM 都属于这一层但二者取向完全不同Ollama 追求的是“上手快、资源省”vLLM 追求的是“性能高、并发强”。中间层是“应用开发框架”。它在模型之上帮你封装好 API、数据库、知识库、流程编排、对话管理。Dify 属于这一类。使用它的人通常不只是“想聊天”而是想搭一个具备工具调用、文档问答、工作流处理能力的产品。AnythingLLM 的位置更偏向“即插即用的知识库应用”你可以不写代码就完成私有文档问答。最上层是“专项工具”。它们不是通用的 LLM 平台而是解决某个具体环节。比如 MinerU 解决的是文档解析OpenClaw 解决的是多智能体编排。这类工具常常和其他部署方案搭配使用MinerU 解析出干净文本Dify 做向量化和检索Ollama 负责模型推理OpenClaw 调度整个流程。所以我给所有准备入坑的人一个建议先确定你要做的是“聊天”“应用”还是“流水线”再选工具。要是目的都没定看着哪个工具火就装哪个大概率会踩坑。3. 七款工具逐个拆解我的真实使用感受3.1 Ollama轻量、快、省心入门首选Ollama 几乎已经成为本地大模型部署的代名词。我第一次接触它时最大的感受是“没什么存在感”——安装完几条命令就把模型拉下来跑起来了整个流程顺到不像本地方案。# 安装完成后拉取一个 7B 量级的中文模型试试 ollama pull qwen2.5:7b # 直接开启交互式对话 ollama run qwen2.5:7b # 启动 API 服务默认监听 11434 端口 ollama serve它的设计思路非常符合“最小可用”原则模型仓库统一管理、命令行工具极简、自带 OpenAI 兼容接口。你甚至可以用一行 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 在 Mac 和大多数 Linux 机器上表现都不错尤其是 Apple Silicon 平台它会自动利用 Metal 加速。我在 M 系列芯片上跑 7B 模型生成速度能达到 20~30 token/s体感非常流畅。但它的短板也很明显。首先并发能力弱多个请求同时进来时默认方案基本是排队处理不适合高并发的在线服务。其次参数控制相对有限想深度调节采样器、做前缀缓存优化就有点力不从心了。还有一点Ollama 的模型仓库虽然覆盖广但一些特殊模型需要用 Modelfile 手工封装对新手来说又是一个隐藏门槛。我的建议是如果你刚开始接触本地部署或者只是需要一个“能跑模型、能调 API”的轻量方案直接选 Ollama 不会错。它不解决复杂应用问题但它是你最容易跑起来的那个起点。3.2 LM Studio小白友好的图形化之选LM Studio 是那种“宣传图看着漂亮实际用起来也确实漂亮”的工具。它的定位非常清晰不想打命令行、不想看英文文档、不想自己写代码的人也可以通过图形界面完成模型下载、加载、对话。我拿它帮一位做法律翻译的朋友装机全过程就是“搜索模型 - 点下载 - 等进度条 - 选择量化版本 - 点加载 - 开始聊天”。没有出现任何一步需要打开终端的操作这对非技术用户来说非常友好。它还内置了“本地模型服务器”功能可以启动一个兼容 OpenAI 的本地 API 服务给后续接应用留了后路。不过这种“好用”是有代价的。图形界面本身会占用一部分系统资源虽然不多但在低配机器上会放大卡顿感。另外LM Studio 的模型下载和更新依赖它自己的接口有些时候你会发现某个版本的模型在官网已经有了但在 LM Studio 里搜不到需要你手动下载后放到模型目录里。它在性能上和 Ollama 没有本质差距底层都是 llama.cpp 或者类似的原生推理框架量化格式也基本通用。差别主要在交互方式和工程集成度上。如果你是完全不写代码的用户或者你只是想在笔记本上跟模型聊聊天、做做实验LM Studio 会比 Ollama 让你心情愉悦得多。3.3 Dify从模型到应用的“工作流工坊”如果说 Ollama 解决了“模型怎么跑”Dify 解决的就是“模型怎么用”。Dify 是一个开源的 LLM 应用开发平台它把模型接入、提示词编排、知识库管理、Agent、工作流、API 发布这些都做成了可视化操作。你在界面上拖一拖、点一点就能把一个普通的模型调用变成“带知识库检索的问答机器人”或者“能查数据库、能算数据的 Agent 应用”。我在实际项目里用 Dify 搭过一个内部文档助手。流程大概是这样先把几百份 PDF 交给 MinerU 做解析转成干净的 Markdown然后通过 Dify 的知识库模块完成文档分段和向量化最后接上 Ollama 提供的本地模型接口把对话流程发布给团队使用。整个过程我没有写一行后端代码。但 Dify 的上手曲线明显比前两款高。它不是一个“点开就能跑模型”的工具而是一个“需要你理解应用架构”的平台。你要明白什么是 Embedding、什么是向量数据库、什么是上下文窗口、什么是工具调用才能在 Dify 里做出靠谱的东西。初学者一上来容易把工作流节点拖得乱七八糟最后调试到心态爆炸。我的实操心得是Dify 和 Ollama 是本地部署里非常有性价比的组合。Dify 通过http://localhost:11434接入 Ollama然后在模型供应商里填好模型名称就能完成对接。注意要提前在 Ollama 里拉好对应模型因为 Dify 本身不会帮你下载权重。资源占用方面Dify 推荐用 Docker 部署默认会启动 Postgres、Redis、Weaviate 等依赖吃内存比较厉害至少给它 8G 内存才稳。3.4 AnythingLLM私有知识库问答的开箱方案AnythingLLM 和 Dify 有一部分功能重叠但它的切入角度更垂直私有知识库问答。它主打的是“把文档丢进去就能基于文档聊天”的完整体验。我拿它做过一次个人资料归档测试把自己写的几十篇技术笔记主要是 Markdown 和 TXT 格式扔进去向量化完成后问它“我今年写过哪些关于本地部署的文章”回答得相当准确来源引用也能直接定位到具体文档。这种“最小可用”的体验是 Dify 比不了的——Dify 需要你手动配置知识库和模型而 AnythingLLM 把默认路径给你铺好了。AnythingLLM 的默认架构是前端桌面应用或者 Web 端 本地向量库 你指定的 LLM 接口。你可以接 Ollama、LM Studio 也可以接 OpenAI 兼容 API。它的 Workspace工作区概念很实用不同工作区可以绑定不同文档集和模型参数适合一个人管理多个知识库。但说实话AnythingLLM 做轻量演示和团队小范围使用可以真拿到生产环境还是单薄了一点。权限体系比较简单、并发能力有限、定制化空间不大。如果你想深度定制召回策略或者做复杂的多轮 Agent还是需要回到 Dify 这类平台上去。它的价值在于“快”从下载到能跑通常半小时内就搞定。3.5 OpenClaw把多智能体跑在本地的探索者OpenClaw 是这几款里最有“极客味”的一个。它不是一个聊天工具而是一个能让多个 AI Agent 协作完成任务的自动化框架强调用自然语言调度本地工具、插件和模型。我第一次跑 OpenClaw 时有一种“在搭建一个小团队”的感觉有个 Agent 负责查资料有个 Agent 负责整理笔记还有一个 Agent 负责调用代码解释器来算数。它们之间通过任务队列和消息传递来协作而我做的只是用自然语言给它们下了一个总目标。这和 ChatGPT 里那种单轮对话式 Agent 有本质区别更像是在本机起了一个异步多角色的自动化系统。它的部署方式不算复杂核心依赖是 Docker 和 Node.js 环境。配置文件中可以指定模型提供商我直接把它接到了本地 Ollama 服务上。实测跑一些简单的“总结文档 生成周报”任务效果还可以但稳定性确实不如商业产品。多智能体在本地模型上跑最大的问题是上下文管理每个 Agent 都会占用上下文窗口几个 Agent 一协作7B 模型的小窗口很快就被塞满了。如果你想追最新的 Agent 玩法OpenClaw 值得一试但没必要上来就用它承载核心业务。它的最佳定位是一个“探索工具”用来理解多智能体协作的机制以及本地模型在复杂任务链上的能力边界。跑完几个示例任务你心里就对“本地 Agent 能做什么、不能做什么”有数了。3.6 MinerU文档解析RAG 管线的第一道工序很多人做 RAG检索增强生成时把精力全放在向量库和模型上结果效果不好最后发现是文档解析环节出了问题。PDF 里的表格、多栏排版、扫描图片如果不经过处理直接切割喂给模型的知识库就是一团乱麻。这时候就需要 MinerU。MinerU 是上海人工智能实验室开源的工具专门做文档内容提取能把 PDF 转成结构清晰的 Markdown并识别标题、段落、表格、图片位置。我在搭建知识库时被各种格式的 PDF 折磨过有扫描版、有多栏、有加密的、有表格嵌套的直接丢给向量库的效果惨不忍睹。后来用 MinerU 先统一处理一遍再进 Dify 做切片和向量化检索准确率肉眼可见地提升了一个档。使用 MinerU 最简单的方式是通过命令行# 使用 GPU 加速解析 mineru -p input.pdf -o output_dir # 指定设备类型没有 GPU 时用 CPU 跑 mineru -p input.pdf -o output_dir --device cpu需要注意MinerU 对扫描版 PDF 的识别依赖 OCR 模型第一次运行会自动下载相关模型权重。在国内网络环境下模型下载偶尔会慢可以考虑配置代理或手动下载放置到缓存目录。解析大体积 PDF 时时间和内存消耗都不小我处理一本 300 页的扫描版书籍时耗时接近十几分钟属于正常的“重活”。不要低估这个工具在 RAG 生态里的价值。一个知识库系统效果好不好30% 靠模型30% 靠向量化策略40% 靠源文档的解析质量。MinerU 就是那 40% 里的关键答案。3.7 vLLM生产级高性能推理引擎如果前面的工具都偏向“易用”vLLM 则完全站在另一边——“性能”。它由加州大学伯克利分校团队开源核心创新是 PagedAttention分页注意力机制极大地减少了显存碎片让高并发推理成为可能。每当有人问我“本地部署能不能支撑几十个人同时用”我的第一反应就是 vLLM。使用 vLLM 需要一定的 Python 基础。它不是一个开箱即用的桌面工具而是让你在代码程序里加载模型、启动推理服务# 通过命令行启动一个兼容 OpenAI 的推理服务 vllm serve Qwen/Qwen2.5-7B-Instruct --host 0.0.0.0 --port 8000启动后它会提供一个http://localhost:8000/v1接口行为和 OpenAI API 几乎一样from openai import OpenAI client OpenAI(base_urlhttp://localhost:8000/v1, api_keyunused) resp client.chat.completions.create( modelQwen/Qwen2.5-7B-Instruct, messages[{role: user, content: 你好}] ) print(resp.choices[0].message.content)vLLM 的并发能力非常强特别适合给团队内部提供统一的模型服务。在单张 RTX 4090 上7B 量化模型支持几十路并发是完全可能的这个量级 Ollama 根本做不到。不过它的资源占用和部署复杂度也更高。它需要 Python 环境、CUDA 版本匹配、合理的启动参数不像 Ollama 那样“装完就能跑”。显存不够大的机器连量化模型加载都可能失败。我的建议是自己随便玩优先 Ollama要给一个团队或一个产品提供稳定推理服务再考虑 vLLM。它的学习成本值得花但没必要每个人都去啃一遍。4. 横向对比性能、易用性、资源占用、生态扩展4.1 维度说明与评分标准本地部署工具的对比单纯比“跑得有多快”没有意义。因为工具定位不同硬比性能反而失真。我更习惯从四个维度来看一是易用性指一个完全没有背景知识的人从零开始到跑通默认功能需要多久。Ollama 和 LM Studio 在这个维度明显领先。二是性能与并发指模型推理速度、多请求处理能力以及做正式服务时的稳定性。vLLM 是这里的天花板。三是资源占用指工具本身的额外开销和它对显存、内存的利用效率。四是生态扩展指能不能方便地接入 API、知识库、第三方应用以及社区活跃度。Dify 和 Ollama 在生态上表现最好。4.2 横向对比表这张表里我给了自己用过一段时间后的主观评分分数基于“我在普通消费级硬件RTX 4070 / 32G 内存 / Win11 WSL2上的体验”仅供参考。工具易用性并发能力资源占用生态扩展上手成本推荐度综合Ollama94低8极低9LM Studio93中5极低8Dify56高9中高8AnythingLLM74中6低7OpenClaw43中高5高5MinerU62高6中7vLLM39高8高7单看这张表Ollama 好像无敌但这完全是因为它把“简单”做到了极致。复杂场景下它的“生态”主要停留在“能跑很多模型”而不是“能构建复杂应用”。Dify 的推荐度紧随其后就因为它解决的是 Ollama 解决不了的应用层问题。4.3 按场景推荐什么情况选哪款根据用途来选的话我的建议如下。如果只是想在个人电脑上体验本地大模型或者写脚本调用模型做自动化选 Ollama。想在 Mac 或者 Windows 桌面上安安静静聊个天不折腾命令选 LM Studio。想做一个团队可用的知识库问答系统选 AnythingLLM 做快速原型如果希望这东西能长期迭代、支持更复杂的权限和流程那直接上 Dify。如果手头有一批 PDF、扫描文档要变成结构化内容交给 MinerU。如果要做多智能体实验OpenClaw。如果本地模型将来要当成一个正式服务对外开放那 vLLM 是绕不开的选项。这几条路线并不矛盾。我自己的主力方案就是MinerU 解析文档Dify 做应用编排Ollama 提供轻量推理关键时刻再开 vLLM 顶高并发。工具之间是配合关系不是替代关系。5. 实战用 Ollama 跑一个可用的本地大模型附参数说了这么多对比还是要落一次地。这一节我用 Ollama 为例演示一个完整流程从安装到通过 API 把模型接进自己的代码里。选 Ollama 的理由很简单它是当前本地部署环境中“边际成本最低”的一环。5.1 环境准备与安装Ollama 官方支持 Windows、macOS、Linux。最简单的方式是去官网下载对应的安装包装完在终端输入ollama --version验证。如果使用 Docker也可以用一行命令起服务docker run -d -v ollama:/root/.ollama -p 11434:11434 --name ollama ollama/ollama这里重点说一个很多人容易忽略的点Ollama 的模型默认存储在系统盘的用户目录下模型文件动辄几个 GB系统盘空间不够时会请求失败。可以在运行 Ollama 之前设置环境变量OLLAMA_MODELS来指定模型存储路径。比如在 Linux 的~/.bashrc里加一行export OLLAMA_MODELS/data/ollama/models这个动作能帮你避免“模型下载到一半空间不足”的尴尬。Windows 用户可以在系统环境变量里直接添加。我踩过这个坑所以每次装新机器都会先设置模型目录再去拉模型。5.2 拉取模型、启动服务、验证调用选模型时建议新手先从 7B 参数的量化版本开始比如qwen2.5:7b或llama3.1:8b这类模型在 8G 显存或 16G 内存的机器上都能流畅运行。拉取并启动# 拉取模型默认是 q4_K_M 量化版本 ollama pull qwen2.5:7b # 保持 ollama serve 在后台运行 # 如果之前没启动可以先执行一次 ollama serve ollama serve确认服务正常可以用curl快速验证curl http://localhost:11434/api/generate -d { model: qwen2.5:7b, prompt: 你好请简单介绍一下自己。 }如果能看到流式返回的 JSON说明本地服务已经跑通。之后用任何支持 OpenAI 兼容接口的客户端把base_url指向http://localhost:11434/v1就能开始调用。5.3 显存、内存、CPU 取舍的关键原则本地部署的硬件矛盾本质上是“模型大小”和“可用内存/显存”之间的矛盾。一个 7B 模型的 FP16 权重约 14GB量化到 4bit 后约 4GB 左右。显存不足时Ollama 会自动将部分层放到内存中由 CPU 参与推理但这会大幅降低生成速度。我的经验是生成速度的瓶颈主要看“内存带宽”而不是看 CPU 主频。Apple Silicon 统一内存架构在这方面很有优势所以 Mac 跑中小模型的表现并不输普通 Windows 游戏本。如果是 NVIDIA 显卡优先保证显存足够装下整个量化模型显存不够时再考虑 CPUGPU 混合方案。真要在老机器上跑就尽量选 3B、1.5B 的小模型体验反而更好。顺带再分享一个参数技巧Ollama 可以通过设置环境变量OLLAMA_NUM_PARALLEL调整并行请求数默认是 1也就是同一时间只能处理一个请求。如果想多开几个会话可以设成 4 试一下但前提是内存足够。export OLLAMA_NUM_PARALLEL4这个值不是越大越好开多了上下文叠加显存会快速爆满对延迟的改善也很有限。自己试几个档位找到一个“刚好不卡”的平衡点就好。6. 常见问题与排查技巧实录6.1 问题速查表本地部署看起来简单实操中翻车的地方却非常集中。我把这些年在各类机器上遇到的问题整理成了一张速查表大部分情况下照着排查都能解决。现象可能原因解决方案模型下载到一半失败网络波动或存储空间不足设置OLLAMA_MODELS指向剩余空间大的磁盘重试下载加载模型时直接进程崩溃显存不足量化精度过高换更低的量化版本像 q4 换成 q3或使用更小模型生成速度极慢每秒不到 5 tokenCPU 参与推理或上下文过长换小模型、减少num_ctx、增加内存带宽更好的硬件API 接口能通但应用连不上地址填错或跨机器访问无监听检查是否监听0.0.0.0跨机访问要设置OLLAMA_HOSTDify 接入 Ollama 后报模型不存在Ollama 中没有拉取该模型先在 Ollama 执行ollama pull 模型名Dify 里名称保持一致MinerU 解析 PDF 时卡在 OCR模型下载不完整或设备配置不对重新下载 OCR 模型确认--device参数与硬件一致vLLM 启动提示 CUDA 版本不正确PyTorch 与本地驱动不匹配按官方文档安装与 CUDA 版本对应的 PyTorch 轮子OpenClaw 内 Agent 频繁丢失上下文模型上下文窗口太小改用 32K 上下文的模型或减少单次任务的子步骤数量6.2 三个值得记住的排查思路第一个思路分清“模型问题”还是“工具问题”。当应用没反应时先用curl直接调用模型接口。如果接口本身返回正常问题就出在应用和模型的对接层比如地址、模型名、API 格式或时间超时。大多数 Dify 和 AnythingLLM 接入失败都发生在这个环节。第二个思路观察资源占用要“看过程而不是看峰值”。很多人在任务刚开始显存还没达到峰值时就以为跑不动过早放弃。应该用nvidia-smi -l 1连续观察几秒确认显存曲线和生成速度的关系再决定要不要调低参数。第三个思路多关注日志而不是凭感觉猜。Ollama 的日志会输出 GPU/CPU 层分配信息vLLM 的日志会告诉你 KV Cache 占用多少显存MinerU 的日志会标明当前在解析哪一页。遇到问题先看日志很多时候答案就在最后几行里。最后分享一点个人体会这几款工具我用下来最大的感受是本地部署真正难的从来不是“把模型跑起来”而是“把方案选得足够合理”。Ollama 够简单但它撑不起复杂应用vLLM 够强但普通人没必要上来就啃它。懂原理、熟悉每款工具的性格再按自己的场景做组合才是性价比最高的路径。我自己现在的工作流已经固定了写代码和跑实验用 Ollama做团队应用用 Dify处理文档用 MinerU压力测试和高并发场景交给 vLLM。这个组合不是所有人通用但它帮我踩过了大多数坑。如果你正准备入坑本地部署不妨也先花一个下午把这篇文章里提到的工具各试一遍感受一下它们各自的长短。试完之后你大概率就知道哪些工具适合留在你的工具箱里了。 本地大模型部署工具横向对比：Ollama、Dify、vLLM等7款选型指南
1. 先想清楚为什么要在本地跑大模型这几年“AI本地部署”被提得越来越频繁差不多已经到了程序员茶余饭后必聊的程度。很多人一看到 Ollama、LM Studio、Dify 这些名字就跟着下载结果装完发现要么跑不起来要么跑起来了不知道自己该拿它做什么。我身边就有同事折腾了一个周末最后停在“模型能聊天”这一步然后就没了下文。如果要给“AI本地部署”下个通俗定义其实就一句话把大语言模型LLM的推理过程从云端 API 搬到你自己的电脑或服务器上让模型的权重文件、上下文数据、生成结果全部只经过你手里的硬件。听起来很酷但真正动手之前得先想明白“为什么”。我自己的经验是适合本地部署的场景大概有三类。第一类是数据敏感场景。比如企业内部的合同、代码、客户资料这些内容本身不适合发送到外部 API。本地部署之后所有请求都在内网完成至少在数据出域的环节上少了一个风险点。第二类是长期使用比较在意成本的情况。高频调用商业 API 的账单会很难看尤其是做批量生成、批量总结、跑 Agent 循环时token 消耗跟流水一样。本地部署虽然要买硬件、花电费但跑熟了之后边际成本确实更低。第三类是稳定性和自由度。没有网络依赖、不受 API 限流影响、可以随便换模型、可以改采样参数这些对做技术研究和做产品原型的人来说都是实打实的好处。不过也要泼一盆冷水本地部署不等于万能。它受显卡显存、内存带宽、供电散热的限制非常明显7B 级别的模型在消费级显卡上表现尚可70B 级别就需要多卡或量化方案了。所以这篇文章不是一个“无脑推荐”而是一份从实际使用出发的横向对比帮你判断“我这个需求到底该用哪一款”。适合读这篇文章的是有一定动手能力、想把大模型真正落到本机的开发者、算法工程师、产品原型爱好者以及所有对数据隐私有要求的人。2. 7款热门工具大盘点各自想吃哪碗饭2.1 一句话定位速览表先给一张速览表把7款工具按“它本质上是什么东西”来分个类。很多人选错工具是因为根本没搞清楚自己需要的是“模型运行器”还是“应用开发平台”。工具本质定位最擅长的事典型使用人群Ollama模型运行器/模型管理 CLI快速拉起 Llama、Qwen、DeepSeek 等开源模型提供 OpenAI 兼容 API开发者、刚入门本地部署的用户LM Studio图形化桌面客户端可视化下载、加载、测试模型上手零门槛没有编程经验、想用本地 AI 聊天或做实验的用户DifyLLM 应用开发平台把模型接入知识库、工作流、Agent快速做应用产品经理、后端开发者、想做完整应用的人AnythingLLM私有知识库问答应用本地文档导入 向量化 聊天问答的开箱方案企业知识管理、个人资料库用户OpenClaw多智能体自动化框架用自然语言指挥多个 AI 工具协作完成复杂任务AI Agent 玩家、技术探索型用户MinerU文档解析/内容提取工具把 PDF、扫描件转成结构化 Markdown保障 RAG 质量做资料库、RAG 管线、内容中台的人vLLM高性能推理引擎高吞吐、高并发的模型推理服务支持 PagedAttention把模型做成在线服务、对性能有要求的工程师这7款工具不是同一个赛道的竞品更多是“本地部署生态里的不同环节”。理解这一点才能看明白后面的横向对比表。2.2 选型前先搞懂三类“部署工具”我发现很多人在本地部署时卡住不是因为电脑不够好而是脑子里没有分类概念。本地部署工具大致分三层。最底层是“模型推理引擎”。它负责把模型权重加载进显存处理输入输出核心指标是吞吐量、显存占用、并发能力。Ollama 和 vLLM 都属于这一层但二者取向完全不同Ollama 追求的是“上手快、资源省”vLLM 追求的是“性能高、并发强”。中间层是“应用开发框架”。它在模型之上帮你封装好 API、数据库、知识库、流程编排、对话管理。Dify 属于这一类。使用它的人通常不只是“想聊天”而是想搭一个具备工具调用、文档问答、工作流处理能力的产品。AnythingLLM 的位置更偏向“即插即用的知识库应用”你可以不写代码就完成私有文档问答。最上层是“专项工具”。它们不是通用的 LLM 平台而是解决某个具体环节。比如 MinerU 解决的是文档解析OpenClaw 解决的是多智能体编排。这类工具常常和其他部署方案搭配使用MinerU 解析出干净文本Dify 做向量化和检索Ollama 负责模型推理OpenClaw 调度整个流程。所以我给所有准备入坑的人一个建议先确定你要做的是“聊天”“应用”还是“流水线”再选工具。要是目的都没定看着哪个工具火就装哪个大概率会踩坑。3. 七款工具逐个拆解我的真实使用感受3.1 Ollama轻量、快、省心入门首选Ollama 几乎已经成为本地大模型部署的代名词。我第一次接触它时最大的感受是“没什么存在感”——安装完几条命令就把模型拉下来跑起来了整个流程顺到不像本地方案。# 安装完成后拉取一个 7B 量级的中文模型试试 ollama pull qwen2.5:7b # 直接开启交互式对话 ollama run qwen2.5:7b # 启动 API 服务默认监听 11434 端口 ollama serve它的设计思路非常符合“最小可用”原则模型仓库统一管理、命令行工具极简、自带 OpenAI 兼容接口。你甚至可以用一行 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 在 Mac 和大多数 Linux 机器上表现都不错尤其是 Apple Silicon 平台它会自动利用 Metal 加速。我在 M 系列芯片上跑 7B 模型生成速度能达到 20~30 token/s体感非常流畅。但它的短板也很明显。首先并发能力弱多个请求同时进来时默认方案基本是排队处理不适合高并发的在线服务。其次参数控制相对有限想深度调节采样器、做前缀缓存优化就有点力不从心了。还有一点Ollama 的模型仓库虽然覆盖广但一些特殊模型需要用 Modelfile 手工封装对新手来说又是一个隐藏门槛。我的建议是如果你刚开始接触本地部署或者只是需要一个“能跑模型、能调 API”的轻量方案直接选 Ollama 不会错。它不解决复杂应用问题但它是你最容易跑起来的那个起点。3.2 LM Studio小白友好的图形化之选LM Studio 是那种“宣传图看着漂亮实际用起来也确实漂亮”的工具。它的定位非常清晰不想打命令行、不想看英文文档、不想自己写代码的人也可以通过图形界面完成模型下载、加载、对话。我拿它帮一位做法律翻译的朋友装机全过程就是“搜索模型 - 点下载 - 等进度条 - 选择量化版本 - 点加载 - 开始聊天”。没有出现任何一步需要打开终端的操作这对非技术用户来说非常友好。它还内置了“本地模型服务器”功能可以启动一个兼容 OpenAI 的本地 API 服务给后续接应用留了后路。不过这种“好用”是有代价的。图形界面本身会占用一部分系统资源虽然不多但在低配机器上会放大卡顿感。另外LM Studio 的模型下载和更新依赖它自己的接口有些时候你会发现某个版本的模型在官网已经有了但在 LM Studio 里搜不到需要你手动下载后放到模型目录里。它在性能上和 Ollama 没有本质差距底层都是 llama.cpp 或者类似的原生推理框架量化格式也基本通用。差别主要在交互方式和工程集成度上。如果你是完全不写代码的用户或者你只是想在笔记本上跟模型聊聊天、做做实验LM Studio 会比 Ollama 让你心情愉悦得多。3.3 Dify从模型到应用的“工作流工坊”如果说 Ollama 解决了“模型怎么跑”Dify 解决的就是“模型怎么用”。Dify 是一个开源的 LLM 应用开发平台它把模型接入、提示词编排、知识库管理、Agent、工作流、API 发布这些都做成了可视化操作。你在界面上拖一拖、点一点就能把一个普通的模型调用变成“带知识库检索的问答机器人”或者“能查数据库、能算数据的 Agent 应用”。我在实际项目里用 Dify 搭过一个内部文档助手。流程大概是这样先把几百份 PDF 交给 MinerU 做解析转成干净的 Markdown然后通过 Dify 的知识库模块完成文档分段和向量化最后接上 Ollama 提供的本地模型接口把对话流程发布给团队使用。整个过程我没有写一行后端代码。但 Dify 的上手曲线明显比前两款高。它不是一个“点开就能跑模型”的工具而是一个“需要你理解应用架构”的平台。你要明白什么是 Embedding、什么是向量数据库、什么是上下文窗口、什么是工具调用才能在 Dify 里做出靠谱的东西。初学者一上来容易把工作流节点拖得乱七八糟最后调试到心态爆炸。我的实操心得是Dify 和 Ollama 是本地部署里非常有性价比的组合。Dify 通过http://localhost:11434接入 Ollama然后在模型供应商里填好模型名称就能完成对接。注意要提前在 Ollama 里拉好对应模型因为 Dify 本身不会帮你下载权重。资源占用方面Dify 推荐用 Docker 部署默认会启动 Postgres、Redis、Weaviate 等依赖吃内存比较厉害至少给它 8G 内存才稳。3.4 AnythingLLM私有知识库问答的开箱方案AnythingLLM 和 Dify 有一部分功能重叠但它的切入角度更垂直私有知识库问答。它主打的是“把文档丢进去就能基于文档聊天”的完整体验。我拿它做过一次个人资料归档测试把自己写的几十篇技术笔记主要是 Markdown 和 TXT 格式扔进去向量化完成后问它“我今年写过哪些关于本地部署的文章”回答得相当准确来源引用也能直接定位到具体文档。这种“最小可用”的体验是 Dify 比不了的——Dify 需要你手动配置知识库和模型而 AnythingLLM 把默认路径给你铺好了。AnythingLLM 的默认架构是前端桌面应用或者 Web 端 本地向量库 你指定的 LLM 接口。你可以接 Ollama、LM Studio 也可以接 OpenAI 兼容 API。它的 Workspace工作区概念很实用不同工作区可以绑定不同文档集和模型参数适合一个人管理多个知识库。但说实话AnythingLLM 做轻量演示和团队小范围使用可以真拿到生产环境还是单薄了一点。权限体系比较简单、并发能力有限、定制化空间不大。如果你想深度定制召回策略或者做复杂的多轮 Agent还是需要回到 Dify 这类平台上去。它的价值在于“快”从下载到能跑通常半小时内就搞定。3.5 OpenClaw把多智能体跑在本地的探索者OpenClaw 是这几款里最有“极客味”的一个。它不是一个聊天工具而是一个能让多个 AI Agent 协作完成任务的自动化框架强调用自然语言调度本地工具、插件和模型。我第一次跑 OpenClaw 时有一种“在搭建一个小团队”的感觉有个 Agent 负责查资料有个 Agent 负责整理笔记还有一个 Agent 负责调用代码解释器来算数。它们之间通过任务队列和消息传递来协作而我做的只是用自然语言给它们下了一个总目标。这和 ChatGPT 里那种单轮对话式 Agent 有本质区别更像是在本机起了一个异步多角色的自动化系统。它的部署方式不算复杂核心依赖是 Docker 和 Node.js 环境。配置文件中可以指定模型提供商我直接把它接到了本地 Ollama 服务上。实测跑一些简单的“总结文档 生成周报”任务效果还可以但稳定性确实不如商业产品。多智能体在本地模型上跑最大的问题是上下文管理每个 Agent 都会占用上下文窗口几个 Agent 一协作7B 模型的小窗口很快就被塞满了。如果你想追最新的 Agent 玩法OpenClaw 值得一试但没必要上来就用它承载核心业务。它的最佳定位是一个“探索工具”用来理解多智能体协作的机制以及本地模型在复杂任务链上的能力边界。跑完几个示例任务你心里就对“本地 Agent 能做什么、不能做什么”有数了。3.6 MinerU文档解析RAG 管线的第一道工序很多人做 RAG检索增强生成时把精力全放在向量库和模型上结果效果不好最后发现是文档解析环节出了问题。PDF 里的表格、多栏排版、扫描图片如果不经过处理直接切割喂给模型的知识库就是一团乱麻。这时候就需要 MinerU。MinerU 是上海人工智能实验室开源的工具专门做文档内容提取能把 PDF 转成结构清晰的 Markdown并识别标题、段落、表格、图片位置。我在搭建知识库时被各种格式的 PDF 折磨过有扫描版、有多栏、有加密的、有表格嵌套的直接丢给向量库的效果惨不忍睹。后来用 MinerU 先统一处理一遍再进 Dify 做切片和向量化检索准确率肉眼可见地提升了一个档。使用 MinerU 最简单的方式是通过命令行# 使用 GPU 加速解析 mineru -p input.pdf -o output_dir # 指定设备类型没有 GPU 时用 CPU 跑 mineru -p input.pdf -o output_dir --device cpu需要注意MinerU 对扫描版 PDF 的识别依赖 OCR 模型第一次运行会自动下载相关模型权重。在国内网络环境下模型下载偶尔会慢可以考虑配置代理或手动下载放置到缓存目录。解析大体积 PDF 时时间和内存消耗都不小我处理一本 300 页的扫描版书籍时耗时接近十几分钟属于正常的“重活”。不要低估这个工具在 RAG 生态里的价值。一个知识库系统效果好不好30% 靠模型30% 靠向量化策略40% 靠源文档的解析质量。MinerU 就是那 40% 里的关键答案。3.7 vLLM生产级高性能推理引擎如果前面的工具都偏向“易用”vLLM 则完全站在另一边——“性能”。它由加州大学伯克利分校团队开源核心创新是 PagedAttention分页注意力机制极大地减少了显存碎片让高并发推理成为可能。每当有人问我“本地部署能不能支撑几十个人同时用”我的第一反应就是 vLLM。使用 vLLM 需要一定的 Python 基础。它不是一个开箱即用的桌面工具而是让你在代码程序里加载模型、启动推理服务# 通过命令行启动一个兼容 OpenAI 的推理服务 vllm serve Qwen/Qwen2.5-7B-Instruct --host 0.0.0.0 --port 8000启动后它会提供一个http://localhost:8000/v1接口行为和 OpenAI API 几乎一样from openai import OpenAI client OpenAI(base_urlhttp://localhost:8000/v1, api_keyunused) resp client.chat.completions.create( modelQwen/Qwen2.5-7B-Instruct, messages[{role: user, content: 你好}] ) print(resp.choices[0].message.content)vLLM 的并发能力非常强特别适合给团队内部提供统一的模型服务。在单张 RTX 4090 上7B 量化模型支持几十路并发是完全可能的这个量级 Ollama 根本做不到。不过它的资源占用和部署复杂度也更高。它需要 Python 环境、CUDA 版本匹配、合理的启动参数不像 Ollama 那样“装完就能跑”。显存不够大的机器连量化模型加载都可能失败。我的建议是自己随便玩优先 Ollama要给一个团队或一个产品提供稳定推理服务再考虑 vLLM。它的学习成本值得花但没必要每个人都去啃一遍。4. 横向对比性能、易用性、资源占用、生态扩展4.1 维度说明与评分标准本地部署工具的对比单纯比“跑得有多快”没有意义。因为工具定位不同硬比性能反而失真。我更习惯从四个维度来看一是易用性指一个完全没有背景知识的人从零开始到跑通默认功能需要多久。Ollama 和 LM Studio 在这个维度明显领先。二是性能与并发指模型推理速度、多请求处理能力以及做正式服务时的稳定性。vLLM 是这里的天花板。三是资源占用指工具本身的额外开销和它对显存、内存的利用效率。四是生态扩展指能不能方便地接入 API、知识库、第三方应用以及社区活跃度。Dify 和 Ollama 在生态上表现最好。4.2 横向对比表这张表里我给了自己用过一段时间后的主观评分分数基于“我在普通消费级硬件RTX 4070 / 32G 内存 / Win11 WSL2上的体验”仅供参考。工具易用性并发能力资源占用生态扩展上手成本推荐度综合Ollama94低8极低9LM Studio93中5极低8Dify56高9中高8AnythingLLM74中6低7OpenClaw43中高5高5MinerU62高6中7vLLM39高8高7单看这张表Ollama 好像无敌但这完全是因为它把“简单”做到了极致。复杂场景下它的“生态”主要停留在“能跑很多模型”而不是“能构建复杂应用”。Dify 的推荐度紧随其后就因为它解决的是 Ollama 解决不了的应用层问题。4.3 按场景推荐什么情况选哪款根据用途来选的话我的建议如下。如果只是想在个人电脑上体验本地大模型或者写脚本调用模型做自动化选 Ollama。想在 Mac 或者 Windows 桌面上安安静静聊个天不折腾命令选 LM Studio。想做一个团队可用的知识库问答系统选 AnythingLLM 做快速原型如果希望这东西能长期迭代、支持更复杂的权限和流程那直接上 Dify。如果手头有一批 PDF、扫描文档要变成结构化内容交给 MinerU。如果要做多智能体实验OpenClaw。如果本地模型将来要当成一个正式服务对外开放那 vLLM 是绕不开的选项。这几条路线并不矛盾。我自己的主力方案就是MinerU 解析文档Dify 做应用编排Ollama 提供轻量推理关键时刻再开 vLLM 顶高并发。工具之间是配合关系不是替代关系。5. 实战用 Ollama 跑一个可用的本地大模型附参数说了这么多对比还是要落一次地。这一节我用 Ollama 为例演示一个完整流程从安装到通过 API 把模型接进自己的代码里。选 Ollama 的理由很简单它是当前本地部署环境中“边际成本最低”的一环。5.1 环境准备与安装Ollama 官方支持 Windows、macOS、Linux。最简单的方式是去官网下载对应的安装包装完在终端输入ollama --version验证。如果使用 Docker也可以用一行命令起服务docker run -d -v ollama:/root/.ollama -p 11434:11434 --name ollama ollama/ollama这里重点说一个很多人容易忽略的点Ollama 的模型默认存储在系统盘的用户目录下模型文件动辄几个 GB系统盘空间不够时会请求失败。可以在运行 Ollama 之前设置环境变量OLLAMA_MODELS来指定模型存储路径。比如在 Linux 的~/.bashrc里加一行export OLLAMA_MODELS/data/ollama/models这个动作能帮你避免“模型下载到一半空间不足”的尴尬。Windows 用户可以在系统环境变量里直接添加。我踩过这个坑所以每次装新机器都会先设置模型目录再去拉模型。5.2 拉取模型、启动服务、验证调用选模型时建议新手先从 7B 参数的量化版本开始比如qwen2.5:7b或llama3.1:8b这类模型在 8G 显存或 16G 内存的机器上都能流畅运行。拉取并启动# 拉取模型默认是 q4_K_M 量化版本 ollama pull qwen2.5:7b # 保持 ollama serve 在后台运行 # 如果之前没启动可以先执行一次 ollama serve ollama serve确认服务正常可以用curl快速验证curl http://localhost:11434/api/generate -d { model: qwen2.5:7b, prompt: 你好请简单介绍一下自己。 }如果能看到流式返回的 JSON说明本地服务已经跑通。之后用任何支持 OpenAI 兼容接口的客户端把base_url指向http://localhost:11434/v1就能开始调用。5.3 显存、内存、CPU 取舍的关键原则本地部署的硬件矛盾本质上是“模型大小”和“可用内存/显存”之间的矛盾。一个 7B 模型的 FP16 权重约 14GB量化到 4bit 后约 4GB 左右。显存不足时Ollama 会自动将部分层放到内存中由 CPU 参与推理但这会大幅降低生成速度。我的经验是生成速度的瓶颈主要看“内存带宽”而不是看 CPU 主频。Apple Silicon 统一内存架构在这方面很有优势所以 Mac 跑中小模型的表现并不输普通 Windows 游戏本。如果是 NVIDIA 显卡优先保证显存足够装下整个量化模型显存不够时再考虑 CPUGPU 混合方案。真要在老机器上跑就尽量选 3B、1.5B 的小模型体验反而更好。顺带再分享一个参数技巧Ollama 可以通过设置环境变量OLLAMA_NUM_PARALLEL调整并行请求数默认是 1也就是同一时间只能处理一个请求。如果想多开几个会话可以设成 4 试一下但前提是内存足够。export OLLAMA_NUM_PARALLEL4这个值不是越大越好开多了上下文叠加显存会快速爆满对延迟的改善也很有限。自己试几个档位找到一个“刚好不卡”的平衡点就好。6. 常见问题与排查技巧实录6.1 问题速查表本地部署看起来简单实操中翻车的地方却非常集中。我把这些年在各类机器上遇到的问题整理成了一张速查表大部分情况下照着排查都能解决。现象可能原因解决方案模型下载到一半失败网络波动或存储空间不足设置OLLAMA_MODELS指向剩余空间大的磁盘重试下载加载模型时直接进程崩溃显存不足量化精度过高换更低的量化版本像 q4 换成 q3或使用更小模型生成速度极慢每秒不到 5 tokenCPU 参与推理或上下文过长换小模型、减少num_ctx、增加内存带宽更好的硬件API 接口能通但应用连不上地址填错或跨机器访问无监听检查是否监听0.0.0.0跨机访问要设置OLLAMA_HOSTDify 接入 Ollama 后报模型不存在Ollama 中没有拉取该模型先在 Ollama 执行ollama pull 模型名Dify 里名称保持一致MinerU 解析 PDF 时卡在 OCR模型下载不完整或设备配置不对重新下载 OCR 模型确认--device参数与硬件一致vLLM 启动提示 CUDA 版本不正确PyTorch 与本地驱动不匹配按官方文档安装与 CUDA 版本对应的 PyTorch 轮子OpenClaw 内 Agent 频繁丢失上下文模型上下文窗口太小改用 32K 上下文的模型或减少单次任务的子步骤数量6.2 三个值得记住的排查思路第一个思路分清“模型问题”还是“工具问题”。当应用没反应时先用curl直接调用模型接口。如果接口本身返回正常问题就出在应用和模型的对接层比如地址、模型名、API 格式或时间超时。大多数 Dify 和 AnythingLLM 接入失败都发生在这个环节。第二个思路观察资源占用要“看过程而不是看峰值”。很多人在任务刚开始显存还没达到峰值时就以为跑不动过早放弃。应该用nvidia-smi -l 1连续观察几秒确认显存曲线和生成速度的关系再决定要不要调低参数。第三个思路多关注日志而不是凭感觉猜。Ollama 的日志会输出 GPU/CPU 层分配信息vLLM 的日志会告诉你 KV Cache 占用多少显存MinerU 的日志会标明当前在解析哪一页。遇到问题先看日志很多时候答案就在最后几行里。最后分享一点个人体会这几款工具我用下来最大的感受是本地部署真正难的从来不是“把模型跑起来”而是“把方案选得足够合理”。Ollama 够简单但它撑不起复杂应用vLLM 够强但普通人没必要上来就啃它。懂原理、熟悉每款工具的性格再按自己的场景做组合才是性价比最高的路径。我自己现在的工作流已经固定了写代码和跑实验用 Ollama做团队应用用 Dify处理文档用 MinerU压力测试和高并发场景交给 vLLM。这个组合不是所有人通用但它帮我踩过了大多数坑。如果你正准备入坑本地部署不妨也先花一个下午把这篇文章里提到的工具各试一遍感受一下它们各自的长短。试完之后你大概率就知道哪些工具适合留在你的工具箱里了。