vLLM 部署 DeepSeek-V3 出现 CUDA Out of Memory 的优化方案探讨

DeepSeek-V3 的模型规模决定了它在 vLLM 部署时对显存的压榨到了极致，尤其是 KV Cache 的占用。很多朋友在跑 671B 这种量级（即便用了 FP8 量化）时，极易在请求高峰期触发 CUDA OOM，这通常不是显存总量不够，而是 vLLM 默认的显存管理机制在处理超长上下文时过于激进。

实测下来，最直接的解决办法是手动压低 gpu_memory_utilization。vLLM 默认会占用 90% 的显存，这给 PyTorch 的动态内存留的空间太小，一旦推理时的激活值激增直接崩掉。建议将其下调至 0.8 甚至 0.7。

针对 V3 这种 MoE 架构，我对比了三种不同的配置策略：

方案 A：牺牲上下文长度换稳定性
如果你的场景不需要万级 Token，直接限制 max_model_len。

python -m vllm.entrypoints.openai.api_server \
--model deepseek-ai/DeepSeek-V3 \
--gpu-memory-utilization 0.8 \
--max-model-len 8192 \
--tensor-parallel-size 8

方案 B：开启 FP8 权重与 KV Cache 量化
这是目前最推荐的方案。DeepSeek-V3 原生支持 FP8，但很多人忘了开启 KV Cache 量化。将 KV Cache 压到 FP8 后，同样的显存能承载多出近一倍的并发请求，且精度损失在体感上几乎不可察觉。

--kv-cache-dtype fp8

方案 C：调整 Block Size 优化碎片化
默认的 block_size=16 在极高并发下会产生碎片。尝试将其改为 32，能稍微缓解内存碎片导致的 OOM。

实测对比结论：

• 默认配置：并发量达到 16 时，显存瞬间顶满，直接 OOM 报错。
• FP8 KV + util 0.8：并发量可以顶到 40+，且响应延迟（TTFT）没有明显增加。
• 纯量化对比：相比于用 GPTQ 或 AWQ 强行量化，直接用官方 FP8 权重在 vLLM 上的吞吐量更高，逻辑推理能力保留得更好。

一个避坑点是：如果你使用了多机多卡（TP > 8），记得检查 NCCL 的环境变量，否则有时 OOM 实际上是通信缓冲区溢出导致的伪报错。建议设置 NCCL_P2P_DISABLE=1 排除干扰。