我最近在折腾大模型部署的时候被显存问题反复折磨。单是 Llama-70B 这样的模型FP16 权重就要占掉 140GB 显存手里两张 80GB 的卡都觉得紧巴巴。量化、剪枝、蒸馏这套“压缩”方案听起来是老生常谈但真要把一个 Llama 模型的推理版本降到单卡可跑、并且吞吐量还能看走弯路是少不了的。NVIDIA Model Optimizer 就是专门干这个事的工具集它把 PTQ 量化、结构化稀疏、知识蒸馏这些路径整合成一条可复现的流水线最终输出给 TensorRT-LLM 或 vLLM 这类推理引擎使用。这篇文章我想从“推理瓶颈”讲到实际压缩流程再到我踩过的坑尽量把每一步“为什么这么做”讲透。适合正在做大模型私有化部署、推理服务优化或者准备把模型塞进有限显存环境里的同学参考。1. 先弄明白推理卡在“内存带宽”而不是“算力”很多人在优化大模型推理时第一反应是堆卡、上高带宽集群或者盲目升级 GPU。但实际上生成式大模型的 decode 阶段瓶颈和训练阶段完全不同先把这点看懂后面理解 Model Optimizer 为什么强调“减少参数量”和“降低位宽”就顺了。1.1 LLM 推理的两个阶段prefill 和 decode大模型推理不是一个均匀过程而是分成两个特征非常明显的阶段。第一个是 prefill也就是用户输入提示词后模型并行处理整段输入生成首个 token第二个是 decode模型逐 token 生成后续内容每一步都依赖上一步的新 token。学术上也分别叫“首 token 延迟”和“吐字速度”。prefill 阶段算力需求高因为要对整段上下文做矩阵乘decode 阶段虽然单次计算量小但每个 token 都要把权重从显存搬一遍。GPU 的显存带宽在这个阶段比算力更容易成为天花板。你用一张 H100 SXM3理论带宽大约 3.35TB/s如果模型是 FP16 的 70B权重有 140GB那么理论上 decode 最快也就每秒 20 多个 token 的水平这还是纯理论上限。现实中各种等待、同步、反量化开销一叠加往往只有 60% 甚至更低。所以大模型推理优化的第一性原理不是把 GPU 算力拉满而是“少搬数据”。量化把 FP16 权重变成 INT8、FP8 甚至 INT4相当于把每个 token 需要读取的数据量砍半、砍四分之一decode 速度自然上去了。这是 Model Optimizer 带来的最直接收益也是我后来做压测时感受最明显的一点。1.2 显存到底被谁吃掉了很多人以为显存消耗主要在权重其实模型跑起来之后KV Cache 的膨胀速度同样惊人特别是在长上下文场景下。我们可以估算一下KV Cache 大小约等于 2 × 层数 × 注意力头数 × 头维度 × 序列长度 × 每个 KV 元素的字节数。以 Llama-3-8B 为例32 层、32 个头、每头 128 维如果序列长度到 4096FP16 存储下一个请求的 KV Cache 就是 2 × 32 × 32 × 128 × 4096 × 2 字节算出来是 2GB 多。看起来还能接受但如果 batch 32那就是 64GB权重才不过 16GB。所以实际部署时长上下文比大模型本身更吃显存这也是为什么现在推理引擎都在大力优化 KV Cache 的量化和管理策略。再加上激活值、临时缓冲区、CUDA context 开销显存预算永远比模型权重容量紧张。我们压缩模型时必须把“权重压缩”和“KV Cache 压缩”一起考虑Model Optimizer 的量化配置里也有专门针对 KV Cache 的选项而不是只盯着权重。1.3 压缩的真正收益是并行度和吞吐不只是体积模型压缩经常被误解为“把模型塞进小卡跑本地 demo”。这个用途当然有但对生产环境来说更大的价值是省下来的显存可以换并发。打个比方原来 FP16 的 70B 在 80GB 单卡上连权重都放不下必须拆到两张卡量化成 FP8 之后权重 70GB单卡 80GB 刚够但 KV Cache 一上去又悬了如果做到 INT4权重只要 35GB单卡可以带更大的 batch 和更长的上下文。同一张卡上能跑的并发请求越多整体吞吐量才真正上来了。压测的时候你会发现单请求 decode 速度提升是 30% 还是 80%远不如你用静态 batch 和 inflight batching 把这些“省下来的空间”换成并行请求来得实在。这也是我后面在 TensorRT-LLM 里调 max_batch_size 时反复体会到的模型“瘦身”是手段跑满整卡才是目的。2. NVIDIA Model Optimizer 的方案组合量化、剪枝、蒸馏不是三选一Model Optimizer 经常被人拿来和单纯的“模型转换工具”对比比如只转精度或者只调算子。它更准确的定位是“面向 TensorRT 和 TensorRT-LLM 的优化前处理工具集”重点解决“模型怎么改才能跑得更快”而不是“模型怎么转格式”。2.1 它和 TensorRT、TensorRT-LLM 的分工关系很多人一开始会把 Model Optimizer、TensorRT、TensorRT-LLM 混在一起我来梳理一下我理解中的分工。TensorRT 是 NVIDIA 的通用推理编译器负责把训练好的模型变成针对特定 GPU 调优过的执行计划TensorRT-LLM 是在 TensorRT 之上专门为大语言模型设计的高层推理框架封装了 paged attention、inflight batching、KV Cache 管理等能力Model Optimizer 是在这一切之前使用的模型优化工具负责把模型做量化、剪枝、蒸馏导出成 TensorRT-LLM 能直接消费的 checkpoint。换句话说Model Optimizer 负责“模型层面”的压缩TensorRT-LLM 负责“运行时层面”的调度。如果你不先做模型优化直接拿去 TensorRT-LLM 构建引擎它当然也能跑但量化和剪枝带来的性能红利就吃不到了尤其是 FP8/INT4 这类硬加速指令必须有对应的量化模型格式才能激活。我在早期踩过这个坑拿着 FP16 模型直接 trtllm-build建完引擎换了个寂寞显存一点没省。2.2 PTQ 量化SmoothQuant、AWQ、GPTQ 各解决什么问题量化是 Model Optimizer 里用得最多的一类功能。按是否需要重新训练可以分成训练后量化和量化感知训练实际部署中大部分场景用前者因为成本低只需要准备几百条校准数据。PTQ 的核心难点在于激活值的离群点。早期做法是只量化权重把激活保留 FP16但遇到激活分布接近正态分布、偶尔冒出几个特别大的值的模型时误差会集中在那几个离群位置上特别影响生成质量。SmoothQuant 的思路挺巧妙把激活中的离群值“迁移”一部分到权重侧让激活分布变平滑权重稍微吃点误差整体效果平衡很多。Model Optimizer 里默认的 INT8 配置基本都带 SmoothQuant。针对权重 INT4 的场景AWQ 和 GPTQ 是两个主流路线。AWQ 的好处是它不追求把所有权重都压到 INT4而是观察哪些通道对精度贡献大把这些通道的缩放因子保留更高精度相当于“重点保护”。实测下来AWQ 在低比特量化下比纯均匀量化的困惑度损失要小。GPTQ 则是基于二阶误差的经典方案老牌、成熟但近年在大模型上优势不如 AWQ 明显。Model Optimizer 里可以直接选择这套配置不需要自己造轮子。2.3 结构化稀疏和剪枝不是所有场景都适合剪枝和稀疏在理论上省权重省计算但实际部署里有不少限制。像 2:4 结构化稀疏是 NVIDIA Ampere 架构以来就支持的特性它要求每连续 4 个权重中最多 2 个非零硬件可以跳过一半的乘法。好处是不需要真的“删掉”参数模型依旧保持原有形状但是 Tensor Core 的稀疏计算单元能加速约一倍。听起来很美好但要注意2:4 稀疏主要节省的是计算时间并不明显减少显存占用。对 prefill 这种算力密集阶段有用对 decode 这种内存带宽密集阶段效果有限。所以我在实际项目里很少把稀疏当作大模型推理的首要优化手段更多是用它配合量化做二次压榨。如果你做的是视觉 Transformer 或者多模态模型sparse quantize 常常能拿到额外收益但纯文本 LLM 的收益就要具体测了。还有一种更彻底的结构化剪枝直接删除部分注意力头或者 FFN 维度。这种做法在中小模型上有效但大模型一旦剪错结构重构损失的代价很高往往需要配蒸馏恢复精度模型的部署灵活性也会下降。因此在我的工作流里剪枝是“最后考虑”的选项只有在量化之后显存依然不够且训练资源充足时才会做带蒸馏的剪枝。2.4 蒸馏的定位它不是替代量化而是救精度知识蒸馏在大模型圈子里被讨论得很多但 Model Optimizer 语境下的蒸馏通常不是指从头训练一个小模型而是指针对已经压缩过的模型做恢复训练。用一个高精度教师模型的输出去指导学生模型继续微调几步帮助学生把量化或剪枝过程中丢失的分布信息拉回来。最典型的场景是 INT4 量化后模型困惑度掉得比预期多。这时候可以把原始 FP16 模型当教师用相同的输入让两个模型分别生成 logits让学生模型去拟合教师模型的概率分布几个 epoch 就能让精度明显回升。实际操作里很多时候只需要在少量领域数据上做这种蒸馏比从头训练成本低得多。所以我的经验是量化先行蒸馏兜底。先用 Model Optimizer 的量化配置拿到体积和速度如果精度不达标再在量化模型上做轻量蒸馏而不是一开始就上蒸馏那样周期太长、收益不一定匹配。3. 实操用 Model Optimizer 把一个 Llama 模型压缩到可部署版本这一部分是整套流程的具体走法。我以 Llama-3.1-8B-Instruct 为例目标是把它量化为 FP8 或 INT4导出 TensorRT-LLM checkpoint然后构建推理引擎跑通。不同版本的工具链 API 和 flag 会有差异下面是代表性流程重点在思路而非逐字照抄。3.1 环境准备尽量用 NVIDIA 容器镜像Model Optimizer 跟 TensorRT-LLM 的版本耦合度不低强烈建议不要自己拼环境。我吃过亏本地 PyTorch 版本太新Model Optimizer 的量化 kernel 编译不过去最后全部推倒重来改用 NVIDIA NGC PyTorch 容器镜像一次就通。基本环境如下docker run -it --gpus all \ --shm-size16g \ -v /data:/models \ nvcr.io/nvidia/pytorch:24.10-py3 \ bash容器里 PyTorch、CUDA、TensorRT-LLM、Model Optimizer 一般都已经配好你只需要确认版本pip show modelopt tensorrt-llm | grep Version拿到模型权重时优先用 Hugging Face 原始权重。如果你的模型已经做过其他量化和合并最好还原回 FP16 版本再开始因为 Model Optimizer 的量化过程是面向 FP16 基座设计的二次量化会造成额外精度损失。3.2 准备校准数据集校准集的“像不像”决定了量化质量量化的本质是拿一批真实数据去统计权重和激活的分布校准集选得不好量化后的模型在真实任务上会出现预料之外的崩坏。具体选多少条我看到很多人用 128 或 512 条但我的经验是不能只看条数还要看内容覆盖。关键词是“任务相关性”。如果你的模型主要做代码生成校准集里就多放代码片段如果做客服问答就放客服对话样本。长度控制在模型最大上下文的一半左右比如 8K 模型的校准样本取 1024 到 2048 token 比较合理太长校准太慢太短分布不准确。下面是个简单示例from datasets import load_dataset from transformers import AutoTokenizer tokenizer AutoTokenizer.from_pretrained(meta-llama/Llama-3.1-8B-Instruct, trust_remote_codeTrue) def build_calib_dataloader(tokenizer, sample_num256, block_size1024): dataset load_dataset(wikitext, wikitext-103-v1, splittrain) samples [] count 0 for text in dataset[text]: if not text.strip(): continue token_ids tokenizer(text, truncationTrue, max_lengthblock_size)[input_ids] if len(token_ids) 128: samples.append(token_ids) count 1 if count sample_num: break return samples这套代码很简单但有一个隐蔽问题如果所有样本都从同一个文档开头截取分布会偏。我后来改用滑动窗口采样每次从长文本随机位置切 block校准出来的模型困惑度更稳定。3.3 用 Model Optimizer 量化模型拿到校准数据后量化代码本身并不复杂。Model Optimizer 把量化配置抽象成了一个个字典你选择不同的配置它会自动决定权重位宽、激活位宽、是否使用 SmoothQuant、是否做 GPTQ/AWQ 等。下面是我常用的 INT8 SmoothQuant 配置流程import torch import modelopt.torch.quantization as mtq from transformers import AutoModelForCausalLM, AutoTokenizer model_path meta-llama/Llama-3.1-8B-Instruct model AutoModelForCausalLM.from_pretrained(model_path, torch_dtypetorch.float16, device_mapcuda) tokenizer AutoTokenizer.from_pretrained(model_path) # 等价于配置字典按需选择: INT8_SMOOTHQUANT_CFG / FP8_DEFAULT_CFG / INT4_AWQ_CFG quant_cfg mtq.INT8_SMOOTHQUANT_CFG calib_samples build_calib_dataloader(tokenizer, sample_num256, block_size1024) def calibrate_loop(model, dataloader): model.eval() for batch in dataloader: batch torch.tensor(batch, dtypetorch.long, devicecuda) with torch.no_grad(): model(batch) quant_model mtq.quantize(model, quant_cfg, calibrate_loopcalibrate_loop)这一步完成后quant_model就是已经完成激活统计和权重转换的量化模型。想要 FP8 就把quant_cfg换成 FP8 配置。如果是 INT4 AWQ则需要额外的 AWQ 搜索流程这个搜索过程很吃显存通常要用多卡或者在 80GB 以上显存的卡上跑否则 OOM 是家常便饭。量化结束时我建议先做一次简单推理看生成结果是不是还像人话。这一步虽然粗糙但能立刻暴露校准集明显不匹配的问题不用等到构建完引擎再返工。3.4 导出 TensorRT-LLM checkpoint 并构建引擎量化完的模型要交给 TensorRT-LLM还需要导出成它认识的 checkpoint 格式。Model Optimizer 提供了导出接口这一步会把模型切分、格式转换、量化元数据打包好然后 trtllm-build 读取这些元数据做算子融合和 kernel 选择。from modelopt.torch.export import export_tensorrt_llm_checkpoint export_tensorrt_llm_checkpoint( quant_model, llama3.1-8b-int8-checkpoint, dtypetorch.float16, n_gpus2, )构建引擎命令大致如下trtllm-build \ --checkpoint_dir llama3.1-8b-int8-checkpoint \ --engine_dir llama3.1-8b-int8-engine \ --gemm_plugin auto \ --max_batch_size 16 \ --max_input_len 2048 \ --max_seq_len 4096 \ --kv_cache_type paged \ --use_fused_mlp这里我建议重点关注几个参数。max_batch_size不是越大越好因为它会为每个 batch 槽预留显存设得过高反而导致可用显存紧张。max_seq_len同样如此长上下文场景下KV Cache 是最大的显存黑洞按实际业务需求留余量即可不要盲目设满。gemm_plugin auto是让 TensorRT-LLM 自己决定哪些算子走 cutlass 内核量化模型通常需要这个保证精度和速度的平衡。构建过程会打印每一层的量化类型和算子选择花几分钟扫一遍很值得。比如看到quantize算子和dequantize算子过多说明你的量化粒度可能偏细kernel 开销会抵消一部分显存收益。3.5 推理验证和性能对比引擎构建完成接下来就是验证。我一般分三步功能验证、精度验证、性能压测。功能验证最简单启动 Python 客户端加载 engine跑几个业务样本python3 run.py \ --engine_dir llama3.1-8b-int8-engine \ --max_output_len 128 \ --input_text 请写一段关于模型压缩的简要介绍精度验证用困惑度最省事。加载原始 FP16 模型和量化引擎在同一批验证文本上计算 perplexity 变化。经验参考值INT8 的困惑度增加在 0.5 以内通常可接受FP8 更小INT4 在 1 到 3 也都算正常如果超过 5 就需要警惕了。如果是任务型模型比如分类、抽取直接跑宏平均 F1 更直观。性能压测我推荐直接在 TensorRT-LLM 里开启--metrics_level 2看首 token 延迟和每 token 延迟或者用 perf 脚本python3 benchmark.py \ --engine_dir llama3.1-8b-int8-engine \ --batch_size 1 \ --input_output_len 128,128 \ --num_requests 50我实测过一个 8B 模型FP16 基础 engine 单请求 decode 大概每秒 100 tokens 出头INT8 后明显往 160 以上走INT4 能到接近 200。换算成成本同样的卡跑同样的 qps吞吐能提升 50% 到 100%这就是压缩对生产环境最实在的价值。4. 推理引擎常见问题排查与实战调优模型压缩和引擎构建不是一次就能顺利跑通的。我在这里把常见问题整理成速查思路每一条都是我实际踩过的坑按“问题现象、根因、解法”的顺序来。4.1 精度掉得离谱先怀疑校准集而不是量化配置很多人一看到量化后输出胡言乱语就立刻觉得“这个模型不能量化”。我现在的第一反应是回去检查校准集。有一次我图省事直接从测试集里抽了 128 条短文本结果模型在中文问答任务上直接崩了换成长度、领域匹配的数据后困惑度恢复正常量化配置完全没动。校准样本太少是最常见的问题。特别是 INT4需要更多的样本来覆盖激活分布256 条是一个偏保守的起点有些模型甚至要 1000 条以上。另外校准时的 batch 大小也会影响统计结果我一般让每个样本独立进模型减少 padding 干扰。如果你是流式服务量化模型在校准集上表现正常但生产流量一上来就变差那多半是校准集和线上数据分布差异太大需要引入线上日志做增量校准。还有一点Model Optimizer 的一些量化配置默认开启“自动测”或“层级别搜索”如果显存不足它可能会自动退化到较低质量方案。跑之前先设置CUDA_VISIBLE_DEVICES并预留足够显存不要让它自己静默降级。4.2 推理速度不升反降优先检查 kernel 和 batch 配置有几次我量化完后跑起来发现延迟比 FP16 还差顿时怀疑是不是这个模型不适合量化。排查到最后基本都是没有用 TensorRT/CUTLASS 内核或者 batch 设得太小。在 PyTorch 原生环境里直接跑量化模型某些模块反而会经历“反量化 FP16 计算 再量化”的路径开销比直接 FP16 还大。Model Optimizer 强在它导出的模型专门给 TensorRT-LLM 消费所以不要拿它在原生 PyTorch 下对比速度。一定要导出、构建引擎、再对比。batch 影响也很大。当 batch_size 等于 1 时decode 主要靠 memory bandwidth量化收益明显但 prefill 阶段计算密集如果模型很小或者序列很短kernel 启动和量化开销会吃掉收益。生产环境建议用静态 batch比如固定 8 或 16 的 max_batch_size让 GPU 利用率跑起来。低于 4 的 batch做量化的收益边际递减。如果你的服务并发很低宁可优先考虑 2:4 稀疏优化计算也不要过度追求低比特量化。4.3 显存还是不够往 KV Cache 和引擎配置两个方向调权重已经压缩到位显存依旧爆掉那问题多半出在 KV Cache。TensorRT-LLM 默认会给每个请求预留max_seq_len长度的 KV Cache如果 max_seq_len 设了 4096但实际平均才 1024空置区域全是浪费。更合理的方式是启用 paged KV cache或者按业务统计设一个合理的 max_seq_len。KV Cache 也可以量化。INT8 KV Cache 在实际任务中精度损失通常很小但对显存占用是减半级别的收益。Model Optimizer 对新模型的量化配置里如果有 KV cache 量化选项建议开启测试。还有一个容易被忽略的地方中间激活值。显存优化时可以在 TensorRT-LLM 里开启--reuse_memory_pool或调整 workspace 大小有时能挤出几个 GB。另外多卡并行不等于拆完就完。TP 并行时 KV Cache 是按层分摊的PP 并行则按层切分不同并行方式对显存峰值的改善不同。如果你单卡跑大模型 OOM与其盲目加卡不如先用 2 卡 TP 把权重摊开再配合 KV cache 量化往往两张 80GB 卡就能跑起来原来要 4 张卡的模型。4.4 不同量化方案对比与选型建议到选择压缩方案的时候我用下面这张表做决策非常直观。它不是绝对参数但能帮你快速锁定方向。方案权重位宽激活位宽显存相对 FP16精度损失硬件要求主要场景FP16 基线16-bit16-bit1x无通用显存充足追求最高精度FP8 量化8-bit8-bit/16-bit约 50%极低Hopper 原生 FP8 支持大规模 LLM高并发生产INT8 SmoothQuant8-bit8-bit约 50%低Ampere 通用部署兼容性好INT4 AWQ4-bit16-bit约 25% 到 30%中等Turing 单卡跑大模型强显存压力2:4 稀疏 量化8/4-bit视量化计算减半显存略减低Ampere 稀疏核心prefill 算力密集场景配合量化使用我的判断标准很简单如果目标是高并发生产优先 FP8如果只追求成本极致、单卡部署大模型INT4 AWQ 首选如果既要兼容性又要稳健INT8 SmoothQuant 最平衡。量化不是越狠越好因为反量化和特殊 kernel 也会带来控制开销30% 以上的压缩已经能满足绝大多数业务强上 3-bit 或 2-bit 往往会面临适配问题。4.5 排查问题速查表最后整理一份速查表方便你现场对照现象可能原因排查方向量化后输出乱码校准集不匹配换领域相关数据增加样本量显存占用下降不明显KV Cache 未量化开启 KV Cache INT8 或降低 max_seq_len单请求延迟反而变高PyTorch 原生跑量化导出 TensorRT-LLM 引擎再测并发吞吐没提升max_batch_size 太小调大静态 batch使用 inflight batching构建引擎时 OOM显存不足减小 max_batch_size/workspace分卡 TP某些层仍然是 FP16算子不支持量化检查量化报告替换不支持的自定义算子这个表是我日常排查的起点。遇到问题先在表里过一轮通常不需要直接上 GitLab issues 就能定位到方向。如果表里没有再去看 TensorRT-LLM 的日志里面对每个 phase 的内存占用和延迟都有细粒度输出比网上很多玄学排错靠谱得多。5. 最后说几点实际心得跑过几个完整的大模型压缩项目之后我的体会是Model Optimizer 本身不复杂复杂的是你想在什么样的约束下得到一个什么样的模型。它给了你量化、稀疏、蒸馏的按键但按哪个键、按多深取决于你的显存预算、上线延迟要求、精度底线和团队训练调优能力。一个小建议量化之前先把基线测准。所谓基线不只是模型权重大小还包括原始 FP16 引擎在同一批硬件上的精度、首 token 延迟、每 token 延迟、最大并发数。没有这组数据后面所有优化都说不清楚收益是多少。我每次做压缩都会建一张 Google Sheet 记录基线和每一版压缩模型的数字决策都从表里来而不是靠感觉。另一个心得是“变化率”比“绝对值”重要。不要只盯着压缩后模型每秒吐多少 token要看它和 FP16 版本相比的延迟变化率、精度退化率。如果 INT4 比 INT8 只快了 20%但精度掉了一倍那这个收益是不值得的。踩过几次坑之后我现在对 4-bit 以下方案都非常保守除非硬件特殊否则 INT8 和 FP8 才是性价比最优区。如果你接下来准备做类似的项目我建议按这个顺序推进先用默认量化配置跑通全链路确认每个环节都能产出结果再调校准集和量化配置观察精度变化最后再考虑稀疏和蒸馏。一步到位追求“最优”往往会在排错上耗尽热情能稳定复现的流程永远比某一项参数的极限值更有价值。