留一条带后续的旧记录。2021 年 9 月，kjyong2 用 RTX 2080 Ti 做 Ray Tune 训练，约二十轮后 GPU 0、1 报 OOM。终止训练后，作者称设备看起来已空闲，但连 torch.rand(1, 2) 搬到这两张卡也失败；同机 GPU 2、3 仍可运行。
他记录了重启后暂时恢复、继续训练又出现的现象，并附 Ubuntu 18.04.3、驱动 460.27.04 等环境信息。这个对照比单张“显存没占满”的截图更完整：异常持续到了训练结束之后，而且并非四张卡一起失效。
9 月 27 日作者补充，升级到 PyTorch 1.9.1+cu111 后，问题“似乎不再出现”。这里保留他的观察强度：帖子没有给出根因证明，也没有证明升级就是所有同类 OOM 的解决办法。
这条资料适合查询历史现象与后续追踪。现有任务遇到 OOM 时，仍需依据自己的硬件和软件版本定位。
来源：kjyong2 的原帖及 9 月 27 日跟进 · 2021 年，历史资料。
fenghuohuo2001 在 2025 年 11 月报告了一个明确的对照：同一项 Qwen3-VL-4B 的 INT8 量化部署，在 RTX 5090 上报 Int8 not supported for this architecture，他同时说在 RTX 4090 上可以正常运行。推理框架版本是 vLLM 0.11.0，量化使用 llmcompressor。
这份记录的价值，在于它把模型、量化格式、框架版本和两张卡的不同表现放到了同一个场景里。“模型大小差不多，换张卡就应该能跑”没有覆盖这类兼容性条件。
但原帖里的对照，仍是作者报告的结果。已读内容没有展示一套完整的复现环境，也没有看到作者后续提供新版复测。楼中机器人建议改用 FP8，不能因此把它写成已验证解决方案。
我会把这条保留在兼容性历史案例里：用于识别“报错可能与量化执行路径有关”的线索，不用于判定今天 5090 是否支持某种 INT8 组合。若要继续做成部署建议，应补量化配置、运行后端及对应版本的官方支持说明，再做同条件验证。
先说这条记录的适用范围：它来自 2025 年的多卡服务器排错，不能直接套到今天的单卡 4090 实例。
XiaoDouGeGe 最初使用 4 张 L20 跑 Qwen2.5-72B，日志显示 vLLM 0.9.1，驱动 570.172.08，启动配置包含 TP=4 和较长上下文。作者报告进程停在初始化阶段，GPU 利用率很高，但服务没有完成启动。
楼中先有机器人把高利用率解释成正常初始化，作者随后明确补充：日志没有继续，也没有出现服务监听信息。之后他补了 DEBUG 和 NCCL 日志，并链接到相关 issue。单看 GPU 忙碌，不能代表这条记录已经成功提供服务。
8 月 27 日，作者又报告了两个对照：一台混有 L20 和 4090 的服务器需要设置 NCCL_P2P_DISABLE=1 才能继续；把这些卡移到另一台服务器后，不加这项设置也能运行。这里摘录的是作者在特定机器上的观察，不是通用启动命令。
最值得留下的是“换服务器后现象改变”这一过程。现有记录不能证明混合型号必然出错，也不能把禁用 P2P 当成固定配置；两台机器的拓扑和软件差异还需要继续对照。
杨乾基记录了一台双 R9700 机器跑 Radiance TP2 的故障：九天六次 device lost from bus，全部落在同一张物理卡上。另一张卡在约 77 小时的连续记录窗口内没有失联。
最关键的一轮发生在 10 月 26 日晚：两张卡对调槽位，同时交叉供电线。约 13 小时后，原来那张故障卡在新槽位再次失联。卡的身份按 unique_id 追踪，没有把新枚举地址误当成另一张卡。
现场也不只是程序退出：作者报告整卡连同板载 PCIe switch 一起不可访问，AER 计数仍为零；最后采样的结温约 77℃、显存约 78℃。
但“跟着卡走”还不能直接等于卡坏了。换槽和换线发生在同一轮，不能拆成两个独立实验；而且 12V-2x6 转接头当时仍插在卡上，跟卡一起移动，尚未排除。作者还记录了 SMU 接口不匹配，Windows 对照和故障卡单卡运行也仍在待测清单。
这个案例真正留下的悬点是：卡本体、随卡移动的转接头，以及特定软件路径，哪一个能解释这次失联。
来源：杨乾基原帖 · 2026-10-27；外部故障案例整理。
