前言

最近在内部平台部署了Qwen3-32B大模型，使用4张NVIDIA A100 80GB显卡，采用vLLM框架提供服务。模型跑起来看似正常，但每运行2-3天就会崩溃一次，导致线上服务中断。

起初以为是显存泄漏或并发问题，但经过一番排查后，真相令人意外——并非软件问题，而是一块GPU正在悄悄“死去”。

本文将完整记录这次排障过程，希望能为遇到类似问题的同行提供一些参考。

硬件环境

• GPU：4 × NVIDIA A100 80GB
• 模型：Qwen3-32B (FP16全精度)
• 框架：vLLM 0.17.0
• 并发：10
• 最大上下文：30K tokens

按理说，4张A100跑32B模型绰绰有余，为什么还会崩呢？

一、症状：能跑，但跑不久

服务启动后一切正常，显存占用约0.85（即每卡约68GB），推理速度也符合预期。但运行2-3天后，服务突然 hang 住或直接退出，重启后又恢复正常。

这种“周期性崩溃”很隐蔽——快速验证时看不出问题，只有在长期运行下才会暴露。

二、排查：dmesg 揭露真相

第一步：看系统内核日志

排查这类问题的第一利器就是 dmesg：

dmesg | tail -50

输出中出现了大量重复的错误：

NVRM: Xid (PCI:0000:e5:00): 63, Row Remapper: New row marked for remapping, reset gpu to activate.
NVRM: Xid (PCI:0000:e5:00): 94, pid=2264756, name=VLLM:: Worker, Contained: SM (0x1)

第二步：理解 Xid 错误码

NVIDIA 驱动的 Xid 错误码含义：

Xid	含义	严重程度
63	显存行损坏，被重新映射（Row Remapper）	⚠️ 硬件级警告
94	GPU 流多处理器（SM）执行非法指令	🔴 严重硬件错误

• Xid 63 是根源：GPU 内部的 HBM2e 显存出现了“坏道”，驱动自动用备用行替换。这是一种自愈机制，所以模型短时间内仍能运行。
• Xid 94 是结果：随着备用行耗尽，或某次恰好分配到未标记的坏行，GPU 抛出致命错误，导致 vLLM Worker 进程崩溃。

第三步：定位故障卡

通过 PCIe 地址 0000:e5:00 定位到具体的GPU卡：

nvidia-smi --query-gpu=index,bus_id --format=csv

输出确认 e5:00 对应其中一张A100。只有这张卡报错，其他三张完全正常。

结论：不是4张卡都坏了，而是其中一张存在物理缺陷——属于间歇性硬件故障。

三、为什么能跑两三天才崩？

这是最容易产生误判的地方。很多人会认为“能跑起来=硬件没问题”，但实际上：

• GPU 的 Row Remapper 机制会在坏行被访问时动态替换，保证当前运行不中断。
• 随着时间推移，累积的坏行越来越多，备用行耗尽后，下一个错误就会直接炸掉进程。
• 重启后，GPU 会重新进行行映射，又进入下一个“蜜月期”。

类比：就像一块有坏扇区的硬盘，平时能用，但拷大文件到坏道上就报错。

四、解决方案

短期方案：隔离坏卡，2卡运行

找到故障卡的索引（假设坏卡是GPU 2或3），将其排除：

# 假设坏卡是索引3，保留0和1
export CUDA_VISIBLE_DEVICES=0,1

然后用2卡启动vLLM服务：

vllm serve /data/models/Qwen3-32B \
  --tensor-parallel-size 2 \
  --max-model-len 32768 \
  --max-num-seqs 10 \
  --gpu-memory-utilization 0.85 \
  --enforce-eager

2张A100跑Qwen3-32B完全够用：模型权重占64GB，两张卡总显存160GB，剩余约96GB用于KV Cache和并发缓冲。实测10个并发、30K上下文下稳定运行，余量充足。

---

为什么不用3卡？

主要有三个原因：

1. 张量并行效率问题：3卡不是2的幂次，通信模式不如2卡或4卡高效，跨卡同步开销更大。
2. 显存浪费：32B模型用3卡，每卡显存占用不均，有一张卡会明显空闲。
3. 生产环境惯例：主流推理框架（vLLM、TGI）和模型并行策略都优先支持偶数卡（2/4/8），3卡需要额外配置且未经充分测试。

所以，要么2卡，要么4卡——既然4卡里坏了一张，降到2卡是最稳妥的选择。

---

性能验证

配置	总显存	模型占用	KV Cache余量	推荐度
2×A100 80GB	160GB	64GB	~50GB	✅ 推荐
3×A100 80GB	240GB	64GB	~140GB	⚠️ 效率低，不推荐
4×A100 80GB	320GB	64GB	~200GB	✅ 原方案（坏卡除外）

长期方案：物理更换故障卡

• 联系运维/供应商，记录故障卡序列号：nvidia-smi -a | grep -E "Product Name|Serial Number"
• 冷重启整机（彻底断电），让Row Remapper重新映射——若仍报错，必须换卡。
• 若在保，走RMA流程；若不在保，更换该卡。

五、踩坑总结与反思

1. 不要被“能跑”迷惑：硬件故障往往是间歇性的，跑得起来不代表没问题。
2. dmesg 是硬件级排障的第一道防线：应用程序日志看不到的东西，内核日志可能早就记下了。
3. Xid 63 是黄牌，Xid 94 是红牌：看到63就要警惕，不要等到94才处理。
4. 大模型长文本场景会放大硬件问题：30K上下文对显存带宽和稳定性要求极高，平时不报错的瑕疵在这个场景下会暴露。

附录：常用诊断命令速查

# 查看最近的内核错误
dmesg | grep -E "Xid|NVRM|Out of memory" | tail -20

# 带时间戳查看
dmesg -T | tail -50

# 查看GPU健康状态
nvidia-smi -a | grep -E "Product Name|Bus Id|Serial Number"

# 定位故障卡索引
nvidia-smi --query-gpu=index,bus_id --format=csv

---

最后想说的话：这次的故障排查过程有些曲折，但最终定位到是硬件问题。希望这篇记录能帮助你少走一些弯路。如果你也遇到类似的“周期性崩溃”，不妨先看看 dmesg——也许答案就在那里。