NVIDIA Vera Rubin 与 Blackwell 树立 Agentic AI 每瓦性能新标杆
AI 智能体已将推理从单轮交互扩展至多步骤工作流——能够推理、调用工具、协调子智能体,并在各轮间累积不断增长的历史上下文。这一转变的规模在原始消耗数据中清晰可见:根据 OpenRouter 的 State of AI 报告,在 100 万亿 token 的真实使用量中,每次请求的平均提示 token 增长约四倍,而单次智能体请求消耗的 token 是普通对话的 15 倍。
为此类工作负载准确衡量硬件性能提出了新的挑战。一个有效的基准测试需要同时捕捉长上下文预填充、KV 缓存复用、交互式解码、工具调用间隙,以及分布式专家混合(MoE)在真实并发下的执行表现;还要体现 AI 工厂的电力预算有多少真正转化为了可用的智能体吞吐量,同时维持可接受的用户体验。
本文考察了 SemiAnalysis AgentX 基准测试——它通过重放生产环境风格的会话来评估 AI 基础设施在智能体编码推理方面的表现。结果显示,Vera Rubin NVL72 预览版相比 GB300 NVL72 每兆瓦吞吐量高达 30 倍,而 Blackwell GB300 NVL72 则将相比前代单兆瓦吞吐量的数量级优势延续到了动态智能体工作负载中。
什么是 AgentX?
AgentX 是 SemiAnalysis 开源基准测试套件 InferenceX 中的智能体编码基准,用于衡量加速器服务真实编码智能体请求模式的效率。
AgentX 测试与测量方法
智能体会话具有长周期、有状态、高度可变的特点:它们串联模型调用、工具使用和持续增长的历史上下文,而非遵循固定的提示-响应模式(见图 1)。因此 AgentX 需要衡量平台能否响应式地处理重放的智能体流量、复用已处理的历史上下文,以及每分配一兆瓦电力所能实现的最大智能体吞吐量。
下图图 2 展示了使用传统 InferenceX 静态 8K/1K 序列长度对 DeepSeek-R1-0528 的推理结果。GB300 NVL72 相比 H200 每兆瓦可处理高达 40 倍的 token 量。然而,该场景代表的是受控环境下的固定长度服务,而非 Agent 在实际生产中产生的流量。
在实际 Agent 会话中,每次请求的长度各不相同。上下文随任务推进而不断累积,之前处理过的 token 可被重复利用,模型调用也常因工具执行或被委派的任务而中断。随着 Agentic AI 成为主流负载,固定序列长度的测试场景已越来越难以真实反映推理性能,因此在 InferenceX 基准测试套件中被降格为"维护模式"。
AgentX 通过回放带有推理与工具调用交织的预录制 Claude Code 会话,填补了这方面的空白。它使用AIPerf 客户端逐轮重放每次会话。由于所有系统接收到的流量完全相同,观测到的差异反映的是推理栈本身的性能,而非针对特定基准的调优结果。下图(图3)展示了一次典型的预录制会话样本。
如何解读 AgentX 结果
对 AI 工厂而言,AgentX 最重要的指标是每兆瓦 token 数。该基准测试围绕四个用户体验维度来报告此指标:端到端归一化交互性、标准交互性、端到端延迟和首 token 时间(TTFT)。下表说明了如何充分利用这些指标。| 指标 | 定义 | 用途 |
| E2E 归一化交互性 | 整个请求期间每个用户的平均输出 token 速率,由总输出 token 除以从请求提交到最终 token 交付的时间得出。 | 展示平台在给定端到端体验(含首 token 时间)下每兆瓦能交付多少用户可见输出。越高越好。 |
| 标准交互性 | 仅生成阶段每个用户的 token 速率,由输出 token 除以从首 token 到尾 token 的耗时得出。 | 展示生成开始后平台每兆瓦能交付多少流式输出,不含首 token 时间。越高越好。 |
| E2E 延迟 | 单次请求的总耗时,从提交请求到接收最终输出 token 为止。 | 用于评估每兆瓦吞吐量结果是否可用:若请求耗时过长,高效率也无意义。数值越低越好。 |
| TTFT | 从提交请求到首个输出 token 到达的时间。 | 反映能效型吞吐量是否伴随快速的初始响应,这对智能体反复开启长上下文交互轮次至关重要。数值越低越好。 |
NVIDIA Vera Rubin NVL72 测试结果
以下 Vera Rubin NVL72 的测试结果由 NVIDIA 采用 SemiAnalysis AgentX 工作负载测得,目前尚在等待 SemiAnalysis 审核。如图 4 所示,在 AgentX DeepSeek V4-Pro 工作负载下,当每个用户达到 160 token/秒的互动性指标时,Vera Rubin NVL72 的 AI 工厂每兆瓦吞吐量最高可达 GB300 NVL72 的 30 倍,这意味着在保持同等交互式服务目标的同时,智能体推理容量实现了大幅提升。
要了解 NVIDIA Vera Rubin NVL72 如何设计以实现每兆瓦最大性能,请参阅《NVIDIA Rubin GPU 架构内幕:赋能智能体 AI 时代》。
NVIDIA GB300 NVL72 测试结果
在 AgentX 工作负载下,针对 DeepSeek V4 Pro 1.6T 模型,GB300 NVL72 的每兆瓦 AI 工厂吞吐量比 H200 NVL8 最高高出 15 倍(见下方图 5)。换句话说,在相同功耗预算内,GB300 NVL72 能维持显著更强的智能体推理响应吞吐能力。
这一吞吐量优势直接转化为更优的单位经济效益。GB300 NVL72 的每百万 token 成本比 H200 NVL8 低高达 10 倍(图 6,见下方)。对运营方而言,这意味着在固定的功耗和基础设施预算下,可以支撑显著更多的交互式智能体容量,或以明显更低的运营成本提供同等容量。
随着模型规模增大,GB300 NVL72 的优势越发凸显。下图 7 展示了 Kimi K3 2.8T 在 AgentX 工作负载下的每兆瓦吞吐量。在同等交互水平下,GB300 NVL72 的每兆瓦吞吐量约为 H200 NVL8 的 80 倍,同时还将交互上限扩展至约每秒每用户 215 个 token,远超 H200 NVL8 的可用范围。
上述 GB300 NVL72 的成果,来源于系统在推理运行时、模型核以及 scale-up 互联层面所开展的整体优化。这些层级协同工作,使得大型 MoE 模型在 agent 会话不断累积上下文、并发量上升、decode 压力加剧的情况下,仍能保持响应式吞吐量。
- MoE 推理运行时:包括 SGLang、TensorRT-LLM 和 vLLM 在内的框架,能够在 NVL72 域内分布专家执行。Wide Expert Parallelism、DeepEP 等技术有助于在更多 GPU 上均衡专家负载,从而扩大可供并发 agent 请求使用的有效批处理规模。
- MoE 核与通信重叠:基于 DeepGEMM 的核函数、MXFP4 和 MXFP8 等混合精度格式以及融合式 MoE 执行路径,可减少数据在专家阶段间传输的时间。通过将专家并行通信与 Tensor Core 计算重叠,推理栈能够进一步提升推理与代码类工作负载的 token 吞吐。
- NVIDIA Dynamo: Dynamo 将 prefill 和 decode 分离到独立扩展的 worker 池中,使各阶段可按自身性能需求进行配置。它还支持基于 session 的服务,通过 session ID 将 Agent 运行中相关的模型调用、tool spans 和 traces 关联起来。此外,其 KV-cache 感知路由器利用缓存重叠情况和 worker 负载来选择目标,减少不必要的 prefill 计算,在 Agent session 复用上下文时帮助维持响应的多轮对话服务。
- NVIDIA NVLink scale-up 网络:NVLink 在 GB300 NVL72 中连接 72 个 GPU,构成高带宽的 scale-up 域,为大规模模型提供协调的机架级系统所需的计算、内存、专家并行通信和 KV-cache 数据移动。
Agentic AI 的未来方向
Vera Rubin NVL72 展示了当机架级系统针对 agentic 推理的长上下文、交互式和分布式执行模式进行调优时所能达到的效果。更广泛的 Vera Rubin 平台将这一方法扩展到完整工作流中:Rubin GPU 高效处理大上下文和解码,Vera CPU 负责工具执行和 KV-cache 卸载,Groq 3 LPX 解锁超快交互体验。
在整个 AI 工厂中,NVLink 6、ConnectX-9、BlueField-4 和 Spectrum-X 在不同资源间传输 tokens、上下文和工具结果;Dynamo、Attention-FFN 分离、NVFP4、TensorRT-LLM WideEP 和推测解码则在最合适的处理器之间协调执行。目标很简单:减少重复计算和等待时间,在 Agent 会话增长时保持交互性能,并将更多固定功耗预算转化为有用的 agentic 输出。
若要深入了解这一成果背后的技术和基准测试,请参考以下资源。
- 了解 NVIDIA Rubin 的架构与能力
- 在 SemiAnalysis InferenceX 仪表板 查看实时基准测试结果
- 在《通过极致协同设计应对智能体系统日益增长的复杂性》一文中,了解 NVIDIA 的极致协同设计如何解决智能体系统日益增长的复杂性、延迟和成本挑战。
致谢
本工作离不开 Xin Li、Ankur Singh、Anthony Casagrande、Jonas Li、Po-Han Huang、Xiaoming Chen 及众多优秀 NVIDIA 工程师的专业支持与工程贡献。