vLLM 量化可以让模型占用更少的 GPU 内存，但它并非通用的提速开关。更小的检查点可能为 KV 缓存和并发请求留出更多空间。实际吞吐量取决于模型、量化格式、GPU 架构、内核、提示词长度、输出长度和流量模式。合理的做法是选择受支持的格式，然后针对具有代表性的工作负载，与未量化基线进行测量对比。
本 vLLM 量化指南为您提供实用的选择和测试流程。我们不会对未经测试的 GPU 或模型声称任何基准测试结果。
vLLM 量化会改变什么
量化会以比典型 FP16 或 BF16 检查点更少的位数存储部分模型数值。最明显的一阶影响是降低权重内存。如果权重内存是模型无法装入的原因，兼容的量化检查点可能使其能够在更小的 GPU 上运行，或为请求留出更多内存。GPU 仍需要为激活值、KV 缓存、运行时开销和任何并行工作进程提供内存。因此，用参数数量除以每个权重的位数仅是一个粗略的下限，而非可部署的内存估算。
vLLM 量化有两种常见路径。您可以加载预先量化的检查点，或在加载时使用受支持的在线量化路径。在这两种情况下，选择格式前都应检查模型卡和当前的 vLLM 兼容性矩阵。vLLM 量化文档是量化方法和硬件支持的权威来源；其中明确警告，支持矩阵会随着支持能力的发展而变化。
根据检查点和 GPU 选择格式
| 选项 | 实用的起点 | 部署前验证 |
|---|---|---|
| AWQ | 以 AWQ 检查点形式发布的模型，以及兼容的 GPU | 模型质量、内核选择、提示词长度和实际延迟。 |
| GPTQ | 以 GPTQ 检查点形式发布的模型 | 确切的检查点配置、vLLM 版本、GPU 支持情况和质量回归。 |
| FP8 | 兼容的检查点，以及支持 FP8 执行的 GPU | 所选 vLLM 实现是否支持您的架构和模型层。 |
| GGUF | 已采用 GGUF 格式发布的模型 | 具体架构和 vLLM 功能支持；不要假定 Ollama 的行为可以一一对应。 |
| BitsAndBytes 或压缩张量 | 明确要求使用它们的检查点和部署路径 | 运行时依赖项、加载行为、受支持的内核和吞吐量。 |
当前 vLLM 矩阵列出了对 Ampere、Ada 和 Hopper 的 AWQ 与 GPTQ 支持。它列出了通过 llm-compressor 对 Ada、Hopper 和部分 AMD GPU 路径的 FP8 支持，而 GGUF 具有不同的支持模式。A100 是 Ampere GPU，H100 是 Hopper GPU，但支持是方法特定的。不要推断某个系列中的每张卡都支持所有 FP8、FP4 或 Marlin 变体。请查看硬件
兼容性表中的确切条目，以及检查点自身的元数据。
如果您尚未选择模型，请比较使用相同基础模型和评估集的两个候选检查点。将一个系列的 AWQ 模型与另一个系列的未量化模型进行比较，会将 vLLM 量化与模型质量混为一谈。
避免虚假收益的部署工作流程
- 定义服务目标。记录模型、上下文长度、预期输入和输出长度、并发请求数、p95 延迟目标以及质量测试。聊天机器人、批量分类器和长上下文智能体具有不同的瓶颈。
- 记录基线。在相同 GPU 和 vLLM 版本上运行未量化检查点。记录 GPU 峰值内存、首个 token 时间、输出 token 吞吐量、端到端 p50/p95 延迟、错误以及可接受结果率。
- 选择兼容的量化检查点。阅读其模型卡和 vLLM 当前的方法矩阵。在测试记录中固定检查点修订版本、vLLM 版本、CUDA/驱动程序栈和硬件 SKU。
- 从小规模金丝雀测试开始。在施加流量前，确认模型可以加载、能够提供您所需的端点和生成设置，并产生看似合理的输出。
- 在多个并发级别下进行基准测试。按实际的提示词和响应长度测量。单个请求可能偏向与持续服务不同的配置。
- 运行相同的质量测试套件。量化可能改变输出。不要只依赖困惑度，而应评估特定领域的正确性、格式遵循情况、拒答以及安全敏感案例。
- 计算每个可接受结果的成本。如果量化模型失败的任务更多或需要重试，仅用 GPU 每小时价格除以原始每秒 token 数是不够的。
对于服务基准测试，vLLM 在官方
基准测试 CLI 指南中记录了 vllm bench serve 及其数据集和端点选项。请使用与您的应用匹配的流量数据集；合成随机提示词对受控比较很有用，但不应被表述为生产环境性能。
内存规划：权重只是其中一个项目
一个简单的规划工作表将内存分为四类：
所需 GPU 总内存 ≈ 模型权重 + KV 缓存 + 运行时/激活开销 + 安全余量
量化格式主要改变模型权重这一项。KV 缓存压力会随上下文长度和活跃序列数量增加而增长。一个在单个请求下勉强能容纳的模型，在并发的长上下文流量下仍可能失败或显著变慢。在多 GPU 配置中，张量并行会同时改变每张卡的内存占用和通信开销；体积最小的检查点并不一定是成本最低的部署方案。
在租用 GPU 之前，请明确您是需要容纳一个更大的模型、提高较小模型的并发能力，还是在保持质量的同时降低成本。答案决定了哪种内存与吞吐量权衡最重要。Flatkey 的 Cloud GPU Compute 列出了 GPU 租用选项，并要求客户确认配置、区域、容量和租用条款。应将实时可用性和价格视为报价时的输入，而非基准测试文章中的固定数字。
公平地基准测试 vLLM 量化
保持基础模型、生成参数、提示词集合、输出限制、缓存状态和 GPU 不变。至少测量三种负载：用于响应能力的单个请求、具有代表性的生产并发量，以及延迟开始下降时的压力点。报告总吞吐量和 p95 延迟。如果您只报告饱和状态下的每秒 token 数，用户就无法判断交互式请求是否仍然可接受。
在评分卡中纳入模型质量：
| 指标 | 重要原因 |
|---|---|
| GPU 峰值内存 | 显示量化是否创造了可用余量。 |
| 首个 token 时间 | 对流式界面很重要。 |
| 每秒输出 token 数 | 显示生成吞吐量，但不反映任务质量。 |
| p95 端到端延迟 | 揭示负载下的长尾表现。 |
| 错误率和 OOM 率 | 识别仅在请求成功时看起来很快的配置。 |
| 结果接受率 | 将原始速度转化为有效工作量。 |
vLLM 量化的关键比较并不是抽象意义上的“量化与未量化”对比，而是“在该工作负载下，此 GPU 上的此检查点和内核，与我们的基线相比”。发布任何结果时都应附上测试条件。如果您的测试缺少质量检查，应将其称为仅性能实验。
常见故障模式
模型无法加载。检查检查点元数据、量化方法、vLLM 版本、GPU 能力，以及该方法是否支持该架构使用的每一层。在盲目更改命令标志之前，应先查看 vLLM 方法矩阵。
内存节省并未改善延迟。更小的权重占用并不保证内核更快。请在目标并发量下进行测试，并检查首个 token 时间、解码速度和 GPU 利用率。更大的 KV 缓存余量可能才是真正的收益。
低比特检查点看起来很快，但未通过质量测试。保留一套生产验收集，并测量满足应用标准的输出百分比。应在金丝雀发布之前设置回滚阈值。
基准测试无法复现。记录模型和检查点修订版本、vLLM 和驱动程序版本、GPU SKU、数据集、并发量、提示词长度、输出长度及命令参数。没有这些信息，吞吐量数字就是营销，而非工程证据。
何时使用 Flatkey Cloud GPU
如果您需要运行自己的 vLLM 服务器并比较量化检查点，请根据经过测量的内存和并发需求选择 GPU 容量。Flatkey 通过 Cloud GPU Compute 提供 NVIDIA GPU 租用选项。在确定使用之前，请确认可用的 SKU、部署区域、容量、价格和服务条款。vLLM 量化测试应在您实际打算租用的配置上进行。如果您需要的是托管模型 API，而不是自行运行 vLLM，请单独评估 Flatkey 的 API route and model directory；这是不同的运营模式。
有关相邻的部署决策，请参阅我们的 vLLM 部署 指南、vLLM 多 GPU 推理指南和 vLLM 与 Ollama 对比。
常见问题
vLLM 量化是否总能让推理更快？
不会。 它可以减少权重内存，但延迟和吞吐量取决于检查点、内核、GPU、序列长度和请求负载。请针对真实工作负载与基线进行基准测试。
我可以在 A100 或 H100 上使用 AWQ 吗？
当前 vLLM 兼容性矩阵列出了对 Ampere 和 Hopper 的 AWQ 支持，其中包括 A100 和 H100。部署前请检查确切的检查点、当前 vLLM 版本和模型架构。
每个 NVIDIA GPU 都支持 FP8 吗？
不支持。支持情况因量化实现和架构而异。当前矩阵区分了诸如 llm-compressor FP8 和 Marlin 等方法；请验证适用于您硬件的确切行。
我应该在选择 GPU 之前还是之后进行量化？
先确定工作负载规模和质量目标，然后在兼容的 GPU 上测试候选检查点。应将格式选择与硬件选择结合起来评估。
