NVIDIA L20 部署 Qwen3.6-27B-FP8 全链路故障复盘手册

整体状态：未闭环
截至本手册编写，模型未能成功部署运行。

---

环境概览

• GPU : NVIDIA L20 (46GB) x1

• 最终驱动 : NVIDIA 580.142

• Docker 版本 : 20.10.9

• 目标模型 : Qwen3.6-27B-FP8 (ModelScope 下载)

• 目标框架 : vLLM 0.19.x (Docker 部署)

---

阶段一：模型下载与路径映射

问题 1.1：魔搭下载路径与 vLLM 期望不匹配

现象 ：启动时报 HFValidationError: Repo id must be in the form 'namespace/repo_name' 或 OSError: Can't load the configuration。

根因 ：

• 魔搭默认下载路径包含 snapshots 哈希目录，-v 挂载后深度不对。

• 宿主机存在软链接 Qwen3.6-27B-FP8 -> Qwen3___6-27B-FP8，容器内无法正确解析。

• vLLM 将本地绝对路径误判为 HuggingFace 仓库 ID。

解决方案 ：

• 使用 tree 命令定位到包含 config.json 的物理路径 。

• 弃用软链接，直接指向 /root/.cache/modelscope/Qwen/Qwen3___6-27B-FP8。

• 设置 HF_HUB_OFFLINE=1 TRANSFORMERS_OFFLINE=1 强制离线，禁止网络请求。

• 放弃魔搭集成 ：移除 VLLM_USE_MODELSCOPE=True，直接用本地绝对路径。

状态 ：✅ 已解决

问题 1.2：魔搭缓存目录结构不标准

现象 ：设置了 VLLM_USE_MODELSCOPE=True 后报 Cannot find the requested files in the cached path。

根因 ：魔搭期望 hub/models--Qwen--Qwen3.6-27B-FP8/snapshots/main/ 标准缓存结构。

解决方案尝试 ：手动创建上述目录结构并建立软链接。最终因为后续 CUDA 问题放弃此路径，直接用本地路径 + 离线模式。

状态 ：✅ 已绕过，未继续

---

阶段二：Docker 显卡透传

问题 2.1：容器内找不到 CUDA 运行时

现象 ：报 libcuda.so.1: cannot open shared object file、RuntimeError: Failed to infer device type。

根因 ：

• Docker 未配置 nvidia-container-toolkit。

• docker-compose.yaml 的 deploy.resources 在旧版 compose 下被静默忽略。

诊断手段 ：

bash

docker run --rm --gpus all nvidia/cuda:12.1.0-base-ubuntu22.04 nvidia-smi

这条命令能跑通，说明容器运行时正常。

状态 ：✅ 已解决

问题 2.2：Docker Compose 版本语法问题

根因 ：version: '3.8' 的 deploy 块在 docker-compose (v1) 下不被支持，runtime: nvidia 在 3.x 文件中被忽略。

解决方案 ：最终放弃 compose，改用原生 docker run --gpus '"device=0"' --runtime=nvidia 命令行。

状态 ：✅ 已解决

问题 2.3：Docker 重启动后丢失 NVIDIA 运行时

现象 ：驱动升级或 Docker 重启后报 could not select device driver "" with capabilities: [[gpu]]。

解决方案 ：重新安装 nvidia-container-toolkit 并重启 Docker 服务。

状态 ：✅ 已解决

---

阶段三：驱动与 APT 依赖地狱

问题 3.1：nvidia-smi 失效 / 内核模块冲突

现象 ：系统自动更新内核后 nvidia-smi 报无法与驱动通信。

根因 ：旧驱动模块未对新内核编译。

状态 ：✅ 已解决（通过重新安装驱动）

问题 3.2：APT 僵尸包死锁

现象 ：apt install nvidia-driver-550 报错：

text

E: The package nvidia-driver-local-repo-ubuntu2404-570.211.01 needs to be reinstalled

根因 ：之前安装 570 驱动时遗留的 *-local-repo-* 包损坏。

解决方案 ：

bash

sudo dpkg --purge --force-all nvidia-driver-local-repo-ubuntu2404-570.211.01
sudo rm -f /etc/apt/sources.list.d/nvidia-driver-local-*.list
sudo apt --fix-broken install

状态 ：✅ 已解决

问题 3.3：指定 550 驱动却被安装 580

根因 ：Ubuntu 官方仓库将 nvidia-driver-550 元包的依赖重定向到了 580 系列（因新内核兼容性要求）。

尝试 ：手动指定所有 550 核心包版本号、apt-mark hold 锁定。最终放弃，接受 580 驱动。

状态 ：✅ 已接受 580 驱动

问题 3.4：文件覆盖冲突

现象 ：libnvidia-gl 与 libnvidia-egl-xcb1 抢占同一个 .json 配置文件。

解决方案 ：dpkg -i --force-overwrite 强制解包。

状态 ：✅ 已解决

---

阶段四：vLLM 核心故障——持久化 cudaMemGetInfo 错误 【未闭环】

这是整个部署中最顽固、耗时最长 的问题，至今未解决 。

现象

无论在哪个 vLLM 版本、任何 Docker 参数组合下，启动日志都在 EngineCore 初始化时崩溃：

text

torch.AcceleratorError: CUDA error: operation not supported
...
return torch.cuda.cudart().cudaMemGetInfo(device)

排查链路及所有失败尝试

序号	尝试方案	结果
1	升级驱动到 550	被仓库重定向到 580
2	接受 580 驱动 + v0.19.0	cudaMemGetInfo 报错
3	挂载宿主机 /usr/lib/x86_64-linux-gnu 到容器	容器内系统库被污染，as/gcc 找不到 libopcodes
4	精确挂载 libcuda.so.1 等关键文件	报错依旧
5	切换到 --runtime=nvidia	报错依旧；且出现新错误 Error 803: unsupported display driver / cuda driver combination
6	添加 NVIDIA_DISABLE_REQUIRE=1	Error 803 消失，但 cudaMemGetInfo 照旧
7	v0.16.0 镜像测试	CUDA 调用成功！ 但因 transformers 版本太旧，不识别 qwen3_5 架构
8	v0.19.1 + NVIDIA_DISABLE_REQUIRE=1 + --enforce-eager	架构识别通过，EngineCore 初始化再次爆 cudaMemGetInfo
9	所有本地镜像 (v0.6.x ~ v0.20.0) 全部测试	标准镜像均失败

核心矛盾定位

• v0.16.0 镜像 ：内置 CUDA 12.1 + PyTorch 2.x，可以成功调用cudaMemGetInfo，但不支持 Qwen3.6 架构。

• v0.19.x 镜像 ：内置 CUDA 13.x + PyTorch 2.5+，支持 Qwen3.6 架构，但无法通过cudaMemGetInfo 调用。

• 结论 ：580 驱动内核模块与 vLLM 0.19.x 镜像内部 CUDA 13.x 用户态库存在特定兼容性缺陷，而非驱动版本不够高。

最终推测方案（未验证）【未闭环】

用 PyTorch 官方基础镜像（pytorch/pytorch:2.5.1-cuda12.4-cudnn9-runtime）自建 vLLM 环境，绕过预构建 vLLM 镜像的库冲突，该方案尚未执行验证 。

---

阶段五：vLLM V1 引擎架构陷阱

问题描述

驱动通了、路径对了，v0.20.0 启动仍报 cudaMemGetInfo 错误。

根因分析

• vLLM v0.20.0 默认开启 V1 引擎 ，将 API 服务与推理核心拆分为多进程。

• Docker 默认禁止跨进程显存读取，子进程在 fork 模式下无法访问 CUDA 上下文。

• 新版删除了 VLLM_USE_V1=0 降级开关。

解决方案

bash

--disable-frontend-multiprocessing

强行将所有逻辑压在单进程模式，规避跨进程显存读取限制。

状态 ：✅ 方案已明确，但因阶段四的 CUDA 问题，未能在 v0.20.0 上完整验证

---

阶段六：网络模式与 VPN 冲突

问题描述

启动容器后宿主机 VPN 掉线，192.168.x.x 网段冲突。

根因

Docker Compose 默认创建的自定义网桥随机分配子网，容易撞上宿主机内网/VPN 网段。

解决方案

• 明确指定 network_mode: "bridge" 使用默认 docker0 网桥。

• 或在全局配置中锁定容器子网为 172.25.0.0/16。

状态 ：✅ 已解决

---

📝 经验总结：大模型部署生存守则

1. 别太相信 latest 镜像 ：前沿版本意味着你是官方 Bug 的"肉盾"。关键时刻退回 LTS 版本保命。

2. 先跑通物理层再跑逻辑层 ：nvidia-smi 不亮，不要去调任何模型参数。

3. 参数越少越稳 ：当 docker-compose 报错诡异时，回归最原始的 docker run 命令。

4. 重视 IPC 权限 ：大模型多进程推理必须加 --ipc=host 和 --shm-size=16g。

5. 驱动不是越新越好 ：CUDA 用户态库与内核模块的精确匹配，远比驱动版本号重要。

6. 软链接坑爷 ：Docker 挂载只认物理路径，别用软链接。

7. APT 僵尸包 ：卸载 NVIDIA 全家桶时务必搜干净 *-local-repo-* 残留包。

8. Compose 版本陷阱 ：GPU 透传在 Compose 3.x 需要 V2 才支持 deploy，否则静默忽略。

---

🔴 最终状态与未闭环事项

整体结论 ：本次部署未成功 ，Qwen3.6-27B-FP8 未能在 NVIDIA L20 上通过 vLLM Docker 镜像运行。

已解决问题 ：

• 模型路径与映射

• Docker 显卡透传

• APT 驱动依赖与冲突

• 网络与 VPN 问题

未闭环问题 ：

1. 深度学习框架与驱动兼容性缺陷

• v0.19.x 镜像的 CUDA 13.x 用户态库与 580 驱动内核模块不兼容，导致 cudaMemGetInfo 调用失败。

• 未找到可用的预构建镜像同时满足 Qwen3.6 架构支持和 CUDA 调用成功。

  2. 推测方案未验证

• 使用 pytorch/pytorch:2.5.1-cuda12.4-cudnn9-runtime 基础镜像自建 vLLM 环境的方案尚未执行，该方案有望绕过镜像库冲突。

下一步建议 ：

• 验证上述推测方案。

• 若自建环境仍失败，考虑回退至 Qwen3.5-27B 模型或使用非 vLLM 框架（如 TensorRT-LLM、LMDeploy）。

• 等待 vLLM 官方发布针对 580 驱动优化的新镜像。