1. 万卡超节点时代光互连为什么突然成了香饽饽如果你这两年一直在关注智算集群的硬件演进应该能明显感觉到一个拐点单卡算力的提升速度已经追不上集群规模膨胀的速度了。以前大家聊的是单机八卡、NVLink互联现在动辄就是千卡、万卡级别的超节点集群。集群一大瓶颈立刻从“算力够不够”变成了“数据搬得动搬不动”。光互连这个词也就是在这个背景下从幕后走到了台前。我在CIOE芯光论坛上听到海思光电分享的全栈光互连方案时第一反应是终于有人把这件事从芯片到模块到系统层面串起来讲了。过去大家谈光互连要么只谈光模块的速率要么只谈交换芯片的容量很少有人把“全栈”两个字真正落地。海思光电这次讲的是从光芯片、光引擎、光模块到系统级互连架构的一整套东西目标很明确——让万卡级别的超节点集群里GPU之间的数据搬运不再成为拖后腿的环节。这篇文章适合谁看如果你是做智算集群规划的、做数据中心网络架构的、或者做光模块和光芯片选型的那这篇内容应该能给你一些实际的参考。如果你只是刚接触这个领域也没关系我会尽量用生活化的类比把里面的关键逻辑讲清楚。核心关键词就几个CIOE、芯光论坛、海思光电、光互连、超节点。围绕这几个词我把这次论坛上值得深挖的技术点和实操层面的思考整理出来。2. 超节点集群到底卡在哪光互连方案的整体设计思路2.1 从千卡到万卡铜缆为什么撑不住了先说说为什么超节点时代对光互连的需求这么迫切。你可以把智算集群想象成一个超大型的物流中心GPU是各个工位上的工人数据就是需要搬运的货物。在千卡规模的时候工位之间距离还不算太远用铜缆“搬货”勉强够用。但到了万卡规模工位数量暴增距离拉长铜缆的问题就暴露出来了。铜缆的第一个问题是传输距离。高速信号在铜缆里衰减得很快速率越高衰减越严重。到了800G这个级别铜缆的有效传输距离可能只有一两米这在万卡集群里根本不够用。第二个问题是功耗和体积。铜缆要传高速信号需要更强的驱动和均衡电路功耗上去了线缆也又粗又硬机柜内的布线很快就变成一团乱麻。第三个问题是密度万卡集群需要的互连链路数量是千卡的好几倍铜缆的物理密度根本塞不下。光互连解决的就是这几个问题。光纤的传输距离远、衰减低、体积小、重量轻同样一根线缆能承载的带宽是铜缆的好几倍。但光互连也不是没有代价光电转换带来的额外延迟、光模块的功耗和成本、以及系统级的光纤管理都是需要认真对待的工程问题。海思光电这次讲的全栈方案本质上就是在回答一个问题怎么把光互连的代价压到最低同时把它的优势发挥到最大。2.2 全栈方案的核心逻辑从芯片到系统一层层解耦我理解海思光电这个“全栈”的核心思路是把光互连拆成几个层次每一层都做针对性的优化而不是只盯着某一个环节猛攻。这就像盖房子你不能只把屋顶修得漂亮地基、承重墙、水电管线都得配套跟上。第一层是光芯片层。这是最底层的基础包括激光器、调制器、探测器这些核心器件。海思光电在光芯片上有自己的积累这次论坛上提到的方案里光芯片的集成度和性能直接决定了上层光引擎和光模块的上限。第二层是光引擎层把光芯片和驱动、放大等电路封装在一起形成可插拔或者板载的光引擎。第三层是光模块层把光引擎做成标准化的模块形态方便系统集成。第四层是系统互连层包括交换架构、光纤布线、散热设计等等。这个分层解耦的好处是每一层可以独立演进。光芯片的工艺进步了可以直接替换到现有的光引擎设计里系统层的交换架构升级了也不用推翻底层的芯片方案。这种模块化的思路在万卡集群这种大规模部署场景下特别重要因为任何一个小改动都可能被放大成千上万倍的成本和运维压力。2.3 为什么是海思光电来做这件事你可能会问光互连方案为什么是海思光电来牵头讲全栈我的观察是这跟他们在光通信领域的长年积累有关。海思光电在光芯片、光器件上有很深的技术储备同时他们又对系统级的需求理解得比较透因为背后有做计算和网络设备的经验。这种“从芯片到系统”的垂直整合能力在光互连这个领域其实是稀缺的。大部分做光模块的厂商强项在封装和制造但对上层系统架构的理解没那么深做交换芯片的厂商又不太会去碰光芯片这种底层器件。海思光电的位置比较特殊他们既有底层光芯片的能力又能站在系统层面去定义光互连的需求。这次论坛上他们讲的全栈方案我觉得最大的价值不是某一个单点技术有多惊艳而是把整个链条打通了让做集群规划的人有一个完整的参考架构可以照着落地。3. 光互连方案里的核心技术点一个个拆开看3.1 光芯片速率和集成度的平衡怎么找光芯片是整个光互连方案的起点也是技术门槛最高的环节之一。这次论坛上提到的光芯片方案我印象比较深的是他们在速率和集成度之间找平衡的思路。单通道速率从100G往200G走的时候调制器的设计难度会急剧上升。传统的分立方案在100G时代还能应付到了200G就有点力不从心了。海思光电的做法是把调制器和激光器做更紧密的集成减少中间的耦合损耗和寄生参数。这就像把原来分开摆放的厨房设备和食材处理台合并成一个整体操作台动线短了效率自然就高了。具体到参数上他们提到的方案里单通道200G的调制效率做到了比较理想的水平消光比和眼图质量都能满足长距离传输的要求。注意光芯片的选型不能只看单通道速率还要看整体功耗和良率。有些方案单通道速率很高但功耗和成本压不下来大规模部署的时候总拥有成本反而更高。3.2 光引擎和光模块可插拔还是板载这是个问题光引擎和光模块的形态选择是实际部署时绕不开的一个决策点。可插拔光模块的好处是维护方便坏了直接换一个就行但缺点是面板密度有限而且电接口的功耗和信号完整性挑战比较大。板载光引擎也叫CPO共封装光学的好处是密度高、功耗低但维护性差坏了可能整个板子都要换。海思光电这次讲的方案里两种形态都有覆盖但重点似乎在板载光引擎上。我的理解是万卡超节点集群对密度的要求太高了可插拔模块的面板空间根本不够用。板载方案虽然维护性差一些但在大规模部署场景下通过冗余设计和系统级的健康管理可以把维护风险控制住。这里有个实操层面的经验如果你在规划集群时纠结选哪种形态可以先算一笔账。假设一个机柜需要512个800G端口用可插拔模块的话面板空间和散热都是大问题用板载光引擎的话密度能提升好几倍但需要配套更复杂的液冷或者风冷方案。这个账算下来大规模集群里板载方案的优势会越来越明显。3.3 系统互连架构交换层级怎么设计才不浪费光纤系统互连架构是光互连方案里最容易被忽视、但实际上最影响整体成本的部分。万卡集群的互连拓扑有很多种选择胖树、蜻蜓、轨道优化等等每种拓扑对光模块的数量和光纤的用量都不一样。海思光电在论坛上提到的方案里我注意到他们在交换层级的设计上做了优化目标是在保证带宽收敛比的前提下尽量减少光模块和光纤的使用量。举个例子传统的三层胖树架构在万卡规模下核心层和汇聚层需要大量的光模块和长距离光纤。如果改成两层或者轨道优化的拓扑光模块的数量能减少不少但代价是布线复杂度上升对光模块的可靠性要求也更高。海思光电的方案里似乎是结合了他们在光模块上的技术优势在拓扑设计上做了针对性的适配。拓扑类型光模块用量布线复杂度适用规模带宽收敛比三层胖树高低千卡到万卡1:1到1:3两层胖树中中千卡以内1:1到1:5轨道优化低高万卡以上1:1到1:2蜻蜓拓扑中高万卡以上1:1到1:4这个表里的数据是基于常见实践的估算实际选型的时候还要结合具体的业务流量模型来算。比如训练任务如果是全规约密集型的带宽收敛比就不能太低否则通信会成为瓶颈。3.4 光纤管理和散热容易被低估的工程细节光互连方案落地的时候光纤管理和散热是两个特别容易被低估的环节。万卡集群里光纤的数量是千卡集群的好几倍如果布线没做好机柜后面就是一团乱麻维护的时候根本找不到对应的链路。海思光电的方案里提到了他们的光纤管理设计包括高密度的光纤连接器、预端接的线缆组件、以及智能化的链路标识。散热方面光模块的功耗虽然比铜缆方案低但万卡集群里光模块的总数量太大了累积起来的热量还是很可观的。板载光引擎因为离交换芯片更近散热设计需要更精细。海思光电提到的方案里似乎是用了液冷板加风冷的混合散热方式针对不同功耗密度的区域做差异化设计。提示光纤管理一定要在规划阶段就做好不要等到部署完了再整理。预端接的线缆组件虽然前期成本高一些但后期维护省下来的时间成本远超这个差价。4. 实际部署时怎么落地从规划到运维的完整流程4.1 集群规划阶段先算清楚带宽需求和收敛比落地光互连方案的第一步是算清楚你的集群到底需要多少带宽、收敛比定在多少合适。这个账不算清楚后面选什么光模块、用什么拓扑都是拍脑袋。我一般会建议从业务流量模型出发先看训练任务里通信占比有多大再决定收敛比。假设你的训练任务里全规约通信占了总时间的30%那带宽收敛比就不能低于1:3否则通信时间会进一步拉长。如果通信占比只有10%那收敛比可以放宽到1:5甚至1:8光模块的用量能省不少。这个计算过程需要结合具体的模型并行策略和批次大小来细化但大原则是先保通信效率再考虑成本优化。4.2 光模块选型速率、封装、功耗三个维度怎么权衡光模块选型的时候速率、封装、功耗这三个维度往往是互相制约的。速率越高功耗越大封装也越复杂。海思光电的方案里覆盖了从400G到800G甚至更高速率的光模块实际选型的时候需要根据交换芯片的接口速率和面板密度来定。我的经验是不要盲目追求最高速率。如果你的交换芯片接口是400G的硬上800G光模块就是浪费。反过来如果交换芯片支持800G但你的光纤布线条件比较差那可能要先解决布线问题再考虑升级速率。功耗方面板载光引擎的功耗通常比可插拔模块低30%到50%但这个优势只有在规模足够大的时候才能体现出来。4.3 部署实施光纤布线和散热系统的施工要点部署实施阶段光纤布线和散热系统是两个需要重点盯的环节。光纤布线我建议采用预端接的方案工厂里把连接器做好现场直接插拔减少现场熔纤的工作量和质量风险。布线的时候要严格按照拓扑设计走线每一根光纤都要有清晰的标识方便后期维护。散热系统的施工要点是风道设计。板载光引擎通常需要独立的风道或者液冷回路不能和交换芯片共用散热资源。如果机柜的散热能力不足光模块的工作温度会升高误码率也会跟着上升。我见过不少集群因为散热没做好光模块频繁出现链路闪断的问题排查起来特别费劲。4.4 运维阶段链路监控和故障排查怎么做运维阶段最重要的是建立链路监控体系。光模块的健康状态包括温度、光功率、偏置电流这些参数通过DDM数字诊断监控接口可以实时读取。我建议在集群管理平台里把这些参数接进来设置合理的告警阈值提前发现潜在问题。故障排查的时候先看光功率是否正常再看误码率是否超标最后检查物理连接是否松动。大部分光链路故障都是物理层的问题比如连接器脏污、光纤弯折半径过小、或者光模块没插紧。这些问题的排查不需要复杂的工具但需要耐心和一套标准化的流程。故障现象可能原因排查方法解决措施链路闪断光模块温度过高查看DDM温度读数改善散热或降低环境温度误码率上升光功率不足测量收发光功率清洁连接器或更换光纤链路不通物理连接松动检查连接器插入状态重新插拔并锁定带宽下降光纤弯折过大检查光纤走线半径重新布线保证弯曲半径5. 常见问题与实操避坑指南5.1 光模块和交换芯片的兼容性怎么保证光模块和交换芯片的兼容性是实际部署里最容易踩坑的地方。不同厂商的交换芯片对光模块的I2C接口定义、寄存器映射、初始化时序可能有差异如果光模块的固件没有针对性地适配轻则链路不稳定重则根本起不来。海思光电的方案里光模块和交换芯片是配套设计的兼容性有保障但如果你用的是第三方光模块一定要提前做兼容性测试。我的建议是在批量采购之前先拿几对样品做完整的互通测试包括链路建立、误码率测试、温度循环测试。测试通过之后再小批量部署观察一段时间再大规模铺开。这个流程看起来麻烦但比大规模部署后出问题再回退要省事得多。5.2 光纤连接器清洁不到位会有什么后果光纤连接器清洁不到位是光链路故障里最常见的原因之一。连接器端面上的一粒灰尘可能就会导致光功率下降几个dB误码率直接超标。我见过一个案例一个万卡集群部署完之后有几十条链路一直不稳定排查了半天发现是连接器端面有油污清洁之后全部恢复正常。清洁连接器要用专用的清洁工具不要用酒精棉球随便擦。清洁的时候要沿着一个方向擦不要来回蹭。清洁完之后要用光纤显微镜检查端面确认没有残留物再插入。这个操作看起来简单但实际做的时候很多人会偷懒结果就是给自己埋雷。5.3 板载光引擎的维护性怎么解决板载光引擎的维护性差是它最大的短板。可插拔模块坏了运维人员直接换一个就行板载光引擎坏了可能需要把整个板子拆下来返修。海思光电的方案里似乎是用了可插拔的光引擎子模块设计把光引擎做成一个可以单独更换的单元这样既保留了板载方案的高密度优势又改善了维护性。如果你在规划集群时选择了板载方案一定要确认光引擎的可维护性设计。比如是否支持热插拔、更换一个光引擎需要多长时间、是否需要专门的工具。这些细节在规划阶段就要问清楚不要等到出了问题才发现维护起来特别麻烦。5.4 光互连方案的总体拥有成本怎么算光互连方案的总体拥有成本TCO不能只看光模块的采购价格还要算上光纤布线、散热系统、运维人力、故障停机这些隐性成本。我一般会用一个简单的模型来估算TCO等于硬件采购成本加上部署成本加上五年运维成本加上故障损失。硬件采购成本里光模块和光纤占大头部署成本包括施工人力和测试费用运维成本包括日常巡检、清洁、备件更换故障损失包括停机时间和业务影响。这个模型算下来有时候采购价格高的方案因为可靠性好、运维省心TCO反而更低。所以选型的时候不要只盯着报价单要把整个生命周期的成本都考虑进去。提示在算TCO的时候一定要把故障停机的损失算进去。万卡集群停一个小时损失可能是几十万甚至上百万这个数字比光模块的差价大得多。6. 我对光互连方案落地的一些个人体会光互连这个领域技术迭代的速度比我预想的要快。两年前大家还在讨论400G光模块的部署经验现在800G已经成了万卡集群的标配1.6T的方案也在路上了。海思光电这次在CIOE芯光论坛上分享的全栈方案给我的感觉是他们把光互连当成一个系统工程来做而不是只卖光模块。我个人在实际操作中的体会是光互连方案的落地技术选型只占三成剩下七成是工程细节和运维体系。你选了什么速率的光模块、什么形态的光引擎这些决定了大方向但真正决定集群稳定性的是光纤布线的质量、散热系统的可靠性、以及运维流程的规范性。我见过太多集群硬件配置都是顶级的但因为布线混乱、散热不足、运维跟不上实际可用性大打折扣。最后再分享一个小技巧在光互连方案的设计阶段就拉上运维团队一起参与。运维的人最清楚实际部署时会遇到什么问题他们的意见能帮你避开很多坑。比如光纤怎么走线方便维护、光模块的备件怎么管理、故障排查的流程怎么设计这些细节在设计阶段定下来比部署完了再改要省事得多。光互连方案的全栈能力最终要体现在从规划到运维的每一个环节里而不是只停留在技术参数的纸面比较上。