本地部署 LLM

把 LLM 跑在本地，这件事已经过了“看起来很酷”的阶段，进入“到底值不值得”的阶段了。

如果只是为了截图发朋友圈，那没必要。
如果你真有下面这些需求，本地推理就很有意义：

• 要处理代码、内部文档、工单、会议纪要，不想默认发到第三方 API
• 希望成本是可预期的，不想被 token 计费慢慢磨
• 网络不稳定，或者干脆需要离线可用
• 做编辑器助手、知识问答这类低延迟交互，来回走公网太磨人
• 想快速比较模型、排查行为、做内部评测

反过来，如果你的需求是“我要最强推理、最长上下文、最稳的工具调用，而且不想操心环境”，那云端模型通常还是更省事。

先别急着选模型，先把问题问对

很多人折腾本地 LLM，最后体验很差，不是因为模型不行，而是因为一开始问错了问题。

真正该先想的是：

• 你要解决的是聊天、代码补全、摘要，还是结构化抽取？
• 你能接受多大的延迟？
• 是一个人自己用，还是一整个团队共用？
• 你更在意隐私、成本，还是绝对效果？
• 机器的瓶颈到底是算力，还是内存？

这些问题，比“最近哪个模型最火”重要得多。

本地推理最现实的瓶颈，不是算力，是内存

本地跑模型，最先卡住你的通常不是 CPU，也不是 GPU 核心数，而是内存。

一个很实用的判断方式：

• 小模型：容易装下、速度快，但能力天花板低
• 中等规模模型：通常是笔记本和个人工作站最实用的甜点区
• 大模型：不是不能跑，但很多时候只是“勉强能跑”，不是“适合日常用”

“能塞进去”和“能舒服地用”，是两回事。

本地体验主要受这些因素影响：

• 可用 RAM / 统一内存 / VRAM
• 内存带宽
• runtime 能不能把主要权重放在高速设备上
• 上下文窗口有多大
• 是否需要并发处理多个请求

一句话总结：买余量，不要只买刚刚够。

量化是本地大模型能落地的关键

没有量化，很多开源模型对普通机器来说根本没法谈实用。

量化的作用很直接：

• 降低模型占用
• 提高推理速度
• 让更多模型能在消费级硬件上跑起来

代价也很直接：

• 精度会掉
• 指令跟随、代码能力、多语言自然度可能受影响
• 量化压得太狠，模型会更“飘”

实践里不要迷信某一个固定量化档位。
更靠谱的做法是：

• 根据任务选模型
• 根据硬件选量化
• 用真实样本看损失是不是可接受

我自己的倾向是：
宁可跑一个稍小一点、量化更合理的模型，也不要硬塞一个更大的模型进去，然后把量化压到输出都开始发虚。

还有个常见误区：
有人拿“模型 A 的正常量化版本”和“模型 B 的极限压缩版本”做对比，然后得出模型结论。
这其实比较的不是模型，而是硬件妥协程度。

本地更私密，但不是自动安全

“本地部署 = 隐私无忧”，这话方向上没错，但不能说得太满。

本地部署真正带来的好处是：

• prompt 和上下文不必默认发到第三方服务
• 日志、存储、保留策略可以自己控制
• 内部知识库、源码、文档可以留在自己的设备或内网里

但下面这些问题不会自动消失：

• runtime 自己可能会留调试日志
• 你的应用可能会把 prompt、响应写进文件、数据库或浏览器缓存
• 剪贴板、shell history、编辑器历史一样可能泄漏内容
• 做 RAG 或索引时，如果权限没管好，照样会把不该看的东西暴露出来

所以本地推理的隐私优势是成立的，但前提是外围系统也别乱来。

选模型不要按榜单，按任务来

到 2026 年，开源模型更新速度已经快到“静态榜单文章几个月就过期”。
比起背型号，更稳妥的方式是按任务选型。

做代码助手

优先看这些：

• 生成代码时是否容易胡编 API
• 看仓库上下文时是否容易偏离目标
• 改配置、写测试、做小范围重构是否稳定
• 多轮修改时是否越来越乱

代码任务别拿 toy prompt 测，直接拿你的真实仓库测：修 bug、补测试、改配置、迁移脚本。

做写作、摘要、整理

优先看这些：

• 能不能控语气
• 会不会擅自扩写
• 能不能严格基于给定材料
• 格式是否稳定

这类任务很多时候不需要最大模型，中等规模 instruct 模型只要 prompt 和上下文管理做得好，已经够用。

做多语言任务

优先看这些：

• 中文是不是自然，不是“翻译腔”
• 行业术语会不会乱译
• 中英混合场景下是否稳定
• 缺信息时会不会乱补

别默认“英文好 = 中文也好”。这个问题非常常见，尤其在技术写作和代码解释场景里。

做抽取、分类、结构化输出

优先看这些：

• JSON 是否稳定
• 缺字段时会不会老老实实返回空，而不是编造
• 多次重复跑结果是否波动很大
• schema 约束下是否容易跑出非法格式

这类任务很多时候拼的不是“聪明”，而是“稳定”。

做交互式聊天

优先看这些：

• 首 token 出得快不快
• 长对话里会不会明显失忆
• 指令跟随是否足够
• 延迟是否在可接受范围内

真做产品时，交互速度经常比 benchmark 多几分更重要。

Ollama 这类本地 runtime 的价值，在于把麻烦收敛掉

你不必绑定某个 runtime，但像 Ollama 这种工具受欢迎，是有原因的：它让“本地起模型服务”这件事，至少没那么折腾。

一个合格的本地 runtime，最好能提供：

• 简单的模型拉取和管理
• 本地 HTTP API
• 流式输出
• 上下文窗口和生成参数控制
• 对常见桌面硬件比较友好的运行方式

很多时候，做内部工具并不需要很复杂的推理框架。
一个本地 runtime，加一个简单 API client，就够把事情做起来。

安装 Ollama

安装方式请以项目当前文档为准，因为平台支持和包分发方式会变：

• Ollama GitHub 仓库

通常的使用方式依然很直接：

ollama serve

另开一个终端：

ollama run <model-name>

或者通过本地 API 调用：

curl http://localhost:11434/api/generate -d '{
  "model": "<model-name>",
  "prompt": "请把下面这段事故复盘整理成 5 条要点"
}'

具体模型名会一直变，工作流不会。

一个实用的本地模型组合，通常就三类

如果是给真实工程团队配本地模型，我一般会先准备三类：

1. 一个通用 instruct 模型
2. 一个偏代码的模型
3. 一个小而快的模型，专门做分类、整理、格式化这类便宜任务

然后给每一类任务准备一小套评估样本。

比如：

• 20 条内部文档摘要
• 20 个代码库问答
• 20 个结构化抽取样本
• 10 个中文语气控制样本
• 10 个“信息缺失时必须明确说不知道”的样本

不需要很大，但一定要是真实任务。
这样你才能避免每次都靠“我感觉这个模型挺聪明”。

评估时别只看“像不像”，要看“会怎么错”

很多人说“模型 A 比模型 B 好”，其实说的是不同维度：

• 语言更流畅
• 更听指令
• 更快
• JSON 更稳
• 幻觉更少
• 长上下文表现更好

这些不是一回事。

一个比较靠谱的评估流程是：

1. 固定任务集

别拿猜谜题和冷知识做主样本，直接拿业务里的真实 prompt。

2. 控制变量

同一台机器、同一个 runtime、尽量同档位量化、同样的上下文设置。

3. 明确记录失败类型

例如：

• 编造配置项
• JSON 非法
• 引用不存在的函数
• 忽略系统指令
• 中文语气发硬
• 信息缺失时瞎补

4. 版本变化后重跑

本地环境升级很频繁，runtime 更新、模型换版、量化参数变化，都会影响结果。

Prompt 当然重要，但 Grounding 更重要

本地模型不是 prompt engineering 的免死金牌。

想让输出更稳定，基本原则还是这些：

• 任务描述具体一点
• 输出格式讲清楚
• 需要的话给示例
• 明确告诉它：缺信息时怎么处理
• 指令和原始材料分开

但 prompt 再清楚，也不能凭空补知识。
只要任务涉及事实、代码库、内部文档，就还是得靠 grounding：

• 检索文档或代码片段
• 限定上下文范围
• 明确提供源材料
• 对结构化输出做后验校验

这在本地模型上尤其重要，因为很多中小模型“语气很像懂了”，不代表它真的知道。

本地 LLM 的几个硬限制，要提前接受

长上下文不是白送的

就算模型宣称支持很大的上下文窗口，质量是否真能撑住，是另一回事。内存和延迟也会一起涨。

工具调用能力参差不齐

有些本地模型已经能做基本 tool use，但稳定性通常还是比不上顶级云模型，需要更多约束。

幻觉不会因为“本地”就消失

本地不等于有事实依据。
没在 prompt 里、没在知识库里、没在模型权重里，它照样可能编。

并发能力很容易被高估

一个人单机用着挺顺，不代表多人同时调用时还能保持体验。

常见遇到问题

用一次成功案例替代评估

某个 prompt 跑得漂亮，不代表这个模型稳定。

只看 benchmark 截图

benchmark 有参考价值，但远远不够指导实际选型。

一味追最大模型

如果慢到人不想等，那它就不是好工具。

不做输出校验

要给下游系统喂 JSON、SQL、配置、命令时，不校验就是等着出事。

把不同目标混着比

一个适合实时补全的快模型，和一个适合离线摘要的慢模型，不该拿同一把尺子硬比。

什么场景值得本地跑

我会推荐本地部署的情况：

• 数据敏感度确实高
• 任务边界相对清晰、可重复
• 团队愿意做最小限度的评估和验证
• 机器成本已经有，或者能说清楚 ROI
• 你需要的是“够用、可控、可内嵌”，不是“绝对最强”

我不太建议本地优先的情况：

• 一上来就要求接近顶级云模型的推理效果
• 希望廉价硬件承载高并发团队使用
• 不愿意做评估、校验和观测
• 运维负担已经超过了隐私和成本收益

最后一句

本地 LLM 现在已经不是玩具了，但也远没到“闭眼上”的程度。

更靠谱的做法是：

• 先定任务
• 再定硬件
• 有意识地选量化
• 用真实样本评估
• 对事实型任务做 grounding
• 把 runtime 当成基础设施来管

这样它会变成一个很好用的工程工具。
否则，它大概率只会变成一台很贵的 benchmark 展示机。