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