拒绝OOM！双卡RTX 4090用vLLM+Ray部署DeepSeek满血蒸馏版实战踩坑记

2次阅读

共计 3328 个字符，预计需要花费 9 分钟才能阅读完成。

最近团队内部想在本地机房搭建一套支持 32k 长上下文的代码审查与智能 Agent 后端。起初我直接拉了 Ollama 跑量化版，但在跑 5 个并发流式长请求时，推理延迟瞬间从 45ms 飙到 2 秒以上，甚至直接遇到显存雪崩（OOM）。在手头只有两块消费级 RTX 4090（合计 48GB 显存）的约束下，要稳定吃下 DeepSeek-R1-Distill-Llama-70B 这种体量的推理任务，必须改用更底层的推理加速框架。

折腾了整整一个周末，我最终敲定了 Ray 调度 + vLLM 核心引擎 + AWQ 4-bit 量化 + Nginx 双流式反代 的落地架构。这篇文章把我踩过的显存分配、NCCL 通信死锁、多卡张量并行（Tensor Parallelism）参数调优实战记录梳理出来，供同样在折腾本地私有化 LLM 部署的朋友参考。

先算一笔硬账。70B 模型的 FP16 浮点权重体积大约在 135GB 左右，显然两张 24GB 的 4090 连模型权重都加载不下。通常极客们有两种选择：

GGUF CPU+GPU 混合卸载：虽然能跑，但 PCI-e 4.0 4x/8x 的带宽瓶颈会让每秒 Token 生成速度掉到 2~4 tokens/s，基本无法满足 Agent 多轮并发调用。
AWQ 4-bit 激活感知量化：权重缩减到 36GB 左右，两张 4090 开启 tensor_parallel_size=2 后，每张卡均摊约 18GB 静态权重，每张卡还能匀出整整 6GB 纯显存分配给 PagedAttention 作为 KV Cache 池。

因此，选择 DeepSeek-R1-Distill-Llama-70B-AWQ 作为推理核心是性价比最优的方案。在 vLLM 连续批处理（Continuous Batching）加持下，实测首字延迟（TTFT）能压在 600ms 以内，输出速率维持在 28~35 tokens/s 之间。

多卡张量并行最容易翻车的地方就是驱动与 NCCL 的通信效率。双张 4090 没有 NVLink 桥接，数据只能走主板的 PCIe 总线交换。我在 Ubuntu 22.04 LTS 裸机上部署时，遇到的第一个深坑就是 NCCL 试图通过 P2P 访问显存，导致显卡驱动直接卡死在 Initializing Ray cluster 阶段。

关键解决办法是在系统环境变量中强制关闭 P2P，并禁用 InfiniBand 探测：

# 创建专属 Conda 虚拟环境
conda create -n vllm-deploy python=3.10 -y
conda activate vllm-deploy

# 安装与 CUDA 12.1 匹配的 torch 与 vllm
pip install torch==2.3.0 torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121
pip install vllm==0.5.4 ray==2.30.0

# 写入 NCCL 修复环境变量（针对消费级无 NVLink 多卡必须配置）cat << 'EOF' >> ~/.bashrc
export NCCL_P2P_DISABLE=1
export NCCL_IB_DISABLE=1
export CUDA_DEVICE_ORDER=PCI_BUS_ID
export CUDA_VISIBLE_DEVICES=0,1
EOF

source ~/.bashrc

很多人启动 vLLM 只传 --model 和 --tensor-parallel-size，这在跑短文本 Demo 时没事，一旦 Agent 并发传入 16k 以上的长 prompt，立刻报 RuntimeError: Engine out of memory。

下面是我经过反复压测验证后，写入 docker-compose.yml / systemd 服务的最优启动指令：

python3 -m vllm.entrypoints.openai.api_server \
    --model /mnt/models/DeepSeek-R1-Distill-Llama-70B-AWQ \
    --tensor-parallel-size 2 \
    --gpu-memory-utilization 0.92 \
    --max-model-len 16384 \
    --max-num-seqs 16 \
    --enforce-eager \
    --trust-remote-code \
    --host 0.0.0.0 \
    --port 8000

--gpu-memory-utilization 0.92：默认是 0.9。设置过高（如 0.98）会导致 CUDA Context 初始化阶段崩溃；设置为 0.92 时，刚好为 PyTorch 动态算子分配预留了约 1.9GB 显存缓冲。
--max-model-len 16384：DeepSeek 原生支持超长上下文，但在 48GB 双卡机上强开 32768 会大幅压缩 KV Cache 的块数量（Block Numbers），导致并发一上来就排队等待（Queued requests）。16384 是精度与并发吞吐的黄金平衡点。
--enforce-eager：非常关键！ 默认情况下 vLLM 会启用 CUDA Graph 来减少小 batch 时的 CPU overhead，但 CUDA Graph 在双卡 4090 PCIe 传输下非常吃显存，直接吃掉将近 1.5GB 的显存开销。开启 --enforce-eager 后显存立即释放，直接换取了 30% 以上的并发空间。

当大模型输出作为流式响应（Server-Sent Events, SSE）提供给上层业务时，直接暴露 vLLM 的 8000 端口极易遭受恶意长连接拖垮。我们需要用 Nginx 做反向代理，同时必须关闭反向代理缓冲，否则你的前端流式打字机效果会变成“卡顿 5 秒然后啪的一下吐出一整大段”。

下面是实操验证过的 Nginx 虚拟主机核心配置片段：

upstream vllm_backend {
    server 127.0.0.1:8000;
    keepalive 64;
}

server {
    listen 8080;
    server_name llm.internal.local;

    client_max_body_size 64M;

    location /v1/chat/completions {
        proxy_pass http://vllm_backend;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
        proxy_set_header Host $host;

        # 核心：必须禁用缓冲与超时拉长
        proxy_buffering off;
        proxy_cache off;
        chunked_transfer_encoding on;
        
        # 针对长推理思考模型（如 R1 架构）必须拉长读超时
        proxy_read_timeout 600s;
        proxy_send_timeout 600s;
    }
}

配置全部就绪后，我用 Locust 模拟了 10 个用户同时发起 4k 上下文的代码 review 请求，执行以下测试脚本验证显存稳定性：

# 查看双卡显存与 PCIe 吞吐负载
watch -n 0.5 nvidia-smi --query-gpu=index,temperature.gpu,utilization.gpu,memory.used,memory.total --format=csv

实测两张 4090 的显存稳定停留在 22140MiB / 24564MiB，利用率稳定在 90% 且没有发生抖动。即使在 10 并发全打满的情况下，系统自动利用 PagedAttention 进行碎片内存调度，平均吞吐维持在 118 Tokens/s，双卡温度压制在 68°C 上下，彻底打消了 OOM 宕机的顾虑。

在双消费级显卡部署大模型的实践中，硬件性能往往不是最大的阻碍，显存预算的精密计算与通信瓶颈的规避 才是核心。如果你也在折腾类似配置，请记住两点：第一，消费级显卡没有 NVLink，务必在 NCCL 层面禁用 P2P，避免驱动锁死；第二，宁可开启 --enforce-eager 牺牲 5% 的理论单批次峰值速度，也要把显存空间省出来给 KV Cache。只有显存不爆，服务才能真正跑在生产线上。

===EOF===

正文完