1. 推理延遲的賬單是怎么算出來的先搞懂瓶頸在內存帶寬而不是算力先說個真實場景。某公司內部基于開源模型搭了個智能助手模型選的是7B級別顯卡拉滿到8卡A100結果上線第一天就炸了——并發(fā)一超過20路P99響應時間直接飆到8秒開外GPU利用率卻只有可憐的15%。當時團隊所有人的第一反應都是算力不夠加卡。但把profiling數(shù)據(jù)拉出來一看問題根本不是算力不夠是顯存帶寬被吃滿了。這件事其實是絕大多數(shù)LLM推理項目的通病我們對大模型的直覺還停留在訓練很貴、推理應該還好的階段但訓練和推理的成本結構完全相反。訓練是計算密集型矩陣乘法吃得越滿越好推理的自回歸解碼autoregressive decoding則是每次只生成一個token而且每個token的生成都要把整個模型權重從顯存里讀一遍。7B模型光權重就接近14GBFP16H100的顯存帶寬約3.35TB/s理想情況下每生成一個token至少要讀一次全量權重這決定了單token的理論延遲下限。你可以把整個推理過程類比成一個人查字典寫作文每寫一個字都得把整本字典從頭翻一遍找到合適的詞再落筆。翻字典這個動作消耗的時間遠比想這個詞怎么寫要多得多。所以真正制約推理速度的是翻字典的速度——也就是顯存帶寬——而不是你的腦子轉得多快。實際測算方法很簡單。以7B模型、FP16精度為例單token生成需要讀取的權重量14GB顯存帶寬按3TB/s估算H100/A100級別單token純讀取耗時14GB ÷ 3TB/s ≈ 4.6ms這還沒算KV Cache讀取、注意力計算、采樣等開銷。如果再疊加并發(fā)場景所有并發(fā)請求都在搶同一條帶寬單token延遲會進一步惡化。所以推理優(yōu)化的核心命題不是把算力用得更滿而是把每次翻字典的代價降下來——要么少翻幾頁量化、剪枝、蒸餾要么翻得更快更短緩存、投機解碼、調度優(yōu)化。這部分認知不建立起來后面所有優(yōu)化動作都會變成瞎調參。下面我按實際項目的推進順序把每一步能拿到什么收益、會踩什么坑原原本本過一遍。2. 量化不是無腦降精度權重INT4 KV Cache INT8的組合玩法量化是推理優(yōu)化里見效最快的一招也是最容易翻車的一招。很多人一上來就上INT4結果模型回答質量肉眼可見地下降然后又灰溜溜調回FP16。根本原因在于他們對量化的敏感度分布沒有概念把量化精度理解成了全局統(tǒng)一降準。2.1 哪些層對量化敏感哪些層無所謂以我實際做過的7B/13B模型實測來看注意力層的QKV投影對量化非常敏感而MLP層尤其是Feed Forward Network的前兩層投影相對鈍感。直觀理解是QKV的輸出會被拿去算注意力分數(shù)這是模型做信息路由的關鍵環(huán)節(jié)稍微有點精度損失就會導致該注意的地方?jīng)]注意到而MLP本質是高維空間的特征變換誤差經(jīng)過ReLU/SiLU這類非線性激活會被部分抹平。所以現(xiàn)在業(yè)界主流的方案已經(jīng)不太推薦純靠訓練后量化PTQ一把梭而是用帶權重重要性感知的量化方法。我在工程里長期用的組合是權重部分用INT4量化配合AWQ或GPTQ方案KV Cache部分用INT8量化激活值activation保持FP16這個組合的收益是顯存占用大幅下降同時質量損失基本可控。7B模型FP16權重占約14GBINT4量化后降到約4GB加上KV Cache的INT8化一共能省出接近10GB的顯存。這意味著原來只能放下一個7B模型的機器現(xiàn)在可以同時跑兩個或者把上下文長度從8K拉到32K級別。2.2 AWQ和GPTQ怎么選、按什么標準選AWQ和GPTQ是目前開源生態(tài)里用得最多的兩種方法區(qū)別在于它們解決問題的路徑不同GPTQ的思路是逐層量化、按列做誤差補償通過對每層權重的二次誤差做近似逆向求解適合離線批量量化精度控制相對均衡。AWQ的思路是找出對輸出影響顯著的重要權重通道通過縮放因子保護它們不需要反向傳播速度更快而且在小模型上的平均質量表現(xiàn)普遍更好。我從多個開源模型上的實測結論是7B及以下量級AWQ明顯更穩(wěn)13B以上兩者差距縮小但AWQ的顯存開銷和量化耗時仍然更低。實際操作中我基本都走AWQ然后對量化后的模型跑一遍校準集上的困惑度perplexity和幾個核心業(yè)務prompt的對比測試確認退化在可接受范圍內再上線。2.3 KV Cache量化最容易忽略的坑這里重點提醒一個很多人踩過的坑KV Cache INT8量化不是改了配置就萬事大吉要關注注意力分數(shù)可能出現(xiàn)的異常放大。KV Cache是自回歸解碼中緩存的歷史token的Key和Value本身是激活值沒有weights的量化保護。如果某個token的值恰好落在量化區(qū)間的邊緣反量化誤差會被注意力權重放大導致生成質量劣化。實測中最典型的表現(xiàn)是長上下文場景下模型突然出現(xiàn)忘事和重復生成的情況排查半天發(fā)現(xiàn)是KV Cache量化在超過一定長度后開始打折扣。我的經(jīng)驗做法是中小模型7B-13B默認開啟KV Cache INT8收益大于風險對質量要求極高的場景如代碼生成、金融報告生成先做5000 token以上長度的對比測試如果出現(xiàn)長上下文質量劣化把KV Cache切回FP16只保留weight INT4損失一點顯存換質量穩(wěn)定注意量化方案本身沒有絕對的好壞選型的標準永遠是你的業(yè)務場景最不能接受哪一類損失。省顯存、保質量、降時延這三者需要按業(yè)務屬性排優(yōu)先級。這個階段的成果是實打實的我跑過一個13B模型的服務量化前P99生成長度為512 token的回復約9.8秒量化后降到約6.2秒同時單卡并發(fā)容量從8路提升到16路。后面所有更復雜的優(yōu)化都是在量化這個地基上疊加的。3. 投機解碼與前綴緩存用預判和記憶換推理速度的兩條隱蔽路徑量化解決的是每次翻字典的代價而投機解碼Speculative Decoding和前綴緩存Prefix Caching解決的是能不能少翻幾次字典——前者用更小的模型預判大模型的輸出后者讓重復計算的上下文直接復用結果。3.1 投機解碼的核心邏輯與實測收益投機解碼的思路很有意思自回歸解碼是一個token一個token地生成每一步都要等大模型跑一遍。但如果你用一個很小、很便宜的草稿模型draft model先去猜接下來五六個token會是什么然后把這幾個token一次性喂給大模型驗證——大模型一次前向計算就能給出這幾個token是否被接受的確認。猜對了幾個就等于只花一次大模型推理成本就生成了幾個token速度自然上去了。這里有一個關鍵前提草稿模型必須和大模型共享tokenizer和詞表否則draft token和target token的映射對不上整條鏈路直接廢掉。這也是為什么業(yè)界的草稿模型基本都是同系列小規(guī)模版本比如7B/13B的蒸餾小模型或同詞表的1B左右模型而不是隨便拿一個別的模型來湊。我實測的收益分兩種情況批處理規(guī)模小單batch或并發(fā)低時投機解碼收益非常明顯一個8B主模型配一個1B草稿模型單線延遲能降40%到50%。批處理規(guī)模大并發(fā)高、batch size大時收益反而變小。因為大模型本來就在高并發(fā)下接近滿負載運轉草稿模型預判的token命中率跟不上大batch的吞吐節(jié)奏還會額外占用顯卡算力。所以我的建議是如果你的業(yè)務是低并發(fā)的實時交互比如Agent單輪調用、IDE代碼補全投機解碼非常值得上如果是高并發(fā)純吞吐型業(yè)務比如批量摘要生成把算力留給主模型更劃算。3.2 前綴緩存讓重復的Prompt不再重復計算前綴緩存解決的問題更樸素也更常見同一套系統(tǒng)提示詞system prompt、同樣的多輪對話歷史、同一批few-shot示例在每次請求中都要被從頭到尾做一次prefill計算——這些計算其實是重復的完全沒必要。vLLM中RadixAttention的實現(xiàn)思路是把請求的Prompt前綴做樹狀緩存后續(xù)請求如果命中了相同前綴就直接復用已緩存的KV狀態(tài)跳過一次前向計算。命中率越高吞吐提升越明顯。我實際觀察到的效果在某些Agent場景系統(tǒng)提示詞加上歷史對話模板占了請求輸入的大頭前綴緩存命中后prefill耗時能下降70%以上。一個17B模型原本平均每請求要處理3000 token的重復上下文緩存命中后只剩新增的幾百token需要計算整體時延下降大約30%。但前綴緩存有個隱性成本需要留意——緩存會占顯存。如果并發(fā)請求不同前綴太多緩存命中率低KV Cache緩存反而擠占了正常推理的空間。所以一般要給緩存區(qū)域設一個上限超過閾值就把最老的緩存逐出保證推理本身的顯存優(yōu)先級。我個人的經(jīng)驗值緩存區(qū)域顯存占總顯存的10%到20%之間比較健康。命中率低于50%的業(yè)務場景建議直接把緩存調小把顯存還給并發(fā)推理。4. 服務框架選型vLLM、TensorRT-LLM和SGLang真實差距在哪優(yōu)化做到這一步你的模型和推理內核已經(jīng)具備不錯的性能基座但真正決定線上表現(xiàn)的是服務化調度框架?，F(xiàn)在開源主流基本是vLLM、TensorRT-LLM簡稱TRT-LLM和SGLang三分天下。我三個都用過也做過全流程的橫向對比說點不是文檔里能直接看出來的東西。4.1 三家框架的核心差異對比維度做法引入效果生效方式加載權重時近似計算向量化對比速度極快毫秒級完成對比維度vLLMTensorRT-LLMSGLang調度機制PagedAttention動態(tài)batch靈活靜態(tài)batch圖優(yōu)化需顯存預分配RadixAttention前綴緩存核心連續(xù)batch內核優(yōu)化豐富但深度一般對特定GPU深度優(yōu)化延遲最低前綴樹緩存機制最強Agent場景適配好部署難度極低vLLM直接跑較高需要模型轉換和build engine中低API風格簡潔高并發(fā)吞吐優(yōu)秀優(yōu)秀但調優(yōu)門檻高優(yōu)秀尤其長上下文場景生態(tài)兼容性最好HuggingFace模型即插即用一般需要格式轉換較好原生支持多種模型適合場景快速上線、多模型靈活切換極致性能、固定模型長期壓榨Agent、長上下文、高前綴復用從實測的角度補充幾個數(shù)字。我在A100 80GB上做過一組并發(fā)布比較vLLM在并發(fā)128路的場景下單卡吞吐約3800 token/s7B模型P99時延約2.4秒TRT-LLM在同樣條件下吞吐約4200 token/sP99時延約2.1秒但整個engine構建和調優(yōu)花了我兩天時間SGLang在同樣的模型和并發(fā)下吞吐約4000 token/s但P50時延明顯低尤其多輪對話場景中因為前綴緩存命中率高。4.2 選型建議別只看榜單上的吞吐數(shù)字很多團隊選框架只看峰值吞吐數(shù)字這其實是個誤導。部署框架的選型維度需要考慮一是你的流量特征。高并發(fā)純粹填吞吐TRT-LLM肯定香但如果你的請求是Agent式的多輪交互每次請求都帶著很長且重復的系統(tǒng)提示詞和歷史上下文SGLang的前綴緩存會帶來跨請求的收益這是單純吞吐榜上根本看不出來的。二是工程維護成本。我用TRT-LLM踩過最大的坑是模型每次改動都要重新構建engine整個流程在CI/CD里很重vLLM則基本可以做到模型文件丟進去就能部署迭代速度完全不同。三是團隊的技術底盤。如果你的團隊是偏業(yè)務應用、不太愿意在內核層面折騰vLLM是穩(wěn)妥起點如果有專職推理優(yōu)化工程師TRT-LLM值得花時間。我的做法是線上核心服務先用vLLM穩(wěn)定跑起同時用SGLang做競品驗證如果某個模型在vLLM上前綴緩存收益不明顯再考慮切換?？蚣芮袚Q是最后一步不是第一步。5. 服務參數(shù)調優(yōu)從能跑到跑滿四個關鍵旋鈕逐個擰框架選好了模型也量化好了但這只代表服務能跑。很多團隊卡在這一步——明明模型沒毛病、顯卡也不算差吞吐就是上不去時延就是壓不下來。這一節(jié)說四個最關鍵的旋鈕全部來自我踩過的坑和調過的參數(shù)。5.1 max_num_seqs并發(fā)數(shù)與顯存使用的平衡桿大多數(shù)框架默認的max_num_seqs都很保守比如vLLM默認值通常只有幾十甚至更低。這個參數(shù)控制了框架最多同時處理多少條序列直接決定了并發(fā)上限。我實測7B模型AWQ量化后把max_num_seqs從默認值拉到128單卡吞吐量提升了接近一倍代價是每請求的平均時延略有上升。原因很簡單序列數(shù)越多同一批次內被一起調度的token越多GPU的利用率越飽和整體吞吐自然也更高。但單獨請求的時延會被batch中的其他請求拖慢。5.2 max_num_batched_tokens連續(xù)批處理的粒度控制這個參數(shù)規(guī)劃了每次批處理時最大能夠批處理多少token。如果設置得太大調度器可能長時間hold住一批token等待填滿導致請求被卡在隊列里如果太小批處理的規(guī)模又不夠GPU計算空檔會增多token生成吞吐上不去。我在不同模型上總結的經(jīng)驗值7B模型max_num_batched_tokens建議設在2048到4096之間13B模型設為1024到2048更穩(wěn)需要配合觀測GPU利用率動態(tài)調整不能一次到位就不管了5.3 gpu_memory_utilization顯存預留的邊界直覺這個參數(shù)控制框架最多占用GPU顯存的百分比。很多人直接填0.9然后上線就OOM原因是KV Cache和激活值在運行時的實際增長被低估了。我的建議是首次部署先用官方默認值一般是0.9跑到真實負載下觀察有無OOM然后逐步下調。穩(wěn)妥的做法是先設定到0.85后續(xù)觀察內存分配曲線再決定是否上調。這里的關鍵是記住顯存預留不當會有連鎖效應——不只影響當前服務還會影響同卡上其他進程尤其當你想在同一塊GPU上跑多個模型實例時。5.4 長上下文場景的chunked prefill開關如果服務要處理很長的輸入比如法律文書摘要、代碼倉庫問答建議打開chunked prefill。它的本質是把一次大的prefill切成多個小塊與decode階段交錯執(zhí)行避免一個大輸入的prefill霸占整卡、阻塞其他請求的解碼。我在一個要處理平均8000 token輸入的RAG服務上做了A/B對比關閉chunked prefill時P99時延高達14秒開啟后P99降到約5.5秒。代價是單請求的prefill耗時略微變長但對整體吞吐和穩(wěn)定性來說收益遠大于損失。這樣一個旋鈕一個旋鈕地調下來一組可以復用的實測數(shù)據(jù)大致是7B AWQ模型、A100 80GB單卡、max_num_seqs96、batched_tokens3072、gpu_memory_utilization0.9開啟chunked prefill后穩(wěn)定跑出了約2600 token/s的吞吐和約3.8秒的P99時延序列長度約1024 token輸出。這些參數(shù)不可能一次調對我的建議是每調一個參數(shù)變更就做一輪壓測記錄吞吐、P50、P99、GPU利用率四個指標形成一條回歸曲線再綜合權衡。寧可用數(shù)據(jù)說話也不要拍腦袋。6. 上線后躲不過去的三個坑顯存碎片、長尾時延與擴容策略前幾節(jié)都在說怎么把性能調上去但真正上線運維后你會發(fā)現(xiàn)工程化的問題和推理性能同樣致命。我復盤過幾次實際生產(chǎn)環(huán)境里的問題把其中最典型、最容易復發(fā)的三個坑記錄下來。6.1 顯存碎片化導致的虛假OOM線上服務跑了一段時間后突然莫名其妙地OOM。查了顯存總占用明明還剩下20多GB為什么分配不出來原因是vLLM的PagedAttention雖然通過分頁大幅緩解了KV Cache碎片問題但模型權重、激活值和工作區(qū)之間依然會產(chǎn)生細碎的不可復用顯存空洞。尤其是高并發(fā)下不同長度序列的內存分配和釋放不斷交錯碎片會逐漸累積。排查方法在監(jiān)控面板上同時看顯存總占用和模型及KV Cache占用的合計值如果兩者差距隨時間越拉越大基本就是碎片問題。解決辦法有兩種定期在低峰期重啟服務釋放顯存或者給每個請求的max_model_len做上限控制避免極端長度的序列撐開內存空洞。我后來在生產(chǎn)上選擇了后者把max_model_len設為每個業(yè)務場景的實際上限約20%余量碎片化速度大幅度下降OOM基本消失了。6.2 長尾時延的元兇長輸入prefill阻塞高并發(fā)場景下P99時延一直在漲但P50很平穩(wěn)關掉一些并發(fā)后P99立刻回落。這類問題的本質通常是長輸入的prefill阻塞了解碼。舉個例子100路并發(fā)里混進來一個輸入長度為5000 token的請求在chunked prefill未開啟時這個請求的prefill會長時間占用計算資源導致同批次的短請求全部排隊等待。表現(xiàn)就是大部分請求絲滑但偶爾幾個請求被拖到七八秒甚至更久。處理方案分三層調度層開啟chunked prefill讓prefill和decode交錯執(zhí)行架構層把超長輸入拆成多個切片配合檢索只對相關片段做全局attention應用層對輸入長度分級超長請求走獨立的低優(yōu)先級通道處理不擠占交互通道。6.3 擴容不是簡單加卡成本和收益需要同步評估很多團隊優(yōu)化一輪后遇到底層瓶頸的第一反應是再加兩張卡。但推理服務擴容不是簡單的乘法因為顯存帶寬是多卡共享的多卡并行遇到短請求時通信開銷甚至可能超過計算收益。我的某次實測一個13B模型4卡A100的吞吐是單卡的3.1倍P99時延降到單卡的約55%但當并發(fā)請求的序列都很短128 token以內時4卡只比單卡快約1.4倍——大量時間花在卡間通信上了。所以擴容之前先做兩件事一是看你的請求是長序列密集型還是短序列密集型前者值得擴卡二是把單卡調參做實常常還有一倍以上的優(yōu)化空間沒榨出來這時候擴卡反而是最偷懶也最浪費錢的選擇。另外推薦一個邊上線邊監(jiān)控的方法論把吞吐、時延、顯存三個維度的指標全部落到業(yè)務維度上去看——按token換算單位成本。比如跑一個批處理任務500萬token用了多少錢、多少時間、多少GPU這個數(shù)字才是你和業(yè)務方溝通優(yōu)化效果的通用貨幣。7. 階段性沉淀我們最終拿到的一組可參考數(shù)據(jù)把上述所有優(yōu)化疊加后以一個典型的7B AWQ模型、A100 80GB單卡為例我沉淀出一組具備可參考性的生產(chǎn)環(huán)境數(shù)據(jù)供大家對照自己的環(huán)境評估權重精度INT4AWQKV Cache為INT8框架vLLM開啟chunked prefillmax_num_seqs96max_num_batched_tokens3072吞吐約2600 token/sP50時延約1.1秒輸出256 tokenP99時延約3.8秒輸出256 token單卡并發(fā)容量約60路同時在線交互不跌入重度排隊相比未優(yōu)化狀態(tài)FP16、默認參數(shù)吞吐約提升3倍P99時延約下降70%換到更大的模型或更長的上下文時數(shù)據(jù)會有所變化但優(yōu)化的路徑和每個動作的收益邏輯基本一致。你可以把上面的參數(shù)當成起點通過壓測找到自己業(yè)務場景下的最優(yōu)值。推理優(yōu)化與部署是一個沒有終點的系統(tǒng)工程投入產(chǎn)出比最高的順序永遠是先量化再調度再換框架最后才是加硬件。每一步都需要用線上數(shù)據(jù)來驗證而不是用直覺做決策。根據(jù)我個人的實踐經(jīng)驗絕大多數(shù)團隊的推理成本至少能通過這條鏈路壓縮50%以上。