一台 8 卡训练机跑一个要三天的任务，第二天夜里进程抛 CUDA error，运维上去一看，nvidia-smi 里只剩 7 张卡；重启之后 8 张又都在，换个任务跑了一整天也没复现，于是被当成"偶发"归档。两周后，另一张卡也消失了。回头翻日志才发现：早在第一次掉卡前一个月，那张卡的可纠正 ECC 计数就在缓慢上涨，核心温度也比同机箱其他卡高出一大截，PCIe 链路宽度也早就不是 x16。这些信息全都在系统里躺着，只是没人采。GPU 的故障很少以"彻底坏掉"的形式出现，它更常见的样子是悄悄降速、错误计数累积、链路缩水，最后才以一次掉卡收场。
先说一个很容易踩的坑：把"GPU 出问题"当成一件事来监控。实际运维中，GPU 相关的故障至少分成六类，它们在日志里的表现完全不同，采集源也不同，处理方式更是天差地别。把它们混在一起看，结果就是哪一类的信号都淹没在噪声里。
最直观的一种。nvidia-smi 里原本 8 张卡变成 7 张，或者 lspci 里还能看到设备但驱动已经不认，再或者系统重启后设备压根没起来。日志上通常伴随内核层面的 PCI 设备移除、驱动卸载或总线错误记录。这一类故障的采集源是内核日志（dmesg / journalctl 输出的环形缓冲）加上设备枚举结果——也就是定期跑一次"当前系统里有几张卡、UUID 分别是什么"的基线比对。只要卡的数量或 UUID 列表和基线不一致，就是硬告警，没有商量余地。
驱动在遇到硬件或内部异常时，会往内核日志里写一条带编号的错误记录，这就是通常说的 Xid。它不针对某个进程，是驱动层面对这张卡的一次"事件上报"。采集源同样是内核日志，但需要能持续抓取并落盘，因为内核日志环形缓冲会被后续内容覆盖掉——很多团队"事后查不到 Xid"，不是没发生，是被冲掉了。
显存出现比特翻转，分可纠正（单比特）和不可纠正（双比特）两种。它不会让任务立刻失败，也常常不产生任何业务侧报错，只能靠主动读取计数器发现。采集源是驱动暴露的计数器（nvidia-smi 的 ECC 相关字段，或采集库的对应字段），需要按卡、按错误类型分开记录，并且要记录增量而不只是当前值。
核心或显存温度触到阈值，或者整机功耗撞到电源上限，驱动会先降频。此时没有错误日志、没有 Xid、任务也不报错，只是变慢。采集源是时钟频率与降频原因字段，以及温度和功耗读数。这一类最容易漏，因为它"看起来一切正常"。
链路宽度从 x16 掉到 x4、x2 甚至 x1，速率从第 4 代掉到第 1 代。系统照样能跑，只是多卡之间的数据交换慢了若干倍。采集源是PCIe 链路的当前宽度与速率（lspci 的详细输出可读到协商后的实际值），需要定期比对基线，因为降宽往往发生在某次重启之后，而不是运行当中。
卡与卡之间的高速互联（NVLink 一类）出现链路降级或失效时，多卡集合通信会退化到走 PCIe 甚至更慢的路径。表现和 PCIe 降级很像：加速比远低于预期。采集源是互联拓扑与链路状态，通过 nvidia-smi 的拓扑查询或采集库的对应诊断项获取。
这六类里，前三类主要靠驱动日志与内核日志，第四、五、六类主要靠带内周期性采样，而电源与机箱温度这类"卡以外"的信息，只能靠带外管理（BMC/IPMI）拿到。一个能用的 GPU 健康监控，至少要把这三条采集链路都接通，只接一条必然有盲区。
Xid 是驱动通过内核日志记录的错误编号，不同的编号对应不同的故障域：有的指向显存，有的指向总线，有的指向电源，有的只是驱动内部状态异常。这里必须说清楚一件事：不要凭记忆或网上流传的对照表去判定某个编号的含义。编号与含义的对应关系会随驱动版本、GPU 架构变化，唯一可靠的做法是对照你当前所用驱动版本的官方文档中的 Xid 编号表来判定。把一张来路不明的编号对照表贴进运维手册，是很多误判的起点。
虽然具体编号要查表，但处置上的分级是有稳定原则的。第一类是致命且需要干预的：这类编号出现后，该卡上的计算已经不可信，继续跑下去要么结果错误要么进程崩溃，需要停止该卡上的任务，并在合适窗口做复位或停机排查。第二类是单次可恢复但需要计数观察的：一次出现不代表硬件坏了，可能是瞬时扰动，但如果同一张卡在一段时间内反复出现同一编号，就要按硬件隐患处理。第三类是驱动或应用侧状态的：与硬件健康关系不大，重点查驱动版本、容器环境和应用程序。
常见场景是：任务挂了，上去 dmesg 里看到一条 Xid，工程师判断"是某某错误"，重启，继续跑。这个流程有两个漏洞。一是没查编号表就下了结论，二是没有把这条 Xid 记进这张卡的档案。正确做法是：把 Xid 连同卡 UUID、时间戳、当时的温度功耗、当时的任务 ID 一起落库，形成"这张卡历史上出现过什么"的时间线。第二次掉卡时，你需要的正是这条时间线。
内核日志是环形缓冲，机器跑得久、日志量大，早期内容就没了。训练机往往连续跑几十天，等到两周后想复盘第一次掉卡，缓冲区里早就是别的内容。所以要么在机器上配一个长期运行的日志采集代理，把内核日志实时转发到集中存储；要么至少让采集库自己记录健康事件（DCGM 一类的采集库有独立的健康事件记录，不完全依赖内核日志留存）。这件事不做，后面所有复盘都是空谈。
显存也会出比特翻转。ECC 机制允许对单比特错误做纠正并记录，这就是可纠正错误；当同一位置出现双比特翻转，纠错码无法还原，就是不可纠正错误，通常会直接导致该次访问失败，进而影响进程。
单次的、偶发的可纠正错误，在大规模显存上属于正常现象，不必紧张。真正需要警惕的是趋势：同一张卡的可纠正错误计数在几天内持续、单调地上涨，尤其是上涨速度还在加快。这说明某些存储单元正在老化或已经处于临界状态。业界的通行做法是把它当作"换卡或至少隔离"的前兆来处理，而不是当作噪声过滤掉。判断标准不应该是"涨到某个绝对值才处理"，而应该是"是否呈现持续增长态势"——一张卡一周内从 0 涨到几十，和一张卡稳定在几百不涨，价值完全不同。
较新的 GPU 架构提供了行重映射机制：当检测到某个显存行反复出错，硬件可以把这一行替换成备用行，从而把已知坏块隔离掉。这是好事，但有两个限制。一是备用行数量有限，用完了就再也映射不了；二是触发重映射之后，往往需要复位该卡（部分场景需要整机复位）才能让新配置生效。也就是说，看到行重映射被触发，说明这张卡已经用掉了保险丝，下一步就该安排停机窗口做复位并重新评估是否继续服役。把"触发了重映射"当成"问题已自动解决"，是典型误读。
不可纠正错误一旦出现，影响的是数据正确性：可能是这一个 batch 的结果错了，也可能是进程直接崩。处理上要立刻停止该卡上的任务，把这张卡从调度池里摘出来，然后结合 Xid 与温度记录判断是显存本体问题还是外部条件（温度、供电）诱发的。这里有个容易忽略的点：整机温度长期偏高会显著提高显存出错概率，所以不可纠正错误有时不是"卡坏了"，而是"机箱散热撑不住了"。先测温度，再判换卡。
开启 ECC 会占用一部分显存用于校验位，可用容量比标称略小；读写路径上多一次校验计算，带宽也有轻微损失。这个代价在大模型训练场景下通常值得付，因为多卡长时间训练对数据正确性的要求远高于那几个百分点的带宽。但在一些短时、可重跑的推理或离线预处理场景，是否关闭 ECC 换性能要看业务容忍度——关闭 ECC 的代价是你失去了最有效的显存健康信号，因此对长期服役的机器，不建议为了这点性能牺牲可观测性。
这一类是"静默降速"的元凶。当核心或显存温度触到阈值，驱动的保护动作是降频，不是报错。降频之后卡还在干活，利用率照样接近 100%，任务也不崩，只是每个 step 变慢。表现就是：同样的任务，第一天一个 step 300 毫秒，第三天变成 420 毫秒，日志里干干净净，什么错误都没有。
GPU 利用率衡量的是"采样周期内有多少时间在跑 kernel"，不是"跑得多快"。一张被降频 30% 的卡，跑同一个 kernel 需要更长时间，反而会让利用率显得更饱满。所以利用率高不等于健康，甚至"利用率异常饱满 + 吞吐下降"本身就是降频的典型组合。要看出降频，得看这几个量：当前 SM 时钟、显存时钟、当前功耗与功耗上限、以及降频原因（温度限频、功耗限频、还是外部触发）。这些字段 nvidia-smi 和采集库都能给出。
多卡机器在满载训练时，整机功耗非常高。如果电源余量留得不足，或者某路供电出现老化，整机层面会出现功耗封顶：驱动收到的指令是"把功耗压到某个值以下"，于是所有卡一起降频。这时候单看某张卡的温度可能完全正常，但所有卡的时钟都上不去。判断方法是看整机功耗读数是否长期贴着上限、以及降频原因字段里是否出现功耗类原因。这类问题的根在电源，不在卡。
GPU 服务器里的卡是密集排列的，中间那几张卡吸进来的往往是前一张卡排出的热风。常见现象是：同一机箱里，位置靠中间或靠出风口的卡温度系统性比两端高 5–10℃，长期下来最先出问题的也是它们。这不是卡的质量差异，是风道设计问题。判断方法是把温度按卡在机箱里的物理位置排开看，如果呈现明显的位置相关性，就该查风道、查风扇转速曲线、查是否有挡风的线缆或空槽位挡板缺失。空槽位不装挡板会让气流短路，是很典型的低级失误。
具体阈值必须查所用 GPU 型号与驱动版本的官方规格，不同代际差异不小。业界常见的经验范围是：核心温度长期运行在 80℃ 以上需要关注，接近官方标称上限就该介入；显存温度通常比核心更敏感，部分型号的显存温度上限更低，需要单独设阈值。这里强调"按具体机型实测确认"——同样是一张卡，放在风道良好的 4U 机箱里和放在紧凑机箱里，稳态温度可以差十几度，照抄别人的阈值没有意义。正确的做法是：新机上线后先跑一轮满载，记录每张卡的稳态温度和稳态时钟，把这张卡自己的基线记下来，之后以"偏离自身基线"作为告警依据，比绝对阈值更准。
多卡训练里，卡与卡之间要频繁交换梯度、做集合通信。这条路的带宽取决于两样东西：PCIe 链路的宽度与速率，以及卡间高速互联是否正常。链路从 x16 掉到 x4，带宽直接缩水到四分之一左右，多卡加速比立刻垮掉，但单卡跑分完全正常——这就是为什么"多卡比单卡快不了多少"的问题常常被误判成代码写得差。
用 lspci 的详细输出可以读到设备协商后的实际链路宽度与速率，注意要看的是"当前协商值"而不是"设备支持的最大能力值"，很多工具默认显示的是后者，看着是 x16 实际跑在 x4。另外 nvidia-smi 的拓扑查询也能给出卡间连接关系与当前状态。做法上，把新机验收时读到的值存成基线，之后每次重启后自动比对一次，只要不一致就告警。
四类原因最常见。一是插槽本身：主板上的某些槽位走的是芯片组通道，只有 x4 电气，插上去就是 x4，需要查主板手册确认每个槽位的电气规格。二是转接卡与延长线：PCIe 4.0 对信号完整性要求很高，转接卡、延长线、甚至没插紧都会让协商失败降速，这在多卡机箱里非常常见。三是线缆与连接器污染：灰尘、氧化、反复插拔造成的接触不良，会让链路在重启时协商到更低的速率，表现是"时好时坏"。四是主板拓扑与资源分配：某些槽位共享通道，插满之后会拆分，BIOS 设置也可能影响。
卡间高速互联（NVLink 一类）如果出现链路降级或某条链路失效，集合通信会退化到走 PCIe。表现同样是加速比大幅低于预期，但单卡正常、PCIe 链路宽度也正常。判断方法是查互联拓扑与链路状态，看是否所有应有的链路都在、状态是否正常。部分场景下，互联异常还会在驱动日志里留下记录，结合 Xid 一起看更容易定位。
这个没有放之四海皆准的数字，取决于模型规模、batch 大小、通信量与计算量的比例、以及互联拓扑。业界常见的经验范围是：通信占比高的小模型，8 卡加速比能到 5–6 倍就算不错；计算密集、通信占比低的大模型，7 倍以上是有可能的。判断的关键不是和某个绝对值比，而是和这台机器自身的基线比：新机验收时跑一轮标准的多卡基准，记下加速比，之后定期重跑，同样的任务加速比掉了 20% 以上，就该去查链路和降频，而不是先怀疑代码。
很多人问的第一个问题是"用什么采"。答案取决于你是在排查还是在日常监控。
nvidia-smi 是人工排查和临时采样的工具：上去看一眼状态、抓一次 ECC 计数、读一下温度和时钟、查拓扑，这些它都够用。它的问题是单次快照、格式偏人类可读、调用有开销。把它塞进 crontab 每分钟跑一次然后解析文本，是很多团队的第一版方案，能用，但跑久了会遇到两个问题：一是解析格式随版本变化，二是采样点密集时自身开销上升。
专业的 GPU 采集库是为长期、低开销、结构化导出设计的：它常驻运行，自己维护采样，对外提供稳定的指标接口，可以直接对接 Prometheus 一类的时序库。除了常规指标，它还提供健康诊断能力——一组针对 GPU 的针对性检查项，能主动发现一些只在压力状态下才暴露的问题。这是 nvidia-smi 给不了的。
采集本身要读硬件寄存器、要走总线，是有开销的。指标项越多、采样越密，开销越大。业界常见的经验取值是：常规指标（温度、功耗、利用率、显存）10–60 秒一次足够；慢变量（ECC 计数、链路宽度、拓扑）几分钟到十几分钟一次就够；诊断类检查按需触发，不要常驻跑。反过来，为了抓瞬时峰值把采样压到 1 秒以内，在 8 卡机器上会明显吃掉一部分 PCIe 带宽和 CPU，得不偿失。一句话：采样频率要匹配你要观测的现象的时间尺度，几分钟变化的量不需要秒级采样，秒级波动的量才需要。
三个时机。新机上线验收：上架后第一时间跑一轮完整诊断与满载压力测试，把稳态温度、稳态时钟、加速比、链路宽度全部记录下来作为基线。故障复现时：怀疑某张卡有问题，在隔离出来的机器上跑诊断，比在业务压力下瞎猜有效得多。定期体检：按季度或半年做一次全量诊断，尤其是长期满载的机器。体检窗口要提前和业务方约，因为它会占满卡。
一份实用的验收清单至少包含：卡的型号与数量是否与合同一致、每张卡 UUID 与槽位对应关系建档、PCIe 链路宽度与速率达标、卡间互联拓扑符合预期、ECC 已开启且初始计数归零、满载 30 分钟以上后的稳态温度与稳态时钟、整机满载功耗与电源余量、单卡与多卡基准跑分、带外管理可读到温度与电源、日志采集链路打通并验证过一次落盘。这张清单跑一遍不到半天，能省掉后面无数次"到底是卡的问题还是机器的问题"的争论。
复盘一次 GPU 故障，通常需要往前翻至少一个月的数据——因为可纠正 ECC 的增长趋势、温度的季节性漂移、Xid 的重复出现，都是长周期信号。所以建议：指标类时序数据保留 12 个月以上（这类数据压缩后体积不大），原始内核日志与驱动日志保留 3–6 个月或转发到集中存储长期留存，健康诊断结果与健康事件永久保留（量小但价值高）。只留 7 天日志的团队，永远只能看到故障发生的那一瞬间，看不到故障孕育的过程。
告警设计的第一原则是分两类：硬告警和趋势告警。
不设阈值讨论，出现即触发。设备数量变化（卡少了、UUID 变了）、不可纠正 ECC 错误出现、温度超过该机型阈值、整机或单卡功耗长期贴顶、PCIe 链路宽度低于基线。这类告警的处置动作是明确的：把这张卡从调度池摘出去，通知到人，安排窗口排查。
可纠正 ECC 计数在特定时间窗内持续增长（比如 24 小时增量超过某个自定的小阈值，或连续多天单调上涨）、同一 Xid 编号在一段时间内重复出现、稳态时钟相对基线持续偏低、某卡温度相对同机箱其他卡系统性偏高。趋势告警不需要立刻停机，但需要生成一张"待观察卡"清单，让调度系统降低它的优先级。
这里有个很实际的问题：告警发出去了，工程师在工单系统里处理，但下一个训练任务照样被调度到那张卡上，然后又挂，然后又告警。要打断这个循环，调度侧必须能消费健康状态。最小可用实现是：维护一个按 GPU UUID 索引的健康标记表（正常 / 观察 / 隔离 / 待复位），调度器在分配资源时先查这张表，只把"正常"的卡投入调度；容器或作业启动时通过设备可见性控制（如 CUDA_VISIBLE_DEVICES 一类的机制）屏蔽掉被标记的卡。
这个顺序不能颠倒。先隔离：把卡从调度池摘出来，避免继续放大损失，同时保留现场数据（日志、计数器、温度曲线）。再复现：在隔离状态下跑诊断和压力测试，确认问题是稳定的还是偶发的，并明确它属于六类故障中的哪一类。最后才考虑复位或换卡：复位需要停机窗口，换卡要走售后流程，两者都有成本，没搞清楚原因就复位，最常见的后果是两周后原样再来一次。还有一条：复位之后不要直接放回调度池，应该放进"观察"状态跑一个短周期，确认计数不再增长、温度正常、链路正常，再转回"正常"。
很多训练任务是跑在容器里的，容器里看到的 GPU 是宿主机映射进去的子集。这会带来两个监控盲区：一是容器内的监控代理只能看到分给它的那几张卡，看不到整机全貌，所以采集代理要部署在宿主机层而不是容器层；二是隔离动作要在宿主机或调度层做，光在容器里改环境变量没用。虚拟化或直通场景下同理，直通给某个虚拟机的卡，其健康状态需要宿主机侧的管理程序配合采集。多租户环境下，按卡计费与故障责任划分也依赖这套按 UUID 的健康档案——谁的租期内出现了不可纠正错误，记录要能说得清。
训练任务能不能在卡掉之后自动续跑？技术上可以，前提是：检查点（checkpoint）按合理间隔落盘、任务框架支持从最近检查点恢复、调度器能在换成健康卡之后重新拉起任务。真正的问题在成本：检查点太密，写盘开销大；太疏，一次故障丢的进度多。业界常见的经验做法是按"单次丢失可接受的最长训练时间"来反推检查点间隔，比如能接受丢 30 分钟，就按 20–30 分钟存一次。要强调的是：自动续跑是降低损失的措施，不是省略健康监控的理由——它能让你少丢一个晚上的训练，但不会阻止第二张卡在两周后掉。故障自愈的终点应该是"自动摘卡 + 自动重调度 + 通知人复核"，而不是"自动重启后继续用"。
驱动、固件、内核三者之间有兼容矩阵，升级驱动常常要动内核模块，会影响所有在跑的任务。管理上要定几条硬规矩：驱动升级只在预约窗口做，不在业务高峰做；升级前记录当前版本与基线指标；升级后重跑一次基准与健康诊断，比对加速比与稳态时钟是否变化；保留回退方案与旧版本包。频繁追新驱动在训练集群上不划算——新驱动可能修了某些问题，也可能引入新的性能波动。更稳的策略是跟随厂商的长期支持分支，按季度评估一次。
| 故障现象 | 最可能的原因 | 该看哪个指标或日志 | 第一步动作 | 是否需要停机 |
|---|---|---|---|---|
| nvidia-smi 里卡数量变少，或设备 UUID 与基线不符 | 设备从总线脱落、驱动卸载、供电或温度触发保护 | 内核日志中的设备移除与总线错误记录；卡数量与 UUID 基线比对结果 | 比对 UUID 确定是哪一张卡丢失，查看丢失前后的 Xid 与温度记录，把该卡标记为隔离 | 需要停机才能恢复设备枚举 |
| 内核日志出现 Xid 编号记录，任务报错或中断 | 故障域需按所用驱动版本的官方编号表判定（显存、总线、电源或驱动内部） | 内核日志中该编号的出现次数、时间间隔；同期的温度、功耗、ECC 计数 | 查当前驱动版本的官方编号表判定致命还是可恢复；致命则摘卡，可恢复则记录计数并观察是否重复 | 致命类需要，单次可恢复类可延后 |
| 可纠正 ECC 计数持续单调上涨，任务本身没报错 | 显存单元老化或长期高温运行诱发，可能已触发行重映射 | 按卡、按错误类型分开的 ECC 计数增量；行重映射状态与剩余备用行 | 确认增长趋势而非绝对值；检查温度是否偏高；把该卡降为观察并预约窗口做复位评估 | 复位需要窗口，可不立即停机 |
| 同样任务越跑越慢，无任何错误日志，利用率显示很高 | 温度或功耗触顶导致驱动降频；风道不良或电源余量不足 | SM 与显存时钟当前值、降频原因字段、温度、整机功耗与功耗上限 | 对比该卡自身的稳态基线，确认是温度限频还是功耗限频；温度类查风道，功耗类查电源余量 | 通常不需要，先在线调风道或降规格 |
| 多卡加速比远低于预期，单卡性能正常 | PCIe 链路宽度或速率降级（x16 掉到 x4/x1）、槽位电气规格受限、转接卡或线缆问题 | lspci 详细输出中的当前协商宽度与速率；与验收基线的比对 | 核对每个槽位实测宽度与主板手册标称，检查插紧程度、转接卡与线缆，必要时换槽位验证 | 需要停机调整硬件 |
| 互联拓扑异常，集合通信耗时显著上升 | 卡间高速互联链路降级或失效，通信退化到 PCIe 路径 | 互联拓扑查询结果与链路状态；同期 Xid 记录；多卡基准加速比变化 | 与验收时的拓扑基线比对，确认缺失链路；重跑多卡基准量化损失 | 通常需要停机复位或检修 |
把上面这些故障反推回选型，会发现 GPU 服务器对硬件规格的要求和普通机架服务器根本不在一个量级。最容易出问题的三处是电源、散热、带外管理。
8 卡满载训练时整机功耗很高，加上 CPU、内存、磁盘、风扇，峰值往往逼近甚至超过标称配置。电源余量留得不够，表现就是前面说的整机功耗封顶、所有卡一起降频。选型时要把最坏情况算进去：所有卡满载 + 所有风扇满速 + CPU 满载，在这个基础上留余量。冗余电源不是摆设，训练机跑的是三天的任务，一路电源故障就丢三天进度，代价远高于冗余电源的钱。
这是最容易被低估的一项。多卡机器不能按普通机架服务器的散热口径来选——普通 1U/2U 服务器的散热是为每 U 几百瓦设计的，多卡 GPU 机箱每 U 的功耗要高出一截。要关注的点包括：机箱是否为 GPU 做了专门的前后直通风道、风扇是否支持按温度分区调速、空槽位是否配有挡板、以及机柜层面的冷热通道与进风温度。机房侧也要确认：单机柜能承载的功率密度、空调冗余、以及高温季节的进风温度上限。进风温度每升高几度，卡的核心温度会跟着上浮，长期满载的机器对此非常敏感。
带外管理（BMC/IPMI）的价值在故障时刻才显现：当操作系统挂掉、驱动崩溃、或者机器根本起不来的时候，带内采集全部失效，你仍然需要知道机箱里的温度是多少、电源状态如何、风扇是否还在转。没有带外管理，这类故障只能靠人去机房看，或者盲猜。带外网络也要独立——和业务网走同一张网卡同一个网段，业务网拥塞时你连带外都进不去，那就等于没有。选机器时把这两条作为硬指标。
GPU 机器的日志量比普通服务器大：驱动日志、内核日志、采集库的时序数据、诊断结果、任务日志，全都在持续增长。系统盘太小，最先被撑爆的往往是日志目录，结果是故障期间的日志丢失、事后无法复盘。规划上要把日志单独放在容量足够的盘上，配好轮转与清理策略，并把关键日志实时转发到集中存储。这一点在采购阶段提，成本最低；上线后再改，要停机。
自建一套 8 卡机器，除了机器本身的钱，还要算电源改造、机柜功率密度、散热改造、带外网络、日志存储、以及常驻运维的人力。对多数中小团队来说，前期用租用来验证业务模型更划算：业务跑通了、规模稳定了，再考虑自建。比选时可以看一万网络这类深耕 19 年（成立于 2007 年）的服务商，它的 GPU 租用覆盖了从入门到训练级的档位，例如 T4 ¥900/月、RTX3090 24G ¥1750/月、A100 40G ¥2800/月、H100 8 卡整机月 ¥8–12 万（均以官网实时价为准），其余机型与配置需询价。对刚上手的团队，工程师 1 对 1 部署 CUDA/cuDNN/TensorRT/PyTorch/TensorFlow 这类服务能省掉大量环境搭建时间；是否提供因地制宜的健康采集与告警配置建议，也建议在签约前问清楚。
坑是什么：监控面板上只有利用率、显存、温度三条线，看起来很全。为什么发生：这三条是最容易拿到的指标，绝大多数默认采集脚本就带这三项。怎么判断：问自己一个问题——如果一张卡被降频 30%，你现在的监控会不会报警？答案是不会，那就是踩了。怎么规避：至少补齐时钟频率与降频原因、可纠正与不可纠正 ECC 计数、PCIe 链路宽度与速率、Xid 事件、卡数量基线这五类。利用率可以保留，但它是佐证，不是主指标。
坑是什么：看到单比特错误可纠正，就在采集规则里把这类事件丢弃。为什么发生：单次可纠正错误确实常见，看一眼确实"无害"，于是顺手过滤。怎么判断：查一下你有没有保留 ECC 计数的历史曲线，如果只有当前值没有趋势，你就没有判断依据。怎么规避：按卡记录可纠正与不可纠正两类计数并保留至少一年，对"持续增长"设趋势告警；同时把温度一起看，高温诱发的错误先解决散热再评估换卡。
坑是什么：新机通电、装好驱动、直接上业务，健康诊断从来没跑过。为什么发生：业务急着上线，而诊断要占满卡、要花时间。怎么判断：如果没有一份"新机验收基线"文档，你就属于这一类。怎么规避：把验收清单写进上线流程，跑一次完整诊断 + 满载压测，记录稳态温度、稳态时钟、加速比、链路宽度、ECC 初值，之后每季度重跑一次比对。没有基线的监控，等于没有判据。
坑是什么：8 卡跑出 3 倍加速，工程师花两周优化通信逻辑，性能纹丝不动。为什么发生：默认认为硬件是好的，链路是按标称跑的。怎么判断：先用 lspci 看当前协商宽度，再看互联拓扑状态，这两个查完再谈代码。怎么规避：把"核对链路宽度与拓扑"设为多卡性能问题的第一个排查步骤，并且在验收时就把基线加速比记下来，用"相对自身基线的变化"来判断是硬件退化还是代码问题。
坑是什么：卡掉了一次，重启或复位之后状态正常，于是照常参与调度。为什么发生：复位成本最低，业务又急着要资源，看起来"修好了"。怎么判断：复位后有没有观察期？没有观察期就是直接放回去。怎么规避：建立四级状态标记（正常 / 观察 / 隔离 / 待复位），复位后的卡必须先进入"观察"状态，跑一个短周期确认 ECC 不再增长、温度与时钟回到基线、链路宽度正常，再转回"正常"。日志盘也要留够容量，否则复位前的现场数据已经丢了，什么都没得看。
Q1：健康体检多久做一次合适？
A1：分三层。常规指标（温度、功耗、时钟、ECC 计数、链路宽度）是常驻采集的，不需要单独"体检"；完整健康诊断与满载压力测试建议每季度一次，长期满载或运行环境温度偏高的机器可以加密到每月一次；新机上线、硬件变更、驱动升级、故障复现这四个时点必须额外跑一次。诊断会占满卡，需要提前和业务方约窗口。判断频率是否合适的标准是：你是否能在故障发生前，从历史数据里看到它的苗头——如果每次都是故障先发生、数据后补，说明体检频率或留存周期不够。
Q2：核心温度多少算高？
A2：具体阈值以所用 GPU 型号的官方规格为准，不同代际差异较大，不要跨型号照抄。业界常见的经验范围是：满载稳态下核心温度长期在 80℃ 以上需要关注，接近官方标称上限就必须介入排查风道与机房进风温度。更实用的判据是自身基线：新机验收时记录满载稳态温度，之后同一负载下高出基线 5℃ 以上就值得查，因为这通常意味着风道堵塞、风扇老化或机房进风温度升高。另外显存温度要单独看，部分型号的显存温度上限比核心更低，只看核心温度会漏掉显存过热导致的降频。
Q3：掉卡之后这台机器还能继续用吗？
A3：能继续用，但前提是把掉的那张卡真正隔离掉，而不是重启之后当作没发生过。掉卡是结果，原因可能是显存老化、供电不足、温度保护或总线接触问题，重启只是让设备重新枚举，原因还在。正确做法是：先通过 UUID 确定掉的是哪一张，把该卡从调度池摘出，查它掉卡前的 Xid、ECC 趋势、温度与功耗记录，判断属于哪一类故障；然后在隔离状态下跑诊断与压测确认。剩下的卡可以继续使用，但要加强该机的巡检频率，因为同一机箱里的卡往往共享相同的风道与电源环境。
Q4：可纠正 ECC 涨到多少才需要处理？
A4：不要等绝对值。单比特可纠正错误在大规模显存上偶发出现属于正常现象，真正的信号是增长趋势：如果同一张卡在数天到数周内持续、单调上涨，尤其上涨速度在加快，就该处理，哪怕绝对值还很小。处理方式按顺序来：先查温度是否长期偏高（高温会显著提高错误率，散热问题解决后计数可能就稳住了）；再查是否触发了行重映射、剩余备用行还有多少；最后才安排窗口做复位或换卡评估。绝对阈值可以作为辅助参考，但不要作为唯一判据，否则会错过早期信号。
Q5：多卡加速比多少算正常？
A5：没有统一标准，取决于模型规模、batch 大小、通信量与计算量的比例、以及卡间互联拓扑。业界常见的经验范围是：通信占比高的小模型，8 卡能到 5–6 倍已属正常；计算密集、通信占比低的大模型，7 倍以上也有可能。更靠谱的做法是和自己的基线比：验收时跑一轮固定的多卡基准，记录加速比，之后定期重跑。同样的任务加速比掉了 20% 以上，先查 PCIe 链路宽度、互联拓扑状态和是否降频，这些都正常了再去怀疑代码。另外要注意，超大批次下的加速比和小批次不可直接比较。
Q6：带外管理是不是必须买？
A6：对多卡 GPU 服务器，答案是必须。带外管理（BMC/IPMI）的作用在操作系统挂掉时才体现：驱动崩溃、内核 panic、机器起不来的时候，带内采集全部失效，你仍然需要知道机箱温度、风扇转速、电源状态，否则只能靠人去机房或者盲猜。选的时候还要确认带外网络是独立的，不要和业务网共用一张网卡和网段，否则业务网拥塞时连带外都进不去，等于没有。这项在自建采购时要写进硬指标；租用场景下，"能否查看带外温度与电源""带外是否独立组网"也是签约前值得问清楚的两条。
Q7：驱动版本要不要一直追新？
A7：不建议。驱动、固件、内核三者有兼容矩阵，升级驱动往往要重新编译或加载内核模块，会影响所有在跑的任务。更稳的策略是跟随厂商的长期支持分支，按季度评估一次，只在明确修复了你所遇到的问题、或新硬件新框架有硬性要求时才升级。升级必须走流程：预约窗口、记录当前版本与基线指标（稳态时钟、加速比、温度）、升级后重跑基准与健康诊断做比对、保留旧版本包与回退方案。追新的隐藏成本是性能波动——新驱动可能修了问题，也可能让某类 kernel 变慢。
Q8：训练中断能不能自动续跑？
A8：技术上可行，但要满足三个条件：检查点按合理间隔落盘、训练框架支持从最近检查点恢复、调度器能在换到健康卡之后重新拉起任务。检查点间隔建议按"能接受的最长丢失时间"来反推，比如能接受丢 30 分钟，就按 20–30 分钟存一次，存得太密会明显占用 I/O 与存储。需要明确的是：自动续跑是降低损失的措施，不能替代健康监控——它能让你少丢一晚训练，但不会阻止第二张卡在两周后掉。完整的自愈链路应该是"自动摘卡 + 自动重调度 + 通知人复核"，而不是自动重启后继续跑同一张卡。
本文关于 Xid 事件、ECC 机制（可纠正与不可纠正的区分、行重映射）、温度与功耗保护行为、PCIe 链路协商、卡间互联拓扑的说明，依据 GPU 厂商公开的驱动与硬件文档，以及 DCGM 一类官方采集工具公开的能力说明。其中 Xid 编号与具体含义的对应关系，需对照你当前所用驱动版本的官方文档编号表判定，本文不提供编号对照表，也不建议采用非官方渠道流传的对照表。文中提到的温度区间（如满载稳态 80℃ 以上需关注）、多卡加速比经验区间（5–7 倍量级）、采样间隔（常规指标 10–60 秒、慢变量数分钟至十余分钟）、日志留存周期（指标 12 个月以上、原始日志 3–6 个月）均为业界常见经验范围，需按具体机型、机箱风道、机房进风温度与实际任务负载实测确认，不构成对任何特定环境的承诺。文中出现的租用价格为公开渠道明示价锚点，仅供量级参考，实际配置、带宽与价格需实时询价，具体以签约时最新报价与合同为准。更多产品与服务信息可参见 https://www.idc10000.net/ 。
把监控建起来的顺序应该是这样排：先把六类故障的采集链路接通（内核日志落盘 + 带内周期性采样 + 带外传感器），再补齐五类必采指标（时钟与降频原因、ECC 两类计数、PCIe 链路宽度与速率、Xid 事件、卡数量与 UUID 基线），然后才做告警分级，最后做调度联动。如果预算或人力有限，优先级反而该这样排：ECC 计数与 Xid 事件的留存优先于可视化大屏，新机验收基线优先于告警阈值调优，与调度的隔离联动优先于更多的图表。理由很直接——没有留存就没有复盘，没有基线就没有判据，没有隔离联动告警就只是噪音。对已经踩过掉卡的团队，第一步建议是补一份按 UUID 建档的卡级健康档案，把过去半年能找回的日志全部捞出来补录，这比新买一台机器更能解决眼前的问题。
一万网络深耕 19 年（成立于 2007 年），提供 GPU 服务器租用与算力相关服务，覆盖入门推理到多卡训练的不同档位：T4 ¥900/月、RTX3090 24G ¥1750/月、A100 40G ¥2800/月、H100 8 卡整机月 ¥8–12 万，具体机型、带宽与价格需实时询价，以官网实时报价与合同为准，其余配置与机型一律需询价。服务层面包括 7×24 中文工单、平均 5 分钟响应、硬件故障 10 分钟自动迁移、免费系统盘快照（每日 3 份、30 秒回滚）、免费备案协助、5–20G 免费 DDoS 防护、自营机柜最快 1 分钟上架、工程师 1 对 1 部署 CUDA/cuDNN/TensorRT/PyTorch/TensorFlow、BGP 多线 + CN2 GIA 回国线路，节点覆盖华南、华东、华北、中国香港及海外多地。如果你的团队正在规划多卡训练环境，或者手上已经有一台"偶尔掉卡"的机器需要排查，可以带上机型、卡型、任务类型与当前监控覆盖情况来沟通，重点确认三件事：电源余量与散热规格是否匹配满载功耗、带外管理与带外网络是否独立可用、以及日志与健康指标的采集与留存是否已经打通。具体机型、带宽与价格需实时询价，以官网实时报价与合同为准。
上一篇：Spark 作业一跑到 shuffle 就 OOM：executor 内存模型、分区数与 spill 这三处该怎么调
下一篇：K8s 集群才二十几个节点，apiserver 却开始间歇性超时：etcd 的 fsync、压缩与 db 配额这三件事查过没有
Copyright © 2013-2020 idc10000.net. All Rights Reserved. 一万网络 科技有限公司 版权所有 深圳市科技有限公司 粤ICP备07026347号
本网站的域名注册业务代理北京新网数码信息技术有限公司的产品
