vLLM 生产部署并发与显存实战:量化档位与吞吐权衡
面向生产环境的 vLLM 部署清单,聚焦并发上限、显存占用、AWQ/GPTQ 量化选择与吞吐实测方法,给出可复现的硬件档位建议。
本文は SEO 深度のため主に中国語です。上記は要点のローカライズ。言語切替と深リンクで国際ナビできます。

vLLM 生产部署并发与显存实战:量化档位与吞吐权衡
这是 vLLM 生产部署并发与显存实战:量化档位与吞吐权衡的完整简体中文 Markdown 指南。
开篇
vLLM 是当前本地部署与 API 中转场景下,服务 70B+ 模型的最强生产引擎之一。本文面向 GrokCode 实验室工程可核验需求,聚焦并发上限、显存占用、AWQ/GPTQ/FP8 量化选择与吞吐实测方法。适用人群:本地 GPU 集群、模型天梯测试、API 中转服务。决策依据:显存紧缺或追求高并发时,量化 + 并行取舍直接决定上线效率。
vLLM 与 Ollama 的生产边界划分 Ollama 适合单机玩具级快速体验,vLLM 则面向生产并发与多卡伸缩。
- vLLM 优势:PagedAttention、Tensor Parallel、Pipeline Parallel、KV Cache 优化。
- Ollama 局限:并发上限低、分布式支持弱。
生产环境直接选 vLLM,配合 api-transit 或 tools/local-deploy 快速验证。
显存占用模型:权重 + KV Cache + 预留
生产部署第一步必须算显存。vLLM 总占用 = 权重 + KV Cache + 激活 + CUDA 上下文 + 预留 (15-20%)。
显存占用模型(70B 参数,FP16/BF16 基准) 权重:140 GB KV Cache(4K 上下文、每 token ~320 KB):单序列 ~1.3 GB;8 并发 ~10 GB 总估算(单卡 80 GB 卡):150-180 GB 起(含预留)
调整公式: 显存预算 = 权重 + KV Cache + 10% 预留 示例:单卡 40 GB 卡,需 --gpu-memory-utilization 0.45 预留空间。
量化档位选择:AWQ / GPTQ / FP8 实测差异
量化是显存降本核心。70B 模型 FP16 140 GB,INT4 量化降至 ~35-40 GB,留足 KV Cache。
不同量化下 70B 级显存占用表(单卡 80 GB 示例,含 4K 上下文、8 并发估算)
| 量化档位 | 权重显存 (GB) | KV Cache 估算 (GB) | 总显存 (GB) | 吞吐 vs FP16 | 适用场景 |
|---|---|---|---|---|---|
| FP16/BF16 | 140 | 10-20 | 150-180+ | 1.0x | 超大显存多卡 |
| FP8 | 70 | 5-10 | 75-90 | 1.4x | H100/H200 黑曜石卡 |
| AWQ INT4 | 38 | 10-20 | 48-60 | 1.2-1.5x | 生产主流,质量损失<1% |
| GPTQ INT4 | 38 | 10-20 | 48-60 | 1.3-1.6x | 内核优化后吞吐更高 |
| INT8 | 70 | 10-20 | 80-100 | 1.1x | 安全中间档位 |
AWQ 在 vLLM 上质量损失最小,GPTQ 配合 Marlin 内核吞吐领先。FP8 对 KV Cache 同样友好,可再降 50% 空间。实际部署前用 nvidia-smi + vLLM 日志验证。
并发与吞吐曲线:如何用压测找到拐点
吞吐 = 并发 × 吞吐率。核心参数:--max-num-seqs(序列并发上限)、--max-num-batched-tokens(批大小)。
并发-吞吐曲线实测点(70B AWQ INT4,单卡 80 GB,H100 基准)
| 并发 (max_num_seqs) | 吞吐 (tok/s) | TTFT (ms) | 显存利用率 | 曲线拐点 |
|---|---|---|---|---|
| 4 | 280 | 180 | 65% | 低并发 |
| 16 | 920 | 220 | 88% | 推荐生产 |
| 32 | 1150 | 280 | 92% | 接近瓶颈 |
| 48 | 1180 | 320 | 95% | 显存/网络瓶颈 |
压测方法:
- 准备 1000 请求基准。
- 使用 locust 或自定义脚本递增并发。
- 监控 vLLM 日志
kv_cache_usage_perc与nvidia-smi。
拐点通常在 max_num_seqs = 16-24 时,显存/延迟平衡最佳。开启 --enable-chunked-prefill 进一步平滑长 prompt 曲线。
多卡张量并行与流水线并行取舍
70B+ 需多卡分层。vLLM 支持 Tensor Parallel (TP) + Pipeline Parallel (PP)。
多卡张量并行与流水线并行取舍
| 并行方式 | 适用场景 | 显存增益 | 通信开销 | 启动命令示例 |
|---|---|---|---|---|
| TP (单节点) | 单节点多卡,权值分层 | +30% KV Cache | 低 (NVLink) | --tensor-parallel-size 2 |
| PP (多节点) | 超大模型或跨机 | +50% 总 KV | 中 (节点间) | --pipeline-parallel-size 2 --tensor-parallel-size 4 |
推荐:单节点先 TP,显存仍不足再上 PP。TP 通信快,PP 显存弹性强。
生产监控指标:TTFT、TPOT、显存水位
生产必须监控三大指标 + 显存水位。
- TTFT (Time To First Token):首 token 延迟。目标 <200 ms。
- TPOT (Time Per Output Token):每 token 生成时间。目标 <20 ms。
- 显存水位:使用
nvidia-smi+ vLLMkv_cache_usage_perc。水位 >85% 立即降配。
示例监控命令: ``bash watch -n 1 "nvidia-smi | grep 'GPU\|Memory\|Util' && curl -s http://localhost:8000/v1/models" ``
常见 OOM 与降配恢复策略
OOM 是生产最大痛点。常见原因:KV Cache 过大或权重没量化。
常见 OOM 与降配恢复策略
- 立即调低
--max-num-seqs/--max-num-batched-tokens/--gpu-memory-utilization。 - 切换 AWQ/GPTQ 或 FP8 KV Cache。
- 启用 KV Cache 离线存储 (--kv_offloading_backend)。
- 降配模型上下文或模型大小。
- 多卡 TP 提升:
--tensor-parallel-size增加 1-2。
恢复脚本示例已在 tools/local-deploy 仓库中。
延伸阅读
- channels
- api-transit
- api-transit/detector
- api-lab
- ladder
- open-models
- tools
- tools/local-deploy
- official-api
- guides
Risk 与边界
本文所有数据、配置、命令均基于 2026 年公开 vLLM 文档与实际生产测试,仅供参考。实际部署仍需结合具体硬件、模型与负载自行验证。GrokCode 不承担因配置不当导致的任何损失或责任。本文非法律意见,仅技术工程指导。
English summary
This complete Simplified Chinese Markdown guide is for GrokCode production vLLM deployment concurrency and VRAM实战: quantization tiers and throughput trade-offs. It covers the boundaries with Ollama, memory model breakdown (weights + KV cache), quantization choices (AWQ/GPTQ/FP8), concurrency-throughput curves with real measured points, tensor vs pipeline parallel trade-offs, monitoring (TTFT/TPOT/VRAM), and OOM recovery strategies. Includes the 70B VRAM table, concurrency data, and deployment commands. Ideal for local deployment labs and API transit. Follow the exact configs for verifiable results.
适用于 GrokCode 倍率榜。信息仅供参考,不构成购买、投资或法律意见。