算力

vLLM 本地部署生产清单:70B 级并发、显存与量化实测思路

从原型到生产的 vLLM 部署检查表,聚焦 70B 级模型在常见卡型上的显存占用、并发吞吐、量化方案与成本账,给出可复现的测量步骤而非泛泛推荐。

正文為 SEO 深度以中文為主;上方要點已本地化。可用語言切換與深鏈進行全球導航。

vLLM 本地部署生产清单:70B 级并发、显存与量化实测思路

这是一份面向工程落地的 vLLM 生产检查表,帮助判断何时从 Ollama 原型切到 vLLM,以及如何在常见卡型上量化 70B 级模型的显存、并发与成本。适用于已跑通单机推理、准备承担真实并发与可观测性的团队。决策路径是:先固定显存基线与量化档位,再做可复现的吞吐曲线,最后用卡时与电费粗算 TCO。

GrokCode 实验室将本地部署与算力账视为核心护城河,强调可核验测量而非泛泛推荐。下文给出可直接复制的步骤与对照表。

Ollama 原型与 vLLM 生产边界判断

Ollama 适合快速验证模型可用性与提示词效果,默认配置偏单用户、低并发。当出现以下任一信号时,应切换到 vLLM:

  • 并发请求 > 4–8 且延迟抖动明显
  • 需要 continuous batching、前缀缓存或 OpenAI 兼容的稳定 API
  • 要做显存精确控制、多卡 tensor parallel 或生产级监控

边界判断口诀:原型用 Ollama 验证“能不能跑”,生产用 vLLM 验证“能跑多快、多稳、多省”。

70B 级显存基线与量化档位对照

70B 级模型(如 Llama-3-70B、Qwen2-72B 等)在 FP16/BF16 下权重约 140 GB,加上 KV cache 与激活,单卡几乎无法承载。生产常用量化档位与粗略显存占用如下(仅权重 + 基础开销,实际需叠加序列长度与 batch):

量化档位权重显存粗估常见适用卡型精度与吞吐权衡
FP16/BF16~140 GB多卡 H100/A100最高精度,吞吐低
FP8~70–80 GB2×A100 80G 或 H100接近无损,吞吐提升
AWQ/GPTQ 4-bit~35–40 GB单卡 48G 或 2×24G精度可接受,高并发友好
3-bit 激进量化~28–32 GB单卡 32–40G需严格抽样验证

实测思路:用 nvidia-smi 与 vLLM 的 --gpu-memory-utilization 固定利用率(建议 0.85–0.92),记录空载与满载显存差,画出“显存占用曲线”。量化后必须做精度抽样:固定 50–100 条代表性 prompt,对比原始与量化输出的一致性(token 级或人工评分)。

相关工具与本地部署入口可参考站内 本地部署工具页开放模型

并发、批大小与吞吐的实测方法

可复现测量步骤(建议写进脚本):

  1. 固定模型路径、量化权重、最大序列长度(如 4096 或 8192)。
  2. 使用 vLLM 的 OpenAI 兼容接口,发送并发请求(可用 locust 或简单 asyncio 脚本)。
  3. 记录 tokens/s(output tokens)、TTFT、TPOT、以及 GPU 利用率。
  4. 变化参数:max_num_seqs(并发上限)、max_num_batched_tokenstensor_parallel_size
  5. 绘制 tokens/s 随并发数变化的曲线,找到拐点(通常在显存或计算饱和处)。

关键原则:吞吐不是越高越好,需同时看延迟尾部(P95/P99)。70B 级在 4-bit 下单卡 48G 常见有效并发 8–32,取决于序列长度。

连续批处理与前缀缓存的开启条件

vLLM 默认开启 continuous batching。生产中建议显式确认:

  • 开启条件:请求到达率高、序列长度差异大时收益最明显。
  • 前缀缓存(prefix caching):多轮对话或共享系统提示时开启,可显著降低重复 prefill 成本。开启前确认 vLLM 版本支持,并监控缓存命中率。

关闭场景:极低并发或调试阶段,避免缓存带来的状态干扰。

电费、卡时与 TCO 粗算框架

粗算公式(可直接用表格记录):

  • 卡时成本 = 单卡小时价格 × 卡数 × 运行小时
  • 电费 = 平均功耗(kW)× 电价 × 小时
  • 单 token 成本 ≈(卡时 + 电费)/ 总 output tokens

示例框架:假设 2×A100,功耗约 0.6–0.8 kW,电价 0.8 元/kWh,卡时按云或自建折旧。记录一周真实流量后回填,得到可对比的 TCO。GrokCode 强调把本地部署账与中转 API 成本对照,避免只看单次 tokens/s。

更多算力与模型对比见 模型天梯API 中转

监控指标与常见 OOM / 降速排查

必备指标:

  • GPU 显存利用率与碎片
  • tokens/s、请求队列长度
  • TTFT / TPOT 分布
  • 前缀缓存命中率

常见问题快速定位:

  • OOM:降低 gpu_memory_utilization、减小 max_num_seqs 或序列长度,检查是否有未释放的 KV cache。
  • 吞吐突然下降:检查是否触发了 swap 或 CPU offload;确认是否有大量长序列挤占 batch。
  • 延迟抖动:开启 continuous batching 后仍抖动,优先看调度队列与网络。

监控可与站内 工具集实验室 结合使用。

从单机到多卡的最小扩展路径

  1. 单卡跑通 4-bit 或 FP8,确认精度与基本吞吐。
  2. 增加 tensor_parallel_size=2,验证通信开销可接受(同机 NVLink 优先)。
  3. 再扩展到 4 卡,观察 scaling 效率(通常 < 线性)。
  4. 需要更高吞吐时再考虑 pipeline parallel 或外部调度。

最小路径原则:先垂直(量化 + 单机优化),再水平(多卡),最后才引入复杂编排。

风险与边界

本文仅为工程实践清单与测量思路,不构成任何硬件、软件或商业采购建议。显存与吞吐数据会随模型版本、vLLM 版本、驱动与具体卡型变化,必须以本机实测为准。量化可能带来精度损失,生产前必须完成业务相关抽样验证。电费与卡时粗算仅供内部对比,实际 TCO 需纳入折旧、维护与人力成本。本文不涉及任何攻击、绕过或未授权使用场景。以上内容为技术分享,非法律意见。

延伸阅读

English summary

This guide provides a production checklist for deploying 70B-class models with vLLM, focusing on measurable memory footprints, concurrency throughput, quantization trade-offs, and rough TCO. It helps teams decide when to move from Ollama prototypes to vLLM, how to baseline VRAM across quantization levels, and how to run reproducible tokens/s curves. Continuous batching and prefix caching conditions are outlined, along with a simple power and card-hour cost framework. Monitoring signals and common OOM or slowdown diagnostics are included, plus a minimal single-to-multi-GPU expansion path. All recommendations emphasize verifiable measurements aligned with GrokCode’s focus on local deployment labs and compute accounting.

适用于 GrokCode 倍率榜。信息仅供参考,不构成购买、投资或法律意见。