同一业务内怎么用轻量模型和重模型分档调度，把大模型调用成本降下来？

大模型降成本的可行路径是同一业务内做轻量与重模型的分档调度，把必须由重模型完成的请求留给重模型，其余按复杂度下沉到轻量模型，前提是业务能定义质量下限并允许失败回退；整条链路要求同一模型行为完全一致的场景不适合分档。 模型账单的成本结构由输入 token、输出 token 和调用次数共同决定，其中输出 token 通常是波动最大的一项。同一段提示词的输入长度基本稳定，输出长度却随模型发挥浮动，长输出既抬高单价又拖长耗时，还可能触发更多轮次。做法是把输出长度写进调用参数，并让业务侧明确每次任务需要多少字，超出的部分截断或改写。 给请求分档的前提是先有无歧义的请求标签，而不是凭模型名猜。标签维度至少包括意图复杂度、上下文长度、是否多步推理、是否要求结构化输出、是否可自动校验。做法是先在网关埋点采集真实请求分布，用一段时间的样本统计各维度占比，再决定阈值；没有埋点就直接切流的团队，分档比例一旦设错，质量下滑和成本反弹会同时出现。 前置分类器应该由轻量模型或规则承担，而不是让重模型自己判断该不该被调用。如果每个请求先发给重模型再决定路由，成本已经产生，分档失去意义。做法是用关键词、正则、业务字段做第一层规则，覆盖高频且意图明确的请求；剩余长尾交给小模型分类，并对其结果做缓存。 意图明确、答案空间有限、可自动校验的任务适合下沉到轻量模型，包括意图分类、字段抽取、短文本改写、简单问答、格式转换。多步推理、长文档理解、代码生成、需要严格遵循多条约束的输出，应直接留在重模型上。试图用提示词把轻量模型逼到同等水平，通常以反复重试收场，单次任务成本反而更高。 分档能否省钱，取决于升级率而不是降级率。轻量模型处理失败后回退到重模型的比例越高，节省下来的单价差越容易被重试和重复输入吃掉。做法是给轻量输出设置信度阈值与规则校验器，只让通过校验的结果直接返回，其余升级；同时把升级率当作核心指标监控，超过预期就回头调整标签阈值，而不是继续硬压降级比例。 调度粒度应放在会话或任务上，而不是每一次调用上。同一会话前几轮已由重模型建立的上下文，如果中间几轮降级到轻量模型，容易产生风格与事实不一致，用户追问后又要重算。做法是以任务为单位锁定模型档位，一旦升级就在剩余轮次沿用同一档，直到任务结束。 缓存是分档之外的第二根成本杠杆，命中率决定分档的边际收益。相同系统提示词与业务前缀的请求可以复用前缀缓存，结构化抽取结果、翻译结果、常见问答可以整体缓存。做法是把提示词拆成稳定前缀与可变后缀，稳定部分尽量不随请求变化，缓存才有生效空间。 算分档的账要看单次业务任务完成成本，而不是每百万 token 的单价。完成成本等于各档请求占比乘以对应单价，加上重试带来的重复输入输出，再加上人工兜底与客服成本。只看单价会得出轻量模型全面更省的结论，但一旦升级率居高不下，总账可能比不分档更贵。 分档会带来一套固定的工程与评测开销，请求量不足以摊薄时并不划算。需要维护两套提示词、两套评测集、回归测试与灰度流程，还要持续跟踪升级率与坏例。可行做法是先用影子流量对比分档前后的输出，确认质量落在可接受区间后再放量。 最常见的失败是把重模型当无条件兜底，或者只按价格挑模型。前者让分档沦为多一次调用，后者忽略任务完成率，用户重问一次的成本高于省下的差价。可行的落地顺序是先按任务类型固化档位，再按升级率与完成成本两个指标定期复盘，逐步收紧或放宽阈值。