同一批任务比耗时：阿里云用验收标准给 Fast 路由定级

同一句开发需求交给不同模型，一个答得快但没抓到点，一个更准但更慢。阿里云社区在 2026 年 10 月 19 日写的是 Qoder Fast 怎么选模型，而不是再发一版产品介绍。Qoder 是阿里云的 AI 编程产品。Fast 是其中偏速度的一档：开发者只选 Fast，背后的路由决定用哪一个模型。文中给出的整体结果是，首个响应从 8 秒降到 3 秒，Credits 消耗从 1.1 倍降到 0.8 倍。Credits 是 Qoder 的用量单位。这些数字来自模型、Agent 和网络三层一起改，这篇只拆模型层：用 System One 做一次任务分类，再拿分类结果去选模型。System One 只负责快速判断「这是哪一类任务」，不负责写代码。

1. 不同任务要的能力不一样

「解释这个函数为什么报错」和「理清这个模块的依赖、改完再核对结果」，都是开发任务，对模型的要求不一样。前者要尽快找到相关逻辑并讲清楚。后者要看更多上下文、估计跨文件影响，改完还要核对。理解、生成、用工具、把多步做完，会随任务变化。

就算都是改代码，加一个空输入检查，和改多个调用点还要保住原有接口，分析深度也不一样。任务目标、改动范围和交付约束，一起决定模型必须做什么。Fast 在这一档内部调整候选模型的优先级，再结合这次请求需要的能力，以及模型是否可用，决定后面怎么跑。

2. 用一次结构化判断认出当前任务

应用先规定要区分的任务类别和候选标签，模型按输入返回一个明确类别，路由再用这个结果去调度。同一段代码，用户可能问「为什么它保持原来的顺序」，也可能说「改成空输入也能用」。前者是解释，后者是修改。分类要认出用户现在要做的动作；代码和前面的对话只是上下文。

Qoder 把当前请求和最近对话分开整理，并限制做这个判断需要的信息量。System One 只做分类。真正执行的模型仍然拿到完成工作所需的全部上下文，去生成代码、调用工具、核对结果。两边读的东西差很多：评测里，一次分类的输入大约是一千个 token；复杂开发任务里，执行模型累计可能处理几十万个 token。分类器只读它需要的，完整上下文留给真正干活的模型。

类别会进入候选模型排序，再和能力要求、模型是否可用合在一起，决定后续选择。一次判断的结果直接进现有执行流程。

在一千条以上的历史任务文本上做分类评测，任务分类的平均返回延迟是几百毫秒这一量级，超过 99% 的判断在 0.5 秒内返回。这一步用的是结构化选择，不用生成长篇分类说明，也不用再解析一段自由文本，所以多出来的判断开销低。

3. 同一批任务上比质量和端到端耗时

认出任务之后，评测要回答哪一个模型更适合这类活。离线评测先比较不同模型和不同执行方式，再用结果调整每一类任务的选型优先级。线上请求到来时，那次快速判断用的就是这些已经积累的结果。

比较覆盖 20 类以上任务，包括代码实现、解释、重构、测试和架构设计。每一题上，所有模型配置用同一份输入和同一套验收标准，并且去看实际代码、文件和运行结果。文中举了三例：

去重算法优化：保持第一次出现的顺序，不改输入，并通过边界测试。

跨模块重构：原有测试继续通过，独立的行为检查结果一致，数据量变大时也要评估行为。

API 架构设计：幂等、并发和失败恢复要完整，设计文档要和场景结论一致。

速度按完整流程比：从用户发起任务，经过模型调用、工具执行、任务内验证，到最终输出完成。更早开始往外吐字，只说明首个响应更短。输出更长、工具调用更多，或者来回改了好几轮，都会把端到端任务时间拉长。

在他们自己的复杂任务对比里，同一批任务上，不同模型配置的端到端耗时可以差好几倍。拆开看，多出来的时间里超过 90% 发生在模型生成阶段；最慢配置的输出 token 数接近最快配置的三倍。工具调用的轮次和执行时间也有贡献。所以路由评测必须同时记下：任务有没有通过验收、端到端耗时、以及执行过程。

这些结果用来排每一类任务的候选模型。代码解释、测试生成和重构分开评。模型更新之后要重评，选型标准才跟得上实际表现。

4. 会话内复用选型，少做重复分类

一个 Coding Agent 任务通常要很多次模型请求：读文件、改代码、跑测试，再按结果继续。复杂任务对比里，一个任务平均超过 10 轮模型请求。如果每一轮都重新分类并换模型，分类会反复发生，已经积起来的上下文还可能要换一个模型重读。

所以 Qoder 在会话这一层复用选型：第一次需要路由时做分类，并保存候选顺序；会话缓存还有效时，后面的请求沿用这个结果。端到端验证里，第一次请它写一个函数会触发分类；同一会话里接着问这个函数为什么保持顺序，就复用已有选择，不再调分类器。

在完整任务上，这个复用更明显。复杂任务对比里，每个任务只在开头分类一次。和每轮都分类相比，分类调用减少超过 90%，累计分类延迟仍低于端到端任务时间的 1%。

这里换掉的是两类开销：反复等待分类，以及把同一份上下文再算一遍。前面说的几十万输入 token 里，多轮请求会反复带上前面轮次的上下文。会话内让模型和后端选择相对稳定，模型侧的上下文缓存才有机会复用。实际收益仍取决于缓存是否命中，以及任务怎么执行。

分类调用自己有超时。每次分类只打一次；超时之后，选型按已有打分规则继续。超时后，系统还会暂时停掉后面的分类调用，直到一次探测确认恢复。执行模型的重试和回退仍走原有规则。会话级复用、把分类开销压住、再加上超时后的退路，分类才能进 Fast 的真实执行，而不是只留在离线表里。

5. 日常任务更快，以及版本边界

解释函数、修局部错误、补测试、整理信息或工作计划，都希望尽快拿到能用的结果。路由把任务分类用到选型上，再和高速模型、客户端执行、网络优化放在一起，改的是 Fast 的交付体验。

文中把可用性写死了：Fast 覆盖 Qoder 产品家族。要用 Fast，Qoder CLI 要升到 1.1.70 或更高，QoderWake 要升到 1.1.11 或更高。个人版和企业版、中国站和国际站都有。版本不够，就还不是这篇里的那条路由。

阿里云，阿里云社区，Inside Fast's Model Layer: Matching Every Task with the Right Model，2026-10-19，https://www.alibabacloud.com/blog/inside-fasts-model-layer-matching-every-task-with-the-right-model_603649