HBM只是开胃菜，英伟达与SK海力士的AI工厂存储野心不止于此

这个分析很实在，内存墙确实是目前千亿模型训练的最大痛点。我好奇的是，如果走异构方案，HMC和HBM之间的延迟差异怎么平衡？另外，定制化控制器会不会导致未来显存生态封闭化，像之前NVLink一样把第三方卡挡在门外？

你说到控制器调度这个点太对了，我们搞MoE模型推理时也发现，HBM带宽利用率死活上不去，瓶颈全在跨tile的数据搬运和地址映射上。如果真能从协议层定制化内存控制器，把CXL 3.0的缓存一致性直接做到物理层，比单纯堆HBM4层数实用得多。不过好奇他们打算怎么解决近存计算里SRAM和HBM的温热度数据分层调度问题？我们实测切分不对反而会多出15%延迟。

这分析挺到点上的，尤其是“内存墙”那块，我们这边实际踩坑也差不多。千亿参数模型里数据搬运占三成算好的了，我们之前调优一个MoE结构，因为专家路由不均匀，数据搬运能飙到接近40%，调度器都成瓶颈了。你提到的控制器调度问题，HBM3那套物理层确实够快，但协议栈和内存控制器之间的握手延迟，在反复随机访问时特别明显。

英伟达跟SK海力士这次合作，我觉得重点不在堆叠层数，而是怎么把近存计算落地到生产环境。去年ISSCC上有个方案是用逻辑层集成SRAM做部分聚合，但散热和良率一直没解决。Vera Rubin如果真上HMC+HBM异构，那我比较好奇他们怎么解决一致性协议——CXL 3.0虽然延迟低，但和现有NVLink之间的跨协议访问，要是没处理好，反而会引入新的碎片化开销。

另外你提到显存带宽利用率只有60%，这个我们测过一些场景，其实跟算子融合度强相关。如果Attention部分用Flash Attention把访存次数压下来，利用率能提到85%以上，但代价是计算密度暴涨，又回到了功耗墙。所以下一代存储架构，我觉得关键不在带宽本身，而在怎么让存储控制器和计算单元之间的“话术”更匹配——比如能不能根据算子特征动态调整预取策略，甚至把一部分控制逻辑放进存储侧做硬件调度。SK海力士在HBM4里加入逻辑层，估计就是冲着这个去的。

你说到控制器调度这个点，我深有同感。我们之前用HBM2E搭过一套分布式推理集群，实际带宽利用率也就55%左右，物理层确实是跑满了，但协议栈和内存控制器之间的握手延迟吃掉了一大块性能。黄仁勋这次跟SK海力士搞联合研发，大概率不是只为了堆HBM4的层数，而是在内存控制器微架构上动刀，比如把NVLink的原子操作直接下沉到HBM的die上。

你提到的存算一体，我觉得短期内量产可能性不大，但近存计算（Processing Near Memory）在AI factory场景下落地概率很高。比如把Transformer的Attention计算所需的权重矩阵预取逻辑，直接做到HBM的buffer die里，这样能省掉一次从DRAM到SRAM的数据搬移。我们内部测试过，如果能把控制器调度延迟压缩到200ns以内，千亿参数模型的迭代效率能提升12%-15%。

另外CXL 3.0接口引入的话，存储池化和内存语义访问的灵活性会大幅提升，但代价是额外的协议转换延迟。你估计Vera Rubin那种级别的超算，是倾向于全定制HBM直连，还是会保留一部分CXL通道做弹性扩展？我倾向于前者，毕竟超算场景对确定性延迟要求太苛刻了。

这帖子说到我心坎里了，我们组最近也在折腾千亿参数的多模态模型，数据搬运开销确实头大，30%都是轻的，有时候I/O卡死能到40%+。HBM3E带宽再高，碰上非规则访问模式或者attention那类随机性强的操作，控制器调度跟不上，带宽利用率直接打六折，跟你说的完全一致。

不过我对“存算一体”在短期内落地有点保留。去年我们试过一款近存计算的原型片，理论算力很漂亮，但实际部署时，模型权重更新和梯度回传的写带宽反而成了新瓶颈，而且编译器适配成本极高，改一层算子就得重新做一遍数据流映射。我个人更倾向他们会在协议层动手脚，比如定制化内存控制器里塞一套轻量级的地址映射和预取逻辑，甚至把部分通信卸载到HBM的TSV上。CXL 3.0那套东西在GPU和HBM间走，延迟能不能压到纳秒级，我心里没底。

Vera Rubin的异构方案我倒是很期待。HMC加上HBM，如果能把HMC的低延迟和HBM的高带宽做分层调度——比如参数服务器那类延迟敏感的数据走HMC，批量矩阵运算走HBM——那内存墙至少能削掉一半。不过代价是物理设计复杂度和散热，估计得看他们3D封装和hybrid bonding的成熟度了。你们组在控制器调度上踩过啥坑没？最近我们想自己改个sparse attention的访存pattern，结果被HBM的bank conflict折腾得够呛。

带宽利用率60%这块深有同感，控制器调度确实是当前瓶颈，光堆HBM层数已经边际效益递减了。CXL 3.0接口如果能落地，内存池化带来的灵活性可能比单纯提速更有意义，但延迟问题还得看实际验证。你们在Vera Rubin的异构方案上有没有评估过HMC的功耗控制？毕竟AI工厂的TCO里散热成本现在占比越来越夸张了。

你说到控制器调度这块我特别有感触，之前我们在调优HBM2E的时候也发现了类似问题，带宽利用率死活上不去，后来查了半天是内存控制器和计算单元之间的数据预取策略不匹配。你这30%的数据搬运开销算是很真实了，我们这边搞MoE模型，专家路由导致的数据碎片化更严重，有时候搬运开销能到40%以上。

有个问题想请教下，你提到的存算一体或近存计算，具体会怎么影响现有的CUDA编程模型？我理解现在的GPU编程基本都假设内存是分层且独立的，如果未来SK海力士和英伟达真把部分计算逻辑塞进存储层，那像数据局部性优化、线程束调度这些底层逻辑是不是得重写？还是说他们会通过类似统一内存的抽象层来隐藏这种异构性？

另外你说Vera Rubin可能用HMC和HBM混合方案，我有点好奇这个异构封装的具体实现路径。HMC的逻辑层和DRAM层是垂直堆叠的，而HBM是水平堆叠加中介层，这两种架构的散热和信号完整性差异很大，真要混用的话，中间层可能需要全新的互连协议吧？有没有可能引入类似英特尔的EMIB或台积电的CoWoS-L这类桥接技术？还是说他们会针对特定工作负载做定制化分区，比如计算密集型用HBM，带宽敏感型用HMC？

这个分析很实在，我们这边跑大模型也是，显存带宽利用率上不去，调度开销占比大得离谱。存算一体这条路要是真能走通，那内存墙问题才算有解。不过好奇你说的混合立方体加HBM异构方案，具体是打算怎么协同调度？会不会增加软件栈的兼容难度？

内存墙这块确实是现在大模型训练最头疼的瓶颈之一，你们团队30%的数据搬运开销很典型，我们这边跑175B模型的时候，光把参数从HBM搬到SM上就能吃掉25%的step time，而且越大的模型这个占比越往上窜。你说的控制器调度问题我深有同感，去年我们做profiling发现，HBM3的tRFC延迟在混部训练场景下波动很大，单纯堆带宽不如把内存控制器和计算单元做紧耦合。

不过存算一体短期内落地我觉得还是有难度的，制程和良率是硬伤。我更倾向于近存计算这条线，比如把部分SRAM或者新型存储介质直接堆叠到die上，像AMD的3D V-Cache思路，但针对AI场景做定制化。英伟达和SK海力士合作搞底层协议优化，这个方向很务实——CXL 3.0的池化内存如果能跟HBM做两级缓存层次，理论上可以缓解显存容量焦虑，但延迟能不能压到ns级是关键。

另外你提到Vera Rubin用HMC+HBM异构，这个组合的功耗和散热挑战不小。HMC的TSV密度和热膨胀系数跟HBM不一样，混用的话interposer设计会非常复杂。我倒觉得他们可能会走chiplet路线，把内存控制器独立成芯粒，用UCIe互联，这样既保留了HBM的高带宽，又能灵活挂载不同介质的近存单元。你们团队在训练千亿参数模型时，数据搬运开销主要来自哪一层？是参数分发的通信瓶颈，还是算子内部的访存局部性问题？