留一条带后续的旧记录。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 年，历史资料。

先说这条记录的适用范围：它来自 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 当成固定配置；两台机器的拓扑和软件差异还需要继续对照。 来源整理：XiaoDouGeGe · 2025-08-20 起，含 08-27 更新 · 原帖

Qwen3-4B-Instruct-2507 和不带 Instruct-2507 的模型不要当成同一份配置。Qwen 的官方模型卡明确：这个版本只支持非思考模式，不产生思考块，调用时不再需要指定 enable_thinking=False。这是该型号的说明，不推广到所有 Qwen3 模型。 同一模型卡还说明，transformers<4.51.0 会遇到 KeyError: 'qwen3'。如果导入阶段就报这个错误，可以先核对当前 Python 环境里实际加载的库，而不是直接判断显卡不够用。 下面两条只查看当前环境，不安装或升级包： python -c 'import sys; print(sys.executable)' python -c 'import transformers; print(transformers.__version__)' 若使用容器运行，要在实际服务容器内查；宿主机的版本不能代表容器内版本。接着按三列留一份记录： 检查项 实际值 判断依据 模型名与revision 自行填写 是否准确对应这份模型卡 Python路径与Transformers版本 自行填写 是否查到了服务真正使用的环境 后端与启动参数 自行填写 是否和当前后端文档匹配 短请求结果或完整报错 自行填写 区分加载失败与推理失败 填完后，保留一份你自己的环境／错误记录：每项写实际值或“待补”，并标明从哪里查到。命令无法执行时，留下原错误，不猜版本；还没启动服务就写“未启动”，不要把查看环境失败当成模型推理失败。暂时没有运行环境，也可以先写计划与缺口，无需为了填表先跑模型。 带上这份记录，再补一句任务目标和希望获得的帮助，即可到环境与 GPU 排错发起求助。发布前移除凭据、个人路径和客户材料；这份记录用于说明问题，不代表已诊断故障或有人承诺答复。 模型卡给出的原生上下文长度是 262,144，并建议遇到 OOM 时考虑缩短上下文。这个长度不是单卡 4090 的运行承诺。做首次验证时，编辑建议先保留一条短请求及其成功/失败结果，再扩展到实际任务；表内没有预填性能或显存数字。 来源：Qwen 官方 Qwen3-4B-Instruct-2507 模型卡，版本名含2507；2026-10-27核查当前页面，页面本次未确认首次发布日。资料超过一年，兼容性描述归属该模型卡；当前具体环境仍需核对。页面标注 Apache-2.0；本文仅原创整理和链接，没有转载权重或图表。未在 ShuihuaLab 的 4090 环境实测。 <!-- [content-agent:qwen-4b-instruct-2507-preflight] -->

杨乾基记录了一台双 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；外部故障案例整理。