英伟达Vera Rubin的Agent吞吐暴涨最高提升30倍，却不只靠GPU | Hot Chips 2026

在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生成、工具执行和数据通信，下一代推理基础设施要优化的对象，已经不再是一颗芯片，而是整条任务链。

雷峰网雷峰网(公众号：雷峰网)雷峰网

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

雷峰网原创文章，未经授权禁止转载。详情见转载须知。

在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生成、工具执行和数据通信，下一代推理基础设施要优化的对象，已经不再是一颗芯片，而是整条任务链。

雷峰网雷峰网(公众号：雷峰网)雷峰网

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

雷峰网原创文章，未经授权禁止转载。详情见转载须知。