小模型 vs 大模型：4B 参数能做什么不能做什么

跑本地模型省钱，这个想法很自然。云端 API 按 token 计费，一个多 agent 系统每天烧的钱不少。如果能用一张消费级显卡跑个开源模型，成本直接归零——听起来很美好。

我试过了。结论是：4B 参数的模型在多 agent 场景下，基本不可用。

起点：vLLM + 4B 模型

最初的方案是用 vLLM 在本地部署一个 4B 参数的开源模型，作为多 agent 系统的推理后端。选 4B 是因为显存限制——单卡要跑得起来，参数量不能太大。

部署本身很顺利，模型加载、API 启动都没问题。问题出在真正开始跑 agent 的时候。

第一个坑：System Prompt 太大

多 agent 系统里，每个 agent 都有自己的角色定义、工具列表、行为规范。这些全部写在 system prompt 里，加起来大约 14KB。

14KB 对大模型来说不算什么，但对 4B 模型来说是致命的。模型的有效 context window 很短，一个巨大的 system prompt 直接把可用空间挤没了。实际表现就是：模型输出完全混乱，tool calling 格式错误，甚至连基本的 JSON 都生成不对。

为了解决这个问题，我写了一个 strip plugin，专门压缩 system prompt。把冗余描述删掉，把格式化的工具定义压缩成最简形式，最终从 14KB 压到了大约 2KB。

压缩之后，tool calling 终于能正常工作了——至少在单轮对话里能用。

第二个坑：多轮对话崩溃

单轮能用和多轮能用完全是两回事。

在多 agent 系统里，一个 agent 可能要连续执行好几步：先调用搜索工具，根据结果调用代码工具，再把结果格式化返回。这需要模型在多轮对话中保持角色一致性和工具调用的时序正确。

4B 模型在这里彻底暴露了能力上限：

• 角色遗忘：对话超过几轮后，agent 开始忘记自己的角色，QA agent 突然开始写代码，PM agent 开始跑测试
• 时序混乱：应该先查询再操作的流程，模型会跳过查询直接操作，或者重复调用同一个工具
• 格式退化：随着对话变长，tool calling 的 JSON 格式开始出错，参数丢失或类型错误

这些问题在压缩 system prompt 之后依然存在。根本原因是模型的推理能力不够，context 变长之后，它无法同时追踪角色定义、对话历史和工具状态。

切换到云端大模型

最终切到了云端的 Sonnet 模型。稳定性提升非常明显——同样的多 agent 任务，之前 4B 模型经常跑到一半崩掉，换成 Sonnet 之后可以连续完成整个流程，角色一致、工具调用正确、输出格式稳定。

代价当然是成本上去了。但考虑到 4B 模型跑出来的结果基本不能用，"免费但不能用"和"付费但好用"之间的选择其实很容易。

教训

这次尝试之后，我对小模型的定位更清晰了：

适合 4B 模型的场景：

• 单轮、结构化的简单任务（分类、提取、格式转换）
• System prompt 很短，输入输出都简单
• 对错误有容忍度，可以重试

不适合 4B 模型的场景：

• 需要长 context 的多轮对话
• 多工具协调，有时序依赖
• 角色扮演类的 agent 系统
• 对输出格式有严格要求（JSON schema 等）

给想省钱跑本地模型的人

如果你在考虑用本地小模型替代云端 API，几个实际建议：

1. 先明确你的任务复杂度。如果只是做文本分类或简单提取，本地小模型完全够用，省钱有意义。如果是 agent 系统，省下来的钱会被调试时间吃掉。

2. System prompt 的大小是关键指标。如果你的 system prompt 超过 2KB，小模型大概率撑不住。在选型之前先量一下这个数字。

3. 测试要用真实场景。小模型在 benchmark 上的分数可能看起来不错，但 benchmark 通常是单轮、短 context 的。用你的真实 prompt 和真实对话长度去测，结果可能完全不同。

4. 混合方案值得考虑。简单任务走本地小模型，复杂任务走云端大模型。需要写路由逻辑，但长期来看是成本和效果的平衡点。

模型参数量和实际可用性之间的关系，比 benchmark 排行榜暗示的要陡峭得多。在真实的工程场景里，"差一点"往往意味着"完全不能用"。