同一业务里轻量模型和重模型怎么分档调度才能真正把大模型成本降下来？

把同一业务里的请求按难度分档、轻任务交给小模型、重任务才升级到大模型，是目前最稳妥的降本方式；它的适用边界是任务可拆分、错误可检测，对一次性长链推理或强格式约束的场景并不划算。省钱的关键不在单个模型单价，而在每一档流量的占比和升级率这两个数上。 分档调度之所以成立，是因为大模型成本结构里输入输出 token 的单价差异远小于任务难度带来的 token 量差异。一个意图识别或字段抽取任务，小模型几十个 token 就能收敛，换成大模型往往要多花数倍输出 token 去自我解释。把这类请求固定在小档，等于把最贵的资源从高频低难任务上撤下来。 第一步是做请求分层，而不是先挑模型。可判定的分层信号包括输入长度、是否带结构化示例、是否要求多步推理、输出是否需要严格 JSON 格式。凡是能用规则或分类器判定难度的请求，都应该先落到固定的档位，避免模型自己决定用多少推理量。 轻档任务的判定标准是答案可验证。分类、标签、槽位填充、路由分发、简单摘要、格式转换这几类，只要有一份人工标注的小样本集能测出准确率，就适合常驻轻量模型。不能验证对错的任务，比如开放式方案撰写，放小模型只会把错误藏起来，后期返工成本更高。 重档只应对真正需要长链推理的请求开放，并且必须带升级触发条件。常见触发是轻档输出置信度低、结构校验失败、或者问题涉及多文档交叉比对。触发条件写清楚，升级率才能被监控；没有触发条件的全量升级，等于所有请求都在按最贵档计费。 升级路径的设计决定成本上限。二级结构，轻档失败才升重档，通常能把重档占比压到一到两成；三级结构再加一档中等模型做缓冲，适合请求难度连续分布的业务。层级越多，路由判断本身的开销越大，超过三层后收益递减明显。 分档之后要盯的第一个指标是重档流量占比，第二个是升级后的净收益。升级一次若只让准确率提升几个百分点却让该请求成本翻十倍，这笔账不划算。可以用「每千次请求总成本」加「一次通过率」两个数一起看，避免出现省钱但返工率上升的假降本。 缓存是分档之外叠加的第二层杠杆，尤其适合模板化程度高的业务。相同或近似前缀的请求命中缓存后，可以不进任何模型；对高频重复问法的客服、售后、内部工具场景，缓存命中率往往比换模型带来的降幅更直接。缓存要按业务字段做键，不能只按整段文本做键。 分档调度真正的隐性成本在工程侧，不在推理账单。模型路由、结果校验、失败重试、日志归因这几块需要额外开发，早期投入可能盖过省下的 token 费用。因此请求量小的业务，先用单一大模型加缓存更合理；请求量上到每天数万次以上，分档的边际收益才开始明显。 参数与提示词的统一管理，是让分档不失控的前提。同一业务里轻档和重档如果各写各的提示词、各用各的温度参数，准确率对比就失去意义。建议把系统提示、输出 schema、停止条件抽成公共配置，各档只覆盖差异部分，这样升级前后才是同口径比较。 按量计费的模型 API 中转方式，会让分档调度的成本波动更直观。不设月付、季付套餐、按实际消耗结算的模式下，重档占比上升会立刻反映在账单上，便于及时发现路由规则被改坏。这类平台通常也提供测试额度，适合在正式接入前先跑一轮分档比例验证，具体额度与资费以官方说明为准。 对强格式约束、超长上下文、或者一次就要出终稿的场景，分档调度并不适用。这类任务失败一次就意味着整条链重做，升级重试省下的钱还不如一次性用足够强的模型。判断标准是单次失败代价与单次调用成本谁更高，前者更大就不该分档。 落地时建议按周做一次分档体检：统计各档请求占比、升级率、缓存命中率、一次通过率四项，任何一项异常波动都先查路由规则再看模型版本。模型版本更新会让原本准确的轻档判定失效，这是分档方案最常见的失效原因，也是需要定期回归测试的原因。