vLLM 部署 DeepSeek-V3 时显存溢出怎么优化 PagedAttention 参数

DeepSeek-V3 这种规模的模型在 vLLM 里跑，最让人头疼的就是显存被 PagedAttention 预占得太狠，导致实际推理时稍微长一点的 Context 就直接 OOM。很多人习惯直接调 gpu_memory_utilization，但其实关键在 block_size 和 max_model_len 的配合。

默认情况下，vLLM 会尝试抢占几乎所有可用显存来做 KV Cache 缓存，如果你的显存刚好在临界点，很容易在加载模型瞬间崩掉。

实战优化操作：

首先，把 gpu_memory_utilization 压低到 0.8 或 0.85，给系统留出呼吸空间，防止 CUDA 驱动在动态分配时触发溢出。

其次，重点调整 block_size。默认是 16，在处理超长文本时，如果碎片化严重，显存利用率会下降。尝试将其改为 32，虽然会增加轻微的内部碎片，但在某些 GPU 架构上能提升内存访问对齐效率。

最核心的技巧是限制 max_model_len。不要直接用模型的默认最大长度，根据你的实际业务场景（比如只做 4K 窗口的对话）强制指定，这样 vLLM 在初始化 KV Cache 块时就不会预留过大的空间。

启动命令参考：

python -m vllm.entrypoints.openai.api_server \
    --model deepseek-ai/DeepSeek-V3 \
    --tensor-parallel-size 8 \
    --gpu-memory-utilization 0.85 \
    --max-model-len 8192 \
    --block-size 32 \
    --kv-cache-dtype fp8

几个踩过的坑：

FP8 量化是救命稻草：如果显存依然紧绷，一定要加上 --kv-cache-dtype fp8。DeepSeek-V3 的 KV Cache 体积巨大，用 FP8 能直接把 KV Cache 占用的显存砍掉近一半，且精度损失在绝大多数对话场景下可以忽略不计。

多卡同步问题：在 8 卡 A100/H100 环境下，如果发现某一张卡显存占用异常高，通常是由于 vLLM 的负载均衡在处理请求时，KV Cache 的分布不均导致的。此时检查 tensor-parallel-size 是否与模型分片严格对应。

Swap 空间陷阱：不要依赖 --swap-space。虽然它能让你在显存不足时把 Cache 刷到 CPU 内存，但一旦触发 Swap，推理速度会掉到每秒 1-2 个 token，基本等于不可用，不如直接通过限制 max_num_seqs 来控制并发量。

建议的配置组合：
低显存模式：gpu_memory_utilization 0.7 + max-model-len 4096 + kv-cache-dtype fp8
高性能模式：gpu_memory_utilization 0.9 + block-size 32 + tensor-parallel-size 8