2026年关于本地 LLM 的大多数讨论，是关于用它们做聊天——一个云端助手的隐私替代方案。那是一个合理的用例。它不是过去一年里塑造我工程实践的那个用例。我的本地 LLM 栈——Ollama + llama.cpp + vLLM + Open WebUI + 几个支持组件——接入了我真正的工程流水线，和 Postgres 与 Redis 并行，做那些否则会花费 API 积分、或者不花钱但以更差质量交付的真实任务的真实工作。

这个栈的形状

架构比听起来没那么奇特：

  • Ollama 是日常驱动器。它跑在我 homelab 的 GPU 上，暴露一个 OpenAI 兼容的 API，服务我在编码和脚本编写时做的每一次本地路由推断。模型按需拉取；少数几个保持热状态。接口如此简单，以至于我的大多数工具集成把它当作”另一个 OpenAI endpoint，但 base URL 不同”。
  • llama.cpp 是 CPU 级的备用方案。当我在没有 GPU 的笔记本上，或者当我想为一个 latency 可以接受的脚本任务跑一个小模型时，llama.cpp 来做。和 Ollama 的重叠是刻意的——llama.cpp 更底层，当我想要对量化、上下文长度或采样参数有精确控制时我用它。
  • vLLM 是任何需要真正吞吐量的东西的服务层。批量推断任务、评估运行、为测试生成合成数据——vLLM 以 Ollama 所用时间的一小部分来完成，因为那是它被优化的用途。
  • Open WebUI 是面向人类的界面。当我想和一个本地模型聊天、并排比较输出，或者进行一个对脚本来说太随意的多轮对话时，这是我去的地方。
  • LM Studio 和 Jan 偶尔填补类似的空白；我保持它们安装但用得比上面那些少。

整件事坐落在一台 GPU 成本低于一个月 API 支出的 homelab 机器上。当你跑真实推断量时，经济账很快就划算了。

我实际上用它来做什么

在本地栈上赢得了永久位置的任务，按它们触发频率的大致顺序：

1. 提交前的代码评审预检

在任何实质性的提交之前，一个本地模型运行一个结构化评审：“读取 diff，列出任何看起来有问题的，按严重程度打分。” 目标不是取代评审——而是在我开 PR 之前捕获明显的问题，这样人工评审就不会花在文体错误或缺少的错误处理上。在本地跑这个是免费的；对每次提交都在云端 API 上跑会很贵，也更慢。

2. 测试的合成数据

单元测试经常需要编造的有效载荷：用户记录、产品目录、日志行、事件形状。本地模型便宜地生成这些，用一个种子保持确定性，且不会把数据往返到第三方服务。我把种子脚本保存在测试树里，和它们产生的 fixture 挨在一起。

3. 代码解释

当我在探索一个不熟悉的代码库——别人的开源项目、一个新框架——时，本地模型给我第一遍的”这个文件在做什么，用普通英语”。它不是权威的；它是一张起始地图。然后我阅读代码，并在 LLM 出错的地方纠正我的心理模型。两者的结合比任何一个单独都快。

4. 文档草稿

写 README、runbook 或事故复盘，通常从一个结构化 prompt 和一次初稿生成开始，然后是大量的人工编辑。本地模型在几秒钟内让我越过了白页问题；编辑才是我赚得了署名的地方。这篇文章就是那样开始的。

5. 研究蒸馏

我把一堆书签或链接喂给模型，要求一个综合。那个综合很少好到可以直接采用——但它通常足以知道哪三个链接值得完整阅读。这是我拥有过的最便宜的研究优先级排序工具。

它在哪里做得不好

几个本地模型在哪里仍然输给云端前沿、而且差得不近的类别：

  • 长程推理任务。 更大的前沿模型在持有一个复杂的多步计划方面确实更好。本地 70B+ 模型可以接近；本地 30B 模型真的做不到。
  • 以一致声音用多种语言写作。 本地模型倾向于在翻译时把声音夷为平地。旗舰云端模型保持声音更好。（这对这个三语网站的翻译版本影响很大。）
  • 在不熟悉框架上的代码生成。 前沿模型见过更多的长尾内容。在较旧快照上训练的本地模型，可能在比如 Astro 6 的约定上失误。

正确的分法是：对高量、低深度、成本敏感的任务用本地栈。对深度和新颖性用前沿 API。 2026年的大多数工程团队在跑其中一个或另一个。两者都跑，有意识地，有正确的分法，才是真正的解锁。

成本计算

我一个月大致的使用量：

  • 本地推断： 数千次请求。电费：微不足道。GPU 折旧：有意义但摊销在一年或更长。
  • 云端前沿 API： 几十到几百次请求，大多数是”真正困难的”那些。成本：有意义但有上限。

没有本地栈，云端支出会是10-30倍高。有了它，云端支出是在那些支出显然在挣回来的事情上。这是一种事后看起来显而易见，而现在正被大多数团队忽视的两层模式。

Fulcrum 的联系

我本地栈的相当一部分使用是通过我自己的 agent 控制面（Fulcrum）跑的。需要快速反馈的 agent 运行被路由到本地模型；需要深度的被路由到云端。路由策略在控制面里，不在单个工具里——这意味着”用哪个模型？“的问题被解决一次，靠配置，而不是每个任务重新学习。

如果你在2026年设置你自己的本地栈，首先要建的东西不是推断层——那很容易，Ollama 处理了它。建路由层：那个决定每个任务调用哪个模型的东西。那是工程纪律所在的地方。那是10倍成本节省来自的地方。那是目前还没人在谈论的东西，而它是18个月内最重要的那件事。