上个月接了个活，要把一个开源模型部署成内部可用的 API 服务。一开始图省事用了 Ollama，单用户测着挺顺，结果一上并发（就 5 个请求），P95 延迟直接从 0.8s 飙到 45s——排队排到怀疑人生。查了下原因，Ollama 底层是 llama.cpp，本质是单请求串行处理，没有连续批处理。得，换 vLLM。
本以为装好就能跑，结果一晚上全耗在报错上。下面这四个坑，我挨个踩了一遍，你直接跳过。
坑 1：--max-model-len 拍脑袋设 32k，直接 OOM
第一次起服务，我寻思模型支持长上下文，就把 --max-model-len 设成 32768。结果一启动，CUDA out of memory，连模型都加载不进去。
后来才搞明白：KV cache 是随 context 长度平方级涨的，不是线性。32k 的上下文，光 KV cache 就把显存吃穿了。降到 8192 才稳住。如果你的场景大部分是短 query，老实设个 8k 就行，别贪。
坑 2：--gpu-memory-utilization 别拉满
我又犯了个典型错误：觉得显存越用满越好，设了个 0.98。结果跑着跑着偶发 OOM，还不好复现。
vLLM 其实要预留一部分显存给 KV cache 做缓冲，拉满反而容易炸。保守一点，设 0.85 左右，给 KV cache 留够空间。这个数值要实测，别抄别人的。
坑 3：环境不干净，全是 wheel 和运行时版本错配
最烦的一次：pip install vllm 装好了，一 import 就报一堆奇奇怪怪的符号错误。排查了半天，九成是环境不干净，wheel 和 PyTorch/CUDA 版本对不上。
处理方式也很粗暴：卸干净重来。
pip uninstall -y vllm torch torchvision torchaudio
再装，确保 PyTorch 源和 CUDA 版本匹配：
pip install vllm --extra-index-url https://download.pytorch.org/whl/cu129
装完之后一定先跑个 python -c "import vllm" 验证，别直接上服务。
坑 4：flashinfer 编译报错，JIT 炸了
装完环境，起了服务，结果采样后端 flashinfer 在 CUDA 13.2 下 JIT 编译直接报错，报的是 cub 里一个类缺成员。这东西是 vLLM 默认的采样后端，但新 CUDA 下 0.6.x 版本就是编不过。
解法：禁用 flashinfer，切回 PyTorch 原生后端。按你版本对应的环境变量设一下，改完就好了。低端卡上我后来一直用的 PyTorch 原生后端，稳。
调完的结论
调完这几轮，服务终于跑起来了。同样一张卡，从 Ollama 串行到 vLLM 连续批处理，吞吐能提 10-20 倍。几个关键参数再强调一遍：
--max-model-len按真实场景设（8k 起步），别贪长上下文--gpu-memory-utilization留余量（0.85 左右），别拉满--max-num-seqs和--max-num-batched-tokens配套调- 环境必须干净，PyTorch / CUDA / wheel 版本要一致
- flashinfer 新 CUDA 下编译不过就切 PyTorch 原生后端
如果你也在折腾 vLLM，卡在哪个报错上，评论区甩过来，我看能不能帮上忙。
📌 更多 AI 实战干货、踩坑记录，欢迎关注公众号 「你的应急食品」
