通过极端协同设计应对代理系统日益增长的复杂性

生成式 AI 爆发式发展的第一章，是由人类发送请求、模型作出响应来定义的。而智能体章节则有所不同。

智能体并不遵循预先确定的动作序列。它们会调用工具，生成承担不同任务、使用不同模型的子智能体，将信息保留在记忆中，管理自己的上下文窗口，并自行决定何时完成任务。在此过程中，这些系统将 token 消耗、上下文长度和延迟需求推向极其苛刻的区间——而这些压力正是当前塑造 NVIDIA 极限协同设计栈和 NVIDIA Vera Rubin 平台的关键因素。

本文分三部分分析这一演进：

1. 智能体如何消耗 token
2. 为什么它们的经济性会在传统服务方式下崩溃
3. 面向智能体专门构建的基础设施栈是什么样的

从聊天机器人向智能体过渡

如下方图 1 所示，生成式 AI 的普及始于一种简单的交互模型：一条用户消息，一条聊天机器人消息，如此重复。模型在上下文窗口中基于记忆作出响应，聊天历史线性增长，系统需求也是可预测的。

工具调用的引入从根本上改变了 AI 聊天机器人的运行方式。一旦模型可以调用计算器，而不是猜测数学结果，整个工作负载就会发生变化。由于工具响应会被直接添加到上下文窗口中，它们会给输入序列带来不可预测性。这是因为工具输出的大小取决于具体查询和工具的设计，包括它如何处理相关数据。即使该过程仍然受提示词和最终答案的限制，标准聊天的简单可预测性也已经不复存在。

当我们引入智能体时，这种动态会变得更加复杂。如果一个模型有能力调用一个工具，它也有能力决定使用多少工具以及按什么顺序使用它们。例如，一个被要求起草电子邮件的智能体可能会：

1. 阅读现有通信记录
2. 检查云端硬盘以获取上下文
3. 确认收件人的身份
4. 然后起草电子邮件

这种链式调用正是模型成为智能体的地方，也是在这里，工作负载从“具有概率性峰值的线性可预测”转变为“结构性概率化”，以至于每个智能体会话的形态可能彼此表现得非常不同。

智能体架构的特征

现代智能体架构由智能体层级结构与优化技术组合而成，能够实现有效的上下文管理、工具使用和任务优化：

• 主智能体：负责端到端地交付整个任务。可以编排处理子任务的子智能体。通常，主智能体由最智能的模型驱动，并直接与用户对话。
• 子智能体：由主智能体生成，用于处理范围更窄的任务，并且能够像主智能体一样自行管理其上下文窗口。通常，子智能体在架构上与主智能体相同或非常相似，只是实际主智能体通过提示词提供给子智能体的任务范围更有限。
• 文件系统有状态性：源自智能体将记忆和工具调用输出写入文件，并在之后搜索或重新读取其内容的额外有状态性。这是一种上下文管理和记忆的方法。
• 摘要与压缩：一种对智能体的上下文窗口进行摘要并由此压缩的技术，用于为新信息腾出空间并降低输入处理成本。

当今一些最流行的智能体工具采用相似的架构。Claude Code 等工具中的主智能体经常将工作委派给子智能体，以利用更小的上下文窗口并并行化任务。由于系统必须在每一次推理步骤中处理输入 token，使用更小的上下文可以提升效率，并降低输入 token 处理成本。这种架构为抵御一种名为上下文腐化的现象提供了必要防线；在这种现象中，不断扩展的上下文会不可避免地降低输出质量。当任务复杂度增加时，有意的压缩事件会迫使主智能体的上下文窗口急剧缩小，以弥补 token 无法无限扩展的限制。

智能体系统的工作负载动态与经济性

Anthropic 在其关于构建多智能体系统的报告中估计，这些系统消耗的 token 数量最高可达标准聊天的 15 倍。这一显著增长要求改善 token 的单位经济性，才能使这些应用在规模化时具备经济盈利能力。要应对这一推理经济性挑战，需要深入理解支配智能体经济性的系统级 token 吞吐量和延迟要求。

要理解这些工作负载的成本和复杂性，最好的方式是分析一次真实的智能体会话。图 4 提供了一个 Claude Code 编码任务的实测示例。图表中的线表示会话期间由子智能体（橙色）和主智能体（灰色）发起的每个请求的输入序列长度（上下文 + ISL）。即使在单次会话中，该轨迹也清楚表明，长上下文容量、缓存可编程性以及可预测的逐 token 延迟，与原始模型质量同样重要。

这个 33 分钟的会话跟踪了 58 个主智能体轮次，用于协调 225 次子智能体调用。在 283 个推理请求中，上下文窗口从 15K token 增长到 156K 的峰值，随后一次上下文压缩事件将其降至约 20K。该轨迹清楚表明，智能体的 token 消耗既受到智能体系统行为的影响，也受到任务性质的影响。

当主代理不进行委派或压缩上下文时，它会迅速累积输入上下文，这导致缓存读取的输入 token 成本在每一轮都重复产生。在前 40 轮中，主代理的上下文平均约为 85K tokens，并在一次压缩后的会话中再增加 100 万之前，累计处理了约 350 万个输入 tokens。正是在这些条件下，高带宽内存（HBM）、Vera Rubin NVL72 等高吞吐量平台变得相关，因为长上下文提示需要在经济上保持可行，同时预填充需求还在持续扩展。

提示缓存使这种模式变得可行。没有 KV 缓存复用，每个输入 token 都需要被完整重新处理。主流 API 提供商对缓存命中的折扣约为 90%，因此在 95% 的缓存命中率下，输入处理成本会下降约 85%；如果没有提示缓存，这里的成本将大约高出 6 倍。编码代理通常能维持 95-98% 的缓存命中率，尤其是在工具输出保持较小时。这就是为什么提示缓存越来越成为一个系统问题，而不仅仅是一个 API 功能：维持高缓存命中率取决于高效的 CPU 侧 KV 缓存管理，以及专门构建的高容量上下文存储（如 NVIDIA CMX），以便在会话扩展时保留长前缀并快速恢复它们。

子代理轨迹中的 225 个请求突出显示了各自独立的推理会话，每个会话都使用独特的上下文和特定的工具定义。子代理通常会增加总输出 token 量，但它们通过从新的上下文窗口开始，并且只传递与委派任务相关的内容来降低输入成本。它们还可以在较小的模型上运行，从而在较窄任务中仍保持准确性的同时降低延迟和成本。

上下文压缩同样重要。它提供了一种机制，可避免达到上下文窗口限制，减少上下文腐化的影响，并带来成本管理方面的附带效应。将上下文窗口从 156K token 缩减到 20K，会立即降低缓存输入 token 的支出，并为下一组任务腾出空间。

在下方图 5 中，可以从定性上明显看出，大多数已处理的 token 都是从缓存中检索的。一旦出现这种情况，网络和内存系统行为就会开始直接影响用户感知的延迟，而 NVLink 6、ConnectX-9、BlueField-4 和 Spectrum-X 等低延迟互连结构有助于保持共享上下文可访问，并在会话扩展到多个代理时减少重新计算带来的惩罚。

从这个例子可以清楚地看出，智能体的 token 动态相当复杂，token 消耗可能会在主智能体和子智能体之间迅速扩展。要理解在这种不断增长的 token 需求下扩展这些应用所面临的挑战，我们必须考虑实际交付的性能要求。

智能体工作负载的性能要求

释放智能体工作负载的价值需要高模型智能、大上下文和低延迟。这些智能体产生洞察的速度越快，其价值就越呈指数级增长。这种速度缩短了研发周期，改进了 harness 控制，并支持复杂的多智能体循环。由于实现这些能力的 token 本质上处理成本高昂，实际交付的性能就成为使这些系统既可扩展又可盈利的关键杠杆。

降低这些 token 的成本，要求生产者在大模型和大上下文场景下，在高交互性区域持续保持规模。下方图 6 通过标准推理性能帕累托展示了这一瓶颈。曲线左侧提供高吞吐量，但处于交互性的较低极端，而智能体工作负载无法在这种情况下运行。

这些工作负载必须转而移向曲线中高交互性的一侧（右侧），才能成功运行。智能体系统会消耗海量 token，同时要求较快的生成速度，以保持终端用户的交互性。问题在于，实现这种低延迟通常会导致系统吞吐量大幅下降。吞吐量降低会导致每 token 成本高得难以承受，使智能体系统在规模化时面临经济上的挑战。

打破这一瓶颈需要基础设施设计发生彻底转变。现代 GPU 提供了巨大的计算能力和可观的带宽，但要在低延迟下维持规模化，需要的不止是任何单一架构所能提供的能力。答案是极致的协同设计。这种方法会针对每个阶段专用的硬件来优化推理，并将这些独特挑战交由整个平台来承担，而不仅仅是交给一个处理器。

为什么单个处理器还不够

这些独特需求无法通过简单增加更多计算 FLOPs 和内存容量来解决。这些需求源于智能体工作方式的架构特性，而没有任何单一处理器能够同时解决它们。

所需要的是一个平台，其中每个瓶颈都映射到专用硬件，并通过极致协同设计作为统一系统进行编排（见上方图 8）：

• Vera Rubin NVL72 平台以 Blackwell 每百万 token 成本的十分之一处理容量和计算。HBM 容量使长上下文流水线变得可行；计算密度在规模化时吸收预填充成本。Vera CPU 通过更低的智能体延迟、无缝的 KV 缓存卸载以及统一的 CPU-GPU 执行，弥合了工具执行差距。Groq 3 LPX 打破了吞吐量与延迟之间的权衡。SRAM 优先架构提供严格有界、低抖动的 token 生成——当任何单个智能体的方差会传播到整个流水线时，这一点至关重要。网络芯片（NVLink 6 Switch、ConnectX-9 SuperNIC、BlueField-4 DPU 和 Spectrum-X Ethernet）为智能体工作负载创建统一、低延迟的服务结构，使智能体能够更快地协调、保持共享上下文可访问，并随着会话增长避免代价高昂的重复计算。
• 软件栈组件：Dynamo 和 Attention-FFN Disaggregation（AFD）通过将工作负载拆分到最适合的处理器上，并协调执行以减少资源争用和延迟，从而形成一条连贯的服务路径。此外，Dynamo 向智能体框架开放缓存可编程能力。NVFP4 降低了精度开销，使 MoE 智能体能够在不牺牲智能水平的情况下，以更低延迟、更高吞吐量和更低内存压力运行。TRT-LLM WideEP 为前沿 MoE 优化大规模专家并行，使智能体能够以更低延迟和更高吞吐量提供高智能响应。Speculative Decoding 通过并行生成可能的 token 并快速验证它们来缩短智能体响应延迟，从而加速大型模型的低延迟推理。

通过极致的协同设计将这七款芯片与一个软件栈结合起来，Vera Rubin 平台能够在拥有 400k 大上下文的万亿参数 MoE 模型上，为每位用户提供每秒 400+ 个 token 的性能。这一性能水平改变了智能体领域历史上的权衡范式——为了提供较高的单用户速度和较高的系统吞吐量，你不再需要通过使用更小的模型和有限的上下文窗口来牺牲质量。在这一性能区间，智能体架构将成为可规模化落地的产品，而不再是昂贵的实验。

有关 Vera Rubin 平台规格和 LPX 的更多详细信息，请查看它们各自的发布日博客：

• 深入了解 NVIDIA Vera Rubin 平台：六款新芯片，一台 AI 超级计算机
• 深入了解 NVIDIA Groq 3 LPX：面向 NVIDIA Vera Rubin 平台的低延迟推理加速器