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

张开发
2026/4/14 1:47:10 15 分钟阅读

分享文章

当 6912 个光模块成为常态,超节点是不是走错了路?
当一个系统需要靠软件不停地“兜底”才能跑起来我们是不是该问问硬件这条路是不是走偏了最近关注到某头部厂商在通信库中上线了一个很有意思的机制算子级重执行。简单说当通信链路出现闪断或故障时软件层可以尝试重新执行这个通信算子避免训练任务直接崩溃。听起来很高级。但难免让人多想一步为什么需要这个功能文档里的措辞很坦诚——“针对某超节点下光模块故障率较高的场景”。换句话说这不是锦上添花这是亡羊补牢。而且是有代价的补牢开启后对性能有轻微影响成功率大约95%还不支持通信计算融合模式。公平地说这确实是一个有价值的工程创新。能在算子级别实现在线恢复本身是软件技术的进步。但它背后反映的问题值得整个行业思考当一个系统的硬件基础越来越“娇气”软件到底能补多少补得了一时补得了一世吗实际上这类“兜底”机制并不是孤例。智能运维软件、光模块通道抗损技术、优雅隔离……某384超节点在软件层面的“补丁”可谓琳琅满目。光模块年失效率从4‰被优化到0.4‰听起来是10倍的提升。但基数摆在那里——6912个光模块0.4‰意味着每年还是有近3个自然失效再加上实际环境中灰尘、松动、温湿度变化带来的问题运维手里的工单从来就没断过。有一个场景特别典型光模块脏污导致闪断重执行机制触发任务暂时续上了。但如果下次脏污更严重呢如果多条链路同时出问题呢软件还能不能兜住当一个系统的稳定运行越来越依赖软件层面的“精巧设计”我们是不是该回头看看硬件这条路本身有没有问题有意思的是当行业主流还在用更复杂的软件去补偿更脆弱的硬件时另一种思路已经在工程层面给出了答案从根本上减少故障源。中科曙光的scaleX40选择了一条完全相反的路径——正交无线缆电互联计算板卡和交换板卡直接对插没有线缆没有光模块。没了线缆自然就没有了线缆带来的故障没了光模块自然就不需要软件去“擦屁股”。结果是系统可靠性做到了99.99%部署周期从数月压缩到数小时。这不是在否定光互联的价值。但问题在于当一个超节点内部的互联需要动用如此多的软件手段才能勉强稳住我们是不是该想一想这条路是不是走得有点急了算力系统的本质是持续、稳定的输出不是不停地“修复”和“重试”。软件可以补一时的坑但不能填一辈子的坑。有时候少即是多。

更多文章