【AI工具链】跟着敲一遍⑫:8 核跑 vLLM 翻车记

 到这里账已经算清了：1.5B 需要 11.1 GiB，可用只有 9.32 GiB，缺口 1.8 GiB。

补这个缺口有两条路：停掉 Dify 腾出 3.4 GiB，或者换更小的模型。我选了后者，理由很实际——停 Dify 要动生产环境，换模型只要下一个 1 GB 的文件。

内存预算：先算，再动手

0.5B 需要的 5.2 GiB，在 7.21 GiB 可用下余量 2 GiB。 这次不会触发页回收死循环。

下载：顺手拿到一个关键数字

docker run --rm -v /root/.vllm/models:/root/.cache/modelscope \   --entrypoint python vllm-openai-cpu:day12 \   -c "from modelscope import snapshot_download; print(snapshot_download('Qwen/Qwen2.5-0.5B-Instruct'))" 

11 个文件、共 943M，耗时 3 分 06 秒：

Downloading: 100%|██████████| 11/11 [03:06<00:00, 16.94s/file] /root/.cache/modelscope/models/Qwen--Qwen2.5-0.5B-Instruct/snapshots/master 

📖 初学者讲解：下载完一定要 ls -lh 确认 model.safetensors 的完整大小。中断的下载最容易在权重文件上留下"看起来存在、实际只有几 MB"的残缺文件，而这种文件会让 vLLM 报出与实际原因毫无关系的错误。

ls -lh /root/.vllm/models/models/Qwen--Qwen2.5-0.5B-Instruct/snapshots/master/ 

total 954M -rw-r--r-- 1 root root  659 config.json -rw-r--r-- 1 root root  242 generation_config.json -rw-r--r-- 1 root root 1.6M merges.txt -rw-r--r-- 1 root root 943M model.safetensors      ← 权重 -rw-r--r-- 1 root root 7.2K tokenizer_config.json -rw-r--r-- 1 root root 6.8M tokenizer.json -rw-r--r-- 1 root root 2.7M vocab.json 

一个小坑：容器名冲突

docker: Error response from daemon: Conflict. The container name "/vllm-server" is already in use by container "a81adff0dbe66...". 

上一轮被刹车杀掉的容器虽然 Exited (137)，但容器名仍然被占用。Docker 要求名字全局唯一，已停止的容器也占名。

修正：启动前先删。

docker rm -f vllm-server 2>/dev/null 

💡 为什么是 -f 而不是普通的 docker rm：普通 rm 要求容器处于停止状态才肯删；-f 会先发 SIGKILL 再删。这里旧容器已经 Exited，两者都能用，但 -f 更省事。

前提是旧容器不在 D 状态——在的话 -f 也会卡住，那就得先重启系统。

启动参数：只改四处

docker run -d --name vllm-server \   --network lpw-ai -p 8000:8000 \   --ipc=host \   --cpus=4 --memory=9g --memory-swap=9g \   --security-opt seccomp=unconfined --security-opt label=disable \   --cap-add SYS_NICE \   -e VLLM_TARGET_DEVICE=cpu \   -e VLLM_CPU_KVCACHE_SPACE=1 \   -e OMP_NUM_THREADS=4 \   -e PYTHONUNBUFFERED=1 \   -v /root/.vllm/models:/root/.cache/modelscope \   --entrypoint vllm \   vllm-openai-cpu:day12 \   serve /root/.cache/modelscope/models/Qwen--Qwen2.5-0.5B-Instruct/snapshots/master \   --host 0.0.0.0 --port 8000 \   --dtype float32 \   --max-model-len 2048 \   --max-num-seqs 4 \   --enforce-eager 

后两项放宽是有意的：1.5B 那次把上下文压到 512、并发压到 1，是为了"能在最小配置下起来"；这次内存充足，要验证的是"能不能实用"。

全文最重要的判据转折：load 26.77 但 D=1

启动后按 15 秒一次采样，得到了这组数据：

11:24:56  load=1.22   R=—   D=0   code=000 11:25:58  load=1.75   R=—   D=0   code=000 11:27:52  load=15.83  R=—   D=1   code=000 11:29:51  load=16.17  R=—   D=2   code=000 11:30:43  load=26.77  R=15  D=1   code=000 11:31:09  load=20.13  R=8   D=1   code=000 11:31:43  load=24.69  R=5   D=2   code=000 11:32:23  load=25.72  R=10  D=1   code=000 11:33:13  load=25.94  R=13  D=0   code=000 11:33:55  load=27.19  R=5   D=1   code=000 

如果你只看 load，这十行数据会让人得出"卡死了，赶紧杀"的结论——load 一直在 20~27，远超我为它设的 25 阈值。

但把 load 拆成 R 和 D 之后，性质完全变了：

D 只有 0~2，说明没有 I/O 等待堆积。 那 20~27 的 load 全部来自 R 状态的线程——它真的在算，不是在等。

⚠️ 这是整篇文章最该记住的一条：

load 高本身不是故障，D 任务堆积才是。

load 把 R（运行中）和 D（不可中断睡眠）加在一起统计。前者代表"在干活"，后者代表"在等 I/O 卡住"。同一个数字，两种截然相反的含义。

判断方法只要一行：

bash echo "R=$(ps -eo stat | awk '$1 ~ /^R/' | wc -l)  D=$(ps -eo stat | awk '$1 ~ /^D/' | wc -l)"

• R
   多、D ≤ 2 → 正在算，继续等
• D
   ≥ 5 且递增 → 真的卡住了，该杀

我的刹车脚本只设了 load ≥ 25 这一条阈值。按这个阈值，11:30:43 的 load=26.77 就会把它杀掉——而那一刻正是它做最后一次 warmup 前向的时刻，差 6 分钟就成功了。

这一段是"差点误杀"的完整现场。阈值本身没错，错的是用了一个含义模糊的指标做阈值。

时间账：12 分 40 秒

最后那 8 分钟是 warmup。它比"加载权重"本身还长 3 倍，这是最反直觉的一点：

无 AVX512-BF16 的 CPU 上，vLLM 的启动耗时不由模型体积决定，而由 warmup 决定。

warmup 要做一次完整的前向计算，耗时 ≈ 模型参数 × 上下文长度 × 线程数 三者共同决定，而且 float32 比 bf16 慢一个量级。

一次差点被误判的探测时机

采样循环跑完 6 次（11:33:55）时全部是 code=000，看起来像"跑了 10 分钟还是失败"。

但服务实际在 11:36:36 才就绪——比最后一次探测晚了 2 分 41 秒。

2026-10-29T03:36:35  INFO: Waiting for application startup. 2026-10-29T03:36:36  INFO: Application startup complete. 

💡 教训：000 只代表"此刻端口还没监听"，不代表"永远不会监听"。探测循环必须有足够长的窗口，而且不能因为窗口用完就下结论。

判断"还在加载"还是"已经失败"，靠的是 docker ps 的状态和日志时间戳，不是 curl 的返回码。

验收

curl -s -o /dev/null -w "code=%{http_code}\n" --max-time 10 http://127.0.0.1:8000/v1/models code=200 

图 19：code=200，端口通了。

curl -s http://127.0.0.1:8000/v1/models | python3 -m json.tool | head -30 

图 20：/v1/models 返回完整信息。max_model_len: 2048 说明参数正确生效；id 是绝对路径，因为用本地快照启动时模型名就是路径本身。

{   "object": "list",   "data": [{     "id": "/root/.cache/modelscope/models/Qwen--Qwen2.5-0.5B-Instruct/snapshots/master",     "object": "model",     "owned_by": "vllm",     "max_model_len": 2048,     "permission": [{"allow_sampling": true, "allow_logprobs": true, ...}]   }] } 

三个字段各自印证一件事：

预算验证：内存峰值落在预期区间

跑通之后回头看，最关键的不是"通了"，而是实际内存峰值是否落在预算内。

预算 5.2 GiB、可用 7.21 GiB、余量 2 GiB —— 没有触发页回收死循环。 这反向确认了 1.5B 的失败纯粹是那 1.8 GiB 缺口，而不是别的模糊原因。

💡 这就是"先算账、再动手"的价值：不是猜"应该够吧"，而是算出 5.2 < 7.21 再动手；跑完再核对实际值是否落在区间内。

对比前面三次失败——每次都是"先试，试了再说"，于是每次都要花 10 分钟以上才知道行不行。

速度实测：首次 262 秒，稳态 4.3 秒

接口通了之后，最后一步是测真实速度——这一步差点让我得出完全相反的结论。

第一次请求：

curl -s http://127.0.0.1:8000/v1/chat/completions \   -H 'Content-Type: application/json' \   -d '{"model":".../Qwen--Qwen2.5-0.5B-Instruct/snapshots/master","messages":[{"role":"user","content":"你好"}],"max_tokens":16}' \   -w "\n耗时=%{time_total}s\n" 

图 21：choices 正常返回，但末尾那行 耗时=261.912227s 让人心凉——16 个 token 用了 4 分 22 秒。

按这个数字算：16 ÷ 261.9 = 0.061 token/s。当时我几乎就写下"工程上不可用"了。

幸好又跑了一次：

图 22：同一请求第二次 103.625552s，比第一次少 158 秒——差值就是冷启动成本。

再跑五次，答案就完全不同了：

图 23：五次连续测试，用 python 直接解析 usage.completion_tokens 算准确速度——不能只看耗时，必须同时知道生成了几个 token。

第1次 4.27s  tokens=16  finish=stop   速度=3.745 token/s 第2次 4.61s  tokens=16  finish=length 速度=3.473 token/s 第3次 4.86s  tokens=16  finish=length 速度=3.291 token/s 第4次 4.43s  tokens=16  finish=length 速度=3.612 token/s 第5次 3.49s  tokens=13  finish=stop   速度=3.725 token/s 

稳态稳定在 3.3~3.7 token/s，五次波动不超过 15%。

从 0.061 到 3.5，差 57 倍。 同一个模型、同一条命令、同一个 16 token 的输出。

⚠️ 这是本文最容易犯的统计错误，也是最值钱的一条：

测推理速度必须跑多次取稳态，而且必须同时记录 completion_tokens。

两个陷阱叠在一起： 1. 拿首次请求当速度 → 把冷启动成本摊进每 token，低估 57 倍 2. 只看耗时不看 token 数 → 如果模型只生成 4 个 token 就停了，4 秒的耗时会被误算成 1 token/s

正确做法（就是上图那段）：

python for i in range(1, 6):     t0 = time.time()     out = subprocess.run(["curl","-s",url,"-H","Content-Type: application/json",                           "-d",json.dumps(payload,ensure_ascii=False)],                          capture_output=True, text=True).stdout     el = time.time() - t0     d = json.loads(out)     n = d["usage"]["completion_tokens"]     print(f"第{i}次 {el:.2f}s tokens={n} 速度={n/el:.3f} token/s")

慢的到底是什么：不是算力，是 I/O

这五次数据把前面所有推测都校正过来了：

算力其实是够的。慢的全部是 I/O 冷启动。

这跟 05 节那个发现完全自洽：import torch 53 秒、本地虚拟盘 6.4 MB/s ≈ 网络下载 5.68 MB/s。943 MB 的 safetensors 按 6 MB/s 读，就是 157 秒——正好对上第一二次请求之间那 158 秒的差值。

💡 所以 ⑫ 真正的结论是：vLLM CPU 版在这台机器上可用（稳态 3.5 token/s），但首次成本极高（启动 12 分 40 秒 + 首答 262 秒），适合长期常驻，不适合用完就停。

对比一下两种选型：

稳态差 3~6 倍，冷启动差 20 倍以上。

所以选择取决于场景：

• 常驻服务
  （一天用几十次）→ 13 分钟的启动成本可以摊薄，vLLM 能用
• 随手一问
  （一天用两三次）→ Ollama 明显更合适，vLLM 每次冷启动都亏

顺带记下版本：system_fingerprint: vllm-0.32.0-2743d51d。不同版本对启动日志和参数语义有差异（老版本用 --model，新版本用 serve <path> 位置参数），排查时先确认版本。

最后看一眼系统健康度

跑完这一串之后，R/D 依然是健康的：

图 24：R=4 D=1。4 个线程在跑、1 个任务在等 I/O，与 OMP_NUM_THREADS=4 一致——围栏与线程限制都正常工作。

整机没有出现任何 soft lockup，也没有 D 状态堆积。 这次是真的"跑起来了"，不是"把系统拖垮了"。