墙钟拆成依赖图：阿里云用完成率和返工给 Fast 档验收

首包从 8 秒收到 3 秒，只说明 Fast 档对外的结果。阿里云社区在 2026 年 10 月 16 日写的是，Qoder 怎么把一次任务的墙钟时间拆开，再决定哪些改动算优化。Qoder 是阿里云的 AI 编程环境。Fast 档是其中偏速度的一档。墙钟时间指用户从提交到看见结果所经过的真实时间，不是单次模型调用的延迟。同一组结果里，Credits 消耗倍数从 1.1 倍降到 0.8 倍。这篇不把这组数字再说成另一轮提速，只看他们怎么拆时间、怎么验收。

Fast 档已经能在 Qoder Desktop 0.4.4 及以后、Qoder IDE、JetBrains 插件，以及 CLI 1.1.70 及以后使用。个人版和企业版、中国站和国际站都在范围内。家族里的其他产品还没接上。

1. 先看任务卡在哪一段

他们看过一批真实消息。命令执行占了不小份额；快速编辑大约占 9.6%；明确催「快点」的请求大约占 26.9%。这三组不是互斥分类，不能加总成 100%。催得急，不等于任务本身短。

他们把场景分成三类。第一类是执行命令，模型几乎不用长篇推理。第二类要连续反馈，用户看一眼再补一句，每一轮等待都会把协作拉长。第三类边界清楚，例如格式转换、翻译和定点修改；多余的规划、反复确认和过度探索，可能比任务本身更久。

分析墙钟时，他们把执行画成依赖图：模型先决定要什么信息，工具去取，模型再决定，然后才是动作和校验。总时长由关键路径决定。优化只有三种：缩短路径上的一段、删掉不必走的步骤，或者让没有依赖的步骤并行。用户看到的优先指标有两个：端到端首 token 时间，也就是从提交到第一个可见输出 token；以及每一轮对话的总时长。这和单次模型调用的延迟不是同一件事。

2. 冷启动、工具和并行，各有各的尺子

请求开始前，系统可能要准备会话、加载配置、发现工具、恢复上下文或建立连接。冷启动优化先把「第一个动作必须有的前提」和「用到时再准备的能力」分开。能复用的资源不要每轮重新初始化；当前任务用不到的能力延后加载。预热还要受用户行为和资源预算约束，不能为了一个入口占掉别人的 CPU、内存或连接。

和结果正确性有关的权限检查、必填输入和结果校验，仍必须在对应动作之前完成。无关的状态同步、遥测和一部分界面更新可以离开同步路径。执行器可以先把已校验的结果交出去，再做不影响该结果是否成立的后台工作。「完成」的含义不能为了快而改掉。Qoder Desktop 上，这种解耦把整体冷启动时间降了 60% 以上。

取消、超时和资源回收也算进去。用户取消后，任务如果还占着连接或工具槽，下一请求会更慢。异步任务要有明确归属、取消传递和并发上限。

工具耗时再拆成启动、排队、真正执行和结果处理。常用的读和搜索，靠复用执行环境、减少重复扫描、合并已知请求。依赖外部服务的操作，要看连接复用、超时和失败恢复。只为定位一个符号的定义时，把整个目录原文塞回去，会逼模型在下一次调用里再滤一遍。更好的返回是位置、相关片段，以及有没有结果被省略。错误信息要把参数无效、权限不足、瞬时失败和数据缺失分开，减少盲目重试。面向 Agent 的工具要一起看四件事：任务完成质量、工具调用次数、总运行时间和错误率。优化工具加载及相关流程后，整体工具加载延迟降了 200 毫秒以上。部分网页搜索一类工具的执行时间降了 50% 以上。

并行有两个前提：模型得认出这些操作互不依赖，运行时也得真能同时跑。缺一个就会退回串行。举例：读三个互不依赖的文件分别要 2 秒、3 秒、4 秒，串行大约 9 秒；资源够、调度没有额外开销时，执行部分大约 4 秒。这是说明用的例子，不是线上实测。他们的并行优化在部分工具上拿到了数秒级节省。并行工具使用率在 Fast 档提高了 50% 以上，观察到的峰值超过 50 个并发工具调用。这个峰值只说明执行容量，不能单独当成普通任务变快了多少。任务级改善仍要看端到端计时对比。

3. 选模型和推理强度，用同一批任务比

单次调用更快，不代表整轮 Agent 更快。模型如果因此多搜索、多改正、多试几次，后面的动作会把前面省下的时间吃掉。「解释这个函数为什么报错」和「理清模块依赖、完成重构并验证」都是开发任务，需要的能力不一样。加一个空输入检查，也不同于改多个调用点还要保住接口行为。

开发者选定 Fast 档之后，Qoder 按任务类型调整候选模型优先级，再按这次请求的能力要求和模型是否可用来选执行模型。路由要看该模型在这类任务上的理解、生成、工具使用和持续执行，以及由此带来的端到端轮次时长。

分类由 System One 完成。应用事先规定任务类别和输出范围，System One 按输入给出明确类别。同一段代码，「解释它为什么保持原有顺序」是代码解释；「改到空输入也能用」是代码修改。分类只拿当前这一步需要的信息。分类完成后，执行模型仍拿到完成任务所需的完整上下文，负责生成代码、调用工具和验证结果。

推理强度可以调的模型，范围窄、容易验证的任务可以用更低强度，让动作开始得更早。依赖复杂、约束多或跨文件的任务要分析得更细。分类能提供参考，真正的强度还要看这次请求的复杂度和验证要求。总指标仍是任务完成时间。降低单次推理时间，如果带来更多遗漏、返工和工具轮次，整体收益可能消失。

所以路由和推理强度都要用同类任务的对照来评，并且先满足质量要求。要一起看的是：任务完成率、端到端轮次时长、工具调用轮次和返工。System One 多出来的分类大约几百毫秒；执行模型侧的优化让每次模型调用的延迟降了 200 毫秒以上。多次调用可以累加，但端到端是否净赚，要看这些节省是否超过全部分类开销。对比必须把分类时间算进去，不能只看模型自己的延迟。

4. 网络只量化了大载荷的 p95

客户端网络不稳定。Fast 档第一次单独做了一条网络路径，客户端（含 CLI）和服务端都做了优化。均值、p50 和 p95 延迟都有改善。文中给出的具体幅度只有一处：大载荷传输的 p95 延迟降了 50% 以上。均值和 p50 改善了多少，没有写成数字。

依赖图、冷启动、工具和网络各自的百分比，不能相加当成「Fast 档整体快了多少」。9.6% 和 26.9% 也不是同一分母上的互斥份额。并行峰值不能代替端到端对比。这篇没有公布完成率、返工次数的具体分数，只规定了验收时必须看这些量。

阿里云，阿里云社区，Every Tenth of a Second Counts — A Technical Deep Dive into Fast Tier Performance Optimization，2026-10-16，https://www.alibabacloud.com/blog/every-tenth-of-a-second-counts-%E2%80%94-a-technical-deep-dive-into-fast-tier-performance-optimization_603645