ShuihuaLab

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

补在 部署启动专题 下的历史案例。2024 年 11 月，enardo7 在 Windows 11 Pro 笔记本的 Docker 环境加载 Mistral-Nemo-12B-Instruct，报 No available memory for the cache blocks。 原帖写的“4090”只有 16GB 显存；监控输出为 16022 / 16376 MiB。不能直接对应桌面 24GB 卡。作者已经试过把 gpu_memory_utilization 调到 1.0，仍然来求助。 后续 neal.vaidya 回复称，当时 NIM 在 4090 上只支持 FP16，该模型仅加载权重就需要约 25GB 以上显存，并建议寻找更小模型。这只是当时 NIM 的支持条件，不能推广到今天的所有框架和格式。 错误提示让人调高利用率，但参数不能凭空增加显存；设备容量与运行格式还得一起看。 来源：NVIDIA 论坛原帖与回复 · 2024-11-10—11，历史资料。

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 组合。若要继续做成部署建议，应补量化配置、运行后端及对应版本的官方支持说明，再做同条件验证。 来源整理：fenghuohuo2001 · 2025-11-19 · 原帖

这条 2025 年的 vLLM 求助，把部署配置和请求体放在了一起。具体细节比“输出不完整”这句描述更值得看。 shaojun0 的环境是单张 4090、vLLM 0.8.0、PyTorch 2.6.0、transformers 4.51.3，模型路径指向 Seed-X-PPO-7B。启动配置中，作者把 max_model_len 设为 4096；请求 JSON 里写的是 "max_token": 4096。注意，这里是在摘录原请求，不是推荐请求写法。 楼中的 RunLLM 回复把字段拼写和上下文预算列为解释，页面将它标为解决方案，原作者随后致谢。可是，在已读记录里，没有看到作者修改后的完整请求及对应输出，也没有重跑前后的日志。 所以，这一案可以保留的结论是：原请求确实出现了这个字段，页面也确实接受了一条回答；不能仅凭机器人回答，就认定已经验证了截断的唯一根因。 如果要把它整理成今天可直接照做的修复教程，下一步应对照当时 API 定义，并补修改前后的对照响应。当前先作为“请求字段与服务配置要一起审查”的历史案例保存。 来源整理：shaojun0 · 2025-07-30 · 原帖

先说这条记录的适用范围：它来自 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 更新 · 原帖