推理成本下降之后：模型路由、KV Cache 与端侧推理

上个月一个团队拿着账单来找我，说模型单价降了，费用却涨了三倍。我让他们把最近一周的调用链导出来看，问题很快清楚了：一个客服 Agent 平均每个任务调用模型十几次，每次都带着完整的历史对话和工具输出，还有大量重试。单价确实降了，但 token 用量涨得更快。

这件事提醒我，讨论推理成本时，盯“每百万 token 多少钱”很容易看错方向。真正该看的是：完成一件任务，总共花了多少。

先把成本拆开

一次模型调用，钱主要花在几个地方。

输入侧是 prefill，上下文越长，计算越多；输出侧是 decode，生成越久，成本越高；中间还有 KV Cache 的存储和调度，尤其是长会话和高并发；再加上重试、超时和失败调用，这些在账单上不太显眼，但加起来很可观。

Agent 把这些放大了。普通问答是一次调用，Agent 可能是十次；每次调用都带上下文，前一步的工具输出又变成下一步的输入。你以为只多了一个步骤，账单上可能是翻倍。

所以我现在的成本指标只有一个：

cost_per_successful_task = 总推理成本 / 成功完成任务数

这个数字不漂亮，但它会逼你同时看质量、重试和上下文效率。单看 token 单价，很容易得出“换便宜模型”这种过于简单的结论。

路由不是选最便宜的模型

模型路由的思路不复杂：简单任务交给小模型，复杂任务交给大模型。难的是怎么判断“简单”和“复杂”。

我见过两种极端。一种是全部用最贵的模型，省事，但成本失控；另一种是全部路由到小模型，账单好看，投诉也变多。

比较稳的做法是先定质量底线。每个任务类型都有必须达到的成功率和格式正确率，低于底线就不允许进入低价池。然后再做级联：小模型先答，置信度低或者校验失败，再升级到大模型。

级联的代价是延迟可能增加，所以适合对成本敏感、对延迟没那么敏感的场景。反过来，如果用户就在等，并行调用大小模型再选一个更好的，可能更合适。

还有一个容易被忽略的点：会话粘性。多轮对话里，如果每一轮都随机路由到不同模型，回答风格会跳，用户能明显感觉到。路由要尽量让同一会话落在同一个模型上。

选模型还要看上下文窗口和工具调用能力。一个便宜但窗口很小的模型，遇到长文档就得截断，答案质量反而更差；一个不支持结构化输出的模型，会在解析上浪费大量重试。单价只是成本的一部分，能力边界也是。

KV Cache 最怕前缀不稳定

KV Cache 是这两年被提得很多的优化手段。简单说，就是把历史 token 的计算结果缓存起来，避免重复计算。它同时影响延迟、显存和成本。

但很多团队用了之后发现效果一般，原因通常出在前缀不一致。

前缀缓存要命中，请求的开头必须尽量一致。如果你在系统 Prompt 里每次都插入当前时间、随机 ID 或者用户昵称，缓存就很难命中。工具定义、固定知识、系统规则这些稳定内容应该放在前面，变化的内容放后面。

我见过一个团队，为了“让模型知道现在几点”，在系统 Prompt 第一行加了精确到秒的时间戳。结果缓存命中率接近零，延迟和成本都上去了。后来把时间戳挪到最后，只在需要时传入，情况立刻好转。

多租户场景还要注意隔离。缓存键不能只按内容哈希，必须带上租户和权限范围，否则可能把别的租户的上下文捞出来。

端侧有它的位置，但不是万能药

端侧推理这两年又热了起来。原因很现实：有些场景不能等网络，有些数据不能出设备，有些任务用一个小模型就够了。

它适合什么？输入法、语音唤醒、实时翻译、文档预处理、敏感数据的初步分类。这些任务通常边界清楚、对延迟敏感、对模型能力要求没那么高。

但它不适合什么？需要复杂推理、长上下文、多工具协作的任务。把大模型硬塞到端上，量化、剪枝、蒸馏一套做完，效果可能还是不够，功耗和发热反而成了新问题。

我更看好端云协同：端侧负责唤醒、分类、抽取和草稿，云端负责复杂推理和工具调用。分工清楚，比“全部端侧”现实得多。

还有一个经常被忽略的成本是并发。同样的请求量，集中在一个时间段打进来，和均匀分布，成本可能差很多。批处理能提高 GPU 利用率，但会增加排队时间；弹性伸缩能吸收峰值，但冷启动有代价。路由策略要和调度策略一起看，不能只算单次调用的账。

我会先做哪三件事

如果让我接手一个成本失控的 AI 应用，我不会先换模型。我会先做三件事。

第一，按任务打标签，算清楚每个任务类型的调用次数、token、成本和成功率。通常 10% 的请求贡献了大部分成本，找到它们比全局优化有效。

第二，设预算。按租户、会话和任务设 token 或金额上限，超了就降级、截断或者转人工。没有上限的系统，一定会被长尾拖垮。

第三，优化上下文和缓存。压缩重复内容，稳定前缀，减少不必要的工具输出，把重试限制在幂等操作上。这些改动不性感，但往往比换模型省得多。

一笔账单的拆解

拿一个典型的客服 Agent 举例。每个任务平均调用模型 10 次，每次输入 6000 token、输出 400 token，其中七成请求没有命中前缀缓存，另有一成半因为格式错误或工具超时重试。

粗算下来，真正用于“回答问题”的 token 可能不到一半，其余都花在重复的历史对话、完整的工具返回和重试上。

优化前后我们做了三件事：把系统提示和工具定义固定成稳定前缀，缓存命中率从三成提到七成；把工具返回从整段 JSON 改成关键字段摘要，单次输入少了将近一半；给重试加幂等键和上限，失败调用降了一个数量级。

单价没变，账单降了六成多。

这些数字因业务而异，但方向是通用的：先看 token 花在哪，再决定是换模型、改缓存还是压上下文。直接换一个便宜模型，通常只是把成本问题变成质量问题。

还有一个细节：输出长度也要管。很多任务不需要长篇大论，给模型一个明确的字数或结构约束，decode 成本会明显下降，用户读起来也更轻松。

路由的离线评估

路由策略不能拍脑袋定。我会先把真实请求脱敏后存下来，按任务类型分组，然后用不同模型回放，记录每个模型的质量、成本和延迟。

把结果画成一条曲线：横轴是成本，纵轴是质量。大部分任务会在某个点之后收益递减，那个点就是质量底线。低于底线的模型不进路由池，高于底线的按成本排序。

还要看方差。有些模型平均分不错，但失败得很随机；这种模型放在关键路径上很危险。稳定比偶尔惊艳更重要。

回到账单

推理成本下降是好事，但它会带来更多用量、更长上下文和更复杂的 Agent。单位价格下降，总账单上升，这可能会变成常态。

我现在看一个 AI 产品，会先问它的成本是按什么算的。如果还是按 token 单价算，大概率还没真正进入工程阶段。