"NVIDIA LPX" = NVIDIA Groq 3 LPX，是 NVIDIA 在 GTC 2026（2026 年 3 月）发布的机架级低延迟推理加速器，属于 Vera Rubin 平台。其底层芯片 LP30 基于被 NVIDIA 收购的 Groq 第三代 LPU（Tensor Streaming Processor, TSP）架构。[NVIDIA 技术博客]
关键含义：本报告比较的不是 GPU 与 TPU，而是两种非传统 GPU 的加速器架构——Google 的脉动阵列 MXU + HBM（Trillium） vs Groq 的确定性数据流 LPU + SRAM（LPX）。这让微架构对比格外有张力。
Trillium 与 LPX 并非直接竞品，而是对"不同问题"的两种回答：
两者在内存层级哲学、计算模型、确定性、规模范式、商业模式上根本性分叉，却殊途同归地走向推理解耦（prefill/decode、attention/FFN）这一共同趋势。
Trillium 是 Google 第六代 TPU，代号取自延龄草。官方在所有技术面（API、日志）以 v6e 指代。[Google Cloud 官方文档]
每颗 v6e 芯片含 1 个 TensorCore，每个 TensorCore 含：2 个矩阵乘单元（MXU） + 1 个向量单元 + 1 个标量单元，外加独立的 第三代 SparseCore。[官方文档]
"Each v6e chip contains one TensorCore. Each TensorCore has 2 matrix-multiply units (MXU), a vector unit, and a scalar unit." — Google Cloud Docs
The Next Platform 指出：前四代 TPU 的 MXU 均为 128×128，而 Trillium "enlarged the MXU"。他们推测 Google 回归了 TPU v1 的 256×256 并实现了高效双泵（double-pump）：[TNP]
"The Trillium chips have larger matrix multiply units (MXUs) than the ones used in the prior four generations, which use 128×128 matrices... The TPU v1 chips used a 256×256 matrix in its cores, and we think Google may have reverted to this format and figured out a way to double pump it efficiently."
这解释了官方文档"2 个 MXU"与部分二手源"4 个 MXU"的出入——若每个 MXU 从 128×128 升到 256×256（面积/算力 ~4×），则 2 个新 MXU ≈ 8 个旧 MXU 的算力，结合时钟提升得到相对 v5e（单 128×128 MXU）的 4.7× 峰值。918 TFLOPs ÷ 197 TFLOPs(v5e) ≈ 4.66×，与官方 4.7× 吻合。
SparseCore 自 TPU v4 引入，是面向超大规模 embedding（排序/推荐）的专用处理器——这正是 Google 搜索与广告业务的核心负载。[Google 博客]
"Trillium is equipped with third-generation SparseCore, a specialized accelerator for processing ultra-large embeddings common in advanced ranking and recommendation workloads."
模型设计者视角：这是 Trillium 区别于一切 GPU/LPU 的独门设计——现代推荐/检索增强模型（DLRM、双塔、MoE 的 embedding 表）的瓶颈恰是稀疏嵌入的不规则访存，而非稠密算力。SparseCore 用 ~5% 面积买 5-7×，是极高的面积 ROI。
| 指标 | TPU v6e (Trillium) 每芯片 |
|---|---|
| 峰值算力 BF16 | 918 TFLOPs |
| 峰值算力 Int8 | 1836 TOPs |
| HBM 容量 | 32 GB（较 v5e 翻倍） |
| HBM 带宽 | 1638 GB/s（较 v5e 翻倍） |
| ICI 双向带宽（每芯片） | 800 GB/s，4 端口 |
| 每主机 DRAM | 1536 GiB（v5e 的 3×） |
| 每主机芯片数 | 8 |
| 精度 | BF16、Int8（官方文档未列 FP8；部分分析称支持 FP8，待官方确认） |
| 特殊单元 | 第三代 SparseCore |
注：Google I/O 发布博客宣称"较 v5e 提升峰值算力 4.7×、HBM 容量与带宽翻倍、ICI 带宽翻倍、能效提升 >67%"。[发布博客]
单 Pod = 256 颗芯片，2D Torus 拓扑。[官方文档]
| Pod 级指标 | 值 |
|---|---|
| Pod 芯片数 | 256 |
| 拓扑 | 2D torus |
| BF16 峰值算力 | 234.9 PFLOPs |
| all-reduce 带宽 | 102.4 TB/s |
| 二分带宽 | 3.2 TB/s |
| 每主机 NIC | 4 × 200 Gbps |
| Pod DCN 带宽 | 25.6 Tbps |
"e" 变体（v5e/v6e）采用更小、更省的 256 芯片 2D torus；而 v4/v5p 等训练向变体用 4096 芯片 3D torus。Ironwood（v7）已演进到 9,216 芯片 / 36 Pod / 4D torus。[TNP: Google 推理规模]
Google 通过 Multislice 技术 + Titanium IPU 把数百个 Pod 连成"楼宇级超算"，由多 P比特/秒数据中心网络互联。[发布博客]
"with multislice technology and Titanium Intelligence Processing Units (IPUs), Trillium TPUs can scale to hundreds of pods, connecting tens of thousands of chips in a building-scale supercomputer interconnected by a multi-petabit-per-second datacenter network."
Google 独门的 OCS（光路交换机，Optical Circuit Switch）是关键：动态可重构，能在 TPU 故障时绕开失效芯片无需重启训练/推理任务。[TNP]
"That OCS interconnect... has dynamic reconfiguration capabilities and can heal around TPU failures without having to restart entire training and inference jobs. This latter bit is huge."
"Google has been working on liquid pooling since 2014... we are now in our fifth generation cooling distribution unit... as of 2024, we had around a gigawatt of total liquid cooled capacity, which was 70 times more than any other fleet at that point in time. We created this first for TPUs and now we will replicate it for GPUs." — Mark Lohmeyer, Google
自 2014 年起做液冷、第五代 CDU、~1 GW 液冷容量（彼时是其他厂商的 70×），CDU 规格将贡献给 OCP。[TNP]
Google 全产品推理 token 速率：[TNP]
| 时间 | 月推理 token 量 |
|---|---|
| 2024-04 | 9.7 万亿 |
| 2024-12 | ~160 万亿 |
| 2025-04 | >480 万亿（同比 49.5×） |
| 2025-06 | 980 万亿 |
| 2025-08（估） | ~1,460 万亿 |
MLPerf 上单颗 Trillium v6e 跑 Llama 2 70B 约 800 tokens/s ≈ 每月 ~20.7 亿 token。TNP 据此粗估 2025-08 Google 内部推理需约 70 万颗 Trillium 等效。
"the rate of inference across all Google products that the company has to serve has gone exponential."
LPX 的核心是 NVIDIA Groq 3 LPU——"Vera Rubin 平台的第七颗芯片"，源自 Groq 的 TSP（Tensor Streaming Processor）架构（参考论文 Think Fast: A Tensor Streaming Processor）。[NVIDIA 技术博客]
"Rather than optimizing only for peak arithmetic throughput, the LPU emphasizes deterministic execution, high on-chip memory bandwidth, and explicit data movement."
LPU 采用 Groq 的空间执行模型（spatial execution）：编译器显式调度计算、数据搬运与同步，无运行时动态硬件调度器。硬件采用近同步（plesiosynchronous）芯片间协议消除时钟漂移，把数百颗 LPU 对齐为单一协同系统。[NVIDIA 技术博客]
"the compiler relies on plesiosynchronous, chip-to-chip protocol in hardware that cancels natural clock drift and aligns hundreds of LPU accelerators to act as a single coordinated system."
工作单元 = 320 字节向量。算术、访存、跨设备传输全部以该定长向量为单位，简化调度与同步。专用执行模块：[NVIDIA 技术博客]
"Compute and communication in the LPU are organized around 320-byte vectors as the unit of work... By making data movement explicit and programmable, the LPU enables memory access, compute, and communication to be overlapped, rather than relying on hardware heuristics."
| 指标 | LP30（Groq 3 LPU） |
|---|---|
| 制程 | 三星 SF4（非 TSMC N3） |
| 封装 | 单 monolithic die，无先进封装 |
| 片上 SRAM | 500 MB（主工作存储） |
| 片上 SRAM 带宽 | 150 TB/s |
| 算力 | 1.2 PFLOPS FP8 |
| scale-up 双向带宽 | 2.5 TB/s |
| C2C 链路 | 96 条 × 112 Gbps |
| HBM | 无 |
| 对比 Groq 一代 | 230 MB SRAM / 750 TFLOPs INT8（GF16→SF4 提速） |
LP30 的 150 TB/s 片上 SRAM 带宽约为 Trillium HBM 带宽（1.6 TB/s）的 ~90×，但容量仅 500 MB vs 32 GB（~1/64）。这是"带宽/确定性"对"容量"的经典权衡。
"the high-density SRAM = limited capacity: after weights are loaded, very little space remains, and as batch sizes increase, the KV cache quickly becomes saturated, resulting in overall throughput that is significantly lower than that of GPUs." — SemiAnalysis
结论：独立 LPU 系统不适合大规模 token 吞吐服务，但在单用户、低延迟、小 batch 场景的 TTFT 与每 token 延迟无可匹敌——这正是它被定位到 AFD 解耦架构的基础。
单机架 = 32 个液冷 1U 计算托盘，官方每托盘 8 颗 LP30，共 256 颗芯片；cableless 设计，配 2 台 Spectrum-X 交换机。[NVIDIA 技术博客]
| 机架级指标 | LPX |
|---|---|
| AI 推理算力 | 315 PFLOPS（FP8） |
| 总 SRAM 容量 | 128 GB（256×500MB） |
| 片上 SRAM 带宽 | 40 PB/s |
| scale-up 密度 | 256 颗芯片 |
| scale-up 带宽 | 640 TB/s |
| 每托盘（官方） | 值 |
|---|---|
| LP30 芯片 | 8 |
| 片上 SRAM | 4 GB（8×500MB） |
| SRAM 带宽 | 1.2 PB/s |
| 经 Fabric Expansion 的 DRAM | 最高 256 GB |
| 经主机 CPU 的 DRAM | 最高 128 GB |
| FP8 算力 | 9.6 PFLOPS（8×1.2） |
| scale-up 带宽 | 20 TB/s |
LPX 的集群价值不在独立吞吐，而在与 Vera Rubin NVL72（GPU）协同的双引擎 decode 环：[NVIDIA 技术博客] [SemiAnalysis]
| decode 阶段 | 承载硬件 | 原因 |
|---|---|---|
| prefill（建 KV cache） | GPU（NVL72） | 稠密并行算力 + 大内存容量 |
| decode attention | GPU | 依赖动态 KV cache 加载，需大 HBM |
| decode FFN / MoE 专家 | LPU（LPX） | 无状态、可静态调度，契合确定性架构 |
"Together they deliver a heterogeneous serving path that improves interactive responsiveness without sacrificing AI factory throughput."
| 维度 | Trillium (TPU v6e) | LP30 (Groq 3 LPU) |
|---|---|---|
| 定位 | 通用 AI 加速（训练+推理、稠密+稀疏+embedding） | 专用低延迟推理（decode FFN/MoE + 草稿） |
| 制程/封装 | 未公开（HBM，推测 CoWoS） | 三星 SF4 / monolithic / 无先进封装 |
| 算力 | 918 TFLOPs BF16 / 1836 TOPs Int8 | 1.2 PFLOPS FP8 |
| 计算模型 | 2× MXU 脉动阵列 + 向量 + 标量 + SparseCore（硬件管理） | TSP 空间数据流：MXM+VXM+SXM+MEM，320B 向量，编译器显式调度 |
| 片上 SRAM | 小（cache 性质） | 500 MB（主工作存储） |
| SRAM 带宽 | — | 150 TB/s |
| HBM | 32 GB @ 1638 GB/s | 无 |
| 外部内存 | HBM + 主机 DRAM | DDR5（经 FPGA，最高 256 GB/板）+ 主机 DRAM |
| scale-up 互联 | ICI 800 GB/s 双向，4 端口 | C2C 2.5 TB/s 双向，96×112Gbps |
| 确定性 | 部分（硬件管理） | 全确定性，近同步 |
| 独门单元 | 第三代 SparseCore（embedding） | — |
| 主要瓶颈 | HBM 带宽（长 context attention） | SRAM 容量（KV cache 饱和） |
| 维度 | Trillium Pod | LPX Rack |
|---|---|---|
| 芯片数 | 256 | 256（32 托盘×8） |
| 拓扑 | 2D torus（大规模 3D/4D torus） | 节点全 mesh + 铜背板 + OSFP；2× Spectrum-X |
| 聚合算力 | 234.9 PFLOPs BF16 | 315 PFLOPS FP8 |
| scale-up 带宽 | 二分 3.2 TB/s | 640 TB/s |
| 内存 | 8.2 TB HBM | 128 GB SRAM + DDR5 |
| 冷却 | 液冷（属 ~1 GW 机群） | 液冷 |
| scale-out | Jupiter DCN + OCS + Titanium IPU + multislice | Spectrum-X 以太网 + BlueField-4 |
| 软件栈 | Pathways / JAX+XLA / GKE / vLLM / Anywhere Cache / GKE Inference Gateway | Dynamo / AFD / 投机解码 |
| 集群范式 | 同构 multislice（数万同类 TPU） | 异构（NVL72 GPU Pod + LPX LPU 机架） |
| 核心目标 | 聚合吞吐与成本 | 每用户延迟与高端交互 |
站在算法/模型设计者角度，两类架构映射到当代模型范式的不同痛点：
范式判断：行业正从"单一硬件吃全部负载"转向按 decode 内部阶段硬件解耦（prefill/decode → attention/FFN）。Google 用一类灵活加速器 + 软件智能（Pathways/Inference Gateway）实现；NVIDIA 用专用加速器 + 编排（Dynamo/AFD）实现。解耦是共同终局，谁做硬件解耦、谁做软件解耦是分野。
原始调研笔记已持久化于 trillium_nvidia_analysis/raw/（00_disambiguation → 06_semianalysis_lpx 共 7 份），供后续人工分析。