DeepSeek-V3 在 vLLM 环境下部署面临严苛的显存挑战及 CUDA OOM 问题

DeepSeek-V3 庞大的 671B 参数量导致其在 vLLM 部署中对显存极度敏感，频繁的 CUDA OOM 并非总是源于硬件上限，通常是由于默认显存分配机制在面对长文本处理时缺乏弹性。vLLM 旨在为各类硬件提供 Get Started Documentation Easy Deploy the widest range of open-source models on any hardware 的支持，若直接使用默认 0.9 的 gpu_memory_utilization 往往导致 PyTorch 剩余缓存过少，此时应将该参数下调至 0.8 或 0.7 以保留缓冲空间。

针对 MoE 架构的优化，除了方案 A 中将 max_model_len 限制在 8192 等操作外，还应利用其原生内置的 OpenAI-compatible API 接口实现快速集成。在部署时，建议组合以下策略以提升性能：

方案 B 重点在于通过 --kv-cache-dtype fp8 启用 KV Cache 量化，这能显著压缩显存占用，从而在相同硬件条件下支撑更高的并发量。这契合 vLLM 通过 PagedAttention 机制最大化吞吐量的核心逻辑，确保系统在处理请求时保持高效。

方案 C 通过调整 block_size 为 32 来应对碎片化。在此基础上，利用先进的调度算法和 continuous batching 可以进一步优化 GPU 利用率。若在配置过程中遇到多卡环境下的异常报错，可尝试设置 NCCL_P2P_DISABLE=1 来规避通信缓冲区干扰。

需注意，上述参数调整与量化策略必须结合使用。若仅调整 gpu_memory_utilization 而未开启 FP8 量化，在高并发下依然会触及显存上限。此外，虽然 vLLM 致力于降低高性能 LLM 的使用门槛和推理成本，但若此时硬件的带宽瓶颈被触及，仅靠软件层面的设置将无法生效。保持这些配置项在 Stable 版本下的兼容性，能确保推理任务在各种复杂场景中稳定运行，获得最优的吞吐表现。

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

在 16 并发时默认配置极易触发 OOM，而采用 FP8 KV 量化配合 0.8 的显存占用比，可将承载量提升至 40+，且 TTFT 延迟保持稳定。这种方案在吞吐量与推理精度上均优于外部强行量化，充分发挥了该引擎在不同硬件平台上的性价比优势。