多模型分层调度：从单点性能到任务编排的工程实践

过去两年，模型发布的主旋律是“单点更强”：参数更大、榜单更高、上下文更长。但当模型开始被真正嵌入研发流程与业务系统之后，一个问题迅速浮出水面——绝大多数任务并不需要最强模型，而最强模型的成本与延迟又无法支撑高频调用。于是，行业的产品形态正在从“发布一个模型”转向“发布一组能力档位”，并配套一整套调度机制。本文不讨论某一家厂商的具体产品，而是把这套现象抽象为可复用的工程方法：如何做模型分层、如何设计路由、如何编排长任务。

一、分层发布的本质：把“选模型”变成“调度模型”

当一组模型同时以“旗舰 / 平衡 / 轻量”三档出现时，它传递的核心信号并不是价格表，而是一种使用范式：

• 旗舰档：面向复杂推理、长链路编程、智能体（Agent）任务、知识工作与安全分析等场景，追求的是“一次做对”的成功率；
• 平衡档：面向日常开发任务，能力接近上一代旗舰，成本显著下降，是大多数生产流量的默认落点；
• 轻量档：面向高频、短请求、可容忍一定能力折损的任务，例如格式化、分类、抽取、简单改写、日志摘要。

这种分层的价值在于，它把原本模糊的“要不要用大模型”变成了明确的工程决策：任务分级 → 模型分档 → 成本可控。一个团队如果所有请求都打到旗舰档，通常会出现两个后果：预算快速耗尽，以及高频任务的排队延迟上升；反之，如果全部用轻量档，复杂任务的成功率会塌陷，返工成本反而更高。

因此，分层不是“多卖几个型号”，而是要求使用者建立一套任务-模型映射表。这张表才是分层发布真正的交付物。

二、成本结构决定路由策略

在工程实践中，模型选型几乎总是三元权衡：质量、延迟、成本。分层发布把这三个维度显式化了。假设三档模型的定价呈阶梯关系（旗舰最贵、平衡居中、轻量最低），并普遍提供缓存读取折扣，那么最优策略通常不是“选一个”，而是“按流量特征分流”。

一个可落地的判断框架如下：

任务特征	建议档位	理由
多步推理、跨文件重构、长链路 Agent	旗舰	失败重试的代价远高于单次调用成本
日常功能开发、单测补全、常规问答	平衡	能力够用，成本可控，延迟可接受
分类、抽取、格式化、短文本改写	轻量	高频调用，单位成本敏感
重复性高、上下文稳定的请求	任意档 + 缓存	缓存折扣可显著摊薄成本

这里需要强调一个常被忽略的点：成本不应按单次调用计算，而应按“完成任务的总成本”计算。旗舰模型单次更贵，但如果它把输出 token 数和耗时都压到一半左右，并且减少了下游返工与人工介入，那么总成本可能反而更低。反过来，轻量模型如果导致任务失败率上升，重试与排障的隐性成本会迅速吃掉价差。

一个简化的成本估算函数可以写成：

def task_cost(tokens_in, tokens_out, price_in, price_out,
              retry_rate=0.0, cache_hit_rate=0.0):
    # 缓存命中部分按折扣计价，此处以 10% 价格示意
    effective_in = tokens_in * ((1 - cache_hit_rate) + cache_hit_rate * 0.1)
    per_attempt = effective_in * price_in + tokens_out * price_out
    # 期望成本 = 单次成本 / 成功率
    success_rate = max(1e-6, 1 - retry_rate)
    return per_attempt / success_rate

这个函数的意义在于提醒团队：成功率是成本公式里的分母。把复杂任务强行压到低档模型上，等于用一个很小的分母放大成本。

三、工具输出预处理：被低估的降本环节

分层调度之外，原文提到的“工具输出先处理”是一条非常务实的工程经验。在 Agent 与编程助手场景中，上下文膨胀的主要来源往往不是用户输入，而是工具返回：文件内容、命令输出、检索结果、日志片段。这些内容直接塞进模型，会带来三个问题：token 成本上升、关键信息被稀释、长上下文下的注意力衰减。

推荐的处理顺序是：

1. 裁剪：只保留与当前子目标相关的片段，按行号或符号范围截取；
2. 结构化：把自由文本转为结构化摘要，例如“文件路径 + 变更函数 + 关键行”；
3. 去重：合并重复的报错、重复的检索片段；
4. 缓存：对稳定不变的上下文（如项目规范、接口定义）启用缓存，命中折扣直接体现在账单上。

这一步做得好的团队，往往能在不换模型的前提下把 token 消耗降低一个可观的比例。它的收益是确定性的，且不依赖任何特定厂商能力。

四、长任务编排：多智能体不是银弹，而是分治手段

“长任务再开 multi-agent”这句话容易被误读为“所有任务都上多智能体”。实际上，多智能体架构的适用条件相当严格：

• 任务可以被清晰拆分为可验证的子目标；
• 子目标之间存在明确的依赖关系，可以串行或有限并行；
• 每个子目标都有可检查的产物（代码、测试结果、文档片段），而不是纯开放式创作。

满足这些条件时，多智能体的收益主要来自两点：一是把长上下文拆成多个短上下文，降低单次调用的推理负担；二是让不同子任务使用不同档位的模型，例如规划用旗舰、执行用平衡、校验用轻量。

一个典型的长任务编排骨架如下：

def run_long_task(goal, planner, executor, verifier, budget):
    plan = planner(goal)                 # 旗舰档：拆解与规划
    artifacts = []
    for step in plan.steps:
        if budget.exhausted():
            break
        out = executor(step, context=artifacts)   # 平衡档：执行
        check = verifier(step, out)               # 轻量档：校验
        if not check.passed:
            out = executor(step, context=artifacts, retry=True)
        artifacts.append(out)
    return synthesize(goal, artifacts)

需要注意的工程约束包括：预算上限（避免长任务无限消耗）、中间产物持久化（失败可恢复）、幂等与可重放（便于定位问题）、人工检查点（高风险动作前必须确认）。没有这些约束的多智能体系统，往往在演示阶段惊艳，在生产阶段失控。

五、评估体系：榜单之外看什么

公开榜单能反映能力上限，但生产环境更关心另一组指标：

• 任务成功率：端到端完成率，而非单步正确率；
• 单位任务成本：包含重试与人工介入；
• P95 延迟：高频场景下比平均值更有意义；
• 输出 token 效率：同等质量下更短的输出意味着更低成本与更快响应；
• 稳定性：同一输入多次调用的一致性。

建议在内部建立一套小规模、贴近真实业务的评测集，按任务类型分桶，并定期用新档位模型回归。这样做的目的是把“要不要升级到旗舰档”从直觉判断变成数据判断。

六、落地建议清单

1. 先做任务盘点：把线上请求按类型、频率、失败代价分桶，形成任务-档位映射表；
2. 默认走平衡档：旗舰档用于明确的高价值复杂任务，轻量档用于明确的高频简单任务；
3. 统一网关做路由：把模型选择、缓存、重试、限流、计费统计收敛到同一层，避免业务代码散落选型逻辑；
4. 工具输出必预处理：裁剪、结构化、去重、缓存四步走；
5. 长任务加预算与检查点：没有预算控制的多智能体不要上生产；
6. 建立内部评测集：按任务分桶，定期回归，用数据驱动档位调整；
7. 可观测性先行：记录每次调用的档位、token、耗时、结果状态，否则成本优化无从谈起。

结语

多模型分层发布的真正意义，是把“模型能力”转化为“调度能力”。旗舰档负责突破上限，平衡档承接主力流量，轻量档消化高频请求；工具输出预处理压缩上下文，长任务编排分治复杂度，统一的网关与评测体系保证过程可控。对开发者和企业而言，这套方法的门槛不在模型本身，而在工程治理：你是否清楚地知道自己的任务长什么样，以及愿意为每一次调用付多少钱、等多久、承担多大失败风险。回答好这三个问题，分层才有意义。