vLLM 部署 DeepSeek-V3 时显存溢出（OOM）的调优经验分享

DeepSeek-V3 这种规模的模型，直接用 vLLM 默认参数跑，基本上只要 Prompt 稍微长点或者并发一高，显存瞬间爆掉是常态。我最近在 8 张 H800 上死磕这个模型，总结出一套能让吞吐量上去且不 OOM 的配置方案。

最核心的坑在于 gpu_memory_utilization。vLLM 默认会吃掉 90% 的显存，但 DeepSeek-V3 的 KV Cache 占用极高，留给模型计算的动态空间不足就会直接 OOM。建议把这个值压到 0.8 甚至 0.7，给系统留出呼吸空间。

关键配置组合：

启动命令里必须强制指定 max_model_len，不要让它自动检测，否则它会尝试加载模型支持的最大长度，直接把显存撑爆。

python -m vllm.entrypoints.openai.api_server \
    --model deepseek-ai/DeepSeek-V3 \
    --tensor-parallel-size 8 \
    --max-model-len 16384 \
    --gpu-memory-utilization 0.8 \
    --max-num-seqs 64 \
    --kv-cache-dtype fp8

几个实操细节：

FP8 量化是救命稻草。如果显存依然吃紧，强制开启 --kv-cache-dtype fp8。这能显著降低 KV Cache 的显存占用，且精度损失在可接受范围内。如果不开启，在多用户并发时，显存增长曲线非常恐怖。

限制并发序列数。--max-num-seqs 默认值往往太激进。我测试发现，将它限制在 64 或 128，虽然单次处理的请求数少了，但能有效避免在长文本生成阶段突然触发 OOM 导致整个服务重启。

关于分布式运行的坑。在多机环境下，一定要检查 NCCL_P2P_DISABLE=1 这个环境变量。很多时候 OOM 伴随着 GPU 间通信超时，禁用 P2P 虽有微小性能损耗，但能解决很多莫名其妙的显存碎片问题。

调优后的对比指标：
默认配置：并发 10 个请求，平均长度 2k，显存波动剧烈，极易在生成末尾 OOM。
优化后配置：并发 32 个请求，显存占用稳定在 85% 左右，吞吐量提升约 40%。

如果你的场景需要极长上下文，不要试图通过增加 GPU 数量来硬扛，优先尝试调整 block_size（默认 16，尝试改为 32）来优化内存碎片。