机柜级系统（Rack Scale）

机柜级系统不再以单台服务器为单位，而是把整个机柜的算力、供电、散热与互联统一设计，让几十到上百张加速卡像一台机器那样协同工作。它出现的直接原因是大模型的通信量已经超出传统服务器内部互联的能力，节点之间的带宽成了训练效率的天花板。把互联半径从机箱内扩展到整柜，是绕开这道天花板的一条工程路径。

设计上的几个变化

• 高带宽互联：用专用链路把柜内加速卡连成全互联或近全互联拓扑，缩短跨卡通信的跳数与延迟。
• 统一供电与散热：单柜功率密度大幅提高，普遍需要液冷或更强的风冷方案，供电也要重新设计。
• 整体交付：机柜作为交付与部署单元，现场布线、上电与调试的时间明显缩短。
• 软件配套：调度与通信库要针对柜内拓扑优化，否则硬件带宽无法被实际任务用满。
• 故障域设计：共享供电与互联意味着故障影响范围更大，需要分区与降级策略。

对部署意味着什么

机房需要重新评估承重、供电容量、散热与布线条件，这类改造的周期往往比采购设备更长，选型因此变成了长期的场地规划问题。柜内共享资源让故障域变大，单个部件的问题可能影响整柜任务，所以监控粒度、健康检查与任务重调度能力必须同步跟上。对租用算力的团队来说，理解柜内互联的规格与拓扑，有助于判断多机训练能拿到多少实测效率，而不只是看单卡参数。

常见的误判

• 把柜内带宽当成跨柜带宽：柜内互联很快，跨柜扩展仍受集群网络限制，规模越大差距越明显。
• 忽略供电与散热约束：纸面算力再高，场地供不上电、散不掉热就无法部署。
• 按单卡算力线性外推：并行效率随规模上升而下降，通信与同步开销会吃掉一部分增益。
• 低估软件成熟度：拓扑越特殊，对通信库与调度器的适配要求越高，迁移成本不可忽略。

软件与运维的配套

• 拓扑感知调度：把通信密集的任务尽量放在柜内相邻位置，减少跨柜流量。
• 通信库调优：集合通信算法要按柜内拓扑选择，默认配置往往不是最优解。
• 健康检查与隔离：及时发现慢节点并把它移出通信组，避免拖累整个训练任务。
• 任务重调度：故障域较大，需要能快速重启并恢复训练进度的机制。

机柜级系统代表的是重新划定「整机」边界的思路：过去靠提高单芯片性能获得收益，现在更多靠缩短数据在芯片之间的移动距离。它并不改变算法本身，但会明显改变集群的采购方式、机房形态与运维分工。