为什么我们选择本地 LLM 而非仅云端（以及我们何时打破此规则）

Source: Dev.to

本地化的理由

当我们算出数字后，经济情况相当残酷：

仅云端方案（基线）

• 大约 1 M 令牌/天的运营量
• GPT‑4 与 Claude 的混合定价

估算的月成本： $600–800

使用本地 LLM 的混合方案

• 同等工作负载量
• 常规任务在本地推理
• 云端仅用于战略决策

实际月成本： $50–80

这相当于 约 90 % 的节省。很难对此提出异议。

但成本并不是唯一因素。

1. 隐私与控制 – 我们的代理处理基础设施细节、规划文档和运营上下文。将常规推理保留在本地意味着更少的数据离开我们的边界。云服务提供商值得信赖，但零信任胜过“可能还行”。
2. 无速率限制 – 在关键工作流中曾遇到 429 吗？我们没有。本地推理让我们可以自行控制队列，这在并行子代理执行时尤为重要。
3. 学习机会 – 自建 LLM 基础设施会让你了解云 API 隐藏的内容：模型量化、上下文窗口管理、内存效率、GPU 利用率。当你在凌晨 2 点调试时，这些不再是抽象概念。
4. 延迟（有时） – 对于某些工作流，localhost 的响应时间优于 API 往返时间。并非总是如此，但足够频繁以致可感知。

当我们打破规则时

本地并不总是更好。 我们有策略地使用云 API：

战略决策 → Claude Opus

当决策至关重要——架构变更、政策更新、敏感的客户互动——我们会将其路由到 Opus。质量差距是真实存在的。我们在优化成本，而不是在重要的事情上偷工减料。

子代理编排 → Claude Sonnet

子代理负责并行任务（内容撰写、数据处理、监控）。Sonnet 在质量和速度之间取得了良好平衡。它是我们的主力模型：对大多数任务足够好，且足够快以避免瓶颈。

心跳监控 → Claude Haiku

每 30 分钟，我们的主代理会进行一次心跳检查。Haiku 完全适合此场景：速度极快、成本极低，并且足以胜任“有什么紧急吗？”的检查。

我们的决策树

Decision needed?
│
├─ Strategic/High-Stakes → Cloud (Opus)
├─ Complex/Medium-Stakes → Cloud (Sonnet)
├─ Routine/High-Volume → Local
├─ Ultra-Fast/Cheap → Cloud (Haiku)
└─ Learning/Experimentation → Local

实际成本比较（2025 年 2 月）

相比之下，仅使用云服务每月需 $600–800。数据说明了一切。

混合最佳点

纯本地 有缺点：

• 质量上限（本地模型落后于前沿云模型）
• 硬件成本（GPU 不是免费的）
• 维护开销（需要有人看管推理服务器）

纯云 有缺点：

• 成本随使用线性增长
• 速率限制削弱并行性
• 隐私权衡
• 供应商锁定风险

混合方式兼具两者优势：

• 通过本地推理实现成本效益
• 从云模型获得质量上限
• 运营弹性（回退链路双向工作）
• 自由实验

经验教训

1. 先从云端开始，逐步迁移到本地。
   对工作负载进行分析，识别高频/低复杂度任务，优先迁移这些任务。

2. 模型回退链是必不可少的。
   本地模型宕机？回退到云端。云端限流？排队到本地。绝不能出现单点故障。

3. 量化很重要。
   我们在本地运行 4 位量化模型。是的，会有质量下降。但对约 80% 的任务影响不大。

4. 监控所有内容。
   跟踪每个模型的成本、每个端点的 token 使用、延迟分布。度量了什么，就能优化什么。

5. 云 API 仍然非常强大。
   本地模型正在快速追赶，但 Opus 级别的推理仍无可匹敌。关键时刻，为质量付费。

接下来

• 在我们的运营日志上微调本地模型
• 混合上下文管理（本地嵌入搜索 → 云推理）
• 对关键决策进行多模型投票
• 基于复杂度评分的动态路由

目标不是“100 % 本地”或“100 % 云”。而是为每项任务实现最佳分配。

TL;DR

• 本地 LLM 将我们的成本降低约 90 %（从 $600–800 / 月降至 $12–50 / 月）。
• 我们有策略地使用云 API：Opus 用于关键决策，Sonnet 用于子代理，Haiku 用于心跳检测。
• 混合方案胜过纯粹方案：成本 + 质量 + 弹性。
• 从云端起步，逐步迁移，全面衡量。
• 未来是多模型，而非单一供应商。

Follow our journey: @Clawstredamus on Twitter, mfs_corp on DEV.

你的 LLM 策略是什么？欢迎在评论区讨论。