共计 4150 个字符，预计需要花费 11 分钟才能阅读完成。
最近公有云的推理 API 频频遭遇超时和限流，尤其在跑复杂 Agent 工作流时，网络抖动和单并发排队直接把执行效率拉垮。我决定把生产环境中的部分敏感业务切到工作室的双卡机器上。但刚上手就遇到了现实问题：用常规的 Ollama 跑大上下文推理，并发只要超过 4 个，生成延迟（TTFT）就呈指数级飙升，双卡利用率经常卡在单卡 100%、单卡 0% 的奇葩状态。
为了榨干手头两张 RTX 3090（合计 48GB 显存）的推理性能，我彻底抛弃了封装过度的开箱即用工具，改用原生 vLLM 配合 Tensor Parallelism（张量并行）搭建一套生产级高并发推理端点。本文记录踩坑过程中的真实参数调优、NCCL 通信死锁排查与显存分配细节。
一、硬件拓扑与底层架构避坑
在双卡或多卡环境下部署 LLM，最先制约吞吐的从来不是核心主频，而是卡间互联带宽与 PCIe 通道分配。很多人将两张消费级显卡插在普通主板上就直接开干，结果发现多卡并行比单卡还慢，这是因为卡间通信被卡在了 PCIe 切分上。
我的测试平台配置如下：
- CPU: AMD EPYC 7302P（16 核 32 线程，提供 128 条全速 PCIe 4.0 通道）
- 主板 : 永擎 ROMED8-2T（支持双 PCIe 4.0 x16 全速插槽，直连 CPU）
- GPU: 2x NVIDIA RTX 3090 24GB（无 NVLink 桥接，走 PCIe P2P 通信）
- RAM: 128GB DDR4 3200MHz ECC REG
在消费级 Z790/B650 主板上，第二根 PCIe 槽通常只能走芯片组提供的 x4 通道，或者拆分成 x8+x8。如果走芯片组（PCH），张量并行传输权重切片时会有巨大延迟。部署前先通过命令检查拓扑：
# 查看 GPU 间通信矩阵
nvidia-smi topo -m 如果两个卡之间的连接显示为 SYS（跨 CPU 甚至走主板低速总线），张量并行（Tensor Parallelism）性能会大幅衰减；如果是 PIX 或 PXB（同一 PCIe 控制器直连），则完全可以接受。
二、生产级 Docker Compose 编排实战
我们选用 DeepSeek-R1-Distill-Qwen-32B-AWQ 或 DeepSeek-R1-Distill-Llama-8B 进行部署。对于双 3090（48GB 显存），32B-AWQ 刚好能塞下，留给 KV Cache 的显存较为紧张；而 8B/14B 原生 FP16 模型则能提供极为充裕的上下文并发空间。这里以综合性价比极高的 DeepSeek-R1-Distill-Qwen-14B（FP16 原生精度） 为例。
直接上生产环境测试验证过的 docker-compose.yml 配置文件：
services:
vllm-deepseek:
image: vllm/vllm-openai:v0.7.2
container_name: vllm-deepseek-14b
runtime: nvidia
restart: unless-stopped
ipc: host
network_mode: host
environment:
- CUDA_VISIBLE_DEVICES=0,1
- NCCL_P2P_DISABLE=0
- NCCL_IB_DISABLE=1
- VLLM_WORKER_MULTIPROC_METHOD=spawn
volumes:
- /data/models/deepseek-ai/DeepSeek-R1-Distill-Qwen-14B:/model
- /data/huggingface_cache:/root/.cache/huggingface
command: >
--model /model
--served-model-name deepseek-r1-14b
--tensor-parallel-size 2
--pipeline-parallel-size 1
--max-model-len 16384
--gpu-memory-utilization 0.92
--swap-space 8
--enforce-eager
--enable-chunked-prefill
--max-num-batched-tokens 4096
--enable-prefix-caching
--trust-remote-code
--port 8000
deploy:
resources:
reservations:
devices:
- driver: nvidia
count: all
capabilities: [gpu]关键调优参数硬核拆解：
ipc: host：必须配置。PyTorch 多进程通信通过共享内存传递数据，Docker 默认的 64MB 共享内存会导致 NCCL 瞬时崩溃。--tensor-parallel-size 2：将模型每一层的注意力头切分到 2 张显卡上计算。注意 14B 模型的注意力头数（Qwen-14B 有 40 个 head）必须能被并行度整除。--gpu-memory-utilization 0.92：默认是 0.90。在明确机器没有 X11 桌面渲染占用的情况下，压榨到 0.92 可以多挤出约 1GB 显存给 PagedAttention 分配虚拟块。--enable-prefix-caching：极客利器。DeepSeek-R1 这类带有强 System Prompt、多轮推理思考标签（<think>…</think>）的模型，多轮对话中大量的历史前缀高度重合，开启后显存缓存复用，能降低 60% 以上的 Prefill 耗时。--enable-chunked-prefill与--max-num-batched-tokens 4096：核心吞吐平衡参数。防止某个并发请求发来 10k 的长文档，把整个计算管线占死，导致其他并发请求的生成阶段严重卡顿（Decoded Starvation）。
三、三个高频隐蔽踩坑与排障纪实
1. 无 NVLink 下的双卡 NCCL 进程卡死（D-State 挂起）
在没有物理 NVLink 桥接的消费级双卡上，启动 vLLM 时往往会卡在 Graph capturing... 或首次发起请求时日志直接静止，容器没有任何报错，但 nvidia-smi 显示进程处于 100% 阻塞。
原因定位 ：Linux 内核启用了 PCIe 的 P2P（Peer-to-Peer）DMA 传输，但部分消费级主板的 IOMMU 或 Access Control Services (ACS) 限制导致数据包静默丢弃。此时必须在环境变量中明确约束 NCCL：
# 如果主板对 PCIe P2P 寻址支持不佳，强制通过共享内存规避
export NCCL_P2P_DISABLE=1
# 增加调试日志确认通信链路
export NCCL_DEBUG=INFO
export NCCL_DEBUG_SUBSYS=ALL关闭 P2P 虽然会导致显卡间数据通过系统主内存中转，带宽从 20GB/s 跌至 10GB/s 左右，但至少可以让服务在没有硬件桥的机器上稳定运行且不出现死锁。
2. 动态上下文导致的 OOM 与 --enforce-eager 的选择
vLLM 默认使用 CUDA Graph 机制对特定 batch 维度的静态计算图进行预编译缓存，这能大幅降低算子 launch 延迟。然而在双 3090 跑 14B 且上下文设置到 16k 时，CUDA Graph 会额外吃掉近 2.5GB 显存！
这导致留给 KV Cache 的空间被压缩到极致，一旦并发冲上 8 个且带大 prompt，服务立刻抛出 Engine terminated: CUDA out of memory。
实战解法 ：加上 --enforce-eager 彻底关闭 CUDA Graph。虽然单个 token 的解码延迟上升了约 8-12%，但省下的 2.5GB 显存让系统能多容纳接近 8,000 个 token 的 KV Cache 块，多并发稳定性直接提升一个档次。
四、真实负载压测对比：vLLM vs Ollama
我们使用 locust 编写测试脚本，向本地服务端发送真实业务测试集：每次 Prompt 长度 1200 tokens，要求生成 500 tokens，模拟 10 个客户端并发持续发起 200 次请求。
| 部署方案 | 模型规格 | 并发数 | 平均首字延迟 (TTFT) | 整体吞吐量 (Tokens/s) | 显存利用率 (双卡均值) |
|---|---|---|---|---|---|
| Ollama 默认流水线 | 14B Q4_K_M | 10 | 3850 ms | 42.1 tps | Card0: 95% / Card1: 12% |
| vLLM (关闭优化) | 14B FP16 | 10 | 890 ms | 148.5 tps | Card0: 92% / Card1: 92% |
| vLLM (PrefixCache + Chunked) | 14B FP16 | 10 | 210 ms | 214.8 tps | Card0: 92% / Card1: 92% |
测试数据非常直观：在单卡或简单体验场景下，Ollama 确实省事；但在持续且高并发的应用场景下，vLLM 凭借真正的张量并行与 PagedAttention 显存管理，吞吐量达到了 Ollama 的 5 倍以上，尤其首字响应延迟（TTFT）在 Prefix Caching 加持下降低了一个数量级。
五、上游流式网关（Nginx 反代）防卡顿配置
把服务通过 Nginx 暴露给前端 Open-WebUI 或 Agent 时，很多人反馈打字机效果卡顿，变成“一次喷出一大团字”，这是由于 Nginx 默认开启了响应缓冲（proxy_buffering），把 SSE（Server-Sent Events）的流式 chunk 给拦截缓存了。
在 Nginx 的反向代理配置中，务必打上如下标记：
server {
listen 80;
server_name llm.internal.lan;
location /v1/ {
proxy_pass http://127.0.0.1:8000/v1/;
proxy_http_version 1.1;
proxy_set_header Connection "";
# 核心设置：禁用缓冲，确保 SSE 流式实时推送
proxy_buffering off;
proxy_cache off;
proxy_read_timeout 600s;
proxy_send_timeout 600s;
chunked_transfer_encoding on;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}
