在 AI 基础设施领域，有一个常被低估的事实：GPU 的可靠性远不及 CPU。当你的集群规模从百卡扩展到万卡级别，硬件故障从偶发事件变成必然出现的常态问题。Modal 在过去几年间将并发 GPU 数量提升至两万卡以上，累计启动超过四百万个云实例，这段历程让他们几乎遭遇了所有可能出现的 GPU 可靠性问题。本文将系统梳理他们在 GPU 可靠性建设方面的工程实践，为规模化 AI 基础设施提供可落地的参考框架。
云实例类型测试与选择策略
规模化 GPU 运维的第一步是理解不同云厂商、实例类型之间的可靠性差异。这种差异往往超乎预期，同一款 GPU 在不同云平台上的表现可能判若两物。Modal 将参与的云厂商匿名化为 A、B、C、D 四家，通过内部基准测试工具 modal-host-bench 持续评估各实例类型的性能与可靠性指标。
从实例启动成功率来看，Cloud A 的 API 设计最为简洁可靠，收到 HTTP 201 响应后有 99.6% 的概率能在两到三分钟内成功启动实例。然而，这并不意味着 Cloud A 的所有实例类型都值得优先选用 —— 其 H100 在 StableDiffusion 文本生成图像任务中的性能比 Cloud C 和 Cloud D 低了约 50%。这个差距意味着在某些特定工作负载下，选择性能更优的实例类型可能比选择启动更快的实例更能提升整体效率。
热管理是另一个关键的可靠性维度。Cloud C 的 H100 在 2025 年曾出现过持续过热的问题，部分 GPU 核心温度攀升至 90°C 以上。值得注意的是，GPU 性能从 70°C 左右就开始出现衰减，到达 94°C 时性能可能下降至峰值的 50%。这种热节流现象不仅影响任务执行效率，长期高温运行还会加速硬件老化，增加故障风险。Modal 发现的另一个差异是内存预留：Cloud C 的 H100 预留了比竞对多 228MiB 的显存，直接减少了用户可用的 GPU 内存容量。
时钟与功耗相关的硬件事件同样值得关注。Cloud D 的 A10G 频繁触发 HW_SLOWDOWN 和 HW_POWER_BRAKE 事件，表明硬件在主动降频以应对功耗或热约束。更棘手的是某些区域的美团 A10 出现了较高的不可纠正 ECC 错误率，而这类问题往往难以快速发现。综合考量后，Cloud D 提供了最佳的性价比，其裸金属服务器在原始算力上表现突出，但需要在价格模型中纳入上述可靠性惩罚项。
针对不同实例形态的实测数据揭示了一个重要结论：在预算允许的情况下，应优先选择 SXM 形态的 H100 而非 PCIe 版本。基准测试表明，PCIe H100 在矩阵乘法运算中的耗时比 SXM 版本高出 67.5%，吞吐量则下降 40.3%。这种差距源于 SXM 接口提供更高的 NVLink 带宽和更低的通信延迟，对于大规模分布式训练和推理场景尤为关键。
机器镜像的持续集成与自动化测试
机器镜像是 GPU 服务器的启动根基，包含内核、操作系统、NVIDIA 驱动、系统库以及必要的应用软件。镜像的一致性和新鲜度直接影响实例的可靠性和安全性。Modal 追求在多云环境中保持镜像高度一致 —— 相同的内核版本、相同的驱动版本、相同的系统配置 —— 以降低跨云迁移和故障排查的复杂度。
在早期发展阶段，Modal 的镜像更新依赖人工测试和手动发布，这导致错误频繁发生。当集群规模扩大到一定程度后，这种模式难以为继。他们转而采用持续渐进式集成策略：新镜像在灰度发布前必须通过自动化测试套件的验证，测试覆盖从系统工具到 GPU 功能的全链路。这种「左移」的质量保障思路将大量潜在问题拦截在生产环境之外。
镜像构建流程的末端集成了 NVIDIA Data Center GPU Manager（DCGM）和自定义的 GPU 功能测试。这些测试在容器运行时内部执行，确保宿主机与客户容器都能正确识别和调用 GPU。测试通过后，镜像才会进入生产环境的滚动升级流程。可视化数据显示，某个新版本镜像在上线后被快速回滚 —— 图中橙色版本在上线后不久即被撤下，原因是测试未能捕获的兼容性问题在生产环境中暴露。
云厂商在镜像支持能力上的差距同样显著。主流超大规模云服务商都支持自定义镜像加载，且实例启动性能良好。但众多新兴云厂商在此环节表现欠佳：部分平台不支持镜像定制，且由于虚拟机管理程序和缓存机制的效率问题，实例启动时间往往超过五分钟，而超大规模云厂商的平均启动时间仅需约两分钟。另一个值得注意的细节是区域镜像复制速度：Cloud D 需要三小时才能将新镜像同步至十个区域，这对需要快速响应安全漏洞或驱动更新的场景构成了挑战。
启动时验证与轻量级检查策略
实例启动是将镜像转化为可用计算资源的关键环节，也是发现硬件问题和配置错误的第一道防线。然而，规模化运维场景下的启动验证需要在检查深度和启动延迟之间取得平衡。过于严格的检查会增加调度开销，而过于宽松的检查则可能将问题实例交付给终端用户。
这里存在一个核心权衡：深度诊断与快速启动难以兼得。DCGM 的完整诊断套件 dcgmi diag --run 4 能够发现大量长尾问题，但执行时间约为一个小时。即使是最基础的级别 --run 1 也至少需要一分钟。而 GPU 硬件在出厂时已经通过了云厂商的检测流程，超大规模云厂商的硬件故障率大约在万分之一级别。考虑到这一点，对每一台实例都执行深度诊断并非明智之举 —— 这就像在街边咖啡店买咖啡时坚持要先闻一闻牛奶的新鲜度。
Modal 在启动阶段采用的策略相对轻量：执行 systemctl 查询确认关键服务状态，运行 nvidia-smi 获取 GPU 基础信息，并在随机选择的 GPU（通常是索引 0 到 7 中的某一个）上执行基本的读写测试。这套流程足以捕获绝大多数与 GPU 相关的启动问题，同时将额外延迟控制在可接受范围内。目前，Modal 生产的实例中几乎没有 GPU 问题能够逃脱这套检查并进入用户容器。
不过，仍有一个烦人的例外：Cloud C 的 L4 GPU 在 CUDA 初始化阶段有约 0.1% 的概率出现失败。应用代码在调用这些 GPU 时需要实现 cuInit 重试逻辑以应对这一偶发问题。这个案例说明，即使是最成熟的云平台也可能在特定硬件型号上存在尚未完全解决的固件或驱动层面的问题。
全生命周期的主动与被动健康检查
实例启动并投入生产后，健康检查工作并未结束。持续的监控和定期的主动检测是确保集群长期稳定运行的关键。Modal 将健康检查分为被动和主动两类，两者在实现方式、资源消耗和覆盖范围上各有侧重。
被动健康检查不占用 GPU 资源，以只读方式从系统日志和监控接口获取健康状态信息。这类检查的核心是 DCGM 的周期性采集和 dmesg 日志分析。DCGM 能够报告不可纠正的 ECC 错误、热违规事件、同步提升（Sync Boost）违规、硬件降速事件以及超过 88°C 的高温预警。一个直观的可视化图表展示了各云厂商每小时的 Xid 关键错误率（按 GPU 数量归一化），Cloud B 的错误率明显高于其他三家，是需要重点关注的薄弱环节。
主动健康检查需要独占 GPU 设备并执行读写操作以评估其健康状态。DCGM 的 diag 命令、NVIDIA 的 nvbandwidth 带宽测试工具以及 GPUBurn/GPU-fryer 等压力测试工具都属于主动检查范畴。由于主动检查会暂时占用 GPU 资源，调度频率需要谨慎把控 —— 过度使用会造成资源浪费，检查不足则可能让退化中的硬件持续服务进而引发更严重的故障。
参照 SemiAnalysis 提出的 ClusterMAX 健康检查标准，Modal 确保每台 GPU 节点每周至少执行一次深度主动检查。对于租期超过 24 小时的长生命周期实例，每周会执行 DCGM 诊断级别 2 的检查、GPUBurn 压力测试以及本地 NCCL all-reduce 测试以验证 NVLink、NVSwitch 和 SHM 通信性能。如果检测失败，实例将被标记为不健康并进入隔离状态，等待进一步的人工或自动处置。
随着训练和推理场景对高速互联的需求日益增长，Modal 正在扩展主动检查的范围，新增的项目包括本地 InfiniBand all-reduce 测试（通过禁用 NVLink/p2p/SHM 来验证纯网络性能）以及双向的 ib_write_bw 和 ib_write_latency 性能测试。这些测试将提供更完整的网络健康画像，帮助识别互联层面的性能瓶颈和潜在故障点。
在实际处置策略上，Modal 选择了一种务实但略显「浪费」的方式：由于 GPU 重置和隔离恢复的成功率无法保证，他们直接标记整台主机为不健康状态，执行 draining 操作后进行实例销毁或重装。这种方法虽然增加了硬件置换成本，但大幅简化了运维逻辑，避免了在复杂恢复流程中引入更多不确定性。
可观测性建设与容器级监控
可观测性是可靠性工程的最后一道防线。当自动化健康检查未能拦截问题实例时，完善的监控和日志体系能够帮助快速定位根因并触发人工干预。Modal 为每个容器提供了四类核心 GPU 指标的实时视图：显存使用率、计算利用率、温度和功耗。这些指标来源于 DCGM 的持续采集，经过聚合后以仪表盘形式呈现给用户。
需要注意的是，当前这些指标是在容器级别聚合的，这意味着当一台八卡服务器中仅有一张 GPU 出现异常时，聚合后的数据可能会被其他七张健康的 GPU 数据所稀释，导致问题难以被及时发现。Modal 正在改进这一缺陷，计划引入更细粒度的单卡指标监控。
除了指标数据外，异常 GPU 健康事件也会被写入容器的日志流中。一个典型的例子是连续出现的 Xid 13 错误，这类错误通常与显卡内存访问异常相关，日志中会标记为「gpu-health」级别的事件便于检索和告警。Modal 还维护了一份详尽的 Xid 和 sXid 错误码字典，将其开源为 GPU 故障排查的最佳参考资源。
支持体系与 SLA 保障
再完善的自动化系统也无法覆盖所有边界情况和黑天鹅事件。Modal 为企业客户建立了专属的 Slack 渠道，通过 Pylon 工具实现问题从创建到解决的全程追踪。由于其底层架构设计为动态计算 autoscaling，替换故障 GPU 的操作可以在分钟级完成。对于社区用户，Modal 保持响应活跃度，并在确认因己方失误导致用户任务受损时提供积分补偿。
结语
GPU 的可靠性短板是一个被长期低估的问题。Meta 在 LLaMA 3 训练论文中披露的数据颇具冲击力：在所有意外中断中，GPU 相关问题占比高达 58.7%，而 CPU 问题仅占 0.5%。这一差距在规模化部署场景下会被进一步放大。Modal 的实践表明，通过系统化的实例选型、镜像质量保障、启动验证、健康检查和可观测性建设，可以将 GPU 可用性提升至「四个九」的水平。然而，要真正解决这一系统性挑战，仍需整个行业在硬件可靠性上持续投入。
资料来源：Modal Engineering Blog, "Keeping 20,000 GPUs healthy"（2025 年 12 月 28 日）。