HotChip/FMS 内存墙（一）：HBM scaling、3D-DRAM、PIM 与 CXL-PNM，推理芯片为什么不能只堆带宽

为什么把 Jalapeño 放进内存墙里讲#

OpenAI Jalapeño 的主线很容易被读成「OpenAI 造了一颗比 Blackwell 更快的推理 ASIC」。这当然是故事最抓人的部分，但 HotChip/FMS Talk 的后半段把问题放得更大：Jalapeño 只是推理热路径专用化的一种答案，真正的底层矛盾是内存层次正在被大模型推理重新定义。

训练时代常见的直觉是：买更多 GPU，把 batch 做大，让矩阵乘法把 Tensor Core 喂满。推理时代的 decode 阶段不一样。每生成一个 token，都要读权重、读 KV cache、做注意力、跑 FFN 或 MoE 专家，再把新 KV 写回去。batch 很小时，权重读取无法被足够多请求摊薄；上下文很长时，KV cache 的读取会随序列长度线性增长；MoE 继续扩大时，专家池又把容量压力推高。于是系统被三件事同时夹住：带宽不够、容量不够、数据搬得太远。

Jalapeño 解决的是其中最热的一段：用 HBM4、低延迟切片化内存、本地 KV 和专用网络，把当前 token 的关键路径做短。FMS 侧的讨论则回答另一个问题：当模型继续变大、上下文继续变长、专家继续变多，HBM 本身还能不能继续扛住？如果不能，下一层内存应该长什么样？

AI demand 正在把内存从性能瓶颈推成成本瓶颈#

Talk 的第一组背景不是技术，而是产业账本：AI 基础设施投资把 DRAM 与 HBM 需求推到供给之上，存储厂商的收入增长越来越多来自价格上行，而不是出货量自然增长。HBM 尤其特殊：它吃晶圆、吃先进封装、吃测试产能，扩产慢，良率和封装能力共同限制供给。对模型服务商来说，内存不再只是「机器里的一项配置」，而是直接决定推理成本、上线速度和数据中心功耗的核心约束。

这和本站 OpenAI Jalapeño 完全拆解 里的数据中心视角是一致的：当机房受限于电力和冷却，真正要优化的不是峰值 FLOPS，而是每兆瓦能产出多少 token。内存侧也有同样的问题：继续把更多字节从远处搬到计算单元，会让带宽、I/O 功耗和封装面积一起上涨。长期解法不是简单「买更多带宽」，而是减少必须移动的数据，或者把计算移到更靠近数据的位置。

计算扩得比内存快，HBM gap 会越拉越大#

Talk 里有一条很关键的趋势判断：AI 加速器算力大约每两年提升 3 倍，而 HBM 带宽每两年不到 2 倍。这个差距会持续扩大。直观地说，矩阵乘法单元越堆越多，但每个 token 需要搬的权重和 KV 并不会因为 Tensor Core 变多而自动变少。结果是：硬件纸面算力越来越夸张，decode 端到端延迟却常常被内存拖住。

可以用一个简化账本理解。设每次 decode 需要读取的总字节数为 $D_ ext{token}$，可用内存带宽为 $B$，只看内存下界，则：

算力提升只会降低计算项，无法降低这个内存项。要继续降延迟，只有三条路：

1. 提高 $B$：更快 HBM、更宽接口、更多堆叠；
2. 降低 $D_ ext{token}$：量化、MLA/GQA、稀疏注意力、KV 压缩、专家局部性；
3. 缩短数据路径：把控制逻辑、计算逻辑、缓存逻辑移到内存附近，减少 xPU 与内存之间的长距离搬运。

HotChip/FMS 的 HBM、3D-DRAM、PIM、CXL-PNM 讨论，分别落在这三条路的不同位置。

HBM 是桥，不是终点#

HBM 的价值来自高并行度。每个 DRAM die 内部有多个 channel，channel 又拆成 pseudo-channel，HBM3E 已经做到每 die 128 个 bank，HBM4 进一步提升到 256 个 bank。Base die 负责在 host/xPU 和 DRAM core die 之间搬命令与数据，它既是接口层，也是未来演进的关键位置。

HBM scaling 的目标可以概括成三件事：

问题在于这三者互相牵制。更高 I/O 速率需要更强 PHY，PHY 会占面积、耗电、发热；更高堆叠带来容量，但热阻上升、散热更难；更多 TSV 和更小 pitch 提高带宽，却会碰到制造、可靠性和良率边界。HBM 是当下最强的近存储带宽方案，但它不是无限扩展的魔法。

Base die 正在从「接口层」变成「逻辑扩展层」#

Talk 里对 HBM4 及后续 HBM 的一个核心判断是：Base die 不再只是简单的数据通道和测试逻辑，而会变成 xPU 的逻辑扩展层。原因很直接：xPU compute die 越来越接近 reticle limit，先进制程面积极贵；如果某些内存控制、可靠性、地址修复、近存处理逻辑能下放到 HBM base die，就能把宝贵的 xPU 面积留给矩阵计算和片上网络。

这条路线可以拆成三个阶段。

第一阶段是回收 xPU 面积。传统 HBM PHY 越做越宽、通道越拉越长，xPU 上的 PHY 和 memory controller 面积越来越重。cHBM 一类思路把传统 HBM PHY 替换成更短的 die-to-die 接口，并把 memory controller 逐步下沉到 base die。这样做等价于把一部分「靠近内存才有意义」的控制逻辑从 xPU 里搬出去。

第二阶段是给 base die 增加系统功能。当 PHY 和控制逻辑优化后，base die 可以承载 RAS/test、memory extension、processing element offload 等功能。也就是说，base die 开始从「被动接口」变成「主动系统组件」。这对推理很关键：KV cache 的分配、错误修复、刷新策略、局部预处理，都有可能受益于更近的数据控制点。

第三阶段是3D integration。把 xPU logic 与 DRAM stack 纵向整合，减少 2.5D interposer 上的长距离 I/O。目标不是简单把内存堆高，而是用更短的垂直连接降低 PHY/SerDes 功耗，让 DRAM 与 SoC 共同设计。

封装和散热正在成为 HBM 的一等约束#

HBM scaling 不只是电路设计。Talk 引用了 SK Hynix 侧的先进封装路线：TSV formation、micro-bumping、wafer thinning、chip stacking、MR-MUF、hybrid bonding、I-HBM。它们背后的共同问题是：高堆叠 HBM 的瓶颈越来越多地出现在物理世界。

以 16Hi HBM3E 为例，堆叠更高可以提高单 cube 容量，但 die 越薄、堆叠越高，机械可靠性、热通路和制造良率越难。Hybrid bonding 的吸引力在于同时改善 pitch、导热和高堆叠可行性：SiO₂-to-SiO₂ 提供机械支撑，Cu-to-Cu 提供电连接，连接更细、热路更好。I-HBM 这类概念则把导热结构直接整合到高功耗密度的 D2D PHY 区域，针对局部热点建立额外热路径。

这解释了为什么 Jalapeño 虽然用了 HBM4，却仍然要把功耗控制在 700 W 包络内。内存越靠近计算，系统越受封装和热共同约束。推理芯片不能只问「有多少 TB/s」，还要问「这些 TB/s 的每 bit 功耗是多少、热点在哪里、能不能长期稳定运行」。

Beyond HBM：为什么需要 3D-DRAM、PIM 和 CXL-PNM#

HBM 的演进仍在继续，但 Talk 明确把视角推到 Beyond HBM。原因不是 HBM 要被淘汰，而是推理 workload 已经分化：prefill 更偏 compute-throughput bound，decode 更偏 memory-bandwidth bound，长上下文和 MoE 又把容量压力拉高。单一 HBM 层同时承担热权重、热 KV、冷专家、长尾 KV、前缀缓存，会越来越吃力。

Beyond HBM 的技术可以按「数据离计算有多近」排列：

这几条路线的共同目标是：不要把所有字节都当成必须进入 HBM 的热数据。该靠近计算的靠近计算，该留在容量层的留在容量层，该在内存附近预处理的就在内存附近处理。

3D-DRAM：把逻辑堆到 DRAM 上，带宽和复杂度一起上来#

Talk 重点讲了 d-Matrix Raptor 代表的 3D-DRAM 思路。它的出发点是：模型权重和 KV cache 同时增长，SRAM 速度最快但容量太小，HBM 容量较大但带宽受 I/O、封装面积和功耗限制。若把逻辑直接堆到 DRAM 上，用短垂直连接替代 interposer 上的长路径，就能把数据移动距离大幅缩短。

这个方向的诱惑很强。Talk 中给出的直观例子是：72-card Raptor rack 提供约 2.3 TB 高带宽内存，足以在 4-bit 权重与 8-bit KV cache 条件下支撑前沿 LLM 的 1M-token context 推理。换句话说，3D-DRAM 试图把「容量够」和「带宽高」放进同一个封装级设计里。

但 3D-DRAM 的难点也很硬。Talk 把它拆成三组互相依赖的问题。

难题一：bank-to-channel mapping#

Raptor 示例里，每个 tensor engine 需要一次访问拿到 128B flit；每个 bank 每次 column access 给 32B。理想情况下，一个 channel 要同时动用 4 个 bank 才能凑满 128B。可具体配置里，840 个 DRAM bank 支撑 256 个 channel，平均每 channel 只有约 3 个 bank。若朴素映射，channel 每次只能返回约 96B 有效数据，为凑 128B 需要额外访问，造成约 33% bandwidth overfetch。

这不是小优化，而是 100 TB/s 量级系统里的巨大浪费。Talk 里的解法是 stream blocking：把第 4 个 32B partial 分摊进连续 flit 流里，让 4×96B 输入正好组成 3×128B 输出，从而把 overfetch 降到 0%。这说明 3D-DRAM 的「高带宽」不是物理堆叠天然送的，而是地址映射、bank 组合、数据流形状共同设计出来的。

难题二：I/O power wall#

如果目标是 100 TB/s，按 0.37 pJ/bit 粗算，I/O 功耗就是：

也就是说，只是把数据从 DRAM 送出来，就可能花掉接近 300 W。传统 DBI（Data Bus Inversion）依赖多周期 burst 和额外 sideband pin，PHY 看到完整 burst 后决定是否反转。但 3D-DRAM 的短垂直接口可能没有这种 burst 结构和专用 DBI pin。

Talk 给出的方案是 stream flipping / pinless DBI：把每个 flit 和前一个 flit 比较，若反转后切换更少就写入反转版本，并把 1-bit tag 与 ECC 共址存放。读的时候取 tag，再决定是否恢复。它把 DBI 从 PHY sideband 机制变成架构级数据流机制，代价约 0.8% tag overhead，换来约 20% power saving。这正体现了近存架构的特点：物理接口变了，经典内存技巧也要重写。

难题三：105℃ 下的可靠性#

3D 堆叠会加剧热。Talk 里列了三个连锁问题：良率、通道对称性、刷新压力。840 banks/die 意味着即使很小的 fault rate，也可能让整条通道失效；禁用 faulty bank 又会让 channel 变窄，破坏 tensor engine 依赖的对称带宽；温度到 105℃ 后，DRAM retention time 可能从约 32 ms 降到约 4 ms，需要 8 倍更频繁的 refresh，进一步抢带宽和功耗。

对应的解法包括 thermal-aware refresh/ECC 和 bank chaining。前者按温度与错误风险分配刷新和纠错强度，避免全局保守；后者通过 bank 级链式替换保持通道形状，避免局部坏 bank 直接破坏并行结构。结论很清楚：3D-DRAM 要把带宽和容量放进一个封装，必须把 bank mapping、fault repair、refresh scheduling、power management 一起做成系统工程。

Raptor 与 Hope：两种 3D-DRAM 心智模型#

Talk 还对比了 Hope 与 Raptor 两种思路。Hope 更像从传统 DRAM 层次往上走：channel → bank group → banks，并通过 4-layer stacking 增加垂直容量。Raptor 更像从并行数据流往下切：bank → channel，通过大量 bank/channel 和多个 chiplet 实现高并行度。

这两种心智模型的区别很重要。前者先保证 DRAM 组织，再让计算适配；后者先问 tensor engine 需要怎样的 flit 流，再反推 bank/channel 布局。对于 LLM decode，后者更接近推理芯片设计的方向：不是把通用内存挂在加速器旁边，而是从 token 流、KV 流、专家流反推内存组织。

PIM：在内存附近做什么才值得#

PIM（Processing-In-Memory）常被讲成「把计算搬到内存里」，但这句话太粗。对 LLM 推理来说，并不是所有计算都适合 PIM。矩阵乘法的主干仍然需要高度优化的阵列、Tensor Core 或脉动阵列；PIM 更适合的是数据移动占比高、计算简单、访问规整或可局部化的部分。

典型候选包括：

• KV cache 的简单筛选、压缩、统计；
• 稀疏注意力的块级打分或候选过滤；
• MoE 专家权重的局部 gather / reorder；
• prefix cache 的命中检查与局部搬运；
• embedding/lookup 类访问密集操作。

PIM 的难点是编程模型。GPU 生态之所以强，是因为算子、编译器、调度器、profiling 工具都围绕通用 GPU 建成了闭环。把计算搬到内存侧后，开发者需要新的 kernel 抽象、新的数据一致性规则、新的错误处理和新的调度策略。若只是为了几个小算子引入整套复杂性，收益未必划算。因此 PIM 更可能作为内存层次的一部分出现，而不是单独替代 GPU/ASIC。

CXL-PNM：容量解聚不等于低延迟#

CXL-PNM（Compute Express Link + Processing Near Memory）代表另一条思路：通过 CXL 把内存容量池化、解聚，并在内存附近加入处理能力。它解决的是「单节点本地内存放不下」和「容量利用率不均」的问题，而不是直接把 decode 热路径变成 HBM 级速度。

这对长上下文和 MoE 很有吸引力。冷 KV、长尾前缀、低频专家、权重冷层都可能放在 CXL 侧；当请求需要时，再搬到 HBM 或由近内存处理单元先做过滤。但 CXL 的延迟、协议开销和带宽都决定了它不适合承接每 token 必读的热数据。它更像一个分层存储系统里的中间层：比远端 SSD/对象存储近，比 HBM 慢；比 DRAM/HBM 容量便宜，比真正冷存储贵。

因此 CXL-PNM 的核心不是「能不能接上」，而是调度：哪些 KV 值得保留，哪些专家值得放近，什么时候预取，什么时候迁移，怎样避免热请求被慢路径拖住。这里和本站 DualPath、DeepSeek 3FS 里的 KV offload 思路有同源性：容量层只有配合预测、预取和缓存策略，才不会变成新的尾延迟来源。

与既有推理优化如何拼起来#

这篇文章讲的是硬件内存层次，但它不会单独生效。推理系统真正需要的是多层组合：

这也是为什么 Jalapeño、HBF、3D-DRAM、CXL-PNM 不应被看作互斥路线。未来高端推理系统可能同时包含：片上 SRAM/寄存器承接 tile，中间 HBM 承接热权重和热 KV，HBF/CXL 承接大容量可复用状态，远端存储承接冷数据；调度器根据请求和模型结构在这些层之间搬动数据。

对 Jalapeño 的回看：热路径专用化只是第一层答案#

回到 Jalapeño，它没有试图发明一种全新的容量层，而是把可控的推理热路径做到极致：HBM4、slice-local memory view、简化 NoC、collective network、Gluon、AI 写 kernel、本地 KV。这个选择很合理，因为 OpenAI 最先要解决的是 ChatGPT 级在线推理的每瓦 token 产出。

但 Talk 后半段提醒我们：当上下文拉到百万级、专家池继续膨胀、prefix cache 成为生产系统的主要收益来源，仅靠 HBM4 和 ASIC 热路径并不够。热路径决定单 token 延迟的下界，容量层决定系统能同时容纳多少上下文、专家和可复用状态。下一代推理芯片的竞争，不只是「谁的矩阵阵列更快」，而是「谁把热带宽、冷容量、近存计算、网络和调度拼得更好」。

小结#

HotChip/FMS 的内存侧内容可以归结为五句话：

• AI 推理把内存从性能瓶颈推成成本瓶颈，HBM 供给、封装和功耗都会进入 TCO；
• 计算扩展快于 HBM 带宽扩展，decode 阶段的内存下界会越来越显眼；
• HBM base die 正从接口层变成逻辑扩展层，memory controller、RAS、repair、near-memory function 会逐渐下沉；
• 3D-DRAM 用短垂直 I/O 拉高带宽和容量，但必须同时解决 bank mapping、I/O power wall 和 thermal reliability；
• PIM、CXL-PNM、HBF 都是在承认同一件事：未来推理系统必须是分层内存系统，不能把所有数据都塞进 HBM 热路径。

下一篇继续看 HBF：它为什么不是「便宜版 HBM」，OCP HBF spec 的通道/地址/读写模型意味着什么，以及 HBF-Compass 如何判断哪些 workload 适合 HBM/HBF 混合架构。

参考资料#

1. 本站：OpenAI Jalapeño 完全拆解
2. 本站：H³ 完全拆解：HBM 与高带宽闪存（HBF）混合架构如何驯服长上下文推理的内存墙
3. 本站：Hot Chips 2026 全景拆解：Agentic AI 时代，CPU、GPU 与内存的重新分工
4. 本站：DualPath 完全拆解：双路径 KV-Cache 加载
5. 本站：DeepSeek 3FS 完全拆解：链式复制、用户态零拷贝与 KVCache 磁盘缓存