大语言模型推理硬件挑战：内存带宽、低延迟互连与HBM、近存计算研究方向

注：本文基于 Xiaoyu Ma 和 David Patterson 的论文《Challenges and Research Directions for Large Language Model Inference Hardware》以及行业最新动态进行解读与分析。

前几天，Xiaoyu Ma 和 David Patterson 发表了一篇论文《Challenges and Research Directions for Large Language Model Inference Hardware》[1]，恰好 CES 上 NVIDIA 的演讲也涉及了 KV Cache 和内存层次结构的内容，在此一并进行分析。首先我们来解析这篇论文。

作者首先阐述了 LLM 推理的难题，其底层 Transformer 模型的自回归解码阶段，使得 LLM 的推理与训练有着本质上的不同。在近期 AI 趋势的加剧下，其主要挑战在于内存和互联，而非计算。因此这篇文章主要讨论四个体系结构的研究机遇：

1. HBF：用于以类似 HBM 的带宽提供 10 倍内存容量的高带宽闪存。
2. PNM：用于实现高内存带宽的近存计算，将计算单元置于内存附近以获得高内存带宽。
3. 3D 内存-逻辑堆叠：通过垂直集成实现高带宽和低功耗。
4. 用于加速通信的低延迟互联：针对推理中频繁的小消息通信进行网络优化。

其实核心问题就是内存带宽和互连。Patterson 讲了这么多，有一个显而易见的答案：对于 3D-Stacking，Groq 这样的 Cycle 级确定性控制在对散热和功耗的抑制上是有好处的，它也是一个 PNM 的架构。而对于其它问题，将 SRAM 直接附加在网络上并构建 PNM，然后外挂一些 HBF 做大容量大带宽的池化不就行了么？ 这不就是多年前我折腾 NetDAM 早就分析清楚的一条路么？本文的最后一章将详细阐述。

本文目录如下：

1. 引言：LLM推理是一场危机
2. 当前LLM推理硬件及其低效性
   2.1 Decode挑战1：内存
   2.2 Decode挑战2：端到端延迟
3. 四大研究机遇
   3.1 高带宽闪存 (High Bandwidth Flash, HBF)
   3.2 近存计算 (Processing-Near-Memory, PNM)
   3.3 3D内存-逻辑堆叠 (3D memory-logic stacking)
   3.4 低延迟互联 (Low-Latency interconnect)
4. Nvidia的解决方案
   4.1 BlueField 4
   4.2 Nvidia KV Cache方案
5. 一些潜在的方案
   5.1 3D-Stacking
   5.2 HBF+PNM+Interconnect
   5.3 NetDAM

1. 引言：LLM推理是一场危机

作者首先指出，当前学术界的体系结构研究与工业界的实际需求存在脱节。Patterson 职业生涯开始的 1976 年，大概有 40% 的体系结构论文来自工业界，而到了 ISCA 2025，这一比例已降至 4% 以下，这表明学术研究与工业实践之间几乎脱节。

这一段点出了关键问题。其实在网络互连领域也有同样的情况，审稿人大多在学术界，其品味决定了他们可能无法深入了解工业界的实际问题，对于一些简单巧妙的工业界解决方案以及生产环境下的约束了解较少。

作者开篇的这段话不仅仅是一个引子，更是写作本文的深层动机。他希望通过这篇文章，像一座桥梁，重新连接学术界和工业界。他在呼吁学术界的研究者们，将目光投向工业界真正“卡脖子”的难题上，而不是在一些与现实脱节的“象牙塔”问题上打转。这为本文提出的研究方向赋予了更强的现实意义和紧迫感。

LLM 推理的成本和难度正在成为其经济可行性的决定性因素。据预测，推理芯片的年销售额在未来 5-8 年内将增长 4 到 6 倍。尽管训练阶段展示了非凡的 AI 突破，但推理成本却决定了其经济可行性。随着这些顶尖模型使用量的急剧增加，公司们发现为其提供服务的成本非常高昂。

同时，以下几个 AI 新趋势使得推理变得更加困难：

趋势	核心机制	对推理的影响	主要瓶颈
MoE	用大量稀疏激活的专家网络替代密集网络	模型参数量暴增，需要在众多专家中路由。	内存容量 (存下所有专家)， 互联 (在专家间通信)
Reasoning	生成大量中间“思考”步骤	输出序列长度急剧增加，延迟变长。	内存带宽 (频繁读写 KV Cache)， 延迟
Multimodal	处理图像/音频/视频等大数据类型	输入/输出的数据量更大。	内存容量 & 带宽
Long context	增加模型能参考的输入信息量	KV Cache 体积线性增长。	内存容量 & 带宽
RAG	从外部数据库检索信息作为上下文	增加了输入处理步骤和上下文长度。	内存容量 & 带宽
Diffusion	并行生成，迭代优化	计算步骤增多，但非自回归。	计算

这是一个非常好的总结。对于体系结构而言，前五个趋势的瓶颈归结为内存和通信，最后一个瓶颈为计算。

2. 当前LLM推理硬件及其低效性

LLM 推理主要包含两个阶段：Prefill 和 Decode。前者是计算密集型，而后者是内存密集型。当前主流的 GPU/TPU 在为训练设计时，其架构并未专门为 LLM 的 Decode 阶段优化，导致在推理时效率低下。作者总结了 Decode 阶段面临的两大挑战。

2.1 Decode挑战1：内存

自回归模型的 Decode 阶段是一个内存瓶颈的应用，而新的软件趋势更是加剧了这一挑战。与此相反，硬件的发展趋势却走向了一个完全不同的方向：

1. AI 处理器面临内存墙问题：当前的数据中心 GPU/TPU 依赖于高带宽内存 (HBM)，并将多个 HBM 堆栈连接到单个巨大的加速器 ASIC 上。然而，内存带宽的提升速度比计算浮点性能 (FLOPS) 要慢得多。例如，从 2012 年到 2022 年，NVIDIA GPU 的 64 位 FLOPS 增长了 80 倍，但带宽仅增长了 17 倍。这个差距将继续扩大。

	HBM	HBM2	HBM2E	HBM3	HBM3E	HBM4
推出年份	2013	2016	2019	2022	2023	2026
最大引脚带宽 (Gbit/sec)	1.0	2.4	3.6	6.4	9.8	8
引脚数	1024	1024	1024	1024	1024	2048
堆栈带宽 (GB/s)	128	307	461	819	1254	2048
最大 Die 数/堆栈	4	8	12	12	16	16
最大 Die 容量 (GiB)	1	1	2	2	3	4
最大堆栈容量 (GiB)	4	8	24	24	48	64
NVIDIA GPU		Volta V100	Ampere A100	Hopper H100	Blackwell B100	Rubin R100
HBM 堆栈数/GPU		4	5	6	8	8

（注：论文原始表格有一个 Typo，Hopper 一代应为 6 颗 HBM3e）

2. HBM 成本日益高昂：HBM 的制造和封装难度越来越大，导致其单位容量和单位带宽的价格不降反升。虽然原文说 DDR 的价格在下降，但是最近 DDR5 也在涨价。

3. DRAM 密度增长放缓：单个 DRAM 芯片的容量增长速度也在变慢。
4. 纯 SRAM 方案的局限性：类似 Cerebras 和 Groq 采用片上 SRAM 的方案，随着 LLM 模型参数的爆炸式增长，其 SRAM 容量已无法满足需求，最终仍需依赖外部 DRAM。

2.2 Decode挑战2：端到端延迟

面向用户意味着低延迟。与需要数周时间的训练不同，推理与实时请求绑定，需要在几秒或更短时间内响应。低延迟对于面向用户的推理至关重要 (批处理或离线推理没有低延迟要求)。根据应用的不同，延迟的衡量标准是所有输出 token 的完成时间，或是首个 token 的生成时间 (TTFT)。两者都面临挑战：

• 完成时间挑战：Decode 阶段一次只生成一个 token，因此输出越长，延迟就越高。长的输出序列会拉长延迟，但长的输入序列也会使速度变慢，因为在 Decode 和 Prefill 阶段访问 KV Cache 需要更多时间。由于是内存密集型，每个 Decode 迭代都有很高的内存访问延迟。
• TTFT 挑战：长的输入序列和 RAG 增加了生成开始前的工作量，因此也增加了首个 token 的生成时间。推理模型同样会增加这个延迟，因为它们在生成第一个用户可见的 token 之前，会先生成许多“想法” token。

LLM 推理因模型巨大通常需要多芯片系统，这意味着频繁的跨芯片通信。与训练不同，Decode 阶段的批量大小通常很小，导致网络消息的尺寸也很小。对于频繁的小消息通信，网络延迟的影响远大于带宽。下表总结了 LLM Decode 的硬件瓶颈以及论文提出的研究方向如何应对这些瓶颈。

LLM Decode 特点与趋势 + 潜在研究机遇	内存 容量	内存 带宽	互联 延迟	计算
硬件改进的驱动因素
常规 Transformer Decode	✅	✅
MoE	✅	✅	✅
Reasoning 模型	✅	✅	❓
多模态	✅	✅	❓
长上下文	✅	✅	❓
RAG	✅	✅	❓
Diffusion				✅
潜在研究方向
① 高带宽闪存 (High Bandwidth Flash)	✅		⬆️
② 近存计算 (Near Memory Compute)		✅	⬆️
③ 3D 计算-逻辑堆叠 (3D Compute-Logic Stacking)		✅	⬆️
④ 低延迟互联 (Low-Latency Interconnect)			✅

注: “✅” 表示主要瓶颈。 “⬆️” 表示该方向通过缩小系统规模间接帮助降低了互联延迟。

3. 四大研究机遇

作者提出了四个可以重塑 LLM 推理硬件的研究方向，旨在优化新的性能/成本指标，如 TCO (总拥有成本)、功耗和碳排放。

3.1 高带宽闪存 (High Bandwidth Flash, HBF)

采用类似 HBM 的堆叠技术来堆叠闪存 (Flash) die，从而获得闪存的容量和HBM 级的带宽。

优势

• 10 倍权重内存：HBF 可提供比 HBM 大一个数量级的容量，用于存储推理时固定的模型权重，使单节点能够承载远超当前规模的模型 (如巨型 MoE)。
• 10 倍上下文内存：可用于存储变化缓慢的上下文数据，如网络语料库、代码库等。
• 更小的推理系统：由于单节点内存容量大增，运行同一个模型所需的节点数减少，从而降低通信开销，提高可靠性。

挑战

• 有限的写寿命：闪存的擦写次数有限，因此 HBF 只适用于存储不经常更新的数据。
• 基于页的高延迟读取：闪存以页 (Page) 为单位读取 (通常几十 KB)，延迟远高于 DRAM (几十微秒 vs 几十纳秒)。

下表是 HBF 与其他存储设备的粗略比较：

研究方向

1. 如何设计软件来适配 HBF 的特性？
2. 系统中 HBF 与传统内存的比例应该是多少？
3. 能否从技术上改进 HBF 的限制？

3.2 近存计算 (Processing-Near-Memory, PNM)

首先作者严格区分了 PIM 和 PNM：

• PIM (Processing-in-Memory，存内计算)：计算逻辑和存储单元在同一个 die 上。
• PNM (Processing-Near-Memory，近存计算)：计算逻辑和存储单元在不同但邻近的 die 上。

下表总结了 PIM 和 PNM 在数据中心 LLM 推理场景的对比：

	Processing-in-Memory (PIM)	Processing-Near-Memory (PNM)	胜出者
数据移动功耗	非常低 (片上)	低 (片外但邻近)	PIM
带宽(每瓦)	非常高 (标准的5-10倍)	高 (标准的2-5倍)	PIM
内存-逻辑耦合	内存和逻辑在同一个 die 上	内存和逻辑在分离的 die 上	PNM
逻辑 PPA	在 DRAM 工艺下逻辑更慢，功耗更高	逻辑工艺有助于性能，功耗和面积	PNM
内存密度	更差，因为与逻辑共享面积	不受影响	PNM
商品化内存定价	否。量小，供应商少，密度低	是。不受影响	PNM
功耗/散热预算	逻辑在内存 die 上预算紧张	逻辑受限较小	PNM
软件分片	需要为内存 bank (如32–64 MB) 分片	分片限制较小 (如16–32 GB)	PNM

作者结论

针对数据中心 LLM PNM 优于 PIM：作者认为，尽管 PIM 在理论带宽和功耗上更有优势，但 PNM 在实际应用中更胜一筹。

• 软件分片：PIM 要求将数据切分到极小的内存 bank (如 32-64MB)，这对于 LLM 复杂的内存结构来说非常困难。PNM 的分片粒度可以大得多 (如 16-32GB)，易于实现。
• 逻辑 PPA：PNM 的计算逻辑可以使用先进的逻辑工艺制造，PPA 更优。而 PIM 的计算逻辑受限于 DRAM 工艺，性能较差，功耗较高。
• 内存密度与成本：PNM 不影响标准内存的密度和商品化定价。
• 功耗/散热预算：PIM 中计算逻辑的功耗和散热受到 DRAM die 的严格限制。

另外，作者也指出，对于移动设备，由于模型更小，功耗预算更紧，PIM 的劣势不那么突出，可能是一个可行的方案。

3.3 3D内存-逻辑堆叠 (3D memory-logic stacking)

利用硅通孔 (TSV) 技术将内存 die 和逻辑计算 die 垂直堆叠在一起，从而获得极宽、极密集的内存接口，实现高带宽和低功耗。这本身就是 PNM 的一种实现方式。有两种形式：

1. 基于 HBM Base-die 的计算：在 HBM 的 Base Die 中嵌入计算逻辑。带宽与 HBM 相同，但功耗因路径缩短而降低 2-3 倍。
2. 定制化 3D 方案：设计全新的 3D 堆叠接口，可以实现比 HBM 更高的带宽和能效。

主要挑战

1. 散热：3D 堆叠表面积减小，散热更困难。一种解决方案是限制计算逻辑的频率和电压。
2. 内存-逻辑耦合：需要行业标准来定义 3D 堆叠的接口。

研究方向

1. 软件如何适应新的带宽/容量/算力配比？
2. 如何在多种内存类型的系统中高效映射 LLM？
3. 如何与其他 3D 堆栈或主处理器通信？

3.4 低延迟互联 (Low-Latency interconnect)

针对推理场景中延迟敏感的特点，重新思考网络设计的延迟-带宽权衡。具体技术方案：

• 高连通性拓扑：采用 Tree, Dragonfly, Tori 等拓扑结构，减少网络跳数，降低延迟。
• 网络内处理：利用交换机硬件加速集合通信操作 (如 all-reduce, broadcast)，例如 NVIDIA SHARP 技术。
• AI 芯片优化：将小数据包直接存入片上 SRAM 而非 DRAM；将计算引擎靠近网络接口。
• 可靠性协同设计：使用本地备用节点减少故障迁移延迟；在对通信质量要求不高的场景下，允许使用过期或伪造数据来避免等待慢节点，从而降低尾延迟。

4. Nvidia的解决方案

4.1 BlueField 4

BF4 实际上是 Grace CPU 和 CX9 拼接而成的：

总体来看，NVIDIA 网络团队在体系结构上可能面临挑战。整个芯片实际上算上 CX9 内部的 PSA/DSA，再加上 Grace 有三套不同的处理器运行，还包括了一些 Spectrum-X 的交换机 PortLogic，从 PPA 角度来看，这可能只是一个临时拼凑的方案。然后基于 BF4 构建了一个 KV Cache 的存储服务器。

由于 Grace 本身的性能以及 ARM 内存序带来的生态问题，加上对分布式存储的理解可能存在局限，或许选择用几颗 x86 搭配 CX9 来实现，还能扩展更多 CPU 内存作为热 Cache，避免对 SSD 的频繁直接写入并降低延迟。

4.2 Nvidia KV Cache方案

NVIDIA 在 CES 上发布了基于 BF4 的 KV Cache 方案。总共分为如下四个层级：

首先在 G1 这一层，GPU 内的 HBM 直接存储 KV Cache 以及 G4 通过对象存储是没问题的。主要问题出现在 G2 和 G3 这两层。

1. G2 的问题：在 G1 和 G2 之间有一个强假设，即必须使用 NVLink C2C 的 Grace-Blackwell 和 Vera-Rubin 方案。而对于那些 PCIe 的卡（例如 Rubin CPX 或 B200/R200 这些 8 卡平台）这一条是不成立的，因为在 CPU 和 GPU 之间的 PCIe 带宽存在明显的超额认购，同时 CPU 的内存带宽和 PCIe RC 的性能也有一定限制。并且还要和一些 PCIe 上的 RDMA 横向扩展网络流量有冲突，而 PCIe 又没有很好的 QoS 机制。
2. G3 的问题：对于 G3 这样的本地 SSD 也可能有问题，例如一些 MaaS 平台，T1 时间服务 A 模型，T2 时间服务 B 模型。KV Cache 在本地硬盘或机架级存储都会带来很重的数据迁移成本。

对于 G2/G3 的问题，实质的解决思路为：

1. 通过横向扩展网络或纵向扩展网络接入池化的分布式存储。
2. 在 RDMA 上实现 QoS，即流量速率限制/整形的处理方式，避免 KV Cache 和集合通信互相干扰。

当然 CX9 能不能做到还是未知数。一方面，原来的组网按照多轨道方式构建，那么存储节点的网卡挂在哪个轨道上？如果不采用多轨道而使用 FatTree，如何在一个带有收敛比的网络下做好拥塞控制和避免哈希冲突？即便是 NVIDIA 宣传的自适应路由也有不少问题。对于第二个问题，当前的 NVIDIA CX9 网卡拥塞控制算法也存在挑战。既然能提出这个问题，其实已经在现有的一些先进架构（如 CIPU 2.0）芯片上解决了。

5. 一些潜在的方案

关于 Patterson 的论文以及提出的问题和四个潜在的研究方向，接下来做一些解答。首先我们将谈论 3D-Stacking 的方案，然后再对于剩余 3 种 (HBF/PNM 和 Interconnect) 结合在一起分析。

5.1 3D-Stacking

Groq 的解决方式很不错。由于其确定性的处理方式，对于功耗优化有很多优势，可以以 Cycle 粒度评估整个系统的功耗和散热。

这使得 Logic-on-Logic 的 3D Stacking 成为可能。

功耗控制的问题就可以得以解决。关于 Feynman 如何使用 3D-Stacking 有一个详细的分析可以参考《Nvidia如何整合吸收Groq的技术》。这种方案也很好地解决了 Patterson 提出的纯 SRAM 的 Groq 方案的不足，通过整合 Feynman GPU Die 实现的 3D-Stacking 有更高的 SRAM 容量，对于 MoE 来说权重加载的代价会减少，GEMV 的执行也会更好地与通信重叠。

5.2 HBF+PNM+Interconnect

其实这三种路线可以通过巧妙的结合叠加在一起处理。

首先来谈谈 HBF。如果直接挂载在 GPU Core 上，会存在论文提到的 HBM 和 HBF 配比的问题。

而且 KV Cache 本来就有很繁重的写入压力，对 HBF 的持久性存在很大挑战，同时延迟较大。从软件的视角来看，当前最有可能放入 HBF 的大概也就是一些模型的权重数据。

对于 GPU 需要扩展内存容量，可能更多可以考虑在 HBM4 Base Die 上接入一些 LPDDR，这也是我在前面提到的 NVIDIA G2 层问题的一个解答思路。

而对于 HBF，我们为什么不将其池化后挂载在纵向扩展总线上呢？HBF 自身的延迟已经在数十个微秒的量级，因此穿越一次纵向扩展总线的代价并不大。

接下来我们讨论一下 PNM 如何整合进入互连总线。如果我是 NVIDIA 的架构师，可能会考虑一个快速上市的方案：在 Rubin Ultra 的 NVLink I/O Die 上增加一些 SRAM 来作为 Groq 的 MEM FU，并引入 Groq SXM FU。整体方案如下：

首先对于 MoE 模型而言，Token Dispatch 和 Combine 所需要的低延迟计算在 NVLink SHARP 上是难以实现的。因为大量 token 产生的 Dispatch 和 Combine 操作如果在交换机芯片内处理，每个 Token 需要维持 num_topk 个流表进行 Combine 运算，设计会非常复杂。同时 NVLink Switch 又需要很大的带宽和很高的端口密度，并且它也是多颗交换芯片并行连接到多个 NVLink 上，如何保证 Dispatch 和 Combine 的状态都在同一个 NVLink Switch 上是困难的。

因此最适合的地方可能是在 NVLink I/O Die 上首先增加 Groq 的 MEM FU 和 SXM FU。GPU 产生的 Token 无需存储到 HBM 就可以直接通过 SMEM 写入到 Groq MEM FU，并触发 SXM FU 参与 Dispatch 和 Combine 的运算，同时还可以进行细粒度的转置等操作，更好地适应 Expert FFN 中 GPU Tile-Based GEMM 的运算。

5.3 NetDAM

对于这种方案，在 5~6 年前我还在 Cisco 构建 NetDAM 的时候就进行过验证。整体方案如下，这实质上是工业界第一个以太网纵向扩展方案了。详细内容可以参考《NetDAM: Network Direct Attached Memory with Programmable In-Memory Computing ISA》[2] 以及另一个专题：《NetDAM》。

NetDAM 即在网络上直接附加内存并引入 PNM。它的原型是一颗带有 HBM 的 FPGA，内部架构如下：

PNM 指令通过纵向扩展的协议进行编码，每个数据包头都带有相应的指令，可以执行基于向量的操作。对于数据的读写，由于存在 SRAM，它相对于传统方案具有更好的确定性：

进行 Reduce 操作时，它的延迟远小于传统的方案：

整体处理延迟经过一个交换机为 610ns，直连仅 427ns，抖动仅 8ns：

执行集合通信整体的延迟，经过 4 跳完成 Ring Reduce-Scatter 的延迟仅需要 3us：

抖动也可以控制在很小的范围：

这些 6 年前的设计都可以很好地匹配现在 MoE 的通信难题。但是很遗憾的是，工业界在纵向扩展的协议上，从 GenZ/OpenCAPI，到 CXL，再到现在 NVLink/UALink/SUE 等大量方案一直没有统一。并且直到 MoE 模型大规模推理出现时，这才变成工业界的一个巨大挑战。

在探索这些前沿硬件架构与优化方案时，一个活跃的开发者社区至关重要。欢迎访问 云栈社区，这里汇聚了众多对 人工智能 和 云原生 技术充满热情的同道，共同交流学习，追踪技术最新动态。

参考资料

[1] Challenges and Research Directions for Large Language Model Inference Hardware: https://www.arxiv.org/abs/2601.05047

[2] NetDAM: Network Direct Attached Memory with Programmable In-Memory Computing ISA: https://arxiv.org/pdf/2110.14902