vLLM 本地部署生产清单：并发、显存占用与量化选型

vLLM 本地部署生产清单：并发、显存占用与量化选型

在 GrokCode 实验室的算力护城河中，vLLM 是从单卡原型到多卡生产的首选生产级引擎。它通过 continuous batching（连续批处理）和 PagedAttention（分页注意力）实现 GPU 利用率从 30-40% 到 80%+ 的跃升，特别适合需要高吞吐和低首 token 延迟的生产场景。Ollama 更适合开发者本地测试，而 vLLM 专为并发请求优化，适用于 API 中转、模型天梯验证和本地部署场景。

如果你已有单卡 GPU（如 RTX 4090 或 H100）和明确的生产负载需求（>20 并发请求或需稳定服务 SLA），vLLM 就是决策起点。决策公式很简单：先用 vllm bench 压测确认你的硬件能扛住预期 QPS，再决定量化级别和并行配置。本文提供可复现的检查表、调参清单和边界控制，帮助你从原型直达生产监控。

vLLM 与 Ollama 的定位边界：何时必须上生产级引擎

边界判断方法：在你的机器上跑 vllm bench serve --model meta-llama/Meta-Llama-3.1-8B-Instruct --max-concurrency 32（推荐用 ShareGPT 数据集）。如果 Ollama 的每秒 tokens（tok/s）在 8 并发时已 <100，立即切换到 vLLM。它在生产环境中可达 2-3 倍吞吐，同时保留 OpenAI 兼容 API 接口。

显存估算公式与常见量化（AWQ/GPTQ/FP8）实测对比

vLLM 显存占用主要由模型权重 + KV cache 组成。核心公式（单卡基准，含框架开销）：

显存 (GB) ≈ 模型参数量 (B) × 量化比特 (bits) / 1024 + KV cache (GB) + 1.5（框架/激活开销）

KV cache 计算方式：max_model_len × max_num_seqs × (bytes per token) × 2（K+V）。建议 gpu-memory-utilization 设置为 0.90-0.95，留出 5-10% 缓冲。

常见量化实测对比（基于 H100 80GB 平台，Llama-3.3-70B 参考 2026 基准）：

实测要点：

• FP8 是 Hopper/Blackwell 默认首选：KV cache 容量接近 2 倍 FP16，同时吞吐基本持平。
• AWQ/GPTQ 在单卡紧缺时最优：AWQ 质量损失更低，GPTQ 预量化模型加载更快。
• 所有格式均支持 vLLM 原生，推荐用 vllm serve 直接加载 model 仓库（如 meta-llama/Llama-3.1-8B-Instruct-awq）。
• 实际占用以启动日志 GPU KV cache size 为准，每天挂牌模型页数据可复核。

continuous batching、max_num_seqs 与 GPU 利用率调参

continuous batching 是 vLLM 核心优势：请求到达时动态加入批次，而非等待满 batch。默认开启，无需额外 flag。

关键参数（CLI 或 Python API）：

• --max-num-seqs：最大并发序列数（默认 1024，推荐交互场景 256-512）。
• --max-num-batched-tokens：单步最大 token 预算（默认动态，推荐 8192-16384）。
• --enable-chunked-prefill：长 prompt 分片处理，默认开启，提升 TTFT。
• --gpu-memory-utilization：0.90-0.95，控制 KV cache 池大小。

调参原则：

1. 优先提升 max-num-seqs（不超显存）。
2. 保持 max-num-batched-tokens > max-model-len（开启 chunked prefill 时）。
3. 监控 Prometheus：vllm:gpu_cache_usage_perc < 80% 为健康；>90% 则降低 max-num-seqs 或加卡。

示例生产配置（H100 4 卡 Llama-3.3-70B FP8）： `` vllm serve meta-llama/Llama-3.3-70B-Instruct \ --tensor-parallel-size 4 \ --quantization fp8 \ --max-num-seqs 2048 \ --max-num-batched-tokens 16384 \ --enable-chunked-prefill \ --gpu-memory-utilization 0.95 ``

多卡 tensor parallel / pipeline parallel 的配置与故障排查

单卡无法满足 70B+ 模型时，vLLM 原生支持分布式推理：

• Tensor Parallel (TP)：单节点多卡，推荐 tensor_parallel_size=4（NVLink 集群最佳）。
• Pipeline Parallel (PP)：跨节点或深层模型，pipeline_parallel_size=2 + TP=8。
• MoE 模型：额外启用 Expert Parallel。

配置示例（两节点 8 卡）： `` vllm serve ... \ --tensor-parallel-size 8 \ --pipeline-parallel-size 2 \ --distributed-executor-backend ray ``

故障排查清单：

• 启动失败 OOM：降低 --gpu-memory-utilization 或减少 max_model_len。
• 通信慢（无 NVLink）：切换到 PP，或检查 NCCL 环境变量 NCCL_IB_HCA。
• 负载不均：监控 Prometheus vllm:num_requests_running，调整调度步数 --num-scheduler-steps。
• 多节点：确保每卡 ipc=host 和 /dev/shm 挂载，验证 Ray 状态。

压测脚本：并发、首 token 延迟、吞吐与 OOM 边界

GrokCode 实验室推荐的标准化压测脚本（Python + asyncio）：

```python import asyncio import aiohttp import json import time

async def main(): url = "http://localhost:8000/v1/chat/completions" headers = {"Content-Type": "application/json"} data = { "model": "your-model", "messages": [{"role": "user", "content": "你好，请生成一段 200 token 的技术文档"}], "max_tokens": 200, "temperature": 0.7 } async with aiohttp.ClientSession() as session: tasks = [] for i in range(1, 33): # 1~32 并发 tasks.append(asyncio.create_task(session.post(url, headers=headers, json=data))) start = time.time() results = await asyncio.gather(*tasks) end = time.time() print(f"32 并发完成，耗时 {end-start:.2f}s") # 解析 latency 等指标 ```

使用 vllm bench serve 官方工具复现 ShareGPT 负载，统计：

• 首 token 延迟 (TTFT)
• 吞吐 (tokens/s)
• OOM 临界：监控日志 GPU KV cache size 达到上限时立即降级。

生产环境建议加 Prometheus 采集，报警阈值：TTFT p95 > 500ms 或 KV 使用率 > 85%。

生产监控：显存碎片、请求排队与自动降级策略

vLLM 原生 Prometheus 指标（暴露 /metrics）：

• vllm:kv_cache_usage_perc：显存碎片直接预警
• vllm:num_requests_waiting：排队深度
• vllm:time_to_first_token_seconds：TTFT 直方图

自动降级策略（生产必备）：

1. 显存 >90%：自动降低 max_num_seqs 或 reject 新请求。
2. 排队 >10s：触发 fallback 到更小模型或 CPU 后端。
3. 自定义：用 Prometheus + Alertmanager + GrokCode 模型天梯监控面板。

建议每 15 分钟跑一次 vllm bench 对比 baseline，记录在 /tools/local-deploy 对应页面。

风险与边界

vLLM 在生产环境中极度可靠，但仍存在以下边界（非法律意见，仅供参考）：

• KV cache 碎片在极端并发下可能导致局部 OOM（需正确设置 gpu-memory-utilization）。
• 量化后质量损失（AWQ/GPTQ <2%）在高要求场景需人工验证。
• 多节点 Ray 集群故障恢复需额外监控。
• 所有数据以官方 vLLM 最新版本及你硬件的 2026 年 8 月挂牌参数为准。

延伸阅读

• vLLM 官方量化支持文档
• API 中转与 vLLM 集成边界
• 模型天梯量化选型清单
• 本地部署实验室快速上手
• vLLM Prometheus 监控指南
• OpenAI 兼容 API 生产规范
• 多卡分布式配置详解

English summary vLLM production checklist for local LLM serving covers concurrency, VRAM estimation, quantization trade-offs (AWQ/GPTQ/FP8), continuous batching tuning with max_num_seqs and max_num_batched_tokens, tensor/pipeline parallel scaling, repeatable benchmarking scripts for TTFT/throughput/OOM boundaries, and Prometheus-based monitoring for auto-scaling. Ideal for production where Ollama plateaus under load. Use official docs and vllm bench for daily validation; all numbers current as of August 2026 vLLM releases.