当 6912 个光模块成为常态，超节点是不是走错了路？

当一个系统需要靠软件不停地“兜底”才能跑起来，我们是不是该问问：硬件这条路，是不是走偏了？

最近关注到某头部厂商在通信库中上线了一个很有意思的机制：算子级重执行。简单说，当通信链路出现闪断或故障时，软件层可以尝试重新执行这个通信算子，避免训练任务直接崩溃。

听起来很高级。但难免让人多想一步：为什么需要这个功能？文档里的措辞很坦诚——“针对某超节点下光模块故障率较高的场景”。

换句话说，这不是锦上添花，这是亡羊补牢。而且是有代价的补牢：开启后对性能有轻微影响，成功率大约95%，还不支持通信计算融合模式。

公平地说，这确实是一个有价值的工程创新。能在算子级别实现在线恢复，本身是软件技术的进步。但它背后反映的问题值得整个行业思考：当一个系统的硬件基础越来越“娇气”，软件到底能补多少？补得了一时，补得了一世吗？

实际上，这类“兜底”机制并不是孤例。智能运维软件、光模块通道抗损技术、优雅隔离……某384超节点在软件层面的“补丁”可谓琳琅满目。光模块年失效率从4‰被优化到0.4‰，听起来是10倍的提升。但基数摆在那里——6912个光模块，0.4‰意味着每年还是有近3个自然失效，再加上实际环境中灰尘、松动、温湿度变化带来的问题，运维手里的工单从来就没断过。

有一个场景特别典型：光模块脏污导致闪断，重执行机制触发，任务暂时续上了。

但如果下次脏污更严重呢？如果多条链路同时出问题呢？软件还能不能兜住？

当一个系统的稳定运行越来越依赖软件层面的“精巧设计”，我们是不是该回头看看硬件这条路本身有没有问题？

有意思的是，当行业主流还在用更复杂的软件去补偿更脆弱的硬件时，另一种思路已经在工程层面给出了答案：从根本上减少故障源。

中科曙光的scaleX40，选择了一条完全相反的路径——正交无线缆电互联，计算板卡和交换板卡直接对插，没有线缆，没有光模块。没了线缆，自然就没有了线缆带来的故障；没了光模块，自然就不需要软件去“擦屁股”。结果是系统可靠性做到了99.99%，部署周期从数月压缩到数小时。

这不是在否定光互联的价值。但问题在于：当一个超节点内部的互联，需要动用如此多的软件手段才能勉强稳住，我们是不是该想一想，这条路是不是走得有点急了？

算力系统的本质是持续、稳定的输出，不是不停地“修复”和“重试”。软件可以补一时的坑，但不能填一辈子的坑。有时候，少即是多。