通信分析师别瞎解读了！HBM4E降级，光模块的逻辑可能比你们想的更脆！

开篇：看到那些解读，我真的没绷住

兄弟们，今天刷到几篇通信分析师关于Rubin平台和光模块需求的解读，说实话，我没绷住。

洋洋洒洒几千字，从HBM扯到光模块，从NVLink扯到以太网，看着头头是道。但仔细一琢磨，连GPU的显存传输需求都没彻底搞明白，就在那喊“光进存退”。

这事儿说起来有点绕，但逻辑链条其实很清晰：HBM速率 → GPU显存吞吐 → 节点间互联带宽需求。

今天咱们就把这条链拆开来看。看完你就明白，为啥那些分析师的结论站不住脚，以及Rubin如果用HBM4而不是HBM4E，对光通信产业链的影响到底有多大。

第一部分：先搞清楚HBM4和HBM4E的差距

先上硬货。

下一代Rubin Ultra目前传的HBM4版本有四个——HBM4 8Hi/12Hi，HBM4E 8Hi/12Hi。

这里面有个关键区别：

• HBM4的I/O传输速率大概11-12Gbps

• HBM4E的I/O大概14-16Gbps

差了多少？差不多30%的带宽差距。

如果Rubin最终用的是HBM4 12Hi（而不是HBM4E 12Hi），8颗HBM配置下，GPU总带宽从~32TB/s降到~22TB/s，下降了约30%。

30%是什么概念？就是你本来有一条8车道的高速公路，突然变成了5.6车道。车还是那些车，但路变窄了。

第二部分：三层传输链路，一层层扒

接下来咱们把GPU的数据传输链路分三层看。

第一层：GPU显存吞吐——决定“数据产生的上限”

训练大模型的时候，All-Reduce这种通信操作的量，本质上由模型参数规模决定。但显存带宽决定了GPU能多快把参数从显存搬到NoC/NVLink接口。

说白了，显存带宽就是工厂的原材料到货速度。原材料来得慢，后边的生产线再快也白搭。

如果HBM4E降级成HBM4，原材料到货速度直接砍掉30%。GPU喂给互联网络的数据速率，天然就有了天花板。

第二层：NVLink域内消化——大部分流量根本出不去

Rubin平台内部NVLink速率极高（NVLink 6），大部分All-Reduce通信在节点内或者NVL机架内就完成了。

这就好比一个大型工厂，原材料进来之后，大部分在半成品车间内部就流转完了，真正需要装车发到外地的，只是一小部分。

真正溢出到以太网光互联的，是跨机架（scale-out）层面的流量。

第三层：光模块需求——最终的“出口”有多大？

这里有个关键比例——“机架内HBM总带宽 : 机架间出口带宽”。

以Vera Rubin NVL72为例：

• 机架内HBM总带宽：1,580 TB/s（72颗GPU × ~22TB/s）

• 机架间出口带宽：Spectrum-6 CPO交换机，单芯片102.4T，整个机架出口估计在数Tbps量级

看到差距了吗？1,580 TB/s对几Tbps——差了三个数量级。

机架内带宽是“大河”，机架间出口是“小溪”。如果大河的水位降了30%，小溪里的水还能有多少？

中场休息：用一个比喻把这事儿说透

打个比方你就懂了。

假设一个大型数据中心是一个超级工厂：

• HBM是原材料仓库

• GPU是加工车间

• NVLink域内是工厂内部传送带

• 光模块/以太网是通往全国各地的物流车队

如果原材料仓库的出货速度下降30%（HBM4E降级成HBM4），加工车间的产出自然下降，工厂内部传送带（NVLink）消化掉大部分，但最后需要发往外地的货物（光互联流量）——你觉得不会减少吗？

那些分析师说“光进存退”，意思是存储不行了光通信还能顶上去。但如果存储带宽本身就是整个链条的起点，源头的水位都降了，下游的河道怎么可能不受影响？

第三部分：三种配置，三种结局

咱们按最坏到最好的顺序，把三种配置方案的结果推演一遍。

方案一：HBM4 8Hi（最坏情况）

这是主动减配，不是良率问题，是主动降低规格。

8颗配置下，总带宽比HBM4E 12Hi下降超过30%。而且连HBM4的满血版（12Hi）都没上，直接上了个砍了一刀的版本。

对存储的影响：利空。对光通信的影响：利空。对市场预期的影响：巨大的落差。

因为市场之前普遍预期Rubin会上HBM4E，如果最终出来的是8Hi HBM4，这就是双重不及预期。

方案二：HBM4 12Hi（中间情况）

只用HBM4 12Hi，没用HBM4E。带宽比4E版本下降约30%，但至少是满血的HBM4。

对存储的影响：中性偏空（虽然没减配，但也没升级）。对光通信的影响：偏利空（机架内带宽上限下降，出口流量必然受影响）。

这个方案的问题是：市场之前没有充分price in“不上4E”这个变量。 如果最终真的没上4E，光模块产业链的预期需要向下修正。

方案三：HBM4E 8Hi/12Hi（最好的情况）

上了HBM4E，哪怕是8Hi版本，至少I/O速率是14-16Gbps的级别，带宽明显高于HBM4。

为什么4E的8Hi可能比4的12Hi还值得关注？因为I/O速率本身决定了数据传输的效率，而不只是堆叠层数。

4E哪怕只用8Hi，对光通信也是明确利好——机架内带宽上限更高，溢出到机架间的数据流自然更大。对存储也是利好，因为更高规格的HBM意味着更高的价值和更紧的供需。

第四部分：英伟达会怎么选？答案其实挺明显的

从英伟达的角度看，它一定会尽力推HBM4E，而不是在HBM4上躺平。

为什么？因为英伟达的商业逻辑从来都是：用最强的算力+最强的互联，构建最强的整体方案，然后卖最贵的价格。

如果Rubin用了HBM4而不是HBM4E，整个GPU的吞吐率就卡在了一个低一档的水平上。这直接影响的就是英伟达“下一代产品性能翻倍”的叙事。

而这个叙事一旦被戳破，影响的就不只是光模块的需求预期，而是整个AI算力产业链的估值逻辑。

所以，英伟达有强烈的动机去推HBM4E，哪怕初期良率不高、成本不低。

结尾：别被“光进存退”这种简单叙事带偏了

最后总结一下。

第一，HBM速率是整个链条的起点。 起点带宽下降30%，后边的NVLink域内和以太网出口都不可能不受影响。这不是“光进存退”能解释的，这是“一荣俱荣、一损俱损”。

第二，四种配置方案的结局完全不同。 如果上了HBM4E，光通信和存储都是利好；如果上了HBM4 12Hi，光通信会低于预期；如果上了8Hi HBM4，那是双重利空。关键看英伟达最后选哪条路。

第三，市场目前可能还没充分price in“不上4E”的变量。 如果最终Rubin的方案是HBM4而不是HBM4E，光模块产业链的预期差需要修正。

当然，英伟达大概率会想办法推HBM4E。但如果因为良率、成本或者供应链的原因，最终没能上4E，那单机柜光传输带宽需求下降，就不是“会不会”的问题，而是“什么时候被发现”的问题。

那些喊着“光进存退”的分析师，可能连这层逻辑都没捋清楚。

搞清楚这条链条，你至少比他们高一个段位。