1. 万卡超节点到底卡在哪从电互连的物理天花板说起聊光互连之前得先把万卡超节点这个词拆开看。所谓超节点本质上是把过去分散在多个机柜、多个交换机层级里的大量加速器通过更高带宽、更低延迟的互连网络在逻辑上捏成一个整体。当这个规模从千卡级推到万卡级问题就不再是多插几块网卡那么简单了。我做集群网络调优那几年最直观的感受是算力芯片的迭代速度远远快于互连介质的迭代速度。单颗芯片的算力每代翻倍但传统铜缆电互连的带宽密度和传输距离基本已经摸到了物理极限。具体卡在三个地方。第一是带宽密度。电信号在PCB走线和铜缆里传输频率越高趋肤效应和介质损耗越严重。到了112Gbps这个速率铜缆的有效传输距离被压缩到一两米以内再远就得靠重定时器续命而重定时器本身又带来功耗和延迟。万卡集群里跨机柜、跨列甚至跨排的连接比比皆是纯铜方案根本铺不开。第二是功耗墙。电互连的功耗和速率基本是线性甚至超线性关系。一个万卡集群里光是SerDes和交换芯片的功耗就能占到整个系统功耗的相当比例。散热压力传导到机房侧就是供电和制冷成本飙升。第三是延迟与拥塞。多级电交换带来的跳数增加让集合通信操作比如AllReduce的尾延迟变得很难控制。训练大模型时通信时间占比一旦超过某个阈值加再多的卡也换不来线性加速这就是所谓的通信墙。光互连之所以在这个节点被反复提起是因为光信号在光纤里的损耗极低传输距离可以轻松做到几百米甚至几公里而且波分复用能让一根光纤承载多路信号带宽密度天然占优。海思光电在CIOE芯光论坛上抛出的全栈光互连方案针对的就是从芯片间、板间、机柜间到集群间这一整条链路的替换问题。注意全栈两个字它不是只做某一个环节的光模块而是把光引擎、光交换、光互连架构一起考虑这才是万卡超节点真正需要的。2. 全栈光互连的四个层次海思光电方案拆解全栈这个词容易被滥用但放在光互连语境下它其实有非常明确的层次划分。我结合论坛披露的信息和行业通用架构把它拆成四层来看这样你在评估任何一家厂商的光互连方案时都能套用这个框架。2.1 芯片级光互连把光引擎搬到封装旁边最底层是芯片到芯片的光互连。传统做法是芯片出电信号经过PCB走线到面板上的可插拔光模块再由模块完成电光转换。这条路径太长电信号在PCB上的损耗和功耗都不可忽视。海思光电的思路是把光引擎Optical Engine尽可能靠近计算芯片也就是业界常说的CPOCo-Packaged Optics共封装光学方向。光引擎和交换ASIC或计算芯片封装在同一个基板上电信号只需要走几毫米的基板走线就能完成电光转换损耗和功耗大幅下降。这里有个关键参数值得关注每比特能耗。可插拔光模块方案下整个链路含SerDes、PCB、模块的每比特能耗通常在10~15皮焦耳每比特这个量级CPO方案理论上能压到5皮焦耳每比特以下。别小看这个数字万卡集群里每秒传输的比特数是天文数字每比特省几皮焦耳乘下来就是几十千瓦的差距。注意CPO的工程难点不在光引擎本身而在封装良率和可维护性。光引擎和ASIC共封装后一旦光引擎失效整个封装件可能都要报废。所以海思这类方案通常会配套可插拔的光纤连接器让光纤部分可现场维护这是实操中必须确认的细节。2.2 板级与机柜内光互连AOC和光背板的取舍往上一层是板间和机柜内的连接。这一层目前主流还是AOCActive Optical Cable有源光缆也就是两端带光模块、中间是光纤的光缆。AOC的好处是即插即用兼容现有电接口运维习惯不用大改。但到了万卡超节点机柜内的连接密度极高AOC一根根插过去面板空间和理线都是灾难。所以海思方案里提到了光背板Optical Backplane的概念——把光纤做成背板形态机柜内的板卡通过盲插连接器直接对接光背板省掉大量面板光口和线缆。光背板的实操难点在于盲插对准精度和连接器寿命。一个机柜内可能有几十块板卡每块板卡上几十个光连接点插拔一次的对准误差必须控制在微米级。我见过一些项目因为连接器对准问题导致光功率波动误码率时好时坏排查起来非常痛苦。选型时一定要问清楚连接器的插拔寿命指标和对准容差。2.3 机柜间光互连光交换替代电交换的临界点再往上是机柜之间也就是超节点内部跨机柜的连接。这一层传统上靠电交换机做多级CLOS组网但万卡规模下电交换的功耗和延迟成了瓶颈。海思光电提到的全栈方案里光交换Optical Switching是重要一环。光交换的好处是信号在光域直接切换不需要光电光转换延迟极低且与速率无关。但光交换的短板也很明显光开关的切换速度目前还赶不上电交换而且光缓存几乎不可能实现所以光交换更适合做大颗粒、长持续的连接调度而不是细粒度的包交换。实际部署中比较务实的做法是光电混合高频、小颗粒的通信走电交换低频、大流量的通信比如检查点写入、参数同步走光交换。海思方案里应该也是类似的分层调度思路具体比例要根据你的训练任务通信模式来调。2.4 集群间光互连DCI与长距传输最外层是集群之间的连接也就是DCIData Center Interconnect场景。这一层距离从几公里到几十公里不等必须用相干光通信。海思光电在光模块和光芯片上有长期积累这部分方案相对成熟核心是相干光模块的速率和集成度。对万卡超节点来说集群间互连的关键指标是有效带宽和时延抖动。如果多个超节点需要协同训练一个超大模型集群间的同步开销会直接吃掉算力。所以这一层通常会用波分复用把多路信号复用到一根光纤上同时用相干检测提升接收灵敏度。3. 光互连方案选型时我踩过的那些坑讲完架构说点实在的。光互连方案听起来很美但落地时坑不少。我把自己和同行踩过的坑整理出来你在做方案评估时可以直接对照。3.1 只看峰值带宽忽略有效带宽厂商宣传页上写的都是峰值带宽比如单端口800G整机51.2T。但实际跑训练任务时你拿到的是有效带宽中间要扣掉协议开销、前向纠错开销、重传开销。我做过一个对比测试同样标称400G的端口A厂商方案在AllReduce场景下的有效带宽只有标称的65%左右B厂商能到78%。差距来自FEC编码效率、SerDes均衡能力和流控机制。所以选型时一定要拿自己的实际通信模式去压测别信标称值。指标标称值实测有效值差距来源端口带宽400G260~310GFEC开销、协议头、重传端口时延100ns150~400ns交换跳数、排队、光引擎处理每比特能耗5pJ/bit7~12pJ/bit实际负载率、温漂补偿3.2 忽视光模块的温漂和寿命光模块对温度非常敏感。激光器的波长会随温度漂移虽然模块内部有TEC热电制冷器做温控但TEC本身耗电而且长期工作在高温环境下激光器寿命会大幅缩短。我遇到过一批光模块在机房空调正常时误码率很低但一到夏天机房温度上到28度以上误码率就明显上升。后来查出来是模块的温控余量不足。所以选型时要看模块的工作温度范围和温控余量别只看常温指标。提示光模块的寿命通常用MTBF平均无故障时间衡量但MTBF是统计值不代表你的模块一定能用那么久。实际部署中建议预留10%~15%的备件并且定期用光功率计抽检发射光功率和接收灵敏度。3.3 光背板的对准和维护问题前面提过光背板的盲插对准问题这里展开说。光背板方案在实验室里跑得很漂亮但到了现场机柜运输振动、板卡热胀冷缩、连接器反复插拔都会导致对准偏移。一个实用的经验是优先选带主动对准或浮动连接器的方案。浮动连接器允许一定范围的机械偏差靠弹簧或弹性结构补偿。另外光背板的清洁维护比可插拔模块麻烦得多一旦有灰尘污染整块背板可能都要拆下来清洁。所以机房环境的洁净度管理必须跟上。3.4 光交换的调度算法不成熟光交换的硬件本身已经比较成熟但配套的调度算法还在演进。光开关的切换时间是毫秒级而电交换是纳秒级如果调度算法不能把大流量通信聚合成持续的光路光交换的利用率会很低。我见过一个项目光交换设备买回来大半年实际利用率不到20%因为调度算法还是按电交换的思路做细粒度调度光路频繁切换开销比收益还大。后来改成按训练迭代周期做粗粒度调度利用率才上去。所以光交换方案一定要配套问清楚调度软件的能力。4. 万卡超节点光互连的部署实操要点如果你正在规划或部署万卡级超节点下面这些实操要点可以直接参考。我按部署流程的顺序来梳理。4.1 拓扑设计先定通信模式再定互连拓扑很多人一上来就纠结用几层CLOS、用多少光模块其实顺序反了。正确的做法是先分析你的训练任务通信模式。大模型训练主要是集合通信包括AllReduce、AllGather、ReduceScatter等。不同并行策略数据并行、张量并行、流水线并行对通信模式的要求完全不同。数据并行以AllReduce为主通信量大但模式规整张量并行通信更频繁对延迟更敏感。拓扑设计要匹配通信模式。如果以AllReduce为主可以用胖树或轨道优化拓扑让集合通信的流量尽量走短路径。如果张量并行占比高可能需要更密集的机柜内互连把通信频繁的卡放在同一机柜或相邻机柜。4.2 光模块选型速率、封装、协议一个都不能少光模块选型要同时看三个维度速率、封装形式、协议兼容性。速率方面当前主流是400G和800G下一代是1.6T。选速率不是越高越好要看你的交换芯片和网卡能不能匹配。800G模块插在只支持400G的交换机上要么降速跑要么直接不识别。封装方面可插拔模块如QSFP-DD、OSFP和CPO各有适用场景。可插拔胜在可维护性和兼容性CPO胜在功耗和密度。万卡超节点里机柜内短距连接可以优先考虑CPO或AOC机柜间长距连接用可插拔相干模块。协议方面要确认模块支持你的上层协议比如以太网、InfiniBand或厂商私有协议。协议不匹配会导致链路起不来或者性能大打折扣。4.3 光纤布线别让理线毁了一个好方案光纤布线是容易被低估的环节。万卡集群里光纤数量可能上万根如果理线没做好后期维护就是噩梦。几个实操建议第一按机柜和功能分区用不同颜色的光纤跳线比如计算互连用黄色、存储互连用蓝色、管理网用绿色一眼就能区分。第二光纤弯曲半径必须严格遵守通常要求不小于光纤外径的10倍弯得太狠会导致光损耗剧增。第三预留足够的冗余长度但不要盘得太乱用理线架和魔术贴固定别用扎带勒死。4.4 测试验证分层测试逐段排除光互连部署完必须做分层测试不能只测端到端。分层测试的逻辑是先测单根光纤和单个模块再测单条链路再测机柜内互连最后测跨机柜和跨集群。单模块测试用光功率计和误码仪确认发射光功率、接收灵敏度、误码率在规格内。链路测试用环回或打流工具确认整条链路能跑满带宽。系统级测试用实际的集合通信基准如NCCL Tests确认AllReduce等操作的带宽和延迟达标。分层测试的好处是一旦出问题你能快速定位是哪一层的问题而不是对着整个集群抓瞎。5. 从CIOE芯光论坛看光互连的下一步走向CIOE芯光论坛上海思光电的全栈光互连方案其实释放了几个信号值得关注。第一个信号是光互连从可选变成必选。过去光互连主要用在长距和骨干网现在万卡超节点把光互连推到了芯片间和板间。这个趋势不可逆因为电互连的物理极限摆在那里。第二个信号是全栈能力成为竞争壁垒。只做光模块的厂商很难解决芯片级、板级、机柜级、集群级的协同问题。海思光电强调全栈说明它想打通从光芯片到光引擎到光交换到系统架构的整条链路。对用户来说全栈方案的好处是兼容性和协同优化更好但也要注意供应商锁定的风险。第三个信号是光电混合是长期状态。光交换不会完全取代电交换CPO不会完全取代可插拔模块。未来几年光电混合、分层调度会是主流。做方案规划时要预留光电混合的接口和调度能力别把宝全押在纯光或纯电上。从实操角度我建议你在规划万卡超节点时把光互连当作一个独立的子系统来设计而不是当成网卡的附属品。光互连的拓扑、模块选型、布线、测试、运维都需要专门的团队和流程。越早把这块重视起来后期踩的坑越少。最后分享一个我在实际项目中的体会光互连方案的性能三分靠硬件七分靠调优。同样的模块和拓扑不同的FEC配置、流控参数、调度策略实测性能能差出30%以上。所以别指望买回来插上就能跑满预留足够的调优时间和人力这才是万卡超节点光互连落地的真实状态。 万卡超节点光互连全栈方案：从电互连瓶颈到光电混合部署实践
1. 万卡超节点到底卡在哪从电互连的物理天花板说起聊光互连之前得先把万卡超节点这个词拆开看。所谓超节点本质上是把过去分散在多个机柜、多个交换机层级里的大量加速器通过更高带宽、更低延迟的互连网络在逻辑上捏成一个整体。当这个规模从千卡级推到万卡级问题就不再是多插几块网卡那么简单了。我做集群网络调优那几年最直观的感受是算力芯片的迭代速度远远快于互连介质的迭代速度。单颗芯片的算力每代翻倍但传统铜缆电互连的带宽密度和传输距离基本已经摸到了物理极限。具体卡在三个地方。第一是带宽密度。电信号在PCB走线和铜缆里传输频率越高趋肤效应和介质损耗越严重。到了112Gbps这个速率铜缆的有效传输距离被压缩到一两米以内再远就得靠重定时器续命而重定时器本身又带来功耗和延迟。万卡集群里跨机柜、跨列甚至跨排的连接比比皆是纯铜方案根本铺不开。第二是功耗墙。电互连的功耗和速率基本是线性甚至超线性关系。一个万卡集群里光是SerDes和交换芯片的功耗就能占到整个系统功耗的相当比例。散热压力传导到机房侧就是供电和制冷成本飙升。第三是延迟与拥塞。多级电交换带来的跳数增加让集合通信操作比如AllReduce的尾延迟变得很难控制。训练大模型时通信时间占比一旦超过某个阈值加再多的卡也换不来线性加速这就是所谓的通信墙。光互连之所以在这个节点被反复提起是因为光信号在光纤里的损耗极低传输距离可以轻松做到几百米甚至几公里而且波分复用能让一根光纤承载多路信号带宽密度天然占优。海思光电在CIOE芯光论坛上抛出的全栈光互连方案针对的就是从芯片间、板间、机柜间到集群间这一整条链路的替换问题。注意全栈两个字它不是只做某一个环节的光模块而是把光引擎、光交换、光互连架构一起考虑这才是万卡超节点真正需要的。2. 全栈光互连的四个层次海思光电方案拆解全栈这个词容易被滥用但放在光互连语境下它其实有非常明确的层次划分。我结合论坛披露的信息和行业通用架构把它拆成四层来看这样你在评估任何一家厂商的光互连方案时都能套用这个框架。2.1 芯片级光互连把光引擎搬到封装旁边最底层是芯片到芯片的光互连。传统做法是芯片出电信号经过PCB走线到面板上的可插拔光模块再由模块完成电光转换。这条路径太长电信号在PCB上的损耗和功耗都不可忽视。海思光电的思路是把光引擎Optical Engine尽可能靠近计算芯片也就是业界常说的CPOCo-Packaged Optics共封装光学方向。光引擎和交换ASIC或计算芯片封装在同一个基板上电信号只需要走几毫米的基板走线就能完成电光转换损耗和功耗大幅下降。这里有个关键参数值得关注每比特能耗。可插拔光模块方案下整个链路含SerDes、PCB、模块的每比特能耗通常在10~15皮焦耳每比特这个量级CPO方案理论上能压到5皮焦耳每比特以下。别小看这个数字万卡集群里每秒传输的比特数是天文数字每比特省几皮焦耳乘下来就是几十千瓦的差距。注意CPO的工程难点不在光引擎本身而在封装良率和可维护性。光引擎和ASIC共封装后一旦光引擎失效整个封装件可能都要报废。所以海思这类方案通常会配套可插拔的光纤连接器让光纤部分可现场维护这是实操中必须确认的细节。2.2 板级与机柜内光互连AOC和光背板的取舍往上一层是板间和机柜内的连接。这一层目前主流还是AOCActive Optical Cable有源光缆也就是两端带光模块、中间是光纤的光缆。AOC的好处是即插即用兼容现有电接口运维习惯不用大改。但到了万卡超节点机柜内的连接密度极高AOC一根根插过去面板空间和理线都是灾难。所以海思方案里提到了光背板Optical Backplane的概念——把光纤做成背板形态机柜内的板卡通过盲插连接器直接对接光背板省掉大量面板光口和线缆。光背板的实操难点在于盲插对准精度和连接器寿命。一个机柜内可能有几十块板卡每块板卡上几十个光连接点插拔一次的对准误差必须控制在微米级。我见过一些项目因为连接器对准问题导致光功率波动误码率时好时坏排查起来非常痛苦。选型时一定要问清楚连接器的插拔寿命指标和对准容差。2.3 机柜间光互连光交换替代电交换的临界点再往上是机柜之间也就是超节点内部跨机柜的连接。这一层传统上靠电交换机做多级CLOS组网但万卡规模下电交换的功耗和延迟成了瓶颈。海思光电提到的全栈方案里光交换Optical Switching是重要一环。光交换的好处是信号在光域直接切换不需要光电光转换延迟极低且与速率无关。但光交换的短板也很明显光开关的切换速度目前还赶不上电交换而且光缓存几乎不可能实现所以光交换更适合做大颗粒、长持续的连接调度而不是细粒度的包交换。实际部署中比较务实的做法是光电混合高频、小颗粒的通信走电交换低频、大流量的通信比如检查点写入、参数同步走光交换。海思方案里应该也是类似的分层调度思路具体比例要根据你的训练任务通信模式来调。2.4 集群间光互连DCI与长距传输最外层是集群之间的连接也就是DCIData Center Interconnect场景。这一层距离从几公里到几十公里不等必须用相干光通信。海思光电在光模块和光芯片上有长期积累这部分方案相对成熟核心是相干光模块的速率和集成度。对万卡超节点来说集群间互连的关键指标是有效带宽和时延抖动。如果多个超节点需要协同训练一个超大模型集群间的同步开销会直接吃掉算力。所以这一层通常会用波分复用把多路信号复用到一根光纤上同时用相干检测提升接收灵敏度。3. 光互连方案选型时我踩过的那些坑讲完架构说点实在的。光互连方案听起来很美但落地时坑不少。我把自己和同行踩过的坑整理出来你在做方案评估时可以直接对照。3.1 只看峰值带宽忽略有效带宽厂商宣传页上写的都是峰值带宽比如单端口800G整机51.2T。但实际跑训练任务时你拿到的是有效带宽中间要扣掉协议开销、前向纠错开销、重传开销。我做过一个对比测试同样标称400G的端口A厂商方案在AllReduce场景下的有效带宽只有标称的65%左右B厂商能到78%。差距来自FEC编码效率、SerDes均衡能力和流控机制。所以选型时一定要拿自己的实际通信模式去压测别信标称值。指标标称值实测有效值差距来源端口带宽400G260~310GFEC开销、协议头、重传端口时延100ns150~400ns交换跳数、排队、光引擎处理每比特能耗5pJ/bit7~12pJ/bit实际负载率、温漂补偿3.2 忽视光模块的温漂和寿命光模块对温度非常敏感。激光器的波长会随温度漂移虽然模块内部有TEC热电制冷器做温控但TEC本身耗电而且长期工作在高温环境下激光器寿命会大幅缩短。我遇到过一批光模块在机房空调正常时误码率很低但一到夏天机房温度上到28度以上误码率就明显上升。后来查出来是模块的温控余量不足。所以选型时要看模块的工作温度范围和温控余量别只看常温指标。提示光模块的寿命通常用MTBF平均无故障时间衡量但MTBF是统计值不代表你的模块一定能用那么久。实际部署中建议预留10%~15%的备件并且定期用光功率计抽检发射光功率和接收灵敏度。3.3 光背板的对准和维护问题前面提过光背板的盲插对准问题这里展开说。光背板方案在实验室里跑得很漂亮但到了现场机柜运输振动、板卡热胀冷缩、连接器反复插拔都会导致对准偏移。一个实用的经验是优先选带主动对准或浮动连接器的方案。浮动连接器允许一定范围的机械偏差靠弹簧或弹性结构补偿。另外光背板的清洁维护比可插拔模块麻烦得多一旦有灰尘污染整块背板可能都要拆下来清洁。所以机房环境的洁净度管理必须跟上。3.4 光交换的调度算法不成熟光交换的硬件本身已经比较成熟但配套的调度算法还在演进。光开关的切换时间是毫秒级而电交换是纳秒级如果调度算法不能把大流量通信聚合成持续的光路光交换的利用率会很低。我见过一个项目光交换设备买回来大半年实际利用率不到20%因为调度算法还是按电交换的思路做细粒度调度光路频繁切换开销比收益还大。后来改成按训练迭代周期做粗粒度调度利用率才上去。所以光交换方案一定要配套问清楚调度软件的能力。4. 万卡超节点光互连的部署实操要点如果你正在规划或部署万卡级超节点下面这些实操要点可以直接参考。我按部署流程的顺序来梳理。4.1 拓扑设计先定通信模式再定互连拓扑很多人一上来就纠结用几层CLOS、用多少光模块其实顺序反了。正确的做法是先分析你的训练任务通信模式。大模型训练主要是集合通信包括AllReduce、AllGather、ReduceScatter等。不同并行策略数据并行、张量并行、流水线并行对通信模式的要求完全不同。数据并行以AllReduce为主通信量大但模式规整张量并行通信更频繁对延迟更敏感。拓扑设计要匹配通信模式。如果以AllReduce为主可以用胖树或轨道优化拓扑让集合通信的流量尽量走短路径。如果张量并行占比高可能需要更密集的机柜内互连把通信频繁的卡放在同一机柜或相邻机柜。4.2 光模块选型速率、封装、协议一个都不能少光模块选型要同时看三个维度速率、封装形式、协议兼容性。速率方面当前主流是400G和800G下一代是1.6T。选速率不是越高越好要看你的交换芯片和网卡能不能匹配。800G模块插在只支持400G的交换机上要么降速跑要么直接不识别。封装方面可插拔模块如QSFP-DD、OSFP和CPO各有适用场景。可插拔胜在可维护性和兼容性CPO胜在功耗和密度。万卡超节点里机柜内短距连接可以优先考虑CPO或AOC机柜间长距连接用可插拔相干模块。协议方面要确认模块支持你的上层协议比如以太网、InfiniBand或厂商私有协议。协议不匹配会导致链路起不来或者性能大打折扣。4.3 光纤布线别让理线毁了一个好方案光纤布线是容易被低估的环节。万卡集群里光纤数量可能上万根如果理线没做好后期维护就是噩梦。几个实操建议第一按机柜和功能分区用不同颜色的光纤跳线比如计算互连用黄色、存储互连用蓝色、管理网用绿色一眼就能区分。第二光纤弯曲半径必须严格遵守通常要求不小于光纤外径的10倍弯得太狠会导致光损耗剧增。第三预留足够的冗余长度但不要盘得太乱用理线架和魔术贴固定别用扎带勒死。4.4 测试验证分层测试逐段排除光互连部署完必须做分层测试不能只测端到端。分层测试的逻辑是先测单根光纤和单个模块再测单条链路再测机柜内互连最后测跨机柜和跨集群。单模块测试用光功率计和误码仪确认发射光功率、接收灵敏度、误码率在规格内。链路测试用环回或打流工具确认整条链路能跑满带宽。系统级测试用实际的集合通信基准如NCCL Tests确认AllReduce等操作的带宽和延迟达标。分层测试的好处是一旦出问题你能快速定位是哪一层的问题而不是对着整个集群抓瞎。5. 从CIOE芯光论坛看光互连的下一步走向CIOE芯光论坛上海思光电的全栈光互连方案其实释放了几个信号值得关注。第一个信号是光互连从可选变成必选。过去光互连主要用在长距和骨干网现在万卡超节点把光互连推到了芯片间和板间。这个趋势不可逆因为电互连的物理极限摆在那里。第二个信号是全栈能力成为竞争壁垒。只做光模块的厂商很难解决芯片级、板级、机柜级、集群级的协同问题。海思光电强调全栈说明它想打通从光芯片到光引擎到光交换到系统架构的整条链路。对用户来说全栈方案的好处是兼容性和协同优化更好但也要注意供应商锁定的风险。第三个信号是光电混合是长期状态。光交换不会完全取代电交换CPO不会完全取代可插拔模块。未来几年光电混合、分层调度会是主流。做方案规划时要预留光电混合的接口和调度能力别把宝全押在纯光或纯电上。从实操角度我建议你在规划万卡超节点时把光互连当作一个独立的子系统来设计而不是当成网卡的附属品。光互连的拓扑、模块选型、布线、测试、运维都需要专门的团队和流程。越早把这块重视起来后期踩的坑越少。最后分享一个我在实际项目中的体会光互连方案的性能三分靠硬件七分靠调优。同样的模块和拓扑不同的FEC配置、流控参数、调度策略实测性能能差出30%以上。所以别指望买回来插上就能跑满预留足够的调优时间和人力这才是万卡超节点光互连落地的真实状态。