这篇记录一次 ECS GPU 测试环境里的 vLLM 启动排查。模型目录放在 NAS，共享给 GPU 实例；服务跑在 Docker 容器里。现象是容器已经起来，但 vLLM 长时间没有进入 ready，外层调用一直失败。
这类问题很容易被归到“GPU 不够”或“模型太大”，但我这次按 ECS、NAS、镜像、container runtime 和 vLLM ready 一层层查，最后发现更关键的是启动链路没有拆开验证。
环境
这台机器只是临时测试机，结构如下：
- ECS GPU 实例，宿主机可以正常执行
nvidia-smi。 - Docker 由 systemd 管理。
- NAS 挂载到
/mnt/models。 - 目标模型目录是
/mnt/models/Qwen3-32B。 - vLLM 容器监听
8000端口，提供 OpenAI-compatible API。
启动命令简化后是这样：
docker run -d --name vllm-qwen3 \
--gpus all \
-p 8000:8000 \
-v /mnt/models:/models:ro \
docker.1ms.run/vllm/vllm-openai:latest \
vllm serve /models/Qwen3-32B \
--host 0.0.0.0 \
--port 8000 \
--served-model-name qwen3
容器状态是 running，但下面的检查长时间不稳定：
curl -fsS http://127.0.0.1:8000/health
curl -s http://127.0.0.1:8000/v1/models
我没有直接改 vLLM 参数，而是先从 ECS 节点和容器运行时开始排。
1. ECS 上先确认 GPU 和驱动
第一步看宿主机能不能识别 GPU：
nvidia-smi
lsmod | grep -i nvidia
宿主机正常只能说明驱动层没断。vLLM 运行在容器里，所以还要确认 Docker 能把 GPU 注入进去：
docker run --rm --gpus all \
docker.1ms.run/nvidia/cuda:12.4.1-runtime-ubuntu22.04 \
nvidia-smi
如果这里失败，我会优先查这些方向：
- NVIDIA Container Toolkit 是否安装完整。
- Docker runtime 配置是否被改坏。
- 启动命令有没有带
--gpus all。 - 宿主机驱动和容器 CUDA runtime 是否匹配。
这次容器内可以看到 GPU，所以暂时不往驱动方向深挖。
2. NAS 模型目录要在容器内验证
模型目录放在 NAS 上，ECS 只挂载共享路径。这个结构方便统一模型版本，但不能只在宿主机上看一眼目录。
先看挂载：
mount | grep /mnt/models
df -h /mnt/models
ls -lah /mnt/models/Qwen3-32B
然后用 vLLM 镜像进入容器看同一个目录：
docker run --rm \
-v /mnt/models:/models:ro \
--entrypoint sh \
docker.1ms.run/vllm/vllm-openai:latest \
-lc 'ls -lah /models/Qwen3-32B | head && test -f /models/Qwen3-32B/config.json'
这里要特别注意两类问题：
- 宿主机挂载路径和容器内路径不一致，启动参数还写旧目录。
- NAS 权限对宿主机用户可读，但容器内运行用户读不到。
这次路径和权限都没问题，但 NAS 读取比本地盘慢很多，所以我把缓存目录放到本机 SSD，模型目录继续只读挂载，避免 vLLM 往共享目录写临时文件。
3. 镜像层单独预检
vLLM 镜像里包含 CUDA、Python 依赖和服务入口，镜像层最好单独确认。否则一次 docker run 失败，很难判断是镜像没准备好，还是模型加载卡住。
docker pull docker.1ms.run/vllm/vllm-openai:latest
docker image inspect docker.1ms.run/vllm/vllm-openai:latest --format '{
{.Id}} {
{.Size}}'
docker run --rm --entrypoint python3 docker.1ms.run/vllm/vllm-openai:latest -V
如果多台 ECS GPU 实例一起跑，我会把镜像 ID 记下来，避免某台机器靠旧缓存启动，另一台机器拉到不同环境。测试阶段看起来只是启动慢，到了多节点时就会变成“同一套命令在不同机器上表现不一样”。
4. Docker runtime 和启动参数
接着看 Docker runtime 是否真的把需要的能力交给容器：
docker info | grep -i runtime
docker inspect vllm-qwen3 --format '{
{json .HostConfig.DeviceRequests}}'
docker inspect vllm-qwen3 --format '{
{json .Mounts}}'
这几条能快速确认两件事：GPU 设备请求有没有带进去，NAS 挂载是不是只读映射到了预期路径。
如果在 Kubernetes 或 containerd 环境里，同样思路要换成节点事件、runtimeClass、device plugin 和 Pod 挂载检查。核心不是命令形式，而是确认 GPU、模型目录和镜像环境分别到位。
5. vLLM ready 要给冷启动时间
最后回到 vLLM 本身。容器 running 只能说明进程还在，不能说明模型已经可以对外服务。
我看日志：
docker logs -f vllm-qwen3
再分阶段看接口：
curl -fsS http://127.0.0.1:8000/health
curl -s http://127.0.0.1:8000/v1/models
这次日志没有直接报错，而是模型加载和初始化耗时比较长。外层健康检查的等待时间太短，导致服务还没 ready 就被判断失败。调整后，我把启动分成三个状态：
| 状态 | 判断方式 | 含义 |
|---|---|---|
| 容器存活 | docker ps |
进程没有退出 |
| 服务健康 | /health |
vLLM 服务进入健康状态 |
| 模型可用 | /v1/models 和一次简单请求 |
API 能对外提供模型 |
这样看日志时就不容易把“加载中”误判成“死循环”。
复盘清单
这次我最后留下了一张 ECS GPU 上跑 vLLM 的预检清单：
nvidia-smi只说明宿主机正常，还要用 CUDA 容器测一次 GPU 可见性。- NAS 模型目录要在宿主机和容器内各查一次，路径、权限、
config.json、Tokenizer 和分片权重都要确认。 - 模型目录尽量只读挂载，缓存和日志放到本机盘。
- vLLM 镜像先单独
pull、inspect、跑 Python 入口，避免镜像问题混进模型加载日志。 - Docker runtime、GPU device request、挂载参数要通过
docker inspect复核。 - 健康检查不要只看容器状态，要区分
/health、/v1/models和首次请求。 - 冷启动耗时要记录下来，后面接网关、负载均衡或自动重启策略时才有依据。
这次的结论是：ECS GPU 上跑 vLLM，模型放 NAS 没问题，但要把 NAS、镜像、runtime 和 ready 状态拆开验证。否则一个“启动慢”的现象，会把存储、容器、GPU 和服务层问题全混在一起。
