自研实践：本地 LLM 承担 50% AI 开发任务的分配经验

我是 Uehara，在 EarthLink Network Co., Ltd. 工作。我一个人构建并运行着 20 多个产品，Claude Code 是开发的核心。这是一份来自实际工作的现场笔记。

2026 年 7 月 30 日，在运行我们内部 AI 开发的面板上，本地 LLM 处理的工作份额达到了 50.3%，云端为 48.2%。这并不意味着我们的账单减半了。它意味着执行量（含转录）的分配大致各占一半。

（画像は別途ホスティング予定）

我在这件事上的想法与最初相比有了很大的转变。

最初，我想的是"上一套大模型就行了"

一开始我的想法很简单：在一台大内存的 DGX Spark 上加载一个 70B 级模型，让它成为一个好的指挥官。更大就意味着更聪明——这是一个朴素的假设。

在真实硬件上测量得到了相反的结果

当我实际测量时，结果是相反的。

在任务分类工作中，我在 16 个案例上对 14B、32B 和 72B 进行了比较。最终分类一致性上 14B 和 72B 是一样的；72B 只是慢了五倍。在代码生成测试中，通过率是一样的，72B 慢了六倍。除此之外，大多数失败不是因为模型有多聪明，而是因为生成的 diff 根本无法应用。

"更大的模型更好"这个说法并不成立——至少在这个用法上不成立。

我还曾在内存估算上翻过车

试图在同一台机器上同时托管 14B 和 72B，我的内存计算错了。理论上模型权重是放得下的，但一旦加上上下文，物理上就放不下了。分类停滞了四分半钟。在我缩短了分类器的上下文之后，两个模型都能驻留，停滞时间降到了大约 12 秒。不做测量只做估算直接导致了失败。

（画像は別途ホスティング予定）

不是模型排名，而是角色分工

于是我改变了思路。我不再建立模型排名，而是按角色分割任务。轻量判断交给小的本地模型；重量工作交给云端。而危险操作——数据库、认证、计费、生产——无论模型怎么说，都要回到人工审批。本地模型写的代码并不会因此就减轻审查。

这就是开头那个 50.3% 的来源。这不是本地 LLM 替代云端的故事。它是一份按角色分割工作、加以测量、并构建出可以在失败时回滚的东西的记录——以及这如何不仅帮助了成本，还帮助了速度和安全性。

接下来我要衡量的不是 token 比例，而是每个成功任务的总成本和时间。

Uehara 在 EarthLink Network Co., Ltd. 构建 AI。自 2025 年起我将 Claude Code 作为开发的中心，现在我一个人构建并运行着 20 多个产品。在这个系列中，我写下地面上实际发生的一切——成绩和失败——以及背后的数字。