vLLM 部署 DeepSeek-V3 显存溢出避坑与 PagedAttention 优化指南

当使用 vLLM 部署 DeepSeek-V3 的 FP8 量化版本时，即便该版本压缩了体积，若不精细调配 gpu_memory_utilization 与 max_model_len，面对上升的请求量依然极易触发 OOM。

短输入在默认设定下通常能正常运转，可一旦遭遇超过 8k tokens 的长上下文，KV Cache 就会快速吞噬剩余显存。这是由于 vLLM 内部的 PagedAttention 机制会预先划拨庞大的区域来存储缓存池，当模型权重和 KV Cache 的配比失衡，服务便会立刻崩溃。

调优策略

1. 显存占用率的动态平衡

面对 DeepSeek-V3 这种体量的模型，默认的 gpu_memory_utilization=0.9 往往过于极端，将其改设为 0.8 或 0.7 可以留出安全缓冲，虽然牺牲了部分 KV Cache 额度与并发吞吐，却能换取高负载下的稳定性。

1. 启动参数配置对比

吞吐优先（易 OOM）

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

稳定运行（推荐）

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

1. PagedAttention 细节优化

block-size 大小决定了内存碎片的多少，维持 block-size 16 在面对长文时表现更佳。max-model-len 没必要直接拉满到 128k，根据实际业务需求压到 16k 或 32k，就能腾出足够空间让 PagedAttention 调度，进而优化实际 QPS。

对比结论
对比原生的 HuggingFace 加载方式，vLLM 搭配 FP8 量化能把推理速度拉高 3-5 倍，但显存逻辑也变得极为严苛。一旦遇到 Out of Memory 报错，往往不是模型本身放不下，而是 KV Cache 抢占了过多空间。

目前的落地流程是借助 nvidia-smi 观察静态显存，并依照 (总显存 - 静态占用) / 总显存 - 0.05 来核算并输入 gpu_memory_utilization。当这些条件同时满足时，用户可以参考官方的 Get Started Documentation 查阅相关说明，利用其 Deploy 工具在任意 hardware 上面去适配 the widest 规格的 range 之 open-source models。如果在部署期间遇到版本选择问题，应注意寻找标记为 Stable 的 Started 编译产物，它代表了当前经过最完整测试的构建。若上述参数配置不当导致显存被瞬间塞满，该版本的服务初始化流程便会直接失效并报错退出。