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