Agentic AI延迟问题：算力堆叠不是答案

半数企业 AI 部署在峰值负载下无法达到自身设定的延迟目标。这是 Akamai《2026 AI 推理现状》报告的核心发现，该报告调查了 200 名 AI 从业者，发现 82% 的组织表示其最关键的应用场景需要 500 毫秒或更短的端到端响应时间。64% 的组织现在对其最重要的应用场景要求端到端响应时间低于 250 毫秒，然而 50% 的部署在峰值负载下无法满足这些延迟要求。

我的同事 Ari Weil 是我们云计算业务的产品营销负责人，也是这项研究的负责人，他很好地总结了这些发现："企业 AI 的蜜月期已经结束……他们正在遭遇延迟墙。"

Agentic 工作流不是"单次往返"

延迟问题源于 Agent 的工作方式。这是一个迭代过程，有点像国王派出骑士、使者、信使来管理王国事务。有很多人来来往往，而不是一个人完成一次单程往返。

例如，当基于 LangChain、CrewAI 或 Pydantic AI 等框架构建的 Agent 收到用户请求时，它可能会分散成数十个顺序操作，如推理调用、工具调用、API 查询或上下文检索。然后 Agent 可能会执行另一个推理调用来决定如何处理刚返回的结果。每一个这些操作或"跳跃"必须穿越广域网才能到达集中式数据中心，这会增加延迟，而 50 次跳跃的链式调用可以将传输时间累积到数秒，与模型生成令牌的速度无关。

实际上，在 2025 年 11 月发表在 arXiv 上的一篇论文中，研究人员发现 CPU 端处理可占 Agentic 工作负载总延迟的 90.6%。换句话说，你的 GPU 可能在几百毫秒内完成一个推理步骤，但随后可能需要等待远处数据中心的 CPU 执行额外的工具调用。这正是导致 GPU 空闲时间飙升的原因。

"更多的 GPU 算力对此毫无帮助。你无法用暴力堆算力的方式摆脱等待状态。"

更多的 GPU 算力对此毫无帮助。你无法用暴力堆算力的方式摆脱等待状态。这是业界一直在回避的对话部分，主要是因为"购买更多 GPU"比"找出你的 CPU 密集型工作实际在哪里执行，以及为什么它离所需数据这么远"是一个更容易给出的建议。

我们需要新的基准测试来解决延迟问题

即将到来的延迟墙悄悄逼近团队的一个原因是，他们没有为 Agentic 工作负载查看正确的基准测试。大多数 LLM 服务基准测试衡量的是单个设备上的每秒令牌数和 GPU 利用率。如果工作负载确实在单个设备上（即一个模型回答一个提示），那就很好，但对于 Agentic 工作负载来说并非如此。这些基准测试没有解决 Agentic 响应的问题，比如一条 50 跳的链式调用需要穿越 WAN 4 次才能到达 4 个独立的服务。

"预发布环境可能通过基准测试，因为它测试的是模型，但生产环境测试的是整条链，包括你的服务引擎从未设计去看到的每一次跳跃。"

这就是差距所在：预发布环境可能通过基准测试，因为它测试的是模型，但生产环境测试的是整条链，包括你的服务引擎从未设计去看到的每一次跳跃。

500毫秒墙不是软目标

这一点在大规模中显现出来，因为 Agent 进入生产的速度超过了大多数团队架构演进支持它们的速度。LangChain 的《2026 Agent 工程现状》调查了超过 1300 名专业人士，发现 57.3% 的组织现在有 Agent 在生产环境中运行，高于一年前的 51%。在这些构建者中，延迟已成为生产环境的第二大障碍，仅次于输出质量。

对于应用团队来说，这是一个严重的问题。Akamai 调查中 500 毫秒的阈值不是团队可以错过的性能目标。对于实时客户交互或实时合规检查而言，那 500 毫秒决定了应用是否能正常工作。

我们之前已经解决过这个问题

对于任何在 1999 年为网络构建应用的人来说，这感觉似曾相识是有原因的。Akamai 的存在正是因为一个几乎相同的问题。MIT 研究人员 Tom Leighton 和 Danny Lewin 创立了该公司，以回应 Tim Berners-Lee 提出的挑战：修复媒体开始称之为"万维等待"的难题——将每个请求拉回到少数集中式服务器所造成的巨大延迟。当《星球大战：幽灵的威胁》预告片在 1999 年导致整个互联网的网站崩溃时，罪魁祸首是距离：数百万浏览器同时访问同一个遥远的源服务器。解决方案是将内容移至更接近请求者的数千个点，而不是试图建立一个更快的源站。

Agentic AI 正在遇到同样的墙，只是载体不同。如果你说的是通宵运行批量作业，AI 在集中式推理上运行得很好。但如今基于 Agentic AI 构建的应用程序是嵌入在实时事务中的实时循环，而解决 Agentic 延迟的办法是分布式。与其在整个系统扩展 CPU 和 GPU 机架，不如将 Agentic 执行移到模型工具、上下文数据和用户实际所在的位置。

Agentic AI 需要分层架构，而不是更大的数据中心

实际上，Agentic AI 需要分层架构，包括集中式核心、区域 GPU 集群和边缘 CPU。

集中式核心——非常适合对大型上下文窗口进行重型推理，因为与模型的原始能力相比，到大型模型的往返时间不那么重要。

区域 GPU 集群——越来越多地构建在 NVIDIA Blackwell 平台等硬件上——是本地化推理的理想选择，因此最重的计算可以更接近需求实际集中的地方。

边缘 CPU——速度的关键组件。这是工具执行、编排和上下文检索的枢纽，因为这些是链中发生最频繁的步骤，并且最受益于位于它们调用的数据和 API 旁边。

我们已经围绕这个分层框架构建了 Akamai Inference Cloud。这与我们 AI Grid Orchestrator 背后的分布式逻辑相同。我们将 CPU 密集型的编排和工具调用路由到边缘，并将 GPU 密集型的推理保留在有意义的区域或中心位置。

承诺之前要提出的要求

好消息是你不需要在第一天就将每个工作负载分布到边缘。但在你承诺采用生产架构之前，你应该知道你的 Agent 数十次跳跃中有哪些对延迟敏感，哪些不敏感。然后为每一个构建明确的性能预算。

"那些将其视为 GPU 采购决策的团队，六个月后会回到这里，盯着同样四秒的响应时间，想知道为什么更多的算力没有帮助。"

我的建议是：在签署大规模推理部署之前，向你的基础设施提出四个要求：

• 跨区域和跨提供商的可移植性
• 吸收峰值负载而不崩溃的弹性
• 数据本地性，以便工具调用不必跨越海洋来访问所需的上下文
• 针对生产流量实际测试过的性能预算，而不是预发布环境的流量

现在解决这个基础设施决策的团队，将是那些在基准环境过渡到真实用户时 Agent 仍能正常工作的团队。那些将其视为 GPU 采购决策的团队，六个月后会回到这里，盯着同样四秒的响应时间，想知道为什么更多的算力没有帮助。