十二步串起来的延迟，换更快的卡也补不回来

一条十二步的智能体任务，每一步一次模型调用、一次工具调用，人坐在屏幕前等结果。同一个区域里，模型 200 毫秒返回，工具 50 毫秒返回，250 毫秒乘十二，整条任务三秒。

这个数字里没有任何异常：没有一步重试，没有一次工具卡住，没有一次排队。它是一条正常任务的正常值。把它和 Akamai 今年那份《The State of AI Inference 2026》放在一起看，三秒这个结果就有了来处。

Akamai 的调研给了四个数：64% 的组织要求核心用例在 250 毫秒以内返回；50% 的生产推理部署在规模上来之后守不住延迟；一半的团队把峰值延迟列成扩容时最紧的约束；46% 仍然把推理放在单一云区域，而 60% 的人认同推理应该跑得离用户更近。报告的结论是集中式架构撞上了一堵「延迟墙」。

这四个数看着像四个发现，其实是同一道加法里的三个加数。250 毫秒定下每一步的预算，单区定下每一次往返的长度，峰值定下排队那一项。三秒是它们加出来的，不是 GPU 型号选错的结果。报告说方向对，但它出自一家卖分布式推理的公司，结论和自家产品一致，数字可以当事实用，结论要打一次折。

一、把延迟拆到不能再拆

一条任务的端到端时间，是这几项相加：串行步数乘上每一步的（模型时间 + 网络往返 + 工具等待），加上重试次数乘单步时间，再加首次排队时间。

每一项都还能再拆。模型时间自己分两段：读输入那一段随输入长度线性增长，写输出那一段随输出长度线性增长。网络往返每步至少两次，一次把请求送出去，一次把结果拿回来，长度与物理距离成正比。工具等待落在别人的系统上，你控制不了它，但它经常比模型时间还大。

这里有一件事值得和钱那一栏对照着看。我们此前算过推理账单，七成输入是系统提示，只有 28% 的调用吃到缓存。同一批重复的上下文，在成本表上是一笔钱，在延迟表上是一段读输入的时间；它每被重读一次，就多花一次时间。

单区那一步最容易低估。假设模型调用要跨一个区域，每次多 200 毫秒往返，十二步就是多 2.4 秒，任务从三秒变成五点四秒。如果工具调用也在另一边，是七点八秒。模型的每一次返回还是 200 毫秒，模型没有变慢；变慢的是往返，而往返的次数等于步数。

二、峰值那一项为什么不线性

排队有个粗糙但够用的关系：利用率五成的时候，平均排队时间大约等于一次服务时间；七成是两点三倍；八成五是五点七倍；九成五是十九倍。按 200 毫秒一步算，利用率从五成推到八成五，排队时间从 200 毫秒涨到 1.13 秒。

这就是加卡救不了尾部延迟的机制。容量规划按平均并发做，延迟坏在峰值并发上，两者之间隔着一条指数曲线。多买卡把曲线往右推一点，推不过去，因为排队时间的分母是一减去利用率，不是卡数。

报告说一半的团队在规模化以后守不住延迟，原因在这里。它不是一个选型错误，是两个口径错位：采购按平均 QPS 申请容量，验收按 p95 延迟看结果，中间那段由用户承担。

三、步数是怎么长出来的

设计时的流程图通常只有三四个框：理解需求、查资料、执行、回复。生产里的步数很少停在这个数上。

多出来的部分大多有正当理由。解析意图要一次调用；查知识库，第一次没查到要改写查询再查一次；工具参数不对要重试；拿到结果要校验，校验不过要重来；最后还要一次调用把过程写成给人看的说明。这些都不在设计图里，是迭代里一个一个加上去的，每加一个，端到端就多一次模型往返和一次工具等待。

所以生产里的步数，通常是设计时估的两到三倍。这不是工程纪律问题，是智能体这个形态本身的形状：它把「一次调用」换成了「一串有条件的调用」，而条件是运行时才出现的。

四、三层动作，顺序不该颠倒

按上面的拆法，可动的动作有三层。

第一层，砍步数。十二步减到六步，端到端从三秒到一点五秒，直接减半。砍法有三样：能并行的步并行，固定判断改成规则，重复的检索合并成一次。这一层不改合同，不改供应商，不花钱，但它要求有人真的去读一遍任务的执行路径，而这件事大多数团队没做过。

第二层，缩上下文。读输入是线性项，系统提示从三万 token 降到八千，首 token 的时间跟着掉。这一层和第一层经常一起做，因为长上下文往往是步数多的副产品，步数砍下去，上下文自己会瘦一圈。

第三层，就近部署。它解决的是往返那一项：每次往返从 200 毫秒降到 20 毫秒，十二步能省下两秒上下。这是三层里唯一要花钱、要动合同、要改运维的一层，所以它该排在最后，而不是最先。多数团队的顺序正好相反，因为这一层可以外包出去，前两层只能自己做。

五、哪些任务不该做就近部署

三类任务不用考虑它。

夜里跑的批处理。没有人在等，集中式更便宜，延迟根本不是约束。为它做多区部署，买到的是一个没人消费的指标。

有数据驻留要求的环境。金融、医疗、政务常常要求数据不出境甚至不出省，那 46% 的单区里，有一部分是合规要求，不是疏忽。这类环境能动的只有前两层；硬做就近部署，换来的是合规问题，而合规问题不按毫秒计。

强一致性的多区。模型版本、缓存、索引、特征库在多区之间同步，版本漂移会带出新的、更难解释的行为差异。省下的两秒，可能换来一个查不出来的不一致。

判据只有一句：这条任务有没有人在等。有，就近部署值得算；没有，别为它做。

六、按步计时，怎么落进 trace

上面这些账，没有度量就没法用。一条可用的 trace 至少给每一步记三个数：模型时间、网络往返、工具等待，再给整条任务记一个总时间。

缺了网络那一项，你永远分不清是供应商慢，还是机房远。这两者对应的动作完全不同：一个是换模型或换供应商，一个是换部署位置。多数团队只有总时长，于是只能在两个方向之间猜。

这套字段同时是验收的依据。合同里写的延迟计量点，如果和 trace 里的字段对不上，验收那天你会发现两边在量不同的东西，而且都没有错。

七、合同里值得改的四条

如果已经决定要买，有四条比 SLA 百分比更要紧。

一，延迟的计量点。SLA 通常写的是服务端处理时间，不含你的网络和你的工具调用。让供应商写明在哪一段计时：首 token、完整响应，还是端到端。三个口径之间可以是几倍的差距。

二，地域清单与跨区调度权。峰值时能不能把某类调用路由到别的区域，谁来决定，数据能不能过去。这三问要在签约前答完，不能留到扩容那天。

三，峰值降级策略。换小模型、读缓存、排队等，三选一，写进合同。不写，峰值时的默认行为通常是三者里最坏的那个。

四，限流的口径。按每秒请求数限流的接口，在智能体场景下会以你意想不到的方式限到你，因为一条任务在它眼里是十二个请求。按任务计和按请求计，是两种完全不同的可用性。

八、我们的判断

第一，延迟的单位换了。从一次调用变成一条任务之后，按调用做优化会撞墙：200 毫秒改到 180 毫秒，在十二步里省 240 毫秒；把步数从十二减到六，省一点五秒。两者差一个数量级，而多数团队的优化清单还停在第一栏。

第二，就近部署是智能体架构的必然结果，不是 CDN 的营销延伸。任务一旦有十几步、每步两次往返，物理距离就成了这条账里最容易被忽略、又最容易被量化的一项。它同时也是唯一一项可以外包给供应商的，所以供应商一定会强调它。

第三，报告的数字可用，结论要用自己的任务重算一遍。50% 这个数说明的是行业普遍性，不说明你的某条流程。把它拆成计量点、地域、降级、限流四条款，比当成采购理由有用得多。

第四，这一批里最贵的一项其实不用花钱。步数是自己写的，上下文是自己塞的，这两项改起来不花钱，只花时间；而多数团队先买的是第三项。

九、这个季度能做的三件事

一，挑一条有人等的任务，抓一次完整 trace，按步计时。多数团队第一次做会发现，等待的时间比模型生成的时间长。

二，把步数列出来，标出能并行的、能改成规则的、能合并的，目标先定减半。这一步不需要任何人批准。

三，拿一条真实任务去问供应商：三秒里的每一段，它能不能说清。答不上来的，先把计量点写进验收标准再谈价钱。

来源

Akamai，The State of AI Inference 2026：akamai.com/lp/the-state-of-ai-inference。64% 要求 250 毫秒以内、50% 的生产部署在规模化后守不住延迟、50% 把峰值延迟列为扩容首要约束、46% 绑在单一云区域、60% 认同应靠近最终用户、「延迟墙」的表述，均出自该页。该报告为厂商调研，结论方向与 Akamai 的分布式推理产品一致，本文按此标注。

DigitalOcean，12 Best Inference Providers for AI Agents in 2026：digitalocean.com/resources/articles/best-inference-providers-ai-agents。其中引用的 Currents 报告显示，49% 的受访者把推理成本列为规模化扩张的头号阻碍，同样为厂商调研数据。

文中的 250 毫秒步预算、跨区 200 毫秒往返、排队倍数换算为按公开延迟与排队关系做的推算，不是任何一家厂商公布的实测值；举例用的步数与耗时是示意口径，用于说明加法结构，不代表特定系统的性能。