存储评论网

NVIDIA Groq 3 LPX:我们所知道的一切

AI  ◇  企业版

LPU(语言处理单元)是由 Groq 公司设计和构建的定制化 AI 推理加速器。Groq 由前谷歌工程师 Jonathan Ross 于 2016 年创立,他也是 TPU 的最初发明者之一。Groq 花费数年时间从零开始开发了一种确定性的软件定义处理器架构。与依赖动态硬件调度和多级缓存层次结构的 GPU 不同,LPU 采用了一种截然不同的方法:它消除了所有被动式硬件组件,并将整个控制平面置于编译器中,从而实现了精确到时钟周期的完全可预测执行。

NVIDIA Groq 3 LPX

去年12月,NVIDIA收购了Groq,将LPU架构纳入旗下。此次收购在业内引起了广泛关注,并立即引发了人们对NVIDIA将如何把Groq的技术整合到其数据中心生态系统中的猜测。这些问题最终在GTC 2026大会上得到了解答。NVIDIA在会上发布了Groq 3 LPX,作为Vera Rubin平台的第七款芯片,它将256个LPU加速器与Vera Rubin NVL72集成在一个机架级系统中。

CPX发生了什么事?

去年在人工智能基础设施峰会上,NVIDIA 还发布了 CPX 机架,并推出了几种配置,旨在加速长上下文推理查询。在我们最初报道该消息后,我们对 CPX 的实际功能产生了一些疑问。乍一看,尽管其架构概念很有趣,但除了可能对注意力机制进行额外加速之外,CPX 似乎并没有提供任何实质性的功能,而这些功能与 Rubin GPU 本身并无太大区别。随后,NVIDIA 收购了 Groq,这引发了人们对 NVIDIA 将如何把 Groq 的 LPU 技术整合到更广泛的 Vera Rubin 平台中的猜测。

在2026年GTC大会上,NVIDIA发布了LPX,澄清了之前的种种疑虑。从目前展示的内容来看,CPX机架的概念已经演变为Groq 3 LPX机架,原CPX侧重于上下文处理的架构被基于Groq芯片构建的全新解码加速架构所取代。LPX机架采用全液冷设计,基于MGX架构,将于2026年下半年上市,与Vera Rubin的全面推广同步进行。NVIDIA声称,这款新产品每兆瓦的推理吞吐量可提升高达35倍,并且在处理万亿参数模型时,可带来高达10倍的额外收益机会。

但更重要的是,NVIDIA 确认 LPU 作为加速器运行在 Vera 和 NVL72 平台上的现有 CUDA 堆栈中,能够以透明的方式按令牌卸载计算任务。在 GTC 问答环节,NVIDIA 将 LPU 描述为“解码模型加速器”,并解释说他们将与人工智能实验室和前沿模型构建者紧密合作,部署万亿参数模型,以实现下一代高端模型服务。

CPX 问题解决了,接下来自然会问:NVIDIA 围绕 LPU 构建的整个机架级系统究竟是什么?

什么是LPU?

LPU 的核心是一个非常大的向量处理器。其计算和通信的基本单元是一个 320 元素的向量,其中 INT8 为 320 字节,FP16 为 640 字节。芯片上的所有操作,无论是算术运算、内存访问、数据重塑还是芯片间数据传输,都基于这些固定大小的向量。

资料来源:Nvidia

该架构由一个基础构建模块构成:一个 SIMD 功能单元和一个轻量级指令分发单元。Groq 将其视为一个基类,并将其细分为四种不同的类型,每种类型都针对特定类别的操作进行了优化:

矩阵执行模块(MXM): 作为主要的计算主力,它为矩阵向量和矩阵矩阵运算提供密集的乘加能力。NVIDIA LPX 机架中的 8 个 Groq 3 LP30 芯片,每个芯片可提供 1.2 PFLOPS 的 FP8 计算能力,每个 LPX 托架总共可提供 9.6 PFLOPS 的 FP8 计算能力。

向量执行模块(VXM): 处理逐点算术运算、逻辑运算、类型转换和激活函数。VXM 包含一个 ALU 数组,编译器会自动将这些 ALU 链接起来,在一次编译过程中形成复合运算(例如,先进行归约运算,然后进行偏置加法运算,接着进行激活运算,最后进行类型转换)。

交换机执行模块(SXM): 执行结构化数据移动,包括向量的排列、旋转、分布和转置。

存储单元(MEM): Groq 3 LP30 是一款扁平化的、以 SRAM 为先的内存架构,没有缓存、没有层级结构,也没有缓存未命中的概念。它提供 500 MB 的片上 SRAM,带宽高达 150 TB/s。编译器直接寻址物理存储体位置,在程序执行过程中始终掌握所有数据的精确位置。

芯片水平方向上印制了多种功能单元。指令从上到下流向中间,数据流从东到西流动,与各个功能单元相交以执行操作。

一维互连、流寄存器和确定性

流寄存器和一维互连

LPU 上各功能单元之间的通信通过流寄存器实现,这是一种设计简洁的一维互连方式。通信路径分为两条,一条向东,一条向西,每个流寄存器代表一次传输。数据在每个时钟周期内精确地传输一次,这意味着编译器可以根据两个功能单元在芯片布局上的物理位置,通过简单的加减运算来推断它们之间的传输时间。

互连网络中不存在队列和争用机制。这使得调度问题从复杂的二维装箱问题简化为更易于处理的一维问题。 Groq 的首席架构师 Igor Arsovski 是这样描述的: 最佳方案:编译器能够精确地知道一段数据在 10 个时钟周期后的位置,因为它正好经过 10 跳。这样就不存在任何歧义、猜测,也不需要硬件进行独立的路由决策。

确定性

LPU 的显著特征是确定性。与传统处理器不同,传统处理器的动态调度、缓存行为和内存访问争用会引入运行时差异,而 LPU 的执行没有差异,每个功能单元都同步运行。

这种确定性是通过移除硬件互锁等机制并将所有决策过程移至编译器来实现的;硬件只需执行最终生成的调度方案。这种方法的其他优点包括:所有操作的延迟完全相同,甚至功耗在任何时刻都是可预测的。

确定性也通过 Groq 称之为 TruePoint 的技术扩展到了数值领域。该技术通过保证运算顺序,利用 320 元素融合点积(仅需一次舍入)即可从 FP16 输入获得 FP32 级别的精度。Thinking Lab 的白皮书深入探讨了数值确定性对于 LLM 推理的重要性,以及非确定性硬件为何会在每次运行中产生略有不同的输出。 “克服LLM推理中的非决定论”这不是本文的重点,但对数值精度的影响感兴趣的读者可以在 Groq 的 TruePoint 技术文档中找到相关的分析,链接在文末。

LPU 的连接方式:RealScale、装配线和机架拓扑

数据流水线:数据如何流动

从最简单的层面来说,LPU 之间的数据传输就像一条装配线。当系统编译模型时,编译器会将模型划分为多个阶段,并将每个阶段映射到一组 LPU 芯片上。每组芯片将所需的权重参数存储在本地片上 SRAM 中。在推理过程中,芯片组之间传输的唯一数据是来自前一阶段的中间激活输出。数据像产品沿着传送带移动一样在芯片间流动,每个工作站执行其分配的计算并将结果传递给下一个工作站。这与 GPU 有着本质的区别,GPU 的每个计算阶段都需要从片外 HBM 内存中检索完整的权重集并将结果写回。而在 LPU 上,权重已经驻留在每个工作站的 SRAM 中;只有激活张量会移动。

关于 C2C 链接的说明:RealScale,而非 NVIDIA C2C

在深入探讨拓扑结构细节之前,有必要澄清一个可能造成混淆的地方。LPX 系统中使用的芯片间 (C2C) 链路是 Groq 的 RealScale C2C 互连技术。这与 NVIDIA 生态系统中其他产品使用的 NVIDIA C2C 技术不同。这两种技术在架构上截然不同:

  • NVIDIA C2C 是一种缓存一致性互连技术,旨在连接紧密耦合模块中的两种不同类型的芯片,例如 CPU 到 GPU 的连接。它采用具有高速 SerDes 的一致性协议,专为单个封装或模块内的异构芯片间通信而设计。
  • Groq RealScale C2C 是一种软件调度、确定性的点对点互连协议。网络链路由编译器显式地进行流控制,并像 MXM 或 VXM 计算单元一样作为一级功能单元进行调度。它不涉及硬件仲裁或自适应路由,数据包也不携带源地址或目标地址头部。链路相位对齐,如同芯片间高带宽、固定延迟的线路。准同步协议能够确定性地处理芯片间的自然时钟漂移,从而为编译器提供整个网络的单一公共时间域。

LPX机架中的所有C2C连接,无论是在托盘内、通过主干网跨托盘连接,还是通过前面板端口在机架间连接,都采用RealScale技术。这是Groq自初代GroqNode以来一直使用的基本互连技术,链路速度有所提升(从每通道30 Gbps提升至112 Gbps),但架构保持不变。

注:下一节对连接性的解释是基于我们对 Groq 文档(链接在文末)中架构的理解。 NVIDIA 的博客文章以及我们在GTC展位上得到的关于该机架的说明:

  • LPX机架单元使用的C2C链路是Groq的技术,与NVIDIA其他机架级系统中使用的C2C链路不同。
  • 每个LPX机架单元前端的4个C2C链路用于连接同一层相邻的机架单元。
  • 在机架内部,LPU 之间实现全对全通信。
  • LPX机架中的处理器是x86架构的。

托盘内连接

从最初的 GroqNode 到 NVIDIA Groq 3 LPX,Groq 网络拓扑的基本构建模块没有改变。每个 1U 计算托架都包含恰好八个 LP30 芯片,它们以完全互连图(全对全)的形式紧密连接,其中每个芯片都可以以相同的速率与其他每个芯片直接通信。

资料来源:Nvidia

每个 LP30 芯片拥有 96 条 C2​​C 链路,每条链路的运行速度为 112 Gbps,每个芯片可提供 2.5 TB/s 的双向带宽。在一个包含 8 个芯片的完整网络中,每个芯片有 7 个相邻芯片。一个托架内唯一的芯片间连接数量为 C(8,2) = 28。每个芯片的 96 条链路中,一部分专用于这些托架内的全连接,其余链路则路由至背板(用于机架主干)和前面板(用于机架间连接)。NVIDIA 公布的规格书显示,每个托架的总扩展带宽为 20 TB/s,这代表了托架内带宽和主干带宽的总和。我们可以验证这一点:每个托架共有 8 个芯片 × 96 条链路 = 768 条链路。减去 32 条前面板机架间通道后,剩余 736 条链路可用于扩展。单链路速度为 112 Gbps,则总速度为 736 × 112 Gbps = 82,432 Gbps,约合单向 10.3 TB/s,双向速度约为 20.6 TB/s。这与 NVIDIA 宣称的每托架 20 TB/s 的速度基本吻合。

这8芯片全连接组构成了蜻蜓网络拓扑的“本地组”。初代GroqChip 1每张卡有11条C2C链路,每条链路每通道30 Gbps(每条链路4条通道),每张卡总带宽为330 GB/s。Groq 3 LP30的96条链路,每条链路带宽高达112 Gbps,在保持相同拓扑结构的同时,实现了单芯片I/O带宽的巨大飞跃。

机架内连接

在单个 LPX 机架内,32 个计算托架(共 256 个芯片)通过背板上的四个 ETL 主干互连。这些主干承载托架间的 RealScale C2C 流量,从而构建机架级纵向扩展域。整个机架的总纵向扩展带宽为 640 TB/s(32 个托架 × 每个托架 20 TB/s)。四个主干分配到每个主干上,每个主干承载约 160 TB/s 的双向带宽。

机架间连接

每个 1U 计算托架的前面板都提供四个 QSFP C2C 端口,总共提供 32 条通道(每个端口 8 条通道)用于机架间通信。这些端口以对称模式连接到相邻机架:两个端口(16 条通道)连接到左侧相邻机架,两个端口(16 条通道)连接到右侧相邻机架。每个 U 位置都连接到相邻机架中对应的 U 位置(机架 A 的第一个 U 连接到机架 B 的第一个 U,第二个 U 连接到机架 B 的第二个 U,依此类推)。

资料来源:Nvidia

每个托盘每通道带宽为 112 Gbps,因此每个托盘的 32 条机架间通道可提供 32 × 112 Gbps = 3,584 Gbps 的机架间带宽,即每个托盘每个方向约 448 GB/s。整个机架的 32 个托盘共提供 32 × 32 = 1,024 条机架间通道。这相当于 1,024 × 112 Gbps = 114,688 Gbps,即每个相邻机架每个方向约 14.3 TB/s 的带宽(左右各占约 7.2 TB/s)。

这种机架间带宽的设计使其比机架内带宽更为稀疏。在机架内部,640 TB/s 的扩展域通过主干网提供密集的、全连接可达性。机架间,前面板链路提供蜻蜓拓扑结构中较为稀疏的全局连接。这与最初的 GroqRack 架构模式相同,其中每个芯片的四个外部 C2C 链路连接本地组(节点),形成网络直径较小的多机架系统(在 264 芯片部署中最多三跳)。

整合:相同的架构,4倍的密度

最初的四机架 GroqRack 部署方案包含 264 个 GroqChip 处理器。单个 LPX 机架将 256 个 LP30 芯片集成到一个 MGX ETL 机架中,芯片密度约为原来的四倍,并采用液冷和无电缆背板设计。8 芯片全连接本地组、蜻蜓拓扑结构和软件调度路由模式均得以完整保留。Groq 的基本网络技术并未改变,只是进行了扩展。

对于 SRAM 容量超过单个机架(256 个芯片共 128 GB)的型号,可以通过前面板的 C2C 端口互连多个 LPX 机架或多排机架,从而进一步延长生产线。下一节将详细介绍这对于实际型号尺寸的影响。

为什么需要 FFN 层?了解 NVIDIA 正在卸载什么

为什么解码服务越来越难提供?

在深入探讨NVIDIA将哪些任务卸载到LPX以及原因之前,了解NVIDIA所指出的促成这一架构决策的更广泛趋势至关重要。AI推理并非单一的、统一的工作负载。在单个请求中,预填充阶段(接收提示信息并构建键值缓存)和解码阶段(逐个生成令牌)对硬件的要求截然不同,而且这些要求会随着批处理大小、上下文长度和模型结构的变化而变化。

随着模型生成更长的推理输出和多步骤的思维链,每个请求中越来越多的时间会流向顺序解码阶段。与此同时,诸如前缀缓存之类的技术通过在请求间重用共享的提示状态来降低预填充的成本,这反而使解码的相对成本更加突出。上下文窗口也增长到数十万个令牌,给注意力计算期间的内存带宽带来了越来越大的压力。在智能体工作流程中,延迟会在多次模型调用、工具交互和验证循环中累积。这些累积效应导致解码延迟日益成为用户感受到的瓶颈,而仅仅针对最大总吞吐量优化的硬件并不总是最适合需要为每个请求快速、可预测地生成令牌的工作负载。

此外,正如我们所看到的 人为因素的快速模式 发布、更低的延迟和更高的代币吞吐量确实能带来更高的收入,Anthropic 的快速推理服务成本是普通请求的 6 倍。

通过此次 LPX 的发布,我们了解到 NVIDIA 希望将最大的解码瓶颈——前馈网络 (FFN) 层——转移到 LPU 上。为了理解为何 FFN 层是目标,并体会其意义之重大,我们分析了目前最流行的开源模型的 FFN 参数数量。

FFN层是​​什么?为什么它们占据主导地位?

每个Transformer层都包含两个主要模块:注意力模块和前馈神经网络(FFN)模块。注意力模块允许每个词元查看并混合序列中其他词元的信息。FFN模块则独立地处理每个词元:它将词元的表示投影到更高维度的空间,应用非线性变换,然后再投影回低维空间。你可以把它想象成模型的知识库,其中存储着事实关联和学习到的变换。

混合专家架构 (MoE) 已成为当今领先的开源大型语言模型中的主导架构,例如 DeepSeek R1、Kimi K2、Qwen3-235B、GLM-5、MiniMax M2.5 和 OpenAI 的 GPT-OSS 120B。

在这些 MoE 模型中,FFN 模块会被复制成数百个更小的独立副本,称为专家,而注意力机制则保持共享。一个轻量级的学习路由函数会动态地选择一小部分专家,并根据每个 token 的值进行激活。最终得到的模型虽然存储了庞大的参数总数,但每个 token 只激活其中一小部分,从而在不增加相应计算成本的情况下,获得了规模效应带来的质量提升。

然而,正如您所意识到的,这带来了另一个挑战:FFN 层占据了模型的大部分权重。特别是对于 MoE 模型,这甚至可以占到模型权重的 90%。

DeepSeek R1 内部构造:一个实际示例

为了便于说明,我们放大来看 DeepSeek R1。该模型有 61 个 Transformer 层,隐藏维度 (H) 为 7,168。前 3 层使用标准的密集前馈神经网络 (FFN),其余 58 层使用 MoE(外加 1 个带有自身专家的 MTP 层,总共 59 个 MoE 层)。现代 LLM 使用一种名为 SwiGLU 的变体,它使用三个权重矩阵而不是两个。前向传播计算 w2(SiLU(w1(x)) ⊙ w3(x)),其中 w1(门控投影)和 w3(上投影)都将隐藏维度从 H 扩展到中间大小 I,而 w2(下投影)将其压缩回去。⊙ 表示门控路径和非门控路径之间的元素级乘法。这些矩阵都没有偏置项,因此每个 SwiGLU FFN 块恰好包含 3 × H × I 个参数。

来源:塞巴斯蒂安·拉什卡

对于 DeepSeek R1 的密集层(前三层),中间维度为 18,432,因此每层有 3 × 7,168 × 18,432 = 396.4 亿个参数。对于 MoE 层,256 个路由专家中的每一个都是一个完整的 SwiGLU 块,其中间维度较小,为 2,048,因此每个专家有 3 × 7,168 × 2,048 = 4,400 万个参数。乘以 256 个专家,每层仅路由专家就有 11.27 亿个参数。此外,每个 MoE 层还有一个共享专家(相同的 4,400 万参数的 SwiGLU 块,始终对每个 token 激活)、一个路由门(形状为 [256, 7168] = 180 万个参数的线性投影)以及一个包含 256 个 FP32 值的小型偏置向量,用于路由期间的负载均衡。

完整的 FFN 模型大约有 669.1 亿个参数。采用 FP8 E4M3 格式(每个权重 1 字节),这相当于大约 623.1 GB 的 FFN 数据。这占模型在磁盘上估计总大小的 97.7%。剩余的约 2.3% 是注意力权重、嵌入、输出头、层范数和 FP8 尺度元数据。

解码分解

NVIDIA 现在将解码阶段不再视为单一操作,而是视为一个重复的逐词循环,其中不同的部分会分别考验不同的硬件瓶颈。预填充阶段主要涉及接收大量输入和构建键值缓存,这种工作负载受益于密集并行计算和大容量内存。Vera Rubin NVL72 能够高效地处理这些任务,尤其适用于提示信息量巨大且变化极大的长上下文工作负载。

资料来源:Nvidia

解码过程有所不同。对于每个新词元,系统必须对整个累积的键值缓存执行注意力机制,然后对注意力输出运行 FFN/MoE 计算。在 NVIDIA 的注意力-FFN 解耦 (AFD) 架构中,这两个步骤被分配到两个引擎上。Rubin GPU 负责解码注意力:从 HBM 读取键值缓存,计算注意力分数,并生成中间激活值。该激活张量(NVIDIA 称之为“中间张量状态”)随后被传递给 LPX,LPX 以极高的带宽和确定性的延迟运行 FFN 或 MoE 专家计算,然后将结果返回给 GPU 以继续生成词元。

每个令牌都会进行这种交接。GPU 和 LPU 之间交换的激活张量相对于权重数据而言很小,而这正是 LPU 近乎零开销网络优势的体现。这种分配方式充分发挥了每个处理器的核心优势:GPU 提供 HBM 容量和灵活的执行能力,以支持在大型键值缓存上实现可变长度注意力机制;而 LPU 提供 SRAM 带宽和确定性调度能力,以支持带宽受限、静态可调度的 FFN 权重。

资料来源:Nvidia

这里有一个微妙但重要的扩展特性值得一提。随着上下文长度的增长,注意力机制的计算和内存需求也会随之增长:键值缓存会随着上下文数量的增加而线性扩展,并且每个新的解码步骤都必须访问整个缓存。然而,前馈神经网络(FFN)的计算和内存需求却不会随着上下文长度的增长而增长。FFN 的权重矩阵(在 SwiGLU 中为 w1、w2 和 w3)是模型架构的固定常数。无论上下文是 1,000 个词元还是 1,000,000 万个词元,它们的大小都相同,并且每个词元都会独立地经过这些权重矩阵。这意味着在 AFD 架构中,随着上下文窗口的不断增长,GPU 端会承担不断增加的成本(用于 KV 缓存的更多 HBM,以及用于注意力机制的更多计算),而 LPX 端则完全保持不变。服务于模型 FFN 所需的 LPX 机架数量完全由模型的架构决定,而不是由服务配置的上下文长度决定。这巧妙地解决了长期以来纯SRAM加速器面临的最大挑战之一:不断增长的上下文需求最终会超过片上固定的内存容量。在AFD分离架构中,上下文相关的工作保留在具有可扩展HBM的硬件上,而LPU则只处理那些自然适合存储在固定SRAM中的上下文无关工作。

NVIDIA Dynamo 使异构解码得以运行

要让这种双引擎循环在生产环境中正常运行,需要的不仅仅是硬件。NVIDIA 的 Dynamo 编排层才是异构解码得以实现的关键。Dynamo 负责协调 GPU 和 LPU 后端之间的解耦服务,处理 AFD 所需的每个令牌的分类、路由和激活传输。

资料来源:Nvidia

在实际应用中,Dynamo 将预填充数据路由到 GPU 工作节点来处理输入并构建键值缓存。在解码过程中,Dynamo 会协调 AFD 循环:GPU 对累积的键值缓存进行注意力机制处理,中间激活信息被移交给 LPU 执行 FFN/MoE 指令,输出返回给 GPU 继续生成令牌。最终形成一个统一的服务路径,而不是两个互不相连的系统。

Dynamo 还提供键值感知路由(确保请求到达已驻留相关键值缓存的工作节点)、延迟目标驱动调度(避免交互式会话长时间排队)以及低开销传输管理。这些功能至关重要,因为在实际生产环境中,面对可变上下文长度、混合请求类型和突发并发等复杂情况,编排层能够保持尾延迟稳定,防止跨租户抖动影响用户体验。

FFN 尺寸适用于所有主流开源模型和 LPX 尺寸

现在我们已经了解了LPX的工作原理以及它试图解决的问题,接下来让我们看看它对硬件的要求。

我们使用以下方法计算了常用模型的参数数量和磁盘上的 FFN 大小: 配置文件model.safetensors.index.json 可在 Huggingface 上观看。

型号 FFN 参数 FFN 大小(磁盘上) FFN% 类型 业内专家
DeepSeek R1 和 DeepSeek V3.2 669.1B 623.1 GB 97.7% FP8 256
基米 K2 1.02T 948.0 GB 98.9% FP8 384
基米 K2.5 1.02T 474.0 GB 98.5% INT4 384
MiniMax M2.5 224.7B 209.3 GB 97.7% FP8 256
OpenAI GPT-OSS 120B 114.7B 53.4 GB 95.4% MXFP4 128
GLM 5 738.1B 1,374.8 GB 98.0% BF16 256
Qwen3 235B-A22B 227.2B 423.1 GB 96.6% BF16 128

这一模式证实了我们之前的探索:在本次分析的所有模型中,前馈神经网络(FFN)参数占磁盘总模型大小的95%到99%。Kimi K2是最极端的例子,每层384个路由专家,使得FFN参数超过1万亿个,几乎占总参数的99%。即使是数据集中最小的模型,OpenAI的GPT-OSS 120B(128个专家存储在MXFP4格式中),其FFN参数也占总参数的95.4%。磁盘占用空间从GPT-OSS 120B的53 GB(得益于4位量化)到GLM 5的近1.4 TB(存储在BF16格式中,未进行量化)不等。

这些数据有助于我们了解 LPX 的容量。单个 LPX 机架包含 256 个芯片,总共提供 128 GB 的 SRAM。对于像 OpenAI 的 GPT-OSS 120B 这样占用 53 GB FFN 内存的模型,其 FFN 权重可以轻松装入单个机架,并且还有剩余空间。DeepSeek R1 占用 623 GB 内存,大约需要五个 LPX 机架;而 GLM 5 占用 1.4 TB 内存(采用 BF16 编码),则需要十个以上的机架(不过,如果量化为 FP8,则所需空间将减少近一半)。这正是机架间前面板 C2C 端口的必要性所在:它们允许将多个 LPX 机架串联起来,从而扩展生产线以容纳更大的模型。

利用 LPX 加速推测性解码

除了 AFD 解码循环之外,NVIDIA 还确定了 LPX 的第二个主要用途:作为推测性解码中的草稿生成引擎。

推测解码是降低 LLM 推理延迟的一种日益重要的技术。其原理很简单:一个更小、更快的草稿模型预先生成多个候选词元,而一个更大的目标模型并行地验证并接受这些候选词元。当草稿模型的预测正确时(对于常规文本来说,预测通常是正确的),可以在单个验证步骤中一次性提交多个词元。最终结果是每秒有效词元数显著提高,并且最终用户感知到的延迟也更低。

资料来源:Nvidia

挑战在于,推测性解码要求草稿模型运行速度极快。草稿模型生成候选解的每一毫秒,验证器就需要等待一毫秒。在传统的纯GPU架构中,草稿模型和目标模型会争用相同的硬件资源,而草稿模型的速度也受到与其他所有组件相同的HBM带宽限制。

LPX 非常适合此用途。其确定性执行模型和 LP30 的超高片上 SRAM 带宽,能够实现快速且可预测的草稿令牌生成。较小的草稿模型可以轻松装入单个 LPX 托架或少量托架的 SRAM 中,而确定性调度则确保草稿生成以一致且可预测的速度运行,避免了因速度波动而导致的与验证器流水线集成困难。

在这种配置下,系统将两个处理器配对,发挥互补作用:LPX 利用其低延迟架构快速生成草稿令牌,而 Rubin GPU 则利用其高吞吐量计算能力和大容量 HBM 高效地验证和最终确定令牌。这种分离使得推测性解码能够在异构处理器上运行,而无需两个模型共享单个 GPU,与同构配置相比,这有可能提高草稿速度和验证吞吐量。

NVIDIA 已将推测性解码与 AFD 一起列为 LPX 的关键工作负载,这表明他们认为这是该系统价值主张的重要组成部分。随着前沿模型的不断发展和推理链的延长,在专用硬件上并行生成和验证令牌的能力可能成为保持交互响应能力的重要手段。

总结:极致的软硬件协同设计

NVIDIA Vera Rubin平台和LPX最突出的特点之一,就是每个组件的精准定位。在消费领域,我们经常会遇到一些产品,它们试图解决一些根本不存在的问题,而这些产品背后的公司对客户的需求缺乏深刻的理解。NVIDIA的策略则截然不同。他们显然对推理流程中的问题有着极其细致的理解,并针对流程的每个环节进行优化,以帮助客户最大限度地提高硬件收益。

注意力/FFN分离并非营销概念,而是针对万亿参数MoE模型服务瓶颈问题的直接应对措施。决定专门卸载FFN(而非注意力),并将CPX机架升级为LPX机架,体现了对哪些操作受带宽限制、哪些受容量限制、哪些可静态调度、哪些可动态调度以及哪种处理器架构最适合每种操作的精准理解。Dynamo编排层、透明的CUDA集成以及无线MGX机架设计,都表明工程团队已对整个部署生命周期进行了周全的考虑。

LPX 和 NVIDIA 的新一代产品仍存在诸多未知之处。其中一个悬而未决的问题是,“Fabric Expansion Logic and DRAM”的用途是什么?它使用了哪种硅芯片?许多人已经注意到 x86 插槽,考虑到去年对英特尔的投资以及散热器固定设计,很可能使用的是英特尔处理器,但具体是哪一款仍然是个谜。

LPX部署初期将重点关注模型构建者和服务提供商,而非全面覆盖。其在生产流量模式下的实际性能,包括可变上下文长度、混合请求类型和突发并发等情况,以及能效表现,仍需进行独立验证。我们期待获得这些系统的访问权限,以便进行独立测试。

引用来源:

Groq:什么是语言处理单元?

Groq:Groq LPU 采用 AI 推理技术,可实现更高的能源效率……

Groq:RealScale芯片间互连技术

Groq:面向实时人工智能和高性能计算的低延迟解决方案

Groq:确定性和张量流处理器

Groq:TruePoint Technology

Groq:GroqNode 服务器

英伟达:深入了解英伟达 Groq 3 LPX… 

Aleksa Gordić – 人工智能顿悟:Groq LPU 的工作原理是什么?(特邀硅谷负责人 Igor Arsovski!)

阿贡国家实验室领导计算设施:ALCF人工智能测试平台训练:Groq语言处理单元LPU架构

DeepSeek:DeepSeek-V3 技术报告

Sebastian Raschka:从 DeepSeek V3 到 V3.2……

参与 StorageReview

资讯订阅 | YouTube | 播客 iTunes/Spotify | Instagram | Twitter(现为X) | TikTok | RSS订阅

迪维扬什·贾恩

机器学习工程师、家庭实验室爱好者和技术发烧友。在 Storage Review,我负责人工智能和新兴工作负载测试,旨在提供实用见解和性能分析。