一台机器装六十四张卡：超节点把故障域和运维界面一起放大
一、域变大，先变的是故障半径
据公开报道，有国产算力厂商首次参加工业博览会的集成电路展，以全栈自研、软硬一体为主线，展出了六十四卡级的超节点等算力产品，报道中出现的型号名称按其口径处理。该产品的卡间带宽、功耗、价格与交付状态都不在本篇讨论范围，我们也不做某家产品的评测。
要讨论的是这种形态带来的运维结构变化。把几十张卡收进同一个互联域，省掉的是跨机通信，这属于性能侧的收益，已经有很多人在讲。容易被忽略的是另一侧：域内这些卡共享供电、共享散热、共享互联拓扑，故障隔离粒度从一台服务器粗化到了一个域。原来一张卡出问题，影响的是一台机器上的几张卡；现在同一个域里的供电或散热异常，可能同时压住一批卡。
这就带来本篇的主张：超节点把多机问题变成了单机问题，但单机内部的故障定位难度是上升的。变大的是故障半径，变少的是可以插拔的边界，运维界面必须重做。
二、故障域重划后要重新定义的四件事
原来按服务器定义的东西全部要重写一遍，一件都不能沿用。
可维修单元。原来是一台机器或一张卡，现在要问：一个域里哪些部件可以不中断整个域就更换？供电模块、风扇、互联板卡、单卡，这四种的可热维护性完全不同。答案不在宣传页里，要在交付时逐件确认并写进文档。
可重启单元。重启一个域意味着域内所有卡同时重置。如果域尺寸足够大，一次重启影响的作业量就可能超过原来整个机柜。要明确哪些操作必须整域重启、哪些可以在局部完成，并给出重启前作业快照的要求。
可降级运行形态。掉卡之后这个域还能不能用，是超节点最关键的运维问题。三种形态要分开定义：整域退出、剔除故障卡后继续、把域切成若干子域分别服务。每种形态的成立前提、性能损失与恢复条件都要写清，否则现场只能凭经验决定。
可回滚的配置层。域内拓扑、互联参数、固件版本这三类配置一旦改动，回滚粒度往往比想象中大。要求是配置分层且每层独立可回滚，最忌讳拓扑定义与固件版本绑成一次操作。
三、必须暴露给运维的最小视图
域变大之后，”看得见”就成了硬性交付项。核心交付物之一是这张字段表，建议直接进合同附件。
| 视图层 | 字段 | 采集要求 | 用途 |
|---|---|---|---|
| 单卡 | 每卡温度、每卡功耗、每卡利用率 | 连续采集，不落库也要有原始流 | 热平衡分析与异常卡定位 |
| 链路 | 每链路误码率、重传计数、链路状态变更 | 按链路编号逐条，含时间戳 | 劣化链路预警与绕行决策 |
| 拓扑 | 域内实际连接关系、逻辑分组 | 配置变更后自动重生成，不接受手工维护 | 调度器拓扑感知与故障影响面推算 |
| 事件 | 掉卡事件、降速事件、复位事件 | 事件需带触发原因分类 | 区分硬件失效与热保护降速 |
| 供电与散热 | 各供电模块状态、风扇与进出风温度 | 与单卡温度同时间基准 | 判断异常是共因还是个因 |
| 汇总 | 域内健康度、当前可用卡数、可降级形态状态 | 每次状态变化推送 | 调度层做放置与弹性决策 |
这张表里最关键的三个字段是每链路误码率、域内实际拓扑和事件原因分类。少了误码率，链路劣化只能等到断链才发现；拓扑靠人工维护，调度器就会按错误的邻接关系放置作业；事件不带原因分类，运维会把一次全域热保护降速当成一批卡同时坏了来排查。
还要强调时间基准。域内几十个传感器的数据若不在同一时钟上，共因分析就做不了，而共因分析正是大故障域最需要做的事。
四、作业弹性按什么粒度设计
三种粒度，各自的调度前提不一样，不要笼统地说支持弹性。
整域重启：实现最简单，调度器只要把域当一个不可分资源，作业做检查点并重放。前提是两个，检查点间隔必须短到重启一次的代价可以接受；域的重启时间要有实测值并计入可用性预算。域越大，这个前提越难满足。
卡级剔除：调度器要能在作业运行中接受资源集合变化，这要求并行策略本身允许节点数改变，或者作业按可弹性规模编写。前提还有故障判定要准——剔除错了是白丢算力，该剔不剔是拖垮整批。判定依据就是上一节的误码率与事件分类。
链路绕行：对软件要求最高，互联层要能重构路由或让通信库感知可用链路并绕开劣化路径。适合的场景是链路劣化而卡本身健康，这是大域里最常见也最容易被误判的一类问题。
洹拓给客户的建议是三者都写进作业框架的能力清单，但在合同里只按已经现场验证过的那一档承诺。弹性这件事，文档上写了和现场能跑，中间隔着一次真实的故障演练。
五、验收顺序要从能跑改成能连续跑
跑通一个基准模型不再是终点。域尺寸变大后，真正决定使用体验的是长时间满负荷下会发生什么。核心交付物之二就是这张顺序表。
| 阶段 | 验收动作 | 判定要点 | 未过则不进入下一阶段 |
|---|---|---|---|
| 一 | 单卡与整机功能确认 | 全部卡可识别、驱动与运行时正常 | 是 |
| 二 | 域内互联与拓扑核对 | 实测拓扑与文档一致，链路误码基线记录 | 是 |
| 三 | 短时满负荷 | 功耗与温度进入稳定区间，无异常降速 | 是 |
| 四 | 长时间满负荷热平衡 | 持续运行下温度不再爬升，热点分布可解释 | 是 |
| 五 | 掉卡与降速事件观察 | 事件率、原因分类准确性、剔除动作正确 | 是 |
| 六 | 性能抖动区间 | 同一负载多次运行的性能波动带，非单次最优值 | 是 |
| 七 | 断点恢复演练 | 主动注入故障后检查点恢复、重放时间与业务连续性 | 是 |
| 八 | 运维视图联调 | 字段齐全、时间戳对齐、告警接到客户监控体系 | 是 |
表里第四、第五、第七是最常被跳过的三段。第四段跳过的后果是夏天或者机房制冷能力吃紧时才暴露热平衡问题；第五段跳过的后果是第一次真实掉卡时没人知道该怎么处置；第七段跳过的后果是断点恢复只在纸面上成立。验收顺序之所以要写成阶段门禁，就是为了避免这些段落被一句”后续再看”推掉。
六、软件栈适配与责任边界
超节点不是独立硬件，它要落进既有软件栈，适配面有三处容易被低估。
拓扑感知调度。调度器要理解域内实际连接关系才能做放置，若调度层只把域看成一个整体大节点，就浪费了域内差异；若要细粒度感知，则要求拓扑随配置变更自动更新。并行策略与域尺寸耦合。张量并行、流水并行与数据并行的切分方式，通常和域能装多少卡直接相关，域尺寸一变切分就要重排。换域尺寸要不要重调超参，这个问题必须在采购前问清并做小范围实测，因为答案通常是部分要调，学习率与批规模这类参数不会因为换了互联域就自动适配。
责任边界要写成三列。厂商自检项，指交付前厂商在自己环境完成并出具记录的项，对应上表前三个阶段；客户现场验收项，指必须在客户机房按客户业务负载复跑的项，对应后五个阶段；共性问题归谁，指跨层问题，例如性能抖动究竟来自硬件、驱动、通信库还是作业配置，这类问题最容易在两边之间踢皮球，处理办法是事先约定牵头方与判定实验，而不是约定免责条款。
合同字段建议至少五项：运维视图字段与采集频率；故障域定义与可维修、可重启单元清单；可降级运行形态及其成立前提；按阶段门禁的验收顺序与每阶段留证要求；共性问题牵头方与判定实验方法。这五项缺任何一项，交付之后所有的运维争议都要靠临时协商，而那正是最消耗双方信任的环节。