3.5 t/s降到2.5 t/s，我花了3天驗證一個反直覺的結(jié)論——在8G顯存上，推測解碼（Speculative Decoding）不是加速器，是減速帶。

這個技術(shù)的賣點很誘人：用小模型起草token，大模型批量驗證，理論上能拿到大模型質(zhì)量+小模型速度。DeepMind 2022年論文發(fā)表后，llama.cpp一行-md參數(shù)就能開啟。我手頭的RTX 4060 Laptop 8G，跑27B模型 baseline 3.5 t/s，要是能逼近9B模型的33 t/s，哪怕打個對折都是血賺。

實測結(jié)果：0.8B、4B、9B三種草稿模型，全部比基線慢。

問題從顯存墻開始。27B+9B雙模型同時加載，Q4_K_M量化下需要約22.5G顯存——是8G顯存的3倍。單跑27B時，我最多只能塞24層到GPU（ngl=24），雙模型？第一反應是不可能。

llama.cpp給了條活路：-ngl和-ngld可以獨立設置，把8G顯存拆成"主模型部分層+草稿模型全層"。草稿越小，主模型能搶到的顯存越多：

? 0.8B草稿（0.6G）→ 27B分到7.4G → 20層上GPU
? 4B草稿（2.5G）→ 27B分到5.5G → 13層上GPU
? 9B草稿（5.5G）→ 27B分到2.5G → 0層，純CPU跑

這里有個 tradeoff：草稿越大，接受率越高，但主模型被擠到CPU；草稿越小，GPU層數(shù)越多，但起草質(zhì)量下降。我測了全部三種配置找甜點。

測試1：0.8B草稿，20層GPU

顯存占用約7.1G，生成速度3.1 t/s。比基線慢11%。

草稿模型太小，起草的token質(zhì)量差，大模型驗證時頻繁拒絕。雖然27B有20層在GPU，但驗證開銷抵消了草稿節(jié)省的時間。推測解碼的"批量驗證"優(yōu)勢，被低接受率吃掉了。

測試2：4B草稿，13層GPU

顯存占用約7.0G，生成速度2.8 t/s。比基線慢20%。

草稿質(zhì)量提升，但主模型只剩13層在GPU，CPU-GPU數(shù)據(jù)傳輸成為瓶頸。27B的35層在CPU上跑，每次驗證都要跨總線搬運數(shù)據(jù)。4B草稿起草快，但大模型驗證慢，整體反而更差。

測試3：9B草稿，純CPU跑主模型

顯存占用5.5G，生成速度2.5 t/s。比基線慢29%。

這是最極端的配置。9B草稿全在GPU上，起草速度飛快（參考：單跑9B能到33 t/s），但27B主模型完全在CPU上。驗證階段變成CPU單線程苦戰(zhàn)，草稿省下的時間被驗證拖垮。

三種配置全部陣亡，沒有一個接近理論上的2-3倍加速。8G顯存這個硬邊界，讓推測解碼的核心假設失效——它假設草稿模型和大模型能同時高效運行，但顯存不足時，你必須砍掉大模型的GPU層數(shù)。

我查了下社區(qū)反饋，這不是個例。llama.cpp的GitHub issue里，8G-12G顯存用戶的抱怨很集中：推測解碼在小顯存上"能用"但"不快"。有人用16G顯存測27B+7B組合，能拿到1.5-2倍加速；24G顯存才是這個技術(shù)的舒適區(qū)。

一個細節(jié)：我的測試固定了--draft-max 8（每次推測8個token），接受率數(shù)據(jù)沒單獨記錄。但從速度反推，0.8B草稿的接受率可能不到50%，4B和9B會高一些，但驗證開銷的增長更快。

另一個變量是量化方式。我用的是Q4_K_M，如果換Q5或Q6，顯存占用增加，GPU層數(shù)進一步減少，情況會更糟。反過來，Q3可能緩解，但質(zhì)量損失是另一筆賬。

這次測試的硬件環(huán)境：Ryzen 7 7845HS / 32G DDR5 / RTX 4060 Laptop 8G。桌面端8G卡（RTX 4060/3060）情況類似，筆記本顯存帶寬更低，可能更差。

結(jié)論很直白：8G顯存用戶，現(xiàn)階段別折騰推測解碼了。把ngl拉滿，單模型跑滿血，比花里胡哨的雙模型配置更實在。等技術(shù)優(yōu)化（比如更激進的層卸載策略，或者草稿模型的新架構(gòu)）再 revisit 不遲。

你手頭的卡是多少顯存？測過推測解碼嗎，結(jié)果如何？