🔬 Token 经济学：用便宜的 Token 替代贵的 Token，到底行不行？

最近一直在思考一个问题：LLM 的 token 是有质量分层的。Opus 4.6 输出的是"高质量 token"，本地跑的开源模型输出的是"低质量 token"。那能不能通过多 agent 协作、多次采样，用数量换质量？
研究了一圈文献，结论是：有条件地可以，但有硬天花板。
⸻
📈 好消息：小模型确实能超越大模型
Snell et al.（ICLR 2025）发现，在 FLOP 匹配的评估中，小模型通过增加 test-time compute 可以超越参数量大 14 倍的模型。另一篇 ICLR 2025 的论文显示，Llemma-7B 配合 tree search，在 MATH benchmark 上始终优于 Llemma-34B。
关键条件：模型对目标任务得有非零的成功率，而且你得有一个靠谱的 verifier。
⸻
🚫 硬天花板：No Free Lunch
Chen & Pan（2025）给出了理论证明：无论怎么 scaling 弱模型的推理计算，都无法匹配一个足够强模型的单次采样精度。
直觉解释：如果正确答案根本不在弱模型的输出分布里，采样一万次也不会出现。你只能从模型能想到的答案里选，选不出它想不到的东西。
⸻
📉 多来几次不一定有用
Chen et al.（NeurIPS 2024）研究了多次 LLM 调用 + 投票的 scaling 特性，发现了反直觉的结论：性能先升后降。
原因：对"简单"问题，多投票确实提升准确率；但对"困难"问题（单次正确率 < 50%），投更多票反而让错误答案更确定地胜出。
多 Agent 辩论（MAD）也没那么神：ICLR 2025 的研究发现，大多数 MAD 框架甚至不如简单的 Chain-of-Thought，还有"从众效应"——弱模型引入辩论会拖累强模型表现。
⸻
💡 那什么才真正有效？
不是替代，而是分流。用大量低质量 token 处理 80% 的工作量，只在关键路径上使用高质量 token。
具体来说有几种机制：
① Best-of-N + 测试驱动 — 生成 N 个方案，跑测试选最好的。代码任务最适合，因为编译器和测试用例就是完美 verifier。
② 迭代修正 — 生成 → 测试 → 把错误喂回模型 → 修复 → 再测。比盲目重试聪明得多。
③ 分阶段验证 — Planner → Critic → Coder → Reviewer → Tester，每一步都有质量关卡。用户感觉一次出结果，内部已经循环好几轮了。
④ 难度路由 — 用轻量 classifier（~10ms）自动判断每个请求的难度，简单的给便宜模型，复杂的给强模型。
⸻
🛠 开源路由框架
RouteLLM（LMSYS）— 减少 85%+ 成本，保持 95% GPT-4 质量，OpenAI client drop-in replacement
NadirClaw — 为 coding agent 设计的透明代理，原生支持 OpenCode/Claude Code，实测省 40-70%
LLMRouter（UIUC）— 16+ 种路由模型，最全面的研究框架
vLLM Semantic Router（Red Hat）— Rust 实现，延迟降 47%，token 降 48.5%
⸻
🎯 一个被低估的发现：Scaffolding 效应
SWE-bench 上，Augment、Cursor、Claude Code 都跑同一个 Opus 4.5，但解题数差了 17 个（共 731 题）。同模型不同框架，结果差异显著。
好的 agent 框架 = 零 token 成本的 quality booster。精细的 system prompt、context 隔离、checkpoint 机制——这些优化不消耗任何额外 token，但能显著提升输出质量。
⸻
📌 五条结论

不存在"无限廉价 token 替代昂贵 token"的一般定理。弱模型正确率 < 50% 时，量变不会带来质变。
但 test-time compute scaling 确实有效——前提是有非零成功率 + 可靠 verifier。满足条件时 7B 可以打 34B。
最优策略是分流而非替代：80% 走便宜路径 + 20% 走关键路径。
代码是最佳应用场景（完美 verifier），翻译/写作等需要人类判断的任务天花板更低。
Scaffolding 被严重低估——同模型换框架就能提升数个百分点，这是免费的午餐。