模型量化会怎样影响 GPU 推理性能，显存节省与计算速度之间如何权衡

模型量化是当前大模型推理优化的重要手段之一。它的基本思路并不复杂，就是把模型中的部分参数或中间数据从较高精度的数据类型转换成更低精度的格式，例如FP16、BF16、FP8、INT8甚至INT4，从而减少存储需求和数据搬运量，并在支持相应低精度计算的GPU上提高计算效率。

但量化并不是简单地把数字变小，速度就一定会按照比例提高。实际推理性能取决于模型大小、量化对象、量化粒度、GPU架构、显存带宽、算子实现、批量大小以及推理软件等多个因素。对于大语言模型尤其如此，因为模型推理经常受到显存访问和KV Cache的限制，而不只是受到理论计算能力的限制。

最容易理解的是显存占用。一个参数如果使用FP32存储，需要4字节；使用FP16或BF16需要2字节；INT8通常只需要1字节；INT4则约为0.5字节。因此，在只考虑权重本身、暂不计算额外scale和元数据的情况下，FP32权重转换为INT8，权重存储量理论上可以减少约75%；转换为INT4则可以减少约87.5%。

这也是量化对于大模型部署最直接的价值。例如一个主要由权重构成的模型，如果原本需要大量显存保存FP16权重，采用INT8或者INT4权重量化后，就可能在更小容量的GPU上运行，或者在相同显存下留出更多空间给KV Cache和更大的批量。对于LLM服务来说，这种变化有时比单纯提高计算单元的峰值算力更加重要。

不过，实际模型占用的显存并不只有权重。推理过程中还会保存激活值、临时计算空间以及KV Cache。尤其是在长上下文和多用户并发场景下，KV Cache可能成为非常重要的显存消耗来源。因此，权重量化并不意味着整个推理过程的显存占用会按照相同比例下降。如果只压缩权重，而KV Cache仍然采用FP16或BF16，最终节省的显存就会低于按照参数数量计算出的理论比例。

量化还存在不同类型。最常见的一种是权重量化，只把模型参数压缩到INT8或者INT4，而计算过程中仍然使用较高精度的数据类型。另一种是权重和激活同时量化，这可以进一步减少数据搬运，并让更多矩阵运算直接使用低精度Tensor Core，但对模型的量化误差和软件支持要求也更高。

现在的推理系统已经不局限于INT8。NVIDIA TensorRT支持FP8、FP4、INT8和INT4等多种低精度格式，其中INT4主要用于权重量化。TensorRT-LLM也提供FP8、INT8、INT4 AWQ等量化路径，并结合专门的LLM推理优化。

计算速度方面，不能简单理解为“位数降低一半，速度就提高一倍”。GPU只有在硬件计算单元能够高效执行对应数据类型时，低精度才可能转化为实际性能优势。以NVIDIA A100为例，其官方规格显示，FP32峰值为19.5 TFLOPS，而INT8 Tensor Core峰值为624 TOPS；这些数字说明A100针对低精度矩阵计算进行了专门的硬件设计，但它们并不能直接等同于某个LLM在实际推理中的加速比例。

AMD的情况也类似。以Instinct MI250为例，其官方规格列出的INT8矩阵计算峰值为362.1 TOPS，同时FP16和BF16矩阵计算峰值也达到362.1 TFLOPS。不同GPU的计算单元设计、时钟频率、矩阵指令以及软件栈都不同，因此不能拿某一块NVIDIA GPU上的理论比例直接套用到AMD GPU，更不能用一个固定的“1.8倍”概括所有AMD产品。

对于LLM推理，另一个关键问题是显存带宽。生成一个token时，模型需要反复访问大量权重。如果计算速度很高，却无法足够快地把权重从显存提供给计算单元，GPU就可能处于等待数据的状态。量化可以减少每个参数需要读取的数据量，因此在受到显存带宽限制的模型推理中，低精度权重有机会带来明显收益。

这也是为什么量化并不只是减少显存容量。它同时减少了权重数据搬运量。在某些LLM推理场景中，模型本身的矩阵计算并不是主要瓶颈，权重读取才是限制生成速度的重要因素。此时，即使低精度计算单元没有完全发挥出来，较小的权重也可能通过降低显存访问压力提高每秒生成token数。

但如果模型属于计算密集型任务，情况又会不同。当GPU计算单元已经成为瓶颈时，使用能够直接运行低精度矩阵运算的Tensor Core，才可能同时获得计算吞吐提升。最终速度究竟提高多少，需要通过具体模型和具体GPU进行测试，而不能从INT8或INT4这个名称直接推导出来。

PCIe也需要与显存带宽区分开来。如果整个模型已经放在GPU显存中，那么模型生成过程中的主要权重访问发生在GPU内部显存系统，而不是每次计算都经过PCIe。PCIe更多影响CPU与GPU之间的数据传输、模型加载、多GPU系统中的某些通信路径以及其他主机设备交互。因此，把“PCIe带宽不足”作为量化模型普遍变慢的主要原因并不准确。

量化还会带来精度损失。INT8和INT4能够表示的数值范围和精度低于FP16、BF16等格式，量化过程中会出现舍入和截断误差。对于分布比较复杂的权重和激活，如果量化方案处理不当，误差可能在多层网络中累积，最终影响模型输出质量。NVIDIA的TensorRT文档也明确将舍入误差和截断误差列为量化精度问题的重要来源。

因此，量化通常需要考虑量化粒度。例如可以按照整个张量、通道或者更小的block确定scale。更细的量化粒度可以更好地适应参数分布，但同时会增加scale等额外信息和计算管理成本。TensorRT目前针对不同数据类型提供了不同的per-tensor、per-axis和per-block方案，这说明量化已经发展成一套精细的工程体系，而不是简单改变一个数据类型名称。

在大语言模型中，AWQ、GPTQ、SmoothQuant等方法也体现了不同的量化思路。有些方法主要压缩权重，有些则希望同时处理权重和激活的数值范围。实际部署时还需要考虑推理框架是否有对应的高效kernel。如果模型虽然已经量化，但GPU最终仍然需要频繁进行类型转换，或者关键算子没有针对量化格式进行优化，那么理论上的显存节省就未必能够转化成相同程度的速度提升。

量化方式还会影响并发能力。假设一块GPU原本只能容纳一个较大的模型，量化后多出大量显存，这些空间可以用于更大的KV Cache、更长的上下文或者更多并发请求。在服务器环境中，这可能提高整体吞吐量。此时量化带来的价值并不只是“一个请求跑得更快”，而是让同一块GPU能够同时处理更多请求。

因此，评价量化效果不能只看单次推理延迟。实际部署通常需要同时观察首token延迟、生成阶段的token速度、每秒处理请求数、GPU利用率、显存占用以及模型输出质量。对于聊天机器人、代码生成和长文本服务，不同指标的重要程度也不一样。低延迟交互和高并发批处理可能需要完全不同的量化方案。

量化的另一个重要区别是PTQ和QAT。PTQ，也就是训练后量化，是在模型训练完成以后进行量化，部署成本较低；QAT，也就是量化感知训练，则在训练阶段模拟量化误差，让模型参数适应低精度表示，通常能够帮助保持模型质量，但需要额外训练成本。实际项目并不是所有模型都必须进行QAT，很多部署场景会先尝试成熟的PTQ方案，再根据精度损失决定是否进一步训练。TensorRT目前同时支持PTQ和QAT工作流。

软件栈同样会决定量化能否转化成性能。CUDA、TensorRT、TensorRT-LLM以及具体GPU架构之间存在紧密联系。一个量化模型如果拥有高度优化的kernel，可以充分利用Tensor Core，那么低精度可能带来明显收益；如果只是把模型文件压缩成INT4，却没有相应的高效计算路径，实际推理速度可能并不会明显提高。TensorRT的设计本身就是把数据类型、kernel、图优化和硬件能力结合起来进行推理优化。

对于普通GPU用户，选择量化模型时可以把问题简单化为三个层面。第一是模型能否放进显存；第二是量化之后的输出质量是否能够接受；第三是实际生成速度和并发能力是否得到改善。只看模型文件从8位变成4位，并不能判断最终体验。

对于数据中心部署，则需要进一步考虑GPU架构、显存容量和带宽、batch size、上下文长度、KV Cache、量化kernel以及整个推理软件栈。一个在A100上表现很好的INT8方案，并不意味着在另一种GPU上也能获得同样的收益。AMD MI250的硬件指标与A100就已经存在明显差异，软件栈也不同。

模型量化的核心价值并不是单纯追求最低位数，而是在模型质量、显存容量、显存带宽、计算吞吐和并发能力之间找到适合具体应用的组合。对于部分大语言模型，INT4权重量化可以大幅降低模型存储需求；对于需要更高计算吞吐的服务器，FP8或INT8等格式可能更有吸引力；对于对精度更加敏感的任务，则可能继续使用FP16或BF16。

最终决定量化是否值得采用的，不是某个数据类型在理论规格表中的数字，而是具体模型在具体GPU、具体上下文长度和具体并发条件下的测试结果。量化降低了数据规模，也改变了计算和内存访问之间的比例，但它不会自动消除所有推理瓶颈。GPU推理优化的重点，正在从单纯追求峰值算力转向计算、显存、KV Cache、kernel和软件运行时之间的整体协同。