優(yōu)與部署關(guān)鍵實踐：從指標到實戰(zhàn))
1. 先搞清楚推理性能調(diào)優(yōu)到底在調(diào)什么做AI模型部署的同學(xué)應(yīng)該都有同感模型訓(xùn)練完了只是第一步真正讓人頭疼的是后面那句“上線跑一下”。訓(xùn)練時你關(guān)心loss降沒降、收斂快不快可一旦進入推理階段畫風(fēng)就全變了——延遲、吞吐、顯存占用、首token耗時、并發(fā)能力每一個指標都有可能成為壓垮線上服務(wù)的最后一根稻草。我見過不少團隊把大量精力花在訓(xùn)練調(diào)參上結(jié)果模型一到推理階段就各種翻車GPU利用率上不去、請求一多就超時、顯存莫名其妙OOM?；仡^復(fù)盤問題往往出在“不知道推理性能的瓶頸到底在哪”這件事上。所以這篇文章想認真聊一聊AI模型推理性能調(diào)優(yōu)與部署建議把我在實際項目中踩過的坑、驗證過的方法、以及一些可以直接抄作業(yè)的配置方案分享出來。先給這篇文章定個位如果你正準備把訓(xùn)練好的模型部署成線上服務(wù)或者已經(jīng)在部署但性能不理想這篇文章值得你從頭看到尾。內(nèi)容覆蓋推理性能指標拆解、常見瓶頸定位、模型優(yōu)化手段、部署架構(gòu)選擇、運行時參數(shù)配置、實測調(diào)優(yōu)過程以及高頻故障的排查思路。我會盡量用實際場景說話而不是堆理論。注意文中的所有測試數(shù)據(jù)和配置參數(shù)都來自我本人在某公司內(nèi)部搭建的模擬項目X中的實操記錄硬件環(huán)境為單卡和雙卡兩種方案結(jié)論在同類GPU上具備一定的參考價值但不同架構(gòu)、不同驅(qū)動版本下結(jié)果會有差異建議以實測為準。2. 推理性能的核心指標與瓶頸拆解2.1 別只看單次延遲這些指標同樣重要很多剛接觸部署的同學(xué)習(xí)慣拿“單次推理耗時”來衡量模型快不快但真實線上場景里單次推理耗時只是表象。舉個很簡單的例子一個接口單次推理只要10ms但只能同時處理1個請求另一個接口單次推理要30ms卻能同時處理32個請求。在業(yè)務(wù)并發(fā)較高的時候后者的整體吞吐反而是前者的好幾倍用戶體驗也好得多。推理性能調(diào)優(yōu)時我一般會同時盯住下面幾個核心指標延遲Latency從請求發(fā)出到拿到完整響應(yīng)的時間細分下來還包括首token時間TTFT和每token生成時間TPOT。在線業(yè)務(wù)對延遲特別敏感比如對話類場景首token超過3秒用戶基本就會覺得“卡了”。吞吐量Throughput單位時間內(nèi)能處理的請求數(shù)或token數(shù)。離線批處理場景更看重吞吐比如批量文檔解析、離線生成。GPU利用率這塊很多人會忽略。GPU利用率低往往意味著算子沒有充分利用硬件或者數(shù)據(jù)加載/預(yù)處理成了瓶頸。顯存占用模型權(quán)重、KV Cache、中間激活值、CUDA context加起來分分鐘能把顯存吃滿。并發(fā)能力服務(wù)在同一時刻能支撐的請求連接數(shù)直接決定你能扛多大的業(yè)務(wù)流量。表格整理一下方便對照場景選指標指標適用場景主要瓶頸來源延遲含TTFT/TPOT在線對話、實時交互模型規(guī)模、解碼方式、算子效率吞吐量離線批處理、數(shù)據(jù)生產(chǎn)batch size、并發(fā)數(shù)、顯存帶寬GPU利用率所有場景數(shù)據(jù)加載、CPU預(yù)處理、算子調(diào)度顯存占用所有場景模型權(quán)重、KV Cache、中間激活并發(fā)能力高并發(fā)API服務(wù)框架線程模型、顯存容量、顯存管理策略2.2 推理瓶頸往往不在模型本身我做過的幾個調(diào)優(yōu)案例里印象最深刻的一個是模型本身算力占用不大但接口整體延遲高得離譜。排查到最后發(fā)現(xiàn)問題出在輸入數(shù)據(jù)的預(yù)處理環(huán)節(jié)——每來一個請求服務(wù)端都要做一次圖像解碼、縮放、歸一化而這一步跑在CPU上且是串行執(zhí)行的。GPU在那閑著等數(shù)據(jù)CPU成了瓶頸整個鏈路就被拖慢了。這個案例很有代表性。推理性能調(diào)優(yōu)的第一步永遠是先定位瓶頸而不是盲目上優(yōu)化手段。一般來說瓶頸可能出現(xiàn)在以下幾個位置數(shù)據(jù)預(yù)處理/后處理CPU密集操作、編解碼耗時、數(shù)據(jù)格式轉(zhuǎn)換經(jīng)常被忽視。CPU與GPU之間的數(shù)據(jù)傳輸小批量請求頻繁拷貝數(shù)據(jù)PCIe傳輸耗時占比會非常高。模型計算本身算子實現(xiàn)低效、內(nèi)存訪問模式不佳、圖優(yōu)化未開啟。推理框架與調(diào)度線程數(shù)配置不當(dāng)、顯存分配策略不合理、動態(tài)shape引起的重編譯。服務(wù)端網(wǎng)絡(luò)與IO請求排隊、連接池耗盡、序列化/反序列化開銷。定位瓶頸有一個很樸素但有效的方法先把模型單獨拿出來做一條龍壓測逐步拆解每一段的耗時占比。比如你用profile工具看一遍時間線如果發(fā)現(xiàn)GPU kernel執(zhí)行只占了20%時間其余都在數(shù)據(jù)搬運和CPU處理那砸再多GPU算力也白搭。2.3 用哪個指標判斷優(yōu)化效果調(diào)優(yōu)過程中一定要先定好基準。我推薦的做法是固定同一份測試數(shù)據(jù)集包含不同長度的輸入固定batch size和并發(fā)數(shù)跑足夠多輪取p50/p99延遲同時記錄吞吐量。調(diào)優(yōu)前后對比這些數(shù)據(jù)而不是看單次運氣好的結(jié)果。我自己做調(diào)優(yōu)時第一件事是在服務(wù)里埋好日志記錄每次請求的預(yù)處理耗時、排隊耗時、GPU kernel耗時、后處理耗時。后面所有的優(yōu)化動作都能用數(shù)據(jù)說話哪段耗時長就去優(yōu)化哪段避免憑感覺調(diào)參。3. 模型層面的優(yōu)化從權(quán)重到算子的瘦身術(shù)3.1 模型量化性價比最高的第一刀模型量化是推理性能調(diào)優(yōu)里回報率最高的手段之一。原理很簡單訓(xùn)練時模型權(quán)重通常用FP32或FP16存儲推理時其實沒必要保持這么高的精度把權(quán)重從FP32壓到FP16能直接減半顯存占用從FP16壓到INT8還能再減一半。代價是部分任務(wù)精度會有輕微下降。實際項目中大模型的KV Cache同樣會消耗大量顯存。KV Cache量化比如從FP16壓到INT8甚至INT4可以顯著提升并發(fā)能力因為同樣的顯存可以塞下更多請求的KV緩存。以我在模擬項目X里的一個7B模型為例權(quán)重從FP16切到INT8后單卡能處理的并發(fā)數(shù)從16提升到了28顯存占用降低了約45%。量化落地時有兩點值得特別注意不是所有算子都適合INT8量化。像LayerNorm、Softmax這類對精度敏感的算子通常保持高精度量化主要集中在矩陣乘法和Embedding層。量化后的模型一定要做精度驗證。用一小部分測試集對比量化前后輸出差異超過可接受閾值就需要回退部分層或者改用混合精度方案。表不同量化精度對顯存和速度的影響7B模型實測精度方案顯存占用相對吞吐提升精度損失FP32100%基準1x無FP16/BF16約50%1.6x可忽略INT8約25%2.1x低需驗證INT4約12.5%2.8x中需謹慎3.2 剪枝、蒸餾與模型結(jié)構(gòu)精簡量化解決了存儲和計算強度的問題但很多場景下還需要在結(jié)構(gòu)上做減法這就是模型剪枝和蒸餾的用武之地。模型剪枝的做法是去掉神經(jīng)網(wǎng)絡(luò)中對最終輸出貢獻較小的權(quán)重連接或甚至整個通道。當(dāng)前很多開源模型本身就存在參數(shù)冗余剪掉一部分權(quán)重后精度下降有限但計算量會明顯減少。實際操作中結(jié)構(gòu)化剪枝比非結(jié)構(gòu)化剪枝更適合推理加速因為非結(jié)構(gòu)化剪枝產(chǎn)生的稀疏矩陣在GPU上不太好發(fā)揮除非硬件專門支持稀疏計算。模型蒸餾則是用一個大的教師模型去指導(dǎo)一個小學(xué)生模型學(xué)習(xí)讓小學(xué)生模型在參數(shù)量小很多的情況下盡量逼近教師模型的輸出。蒸餾后的模型精度可能略低但推理成本下降得非常明顯。我見過一個團隊把BERT-base蒸餾成三層的小模型在線問答場景延遲從80ms降到了20ms效果還能接受。選擇哪種手段要看業(yè)務(wù)容忍度毫秒級延遲敏感場景優(yōu)先上蒸餾和小規(guī)模模型別硬扛大模型。離線高吞吐場景可以用量化大批次的方案不用太在意單次延遲。精度要求極高場景盡量保留高精度權(quán)重只在KV Cache和激活值上做溫和量化。3.3 算子融合與計算圖優(yōu)化模型推理時計算圖里有很多細碎的算子頻繁在GPU上啟動內(nèi)核kernel。每個kernel啟動都有固定開銷雖然單次只有幾十微秒但模型里有幾百上千個算子累積起來非常可觀。算子融合就是把相鄰的幾個算子合并成一個減少kernel啟動次數(shù)同時減少中間結(jié)果的讀寫。最經(jīng)典的融合案例是把“矩陣乘法偏置激活函數(shù)”融合成一個算子。比如Transformer里的Attention計算把QKV映射、縮放、Softmax、輸出映射等步驟盡量融合能省掉不少中間顯存讀寫。PyTorch的torch.compile、TensorRT的圖優(yōu)化、ONNX Runtime的graph optimization都在做類似的事。我用torch.compile試過一個12層的Transformer模型在A100上推理延遲直接降了18%且無需改任何業(yè)務(wù)代碼。但要注意torch.compile首次運行會有較長的編譯時間服務(wù)上線時需要預(yù)熱的機制否則第一個請求會特別慢。4. 推理引擎與服務(wù)架構(gòu)的選型邏輯4.1 主流推理引擎橫向?qū)Ρ冗x推理引擎是部署中繞不開的決策點。我用過的方案包括PyTorch原生、ONNX Runtime、TensorRT、以及專門的大模型推理框架如vLLM、TGI、SGLang。各有各的優(yōu)劣勢不存在萬能選擇。引擎優(yōu)勢劣勢適用場景PyTorch原生上手快、兼容好、生態(tài)全性能一般、顯存占用高原型驗證、快速迭代ONNX Runtime跨平臺、優(yōu)化好、部署輕部分算子轉(zhuǎn)換有坑通用模型上云、端側(cè)部署TensorRTGPU上性能極致構(gòu)建時間長、硬件綁定生產(chǎn)環(huán)境、固定shape場景vLLM/TGI大模型專用、吞吐極高依賴特定GPU架構(gòu)對話、生成、大規(guī)模并發(fā)我比較推薦的生產(chǎn)路徑是先用PyTorch做功能和正確性驗證再導(dǎo)出ONNX或直接用TensorRT做性能優(yōu)化。如果模型真的很小或者對上線速度要求極快PyTorch torch.compile也能撐一段時間但后續(xù)擴容時大概率還得換引擎。4.2 單機多卡部署時的切分策略模型大到單卡放不下就得考慮多卡部署。常見的有張量并行、流水線并行和數(shù)據(jù)并行三者解決的問題完全不同。張量并行把一層里的矩陣運算切分到多張卡適合單層計算量極大、顯存放不下的場景。缺點是卡間通信頻繁對NVLink帶寬要求很高。流水線并行把模型按層切分成多段每張卡負責(zé)若干層數(shù)據(jù)按順序流過各卡。適合層數(shù)很深的模型但會出現(xiàn)流水線氣泡利用率不一定理想。數(shù)據(jù)并行每張卡都放完整模型各自處理不同batch的數(shù)據(jù)最后同步梯度或結(jié)果。推理時基本不涉及梯度同步所以擴展性很好。實際部署中這些策略往往組合使用。大模型推理通常先用張量并行解決單卡放不下的問題再用數(shù)據(jù)并行提升整體吞吐。通信開銷是必須重點關(guān)注的如果卡間通信瓶頸嚴重多卡跑的收益可能還不如單卡。我做過一個對比7B模型在單卡上能跑但并發(fā)很低切成兩卡張量并行后單次延遲反而增加了約10%因為通信開銷抵消了算力收益。但對于更大規(guī)模的模型比如70B級不多卡部署根本跑不起來通信開銷屬于必須付出的代價。4.3 動態(tài)batch與Continuous Batching傳統(tǒng)的靜態(tài)batching是等一批請求湊夠數(shù)量再統(tǒng)一推理缺點是等待時間不可控而且batch里長短不一的序列會互相拖累——都得按照最長序列來算浪費嚴重。大模型推理框架普遍引入了Continuous Batching連續(xù)批處理本質(zhì)是不再要求一個batch內(nèi)的請求同進同出。某個請求生成完一個token就退出新請求隨時可以插入GPU始終在處理有效計算。這個機制對吞吐的提升非常明顯。以vLLM為例在同等資源下相同并發(fā)壓測中吞吐往往是Naive PyTorch實現(xiàn)的數(shù)倍。部署時如果想用上Continuous Batching就別自己造輪子了直接選vLLM或TGI這類成熟框架內(nèi)部已經(jīng)實現(xiàn)了顯存管理和調(diào)度邏輯比手寫高效得多。5. 運行時參數(shù)調(diào)優(yōu)與關(guān)鍵配置5.1 顯存管理與緩存策略顯存是推理性能最大的物理約束之一。做大模型推理時顯存主要消耗在三塊模型權(quán)重、KV Cache、臨時激活值。模型權(quán)重基本固定臨時激活值隨batch和序列長度波動KV Cache則是優(yōu)化空間最大的部分。幾個實用的顯存優(yōu)化思路盡量復(fù)用顯存框架層面做好內(nèi)存池避免每次請求都重新分配。vLLM就是通過PagedAttention把KV Cache分塊管理大幅減少了碎片和浪費。調(diào)整KV Cache策略將KV Cache從FP16降到INT8或INT4或者限制最大序列長度能直接提升并發(fā)承載量。開啟顯存不夠時的自動換出部分框架支持把不活躍的請求KV Cache換到CPU內(nèi)存但換入換出會增加延遲適合吞吐優(yōu)先的離線場景。用小batch多迭代如果顯存緊張與其一次塞大batch導(dǎo)致OOM不如拆分幾個小batch控制在顯存安全線以內(nèi)。5.2 線程、并發(fā)與批大小設(shè)置服務(wù)端的線程數(shù)和并發(fā)設(shè)置也是性能調(diào)優(yōu)的關(guān)鍵。PyTorch的CPU線程數(shù)默認可能吃滿所有核心但在GPU推理場景下CPU線程太多反而會帶來上下文切換開銷。建議按以下思路設(shè)置torch.set_num_threads如果預(yù)處理在CPU上執(zhí)行可以預(yù)留一部分CPU核給數(shù)據(jù)加載剩下的給計算線程。模型服務(wù)的max_batch_size不宜盲目設(shè)大。batch增大能提升吞吐但延遲會同步上升需要找到吞吐與延遲的平衡點。我一般壓測時會從1、2、4、8、16逐級往上試觀察p99延遲曲線何時開始拐彎。并發(fā)請求數(shù)壓測時并發(fā)太低可能喂不飽GPU太高又可能導(dǎo)致排隊加劇?？梢杂脡簻y工具逐步加壓監(jiān)控GPU利用率和響應(yīng)時間找到拐點。有一個容易踩的坑動態(tài)shape會導(dǎo)致推理框架在運行時不斷重新編譯或layout變換性能嚴重劣化。我的做法是能固定shape就固定不能固定就限制為幾個離散檔位如長度128/256/512/1024框架內(nèi)做padding到檔位長度。雖然會浪費一點算力但換來的穩(wěn)定性非常值。5.3 預(yù)熱、模型編譯與大模型特有參數(shù)部署服務(wù)上線的第一分鐘往往性能很差。原因是模型首次推理時需要加載權(quán)重、建立cuDNN/tensorRT的benchmark、編譯計算圖。生產(chǎn)環(huán)境一定要做預(yù)熱具體做法是服務(wù)啟動后用幾條具有代表性的數(shù)據(jù)跑幾輪推理把編譯和緩存預(yù)熱到位再開始對外提供流量。大模型推理框架里幾個關(guān)鍵參數(shù)值得重點調(diào)gpu_memory_utilization控制在0.85-0.9之間比較穩(wěn)妥太低浪費顯存太高容易OOM遇到碎片化嚴重時還需要降一點。max_num_seqs / max_num_batched_tokens決定并發(fā)上限需要根據(jù)業(yè)務(wù)峰值設(shè)置。設(shè)太大會導(dǎo)致顯存瞬間爆掉太小則浪費算力。enable_prefix_caching開啟后相同的請求前綴比如系統(tǒng)提示詞的KV Cache可以復(fù)用多輪對話場景收益明顯。streaming輸出對話場景優(yōu)先使用流式輸出用戶感知到的首token延遲會大幅降低。6. 一次完整的推理性能調(diào)優(yōu)案例記錄6.1 壓測準備與基線數(shù)據(jù)我在模擬項目X中部署過一個規(guī)模中等的對話模型單卡初始配置用的是PyTorch原生服務(wù)FP16權(quán)重動態(tài)batch關(guān)閉最大并發(fā)16。壓測用的是一組平均輸入長度512token、輸出長度128token的請求共500條?；€數(shù)據(jù)如下指標數(shù)值平均首token延遲820ms平均總延遲6.4s吞吐量2.8 req/sGPU峰值利用率47%顯存峰值占用15.2GB看到這個數(shù)據(jù)第一個直覺就是GPU利用率太低了只有47%說明大量時間在等待數(shù)據(jù)或者算子沒吃滿。接下來開始逐項優(yōu)化。6.2 逐步優(yōu)化過程與效果第一刀先換推理引擎。我把服務(wù)從PyTorch原生換成了vLLM啟用Continuous Batching和PagedAttention。僅僅這一步吞吐就從2.8 req/s提升到了5.6 req/s翻了一倍。GPU利用率也升到了72%。原因是動態(tài)batch和顯存管理帶來的收益非常直觀。第二刀模型量化。把權(quán)重從FP16量化到INT8KV Cache保持FP16。量化后模型吞吐進一步從5.6提升到7.1 req/s顯存峰值降到了約11.8GB。513條測試數(shù)據(jù)里輸出質(zhì)量對比差異基本看不出來。第三刀優(yōu)化服務(wù)端參數(shù)。把max_num_seqs從16調(diào)高到32gpu_memory_utilization設(shè)為0.88同時開啟prefix caching。吞吐提升到8.3 req/sp99總延遲穩(wěn)在7.8s以內(nèi)。這個時候GPU利用率已經(jīng)達到86%顯存還有約1.5GB余量。第四刀把輸入長度限制為128的倍數(shù)并關(guān)閉動態(tài)shape。這個操作對單次推理延遲的降低有一定幫助首token延遲從平均441ms降到了382ms。最終優(yōu)化后數(shù)據(jù)指標優(yōu)化前優(yōu)化后平均首token延遲820ms382ms平均總延遲6.4s4.1s吞吐量2.8 req/s8.3 req/sGPU峰值利用率47%86%顯存峰值占用15.2GB11.8GB整體吞吐提升了接近3倍延遲下降了36%。整個過程沒有改一行模型代碼完全通過引擎選型、量化、參數(shù)調(diào)優(yōu)實現(xiàn)。這也再次驗證了那個觀點很多性能問題壓根不是模型本身的問題而是部署方案沒選對、配置沒調(diào)好。6.3 多場景下的部署建議匯總根據(jù)不同的業(yè)務(wù)場景我建議的部署策略也不同整理成一個速查表場景推薦方案關(guān)鍵配置在線對話/交互vLLM/TGI INT8量化開啟streaming、prefix caching大規(guī)模離線生產(chǎn)TensorRT 固定shape大batch、高吞吐優(yōu)先端側(cè)/邊緣部署ONNX Runtime 量化壓縮體積、CPU多線程優(yōu)化高精度要求場景FP16/BF16 TensorRT不激進量化只做圖優(yōu)化小模型快速上線PyTorch torch.compile預(yù)熱、限制并發(fā)、避免動態(tài)shape需要注意任何時候都不建議直接上線不經(jīng)過壓測的服務(wù)。即使方案看起來合理也必須在小流量下壓一遍確認真實數(shù)據(jù)而不是紙面推算。7. 常見問題與排查技巧實錄7.1 GPU利用率低總感覺性能沒榨干現(xiàn)象GPU利用率只有30%-50%延遲卻不低。優(yōu)先排查以下環(huán)節(jié)數(shù)據(jù)加載和預(yù)處理是不是在CPU上串行執(zhí)行如果是試試異步數(shù)據(jù)加載、多進程預(yù)處理或者把預(yù)處理算子放到GPU上。請求batch是不是太小小batch喂不飽GPU吞吐自然上不去。是不是存在動態(tài)shape導(dǎo)致的recompile觀察第一次請求后有沒有周期性卡頓有的話就固定shape。是不是CPU線程數(shù)設(shè)置不合理導(dǎo)致線程切換開銷過大。排查工具上我慣用nvidia-smi看實時利用率配合Nsight Systems看完整時間線能非常清楚地看到每個環(huán)節(jié)的耗時占比。如果沒有這類工具也可以用簡單的計時埋點把預(yù)處理、傳輸、推理、后處理每一段時間打印出來。7.2 顯存OOM與溢出問題顯存OOM是部署中最常見的故障之一。OOM不一定代表顯存總量不夠更多時候是分配策略或者某個突發(fā)峰值導(dǎo)致。排查思路先分清是權(quán)重放不下還是運行時峰值超了。如果是權(quán)重放不下直接量化權(quán)重或者換多卡部署。如果是運行期峰值超了調(diào)整batch大小、限制max_num_seqs、降低gpu_memory_utilization、縮小或量化KV Cache。還有一種情況是顯存碎片化服務(wù)跑了一段時間后OOM但重啟就好。這是因為不斷分配和釋放不同大小的顯存塊碎片越來越多。vLLM這類框架的PagedAttention能大幅緩解碎片問題用PyTorch原生的話可以考慮顯存池或定期重啟服務(wù)的土辦法不優(yōu)雅但管用。7.3 首token延遲高但整體吞吐正常如果首token延遲特別高多半卡在prefill階段也就是處理輸入Prompt階段。大模型解碼分兩段prefill把整段輸入一次性算完generate階段才逐token生成。輸入越長prefill耗時越高。優(yōu)化手段包括讓模型支持并行prefill某些框架默認支持?？s短輸入的無效內(nèi)容從業(yè)務(wù)層做輸入裁剪。用chunked prefill機制把超長輸入拆成小塊逐步計算避免一次性算完導(dǎo)致延遲尖刺。開啟prefix caching多輪對話和共用system prompt時效果明顯。調(diào)低并發(fā)減少排隊等待時間。7.4 并發(fā)高時延遲快速劣化并發(fā)一高延遲就起飛通常有兩個原因一是請求排隊時間過長二是顯存不夠?qū)е翶V Cache被換出。應(yīng)對方法優(yōu)先保證p99延遲在容忍范圍內(nèi)適當(dāng)通過限流控制并發(fā)數(shù)量。開連續(xù)批處理避免靜態(tài)batch帶來的等待效應(yīng)。增加服務(wù)實例利用水平擴展分散壓力。如果單機已經(jīng)是極限就需要考慮多卡或分布式部署了。8. 最后的實操心得分享幾個我在多次上線部署中學(xué)到的經(jīng)驗不算什么高深理論但真的能救命第一性能調(diào)優(yōu)一定要以監(jiān)控數(shù)據(jù)為驅(qū)動。不要看感覺不要憑經(jīng)驗猜。每個優(yōu)化動作前后都要有明確的指標對比這樣出了問題才能快速回滾也不會白忙一場。第二不要把所有雞蛋放在一個籃子里。推理引擎、量化方案、服務(wù)架構(gòu)這些組件盡量做成可切換的。我見過一些團隊把TensorRT優(yōu)化后的模型寫死進代碼里后來模型迭代了TensorRT重新構(gòu)建要花好幾個小時上線節(jié)奏被拖得很慘。合理做法是把優(yōu)化鏈路自動化模型一變構(gòu)建流程自動跑一遍產(chǎn)物自動驗證。第三注意壓測數(shù)據(jù)的代表性。很多人拿固定長度的輸入做壓測看起來數(shù)據(jù)很漂亮一上真實業(yè)務(wù)就被長短不一的輸入打回原形。建議壓測數(shù)據(jù)的長度分布盡量貼近線上真實請求否則調(diào)出來的參數(shù)很容易在真實場景翻車。第四小步快跑一次只改一個變量。同時換引擎、開量化、改并發(fā)配置如果性能有波動根本分不清是哪一步引起的。我習(xí)慣一次只調(diào)整一項跑一輪壓測記錄數(shù)據(jù)然后再動下一項。調(diào)優(yōu)過程會慢一些但每步結(jié)論都很扎實。推理性能調(diào)優(yōu)是一個系統(tǒng)工程從模型結(jié)構(gòu)化簡、量化、算子融合到推理引擎選型、服務(wù)架構(gòu)設(shè)計、運行時參數(shù)配置每一環(huán)都有文章可做。這篇文章算是我近期實操的一份沉淀也希望能幫你少走一些彎路。如果你手頭正好有模型要部署不妨先從基線測試開始一步步來。 AI模型推理性能調(diào)優(yōu)與部署關(guān)鍵實踐：從指標到實戰(zhàn)
1. 先搞清楚推理性能調(diào)優(yōu)到底在調(diào)什么做AI模型部署的同學(xué)應(yīng)該都有同感模型訓(xùn)練完了只是第一步真正讓人頭疼的是后面那句“上線跑一下”。訓(xùn)練時你關(guān)心loss降沒降、收斂快不快可一旦進入推理階段畫風(fēng)就全變了——延遲、吞吐、顯存占用、首token耗時、并發(fā)能力每一個指標都有可能成為壓垮線上服務(wù)的最后一根稻草。我見過不少團隊把大量精力花在訓(xùn)練調(diào)參上結(jié)果模型一到推理階段就各種翻車GPU利用率上不去、請求一多就超時、顯存莫名其妙OOM?；仡^復(fù)盤問題往往出在“不知道推理性能的瓶頸到底在哪”這件事上。所以這篇文章想認真聊一聊AI模型推理性能調(diào)優(yōu)與部署建議把我在實際項目中踩過的坑、驗證過的方法、以及一些可以直接抄作業(yè)的配置方案分享出來。先給這篇文章定個位如果你正準備把訓(xùn)練好的模型部署成線上服務(wù)或者已經(jīng)在部署但性能不理想這篇文章值得你從頭看到尾。內(nèi)容覆蓋推理性能指標拆解、常見瓶頸定位、模型優(yōu)化手段、部署架構(gòu)選擇、運行時參數(shù)配置、實測調(diào)優(yōu)過程以及高頻故障的排查思路。我會盡量用實際場景說話而不是堆理論。注意文中的所有測試數(shù)據(jù)和配置參數(shù)都來自我本人在某公司內(nèi)部搭建的模擬項目X中的實操記錄硬件環(huán)境為單卡和雙卡兩種方案結(jié)論在同類GPU上具備一定的參考價值但不同架構(gòu)、不同驅(qū)動版本下結(jié)果會有差異建議以實測為準。2. 推理性能的核心指標與瓶頸拆解2.1 別只看單次延遲這些指標同樣重要很多剛接觸部署的同學(xué)習(xí)慣拿“單次推理耗時”來衡量模型快不快但真實線上場景里單次推理耗時只是表象。舉個很簡單的例子一個接口單次推理只要10ms但只能同時處理1個請求另一個接口單次推理要30ms卻能同時處理32個請求。在業(yè)務(wù)并發(fā)較高的時候后者的整體吞吐反而是前者的好幾倍用戶體驗也好得多。推理性能調(diào)優(yōu)時我一般會同時盯住下面幾個核心指標延遲Latency從請求發(fā)出到拿到完整響應(yīng)的時間細分下來還包括首token時間TTFT和每token生成時間TPOT。在線業(yè)務(wù)對延遲特別敏感比如對話類場景首token超過3秒用戶基本就會覺得“卡了”。吞吐量Throughput單位時間內(nèi)能處理的請求數(shù)或token數(shù)。離線批處理場景更看重吞吐比如批量文檔解析、離線生成。GPU利用率這塊很多人會忽略。GPU利用率低往往意味著算子沒有充分利用硬件或者數(shù)據(jù)加載/預(yù)處理成了瓶頸。顯存占用模型權(quán)重、KV Cache、中間激活值、CUDA context加起來分分鐘能把顯存吃滿。并發(fā)能力服務(wù)在同一時刻能支撐的請求連接數(shù)直接決定你能扛多大的業(yè)務(wù)流量。表格整理一下方便對照場景選指標指標適用場景主要瓶頸來源延遲含TTFT/TPOT在線對話、實時交互模型規(guī)模、解碼方式、算子效率吞吐量離線批處理、數(shù)據(jù)生產(chǎn)batch size、并發(fā)數(shù)、顯存帶寬GPU利用率所有場景數(shù)據(jù)加載、CPU預(yù)處理、算子調(diào)度顯存占用所有場景模型權(quán)重、KV Cache、中間激活并發(fā)能力高并發(fā)API服務(wù)框架線程模型、顯存容量、顯存管理策略2.2 推理瓶頸往往不在模型本身我做過的幾個調(diào)優(yōu)案例里印象最深刻的一個是模型本身算力占用不大但接口整體延遲高得離譜。排查到最后發(fā)現(xiàn)問題出在輸入數(shù)據(jù)的預(yù)處理環(huán)節(jié)——每來一個請求服務(wù)端都要做一次圖像解碼、縮放、歸一化而這一步跑在CPU上且是串行執(zhí)行的。GPU在那閑著等數(shù)據(jù)CPU成了瓶頸整個鏈路就被拖慢了。這個案例很有代表性。推理性能調(diào)優(yōu)的第一步永遠是先定位瓶頸而不是盲目上優(yōu)化手段。一般來說瓶頸可能出現(xiàn)在以下幾個位置數(shù)據(jù)預(yù)處理/后處理CPU密集操作、編解碼耗時、數(shù)據(jù)格式轉(zhuǎn)換經(jīng)常被忽視。CPU與GPU之間的數(shù)據(jù)傳輸小批量請求頻繁拷貝數(shù)據(jù)PCIe傳輸耗時占比會非常高。模型計算本身算子實現(xiàn)低效、內(nèi)存訪問模式不佳、圖優(yōu)化未開啟。推理框架與調(diào)度線程數(shù)配置不當(dāng)、顯存分配策略不合理、動態(tài)shape引起的重編譯。服務(wù)端網(wǎng)絡(luò)與IO請求排隊、連接池耗盡、序列化/反序列化開銷。定位瓶頸有一個很樸素但有效的方法先把模型單獨拿出來做一條龍壓測逐步拆解每一段的耗時占比。比如你用profile工具看一遍時間線如果發(fā)現(xiàn)GPU kernel執(zhí)行只占了20%時間其余都在數(shù)據(jù)搬運和CPU處理那砸再多GPU算力也白搭。2.3 用哪個指標判斷優(yōu)化效果調(diào)優(yōu)過程中一定要先定好基準。我推薦的做法是固定同一份測試數(shù)據(jù)集包含不同長度的輸入固定batch size和并發(fā)數(shù)跑足夠多輪取p50/p99延遲同時記錄吞吐量。調(diào)優(yōu)前后對比這些數(shù)據(jù)而不是看單次運氣好的結(jié)果。我自己做調(diào)優(yōu)時第一件事是在服務(wù)里埋好日志記錄每次請求的預(yù)處理耗時、排隊耗時、GPU kernel耗時、后處理耗時。后面所有的優(yōu)化動作都能用數(shù)據(jù)說話哪段耗時長就去優(yōu)化哪段避免憑感覺調(diào)參。3. 模型層面的優(yōu)化從權(quán)重到算子的瘦身術(shù)3.1 模型量化性價比最高的第一刀模型量化是推理性能調(diào)優(yōu)里回報率最高的手段之一。原理很簡單訓(xùn)練時模型權(quán)重通常用FP32或FP16存儲推理時其實沒必要保持這么高的精度把權(quán)重從FP32壓到FP16能直接減半顯存占用從FP16壓到INT8還能再減一半。代價是部分任務(wù)精度會有輕微下降。實際項目中大模型的KV Cache同樣會消耗大量顯存。KV Cache量化比如從FP16壓到INT8甚至INT4可以顯著提升并發(fā)能力因為同樣的顯存可以塞下更多請求的KV緩存。以我在模擬項目X里的一個7B模型為例權(quán)重從FP16切到INT8后單卡能處理的并發(fā)數(shù)從16提升到了28顯存占用降低了約45%。量化落地時有兩點值得特別注意不是所有算子都適合INT8量化。像LayerNorm、Softmax這類對精度敏感的算子通常保持高精度量化主要集中在矩陣乘法和Embedding層。量化后的模型一定要做精度驗證。用一小部分測試集對比量化前后輸出差異超過可接受閾值就需要回退部分層或者改用混合精度方案。表不同量化精度對顯存和速度的影響7B模型實測精度方案顯存占用相對吞吐提升精度損失FP32100%基準1x無FP16/BF16約50%1.6x可忽略INT8約25%2.1x低需驗證INT4約12.5%2.8x中需謹慎3.2 剪枝、蒸餾與模型結(jié)構(gòu)精簡量化解決了存儲和計算強度的問題但很多場景下還需要在結(jié)構(gòu)上做減法這就是模型剪枝和蒸餾的用武之地。模型剪枝的做法是去掉神經(jīng)網(wǎng)絡(luò)中對最終輸出貢獻較小的權(quán)重連接或甚至整個通道。當(dāng)前很多開源模型本身就存在參數(shù)冗余剪掉一部分權(quán)重后精度下降有限但計算量會明顯減少。實際操作中結(jié)構(gòu)化剪枝比非結(jié)構(gòu)化剪枝更適合推理加速因為非結(jié)構(gòu)化剪枝產(chǎn)生的稀疏矩陣在GPU上不太好發(fā)揮除非硬件專門支持稀疏計算。模型蒸餾則是用一個大的教師模型去指導(dǎo)一個小學(xué)生模型學(xué)習(xí)讓小學(xué)生模型在參數(shù)量小很多的情況下盡量逼近教師模型的輸出。蒸餾后的模型精度可能略低但推理成本下降得非常明顯。我見過一個團隊把BERT-base蒸餾成三層的小模型在線問答場景延遲從80ms降到了20ms效果還能接受。選擇哪種手段要看業(yè)務(wù)容忍度毫秒級延遲敏感場景優(yōu)先上蒸餾和小規(guī)模模型別硬扛大模型。離線高吞吐場景可以用量化大批次的方案不用太在意單次延遲。精度要求極高場景盡量保留高精度權(quán)重只在KV Cache和激活值上做溫和量化。3.3 算子融合與計算圖優(yōu)化模型推理時計算圖里有很多細碎的算子頻繁在GPU上啟動內(nèi)核kernel。每個kernel啟動都有固定開銷雖然單次只有幾十微秒但模型里有幾百上千個算子累積起來非常可觀。算子融合就是把相鄰的幾個算子合并成一個減少kernel啟動次數(shù)同時減少中間結(jié)果的讀寫。最經(jīng)典的融合案例是把“矩陣乘法偏置激活函數(shù)”融合成一個算子。比如Transformer里的Attention計算把QKV映射、縮放、Softmax、輸出映射等步驟盡量融合能省掉不少中間顯存讀寫。PyTorch的torch.compile、TensorRT的圖優(yōu)化、ONNX Runtime的graph optimization都在做類似的事。我用torch.compile試過一個12層的Transformer模型在A100上推理延遲直接降了18%且無需改任何業(yè)務(wù)代碼。但要注意torch.compile首次運行會有較長的編譯時間服務(wù)上線時需要預(yù)熱的機制否則第一個請求會特別慢。4. 推理引擎與服務(wù)架構(gòu)的選型邏輯4.1 主流推理引擎橫向?qū)Ρ冗x推理引擎是部署中繞不開的決策點。我用過的方案包括PyTorch原生、ONNX Runtime、TensorRT、以及專門的大模型推理框架如vLLM、TGI、SGLang。各有各的優(yōu)劣勢不存在萬能選擇。引擎優(yōu)勢劣勢適用場景PyTorch原生上手快、兼容好、生態(tài)全性能一般、顯存占用高原型驗證、快速迭代ONNX Runtime跨平臺、優(yōu)化好、部署輕部分算子轉(zhuǎn)換有坑通用模型上云、端側(cè)部署TensorRTGPU上性能極致構(gòu)建時間長、硬件綁定生產(chǎn)環(huán)境、固定shape場景vLLM/TGI大模型專用、吞吐極高依賴特定GPU架構(gòu)對話、生成、大規(guī)模并發(fā)我比較推薦的生產(chǎn)路徑是先用PyTorch做功能和正確性驗證再導(dǎo)出ONNX或直接用TensorRT做性能優(yōu)化。如果模型真的很小或者對上線速度要求極快PyTorch torch.compile也能撐一段時間但后續(xù)擴容時大概率還得換引擎。4.2 單機多卡部署時的切分策略模型大到單卡放不下就得考慮多卡部署。常見的有張量并行、流水線并行和數(shù)據(jù)并行三者解決的問題完全不同。張量并行把一層里的矩陣運算切分到多張卡適合單層計算量極大、顯存放不下的場景。缺點是卡間通信頻繁對NVLink帶寬要求很高。流水線并行把模型按層切分成多段每張卡負責(zé)若干層數(shù)據(jù)按順序流過各卡。適合層數(shù)很深的模型但會出現(xiàn)流水線氣泡利用率不一定理想。數(shù)據(jù)并行每張卡都放完整模型各自處理不同batch的數(shù)據(jù)最后同步梯度或結(jié)果。推理時基本不涉及梯度同步所以擴展性很好。實際部署中這些策略往往組合使用。大模型推理通常先用張量并行解決單卡放不下的問題再用數(shù)據(jù)并行提升整體吞吐。通信開銷是必須重點關(guān)注的如果卡間通信瓶頸嚴重多卡跑的收益可能還不如單卡。我做過一個對比7B模型在單卡上能跑但并發(fā)很低切成兩卡張量并行后單次延遲反而增加了約10%因為通信開銷抵消了算力收益。但對于更大規(guī)模的模型比如70B級不多卡部署根本跑不起來通信開銷屬于必須付出的代價。4.3 動態(tài)batch與Continuous Batching傳統(tǒng)的靜態(tài)batching是等一批請求湊夠數(shù)量再統(tǒng)一推理缺點是等待時間不可控而且batch里長短不一的序列會互相拖累——都得按照最長序列來算浪費嚴重。大模型推理框架普遍引入了Continuous Batching連續(xù)批處理本質(zhì)是不再要求一個batch內(nèi)的請求同進同出。某個請求生成完一個token就退出新請求隨時可以插入GPU始終在處理有效計算。這個機制對吞吐的提升非常明顯。以vLLM為例在同等資源下相同并發(fā)壓測中吞吐往往是Naive PyTorch實現(xiàn)的數(shù)倍。部署時如果想用上Continuous Batching就別自己造輪子了直接選vLLM或TGI這類成熟框架內(nèi)部已經(jīng)實現(xiàn)了顯存管理和調(diào)度邏輯比手寫高效得多。5. 運行時參數(shù)調(diào)優(yōu)與關(guān)鍵配置5.1 顯存管理與緩存策略顯存是推理性能最大的物理約束之一。做大模型推理時顯存主要消耗在三塊模型權(quán)重、KV Cache、臨時激活值。模型權(quán)重基本固定臨時激活值隨batch和序列長度波動KV Cache則是優(yōu)化空間最大的部分。幾個實用的顯存優(yōu)化思路盡量復(fù)用顯存框架層面做好內(nèi)存池避免每次請求都重新分配。vLLM就是通過PagedAttention把KV Cache分塊管理大幅減少了碎片和浪費。調(diào)整KV Cache策略將KV Cache從FP16降到INT8或INT4或者限制最大序列長度能直接提升并發(fā)承載量。開啟顯存不夠時的自動換出部分框架支持把不活躍的請求KV Cache換到CPU內(nèi)存但換入換出會增加延遲適合吞吐優(yōu)先的離線場景。用小batch多迭代如果顯存緊張與其一次塞大batch導(dǎo)致OOM不如拆分幾個小batch控制在顯存安全線以內(nèi)。5.2 線程、并發(fā)與批大小設(shè)置服務(wù)端的線程數(shù)和并發(fā)設(shè)置也是性能調(diào)優(yōu)的關(guān)鍵。PyTorch的CPU線程數(shù)默認可能吃滿所有核心但在GPU推理場景下CPU線程太多反而會帶來上下文切換開銷。建議按以下思路設(shè)置torch.set_num_threads如果預(yù)處理在CPU上執(zhí)行可以預(yù)留一部分CPU核給數(shù)據(jù)加載剩下的給計算線程。模型服務(wù)的max_batch_size不宜盲目設(shè)大。batch增大能提升吞吐但延遲會同步上升需要找到吞吐與延遲的平衡點。我一般壓測時會從1、2、4、8、16逐級往上試觀察p99延遲曲線何時開始拐彎。并發(fā)請求數(shù)壓測時并發(fā)太低可能喂不飽GPU太高又可能導(dǎo)致排隊加劇?？梢杂脡簻y工具逐步加壓監(jiān)控GPU利用率和響應(yīng)時間找到拐點。有一個容易踩的坑動態(tài)shape會導(dǎo)致推理框架在運行時不斷重新編譯或layout變換性能嚴重劣化。我的做法是能固定shape就固定不能固定就限制為幾個離散檔位如長度128/256/512/1024框架內(nèi)做padding到檔位長度。雖然會浪費一點算力但換來的穩(wěn)定性非常值。5.3 預(yù)熱、模型編譯與大模型特有參數(shù)部署服務(wù)上線的第一分鐘往往性能很差。原因是模型首次推理時需要加載權(quán)重、建立cuDNN/tensorRT的benchmark、編譯計算圖。生產(chǎn)環(huán)境一定要做預(yù)熱具體做法是服務(wù)啟動后用幾條具有代表性的數(shù)據(jù)跑幾輪推理把編譯和緩存預(yù)熱到位再開始對外提供流量。大模型推理框架里幾個關(guān)鍵參數(shù)值得重點調(diào)gpu_memory_utilization控制在0.85-0.9之間比較穩(wěn)妥太低浪費顯存太高容易OOM遇到碎片化嚴重時還需要降一點。max_num_seqs / max_num_batched_tokens決定并發(fā)上限需要根據(jù)業(yè)務(wù)峰值設(shè)置。設(shè)太大會導(dǎo)致顯存瞬間爆掉太小則浪費算力。enable_prefix_caching開啟后相同的請求前綴比如系統(tǒng)提示詞的KV Cache可以復(fù)用多輪對話場景收益明顯。streaming輸出對話場景優(yōu)先使用流式輸出用戶感知到的首token延遲會大幅降低。6. 一次完整的推理性能調(diào)優(yōu)案例記錄6.1 壓測準備與基線數(shù)據(jù)我在模擬項目X中部署過一個規(guī)模中等的對話模型單卡初始配置用的是PyTorch原生服務(wù)FP16權(quán)重動態(tài)batch關(guān)閉最大并發(fā)16。壓測用的是一組平均輸入長度512token、輸出長度128token的請求共500條?；€數(shù)據(jù)如下指標數(shù)值平均首token延遲820ms平均總延遲6.4s吞吐量2.8 req/sGPU峰值利用率47%顯存峰值占用15.2GB看到這個數(shù)據(jù)第一個直覺就是GPU利用率太低了只有47%說明大量時間在等待數(shù)據(jù)或者算子沒吃滿。接下來開始逐項優(yōu)化。6.2 逐步優(yōu)化過程與效果第一刀先換推理引擎。我把服務(wù)從PyTorch原生換成了vLLM啟用Continuous Batching和PagedAttention。僅僅這一步吞吐就從2.8 req/s提升到了5.6 req/s翻了一倍。GPU利用率也升到了72%。原因是動態(tài)batch和顯存管理帶來的收益非常直觀。第二刀模型量化。把權(quán)重從FP16量化到INT8KV Cache保持FP16。量化后模型吞吐進一步從5.6提升到7.1 req/s顯存峰值降到了約11.8GB。513條測試數(shù)據(jù)里輸出質(zhì)量對比差異基本看不出來。第三刀優(yōu)化服務(wù)端參數(shù)。把max_num_seqs從16調(diào)高到32gpu_memory_utilization設(shè)為0.88同時開啟prefix caching。吞吐提升到8.3 req/sp99總延遲穩(wěn)在7.8s以內(nèi)。這個時候GPU利用率已經(jīng)達到86%顯存還有約1.5GB余量。第四刀把輸入長度限制為128的倍數(shù)并關(guān)閉動態(tài)shape。這個操作對單次推理延遲的降低有一定幫助首token延遲從平均441ms降到了382ms。最終優(yōu)化后數(shù)據(jù)指標優(yōu)化前優(yōu)化后平均首token延遲820ms382ms平均總延遲6.4s4.1s吞吐量2.8 req/s8.3 req/sGPU峰值利用率47%86%顯存峰值占用15.2GB11.8GB整體吞吐提升了接近3倍延遲下降了36%。整個過程沒有改一行模型代碼完全通過引擎選型、量化、參數(shù)調(diào)優(yōu)實現(xiàn)。這也再次驗證了那個觀點很多性能問題壓根不是模型本身的問題而是部署方案沒選對、配置沒調(diào)好。6.3 多場景下的部署建議匯總根據(jù)不同的業(yè)務(wù)場景我建議的部署策略也不同整理成一個速查表場景推薦方案關(guān)鍵配置在線對話/交互vLLM/TGI INT8量化開啟streaming、prefix caching大規(guī)模離線生產(chǎn)TensorRT 固定shape大batch、高吞吐優(yōu)先端側(cè)/邊緣部署ONNX Runtime 量化壓縮體積、CPU多線程優(yōu)化高精度要求場景FP16/BF16 TensorRT不激進量化只做圖優(yōu)化小模型快速上線PyTorch torch.compile預(yù)熱、限制并發(fā)、避免動態(tài)shape需要注意任何時候都不建議直接上線不經(jīng)過壓測的服務(wù)。即使方案看起來合理也必須在小流量下壓一遍確認真實數(shù)據(jù)而不是紙面推算。7. 常見問題與排查技巧實錄7.1 GPU利用率低總感覺性能沒榨干現(xiàn)象GPU利用率只有30%-50%延遲卻不低。優(yōu)先排查以下環(huán)節(jié)數(shù)據(jù)加載和預(yù)處理是不是在CPU上串行執(zhí)行如果是試試異步數(shù)據(jù)加載、多進程預(yù)處理或者把預(yù)處理算子放到GPU上。請求batch是不是太小小batch喂不飽GPU吞吐自然上不去。是不是存在動態(tài)shape導(dǎo)致的recompile觀察第一次請求后有沒有周期性卡頓有的話就固定shape。是不是CPU線程數(shù)設(shè)置不合理導(dǎo)致線程切換開銷過大。排查工具上我慣用nvidia-smi看實時利用率配合Nsight Systems看完整時間線能非常清楚地看到每個環(huán)節(jié)的耗時占比。如果沒有這類工具也可以用簡單的計時埋點把預(yù)處理、傳輸、推理、后處理每一段時間打印出來。7.2 顯存OOM與溢出問題顯存OOM是部署中最常見的故障之一。OOM不一定代表顯存總量不夠更多時候是分配策略或者某個突發(fā)峰值導(dǎo)致。排查思路先分清是權(quán)重放不下還是運行時峰值超了。如果是權(quán)重放不下直接量化權(quán)重或者換多卡部署。如果是運行期峰值超了調(diào)整batch大小、限制max_num_seqs、降低gpu_memory_utilization、縮小或量化KV Cache。還有一種情況是顯存碎片化服務(wù)跑了一段時間后OOM但重啟就好。這是因為不斷分配和釋放不同大小的顯存塊碎片越來越多。vLLM這類框架的PagedAttention能大幅緩解碎片問題用PyTorch原生的話可以考慮顯存池或定期重啟服務(wù)的土辦法不優(yōu)雅但管用。7.3 首token延遲高但整體吞吐正常如果首token延遲特別高多半卡在prefill階段也就是處理輸入Prompt階段。大模型解碼分兩段prefill把整段輸入一次性算完generate階段才逐token生成。輸入越長prefill耗時越高。優(yōu)化手段包括讓模型支持并行prefill某些框架默認支持?？s短輸入的無效內(nèi)容從業(yè)務(wù)層做輸入裁剪。用chunked prefill機制把超長輸入拆成小塊逐步計算避免一次性算完導(dǎo)致延遲尖刺。開啟prefix caching多輪對話和共用system prompt時效果明顯。調(diào)低并發(fā)減少排隊等待時間。7.4 并發(fā)高時延遲快速劣化并發(fā)一高延遲就起飛通常有兩個原因一是請求排隊時間過長二是顯存不夠?qū)е翶V Cache被換出。應(yīng)對方法優(yōu)先保證p99延遲在容忍范圍內(nèi)適當(dāng)通過限流控制并發(fā)數(shù)量。開連續(xù)批處理避免靜態(tài)batch帶來的等待效應(yīng)。增加服務(wù)實例利用水平擴展分散壓力。如果單機已經(jīng)是極限就需要考慮多卡或分布式部署了。8. 最后的實操心得分享幾個我在多次上線部署中學(xué)到的經(jīng)驗不算什么高深理論但真的能救命第一性能調(diào)優(yōu)一定要以監(jiān)控數(shù)據(jù)為驅(qū)動。不要看感覺不要憑經(jīng)驗猜。每個優(yōu)化動作前后都要有明確的指標對比這樣出了問題才能快速回滾也不會白忙一場。第二不要把所有雞蛋放在一個籃子里。推理引擎、量化方案、服務(wù)架構(gòu)這些組件盡量做成可切換的。我見過一些團隊把TensorRT優(yōu)化后的模型寫死進代碼里后來模型迭代了TensorRT重新構(gòu)建要花好幾個小時上線節(jié)奏被拖得很慘。合理做法是把優(yōu)化鏈路自動化模型一變構(gòu)建流程自動跑一遍產(chǎn)物自動驗證。第三注意壓測數(shù)據(jù)的代表性。很多人拿固定長度的輸入做壓測看起來數(shù)據(jù)很漂亮一上真實業(yè)務(wù)就被長短不一的輸入打回原形。建議壓測數(shù)據(jù)的長度分布盡量貼近線上真實請求否則調(diào)出來的參數(shù)很容易在真實場景翻車。第四小步快跑一次只改一個變量。同時換引擎、開量化、改并發(fā)配置如果性能有波動根本分不清是哪一步引起的。我習(xí)慣一次只調(diào)整一項跑一輪壓測記錄數(shù)據(jù)然后再動下一項。調(diào)優(yōu)過程會慢一些但每步結(jié)論都很扎實。推理性能調(diào)優(yōu)是一個系統(tǒng)工程從模型結(jié)構(gòu)化簡、量化、算子融合到推理引擎選型、服務(wù)架構(gòu)設(shè)計、運行時參數(shù)配置每一環(huán)都有文章可做。這篇文章算是我近期實操的一份沉淀也希望能幫你少走一些彎路。如果你手頭正好有模型要部署不妨先從基線測試開始一步步來。