：量化剪枝與推理加速優(yōu)化全流程)
1. 從一次顯存告急說起Model-Optimizer 到底在解決什么問題上周幫朋友調(diào)一個視覺模型RTX 4060 Laptop 只有 8GB 顯存模型權(quán)重加載完就占了 6.2GB剩下不到 2GB 要留給激活值、KV Cache 和中間張量batch size 只能開到 1推理延遲還飆到 400ms 以上。他問我是不是只能換卡我說先別急把模型過一遍Model-Optimizer再說。折騰了一個下午量化加剪枝組合下來顯存占用壓到 2.8GB延遲降到 110ms精度掉了不到 0.8 個百分點。這就是 Model-Optimizer 這類工具存在的意義——它不是一個單點技術(shù)而是一整套圍繞量化、剪枝、推理加速的模型壓縮與優(yōu)化流水線。很多人第一次聽到 Model-Optimizer 會以為是某個具體庫的名字其實它更像一個方法論集合的統(tǒng)稱。NVIDIA 生態(tài)里有一系列工具在做這件事比如 TensorRT 的模型優(yōu)化器、Model Optimizer 相關(guān)的量化工具鏈社區(qū)里也有大量開源實現(xiàn)。核心目標(biāo)就一個讓訓(xùn)練好的模型在推理階段跑得更快、占得更少、精度盡量不塌。它面向的是所有需要在有限硬件上部署模型的人——不管你是拿 4090 跑本地大模型還是在 H100 千卡集群上做推理服務(wù)壓縮和優(yōu)化都是繞不開的環(huán)節(jié)。我自己的經(jīng)驗是模型優(yōu)化這件事最怕兩種極端一種是無腦上 INT8 量化結(jié)果精度崩了還不知道為什么另一種是死守 FP32覺得壓縮一定會掉點。實際上量化、剪枝、蒸餾、算子融合這些手段各有適用邊界組合起來用才能達(dá)到顯存、延遲、精度的三方平衡。下面我會把這套東西拆開講清楚包括每一步為什么這么做、參數(shù)怎么選、踩過哪些坑。2. 量化、剪枝、推理加速三條技術(shù)路線的底層邏輯2.1 量化到底在做什么從 FP32 到 INT8 的數(shù)值映射量化的本質(zhì)是用更少的比特位來表示原本高精度的數(shù)值。FP32 每個權(quán)重占 4 字節(jié)INT8 只占 1 字節(jié)理論上模型體積直接壓到四分之一。但這不是簡單的截斷而是要做仿射映射把一個浮點區(qū)間 [min, max] 線性映射到整數(shù)區(qū)間 [-128, 127]推理時再反量化回浮點參與計算。關(guān)鍵參數(shù)是scale縮放因子和zero_point零點。公式是real_value scale * (quantized_value - zero_point)scale 決定了量化精度zero_point 保證浮點零能精確映射到整數(shù)。我見過很多人量化后精度崩掉八成是校準(zhǔn)集選得不對。校準(zhǔn)集的作用是統(tǒng)計激活值的動態(tài)范圍如果你拿一堆無關(guān)數(shù)據(jù)去校準(zhǔn)min/max 統(tǒng)計偏了scale 就偏了量化誤差自然大。量化分兩種模式PTQ訓(xùn)練后量化和QAT量化感知訓(xùn)練。PTQ 不需要重新訓(xùn)練拿幾百條校準(zhǔn)數(shù)據(jù)跑一遍就行適合快速驗證QAT 在訓(xùn)練時插入偽量化節(jié)點讓模型提前適應(yīng)量化誤差精度通常更好但成本高。實際項目里我的策略是先用 PTQ 試掉點超過 2% 再考慮 QAT。2.2 剪枝的兩條路結(jié)構(gòu)化與非結(jié)構(gòu)化的取舍剪枝是另一條路核心思想是去掉模型中不重要的權(quán)重或結(jié)構(gòu)。非結(jié)構(gòu)化剪枝把單個權(quán)重置零理論上能壓到很高稀疏度但問題是 GPU 對稀疏矩陣的支持有限除非稀疏度超過 90% 且用專門稀疏算子否則實際加速效果很有限。我試過 ResNet34 做 70% 非結(jié)構(gòu)化剪枝模型文件小了但推理速度幾乎沒變因為稠密計算還是要跑。結(jié)構(gòu)化剪枝直接砍掉整個通道、注意力頭或?qū)蛹敉昃褪且粋€小模型不需要特殊硬件支持。代價是精度損失更明顯需要配合微調(diào)恢復(fù)。實踐中我一般先用結(jié)構(gòu)化剪枝砍掉冗余通道再用非結(jié)構(gòu)化剪枝做細(xì)粒度壓縮最后量化收尾。剪枝的判定標(biāo)準(zhǔn)有很多權(quán)重絕對值、梯度信息、BN 層縮放因子等。BN 縮放因子法比較實用因為 BN 的 gamma 參數(shù)本身就反映了通道重要性gamma 接近零的通道基本可以安全砍掉。2.3 推理引擎為什么能加速算子融合與內(nèi)存復(fù)用量化剪枝之后模型結(jié)構(gòu)變了還需要推理引擎來真正把加速落地。推理引擎做的事情包括算子融合把 ConvBNReLU 合成一個算子、內(nèi)存池復(fù)用、kernel 自動調(diào)優(yōu)等。TensorRT、ONNX Runtime、OpenVINO 都是這個層面的工具。算子融合的收益很直觀原本三個 kernel 要讀寫三次顯存融合后一次搞定帶寬省了延遲自然降。內(nèi)存復(fù)用則是提前分配好張量內(nèi)存池避免推理時反復(fù)申請釋放。這些優(yōu)化疊加起來在 780M 核顯這種帶寬受限的硬件上效果尤其明顯。3. 實操全流程從原始模型到優(yōu)化后推理3.1 環(huán)境準(zhǔn)備與依賴安裝先說環(huán)境。NVIDIA 顯卡的話驅(qū)動和 CUDA 是基礎(chǔ)。Ubuntu 上裝驅(qū)動我習(xí)慣用apt而不是官網(wǎng) runfile省得后面內(nèi)核升級出問題sudo apt update sudo apt install nvidia-driver-550 sudo reboot裝完用nvidia-smi確認(rèn)。如果要在 Docker 里跑還需要nvidia-container-toolkitsudo apt install nvidia-container-toolkit sudo systemctl restart dockerPython 側(cè)的核心依賴pip install torch torchvision --index-url https://download.pytorch.org/whl/cu121 pip install onnx onnxruntime-gpu pip install neural-compressor注意CUDA 版本、驅(qū)動版本、PyTorch 版本三者必須匹配。我踩過最坑的一次是驅(qū)動 535 配 CUDA 12.4 的 PyTorch結(jié)果torch.cuda.is_available()一直返回 False查了半天才發(fā)現(xiàn)是驅(qū)動太舊。3.2 量化實操PTQ 校準(zhǔn)與精度驗證以 ResNet34 為例先做 PTQ。核心是準(zhǔn)備校準(zhǔn)數(shù)據(jù)加載器然后調(diào)用量化接口import torch from neural_compressor.quantization import fit from neural_compressor.config import PostTrainingQuantConfig model torch.load(resnet34.pth).eval() calib_dataloader build_calib_loader(batch_size32, num_batches10) config PostTrainingQuantConfig( approachstatic, calibration_sampling_size300, op_type_dict{Conv: {weight: {dtype: [int8]}}} ) q_model fit(model, config, calib_dataloadercalib_dataloader) q_model.save(resnet34_int8)校準(zhǔn)集數(shù)量我一般取 200 到 500 條太少統(tǒng)計不準(zhǔn)太多浪費時間。校準(zhǔn)完之后必須跑驗證集對比精度掉點超過 1% 就要檢查是不是某些層不適合量化。常見的不適合量化的層包括第一層卷積和最后的全連接層可以配置跳過。3.3 剪枝實操結(jié)構(gòu)化剪枝加微調(diào)恢復(fù)剪枝我用的是基于 BN 縮放因子的通道剪枝。流程是先跑一遍訓(xùn)練集統(tǒng)計所有 BN 層的 gamma 分布然后按全局閾值砍掉 gamma 最小的通道最后微調(diào) 10 到 20 個 epoch 恢復(fù)精度。import torch.nn.utils.prune as prune def structured_prune(model, amount0.3): for name, module in model.named_modules(): if isinstance(module, torch.nn.Conv2d): prune.ln_structured(module, nameweight, amountamount, n2, dim0) prune.remove(module, weight) return model剪枝率的選擇很關(guān)鍵。ResNet34 上我試過 20%、30%、40% 三檔30% 是甜點精度掉 1.2% 微調(diào)后能恢復(fù)到 0.3% 以內(nèi)40% 就掉得比較狠了微調(diào)也拉不回來。這個數(shù)字跟模型冗余度有關(guān)不能照搬。3.4 推理引擎部署ONNX 導(dǎo)出與 TensorRT 加速量化剪枝完的模型導(dǎo)出 ONNX再用 TensorRT 做最終加速torch.onnx.export( q_model, dummy_input, resnet34_optimized.onnx, opset_version13, input_names[input], output_names[output], dynamic_axes{input: {0: batch}, output: {0: batch}} )TensorRT 轉(zhuǎn)換時注意dynamic shape的配置如果 batch size 會變要顯式指定 optimization profile。我一般設(shè) min1、opt8、max32覆蓋大部分場景。4. 踩坑實錄那些文檔里不會寫的問題4.1 量化后精度暴跌的排查思路精度暴跌最常見的原因有三個校準(zhǔn)集分布不對、某些層量化敏感、激活值動態(tài)范圍過大。排查順序是先看哪些層量化后誤差最大再針對性跳過或改用混合精度。我遇到過一次第一層卷積量化后精度掉 5%原因是輸入圖像歸一化后范圍是 [-2.1, 2.1]但校準(zhǔn)集里全是接近零的值scale 統(tǒng)計偏了。換成覆蓋完整范圍的校準(zhǔn)集就好了。4.2 剪枝后模型加載報錯的解決剪枝后保存的模型如果直接torch.load可能報 key 不匹配因為剪枝改變了參數(shù)名。解決辦法是剪枝后先prune.remove把 mask 固化到權(quán)重里再保存 state_dict。另外結(jié)構(gòu)化剪枝后模型結(jié)構(gòu)變了加載時要先構(gòu)建剪枝后的模型骨架再 load。4.3 推理引擎兼容性問題速查問題現(xiàn)象可能原因解決方向ONNX 導(dǎo)出失敗算子不支持升級 opset 或替換算子TensorRT 轉(zhuǎn)換報錯動態(tài) shape 未配置設(shè)置 optimization profile推理結(jié)果與 PyTorch 不一致量化誤差累積檢查首尾層是否量化顯存占用沒降中間張量未復(fù)用開啟內(nèi)存池或減小 batch提示ONNX 導(dǎo)出時如果模型里有自定義算子先確認(rèn)目標(biāo)推理引擎是否支持不支持的話要么改寫算子要么換引擎。5. 不同硬件場景下的優(yōu)化策略選擇5.1 消費級顯卡顯存優(yōu)先RTX 4060 Laptop 這種 8GB 顯存的卡優(yōu)化第一優(yōu)先級是顯存。策略是激進量化加適度剪枝INT8 是標(biāo)配必要時上 INT4。batch size 控制在 4 以內(nèi)配合梯度檢查點如果是訓(xùn)練場景。780M 核顯這種沒有獨立顯存的還要考慮內(nèi)存帶寬瓶頸算子融合的收益比量化還大。5.2 數(shù)據(jù)中心卡吞吐優(yōu)先H100 這種卡顯存不是瓶頸優(yōu)化目標(biāo)是吞吐量。這時候量化主要為了用 Tensor Core 的 INT8 算力剪枝要謹(jǐn)慎因為可能破壞并行度。重點是推理引擎的 kernel 調(diào)優(yōu)和 batch 調(diào)度TensorRT 的 builder 優(yōu)化級別開到最大配合 continuous batching 能把吞吐拉滿。5.3 大模型場景KV Cache 與量化組合大模型推理的顯存大頭是 KV Cache不是權(quán)重。Qwen 系列 27B 模型 FP16 權(quán)重約 54GB但長上下文時 KV Cache 能占幾十 GB。這時候權(quán)重量化到 INT4 省不了太多關(guān)鍵是 KV Cache 量化加 PagedAttention 這類內(nèi)存管理技術(shù)。我實測 Qwen3 27B 在單卡上權(quán)重 INT4 加 KV Cache INT8上下文 8K 時顯存從 70GB 壓到 28GB能跑起來了。6. 我個人的幾條實操心得量化剪枝這套東西工具鏈更新很快但底層邏輯幾年沒變過。我的建議是先把 PTQ 跑通理解 scale 和校準(zhǔn)集的關(guān)系再碰 QAT 和剪枝。剪枝率不要貪30% 是個比較安全的起點每加 10% 都要重新驗證精度。推理引擎的選擇上NVIDIA 卡優(yōu)先 TensorRT其他場景 ONNX Runtime 夠用別為了追新工具把穩(wěn)定流程搞亂。還有一點優(yōu)化前后一定要做端到端延遲對比不能只看模型文件大小。我見過剪枝后文件小了一半但推理沒變快的案例因為瓶頸根本不在計算量而在內(nèi)存帶寬。用nsys或者torch.profiler抓一下 timeline看清楚時間花在哪再決定優(yōu)化方向比盲目調(diào)參高效得多。 Model-Optimizer實戰(zhàn)：量化剪枝與推理加速優(yōu)化全流程
1. 從一次顯存告急說起Model-Optimizer 到底在解決什么問題上周幫朋友調(diào)一個視覺模型RTX 4060 Laptop 只有 8GB 顯存模型權(quán)重加載完就占了 6.2GB剩下不到 2GB 要留給激活值、KV Cache 和中間張量batch size 只能開到 1推理延遲還飆到 400ms 以上。他問我是不是只能換卡我說先別急把模型過一遍Model-Optimizer再說。折騰了一個下午量化加剪枝組合下來顯存占用壓到 2.8GB延遲降到 110ms精度掉了不到 0.8 個百分點。這就是 Model-Optimizer 這類工具存在的意義——它不是一個單點技術(shù)而是一整套圍繞量化、剪枝、推理加速的模型壓縮與優(yōu)化流水線。很多人第一次聽到 Model-Optimizer 會以為是某個具體庫的名字其實它更像一個方法論集合的統(tǒng)稱。NVIDIA 生態(tài)里有一系列工具在做這件事比如 TensorRT 的模型優(yōu)化器、Model Optimizer 相關(guān)的量化工具鏈社區(qū)里也有大量開源實現(xiàn)。核心目標(biāo)就一個讓訓(xùn)練好的模型在推理階段跑得更快、占得更少、精度盡量不塌。它面向的是所有需要在有限硬件上部署模型的人——不管你是拿 4090 跑本地大模型還是在 H100 千卡集群上做推理服務(wù)壓縮和優(yōu)化都是繞不開的環(huán)節(jié)。我自己的經(jīng)驗是模型優(yōu)化這件事最怕兩種極端一種是無腦上 INT8 量化結(jié)果精度崩了還不知道為什么另一種是死守 FP32覺得壓縮一定會掉點。實際上量化、剪枝、蒸餾、算子融合這些手段各有適用邊界組合起來用才能達(dá)到顯存、延遲、精度的三方平衡。下面我會把這套東西拆開講清楚包括每一步為什么這么做、參數(shù)怎么選、踩過哪些坑。2. 量化、剪枝、推理加速三條技術(shù)路線的底層邏輯2.1 量化到底在做什么從 FP32 到 INT8 的數(shù)值映射量化的本質(zhì)是用更少的比特位來表示原本高精度的數(shù)值。FP32 每個權(quán)重占 4 字節(jié)INT8 只占 1 字節(jié)理論上模型體積直接壓到四分之一。但這不是簡單的截斷而是要做仿射映射把一個浮點區(qū)間 [min, max] 線性映射到整數(shù)區(qū)間 [-128, 127]推理時再反量化回浮點參與計算。關(guān)鍵參數(shù)是scale縮放因子和zero_point零點。公式是real_value scale * (quantized_value - zero_point)scale 決定了量化精度zero_point 保證浮點零能精確映射到整數(shù)。我見過很多人量化后精度崩掉八成是校準(zhǔn)集選得不對。校準(zhǔn)集的作用是統(tǒng)計激活值的動態(tài)范圍如果你拿一堆無關(guān)數(shù)據(jù)去校準(zhǔn)min/max 統(tǒng)計偏了scale 就偏了量化誤差自然大。量化分兩種模式PTQ訓(xùn)練后量化和QAT量化感知訓(xùn)練。PTQ 不需要重新訓(xùn)練拿幾百條校準(zhǔn)數(shù)據(jù)跑一遍就行適合快速驗證QAT 在訓(xùn)練時插入偽量化節(jié)點讓模型提前適應(yīng)量化誤差精度通常更好但成本高。實際項目里我的策略是先用 PTQ 試掉點超過 2% 再考慮 QAT。2.2 剪枝的兩條路結(jié)構(gòu)化與非結(jié)構(gòu)化的取舍剪枝是另一條路核心思想是去掉模型中不重要的權(quán)重或結(jié)構(gòu)。非結(jié)構(gòu)化剪枝把單個權(quán)重置零理論上能壓到很高稀疏度但問題是 GPU 對稀疏矩陣的支持有限除非稀疏度超過 90% 且用專門稀疏算子否則實際加速效果很有限。我試過 ResNet34 做 70% 非結(jié)構(gòu)化剪枝模型文件小了但推理速度幾乎沒變因為稠密計算還是要跑。結(jié)構(gòu)化剪枝直接砍掉整個通道、注意力頭或?qū)蛹敉昃褪且粋€小模型不需要特殊硬件支持。代價是精度損失更明顯需要配合微調(diào)恢復(fù)。實踐中我一般先用結(jié)構(gòu)化剪枝砍掉冗余通道再用非結(jié)構(gòu)化剪枝做細(xì)粒度壓縮最后量化收尾。剪枝的判定標(biāo)準(zhǔn)有很多權(quán)重絕對值、梯度信息、BN 層縮放因子等。BN 縮放因子法比較實用因為 BN 的 gamma 參數(shù)本身就反映了通道重要性gamma 接近零的通道基本可以安全砍掉。2.3 推理引擎為什么能加速算子融合與內(nèi)存復(fù)用量化剪枝之后模型結(jié)構(gòu)變了還需要推理引擎來真正把加速落地。推理引擎做的事情包括算子融合把 ConvBNReLU 合成一個算子、內(nèi)存池復(fù)用、kernel 自動調(diào)優(yōu)等。TensorRT、ONNX Runtime、OpenVINO 都是這個層面的工具。算子融合的收益很直觀原本三個 kernel 要讀寫三次顯存融合后一次搞定帶寬省了延遲自然降。內(nèi)存復(fù)用則是提前分配好張量內(nèi)存池避免推理時反復(fù)申請釋放。這些優(yōu)化疊加起來在 780M 核顯這種帶寬受限的硬件上效果尤其明顯。3. 實操全流程從原始模型到優(yōu)化后推理3.1 環(huán)境準(zhǔn)備與依賴安裝先說環(huán)境。NVIDIA 顯卡的話驅(qū)動和 CUDA 是基礎(chǔ)。Ubuntu 上裝驅(qū)動我習(xí)慣用apt而不是官網(wǎng) runfile省得后面內(nèi)核升級出問題sudo apt update sudo apt install nvidia-driver-550 sudo reboot裝完用nvidia-smi確認(rèn)。如果要在 Docker 里跑還需要nvidia-container-toolkitsudo apt install nvidia-container-toolkit sudo systemctl restart dockerPython 側(cè)的核心依賴pip install torch torchvision --index-url https://download.pytorch.org/whl/cu121 pip install onnx onnxruntime-gpu pip install neural-compressor注意CUDA 版本、驅(qū)動版本、PyTorch 版本三者必須匹配。我踩過最坑的一次是驅(qū)動 535 配 CUDA 12.4 的 PyTorch結(jié)果torch.cuda.is_available()一直返回 False查了半天才發(fā)現(xiàn)是驅(qū)動太舊。3.2 量化實操PTQ 校準(zhǔn)與精度驗證以 ResNet34 為例先做 PTQ。核心是準(zhǔn)備校準(zhǔn)數(shù)據(jù)加載器然后調(diào)用量化接口import torch from neural_compressor.quantization import fit from neural_compressor.config import PostTrainingQuantConfig model torch.load(resnet34.pth).eval() calib_dataloader build_calib_loader(batch_size32, num_batches10) config PostTrainingQuantConfig( approachstatic, calibration_sampling_size300, op_type_dict{Conv: {weight: {dtype: [int8]}}} ) q_model fit(model, config, calib_dataloadercalib_dataloader) q_model.save(resnet34_int8)校準(zhǔn)集數(shù)量我一般取 200 到 500 條太少統(tǒng)計不準(zhǔn)太多浪費時間。校準(zhǔn)完之后必須跑驗證集對比精度掉點超過 1% 就要檢查是不是某些層不適合量化。常見的不適合量化的層包括第一層卷積和最后的全連接層可以配置跳過。3.3 剪枝實操結(jié)構(gòu)化剪枝加微調(diào)恢復(fù)剪枝我用的是基于 BN 縮放因子的通道剪枝。流程是先跑一遍訓(xùn)練集統(tǒng)計所有 BN 層的 gamma 分布然后按全局閾值砍掉 gamma 最小的通道最后微調(diào) 10 到 20 個 epoch 恢復(fù)精度。import torch.nn.utils.prune as prune def structured_prune(model, amount0.3): for name, module in model.named_modules(): if isinstance(module, torch.nn.Conv2d): prune.ln_structured(module, nameweight, amountamount, n2, dim0) prune.remove(module, weight) return model剪枝率的選擇很關(guān)鍵。ResNet34 上我試過 20%、30%、40% 三檔30% 是甜點精度掉 1.2% 微調(diào)后能恢復(fù)到 0.3% 以內(nèi)40% 就掉得比較狠了微調(diào)也拉不回來。這個數(shù)字跟模型冗余度有關(guān)不能照搬。3.4 推理引擎部署ONNX 導(dǎo)出與 TensorRT 加速量化剪枝完的模型導(dǎo)出 ONNX再用 TensorRT 做最終加速torch.onnx.export( q_model, dummy_input, resnet34_optimized.onnx, opset_version13, input_names[input], output_names[output], dynamic_axes{input: {0: batch}, output: {0: batch}} )TensorRT 轉(zhuǎn)換時注意dynamic shape的配置如果 batch size 會變要顯式指定 optimization profile。我一般設(shè) min1、opt8、max32覆蓋大部分場景。4. 踩坑實錄那些文檔里不會寫的問題4.1 量化后精度暴跌的排查思路精度暴跌最常見的原因有三個校準(zhǔn)集分布不對、某些層量化敏感、激活值動態(tài)范圍過大。排查順序是先看哪些層量化后誤差最大再針對性跳過或改用混合精度。我遇到過一次第一層卷積量化后精度掉 5%原因是輸入圖像歸一化后范圍是 [-2.1, 2.1]但校準(zhǔn)集里全是接近零的值scale 統(tǒng)計偏了。換成覆蓋完整范圍的校準(zhǔn)集就好了。4.2 剪枝后模型加載報錯的解決剪枝后保存的模型如果直接torch.load可能報 key 不匹配因為剪枝改變了參數(shù)名。解決辦法是剪枝后先prune.remove把 mask 固化到權(quán)重里再保存 state_dict。另外結(jié)構(gòu)化剪枝后模型結(jié)構(gòu)變了加載時要先構(gòu)建剪枝后的模型骨架再 load。4.3 推理引擎兼容性問題速查問題現(xiàn)象可能原因解決方向ONNX 導(dǎo)出失敗算子不支持升級 opset 或替換算子TensorRT 轉(zhuǎn)換報錯動態(tài) shape 未配置設(shè)置 optimization profile推理結(jié)果與 PyTorch 不一致量化誤差累積檢查首尾層是否量化顯存占用沒降中間張量未復(fù)用開啟內(nèi)存池或減小 batch提示ONNX 導(dǎo)出時如果模型里有自定義算子先確認(rèn)目標(biāo)推理引擎是否支持不支持的話要么改寫算子要么換引擎。5. 不同硬件場景下的優(yōu)化策略選擇5.1 消費級顯卡顯存優(yōu)先RTX 4060 Laptop 這種 8GB 顯存的卡優(yōu)化第一優(yōu)先級是顯存。策略是激進量化加適度剪枝INT8 是標(biāo)配必要時上 INT4。batch size 控制在 4 以內(nèi)配合梯度檢查點如果是訓(xùn)練場景。780M 核顯這種沒有獨立顯存的還要考慮內(nèi)存帶寬瓶頸算子融合的收益比量化還大。5.2 數(shù)據(jù)中心卡吞吐優(yōu)先H100 這種卡顯存不是瓶頸優(yōu)化目標(biāo)是吞吐量。這時候量化主要為了用 Tensor Core 的 INT8 算力剪枝要謹(jǐn)慎因為可能破壞并行度。重點是推理引擎的 kernel 調(diào)優(yōu)和 batch 調(diào)度TensorRT 的 builder 優(yōu)化級別開到最大配合 continuous batching 能把吞吐拉滿。5.3 大模型場景KV Cache 與量化組合大模型推理的顯存大頭是 KV Cache不是權(quán)重。Qwen 系列 27B 模型 FP16 權(quán)重約 54GB但長上下文時 KV Cache 能占幾十 GB。這時候權(quán)重量化到 INT4 省不了太多關(guān)鍵是 KV Cache 量化加 PagedAttention 這類內(nèi)存管理技術(shù)。我實測 Qwen3 27B 在單卡上權(quán)重 INT4 加 KV Cache INT8上下文 8K 時顯存從 70GB 壓到 28GB能跑起來了。6. 我個人的幾條實操心得量化剪枝這套東西工具鏈更新很快但底層邏輯幾年沒變過。我的建議是先把 PTQ 跑通理解 scale 和校準(zhǔn)集的關(guān)系再碰 QAT 和剪枝。剪枝率不要貪30% 是個比較安全的起點每加 10% 都要重新驗證精度。推理引擎的選擇上NVIDIA 卡優(yōu)先 TensorRT其他場景 ONNX Runtime 夠用別為了追新工具把穩(wěn)定流程搞亂。還有一點優(yōu)化前后一定要做端到端延遲對比不能只看模型文件大小。我見過剪枝后文件小了一半但推理沒變快的案例因為瓶頸根本不在計算量而在內(nèi)存帶寬。用nsys或者torch.profiler抓一下 timeline看清楚時間花在哪再決定優(yōu)化方向比盲目調(diào)參高效得多。