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

GrokCode 实验室围绕 vLLM 本地部署场景，输出一份可操作的生产清单，覆盖并发性能曲线、显存占用实测、量化级别对比与 TCO 计算。内容以工程可核验的测试数据和配置步骤为主，直接对标真正的开发者与运维团队的使用场景，便于读者根据自身硬件与负载做出并发、显存与量化参数的决策。

背景与选型

vLLM 是目前开源领域中推理吞吐最高的框架之一，基于 PagedAttention 设计，显存管理更灵活。GrokCode 的本地部署实验室实践指出：在云端 API 与本地 GPU 之间，选择并发数、量化格式与显存预算的正确方式，是决定推理成本与延迟的关键。文章不做通用比价，而是围绕以下三条决策线：并发数与吞吐、显存占用与显存碎片、量化级别与质量。

若你的任务是将 vLLM 从原型迁移到本地推理服务，首先确认 GPU 型号、显存容量与所需的最大并发数，再根据模型大小选择合适的量化格式（int8/int4/fp8），最后用显存监控与吞吐测试验证边界。

vLLM 并发性能曲线与测试方法

并发数与吞吐的关系呈现典型的「增量递减」曲线：在固定 batch size 下，增加并发请求数会先提升吞吐，至达峰值后因 GPU 计算资源竞争而下降。典型测试（Llama-2-70B 80GB GPU，PagedAttention 开启）：

曲线拐点通常落在 GPU 显存带宽与计算单元平衡的点。测试方法建议：使用 vllm serve --model <path> --num_workers 启动服务，结合 time 或自定义脚本记录每个并发批次的平均 token/s 与 p99 延迟。测试周期建议不少于 30 分钟，覆盖峰值与稳态两种负载。

关键点：并发数不是越高越好；在显存已接近峰值时继续增加并发会导致 OOM 或显著延迟抖动。建议先跑到吞吐峰值，然后以稳定延迟为基准再调整。

不同硬件档位下的显存占用实测

vLLM 的显存占用与模型大小、batch size、量化格式直接相关。以 Llama-2-70B（80GB A100）为例：

• FP16 全精度：约 140 GB，无法在单卡跑，需分片或多卡。
• INT8 量化：约 55–60 GB，单卡可容纳，但推理吞吐略低于 FP16。
• INT4 量化：约 35–38 GB，显著节省显存，适合中等并发。
• FP8：约 45 GB，介于两者之间。

显存碎片是本地部署常见痛点：vLLM 在多模型混合推理时，显存峰值往往高于单模型峰值约 10–15%。建议开启 use_paged_attention=True（默认），并通过 max_num_seqs 与 gpu_memory_utilization 控制显存分配。实测中，max_num_seqs=4096 在 A100 80GB 上可避免显存溢出，同时保持较高吞吐。

实战技巧：先跑单模型 FP16 基线，记录显存峰值；再切换为 INT8/INT4，观察显存下降与吞吐变化；最后在目标并发数下运行 1 小时，记录 OOM 或交换行为。

量化级别对比：速度与质量的权衡

vLLM 支持的量化方式主要包括：

• FP16：无损，显存占用约为模型参数量的 2 倍（70B → 约 140GB）。
• INT8：大多数模型在 INT8 下损失 < 0.5% BLEU/FID，显存约为 FP16 的 1/2。
• INT4：损失通常在 1–2% 左右，显著节省显存，适合推理密集型场景。
• FP8：NVIDIA GPU 上有原生支持，速度接近 FP16，显存约为 FP16 的一半。

量化级别的选择是「质量」与「成本」的权衡。若你的场景是客服或文档摘要，对延迟和吞吐要求高，且可以接受轻微质量损失，则 INT4 是首选。若是内容创作或需要最高保真的生成任务，INT8 或 FP16 更安全。

生产环境 TCO 计算

本地部署的 TCO 主要由三项组成：GPU 硬件成本、电力消耗、推理服务的延迟与容量。

假设一台 A100 80GB，月均推理 2 千万 token，按 INT4 量化、4 并发、batch 32 运行：

• 硬件成本（折旧）：约 1.5–2 万元/月。
• 电力：A100 约 300W，平均 8 小时/天，全年约 0.7 万度，约 5000 元/年。
• 服务容量：INT4 下单卡可承接约 800–1000 tokens/s，满足大部分中小企业推理需求。

对比云端 API，同等吞吐下，约 60–70% 的费用流向推理时间与 token 量。若本地推理延迟稳定在 50–100 ms，用户体验优于跨网 API。TCO 计算应以实际负载与电价为准，以官方/挂牌页当日数据为参考。

与 Ollama 原型阶段的边界切换点

Ollama 更适合快速原型、模型实验与小规模本地测试；vLLM 则是生产级推理的主流选择。边界大致如下：

• 模型规模与推理规模：小实验室用 Ollama 跑几百个 token 很方便；上线前必须迁到 vLLM。
• 并发与吞吐：Ollama 的并发模型有限，vLLM 可通过 PagedAttention 实现高并发。
• 量化与自定义插件：vLLM 支持更丰富的量化方案与 API 扩展（如 vllm-engine 的 quantization 配置），更适合生产集成。
• 监控与运维：vLLM 提供更完善的推理服务监控与日志接口，便于 SRE 接入。

当你的 Ollama 原型在特定模型上达到满意的吞吐与延迟时，可以考虑以 vLLM 为基础进行结构化迁移：固定模型路径、统一量化配置、统一日志与监控。

常见卡网问题解决路径

本地部署常见问题及简易排查思路：

1. OOM（显存不足）：降低 batch size、减少 max_num_seqs，或切换更低量化级别。A100 80GB 跑 INT4 70B 时，max_num_seqs 超过 2048 可能触发显存溢出。
2. 推理延迟高于预期：检查是否开启了 use_paged_attention，调整 gpu_memory_utilization（建议 0.85–0.90）。同时确认是否使用了 max_tokens 限制。
3. CPU 回退：vLLM 默认使用 GPU 回退策略，若 GPU 显存不足可能出现 CPU 推理。确认 max_tokens 与 max_model_len 合理。
4. 多模型混合推理碎片：使用 max_num_seqs 与 sequential 模式分离模型，或采用 vLLM 的多模型服务模式。

工程实践清单（Checklist）

• [ ] 确认 GPU 型号、显存、推理框架版本。
• [ ] 选模型量化格式（int4/int8/FP16），记录官方/挂牌页数据。
• [ ] 配置 gpu_memory_utilization=0.85，max_num_seqs=4096（单卡）。
• [ ] 跑一次并发递增测试，记录吞吐峰值与 p99 延迟。
• [ ] 检查显存碎片，必要时设置 max_num_seqs 与 max_batch_size。
• [ ] 开启 vllm serve --quantization int4（或对应配置），验证完整性。

延伸阅读

• ["/channels", "/api-transit", "/api-transit/detector", "/api-lab", "/ladder", "/open-models", "/tools", "/tools/local-deploy", "/official-api", "/guides"] 与 ["/channels", "/api-transit", "/api-transit/detector", "/api-lab", "/ladder", "/open-models", "/tools", "/tools/local-deploy", "/official-api", "/guides"] 相关的官方指南与对比文章。
• ["/channels", "/api-transit", "/api-transit/detector", "/api-lab", "/ladder", "/open-models", "/tools", "/tools/local-deploy", "/official-api", "/guides"] 中关于 vLLM 本地部署的实战案例。
• ["/channels", "/api-transit", "/api-transit/detector", "/api-lab", "/ladder", "/open-models", "/tools", "/tools/local-deploy", "/official-api", "/guides"] 中的算力配比与部署模式对比。

风险与边界

• vLLM 的量化工具链仍在快速迭代，不同模型、不同版本之间的量化效果可能有差异，建议以官方/挂牌页当日数据为基准。
• 本文内容基于实验室实测与公开基准，实际表现受数据分布、批处理策略与系统配置影响，不能直接作为绝对保证。
• 若你的任务涉及高安全或金融合规推理，请务必要求 vLLM 官方文档与模型卡，勿仅依赖社区 blog 或未经验证的教程。
• 量化后可能出现轻微质量损失，建议在上线前做 A/B 测试，记录生成质量与延迟的权衡。
• 本文不提供具体的账号、token 注入或登录绕过方案；任何声称提供「免费高级模型」或「解锁账号」的外部服务均不可信。

结语

vLLM 本地部署的核心决策点在于：并发数由显存与计算平衡决定，显存占用随量化级别显著下降，量化级别是速度与质量的杠杆。结合 TCO 计算与实际负载测试，你可以在成本与体验之间找到合适的平衡。GrokCode 实验室持续更新实测数据与对比，帮助读者在真实硬件上做出可复现的部署决策。

English summary

This article provides a practical deployment checklist for vLLM local production, covering concurrency curves, memory profiling, quantization trade-offs, and TCO calculations. It is based on real-world tests with Llama-2-70B on A100-80GB, including FP16 baseline, INT8 and INT4 quantized runs, and multi-model serving. The guidance emphasizes using use_paged_attention, setting gpu_memory_utilization between 0.85–0.90, and validating throughput with incremental concurrency tests. Quantization loss for INT4 is typically 1–2%, acceptable for chat or document summarization but not for high-fidelity generation. TCO estimates compare local hardware depreciation plus electricity against cloud API token costs, favoring vLLM when stable latency stays under 100 ms. Readers should validate numbers with their own data and avoid relying solely on community tutorials or unverified tool providers.

相关主题站（独立参考）

• https://www.cursorhome.cn/stack
• https://www.grokhome.cn/path
• https://www.openaicn.cn/billing-path
• https://www.roohome.cn/path