双卡RTX 3090榨干32B模型：vLLM多卡推理优化与流式反代避坑指南

1次阅读

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

上周我给工作室的 4U 机架式服务器塞进了两张二手涡轮版 RTX 3090，准备拿来跑 DeepSeek-R1-Distill-Qwen-32B 给团队做代码审计和本地 Agent 底座。一开始图省事直接拉了 Ollama，结果并发只要超过 4，首字延迟（TTFT）直接飙升到 9 秒以上，显存更是频繁因动态分配碎片化而爆掉。

对于多卡环境和稍具规模的并发调用，Ollama 的底层封装过于保守，张量并行（Tensor Parallelism）效率也喂不饱消费级显卡的带宽。最终我推倒重来，切回 vLLM + Ray + FastAPI 反向代理 架构。本文把我这三天踩过的 NCCL 死锁、KV Cache 调参、反代 SSE 缓冲截断等大坑整理出来，供各位自建推理节点的极客参考。

消费级主板玩双卡，第一个暗坑不是散热，而是 PCIe 通道拆分与 P2P（Peer-to-Peer）通信。企业级 A100/H100 有 NVLink 高速互联，而我们在普通主板上只能走 PCIe 4.0 拆分的 x8 + x8 通道。

在安装推理引擎前，必须通过 NVIDIA 官方拓扑工具检查通信状态：

nvidia-smi topo -m

输出矩阵中，如果两张卡之间显示的是 SYS（跨 CPU 甚至跨 NUMA 节点通信），张量并行时的通信开销会彻底吃掉双卡的算力红利；最理想的民用状态是 PHB（通过同一 PCIe 主机桥）或 PIX（通过单一 PCIe 开关）。

踩坑预警：没有硬件 NVLink 桥接器的双卡 3090，NCCL 在默认设置下会尝试走 P2P 内存拷贝，直接导致进程无休止卡死在初始化阶段。必须在环境变量中明确强制禁用 P2P，改走系统内存通信：

export NCCL_P2P_DISABLE=1
export NCCL_IB_DISABLE=1

32B 模型的全精度权重达 64GB 以上，2×24GB 显存必须上量化。实测 AWQ 4-bit 在保留逻辑推理精度（尤其是 R1 复杂的 CoT 思维链）的同时，单卡显存占用仅需约 18GB 左右，留给 KV Cache 的空间相对充裕。

我们采用 Docker Compose 编排，屏蔽宿主机复杂的 CUDA 依赖污染：

version: '3.8'

services:
  vllm-deepseek:
    image: vllm/vllm-openai:v0.7.2
    container_name: vllm-deepseek-32b
    runtime: nvidia
    restart: always
    environment:
      - CUDA_VISIBLE_DEVICES=0,1
      - NCCL_P2P_DISABLE=1
      - VLLM_WORKER_MULTIPROC_METHOD=spawn
    ports:
      - "8000:8000"
    volumes:
      - /data/huggingface/hub:/root/.cache/huggingface/hub
      - /dev/shm:/dev/shm
    ipc: host
    command: >
      --model deepseek-ai/DeepSeek-R1-Distill-Qwen-32B
      --quantization awq
      --tensor-parallel-size 2
      --max-model-len 16384
      --gpu-memory-utilization 0.92
      --swap-space 4
      --disable-log-requests
      --trust-remote-code
      --port 8000

--tensor-parallel-size 2：将模型层横向拆分到 2 张 GPU 上，实现显存均摊。
--gpu-memory-utilization 0.92：默认 0.9 比较保守。在规避显存碎片的前提下，3090 设为 0.92 可以压榨出更多显存空间给 PagedAttention 分配 Block，防止长文本推理时 OOM。
--max-model-len 16384：DeepSeek-R1 的输出 token 往往极长，但直接拉满 32k 会导致 KV Cache 瞬间占满显存，限制并发数。在 48GB 总显存下，16k 是性能与并发的黄金折中点。
ipc: host 与 /dev/shm 挂载：必须配置！PyTorch 多进程通信依赖大容量共享内存，Docker 默认的 64MB 会在并发激增时引发 Bus Error 崩溃。

模型跑起来后，直接把 8000 端口裸奔暴露给客户端是不可取的。我们需要一层 Nginx 或自研网关来做 API Key 轮询、限流以及监控。但在配置 SSE（Server-Sent Events）流式反代时，很多人会遇到 “打字机特效失效，憋了十几秒后文字突然整块喷出” 的问题。

核心原因就在于反向代理层的 Buffer 机制拦截了分块传输。下面是经过实战验证的 Nginx 高并发反代配置片段：

server {
    listen 443 ssl http2;
    server_name llm-api.nassky.top;

    ssl_certificate /etc/nginx/certs/fullchain.pem;
    ssl_certificate_key /etc/nginx/certs/privkey.pem;

    location /v1/chat/completions {
        proxy_pass http://127.0.0.1:8000/v1/chat/completions;
        proxy_http_version 1.1;

        # 核心：关闭所有缓冲机制，实现真正的流式推送
        proxy_set_header Connection '';
        proxy_buffering off;
        proxy_cache off;
        chunked_transfer_encoding on;

        # 超时时间调整，R1 思考链长时首次吐字可能需要数秒
        proxy_read_timeout 600s;
        proxy_send_timeout 600s;

        # 透传客户端真实 IP
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

特别关注 proxy_buffering off; 与 Connection ''，这是保持长连接、避免中间网关缓冲 SSE 数据块的生命线。

使用自写的 Python 异步测试脚本模拟内部真实工作流，在输入 Prompt 平均 1.5k Token、生成输出 1k Token 条件下，对比了 Ollama 与优化后的 vLLM 性能表现：

运行框架	并发数 (Concurrency)	TTFT (首字延迟)	吞吐量 (Tokens/s)	显存使用稳定性
Ollama (Q4_K_M)	1	1.82 s	31.2	稳定
Ollama (Q4_K_M)	8	12.45 s	42.1	频繁抖动 / 偶发 OOM
vLLM (AWQ TP=2)	1	0.74 s	48.6	极度平稳
vLLM (AWQ TP=2)	8	1.86 s	182.4	显存被 PagedAttention 锁死，不溢出

压测数据非常残酷：在 8 并发下，vLLM 的总吞吐达到了 182 Token/s，是 Ollama 的 4 倍以上；首字延迟控制在 2 秒内，用户在前端使用 Cherry Studio 或 Open-WebUI 时体感极为丝滑。

折腾大模型私有化部署，切忌迷信“开箱即用”的一键工具。消费级硬件的上限其实很高，但需要你深入到系统底层对资源做精确裁切：

别怕魔改环境变量：消费级多卡互联没有 NVLink，务必关掉 NCCL_P2P，否则通信死锁会让你怀疑人生。
压榨 KV Cache：善用 max_model_len 控制长下文，把 gpu_memory_utilization 顶到极限但别越界，留出 4GB 左右 SWAP 空间作为安全垫。
排查流式代理：如果你的 WebUI 打字机效果迟钝，优先查 Nginx 反代缓冲而不是怪模型卡顿。

整套架构跑通后，两张二手 3090 成功撑起了一个高性能的 DeepSeek 本地服务。后续我将继续分享如何基于此 API 搭建带审计记忆的本地代码 Agent 流程，欢迎持续关注。

正文完