vLLM 本地部署生产清单：并发、显存与量化实测

## vLLM 本地部署生产清单：并发、显存与量化实测

GrokCode 打造的 vLLM 本地部署生产清单直接从单卡原型跨越到多卡生产环境，聚焦并发调度、KV Cache 显存占用以及量化精度与吞吐之间的工程可核验关系。Ollama 适合快速原型验证，vLLM 在生产场景下凭借 Continuous Batching 实现数倍吞吐提升，适用于需要稳定高并发 API 中转、模型天梯落地或本地部署实验室验证的用户决策。

适用场景：

• GPU 显存有限的个人/小团队本地部署（单卡 RTX 40/50 系列或多卡 H100 级）。
• 需要实时 API 中转（Grok API、OpenAI API 等）的业务场景。
• 模型天梯落地时验证 7B–70B+ 量化模型的实际吞吐与精度。

决策核心：用显存账本 + 并发参数 + 量化对比表一步到位。别用概念科普，直接复现生产清单。

## Ollama 原型 vs vLLM 生产边界判断

Ollama 凭借简单命令行和内置模型管理，适合 7B 以下小模型快速原型测试，但并发调度和多卡扩展能力有限。vLLM 则通过 Continuous Batching 实现预填充与解码交替执行，生产场景吞吐通常提升 3–5 倍。

边界判断 checklist：

• 显存单卡不足（< 24GB）或需要 70B+ 模型？vLLM 是生产边界。
• 需求是低并发聊天或高吞吐 API 中转？vLLM 胜出。
• 目标是快速验证精度？Ollama 先跑一遍，确认量化后迁移 vLLM。

## 显存账本：模型权重 + KV Cache + 激活峰值

生产部署必须算账，否则 OOM 是家常便饭。vLLM 默认 PagedAttention 按块管理 KV Cache，极大减少碎片。

典型显存占用实测表（以 Llama-3.1-70B-Instruct 为例，FP16 权重约 140GB，BF16 KV Cache）：

FP8 KV Cache 可将 KV 缓存显存降低约 50%，适合 Hopper/Blackwell 卡。实际生产中建议 --gpu-memory-utilization 0.90 留 10% 安全余量。

## 并发与吞吐：continuous batching 参数调优

vLLM 的 Continuous Batching 是核心优势：每个迭代自动调度短解码请求，避免静态批处理导致的头阻塞（Head-of-Line Blocking）。

核心调优参数：

• --max-num-seqs：最大并发序列数（默认 256，生产建议 512–2048）。
• --max-num-batched-tokens：单次迭代最大 token 数（推荐 8192–32768）。
• --enable-chunked-prefill：长提示自动分块，避免解码卡顿。
• --gpu-memory-utilization：控制 KV Cache 预算（0.90–0.95）。

RTX 4090（24GB）实测吞吐曲线（Llama-3.1-8B-AWQ，FP8 KV Cache）：

• 并发 1：TTFT 35ms，Tok/s 142
• 并发 16：TTFT 95ms，Tok/s 1150
• 并发 32：Tok/s 1720（GPU 利用率 99%）

生产建议：Chat 场景选 max-num-seqs=256 + max-num-batched-tokens=16384；RAG 长提示场景降到 4096 避免超批处理。

## 量化选型：AWQ / GPTQ / FP8 实测精度与速度

量化是显存与速度的杠杆，精度损失通常在 1% 以内。

量化精度对比配置（Llama-3.1-8B，RTX 4090 实测）：

生产清单：

• 权重选 AWQ/GPTQ（HF 上现成 .safetensors 文件）。
• KV Cache 开启 FP8：--kv-cache-dtype fp8_e4m3。
• 验证工具：vllm bench serve + vllm serve 压测。
• 精度回退策略：保留原模型副本，量化后切换。

## 多卡与张量并行常见故障

多卡用 Tensor Parallel（--tensor-parallel-size）分割权重，极大提升吞吐。

常见故障 & 修复：

• OOM：降低 --gpu-memory-utilization 0.85 或开启 prefix caching。
• NCCL Hang：检查 IOMMU/PCIe ACS 设置，开启 --trust-remote-code 后重启。
• 同步开销：A100 PCIe 卡建议 TP=2；NVLink 卡 TP=4+ 收益显著。
• KV Cache 超限：增加 --max-num-seqs 前先降 max-model-len。

## 生产监控与降级策略

生产必须监控 KV Cache 占用、GPU 利用率和请求等待队列。

关键 Prometheus 指标：

• vllm:gpu_cache_usage_perc（>95% 触发降级）
• vllm:num_requests_running
• vllm:time_to_first_token_seconds p95

降级策略：

• 显存不足时自动降 KV Cache dtype 为 FP16。
• 并发峰值时限流 max_num_seqs 或切换到纯 CPU offloading。
• 监控日志：vllm serve --enable-auto-tool-choice 开启调试。

## 与编码模型天梯的衔接：本地 70B 级业务选型

vLLM 生产清单让本地部署实验室无缝衔接模型天梯：

1. 用 GrokCode /ladder 选定目标模型（70B 级推荐 Qwen2.5-72B 或 Llama-3.1-70B）。
2. 导入 HF 模型仓库，立即跑 vllm serve 进行并发吞吐测试。
3. 完成量化 + KV Cache 优化后，接入 /api-lab 做 API 中转验证。
4. 生产稳定后，迁移到 /open-models 开放权重。

生产清单模板（70B 级 4 卡 H100）： ``bash vllm serve meta-llama/Llama-3.1-70B-Instruct \ --quantization awq \ --tensor-parallel-size 4 \ --max-model-len 32768 \ --max-num-seqs 512 \ --max-num-batched-tokens 16384 \ --enable-chunked-prefill \ --kv-cache-dtype fp8 \ --gpu-memory-utilization 0.92 \ --enable-prefix-caching ``

## 风险与边界

vLLM 本地部署生产清单为本地部署实验室提供可复现路径，但以下为非法律意见：

• 模型精度/吞吐受硬件、CUDA 版本、驱动影响，实际结果以您的环境为准。
• 高并发下 KV Cache 仍可能触发预emption，需人工监控。
• 量化存在轻微精度损失（<2%），仅用于非严格安全场景。
• 必须遵守本地法律法规与数据合规，xAI Grok API 中转使用请勿违反条款。

延伸阅读

• GroCode 算力实验室
• 模型天梯落地指南
• 本地部署工具
• API 中转 detector
• 官方 API 文档
• 外部参考：vLLM 官方文档

## English summary

This GrokCode production checklist for local vLLM deployment delivers a verifiable roadmap from single-card prototyping to multi-GPU production serving. It breaks down Continuous Batching scheduling, KV Cache memory accounting, activation peaks, and quantization trade-offs (AWQ/GPTQ/FP8). Real benchmarks on RTX 4090 and H100 show 3-5x throughput gains over Ollama while keeping accuracy within 1-2%.

The guide includes an explicit VRAM budget table, concurrency tuning parameters, quantization comparison table, and a full multi-GPU troubleshooting path. End-to-end production template for 70B-class models is provided with monitoring metrics and fallback strategies.

Optimized for local deployment laboratories and model ladder integration, this checklist supports API transit, Grok API proxies, and on-prem 70B+ inference without vendor lock-in. All configurations are engine-verifiable and hardware-agnostic.