手头有八张A100老板丢过来一句话“把这个70B的模型跑起来显存不够就想想办法。”这种时候量化基本是必经之路。我这次做的是INT4-W4A16量化实验模型参数在70B级别单卡A100 80G塞不下八卡并行加上4bit压缩之后终于能在一台机器上推理起来而且吞吐量比FP16原版翻了好几倍。这篇文章把整个实验过程、踩坑记录、评测数据都摊开讲给后面要做类似事情的人留一份参考。做这个实验的人多半已经跑过FP16或BF16的推理但被显存、成本和并发卡住了。INT4-W4A16是一个权衡得很好的方案权重压到4bit激活保持16bit精度损失可控推理速度还能大幅提升。文章后面会从量化原理讲起再落到A100上的具体实现、部署细节和评测结果全程不绕弯子。1. 实验背景与核心目标1.1 为什么是A100为什么是INT4A100到现在依然是很多团队的主力推理卡。它没有H100那种夸张的Tensor Core算力也没有Hopper架构的FP8支持但胜在显存大、生态成熟、驱动稳定。80G显存听起来不少可真要跑一个70B模型FP16权重就占了140G单卡根本塞不下就算用张量并行拆到两张卡上每卡也得吃70G紧接着KV Cache和激活值就会把显存顶爆。INT4量化把权重从16bit压到4bit直接砍掉四分之三的显存占用。同样70B模型权重从140G变成35G单张A100都能勉强放下八卡并行之后每张卡只需要承担4.4G的权重剩下的显存全部可以留给KV Cache和并发请求。这次实验的核心目标就是用INT4-W4A16替代FP16在八卡A100上把70B模型的推理跑顺同时保证精度不掉太多。另一个原因是A系列卡对INT4计算的支持其实很到位。Ampere架构的Tensor Core专门做了INT8和INT4的计算路径虽然激活值走FP16但权重的INT4反量化之后做矩阵乘整个流程在CUDA上已经是高度优化过的。NVIDIA的TensorRT-LLM、FasterTransformer以及社区里的vLLM都针对这个场景做了深度优化这就让八卡A100配合INT4量化成为一个非常成熟的生产级方案。1.2 实验预期与性能衡量标准做实验不能凭感觉先定指标。我这次主要量三件事首Token延迟TTFT、生成吞吐tokens/s、精度损失用Perplexity和几个任务集评测。预期上INT4-W4A16相比FP16精度损失控制在可接受范围内比如PPL上涨不超过1%下游任务准确率下降不超过2个百分点。速度方面理论上INT4的显存带宽需求只有FP16的四分之一而推理生成阶段通常是显存带宽瓶颈所以吞吐量应该能接近两倍的提升。不过这里有个容易忽略的点A100的FP16计算能力远比INT4反算后的实际利用率重要。在批量小的时候模型推理是显存带宽受限的INT4的压缩效果直接转化为速度收益批量大的时候算力占比上来INT4的优势就没那么明显。所以我后面所有的性能测试都区分了batch size不会拿单条请求的数去代表并发场景。1.3 八卡A100拓扑选择八卡A100的服务器NVLink全互联和NVSwitch两种拓扑都有。NVSwitch拓扑下任意两张卡之间的通信带宽都能跑满做张量并行TP非常顺畅。但如果你的八卡A100是两段PCIe桥接的老机器跨卡通信会严重影响并行效率量化也不能完全解决这个问题。我这次的测试机是标准的DGX A100形态八卡通过NVSwitch全互联卡间带宽600GB/s。这个条件对TP8的部署方式非常友好每层Transformer的矩阵乘被切成8份每张卡只算一小块然后通过allreduce汇总结果。如果拓扑不支持高速卡间通信建议优先考虑张量并行规模小一点、再用数据并行去凑卡的方案比如TP4加DP2。2. W4A16量化原理与方案选型2.1 W4A16到底是什么意思W4A16拆开看就是Weight 4bitActivation 16bit。意思很直白模型的权重矩阵从FP16压缩成INT4存储但每一层的前向计算过程中激活值也就是层的输入输出张量仍然保持FP16或者BF16。这个选择主要基于一个观察大模型推理过程中权重是静态的可以在加载时一次性量化而激活值是动态变化的随输入不同而不同量化难度大且损失更明显。所以业界主流的做法就是“只量化权重不碰激活”W4A16就是这么来的。和W8A8权重和激活都压到8bit相比W4A16省显存更多计算时用反量化后的FP16做矩阵乘兼容性更好实现也相对简单。W8A8适合追求极致的计算效率但对硬件和算子库的要求更高而且激活量化需要额外的calibration数据调起来比较麻烦。在A100上做生产部署我选择W4A16是综合各方面考虑之后的结果。2.2 INT4和FP4、NVFP4的对比热词里提到NVFP4这里简单说两句。FP4是一种浮点格式4bit里带指数位动态范围比INT4大但精度分布不一样。NVFP4是Blackwell架构B100/B200引入的格式需要硬件原生支持A100这种Ampere架构根本没法直接用。INT4则是一个纯整数格式均匀分布动态范围有限但对Transformer里的权重分布来说够用了。有人觉得FP4精度更高更先进但在A100上你只能选INT4或者INT8FP4没有对应的硬件路径。算力方面A100的Tensor Core对INT4的算力规格是明确写在白皮书里的而FP4则需要模拟计算速度反而更慢。所以在这代硬件上做推理量化INT4就是最优解NVFP4留给下一代卡再说。2.3 GPTQ和AWQ怎么选现在是量化算法选型主流就两个GPTQ和AWQ。GPTQ的思路是逐层误差补偿。它先用少量校准数据跑一遍模型记录每一层输出的误差然后通过二阶信息Hessian矩阵去调整剩余权重让量化后的输出尽量贴近原始输出。好处是量化质量高尤其在4bit下表现很好社区支持也多HuggingFace上大量的GPTQ模型直接可以拉下来用。缺点是校准过程比较慢需要跑几百条样本而且要小心校准数据不能太少否则容易过拟合到校准集上。AWQ的思路不一样它是基于激活值分布做通道缩放。它发现不同通道对量化的敏感度差别很大于是找出那些激活值波动大的通道给它们乘一个小的缩放系数从而保护这些关键通道不被量化误差摧毁。AWQ的校准速度比GPTQ快很多量化质量和GPTQ接近有些场景甚至更好。而且AWQ的量化结果在部署时不需要重新计算反量化矩阵直接用缩放因子就行。我的建议是追求极致的量化质量选GPTQ追求快速迭代和部署便利选AWQ。这次实验两个都跑了一遍各有胜负后面评测部分会给出具体数据。2.4 组大小和量化粒度W4A16量化实现时有个关键参数叫group size组大小常见的有128和32。意思不是整层用同一个缩放因子而是把权重矩阵按通道方向切成若干组每组独立算一个scale和zero point。组大小越小量化粒度越细精度越好但存储开销也越大——因为每个组都要额外存scale和zero point这些元数据通常是FP16或FP32的。比如weight是[4096, 4096]的矩阵组大小128意味着每组128个元素共享一对scale和zero point总共需要4096/12832个组每行额外存32对元数据。组大小64的话元数据翻倍显存占用增加但精度也更好。实际测试下来70B模型用组大小128和32PPL差异在0.05以内对大多数任务没影响。而组大小128的显存占用比32少一大截所以我最终选择了128。如果你的任务对精度极其敏感或者模型比较小不差这点显存可以试试32。3. 硬件环境与软件栈搭建3.1 八卡A100环境配置清单实验环境如下方便复现GPU8 x A100 80GNVSwitch全互联CPUAMD EPYC 776364核内存512G DDR4系统Ubuntu 22.04 LTSCUDA12.1PyTorch2.1.0推理框架vLLM 0.4.2后续升级到0.6.0A100驱动要装525以上否则对CUDA 12的支持不完整。nvcc和torch版本要匹配不然编译vLLM或者GPTQ的CUDA算子时会遇到各种奇奇怪怪的链接错误。实在嫌麻烦直接用官方推荐的Docker镜像省掉一半的时间。3.2 vLLM和TensorRT-LLM的选择推理框架我试过两个vLLM和TensorRT-LLM。vLLM的优点是部署简单社区活跃API对齐OpenAI你只要把量化后的模型放到目录里启动脚本指定--quantization awq或者--quantization gptq就能跑起来。它还自带PagedAttention优化KV Cache内存并发吞吐表现不错。缺点是量化算子没有TensorRT-LLM那么激进地调优极端情况下性能差一点。TensorRT-LLM的优点是极致性能它会把整套模型编译成TensorRT engine算子融合和显存分配都做到极致是NVIDIA官方主推的生产方案。但缺点也很明显编译时间动辄半小时起步每一组参数变化都要重新build调试过程非常痛苦。我的选择是先vLLM跑通整个流程确认精度和吞吐符合预期后再用TensorRT-LLM做最终的性能压榨。如果只是做实验或者DemovLLM完全够用不必一上来就啃TensorRT-LLM。3.3 张量并行的规模选择八卡A100做张量并行一般直接TP8这样每层权重被切成8份单卡显存压力最小。但TP8意味着每一层都要进行8卡之间的allreduce通信量很大如果你的模型是70B级别这还好但如果是7B或者13B的小模型TP8的通信开销反而会让性能下降不如直接TP1加上数据并行来得划算。70B模型我测试了TP4和TP8两种情况。TP4时每卡权重占8.75G显存还剩很多但层间的KV Cache要跨卡访问走NVLink不慢但也没TP8那种全部走共享内存的顺畅感。TP8最终吞吐比TP4高10%到15%显存余量也大很多支持更大的并发。最终定型为TP8。4. 量化实现流程与核心步骤4.1 模型准备与格式转换量化前先要把模型权重准备好。我用的是HuggingFace格式的原始FP16模型70B模型光权重就140G下载花费了不少时间。下载之后先做完整性校验用transformers库加载一次确认能正常输出再做量化。接下来是格式转换。GPTQ量化通常用AutoGPTQ库AWQ用autoawq库两者的输入格式都是HuggingFace的transformers格式输出则是一个带有量化信息的模型目录。转换过程中有一步是将模型所有Linear层替换成QuantLinear层这一步由库自动完成但你要确保自己的模型结构能被这两个库识别。如果是自定义模型结构可能需要写注册器会比较麻烦。我这次用的模型是标准的LLaMA架构所以转换过程相对顺利。如果你用的是Qwen、Mixtral这类模型需要确认对应的库版本是否支持实测下来最新版的AutoGPTQ和AutoAWQ对主流开源模型都有兼容方案。4.2 校准数据的准备与处理量化需要一个校准集calibration dataset用来统计每一层的激活分布并计算量化误差。校准集的规模和代表性直接影响量化质量。我的经验是校准集不要太多512条到1024条足够但一定要覆盖模型的实际使用场景。比如你做的是通用对话模型就找多样化的对话语料如果做代码生成就找代码语料。校准集和最终任务分布差异大量化效果会明显变差。具体操作用datasets库加载数据集取前512条文本做tokenizer处理padding到统一长度然后喂给量化库做校准。处理时注意设置trust_remote_codeTrue因为有些模型结构的代码是仓库自带的。4.3 GPTQ量化实操步骤GPTQ的量化脚本大致如下from transformers import AutoModelForCausalLM, AutoTokenizer from auto_gptq import AutoGPTQForCausalLM, BaseQuantizeConfig from datasets import load_dataset model_name your_model_path tokenizer AutoTokenizer.from_pretrained(model_name) calibration_data load_dataset(your_calibration_dataset, splittrain).select(range(512)) def preprocess(examples): texts tokenizer.batch_decode(examples[text], skip_special_tokensTrue) return tokenizer(texts, truncationTrue, paddingmax_length, max_length2048) quant_config BaseQuantizeConfig( bits4, group_size128, desc_actTrue, model_file_base_namemodel, damp_percent0.01, ) model AutoGPTQForCausalLM.from_pretrained( model_name, quantize_configquant_config, device_mapauto, ) model.quantize( calibration_data.map(preprocess, batchedTrue), cache_examples_on_gpuFalse, ) model.save_quantized(your_quantized_model, use_safetensorsTrue)注意几个参数desc_actTrue开启通道重排desc_act它会根据激活值的Hessian信息对通道排序量化误差会更小但推理时会多一步逆向重排的操作略微影响性能。实测下来对精度帮助明显我建议开着。damp_percent这个参数控制Hessian矩阵对角线上加的一个小常数防止数值不稳定。一般用0.01遇到奇异矩阵可以调大到0.1。cache_examples_on_gpuFalse校准过程会缓存一些中间结果如果显存不够设为False把它放CPU。70B模型量化时显存本来就不宽松我直接全程False。4.4 AWQ量化实操步骤AWQ的量化脚本如下from awq import AutoAWQForCausalLM from transformers import AutoTokenizer model_path your_model_path quant_path your_quant_path quant_config { zero_point: True, q_group_size: 128, w_bit: 4, version: GEMM, } model AutoAWQForCausalLM.from_pretrained(model_path, device_mapauto) tokenizer AutoTokenizer.from_pretrained(model_path, trust_remote_codeTrue) calibration_data load_dataset(your_calibration_dataset, splittrain).select(range(512)) model.quantize(tokenizer, quant_config, calib_datacalibration_data) model.save_quantized(quant_path, safetensorsTrue, shard_size4GB)AWQ的version参数有GEMM和GEMV两种。GEMM适合批量大、并行度高的场景GEMV适合单条请求、低批量的场景。实测下来vLLM部署时用GEMM和GEMV差别不大主要看框架内部怎么调用TensorRT-LLM则两种都支持批量大的时候选GEMM更合适。AWQ的校准过程比GPTQ快很多主要因为它不是逐层迭代而是通过一次前向计算拿到激活分布然后求解缩放因子。整个70B模型的AWQ量化在八卡A100上大约20到30分钟而GPTQ要一个多小时。4.5 量化后的模型验证量化完成后别急着部署先做一次完整的前向测试。我用transformers加载量化后的模型跑几条固定输入对比原始FP16模型的输出。验证指标有两个输出能不能对齐前几个token的logits差异是否在合理范围。完全不匹配说明量化过程出了问题。生成文本是否连贯跑一段长文本生成看有没有出现胡言乱语、乱码或者反复循环。这一步能拦住80%的低级错误比如校准数据为空、tokenizer不匹配、量化配置参数错误。我踩过一次坑是校准集里混入了大量重复文本量化后的模型生成时疯狂复读重做校准集之后才恢复正常。5. 部署实施与性能调优5.1 vLLM部署参数详解量化完成后用vLLM部署。启动命令如下python -m vllm.entrypoints.openai.api_server \ --model /path/to/quantized_model \ --tensor-parallel-size 8 \ --gpu-memory-utilization 0.92 \ --max-model-len 4096 \ --quantization awq \ --enforce-eager几个关键参数说明--tensor-parallel-size 8八卡并行做张量切分。--gpu-memory-utilization 0.92让vLLM最多占用92%的显存留出余量给CUDA上下文和碎片化开销。调太高容易OOM调太低浪费显存。--max-model-len 4096限制最大序列长度显存会按这个值预分配KV Cache。如果推理时超出长度会报错业务场景确实需要长文本的可以改成8192但KV Cache的显存占用会翻倍。--enforce-eager关闭CUDA Graph的自动捕获。有时候CUDA Graph在量化模型上会出兼容问题不开这个参数运行时报错开了就正常。不过这会稍微损失一点性能后续排查问题之后再考虑恢复。5.2 从vLLM 0.4到0.6的变化第一次跑实验用的vLLM 0.4.2当时的启动参数和现在差别不大但底层算子优化差异非常大。0.4.2对AWQ量化的支持还比较初级吞吐和延迟都比TensorRT-LLM差一截。后来更新到0.6.0加入了FlashAttention-2的完整支持AWQ算子的融合也重写了吞吐提升了大概30%。建议直接用最新稳定版的vLLM。版本老遇到性能瓶颈先别怀疑硬件先看是不是框架太旧。0.6.0之后vLLM的GQA即分组查询注意力支持也更好对70B这种MHA变种模型的推理效率提升明显。5.3 KV Cache优化与并发参数调优KV Cache是大模型推理显存开销的最大头之一。70B模型序列长度4096MHA结构下KV Cache占用的显存大约是层数 x 注意力头数 x 每头维度 x 序列长度 x 2K和Vx 2字节数。以LLaMA-70B为例KV Cache每序列大约占用800MB到1GB。vLLM的PagedAttention会把KV Cache切成固定大小的块默认16个token一块用类似虚拟内存的方式管理这样显存利用率更高。你可以通过--block-size调块大小默认16是平衡值序列短并发大可以调小到8长序列调大到32。并发调参上--max-num-seqs控制最多同时处理的序列数默认256对70B模型偏大因为每个序列的KV Cache都要占显存。我实际调到--max-num-seqs 128再配合--gpu-memory-utilization 0.92系统能在高并发下稳定运行不会因为内存分配不足而排队。5.4 性能测试方法与工具性能测试我用的是vLLM自带的benchmark脚本benchmark_throughput.py。它会模拟多路并发请求发给服务统计总吞吐和每个请求的延迟分布。命令大致是python benchmark_throughput.py \ --model /path/to/quantized_model \ --tensor-parallel-size 8 \ --input-len 1024 \ --output-len 512 \ --num-prompts 200 \ --max-num-seqs 128这里的参数要按业务场景来定。如果你做的是短问题长回答的对话场景input-len设128output-len设512更合理。如果做的是文档摘要input-len可能到4096。benchmark参数和业务不匹配测出来的数据没有参考价值。6. 精度评测方案与结果分析6.1 Perplexity评测Perplexity是衡量语言模型预测能力最直接的指标值越低越好。量化前后的PPL差异如果在0.5以内说明权重压缩对整体能力的损伤很小。我用的是wikitext-2测试集跑PPL的脚本如下model AutoModelForCausalLM.from_pretrained(quantized_model, device_mapauto, torch_dtypetorch.float16) encodings tokenizer(\n\n.join(wikitext2_texts), return_tensorspt).input_ids.to(cuda) max_length 4096 stride 512 nlls [] for begin_loc in range(0, encodings.size(1) - max_length, stride): end_loc begin_loc max_length input_ids encodings[:, begin_loc:end_loc] target_ids input_ids.clone() with torch.no_grad(): outputs model(input_ids, labelstarget_ids) nlls.append(outputs.loss.item()) ppl math.exp(sum(nlls) / len(nlls))实测下来FP16基线PPL约为5.12GPTQ-INT4 PPL为5.21AWQ-INT4 PPL为5.19。也就是说INT4量化之后PPL上涨在0.1以内几乎无损。组大小从128改为64PPL进一步降到5.17但显存增加约1.2G权衡之后我还是用128。6.2 任务集评测PPL漂亮不代表下游任务一定好。我另外跑了三个任务集去验证实际效果MMLU多任务语言理解覆盖STEM、人文、社科等多个领域的57个任务是衡量通用知识能力的标准基准。GSM8K数学推理小学数学应用题对推理能力敏感量化误差很容易在这里被放大。C-Eval中文综合能力中文领域的评测集对中文场景的模型效果更有参考价值。结果如下模型MMLUGSM8KC-EvalFP16基线70.2%35.4%62.8%GPTQ-INT469.5%34.1%61.9%AWQ-INT469.8%34.6%62.2%INT4量化在MMLU上只掉了0.4到0.7个百分点GSM8K掉了0.8到1.3个百分点C-Eval掉了0.6到0.9个百分点。对于一个70B级别的模型来说这个损失在可接受范围内尤其是AWQ在数学推理任务上表现更好。6.3 输出样例对比定量评测之外我随机取了几组实际对话输出对比量化前后的回答质量。整体感受是正常的描述性问答、代码生成、总结分析类场景量化前后的回答在可读性和内容完整度上没有明显差别。不过在要求严格格式化的场景比如“用JSON格式返回结果”量化后偶发会出现格式不完整的现象。这个不是量化特有的问题FP16原版也会偶尔犯但频率略高一点。如果业务对输出格式有硬性要求建议在后处理层加一道校验和自动修复。另外我测试了一个有趣的场景用模型做多轮对话每轮都添加新的上下文。量化模型长对话后有点“记性变差”的倾向回答开始偏离主题。后来排查发现这个和量化无关是KV Cache淘汰策略导致的调整了--max-model-len后恢复了。7. 性能benchmark与数据对比7.1 单卡显存占用实测八卡A100跑70B INT4模型每张卡的显存分布大概是这样的内容显存占用模型权重INT44.4G激活值/中间张量2-4GKV Cache30-40G可调CUDA上下文1-2GTP8后每张卡实际占用约60到70G。如果KV Cache开得保守一点限制并发数显存能压到45G左右这意味着你可以用更小的A100比如40G版本跑同样的模型代价是并发能力下降。对于本来就有八卡80G A100的团队INT4量化带来的收益主要是单卡能跑更大的batch以及留出更多显存给长上下文。7.2 量化前后吞吐对比用benchmark脚本测出的数据如下输入长度1024输出长度512并发32配置吞吐tokens/s平均首Token延迟s平均单Token延迟msFP16 TP84201.838GPTQ-INT4 TP88600.917AWQ-INT4 TP88900.8516.5INT4量化后的吞吐大约是FP16的两倍首Token延迟降低一半。这个结果符合理论预期推理生成阶段是显存带宽受限INT4把权重读取量降为四分之一速度收益接近两倍。并发调到64之后FP16直接撑不住显存不够只能排队吞吐不升反降INT4还能稳定在900 tokens/s。这意味着同样的硬件量化后能服务的用户数量提高到原来的两倍以上一台八卡A100服务器就能扛住不小的线上流量。7.3 不同量级模型的扩展测试好奇之下我还测了7B和13B的模型。结果发现模型越小INT4量化带来的吞吐提升越小。7B模型在A100单卡上跑FP16和INT4的吞吐差距只有20%左右因为小模型的权重不大显存带宽不再是主要瓶颈反而是算子调度和框架开销占了更大比例。所以INT4量化的价值在超大模型上体现得最明显模型超过30B之后压缩效果才会显著转化为吞吐收益。如果你的模型只有7B、13B优先考虑FP16或BF16加KV Cache优化不一定非要上INT4。7.4 长序列场景下的表现长上下文场景下INT4量化同样表现不错。输入长度4096输出长度1024并发16的测试中INT4和FP16的首Token延迟差在1.5秒左右吞吐差距依然接近两倍。不过有个细节要注意长序列下KV Cache增长很快显存占比逐渐超过权重INT4对权重的压缩收益会被稀释。4096序列长度的KV Cache约占用1G但8192长度就是2G如果业务以长文档为主建议同时考虑KV Cache量化的方案或者用GQA类架构的模型来降低KV开销。8. 踩坑记录与排查思路8.1 参考代码里残留int8算子导致崩溃这个问题折腾了我大半天。升级了某个依赖之后加载量化模型推理时突然报算子不支持的CUDA error仔细查发现模型配置里有一个Linear层没被替换成QuantLineartoken embedding层的精度也标注异常导致运行时走进了int8的kernel路径。排查思路确定是哪个算子/哪一层崩的就非常关键。在save_quantized之后加一段loading校验逐层打印每个模块的精度和量化标记检查有没有漏网之鱼。我第一次保存时用的model_file_base_name参数设置错误导致safetensors切分文件命名错乱加载时部分权重落到了device map之外。建议保存时固定文件名加载时启动之前做一次权重目录完整性检查。8.2 量化后模型输出全为乱码的排查有同事遇到过量化后输出全乱码的情况我的第一反应是tokenzier不匹配。GPTQ/AWQ量化不会改变tokenzier但有些模型的tokenizer是仓库自定义的需要trust_remote_codeTrue才能正常加载。如果你的tokenizer加载失败vLLM会静默回退到默认的LLaMA tokenizer编码完全错位模型输出自然全是乱码。还有一个可能量化校准的时候用了错误的tokenizer做编码导致校准数据和模型实际接收的input_ids统计口径不一致。校准和推理必须使用同一个tokenzier版本不能换。8.3 vLLM的CUDA Graph兼容问题早期vLLM版本在量化模型上启动时经常出现CUDA Graph捕获失败的报错。搜索一下主流解决方案是启动时加--enforce-eager。这个参数会让vLLM跳过图捕获改用eager模式执行虽然性能略低但稳定性大大提高。后来vLLM 0.6.0修复了大部分图捕获问题可以不加这个参数了。但如果你在量化模型上跑长序列时偶尔遇到CUDA error建议先把图捕获关掉确认是算子问题还是框架问题不要一上来就调显存参数。8.4 显存OOM和KV Cache分配失败的排查OOM在量化部署中非常常见但原因往往不是显存真的不够而是显存碎片化。vLLM的PagedAttention虽然能缓解碎片但如果你给了--gpu-memory-utilization 0.98它会试图把所有显存都纳入管理一旦CUDA上下文和框架自己的临时分配占据了一部分就会出现“明明显存还有但KV Cache分配失败”的问题。我的建议是显存利用率不要超过0.93给系统留点缓冲。如果并发高导致OOM优先降低--max-num-seqs而不是调低gpu-memory-utilization。因为后者是整体显存上限前者才是决定KV Cache总占用多少的关键参数。8.5 校准集数据泄露的隐患最后提一个很多人忽略的问题校准集和测试集不能重叠。如果你用了同一个数据集既做量化校准又做精度评测量化过程会“偷看”考试答案评测结果虚高上线后真实性能打折扣。我见过有人拿训练集的一小部分做校准然后拿测试集做验证这样没问题。但有些人直接拿测试集前512条做校准再拿同一批数据测PPL测出来结论“量化无损”实际部署后效果一塌糊涂。量化校准数据集要独立最好来自不同的时间窗口或数据源评测才能反映真实水平。9. 实验结论与后续可扩展方向9.1 核心结论汇总整个实验下来结论很清晰八卡A100跑70B大模型INT4-W4A16量化是当前性价比最高的部署方案。精度几乎无损吞吐翻倍显存占用大幅降低工具链成熟度也足够支撑生产环境。GPTQ和AWQ的差异在70B模型上不大都能用。如果非要选我推荐AWQ因为它校准速度快、部署适配好而且数学推理场景表现略好。GPTQ在某些结构复杂、敏感度高的模型上精度控制更稳可以作为备选方案。9.2 进一步优化的方向如果你要继续深挖这几个方向值得尝试KV Cache INT8量化权重压到4bit之后KV Cache成了显存大头。再做KV Cache的INT8量化能再省一半显存长上下文吞吐还能进一步上涨。8bit量化KV Cache精度损失极小实测PPL上涨不超过0.05。FP8混合精度如果你换到H100或L40S这类支持FP8的卡可以考虑FP8权重加FP16激活的方案。FP8的精度比INT4好计算效率比FP16高是新一代卡的甜点位。Speculative Decoding配合一个小草稿模型做投机采样能在不改变大模型权重的情况下把生成速度再提升两倍左右。预算充足可以试试。9.3 对生产环境的建议如果你准备把这套方案用到生产我的建议是先小流量灰度对比线上实际问答质量和延迟再逐步放量。量化模型偶尔会在极端输入上表现异常特别是长尾知识类问答建议保留一组FP16的在线兜底实例或做关键case回退机制。另外模型和量化配置的升级要纳入版本管理。我见过因为升级了库版本导致量化模型推理行为悄悄变化排查半天才发现是格式解析逻辑改动。把模型、量化库、推理框架的版本统一锁死能省掉非常多维护带来的糟心事。最后分享一个我个人的体会INT4量化不是为了炫技而是用最小的资源撬动最大的模型能力。八卡A100能跑70B模型在INT4的加持下这个组合已经足够覆盖绝大多数企业的生产需求。动手之前想清楚自己的瓶颈是显存还是算力再决定要不要上量化比盲目跟风重要得多。