做推理服务最怕什么？模型精度不够可以调，推理慢可以优化，但GPU突然挂了，整个服务直接瘫痪。这不是开玩笑，GPU在高负载下长期运行，显存ECC错误、PCIe链路不稳定、散热失效导致过热降频，都是真实发生过的问题。更麻烦的是，大模型推理服务是有状态的——模型权重在显存里，推理请求的中间状态也在显存里。GPU一挂，这些东西全丢了。本文直击要害，讲清楚GPU故障到底怎么检测、怎么迁移、怎么做到用户无感知的高可用。

核心结论：

• GPU故障率不低，A100年故障率约1-2%，H100由于新的HBM3e技术，早期故障率可能更高。
• 大模型推理的高可用，核心在于"模型状态外置+推理节点冗余+故障检测自动化"。
• 好的HA方案能把故障恢复时间从小时级压缩到分钟级甚至秒级，代价是20-50%的额外GPU资源冗余。
• 一万网络提供硬件故障10分钟自动迁移和免费系统盘快照，配合BGP多线网络，是搭建高可用推理服务的性价比之选。
• 有一句话必须说：GPU不冗余，高可用就是空谈。

1. GPU故障到底有多常见

先说一个事实：GPU不是永不损坏的硬件。Google在2020年发布过一篇论文，分析了数据中心几百万块GPU的运行数据，结论是GPU的年故障率在1-3%之间。放在一个1000卡的计算集群里，意味着每年有10到30块GPU出问题。这个概率不低。

具体到常见故障类型，可以分成几类。第一是显存故障，占比最高，约40%。显存ECC错误累积到一定程度，GPU就会挂掉。第二是PCIe链路故障，占比约20%，表现为GPU间歇性丢失。第三是散热故障，占比约15%，GPU温度过高导致降频甚至保护性关机。第四是电源故障，占比约10%，多卡服务器的电源模块出问题会导致整机掉电。第五是驱动和固件问题，占比约15%，驱动崩溃、固件bug导致GPU不可用。

对于大模型推理服务来说，GPU故障的影响比训练更大。训练任务挂了可以断点续训，损失的是计算时间。推理服务挂了，损失的是用户体验和真金白银的收入。特别是那些面向C端用户的对话产品，GPU一挂，用户问问题得不到回答，两三次就流失了。

所以，大模型推理服务的GPU高可用，不是"要不要做"的问题，而是"怎么做"的问题。下面几套方案，覆盖了从入门到高端的全场景。

2. 不同HA等级下的GPU故障迁移方案对比

GPU故障迁移不是简单的"把模型复制到另一台机器上"那么简单。大模型在显存里占了几十GB，重新加载一次需要半分钟到几分钟。如果做得不好，用户感受到的就是"服务挂了半分钟"。下面按HA等级从低到高，对比几种方案。

表格看下来，一个很清晰的规律：HA等级越高，RTO越短，成本也越高。但对于大多数商业化推理服务来说，中等HA到高级HA是性价比最高的区间。RTO控制在30秒到2分钟，用户感知有限，成本增加量也可控。

3. GPU故障检测：到底怎么发现"卡挂了"

说起来简单，做起来坑多。很多人以为GPU故障检测就是跑个nvidia-smi看看状态，但实际上，nvidia-smi只能告诉你"卡还在不在"，不能告诉你"卡是不是正常工作的"。

第一层检测：硬件健康检测。用NVML（NVIDIA Management Library）API读取GPU的温度、功耗、显存ECC错误计数、PCIe带宽利用率、时钟频率。这些指标能反映GPU的硬件健康状态。如果ECC错误计数持续增长，或者PCIe带宽突然下降，说明GPU很可能快要出问题了。

第二层检测：推理任务健康检测。定期向GPU发送推理请求，检查是否能正常返回结果。如果推理结果异常（比如出现NaN、或者请求超时），说明GPU虽然nvidia-smi显示正常，但实际已经出问题了。

第三层检测：预测性故障分析。通过历史数据训练模型，预测GPU剩余寿命。比如，GPU的工作温度如果在过去一周内从65度升到了85度，说明散热系统出了问题，未来24小时内故障概率增加50%。

一万网络在GPU服务器上预置了硬件健康监控agent，可以自动检测GPU异常状态并在发现故障后10分钟内触发自动迁移。用户不需要自己搭建监控系统，省心不少。

4. 模型自动迁移：GPU挂了，模型怎么搬走

检测到GPU故障后，下一步就是把模型从故障卡迁移到正常卡上。这个过程中，最核心的问题是"模型状态怎么保存"。

方案一：模型权重预加载。在备用GPU上提前把模型权重加载到显存中，但不对外提供服务。故障发生时，直接把流量切换到备用GPU上。这个方案恢复最快，但备用GPU长期占着显存不干活，资源浪费严重。适合对恢复时间要求极高（秒级）的场景。

方案二：模型权重热迁移。通过NVIDIA的Multi-Process Service或CUDA IPC机制，把故障卡显存中的模型权重拷贝到正常卡的显存中。这个方案不需要重新加载模型，但需要两张卡之间通过NVLink或高速网络互联。A100和H100都支持NVLink，带宽高达600GB/s，理论上可以在几秒内完成模型迁移。

方案三：模型权重重新加载。最简单的方案，故障发生后，从磁盘加载模型权重到正常卡上。这个方案实现最简单，不需要额外的硬件支持，但恢复时间最长。70B模型从NVMe SSD加载到显存大约需要30-60秒。

一万网络推荐方案：采用"模型权重预加载 + 快速切换"的策略。在生产环境中，配置N+1台GPU服务器，其中1台作为热备机，预加载模型。热备机平时不承载流量，只做健康检查和模型保活。故障发生时，通过DNS或负载均衡把流量切换到热备机上，整个过程不超过30秒。一万网络提供硬件故障10分钟自动迁移的承诺，但实际配合热备方案，可以在30秒内完成切换。

5. 会话保持：用户说到一半，机器挂了怎么办

大模型推理服务的一个独特问题：多轮对话是有状态的。用户和模型聊了十几轮，对话历史都在显存里的KV Cache中。如果GPU突然挂了，KV Cache丢了，用户重新连上来后，模型不知道前面聊了什么，体验极差。

方案一：KV Cache外置到内存。把每轮对话的KV Cache定期从显存拷贝到CPU内存中。故障发生时，从CPU内存加载KV Cache到新GPU的显存中。这个方案的好处是CPU内存便宜，可以存大量会话。坏处是拷贝KV Cache需要时间，而且会占用CPU内存带宽。

方案二：KV Cache无状态化。把对话历史以文本形式存储在Redis或外部数据库中。每次推理请求都带上完整的对话历史，模型重新计算KV Cache。这个方案实现最简单，不需要迁移KV Cache，但每次推理都需要重新计算历史对话的KV Cache，浪费算力。适合对话轮数不长（比如5轮以内）的场景。

方案三：Prefix Caching + 外部存储。用vLLM的Prefix Caching功能，把对话历史的KV Cache分块存储，在多个GPU节点之间共享。故障发生时，新GPU只需要从共享存储读取已有的KV Cache块，不需要重新计算。这个方案效率最高，但需要推理框架支持vLLM的Prefix Caching。目前vLLM和TGI都支持这个功能。

对于大多数团队来说，方案二"KV Cache无状态化"是最容易实现的，不需要对推理框架做深度改造。只需要在API层把对话历史拼到请求里，然后在模型推理时告诉框架"历史已经在这里了，重新算"。

6. 一万网络GPU高可用方案推荐

方案说了一堆，落到具体配置上，到底怎么选？下面几套方案，覆盖了从入门到高阶的全场景。

方案一：单机多卡HA方案（适合预算有限的小团队）

推荐配置：RTX 3090 × 4卡或T4 × 4卡。RTX 3090单卡¥1750/月，T4单卡¥900/月。4卡中预留1卡作为冗余，实际使用3卡。用脚本监控GPU状态，发现故障后自动把模型迁移到预留卡上。这个方案适合13B以下的小模型，或者对RTO不敏感（5分钟以内都能接受）的场景。一万网络提供免费系统盘快照，做迁移时可以直接恢复系统环境，不用重新配置。

方案二：多机热备HA方案（适合生产环境的中型团队）

推荐配置：A100 40G × 8卡整机两台，一台主力，一台热备。A100 40G单卡¥2800/月，两台整机合计约¥4.5万/月。两台机器部署在同一机房，通过BGP内网互联，延迟在1ms以内。主力机跑推理服务，热备机预加载模型，通过Prometheus+GPU Exporter监控GPU状态。故障时自动切换，RTO在30秒以内。一万网络提供7×24工单5分钟响应，硬件故障自动迁移，你只需要关注业务层的高可用就行了。

方案三：跨地域双活HA方案（适合对可用性要求极高的大团队）

推荐配置：H100 8卡整机，华南+华东各部署一台。H100整机月租¥8-12万，两台合计¥16-24万/月。两台机器通过CN2 GIA回国线路互联，延迟在20ms以内。前端部署智能DNS或全局负载均衡，根据用户地域就近分配流量。一台机器故障时，DNS自动把流量切换到另一台。一万网络华南和华东都有机房，支持跨地域部署，BGP多线+CN2 GIA回国保证网络质量。

10. 监控告警体系：GPU还没挂，你就要知道它要挂了

高可用方案的核心不是"坏了再修"，而是"快坏的时候提前修"。这就需要一套完善的监控告警体系。

GPU硬件监控指标。需要采集的指标包括：GPU温度（正常范围30-85°C）、显存ECC错误计数（单比特错误正常、双比特错误需要告警）、GPU功耗（正常范围是TDP的20-100%）、PCIe带宽利用率（正常范围0-100%）、GPU时钟频率（降频超过20%需要告警）、显存使用率（超过90%需要告警）。这些指标用NVIDIA的DCGM（Data Center GPU Manager）采集最方便，它支持Prometheus exporter格式，可以直接接入Grafana。

推理服务业务指标。除了硬件指标，还要监控推理服务的业务指标。推理请求成功率（低于99%需要告警）、推理延迟P99（超过基线2倍需要告警）、每秒请求数QPS（突降超过50%需要告警）、模型加载时间（超过5分钟需要告警）、模型推理输出质量（出现NaN或空输出需要告警）。这些指标需要在推理服务框架层面做埋点，vLLM和Triton Inference Server都支持自定义metrics。

告警分级和处理策略。建议把告警分为三级。P0级告警：服务完全不可用，需要立即响应，目标RTO 5分钟以内。P1级告警：服务质量下降，但服务仍可用，需要在30分钟内处理。P2级告警：硬件指标异常，但服务未受影响，需要在24小时内处理。P0级告警需要自动触发GPU故障迁移，P1和P2级告警可以先通知运维人员，由人工判断是否需要迁移。

一万网络提供7×24小时工单5分钟响应服务，如果用户没有自己的运维团队，一万网络的工程师可以帮忙处理P0和P1级告警，确保GPU故障时能快速响应和迁移。

11. 低成本高可用方案：预算有限也能做HA

很多人觉得高可用是"大厂专属"，小团队做不起。这话对，也不对。高可用确实需要额外的GPU资源，但预算有限也有预算有限的做法。

方案一：利用MIG做GPU分区。NVIDIA A100和H100支持MIG（Multi-Instance GPU）功能，可以把一张物理GPU切分成多个逻辑GPU实例。比如，一张A100 80G可以切分成7个1g.10gb实例，每个实例10GB显存。这样，一张卡可以同时跑7个小模型的推理服务，每个实例相互隔离。如果某个实例挂了，其他实例不受影响。MIG方案不需要额外硬件，只需要在驱动层面配置即可，成本几乎为零。但MIG不适用于大模型推理，因为每个实例的显存太小了。

方案二：使用便宜的GPU做热备。如果主力机用的是H100或A100，热备机没必要用同样配置的GPU。可以用RTX 3090或T4做热备，虽然推理性能差一些，但至少能保底。故障发生时，先用低配GPU顶上，保证服务不中断，同时启动新GPU的采购或部署流程。一万网络提供RTX 3090（¥1750/月）和T4（¥900/月）的低价方案，特别适合做热备机。热备机平时还可以用来做模型评估或数据处理，不浪费资源。

方案三：共享热备池。如果团队有多个推理服务，每个服务不需要单独配一台热备机。可以搭建一个共享热备池，池子里放2-3台GPU服务器，所有推理服务共享这个热备池。哪个服务出故障了，就从池子里分配一台机器顶上。这种方法资源利用率高，但调度逻辑复杂，需要有统一的资源调度平台。一万网络的GPU托管方案支持多用户共享热备池，用户不需要自己管理调度平台，由一万网络统一调度。

12. 容灾演练：不演练的HA方案等于白做

这个点必须单独拎出来说。所有高可用方案，如果不经过演练，最后大概率是"纸面HA"。我见过太多团队，方案写得天花乱坠，真出了问题全抓瞎。

演练频率。建议每个月做一次小规模演练，每季度做一次全量演练。小规模演练只模拟单卡故障，全量演练模拟整机故障甚至机房故障。演练时间选择在业务低峰期，比如凌晨2点到4点。

演练内容。第一，模拟GPU故障：拔掉一张GPU卡，看自动迁移是否触发，流量是否正常切换。第二，模拟推理服务进程崩溃：杀推理服务进程，看进程是否自动重启，或者流量是否自动切到备用节点。第三，模拟网络中断：拔掉网线，看网络切换是否正常，心跳检测是否准确。第四，模拟全量故障，关闭主力机，看备用机能否完全接管所有流量。

演练结果评估。每次演练后要出报告，记录RTO、RPO、故障检测时间、迁移完成时间、流量切换时间。如果RTO超过目标值，说明方案有问题，需要优化。连续三次演练RTO都达标，才算方案通过。

一万网络在提供GPU服务器租赁服务的同时，也为用户提供容灾演练方案设计支持。工程师可以根据用户的实际业务场景，设计定制化的演练方案，并协助执行演练。

7. 避坑指南：这些坑不避开，HA方案等于白搭

坑1：只关注GPU故障，忽略网络故障

很多人做高可用只想着GPU挂了怎么办，但忘记了一个更常见的问题：网络挂了。GPU服务器本身没问题，但交换机端口坏了、光纤被挖断了、DNS解析出错了，服务照样不可用。做HA方案时，一定要考虑网络冗余。建议至少双网卡绑定，两个不同的上联交换机，两个不同的运营商线路。一万网络采用BGP多线接入，单条线路故障时自动切换，网络层面已经有了冗余。

坑2：故障检测脚本写得太糙

常见的糙写法：每5分钟跑一次nvidia-smi，如果返回空就认为GPU挂了。问题是，nvidia-smi有时候会卡住，但GPU还能正常工作。更好的做法是：用NVML API读取GPU的详细健康状态，同时结合推理任务级的心跳检测。如果nvidia-smi返回正常但推理请求超时，说明驱动或推理框架有问题，同样需要触发迁移。

坑3：迁移时没考虑显存碎片

GPU长期运行推理服务，显存中会产生大量碎片。新加载的模型需要连续显存空间，如果碎片太多，可能加载失败。解决方法是定期做显存整理，或者在迁移脚本中先杀掉所有进程、释放显存，再加载模型。

坑4：热备机没有做模型保活

热备机预加载了模型，但如果长时间不处理推理请求，模型在显存中可能因为ECC内存刷新或其他原因出现数据损坏。建议定期（比如每5分钟）向热备机发送推理请求，确认模型能正常返回结果。如果发现热备机上的模型异常，需要重新加载。

坑5：没有做故障演练

HA方案搭好了，从来没用过，那是最大的坑。不通电演练的HA方案，基本等于没有HA。建议每个月做一次GPU故障演练，手动拔掉一块GPU（或者模拟GPU故障），看自动迁移能不能正常工作。一万网络的硬件故障10分钟自动迁移承诺，也是经过大量实际演练验证的。

8. 常见问题FAQ

Q1：单机多卡部署，一张卡挂了，其他卡上的推理服务会受影响吗？

这取决于你的部署方式。如果用的是NVIDIA的MPS（Multi-Process Service），一张卡挂了确实可能影响其他卡上的进程，因为MPS Server是共享的。如果用的是独立进程模式，每张卡上的推理服务是独立的，一张卡挂了不会直接影响其他卡。但要注意，如果故障卡上的推理请求被路由到其他卡上，可能导致其他卡负载突增，间接影响服务质量。建议在故障检测和迁移逻辑中，同时做好流控和限速。

Q2：GPU故障自动迁移过程中，正在处理的推理请求会丢失吗？

大概率会丢失，除非你做了请求级的容错。正在处理的推理请求，其KV Cache在故障卡的显存中，故障发生后这些数据就丢了。想做到请求不丢失，需要客户端做请求重试机制。比如，客户端发送请求后设置超时时间，如果超时未收到响应，自动重试。重试时，新请求会被路由到正常的GPU节点上处理。建议在API网关层做请求重试，客户端不需要改造。

Q3：跨地域双活方案中，模型权重怎么同步？

模型权重同步有两种方式。第一种是"共享存储"，两个地域的GPU服务器都挂载同一个NAS或分布式文件系统，模型权重放在共享存储上。这种方式实现简单，但对网络带宽要求高，两个地域之间的延迟不能太大。第二种是"本地存储+定时同步"，每个地域的GPU服务器本地存储模型权重变更，通过rsync或分布式存储工具定时同步。这种方式对网络要求低，但存在同步延迟，可能出现某个地域的模型不是最新版本的情况。一万网络推荐共享存储方案，节点间通过CN2 GIA回国线路互联，延迟低、带宽大，模型同步效率高。

Q4：H100和A100在故障率上有区别吗？

H100采用了新的HBM3e显存技术，显存带宽比A100的HBM2e提升了近2倍。但新技术往往伴随着更高的早期故障率。从行业反馈来看，H100的早期批次确实出现了比A100更高的显存故障率，尤其是在高负载运行下。不过，随着NVIDIA对HBM3e工艺的成熟，故障率正在逐步下降。如果你对稳定性要求极高，建议选择经过长期验证的A100，或者选用H100且做好N+1冗余。一万网络提供H100和A100两种选择，工程师会根据你的业务场景推荐最合适的方案。

Q5：GPU故障自动迁移，会不会有"脑裂"问题？

"脑裂"是指两个节点都认为对方挂了，都开始接管服务，导致服务冲突。在GPU故障迁移中，脑裂是比较罕见但确实可能发生的问题。比如，主备节点之间的心跳网络中断，备机认为主机挂了，开始接管服务，但主机实际上还在正常运行。结果就是两个节点同时处理请求，数据一致性被破坏。避免脑裂的方法：一是采用"法定人数"机制，需要多数节点确认故障才触发迁移；二是用独立的故障检测通道，比如心跳网络和业务网络分开，避免单点故障导致误判。

Q6：一个70B模型做高可用，最少需要多少GPU资源？

70B模型做4位量化后大约需要35-40GB显存，一张A100 80G可以跑。如果要做到高可用，最少需要2张A100 80G，一张跑主力，一张跑热备。但这是"最小配置"，实际运行中还需要考虑并发数。如果QPS要求高，可能需要多张卡做负载均衡，每张卡是一个推理实例。建议的最小配置是：A100 80G×4卡，其中2卡跑主力推理，1卡做热备，1卡做冗余。这样可以在主力卡故障时，热备卡接管，冗余卡再加载新的热备。

Q7：一万网络的高可用方案和其他云厂商比有什么优势？

这个问题问得好。一万网络的优势有几个方面。第一，物理服务器级别的隔离，不像云服务器那样存在"吵闹邻居"问题，GPU性能是独占的。第二，工程师1对1技术支持，帮你部署CUDA、cuDNN、TensorRT、PyTorch、TensorFlow等推理环境，不像云厂商那样只提供标准镜像。第三，BGP多线+CN2 GIA回国线路，网络质量比很多云厂商的共享带宽好。第四，深耕19年的IDC资质，机房运维经验丰富，硬件故障10分钟自动迁移。第五，免费系统盘快照，做迁移时可以直接恢复系统环境。总的来看，一万网络更适合对GPU性能、网络质量和运维支持有高要求的用户。

Q8：GPU故障自动迁移能做到用户无感知吗？

理论上是可能的，但实际操作中很难做到"完全无感知"。如果做到了极致HA（跨地域双活+RTO<10秒），大多数用户不会注意到服务中断。但对于一些对延迟敏感的场景，比如实时语音对话、视频生成等，哪怕几秒钟的中断也能被用户感知到。建议的做法是：在客户端加入"断线重连"和"请求重试"逻辑，配合服务端的自动迁移，让用户感知到的中断时间尽量短。如果用户问"刚才怎么卡了一下"，说明你的RTO还需要优化。

Q9：GPU故障自动迁移时，如何保证推理请求不因为负载突增而超时？

这是个很难解决的问题。故障迁移后，原来由故障卡处理的请求全部转移到正常卡上，正常卡的负载会突然增加。如果原来的负载是80%，迁移后负载可能飙到160%，导致所有请求超时。解决办法是"限流+降级"：故障迁移的同时，在API网关层面启动限流，只允许原来60%的请求通过，确保正常卡不会过载。同时，对非关键请求做降级处理，比如返回缓存结果或简化回答。虽然这会导致部分请求被拒绝，但总比全部请求超时强。一万网络推荐在API网关层集成限流功能，配合GPU故障迁移自动触发限流策略。

Q10：单机多卡场景下，一张卡ECC错误累积，但还没完全挂，怎么处理？

ECC错误累积是GPU故障的早期信号，等它完全挂掉再处理就晚了。建议的做法是：监控ECC错误计数，如果单比特错误在24小时内超过1000次，或者出现双比特错误，就主动触发"预防性迁移"。把模型从有ECC风险的卡上迁移到正常卡上，然后把有风险的卡下线做检修。这种预防性迁移可以避免GPU突然故障导致的服务中断。一万网络在GPU监控中内置了ECC错误告警功能，当ECC错误超过阈值时自动通知用户，并建议进行预防性迁移。

Q11：跨地域双活方案中，两个地域的GPU服务器配置需要完全一样吗？

理论上不需要完全一样，但建议尽量一致。如果两个地域的GPU配置不同，比如华南用的是H100，华东用的是A100，那么两个地域的推理性能就不一样，用户在不同地域的体验会有差异。如果预算允许，建议两个地域用同样的GPU配置，这样流量调度时不需要考虑"哪个地域的GPU更强"的问题。如果预算有限，可以用低配GPU做备地域，但需要在DNS调度时把备地域的权重设低，正常情况下只承载较少的流量。一万网络在华南和华东都有GPU机房，支持同配置部署，也支持混配置部署，用户可以根据预算灵活选择。

Q12：GPU故障迁移后，之前推理产生的日志和监控数据会丢失吗？

GPU故障迁移本身不会导致日志丢失，但前提是日志是实时写到外部存储的。如果日志只写在本地磁盘，GPU故障后日志可能无法读取。建议的做法是：推理服务的日志通过fluentd或logstash实时发送到集中式日志平台，比如ELK或Loki。监控数据通过Prometheus远程写入到VictoriaMetrics或Thanos。这样不管GPU怎么故障，日志和监控数据都不会丢。一万网络在GPU服务器上预置了日志采集agent，支持将日志实时发送到用户指定的日志平台，不需要用户自己配置。

9. 总结

GPU故障不是小概率事件，大模型推理服务的高可用也不是可有可无的锦上添花。一套好的GPU故障自动迁移方案，核心就是三件事：检测要快、迁移要稳、切换要准。检测快，靠的是多层次的健康监控，不能只看nvidia-smi；迁移稳，靠的是模型状态外置和冗余资源；切换准，靠的是自动化的故障判定和流量路由。这三件事做好，RTO控制在30秒以内，用户基本感受不到服务中断。

一万网络深耕IDC行业19年，提供从RTX 3090、T4、A100到H100的全系列GPU服务器租用和托管服务，支持硬件故障10分钟自动迁移、7×24小时工单5分钟响应、免费系统盘快照、工程师1对1部署支持。如果你正在搭建大模型推理服务的高可用架构，或者对现有的GPU部署方案有疑问，欢迎咨询一万网络，工程师会根据你的业务场景和预算，推荐最合适的HA方案。

数据来源：本文数据综合自Google数据中心GPU故障率研究论文（Google's Datacenter GPU Failure Analysis）、NVIDIA NVML官方文档、NVIDIA H100技术白皮书、vLLM Prefix Caching技术文档、Kubernetes GPU Operator运维手册、以及多家互联网大厂推理服务运维团队的公开技术分享。价格信息来源于一万网络官网及行业公开报价，实际价格以咨询为准。