在 Agent 推理上，英伟达又把性能往前推了一大步。

Hot Chips 2026 期间，英伟达披露了 Vera Rubin NVL72 最新 Agent 工作负载测试结果：在 DeepSeek V4-Pro、单用户每秒 160 Token 的测试条件下，相比 GB300 NVL72，每兆瓦吞吐最高提升 30 倍。 

但比 30 倍更值得关注的是，英伟达这次提升 Agent 推理效率，已经不再只依赖一颗更快的 GPU。 

面对长上下文、低延迟 Token 生成、工具调用和数据交互同时出现的 Agent 工作负载，英伟达正在把一次推理拆成不同类型的计算任务：Vera Rubin NVL72 承担大规模模型计算，Groq 3 LPX 专攻低延迟 Token 生成，Vera CPU 处理工具编排、代码执行和数据处理，Spectrum-X 则负责把这些计算、数据和存储资源连接起来。 

换句话说，Agent 工作负载让性能问题不再停留在一次模型计算内部，而是沿着上下文、生成、工具执行和基础设施访问继续向外扩展。

从 GPU、CPU 到专用推理芯片和网络，英伟达在 Hot Chips 展示的已经不只是一代芯片的性能提升，而是一套针对 Agent 工作负载重新划分计算边界的系统架构。

超长上下文实测，Rubin 把 Agent 推理拉进真实长任务

这次 Hot Chips 上，英伟达给出了一组更贴近 Agent 工作流的 Rubin 实测数据。英伟达此次测试采用 SemiAnalysis AgentX 工作负载。

AgentX 基于真实 Agent 编程会话的流量轨迹，在去除原始 prompt、代码、工具参数和结果后，保留请求长度、上下文增长、工具暂停、子任务依赖和时序等负载特征。此次测试的中位输入上下文超过 14 万 Token。

按照英伟达测得、目前仍待 SemiAnalysis 审核的结果，在 DeepSeek V4-Pro 工作负载、单用户每秒 160 Token 的交互速度下，Vera Rubin NVL72 相较 GB300 NVL72 最高实现 30 倍的每兆瓦吞吐。

Vera Rubin 在 160 交互性下，每兆瓦的吞吐量提高了 30 倍。（图源：英伟达技术博客）

英伟达 HPC 与 AI 超大规模基础设施解决方案高级总监 Dion Harris 指出，传统推理基准通常围绕 " 单一、可预测的请求 " 设计：输入和输出相对确定，因此可以比较 Token 生成速度、吞吐量等指标。但 Agent 任务会跨越多轮操作，而且每一步的工作负载都可能变化。

Harris 续指，传统推理负载可以使用 8K 甚至 32K 的输入序列进行测试，但到了递归式、多轮 Agent 任务中，Prefill 需要处理的上下文会随着每一次迭代持续增长，因此平台评估需要开始考虑数十万 Token 级别的输入。 

原因在于，Agent 完成一项任务时，模型可能不断读取文件、调用工具、执行代码，再把新的结果写回上下文，进入下一轮推理。AgentX 测的是推理服务基础设施面对 Agent 流量形态时的表现，不是测 Agent 任务完成质量。 

这也是此次 Rubin 测试采用超过 14 万 Token 上下文的意义。换言之，14 万 Token 的意义并不只是 " 输入更长 "，而是测试对象开始从静态 prompt 转向动态任务轨迹。

它试图回答的不再只是 " 一次模型推理能够跑多快 "，而是在更接近 Agent 实际运行轨迹的长链路负载下，系统还能维持怎样的性能。

与此同时，英伟达把两个指标放在了同一张性能曲线上：横轴是单个用户每秒获得的 Token 数量，即交互速度；纵轴则是固定电力预算下整套系统能够处理的 Token 数量，即每兆瓦吞吐。

在多轮代理会话中，每轮对话所包含的上下文信息稳步增加。（图源：英伟达技术博客）

这两个指标对应着 Agent 推理中两个不同的性能目标：一边是提高单个用户在 Token 生成阶段的交互速度，另一边则是在有限电力条件下承载更多推理负载。

因此，这组数据更值得关注的是，当 Agent 进入硬件实测之后，长上下文、总体吞吐和交互速度开始被放到同一个性能问题中讨论。

而当同一套推理系统需要同时优化这些目标时，下一个问题也随之出现：这些任务，是否仍然适合全部交给同一种处理器完成？

加入 LPX，GPU 不再是 AI 推理环节的最佳架构？

这种性能目标的分化，正在直接反映到推理芯片的架构上。 

英伟达透露，Groq 3 LPX 已经进入全面生产。按照 Artificial Analysis 的测试，在 Gemma 4 31B、10 万 Token 上下文这一特定负载下，Groq 3 LPX 输出速度达到每秒 3400 个 Token，英伟达称其响应速度达到最接近替代方案的 4 倍。

  LPX 瞄准的并不是 " 大模型推理 " 这个笼统的问题，而是其中一个更具体的瓶颈：低延迟 Token 生成。

Prefill 需要并行处理大量输入 Token，通常更偏计算密集型；Decode 则需要一个 Token 接一个 Token 生成，并持续读取模型权重和 KV Cache，因此通常更受内存带宽和单步延迟限制。

英伟达也把 Agentic AI 面对的计算挑战拆成了两个方向：一边是高效处理越来越大的上下文，另一边是以极低延迟生成 Token。 

Groq 3 LPX 针对的是后一个方向，但需要注意，这并不意味着英伟达正在用 LPX 替代 GPU。GPU 与 LPX 之间并不存在一种固定的任务切分方式。 

在最直接的 Prefill-Decode 拆分中，Vera Rubin NVL72 处理输入上下文并生成 KV Cache，LPX 则参与后续 Decode 阶段的低延迟生成；另一种方案则把 Decode 内部继续拆开，由 Rubin 负责 Attention 计算并持有 KV Cache，LPX 负责 FFN 计算；此外，还可以让 LPX 运行一个较小的 draft model 提前生成候选 Token，再由 Rubin 上的大模型进行验证，即推测解码。 

这三种方案的数据流和计算分工不同，但背后的逻辑是一致的：并不是先决定一次推理应该由 GPU 还是 LPU 完成，而是把推理内部进一步拆成性质不同的计算任务，再交给更适合的处理器执行。

英伟达称，Groq 3 LPX 扩展了 Vera Rubin 平台的功能，使其能够支持具有高交互性的智能体 AI 工作负载。（图源：英伟达技术博客）

这也产生了一个问题，将 Groq 3 LPX 加入 Vera Rubin，是否意味着 GPU 已经不再是所有 AI 推理环节的最佳架构？

Harris 给出的解释是，" 为工作负载的不同部分选择合适的处理器 "。他认为，Rubin GPU 仍然提供最灵活的吞吐和交互能力，覆盖更广泛的工作负载；LPX 则进一步把系统推向对极低延迟要求更高的场景。

因此，LPX 真正值得关注的并不是英伟达又多了一颗芯片，它反映的是，在 Vera Rubin 这套系统里，原本由通用 GPU 统一承接的不同性能目标正在被进一步拆开：GPU 继续承担覆盖范围更广的模型计算，而专用加速器则围绕 Token 生成延迟等具体瓶颈补位。 

这也解释了为什么 Agent 工作负载下更细的异构分工，并不意味着 GPU 的重要性下降。恰恰相反，GPU 仍然位于计算中心，只是围绕它，不同处理器的任务边界正在变得更加明确。

从 GPU 到 CPU 和网络，英伟达开始优化整条 Agent 链路

如果说 GPU 与 LPX 的分工仍然发生在模型推理内部，那么 Agent 带来的下一层变化，是性能瓶颈继续延伸到模型调用之外。

传统大模型服务中，一次模型输出往往就是任务的终点。Agent 并不是这样。模型完成一轮推理后，还可能继续调用搜索、数据库或其他软件工具，执行代码、处理返回结果，再把新的信息送回模型，进入下一轮推理。

这意味着，决定一次 Agent 任务速度的，已经不只是 GPU 完成模型计算需要多少时间。Harris 提到，Agent 正在增加模型调用之间的 CPU 负载：工具编排、代码执行、数据处理和模拟，都需要 CPU 参与。

这也是英伟达此次强调 Vera CPU 的原因。Vera 在这里承担的并不是模型计算本身，而是两次模型调用之间那些仍然需要 CPU 完成的任务。 

类似的变化也发生在网络层，当 Agent 不断访问工具、数据和存储时，网络面对的不再只有 GPU 之间的数据交换。用户、Agent、应用、数据源和存储服务需要持续发生交互，计算系统与这些基础设施之间的连接同样可能进入任务的关键路径。 

在这样的背景下，这英伟达此次提出了 Scale-In。与通过 NVLink 连接机架内 GPU 的 Scale-Up，以及通过 Spectrum-X 连接更大规模 GPU 集群的 Scale-Out 不同，Scale-In 针对的是传统数据中心中的南北向基础设施流量，由 BlueField-4 和 DOCA 承担网络、存储访问、安全、控制平面和可观测等任务，再通过 Spectrum-X 接入整套计算基础设施。

与 Scale-In 处理模型调用之外的基础设施访问不同，Spectrum-X Multiplane 解决的是另一类更普遍的问题：随着 GPU 集群规模扩大，网络本身的扩展能力和故障恢复开始直接影响计算资源能否持续被利用。

Spectrum-X Multiplane 通过多个独立网络平面扩大两层网络的规模，并在单一路径出现故障时进行硬件级重新路由。按照英伟达给出的数据，该架构最高可扩展至 51.2 万张 GPU；在八平面拓扑中，一个平面失效后仍可维持约 90% 的总带宽，故障恢复速度较软件方案提高 11 倍。

Scale-In 和 Spectrum-X Multiplane 解决的并不是同一个网络问题。Scale-In 处理计算系统与数据、存储和基础设施服务之间的连接与管理需求；Multiplane 则解决更大规模 GPU 集群的网络扩展和故障恢复问题。

但放回完整的 Agent 任务链中，两者指向同一个变化：决定任务效率的环节正在从一次模型计算不断向外延伸。

GPU 可以更快地完成模型计算，LPX 可以进一步压低 Token 生成延迟；但如果 Agent 随后卡在工具执行、数据读取或者通信上，前面获得的计算性能仍然会被等待时间消耗掉。Agent 改变的不只是推理芯片内部的分工，也在扩大 AI 基础设施需要优化的范围。

这并非意味着未来每一个 Agent 系统都会配置 LPX、Vera 这样的 CPU 和如此大规模的网络基础设施。英伟达此次展示的明显是面向高并发、长上下文和大规模部署的上限设计，它最终能够形成多大的实际市场，仍然取决于 Agent 应用能够产生怎样的真实负载，以及更复杂的异构系统能否换来足够的性能收益。

从 Hot Chips 此次英伟达展示出的架构逻辑来看，一个趋势已经比较清楚：GPU 仍然是 AI 计算的核心。只是当一次 Agent 任务横跨上下文处理、Token 生成、工具执行和数据通信，下一代推理基础设施要优化的对象，已经不再是一颗芯片，而是整条任务链。

雷峰网雷峰网雷峰网

【封面图片来源：网站名英伟达官网，所有者：英伟达】