Modal通过镜像预检、轻量启动验证、全周期健康监控及快速替换机制，在20,000+并发GPU规模下实现99.99%可用性，揭示云GPU隐藏的可靠性鸿沟。
那些在AI训练中呼风唤雨的顶级显卡——比如H100，在云上跑起来居然可能“热到罢工”、“慢到怀疑人生”，甚至刚启动就悄悄报错？这是真实发生在全球头部AI基础设施平台Modal身上的日常。
作为一家为开发者提供弹性GPU算力服务的公司，Modal在过去几年里累计启动了超过四百万个云实例，同时运行的GPU数量一度突破两万张！就在这样的规模下，他们几乎把所有GPU可能出现的故障类型都踩了个遍。
天，我们就来深度拆解这篇由Modal核心工程师Jonathon Belotti亲自撰写的长文，看看这家低调却硬核的技术团队，是如何用一套精密如钟表的可靠性体系，把“不可靠”的GPU变成稳定可靠的生产力引擎的。
云厂商之间的GPU差距，远比你想象的大得多
很多人以为，只要选了同一型号的GPU，比如H100，不管是在哪家云平台租用，性能和稳定性应该差不多。但Modal的实际测试结果狠狠打了这种天真想法的脸。他们发现，即便是同一款H100，在不同云厂商（文中以A、B、C、D代称）的数据中心里，表现天差地别。比如某家云厂商（Cloud C）的H100曾经连续几个月运行温度超过90摄氏度！要知道，GPU在75摄氏度以上就开始出现性能衰减，90度几乎等于“边煮边算”，FLOPS直接腰斩。更离谱的是，这家厂商还偷偷预留了228MiB的显存，导致用户实际可用显存比别家少了一截——这可不是小数目，对大模型推理来说可能就是能不能跑起来的关键。
再比如另一家云厂商（Cloud D）的A10显卡，在某些美国区域频繁出现硬件级降频（HW_SLOWDOWN和HW_POWER_BRAKE），这意味着即便你付了全价，GPU也可能在关键时刻“躺平”。而最让人哭笑不得的是，同样是H100，PCIe版本和SXM版本的性能差距高达67%！在矩阵乘法这种基础操作上，SXM版每秒能跑678万亿次浮点运算，而PCIe版只有405万亿次。带宽方面更是惨不忍睹：主机到设备的 pageable 带宽，SXM是7.68 GiB/s，PCIe居然飙到21 GiB/s？别高兴太早——这是反常现象，实际上是因为PCIe架构在某些测试路径下存在虚假高带宽，真实有效吞吐反而更低。Modal通过自研的基准测试工具“modal-host-bench”持续监控这些指标，并据此对不同云厂商、不同区域、不同机型打分，甚至给“问题实例”打上惩罚性价格标签——不是便宜就好，可靠才是王道。
从镜像构建开始，就把故障“推左”扼杀在摇篮里
Modal深知，等GPU出问题再修，成本太高。所以他们的策略是“把失败尽可能往左推”——也就是在实例真正交付给用户之前，就完成尽可能多的验证。这一切始于机器镜像（Machine Image）的构建。他们的镜像不是随便打包一个Ubuntu加驱动就完事，而是包含统一内核、最新NVIDIA生产级驱动（目前是580.95.05版本）、系统库、配置文件以及Modal自己的运行时组件。最关键的是，这套镜像体系早已告别早期的手动更新模式，转而采用“持续集成 + 自动化测试”的流水线。每次新镜像构建完成后，系统会自动在容器内运行一系列GPU读写测试和DCGM（数据中心GPU管理器）健康检查。只有全部通过，这个镜像版本才会被推送到生产环境。
这种做法的好处在于，一旦某个驱动版本或内核组合存在兼容性问题，会在镜像阶段就被捕获，根本不会流入线上。文中还附了一段Terraform风格的配置代码，展示了他们如何在镜像构建流程中嵌入健康检查脚本：
provisioner "shell" { |
值得注意的是，这种深度定制镜像的能力，恰恰是主流云厂商（AWS、GCP、Azure、OCI）与新兴“小云”（如Lambda Labs、Nebius）的关键分水岭。很多小云根本不支持自定义镜像，或者启动速度极慢——有些连默认镜像都要5分钟以上才能启动，而Modal在某家云厂商（Cloud C）上平均不到2分钟就能完成VM启动。不过也有短板：比如某家云厂商（Cloud D）的镜像跨区域复制极其缓慢，10个区域要3小时才能同步完，这对全球调度是个挑战。
启动时轻量快检，宁可弃用也不冒险交付
当镜像被加载到物理服务器上，实例正式启动那一刻，才是真正考验开始的时候。Modal在这里面临一个经典权衡：检查越彻底，启动越慢；启动越慢，用户等待时间越长，甚至影响故障转移效率。因此，他们放弃了耗时动辄一小时的深度诊断（如dcgmi diag --run 4），转而采用“轻量快检”策略。具体包括：用systemctl确认系统服务状态、用nvidia-smi快速读取GPU基本信息、以及对随机一张GPU（0-7号）执行基础读写测试。整个过程控制在几十秒内，确保不影响弹性伸缩的响应速度。
这套机制效果显著——如今几乎不会有带病GPU流入用户容器。唯一的例外是某家云厂商（Cloud C）的L4显卡，在0.1%的启动场景中会出现CUDA初始化失败。对此，Modal的解决方案很务实：要求应用层代码加入cuInit重试逻辑。这种“不追求100%完美，但确保问题可控”的工程哲学，正是他们在超大规模下保持稳定的关键。
全生命周期监控：被动+主动双保险，不让一块坏卡漏网
实例上线后，战斗才刚刚开始。GPU在长时间高负载运行中可能因散热不良、电压波动、内存错误等原因逐渐劣化。为此，Modal建立了双轨制健康检查体系：被动监控 + 主动诊断。
被动监控完全无侵入，只读不写。系统定期采集dmesg日志和DCGM健康数据，重点关注几类致命信号：Xid错误（尤其是级别13以上的严重错误）、不可纠正的ECC内存错误、温度超过88℃、硬件强制降频等。数据显示，某家云厂商（Cloud B）的Xid错误率远高于同行，成为重点监控对象。而前文提到的“94℃烤GPU”事件，也正是通过被动监控第一时间发现的。
主动诊断则需要独占GPU资源，因此调度更复杂。Modal遵循“每周至少一次深度检查”的原则，对长期运行的实例执行：DCGM二级诊断、GPUBurn压力测试（模拟满载工况）、本地NCCL all-reduce测试（验证NVLink/NVSwitch互联性能）。一旦任一测试失败，该实例立即被标记为不健康，停止接收新任务，甚至进入“隔离区”供工程师或云厂商进一步分析。未来，他们还将加入InfiniBand网络专项测试，以应对日益增长的多机多卡训练需求。
发现问题？直接换掉，绝不修修补补
面对故障GPU，很多团队可能会尝试“热重置”或“隔离坏核”等恢复手段。但Modal的态度非常坚决：不修，直接换！原因很简单——恢复操作复杂且成功率无法保证，而他们的架构天生支持快速替换。一旦检测到异常，系统会自动将该主机“drain”（排空任务），然后要么销毁实例重新申请，要么触发整机重装。这种“宁可浪费一点资源，也要确保绝对干净”的策略，极大简化了运维逻辑，也提升了整体SLA。
可观测性拉满：让用户自己也能看懂GPU健康状况
再好的后台系统，如果用户看不见，信任感就无从建立。Modal为此打造了极致透明的可观测体系。每个容器都能在仪表盘上实时查看四项核心指标：显存使用率、计算利用率、温度、功耗。虽然目前这些数据是按容器聚合的（难以定位单卡问题），但已经足够帮助用户判断是否存在异常。更贴心的是，所有异常GPU事件都会以“gpu-health”日志的形式直接注入容器日志流。比如当系统检测到多次Xid 13错误时，用户在日志里就能看到醒目的提示。Modal甚至还维护了一份全网最详尽的Xid/sXid错误字典，堪称GPU故障排查圣经。
企业级支持兜底，黑天鹅也不怕
即便有上述层层防护，极端情况仍可能发生。对此，Modal为企业客户开通了专属Slack私有频道，对接Pylon工单系统，承诺严格SLA。普通用户则可通过社区渠道获得响应，若因Modal漏检导致损失，还会发放算力积分补偿。数据显示，他们的GPU可用性已稳定达到“四个九”（99.99%），但这背后是无数细节堆砌而成的护城河。
结语：GPU可靠性，是AI时代的隐形基石
文章最后引用了Meta训练LLaMA 3时的惊人数据：58.7%的意外中断源于GPU问题，而CPU问题仅占0.5%。这说明在AI狂飙突进的今天，硬件可靠性已成为最大瓶颈之一。Modal的这套体系，不仅是对客户的承诺，更是给整个行业的启示：别再迷信“大厂GPU=稳定”，真正的稳定性，来自于对每一层细节的极致掌控。正如作者所言：“当你独自上路时，别说我没警告过你。”