最近在调一个面向AI训练的Scale-Up集群时光链路可靠性这块让我吃了不少苦头。Scale-Up这类短距无损互连协议本来就是在机柜内或跨机柜之间把GPU加速卡直连起来带宽大、时延要求极低和传统以太网那种“尽力而为”的模型完全不同。光链路一旦抖动整个训练任务可能直接中断恢复重跑的代价非常大。这篇就当是我自己踩过坑之后的复盘聊聊Scale-Up协议设计中光链路可靠性到底该怎么考虑、协议层能做哪些事、工程上又该怎么配合。1. Scale-Up协议为何把可靠性压在光链路上1.1 从电互联到光互联的必然性Scale-Up协议的核心场景是AI集群里的加速卡直连拓扑通常是全互联或超节点结构。单机柜内几个节点之间用铜缆背板或DAC直连铜缆可以覆盖但一旦跨越多个机柜、机柜间距超过5米甚至到几十米铜缆的插入损耗就开始失控。高速信号在铜缆上的衰减是频率越高越严重在112Gb/s SerDes速率下铜缆长度基本被限制在2米以内再长就得换有源铜缆或者直接上光模块。光链路的好处在于损耗和距离解耦。光信号在光纤里跑几十米衰减通常只有零点几个dB远小于铜缆的十几dB损失。同时光模块把电信号转成光信号的过程本身就是一次“中继整形”信号质量反而比长铜缆更稳定。所以Scale-Up跨机柜场景基本都选择光互连这也是光链路可靠性必须从协议层面重点设计的原因——骨干连接越多、越关键出问题的爆炸半径就越大。1.2 可靠性设计的目标不是不出错而是可控可恢复做可靠性设计首先要分清目标。我们不能指望光模块、光纤、连接器永远不出错那是做制造业良率思维不是做系统工程的思维。Scale-Up协议里可靠性设计的核心目标有四个第一是错误快速发现链路劣化或故障出现时能在极短时间内被感知第二是错误准确定位知道问题出在哪根链路、哪个方向、哪类器件第三是错误快速恢复通过重传、切换或降级策略把业务影响降到最低第四是劣化趋势可预测在链路完全断掉之前就提前干预。这四个目标对应到协议设计上就是FEC机制、链路保活检测、遥测上报和冗余策略。我见过不少工程团队只盯着FEC纠错能力以为前向纠错能兜底就不管别的实际上一旦链路误码率高到FEC持续纠错、纠不过来协议层完全没有快速定界手段整个集群都在丢包重传这是最难受的场景。1.3 光链路可靠性设计的分层思路Scale-Up协议的光链路可靠性不能只看协议一个层面。我习惯把整个系统分成三层来考虑。物理层是光模块、光纤、连接器和SerDes负责信号本身的传输质量。这一层的问题是“信号坏了”表现为误码率升高、链路失锁、光功率异常。链路层是协议里的FEC、链路训练、保活机制、重传逻辑负责“发现坏了并尽量修复”。网络层或流控层则负责端到端的拥塞控制、背压和拓扑级保护切换解决“局部坏了如何不让全局崩盘”的问题。三层之间的关系是逐级兜底。物理层的错误尽量靠链路层FEC吸收吸收不了的重传重传还搞不定的就触发保护切换或降级运行。如果一开始就把可靠性设计全部押在某一层比如只依赖FEC或者只依赖上层重传那必然会顾此失彼。后面我拆细节的时候也是按这个分层思路来讲。2. 光链路失效模式与根因分析2.1 光路器件层面的典型失效光链路是一长串器件的串联发送端DSP驱动激光器发光光耦合进光纤经过连接器、跳线、配线架再到对端接收器经过光电二极管转成电流、跨阻放大器放大、DSP均衡解调。其中任何一环出问题表现都是接收端信号劣化。最常见的问题是连接器污染。光纤连接器的端面直径只有微米级一粒灰尘落到端面上如果正好盖住纤芯耦合区域插入损耗可能瞬间增加几个dB。多模光纤还好一点单模光纤的模场直径只有9微米左右灰尘带来的影响几乎是致命的。我见过一个真实案例一条链路的DDM报接收光功率从-6dBm掉到-11dBm误码率一跳就是两个数量级现场用光纤显微镜一看端面上有一小块白色污染物清洁之后指标完全恢复。其次是光纤弯曲衰减。很多人以为光纤弯个90度没事实际上弯曲半径小于规定值时光信号在弯折处会大量泄漏到包层里。单模光纤一般要求静态弯曲半径不小于30mm动态施工时不小于20mm多模光纤可以稍小一些。如果走线时被机柜门夹住或者被扎带勒得太紧弯曲损耗会逐段叠加最终反映为链路预算余量不足。还有就是激光器老化和温度漂移。VCSEL激光器在多模模块里很常见它的输出光功率随温度升高明显下降。如果模块散热不好内部温度从40度升到70度光功率可能下降2-3dB同时发射波长也会漂移与接收端滤波器失配之后灵敏度也跟着掉。这类失效是渐进式的靠瞬时检测很难发现必须依赖长时间趋势监控。2.2 信号完整性损伤PAM4时代的“隐形杀手”现在400G、800G光模块基本都是PAM4调制一个符号携带2bit信息对信噪比的要求比NRZ高了非常多。PAM4信号的眼图只有三个电平眼高变矮、眼宽变窄噪声稍微大一点就会出现符号误判。信号完整性问题有几个典型来源。一个是发送端电气信号质量不好SerDes的摆幅不够、上升沿过缓进到DSP之后虽然可以重新整形但发射光信号的ER消光比会明显变差。另一个是光纤色散单模光纤在1310nm窗口色散很小但到1550nm窗口色散就不可忽略了长距离时PAM4信号会被色散展宽符号间干扰加大。还有一个是接收端的光功率过高导致接收器饱和光模块的接收组件有个过载点超过之后信号反而失真。这类问题在协议层看不到具体原因只能看到误码率上升。通常排查手段是读模块的实时DDM参数配合BIST内建自测试的PRBS码型去分段验证先测电口环回再测光口环回逐段缩小范围。实测下来大部分“莫名其妙”的误码告警最后都指向发送端信号质量而不是光路本身。2.3 环境与运维因素温度、污染、振动机房环境对光链路可靠性的影响容易被低估。高密度AI集群的功率密度极大机柜内温度经常处于上限运行状态。长期高温对光模块激光器的损伤是累积性的一开始不显眼半年之后发射光功率开始快速下降这就是典型的温度加速老化。振动也是个隐形因素。风扇轴承磨损带来的机械振动、相邻机柜的共振都可能让光纤连接器产生微观移动。连接器插芯是靠弹簧力压紧的微幅振动久了会导致端面微磨损插入损耗缓慢变大。更麻烦的是振动可能让连接器瞬时脱离接触表现为链路秒级闪断误码率忽高忽低日志里很难抓到规律。运维操作失误同样常见。机房割接时拔错光纤、清洁光纤时用干棉球直接擦、跳线标签写错导致验收时插错端口这些都真实发生过。所以光链路的可靠性不只是协议和芯片的事运维规范和操作SOP必须同步设计。3. 协议层可靠性机制拆解3.1 FEC光链路的第一道防线FEC前向纠错是Scale-Up协议光链路可靠性里最基础的一道防线。FEC的基本思路是在发送端对数据做编码附加冗余校验信息接收端收到后不仅知道有没有错还能在错误数量可控时直接纠正过来不需要反向重传。实际系统中常用的是RS-FEC典型结构是RS(544,514)也就是每条FEC Codeword 544个符号里有514个是数据符号、30个是校验符号。这种码可以纠正最多15个符号错误。对应到PAM4场景每个符号对应2bit纠错粒度比较灵活。选FEC参数要权衡纠错能力和开销。RS(544,514)的开销约5.8%也就是有效带宽会打95折。如果选择纠错能力更强的码型比如RS(560,514)开销会到9%左右但能容忍的误码率更高。对于Scale-Up这种对时延极度敏感的场景FEC还有个关键指标叫延迟预算编解码都会引入处理时延所以不能盲目提高纠错能力。一般以链路BER在1e-6以下作为FEC的舒适区如果持续高于这个值说明链路本身已经劣化到需要排查物理层问题的程度。实际工作中要特别关注一个现象叫FEC纠错极限。FEC输入BER太高时纠错后输出的误码可能不降反升或者纠错失败导致整帧丢失。这时候协议要能识别出是“FEC在硬扛”还是“FEC已经扛不住”并触发上层保护动作。3.2 链路训练与自适应均衡Scale-Up协议里的链路训练机制类似以太网的Link Training但要求更快、更高效。链路两端上电或复位后会执行一系列训练阶段首先建立符号同步接着调整发射端均衡参数和接收端均衡参数最后交换握手信息确认链路可用。自适应均衡是这里面的核心技术。高速信号经过PCB、连接器、光模块之后高频分量衰减比低频分量严重信号会变得“圆润”且拖尾这叫码间干扰。接收端均衡器会对信号做反卷积把高频分量补回来。自适应的意思是均衡器参数不是固定写死的而是根据当前链路的实际响应自动调整。我调试时候遇到最多的一个问题是链路训练时均衡器收敛到了局部最优而不是全局最优。这时候训练结果是“能用但余量不足”运行一段时间温度变化后参数就失配了误码率开始上升。比较好的设计是协议在空闲时间周期性重训或至少周期性检查均衡器参数与误码率的关联趋势。另外链路训练信号本身要具备抗噪声能力。训练帧如果误码严重两端的握手就无法完成表现为链路反复重启。工程上线前一定要做训练健壮性测试比如故意在链路上插入衰减器看链路训练在多大衰减下还能收敛成功。这样能提前暴露均衡器余量不足的链路。3.3 保活检测与快速故障定界链路运行期间协议必须有保活机制来感知链路是否还“健康”。最简单的方式是周期性的链路保活帧类似心跳包对端在一定时间内没有收到有效保活帧就判定链路故障。但保活帧只能是最终手段它只能告诉我们链路断了不能告诉我们链路为什么变差。所以现代Scale-Up协议还会周期性插入链路诊断符号或参与遥测的专门帧比如每隔一段固定时间统计一次FEC错误符号数、接收信号质量指示这些数据可以辅助判断链路是“彻底断”还是“缓慢劣化中”。故障定界的粒度很重要。一条物理链路两端分别是两个节点的端口中间还要经过光模块A、光纤A-B、光模块B。如果协议只在链路层做整体检测那定位只能到“链路不通”接下来还得靠人工去看模块光功率、插拔光纤来逐个排除。更高效的做法是在协议里附加段层测量能力比如光模块DDM回传机制配合协议管理帧能直接读出两端模块各自的收发光功率从而快速判断是发送端、光纤还是接收端的问题。3.4 重传、背压与保护切换FEC纠正不了错误的时候协议需要重传。这里有两个选择端到端重传和逐跳重传。端到端重传简单但时延惩罚大逐跳重传时延小却要求中间节点有足够缓冲复杂度高。Scale-Up这种低时延无损互连通常倾向于逐跳或近源重传靠FEC吸收零星错误、靠重传兜底持续性错误。重传逻辑必须和流控背压配合好。如果某条链路持续误码触发大量重传接收端的缓冲区会被待重传数据塞满这时需要向上游发送背压信号让上游暂停发送新数据。否则上游持续灌数据但下游都在重传旧数据整个链路就会进入拥塞崩溃。保护切换则是拓扑层面的能力。如果Scale-Up集群拓扑里有备用物理路径比如环形拓扑的另外半边协议可以定义快速切换机制。切换快慢取决于故障检测时间、转发表更新时间和流量重路由时间。一般来说链路故障检测做到毫秒级切换动作做到几十毫秒以内对业务整体是无感的。若做不到无感切换至少要保证重训练或重启之后数据面能快速恢复训练任务从中断点继续而不是从头开始。4. 管理面监控遥测、告警与预测性维护4.1 关键遥测指标可靠性设计还要考虑“看得见”的问题。光模块的DDM数字诊断监控标准提供了大量遥测数据包括发射光功率、接收光功率、模块温度、供电电压、偏置电流等。协议管理面要把这些数据周期采集上来和链路层的FEC误码率、物理层信号质量指标一起入库分析构成一个完整的光链路健康画像。哪个指标最有用按我的经验排序是接收光功率、FEC错误符号率、模块温度、偏置电流、发射光功率。接收光功率直接反映光路好坏FEC错误符号率是信号质量的“放大镜”链路稍微劣化它先变敏感模块温度和偏置电流则是预测性维护的主要依据。光功率不能只看绝对值要看相对历史基准的变化量。每个模块安装时的光功率就是它的基准值运行中如果比基准值掉了2dB以上即使绝对值还在模块的告警阈值内也说明链路出现了劣化趋势应该触发预警。4.2 异常阈值与告警联动告警设计要区分“故障”和“劣化”两种级别。故障级告警对应链路完全中断、信号失锁、功率严重低于规格这种要立即触发保护动作。劣化级告警则是偏差超过某个比例但业务尚可维持这种的目的在于提前干预。可以按层设置阈值。物理层看光功率和温度接收光功率低于模块的敏感性阈值或相对基准衰减超过3dB告警温度超过模块最大工作温度的80%告警。链路层看FEC错误率FEC corrected symbol rate持续高于1e-6黄色告警高于1e-4或FEC uncorrectable递增红色告警。告警要联动自动化动作不能只是发个通知让人去看。例如链路连续三次红色告警管理面自动触发该端口的禁用或流量切换。这样即使运维人员没有实时盯着监控屏故障也可以在几十秒内被隔离。4.3 预测性维护思路从“故障响应”走向“故障预防”靠的是对长期趋势数据的建模。比如激光器的偏置电流正常工作时会随着老化缓慢增大因为要保持同样的光功率需要加大驱动电流。当偏置电流比出厂值高20%以上时模块大概率在可预见的几个月内失效。温度也是一个预测特征。模块温度的季节性波动是正常的但如果温度持续走高而不回落并且和机房空调负载变化不同步就要注意是不是模块散热不良或风扇故障。实现预测性维护不需要特别复杂的算法先对每个模块建历史基线然后用简单的斜率检测如移动平均和标准差偏离度检测就能发现大部分渐进式故障。当然要做好这类分析遥测数据必须有统一的时间戳和稳定的采集周期否则数据质量太差再好的算法也无能为力。5. 工程实践中的可靠性部署细节5.1 光模块选型与验收测试协议设计得再好物理器件选型不过关也是白搭。Scale-Up场景对光模块的抖动性能和误码性能要求很高采购时不能只看速率和距离参数还要看测试余量。我建议重点看以下几个指标发射端消光比、接收端灵敏度、过载光功率、功耗温度范围和BER一致性。其中接收灵敏度尤其关键灵敏度越好的模块在链路劣化时越“扛得住”。同样一条链路模块灵敏度差1dB运行余量就少1dB出问题的概率差别很大。模块到货后的验收测试不能省。必须做的是BIST误码测试至少跑24小时温度循环测试覆盖模块规格边界光眼图测试确认发射信号形态合格插损余量测试在链路上人为加衰减器看模块在多差的光路下还能维持正常BER。5.2 光纤布线与连接器管理光纤布线这块儿最容易出的问题就是弯曲半径和连接器工艺。施工时要求所有跳线走线弧度自然不打死结、不被扎带勒紧。配线架上的冗余光纤要盘圈收纳盘圈直径也要符合规格不能为了美观盘成小圈。连接器端面的管理是可靠性保障的重中之重。所有新光纤投入使用前必须用光纤显微镜检查端面脏了就先清洁再插。插拔跳线时严禁带着灰尘硬插否则灰尘颗粒会在插芯端面上划出永久性伤痕。端面划伤之后插入损耗的劣化是不可逆的只能换线。建议给每根跳线建立生命周期档案包括链路两端端口号、光纤长度、初始插损、验收BER。一旦链路之后出问题直接对比历史数据能很快判断是线缆问题还是模块问题。此外一定要做链路预算核算。链路预算等于光模块发射功率减去接收灵敏度中间要扣除连接器损耗、光纤损耗、熔接点和配线架损耗的余量。一般建议总插损控制在预算的70%以内留出30%作为老化余量。如果光纤中间有跳接每增加一个连接器就有0.3-0.5dB损耗链路预算就会被快速吃紧。5.3 故障演练与应急切换可靠性设计还要经过实战检验。建议每隔一段时间做一次光链路故障演练人为拔掉一根关键链路的光纤观察协议是否能在预期时间内检测到故障保护切换是否正常触发业务中断时间是否符合目标。不要挑业务低峰期搞突袭式的演练而是把演练做成固定流程每次只针对一条链路、有预案、有回滚方案。演练之后要复盘几个时间点物理层故障注入到协议检测的时间、协议故障通告到路由切换的时间、切换完成到业务恢复的时间。任何一个环节超出目标值都要追查是检测机制的问题还是转发逻辑的问题。还有一种演练是模拟链路劣化而不是直接中断。可以插入光衰减器逐步增大衰减观察FEC错误率的变化趋势和告警触发点确认管理面的预判逻辑是准的。这个比直接拔线更有价值因为渐进式劣化才是最常见的真实故障模式。6. 常见问题与排查经验实录6.1 常见告警与排查流程速查排查光链路问题最忌讳没有章法地乱试。我习惯按“端到端分段”的流程来。链路断连时先看两端模块的DDM指标。如果接收光功率远低于正常值甚至读到-20dBm以下问题几乎肯定在光路上光纤断、连接器没插好、端面污染、弯曲过度。如果接收光功率正常但链路还是断那就是信号质量问题重点查发送端模块和接收端均衡。链路误码偏高时先确认是单方向还是双向。单向误码高问题大概率在该方向发送端模块或者对应光纤段双向都高可能是环境因素比如机柜温度高、电源干扰大。然后读FEC校正错误统计看看错误是零星散布还是集中在连续时间段集中在某个时间段可能与机械振动、风扇调速有关。现象可能原因优先排查动作接收光功率过低光纤折断、连接器松动、端面污染用光功率计分段测量显微镜查端面接收光功率正常但误码高模块发射信号劣化、均衡失配BIST环回测试检查眼图和ERFEC错误率缓慢上升器件老化、温度漂移、微弯损耗对比历史遥测基线检查温度趋势链路周期性闪断连接器接触不良、振动重新插拔并检查端面观察振动源单链路故障波及多个端口同缆束内损伤、配线架处污染检查共用路径和配线架所有连接器6.2 几个“反直觉”的典型案例说几个我实际遇到的、比较反直觉的案例。第一个是“FEC错误率长期偏高但业务没有投诉”。查了半天才发现是一条跳线在理线架里被压住了产生微弯损耗但因为链路预算余量够大业务并没有明显感知。这种情况如果不处理随着器件老化余量会越来越小迟早会出问题。所以不要只看业务有没有投诉要主动治理指标异常的链路。第二个案例是“同一批次模块半年内故障率异常”。初期以为是个别模块质量问题后来发现这批模块存放在仓库时没有做防潮处理激光器内部可能发生了结露老化上架后表现为偏置电流异常升高。这提醒我们光模块的存储环境也属于可靠性管理范围器件生命周期管理不能只从上架开始算。第三个案例是“链路故障后快速恢复但频繁重复”。一开始以为是光模块问题换了好几个模块都没用。后来发现故障时间点非常有规律都在机房空调压缩机启动后的几秒内。原来空调启动造成机柜轻微振动一根光纤在连接器处产生了瞬断。这种问题靠换模块永远解决不了最后重新走线加固定才消除。6.3 实战中积累的几点设计心得最后分享几条我自己的设计心得。第一可靠性设计要预留“观测窗口”。协议和模块一定要能输出安全可靠的可观测数据没有观测手段的可靠性设计都是空谈。哪怕多花一些流量的代价也要保遥测通道因为故障现场的每一份数据都可能是定位问题的救命稻草。第二FEC不是万能的但绝对是性价比最高的兜底手段。把FEC余量做大一点链路可用性立刻上一个台阶。代价只是少了一点有效带宽但对AI训练这类任务来说稳定的低时延比峰值带宽更值钱。第三保护切换机制一定要连同管理面遥测一起做。光有协议切换能力没有故障定位能力切换完后根本不知道要不要换模块、换光纤只能全链路换一遍这是最浪费时间的做法。第四初始安装的工程质量决定了后期90%的可靠性。很多光链路问题追溯根源都是安装施工时弯曲半径没控制好、连接器没清洁干净、布线没有留余量。协议层面的可靠性机制是弥补不了物理安装缺陷的。Scale-Up协议的光链路可靠性设计说到底三分靠协议、七分靠工程。协议面要保证检测快、定位准、恢复稳工程面要保证器件余量足、布线规范、数据可视两者缺一不可。希望这篇复盘能帮你少走一些弯路尤其是在初期布线验收和遥测体系搭建上一定要多花心思。