为什么 3B 模型，跑产线比 70B 大模型更快？
上周发生了三件事，放在一起看比单独看有意思。
做 AI IDE 的 Cursor 被收购了。最强闭源模型 Fable 5 被加了出口管制。同一周，Cohere 发布了一个叫 North Mini Code 的开源编码模型——30B 总参数，只激活 3B，Apache 2.0 许可证，一张 H100 就能跑。
前两件事的方向是收束：最火的 AI 编程工具进了大公司手里，最强模型的使用权收缩了。North Mini Code 反着走：开源、轻量、一张消费级设备就能部署。但它的重点不在"又多了一个开源模型"——在它选的设计参数，暴露了 coding agent 场景下一直被搞错的评估逻辑。
3B 激活，不是为了省钱
North Mini Code 是 MoE 架构：30B 总参数，每次推理只激活 3B。第一反应是"省算力，便宜"。但如果是纯省钱，为什么不直接训一个 3B 稠密模型？
MoE 在训练时见过 30B 参数的知识分布，推理时根据输入路由到最相关的 3B 专家子网络——它"知道"的东西接近 30B 模型，但推理开销接近 3B。这才是真实的产品决策：让推理变快，不是让训练变便宜。
Coding agent 的工作流程不是"发一个问题，等一个答案"。它是读文件 → 理解上下文 → 生成代码 → 跑测试 → 读报错 → 改代码 → 再跑测试，循环往复。每一步都在等模型输出 token。如果每次输出都要 30B+ 稠密模型逐 token 生成，这个循环的总耗时会被输出速度卡死。
Cohere 的测试数据：输出吞吐是 Devstral Small 2 的 2.8 倍（同并发、同硬件配置），inter-token 延迟低 30%。换算成工作场景：同一张 GPU，同一个仓库，一小时能完成的有效 debug 循环接近 3 倍。
<!-- diagram:throughput-vs-accuracy -->
排队深度，才是真瓶颈
单 agent 场景下，2.8 倍吞吐只是"快"；多 agent 并发下，是"能跑"和"跑不动"的区别。
打个比方。一个收银台，收银员每分钟结 10 个客人。5 个人排队，每人等 30 秒——这是慢。换一个每分钟结 28 个的收银员，5 个人每人等 11 秒——这是快。但如果排队的是 50 个人，第一个收银员那边队伍越排越长，排在最后的人永远等不到——这不是慢，这是卡的。
GPU 上的 agent 请求同理。单张 H100 同时跑3个 coding agent，每个在各自仓库里做"读-写-测-改"循环。输出慢的模型，agent 之间互相阻塞——一个 agent 卡在等模型返回代码建议，另外两个也在排队等 GPU 空闲。
排队深度和输出速度不是线性关系——是排队论里经典的利用率曲线：GPU 利用率接近饱和时，延迟指数级爆炸。输出快 2.8 倍的模型，同等并发下排队延迟差距是平方级的。
3B 激活不是一个省钱方案——它是一个并发架构选择。
选型坐标该换了
选 coding 模型的主流方式是看 benchmark：SWE-bench 多少分，HumanEval 排第几。
这个逻辑暗含一个假设：模型的使用场景是一次回答一个问题，答完就结束。 但 coding agent 是一次启动、持续运行、多轮交互的生产线。生产线上，总产出取决于整个工位的协同，不取决于某一个人单次的发挥。
把选型指标从"单次得分"换成"单位算力产能"，需要同时看三个变量：
| 变量 | 衡量什么 | 怎么看 |
|---|---|---|
| 输出吞吐 | 每秒生成多少 token | tokens/s，直接影响排队深度和循环速度 |
| 延迟曲线 | 高并发下会不会恶化 | 并发翻倍后，TTFT 和 inter-token latency 怎么变 |
| 可部署性 | 能跑多少并发 | 最低硬件要求、显存占用、同卡并发上限 |
三个变量的乘积，才是一个模型在 agent 工作流里的真实产能。单次得分低几个百分点，但同卡并发数高 3 倍，单位 GPU 有效产出反超。
谁该动，谁不用动
需要重新算账的：正在用或打算用 coding agent 做日常开发的团队。如果你的选型逻辑还是"找 SWE-bench 最高的模型加最强 GPU 跑"，你的单位算力产能大概率被低估了——你可能用着一台跑一个 agent 的 A100，隔壁 3B MoE 在 H100 上跑了 5 个。
可以继续观望的：只用单轮代码补全、不做 agent loop 的场景。Copilot 式的"我写一行它补一行"不涉及多轮循环和并发，单次质量仍然是主导变量。
该立刻试的：已经被 agent 排队折磨过的开发者。North Mini Code 在 Hugging Face 上提供了 bf16、fp8、w4a16 三个版本，OpenRouter 上也能直接调用。挑 fp8 版，单张 H100 用 vLLM 部署，并发 3-5 个 agent 观察吞吐和排队变化——这组数字比任何 benchmark 更能回答"选哪个模型"。
过去选编码模型，像选一个聪明的员工——招 benchmark 分数最高的。现在 coding agent 跑的是一条产线，总产量取决于最慢的那个工位。一个单次准确率低几个点的模型，同卡产出高 3 倍——哪个是"更好的模型"？
答案取决于你问的是单次考试成绩，还是产线总产量。但至少从这周开始，"单次得分"不再是唯一的问题了。
