中文内容
NVIDIA Groq 3 LPX 是一款面向 NVIDIA Vera Rubin 平台的新型机架级推理加速器，旨在满足智能体系统对低延迟和大上下文的需求。LPX 与 NVIDIA Vera Rubin NVL72 协同设计，为 AI 工厂配备了一个针对快速、可预测的 token 生成而优化的引擎；与此同时，Vera Rubin NVL72 仍是用于训练和推理的灵活通用主力，可在预填充和解码环节提供高吞吐量，包括长上下文处理、解码注意力以及大规模高并发服务。
这种组合之所以重要，是因为智能体化的未来需要一种新的推理类别。随着生成速度接近每位用户每秒 1,000 个 token，模型将超越对话速度的交互，迈向思维速度计算。以这种速率，AI 系统可以持续推理、模拟和响应，从而带来更像实时协作、而非回合制聊天的体验。
这一转变也提高了多智能体系统的上限。单个智能体本身可以很强大，但协调一致的智能体群体能够完成更多事情，就像人类社会通过集体智慧和协调来扩展其能力一样。
支持这些新兴工作负载需要能够同时提供高吞吐量和低延迟的基础设施。Vera Rubin NVL72 与 LPX 的组合实现了这种异构架构，将大规模 AI 工厂性能与快速 token 生成相结合，以驱动持续运行的智能体系统和下一代 AI 应用。
推出 NVIDIA Groq 3 LPX
Vera Rubin 与 LPX 结合了 Rubin GPU 和 LPU 的极致性能，可为万亿参数模型提供最高达每兆瓦 35 倍的推理吞吐量提升，以及最高达 10 倍的收入机会。LPX 集成于 NVIDIA MGX ETL 机架架构，并与更广泛的 Vera Rubin 平台保持一致，使数据中心能够在通用基础设施设计中，与 Vera Rubin NVL72 并行部署一条专用的低延迟推理路径。
该系统围绕 256 个互连的 NVIDIA Groq 3 LPU 加速器构建。其架构强调确定性执行、高片上 SRAM 带宽，以及紧密协调的纵向扩展通信，因此即使并发量上升、请求形态变化，交互式推理也能保持响应迅速。
LPX 与 Vera Rubin NVL72 一同部署，可加速解码循环中对延迟敏感的部分，包括 FFN 和 MoE 专家执行，而 Rubin GPU 继续处理预填充和解码注意力。二者共同提供了一条异构服务路径，在不牺牲 AI 工厂吞吐量的情况下提升交互响应能力。
在机架规模下，LPX 可提供：
Vera Rubin NVL72 和 LPX 为 AI 工厂打造了一种更加异构的推理架构——能够支持高总量 token 生成，并提供响应迅速的交互式 AI 体验。
NVIDIA Groq 3 LPX 计算托盘内部
LPX 机架级加速器容纳 32 个液冷 1U 计算托盘，每个托盘都旨在支持大规模低延迟推理。每个托盘集成了八个 LPU 加速器、一个主机处理器以及结构扩展逻辑，采用无缆设计，简化机架级部署，并将计算与通信紧密耦合。
LPU 芯片到芯片（C2C）链路可在托盘内部、通过 LPU C2C 主干在托盘之间，以及在系统扩展时跨机架提供直接通信。连接性很重要，因为交互式推理不仅仅关乎原始计算能力。它还取决于系统能多高效地移动数据、协调工作，并在请求跨设备流动时避免可变延迟。
每个托盘提供：
在系统层面，LPX 面向推理场景而构建，在这些场景中，协调开销和抖动会很快被用户感知到。随着越来越多的 AI 应用从离线或以吞吐量为导向的服务方式转向交互式生成，这一点尤为相关。要了解 LPX 如何针对这种场景进行优化，有助于考察该系统核心的处理器架构：NVIDIA Groq 3 LPU。
初探 NVIDIA Groq 3 LPU 架构——Vera Rubin Platform 的第七款芯片
LPX 的核心是 NVIDIA Groq 3 LPU，旨在通过在编译器控制下紧密耦合计算、内存和通信，实现快速、可预测的 token 生成。LPU 架构旨在通过在编译器控制下紧密耦合计算、内存和通信，实现快速、可预测的 token 生成。LPU 并非只优化峰值算术吞吐量，而是强调确定性执行、高片上内存带宽和显式数据移动。这些能力对于以解码为主、对延迟敏感的推理场景尤为重要。
以张量为先的计算与显式数据移动
LPU 中的计算和通信以 320 字节向量作为工作单元来组织。算术运算、内存访问和设备间传输都在这些固定大小的向量上进行，从而简化调度和同步。
专用执行模块处理不同类别的操作：
- 矩阵执行模块（MXM）为张量运算提供密集乘加能力，基于固定数据类型运行，并具有可预测的吞吐量。
- 向量执行模块（VXM）使用每条通道上的算术逻辑单元（ALU）网格来处理逐点算术、类型转换和激活函数。
- 开关执行模块（SXM）执行结构化数据移动，包括向量的置换、旋转、分发和转置。
通过使数据移动显式且可编程，LPU 能够让内存访问、计算和通信相互重叠，而不是依赖硬件启发式机制。
MEM 实现极高的片上内存带宽
LPU 的一个核心组成部分是 MEM 模块——一种以 SRAM 为优先的扁平化内存架构，其中 500 MB 高速片上 SRAM 作为推理的主要工作存储。编译器和运行时并不依赖硬件管理的缓存，而是将包括权重、激活和 KV 状态在内的活动工作集放入片上内存，并显式移动数据。这减少了不可预测的停顿，并通过让对延迟最敏感的数据靠近计算单元，帮助实现低且稳定的延迟。
由于片上 SRAM 容量有限，更大的模型会通过逐层分区等并行执行策略，扩展到许多互连的 LPU 加速器上，因此整个系统呈现出大得多的有效工作集。在这种设计中，性能更多地取决于系统能否持续为计算单元供给数据，而不是峰值算术吞吐量；这也是 LPX 将每个 LPU 150 TB/s 的片上内存带宽与高带宽的纵向扩展芯片到芯片（C2C）通信相结合的原因。
具备可预测通信的 C2C 扩展
为了在多个设备上扩展推理能力，LPU 包含高基数、高速 C2C 链路，专为确定性数据交换而设计。每个 LPU 通过 96 条 C2C 链路连接，每条链路运行速率为 112 Gbps，从而实现精简的 LPX 纵向扩展拓扑，提供 2.5 TB/s 的高聚合 I/O 双向带宽和可预测的通信时序。这对于分布式推理流水线尤其重要，否则通信开销可能成为延迟的主要来源。
确定性的、由编译器编排的执行
LPU 建立在 Groq 的空间执行模型之上，在该模型中，编译器会显式调度计算、数据移动和同步。编译器不依赖运行时的动态硬件调度器，而是依靠硬件中的近同步芯片间协议来抵消自然时钟漂移，并使数百个 LPU 加速器对齐，从而像一个协调一致的系统一样运行。借助可预测的数据到达和周期性的软件同步，开发者可以更直接地理解时序，系统也能以更高的确定性协调计算和网络行为。
这种执行模型能够实现：
- 内存与计算之间的精确协调。
- 对指令时序的显式控制。
- 在可变工作负载下减少执行抖动
对于实时推理，这种确定性有助于保持首个 token 时间和每个 token 延迟的稳定，即使在小批量大小下也是如此。
向交互式推理的转变
AI 推理涵盖广泛的性能范围。一端是以吞吐量优化的服务，例如批量文档处理、审核、嵌入和媒体流水线，其目标是最大化每个 GPU 的 token 数、每瓦 token 数或整体成本效率。这些工作负载通常支持大规模共享服务，包括免费层级和后台 AI 产品，在这些场景中，高利用率比单个用户的响应速度更重要。
另一端是针对低延迟优化的服务，例如编码助手、聊天机器人、语音助手、副驾驶和交互式智能体，在这些场景中，延迟会立即被用户察觉。对于这些工作负载，最重要的指标是首个 token 延迟、每用户每秒 token 数以及尾延迟。许多现代 AI 平台必须同时支持这两种模式：既要运行用于大规模处理的高吞吐量后端，又要提供响应迅速的交互式体验。这种分化是异构推理架构变得越来越重要的原因之一。
是什么让交互式推理更加困难
如表 3 所示，若干趋势正在使低延迟交互式推理变得更加重要，同时也更难以高效提供服务。随着模型生成更长的输出、上下文窗口不断增大，更多工作负载转移到解码阶段；在该阶段，token 是按顺序生成的，响应速度会直接暴露给用户。
与此同时，更长的上下文增加了内存带宽和数据移动的压力，而服务大量并发用户会降低以吞吐量为导向的系统所依赖的批处理效率。因此，针对最大总体吞吐量优化的系统，并不总是最适合那些要求每个请求都能快速、可预测地生成 token 的工作负载。
在智能体 AI 中，这一挑战变得更加突出，因为系统会在推理、检索、工具使用和推理思考之间反复循环。在这些循环中，延迟会在每一步累积，使得稳定的每 token 性能和强大的尾延迟表现对于响应迅速的用户体验至关重要。
智能体推理时代需要一种新的架构
推理并不是一种单一、统一的工作负载。在一个请求内部，预填充和解码对硬件提出不同要求，而这些要求会随着批大小、上下文长度和模型结构而变化。某些阶段，包括自注意力和稀疏 MoE，可能会对内存带宽和数据移动高度敏感；而其他阶段，如密集投影和前馈层，在有足够并行度时，能够在针对吞吐量优化的硬件上高效扩展。在交互式解码中，许多操作以非常小的批大小运行，使得延迟对停顿、争用和抖动更加敏感。
仅针对一种运行模式优化整个流水线会迫使系统做出折中。针对大批量下峰值吞吐量调优的硬件，并不适合对延迟最敏感的执行路径；而针对低延迟执行优化的硬件，在计算最密集的阶段效率较低。
如图 4 所示，异构系统结合了这两种方法，将低延迟的交互性能与高 AI 工厂吞吐量配对。其结果是一种双引擎架构：GPU 为上下文密集型的预填充提供高输出，并执行解码注意力；而 LPU 则加速对延迟敏感的解码组件，例如 FFN/MoE 执行。二者协同，在不牺牲 AI 工厂吞吐量的情况下提升交互性。
正文：Vera Rubin NVL72 meets LPX
现代推理就像一场接力赛。运行繁重上下文阶段的同一硬件，并不需要继续承担冲刺生成下一个 token 的任务。Rubin GPU 是用于训练和推理的灵活通用主力。它们能够在多种模型规模、批处理模式和服务形态下提供高吞吐量，覆盖从长上下文预填充到解码注意力，以及大规模高并发推理等场景。
LPX 增加了一条专用路径，针对快速、延迟敏感的 token 生成进行了优化。二者结合，可实现一种异构推理设计，在不牺牲系统级效率的同时提升交互响应速度。
解码阶段：重复的多引擎循环
预填充阶段主要由摄取大型输入并构建 KV 缓存所主导——这类工作负载受益于密集并行计算和大容量内存。Vera Rubin NVL72 能高效处理这一阶段，尤其适用于长上下文工作负载和 MoE 模型，在这些场景中上下文可能很大且高度可变。
解码阶段则不同。解码是一个逐 token 重复的循环，而该循环的不同部分会对不同瓶颈施加压力。在搭载 LPX 的 Vera Rubin 平台架构中，解码最好被理解为一个双引擎循环。GPU 负责最能受益于高吞吐量和大容量内存的解码工作，例如基于累积 KV 缓存的全上下文注意力。LPX 加速解码中对延迟敏感的执行，例如稀疏 MoE 专家前馈网络（FFN）以及其他逐点操作。这种拆分通常被称为解码阶段解耦或注意力–FFN 解耦（AFD），它在解码过程中将注意力与 FFN 分离，并为每个 token 交换中间激活值，因此每个引擎都运行其最适合执行的循环部分。这个 AFD 循环扩展了帕累托前沿中价值最高的运行区域。
在机架规模及更大规模下，LPX 旨在作为一个紧密协调的计算单元运行，最大限度地降低协调开销并减少抖动。这对于解码密集型、智能体式工作流很有价值，因为在这些工作流中，微小延迟会在多次模型调用和验证循环中不断累积。
NVIDIA Dynamo 让异构解码具备可操作性
要让异构解码切实可行，需要软件能够对请求进行分类，按延迟目标路由工作，以低开销移动中间激活，并在突发且多变的流量下保持尾延迟稳定。NVIDIA Dynamo 通过协调异构后端上的解耦式服务和解耦式解码，提供了这一编排层。
在实践中，Dynamo 将预填充路由到 GPU 工作节点，以处理大上下文并构建 KV 缓存。在解码期间，Dynamo 编排 AFD 循环：GPU 对累积的 KV 缓存执行注意力计算，中间激活被交接给 LPU 执行 FFN/MoE，输出再返回 GPU 以继续生成 token。其结果是一条单一且连贯的服务路径，在维持高 AI 工厂吞吐量的同时，实现更可预测的尾延迟。
通过 KV 感知路由、低开销传输以及以延迟目标驱动的调度，Dynamo 有助于让交互式会话避开长队列，减少跨租户抖动，并在并发量和请求形态变化时保持稳定的尾部延迟。其结果是一种可用于生产的异构服务模型，能够在大规模维持高 AI 工厂吞吐量的同时，提供响应迅速的用户体验。
使用 LPX 加速推测解码
推测解码是降低 LLM 推理延迟的一项日益重要的技术。该方法使用较小的草稿模型提前生成多个候选 token，同时由较大的目标模型并行验证并接受这些 token。当预测匹配时，可以一次性提交多个 token，从而显著提高每秒有效 token 数并降低响应延迟。
LPX 非常适合在这种架构中充当草稿生成引擎。LPU 的确定性执行模型和极高的片上 SRAM 带宽能够实现非常快速的草稿 token 生成，使草稿模型能够领先于验证器运行。与此同时，Rubin 等 GPU 在大模型执行任务方面仍然非常高效，例如预填充、注意力处理和 token 验证。
通过将二者配对，该系统结合了两种处理器的优势：
- LPX 利用其低延迟架构快速生成草稿 token。
- Rubin GPU 利用高吞吐量计算和大内存容量高效验证并最终确定 token。
这种分离使推测解码能够在异构处理器之间运行，而不是在同一硬件上同时运行草稿模型和验证器模型。其结果是一个能够提供更快草稿生成、同时不牺牲基于 GPU 的验证效率的系统。
释放智能代理群体的潜力
随着 AI 用例从简单聊天和批量推理演进为多步骤代理式工作流，响应能力成为一项要求。离线推理和基础助手通常可以优先考虑总体吞吐量，但交互式应用、深度研究和代理式流水线将高 token 量与紧密反馈循环结合在一起，在这些场景中，延迟会在大量模型调用和工具交互中不断累积。
在这种模式下，异构推理至关重要。将用于长上下文处理的高吞吐量引擎与用于解码 FFN 的低延迟引擎相结合，可以在不牺牲 AI 工厂产出的情况下提升用户交互性。
在 Pareto frontier 上解锁一类新的 AI 体验
可视化这种性能与成本之间权衡的一种实用方法是 Pareto frontier，即将用户交互性（以每用户每秒 token 数（TPS per user）衡量）绘制在横轴上，将 AI 工厂吞吐量（以每兆瓦每秒 token 数（TPS per MW）衡量）绘制在纵轴上。
如图 10 所示，不同的 AI 服务在这条曲线上的运行点差异很大。以吞吐量优先的服务，包括许多免费层级和后台工作负载，通常优先考虑最高效率和高利用率，并且往往使用上下文窗口较短的小型模型。相比之下，高端 AI 服务需要更高的模型能力，以及响应速度快得多、用户可感知的性能，尤其是在长上下文推理和智能体工作流方面。在图 10 中，该高端层级由一个 2 万亿参数的 MoE 模型表示，其输入上下文窗口为 400K，以每位用户约 400 TPS 及以上的速度运行。
使用单一同构平台达到这些高端运行点，会迫使响应能力与整体 AI 工厂吞吐量之间做出权衡，因为工作负载在同一服务流水线中混合了本质上不同的性能区间。异构架构通过结合互补的执行路径，扩展了可实现的区域，使系统能够在维持较高工厂产出的同时，提供响应高度灵敏、低延迟的交互式体验。A
