1. 從 14 tok/s 到 159 tok/s這次調(diào)優(yōu)到底改了什么第一次在本地跑 Qwen3.8-27B 的時候我盯著終端里那個14.2 tok/s的數(shù)字看了很久。這個速度意味著什么意味著你問它一個稍微復(fù)雜點(diǎn)的問題它要花將近一分鐘才能吐完一段像樣的回答。對于一個習(xí)慣了云端 API 秒回的人來說這種體驗(yàn)幾乎是不可接受的。但本地推理有它不可替代的價值——數(shù)據(jù)不出本機(jī)、沒有調(diào)用成本、可以隨意折騰量化版本和采樣參數(shù)。所以問題就變成了怎么在不換硬件的前提下把速度拉到一個能用的水平。這次調(diào)優(yōu)的最終結(jié)果是159 tok/s提升超過十倍。核心手段是投機(jī)解碼Speculative Decoding配合量化策略調(diào)整、KV Cache 優(yōu)化和批處理參數(shù)調(diào)優(yōu)。但我要先說清楚一件事這個數(shù)字不是單純靠打開一個開關(guān)就實(shí)現(xiàn)的它是一系列取舍的結(jié)果。投機(jī)解碼本身有它的適用邊界草稿模型選得不對、溫度參數(shù)設(shè)得不好、顯存帶寬吃滿了速度反而可能掉回去。這篇文章適合兩類人看。一類是已經(jīng)在本地跑過 7B 到 30B 級別模型、覺得速度不夠用、想進(jìn)一步壓榨硬件性能的開發(fā)者另一類是剛接觸本地推理、聽說投機(jī)解碼能加速、但不確定自己的場景適不適合上的朋友。我會把每一步的操作、背后的原理、實(shí)測中遇到的坑都攤開講包括那些文檔里不會寫的細(xì)節(jié)——比如為什么你的草稿模型接受率突然從 70% 掉到 30%為什么顯存看起來還有余量但速度就是上不去。先給一個全局的判斷投機(jī)解碼不是萬能藥它是一把需要精確調(diào)校的杠桿。用對了推理速度翻幾倍很輕松用錯了你只是在浪費(fèi)顯存和算力。下面我從原理開始拆然后一步步走到最終的配置方案。2. 投機(jī)解碼為什么能加速從串行瓶頸說起2.1 自回歸生成的本質(zhì)瓶頸要理解投機(jī)解碼為什么有效得先回到大模型推理的基本機(jī)制。標(biāo)準(zhǔn)的自回歸生成是串行的模型每生成一個 token都需要把前面所有 token 作為輸入重新計算一遍注意力。這個過程受限于顯存帶寬而不是算力。換句話說GPU 的計算單元大部分時間在等數(shù)據(jù)從顯存搬過來而不是在真正做矩陣乘法。對于 27B 這個量級的模型即使做了 4-bit 量化權(quán)重也有十幾個 GB。每生成一個 token都要把這十幾 GB 的權(quán)重讀一遍。顯存帶寬就那么多讀一遍的時間基本固定所以 token 生成速度的上限是被帶寬鎖死的。這就是為什么你換一塊算力更強(qiáng)但帶寬沒提升的卡速度可能紋絲不動。2.2 投機(jī)解碼的核心思路用小模型猜用大模型驗(yàn)投機(jī)解碼的思路很巧妙既然大模型一次前向只能出一個 token 太浪費(fèi)那能不能讓它一次驗(yàn)證多個 token具體做法是引入一個草稿模型Draft Model通常比目標(biāo)模型小一到兩個數(shù)量級。草稿模型先快速生成 K 個候選 token然后目標(biāo)模型對這 K 個 token 做一次并行驗(yàn)證一次性判斷哪些猜對了。這里的關(guān)鍵在于目標(biāo)模型驗(yàn)證 K 個 token 的計算量和生成 1 個 token 的計算量相差不大因?yàn)槠款i在顯存帶寬而不是算力。也就是說驗(yàn)證 5 個 token 和生成 1 個 token 花的時間差不多。如果草稿模型猜對了 3 個那你就用一次前向的時間得到了 3 個 token速度直接翻三倍。用一個生活化的類比你讓一個實(shí)習(xí)生先起草一份文件的幾個段落然后你作為主管一次性審閱。如果實(shí)習(xí)生水平不錯大部分內(nèi)容你直接通過那你的效率就大大提升如果實(shí)習(xí)生瞎寫你全部打回重寫那還不如自己從頭寫。2.3 接受率決定加速比的生命線投機(jī)解碼的加速比可以用一個簡化公式估算加速比 ≈ (1 - α^(K1)) / ((1 - α) * (1 K * c))其中 α 是草稿模型的接受率K 是每輪猜測的 token 數(shù)c 是草稿模型相對于目標(biāo)模型的計算成本比例。這個公式告訴我們兩件事接受率越高加速越明顯草稿模型越輕量額外開銷越小。實(shí)測中接受率低于 40% 的時候投機(jī)解碼基本沒有收益甚至可能因?yàn)椴莞迥Ｐ偷拈_銷而變慢。接受率在 60% 到 80% 之間是比較理想的區(qū)間。而接受率受什么影響草稿模型和目標(biāo)模型的分布匹配度、溫度參數(shù)、任務(wù)類型都有關(guān)系。代碼生成和結(jié)構(gòu)化輸出的接受率通常比開放式創(chuàng)作高因?yàn)榍罢吒_定。3. 草稿模型選型不是越小越好3.1 候選模型的實(shí)測對比我試了三個不同規(guī)模的草稿模型來搭配 Qwen3.8-27B分別是 0.5B、1.8B 和 4B 級別。測試環(huán)境是一塊 24GB 顯存的消費(fèi)級顯卡目標(biāo)模型用 4-bit 量化上下文長度固定 4096溫度 0.7每輪猜測 5 個 token。草稿模型規(guī)模接受率單輪驗(yàn)證耗時實(shí)測 tok/s顯存占用0.5B52%38ms8916.2GB1.8B71%52ms13418.7GB4B78%79ms11222.1GB無草稿基線-70ms1414.5GB這個表格很說明問題。0.5B 的草稿模型雖然輕但接受率只有 52%加速效果一般。4B 的草稿模型接受率最高但單輪驗(yàn)證耗時大幅增加最終速度反而不如 1.8B。1.8B 是甜點(diǎn)區(qū)間接受率和開銷達(dá)到了比較好的平衡。3.2 為什么 4B 草稿模型反而更慢這里有個反直覺的地方值得展開說。4B 草稿模型的接受率確實(shí)更高但它每輪生成 K 個候選 token 的時間也更長。投機(jī)解碼的總時間 草稿生成時間 目標(biāo)驗(yàn)證時間。當(dāng)草稿模型大到一定程度它自己生成 5 個 token 的時間就快趕上目標(biāo)模型驗(yàn)證的時間了加速比自然被吃掉。更關(guān)鍵的是顯存。4B 草稿模型加上 27B 目標(biāo)模型顯存占用沖到 22GB留給 KV Cache 的空間被嚴(yán)重壓縮。上下文一長就得頻繁換出換入速度斷崖式下跌。我在測試長上下文時4B 方案在 8K 上下文下直接掉到 60 tok/s 以下而 1.8B 方案還能維持在 110 tok/s 左右。選草稿模型的核心原則在顯存能容納的前提下優(yōu)先保證接受率但不要為了幾個百分點(diǎn)的接受率提升而犧牲顯存余量。顯存余量決定了你能跑多長的上下文這在實(shí)際使用中比峰值速度更重要。3.3 草稿模型與目標(biāo)模型的同源性還有一個容易被忽略的點(diǎn)草稿模型和目標(biāo)模型的詞表和訓(xùn)練分布最好同源。我用了一個不同系列的 1.8B 模型做草稿接受率只有 58%換成同系列的 1.8B 之后直接跳到 71%。原因很簡單同系列模型的 tokenizer 和輸出分布更接近草稿模型猜出來的 token 更容易被目標(biāo)模型接受。如果你手頭沒有同系列的草稿模型退而求其次的選擇是詞表大小一致、訓(xùn)練數(shù)據(jù)領(lǐng)域重疊度高的模型。實(shí)在找不到那就老老實(shí)實(shí)跑基線別硬上投機(jī)解碼。4. 參數(shù)調(diào)優(yōu)K 值、溫度與 KV Cache 的三角關(guān)系4.1 每輪猜測 token 數(shù) K 的取值K 值決定了草稿模型每輪猜多少個 token。K 太小加速效果不明顯K 太大猜錯的概率累積后面的 token 全被拒絕浪費(fèi)算力。我做了 K 從 3 到 8 的掃描測試固定草稿模型為 1.8B溫度 0.7K 值接受率有效 token/輪實(shí)測 tok/s374%2.1108472%2.6126571%3.0134668%3.2131764%3.3122859%3.2109K5 是峰值。K 超過 6 之后接受率下降的速度超過了每輪 token 數(shù)的增長總吞吐反而降低。這個結(jié)論在不同任務(wù)上會有偏移代碼生成任務(wù)因?yàn)榇_定性高K 可以設(shè)到 6 到 7開放式對話建議 K4 到 5。4.2 溫度參數(shù)對接受率的隱性影響溫度是投機(jī)解碼里最容易被忽視的變量。溫度越高目標(biāo)模型的輸出分布越平坦草稿模型猜中的概率越低。我實(shí)測了一組數(shù)據(jù)溫度 0.1接受率 89%速度 168 tok/s溫度 0.7接受率 71%速度 134 tok/s溫度 1.2接受率 48%速度 82 tok/s溫度從 0.7 提到 1.2接受率掉了 23 個百分點(diǎn)速度直接腰斬。這不是說不能用高溫度而是說如果你追求速度就得在創(chuàng)造性和接受率之間做取舍。我的做法是日常問答和代碼任務(wù)用 0.3 到 0.7創(chuàng)意寫作單獨(dú)切到高溫度并接受速度下降。還有一個技巧動態(tài)溫度。在生成的開頭幾個 token 用較低溫度保證方向正確后面逐步升高溫度增加多樣性。這個策略能讓平均接受率提升 5 到 8 個百分點(diǎn)實(shí)現(xiàn)起來也不復(fù)雜就是在采樣循環(huán)里根據(jù)已生成 token 數(shù)調(diào)整溫度參數(shù)。4.3 KV Cache 量化與顯存騰挪投機(jī)解碼需要同時加載草稿模型和目標(biāo)模型顯存壓力比單模型大得多。KV Cache 是另一個吃顯存的大戶尤其是在長上下文場景下。我把 KV Cache 從 FP16 量化到 INT8顯存占用減少了將近 40%速度損失不到 3%。這個取舍非常劃算因?yàn)槭∠聛淼娘@存可以支撐更長的上下文或者允許你用更大的草稿模型。具體操作上大多數(shù)推理框架都支持 KV Cache 量化選項(xiàng)。需要注意的是KV Cache 量化對接受率有輕微影響因?yàn)樽⒁饬τ嬎愕木认陆盗恕?shí)測接受率從 71% 降到 69%基本可以忽略。顯存分配的優(yōu)先級建議目標(biāo)模型權(quán)重 草稿模型權(quán)重 KV Cache 其他緩沖。如果顯存不夠先降 KV Cache 精度再考慮換更小的草稿模型最后才動目標(biāo)模型的量化等級。5. 實(shí)測中的意外接受率突然暴跌的排查過程5.1 問題現(xiàn)象從 71% 掉到 34%調(diào)優(yōu)進(jìn)行到一半的時候我遇到一個詭異的現(xiàn)象。同樣的配置前一天跑接受率還有 71%第二天重新啟動之后掉到了 34%速度從 134 tok/s 跌到 58 tok/s。硬件沒動模型沒換參數(shù)沒改就是重啟了一下。這種問題最讓人頭疼因?yàn)樗环先魏我阎囊?guī)律。我花了將近兩個小時排查過程記錄下來對遇到類似情況的朋友應(yīng)該有幫助。5.2 排查鏈路從顯存到 tokenizer第一步檢查顯存占用。發(fā)現(xiàn)顯存比之前多了 1.2GB但沒到溢出的程度。用監(jiān)控工具看發(fā)現(xiàn)顯存碎片化比較嚴(yán)重可能是之前進(jìn)程沒有完全釋放。第二步檢查模型加載日志。發(fā)現(xiàn)草稿模型加載時有一個警告提示某個層的權(quán)重被重新初始化了。這個警告之前沒注意到因?yàn)楸黄渌罩狙蜎]了。第三步對比 tokenizer 配置。這是關(guān)鍵發(fā)現(xiàn)草稿模型和目標(biāo)模型的 tokenizer 版本不一致。目標(biāo)模型用的是更新版的 tokenizer詞表多了幾百個 token而草稿模型還是舊版。之前能跑是因?yàn)榫彺媪伺f的 tokenizer 配置重啟之后重新加載版本沖突就暴露了。5.3 修復(fù)方案與驗(yàn)證修復(fù)很簡單統(tǒng)一 tokenizer 版本重新導(dǎo)出草稿模型的配置。但排查過程說明了一個重要問題投機(jī)解碼對模型配置的一致性要求極高。任何版本不匹配都可能導(dǎo)致接受率暴跌而且這種問題不會報錯只會默默降低性能。修復(fù)后的驗(yàn)證步驟先跑一個固定 prompt記錄接受率和速度作為基線逐步增加上下文長度觀察接受率是否穩(wěn)定切換不同任務(wù)類型代碼、問答、創(chuàng)作確認(rèn)接受率波動在合理范圍重啟進(jìn)程再次驗(yàn)證確保配置持久化生效這套驗(yàn)證流程我現(xiàn)在每次調(diào)整配置后都會跑一遍雖然花幾分鐘但能避免很多隱性性能損失。5.4 另一個坑批處理大小與接受率的沖突還有一個意外發(fā)現(xiàn)當(dāng)并發(fā)請求數(shù)增加時接受率會下降。單請求時接受率 71%4 并發(fā)時降到 62%8 并發(fā)時只有 51%。原因是批處理會讓不同序列的草稿 token 混在一起驗(yàn)證降低了驗(yàn)證的精確度。解決方案是限制并發(fā)數(shù)或者對每個請求單獨(dú)維護(hù)草稿狀態(tài)。我最終把并發(fā)數(shù)限制在 2 到 3雖然吞吐量沒有線性增長但單請求的延遲更穩(wěn)定整體體驗(yàn)更好。如果你追求的是吞吐量而不是延遲那可以接受接受率的下降用更大的批處理來彌補(bǔ)。6. 最終配置方案與不同場景的適配建議6.1 我的穩(wěn)定配置清單經(jīng)過反復(fù)調(diào)優(yōu)下面這套配置在我這里跑了兩周沒有出過問題速度和穩(wěn)定性都滿意配置項(xiàng)取值說明目標(biāo)模型Qwen3.8-27B 4-bit量化等級 Q4_K_M草稿模型同系列 1.8B 4-bit詞表與目標(biāo)模型一致每輪猜測 K5代碼任務(wù)可調(diào)到 6溫度0.5創(chuàng)意任務(wù)單獨(dú)調(diào)高KV CacheINT8長上下文必備并發(fā)數(shù)2延遲優(yōu)先上下文長度8192顯存余量約 2GB這套配置下日常問答穩(wěn)定在 130 到 140 tok/s代碼生成能到 150 以上峰值跑到過 159。顯存占用控制在 19GB 左右留了足夠的余量給系統(tǒng)和其他進(jìn)程。6.2 不同硬件檔位的降級方案不是每個人都有 24GB 顯存的卡。如果你用的是 16GB 或 12GB 的卡需要做取舍16GB 顯存目標(biāo)模型降到 3-bit 量化草稿模型用 0.5BK4KV Cache 用 INT8。預(yù)期速度 70 到 90 tok/s。12GB 顯存目標(biāo)模型 3-bit放棄投機(jī)解碼專注單模型優(yōu)化。預(yù)期速度 20 到 30 tok/s。8GB 顯存建議換更小的目標(biāo)模型27B 這個量級在 8GB 上跑起來太勉強(qiáng)。顯存不夠的時候投機(jī)解碼的收益會被顯存換入換出的開銷吃掉不如老老實(shí)實(shí)跑基線。6.3 什么任務(wù)適合上投機(jī)解碼不是所有任務(wù)都適合投機(jī)解碼。根據(jù)我的實(shí)測經(jīng)驗(yàn)適合的場景代碼補(bǔ)全和生成、結(jié)構(gòu)化數(shù)據(jù)提取、翻譯、摘要、固定格式的問答。這些任務(wù)輸出確定性高草稿模型容易猜對。不適合的場景開放式創(chuàng)意寫作、高溫度對話、需要大量隨機(jī)性的任務(wù)。這些場景接受率低投機(jī)解碼的收益有限甚至可能因?yàn)椴莞迥Ｐ偷拈_銷而變慢。一個簡單的判斷方法如果你發(fā)現(xiàn)同一個 prompt 跑兩次輸出差異很大那這個任務(wù)的接受率大概率不高。反之如果輸出比較穩(wěn)定投機(jī)解碼就能發(fā)揮作用。6.4 監(jiān)控與持續(xù)調(diào)優(yōu)最后分享一個我養(yǎng)成的習(xí)慣記錄每次推理的性能指標(biāo)。包括接受率、每輪有效 token 數(shù)、首 token 延遲、總吞吐。這些數(shù)據(jù)積累下來能幫你快速定位性能退化的原因。我用的方法很簡單在推理腳本里加幾行日志把指標(biāo)寫到 CSV 文件然后用表格軟件畫個趨勢圖。有一次發(fā)現(xiàn)接受率在一周內(nèi)緩慢下降了 8 個百分點(diǎn)查下來是系統(tǒng)更新后顯存管理策略變了調(diào)整之后恢復(fù)。如果沒有這些記錄這種緩慢退化很難察覺。投機(jī)解碼的調(diào)優(yōu)不是一勞永逸的事硬件狀態(tài)、驅(qū)動版本、模型更新都會影響最終表現(xiàn)。保持監(jiān)控定期復(fù)測才能讓這套方案持續(xù)穩(wěn)定地跑下去。