Intelligence Efficiency: 路由推理,而不只是路由模型

在为 Interaction 搭建 Lite 与 Pro 两条模型路径时,我们反复观察到一个反直觉的结果:更大的模型、更长的推理预算,并不自动带来更高的任务效率。真正决定效率的,往往不是“用哪个模型”,而是“这一步到底要不要推理”。

什么是 intelligence efficiency

我们用 intelligence efficiency(智能效率)描述一个很务实的系统问题:面对同一类用户任务,产品如何用更少的 token、更短的等待和更低的成本,交付足够可靠的结果。

直觉的答案是“上更强的模型”。但更强的模型既贵又慢——而且正如下面的实测所示,在很多结构化任务上,它并不比小模型更准。系统真正需要路由的,常常不是模型,而是推理本身。

实验设置

我们通过 DeepSeek 的 OpenAI 兼容 API,跑了一组小而可复跑的确定性基准:8 个任务,覆盖计算、抽取、逻辑判断、代码执行理解、迁移规划、指令过滤、长上下文矛盾识别与 JSON 修复。每个任务都有唯一可判定的正确答案,自动评分,同时记录返回的 token 用量、延迟、finish reason,以及按用量估算的成本。输出上限固定为 max_tokens = 1024。

在 deepseek-v4-flash 与 deepseek-v4-pro 两个模型上,我们各跑两种配置:默认开启 thinking,和显式关闭 thinking。除此之外,提示词、任务与评分完全一致。

结果

结果很直接。

默认 thinking 下,flash 通过 5/8、平均分 0.812,pro 通过 6/8、平均分 0.833;pro 每个通过任务的成本(457.6 微美元)是 flash(149.9)的三倍多。Pro 质量略高,效率却明显更低。

显式关闭 thinking 后,两个模型都通过 6/8,平均分同为 0.896;每个通过任务的成本分别降到 31.5 与 99.8 微美元——比默认配置低了约 4 到 4.6 倍。在这组结构化任务上,精简执行同时提升了质量、压低了成本,而 flash 仍保持大约 3 倍于 pro 的成本效率。

机制:推理预算把答案挤出了窗口

最有解释力的是迁移规划(planning)这道题。默认 thinking 下,flash 和 pro 都把 1024 个输出 token 全部消耗在推理上,finish reason 为 length,最终返回的正文为空——得分 0。关闭 thinking 后,同一道题直接返回了正确的 JSON。失败的原因不是模型不会做,而是推理预算在有限的输出窗口里挤掉了最终答案。

但关闭 thinking 并不是对每道题都更好。同一批测试里,逻辑判断题反而回落:两个模型都从满分 1.0 降到 0.5,选错了赢家。净效果是两者都停在 6/8——关闭 thinking 修好了 planning,却弄坏了 logic。这恰恰说明,thinking 不是一个“越多越好”的旋钮,而是一个应当按任务类型开合的选择。

对 Lite 与 Pro 的重新定义

这改变了我们对产品分层的理解。Lite 不该被当成“低智商版本”,而应是更高效率的默认执行层:面对抽取、格式化、规则过滤、简单代码理解这类任务,它应该快、便宜、足够好。

Pro 也不只是“更贵模型的入口”。它应当服务于高不确定性、长链路、需要更深思考才有边际收益的任务——而不是对每一步都默认加上推理。

结论

因此,一个路由系统不能只问“用 flash 还是 pro”。它至少要同时回答三个问题:这一步需要推理吗?需要更强的模型吗?值得多花 token 吗?把这三个变量拆开,系统才可能在质量、成本与延迟之间找到真正的 Pareto frontier。

我们的结论是:智能效率来自“路由推理”,而不只是“路由模型”。一个好的 AI 产品系统不会永远调用最强的模型,而是知道——什么时候智能应该便宜、快速、够用,什么时候更深的推理才真正值得付费。

Intelligence efficiency comes from routing reasoning, not just routing models.

局限

这是一组小规模、确定性、可自动判分的任务,刻意用来隔离“推理开关”这一个变量;它不是人类偏好评测,也不覆盖开放式写作或多轮智能体任务。绝对数值会随模型版本、定价与提示词变化。真正值得记住的不是某个具体数字,而是这个形状:在结构化任务上,精简执行往往落在质量与成本更优的那个点上。