8G 顯存跑 llama.cpp 怎麼調：32K 更穩，64K 要開 KV Cache 量化

Thu, 23 Apr 2026 12:13:04 +0800

8G 顯存到底還能不能把本地大模型跑順，尤其是在長上下文場景下還能不能保住速度，這是很多人在折騰 llama.cpp 時都會遇到的問題。

核心結論可以先記住三條：

對 8G 顯存來說，32K 上下文通常是更穩的平衡點
如果一定要跑 64K，KV Cache 量化基本是必選項
在全顯卡運行場景裡，盲目拉高 CPU 執行緒數，反而可能讓速度明顯下降

一、先解釋清楚：32K、64K 和 KV Cache 是什麼

很多人第一次看這類調優文章，最容易卡住的就是這三個詞。

32K 和 64K 說的是上下文長度，也就是模型一次最多能處理多少 token。這裡的 K 就是千，32K 大約是 32000 token，64K 大約是 64000 token。上下文越長，模型一次能看到的歷史內容越多，適合長文件問答、長對話和多輪分析。

KV Cache 則是模型為了加速連續生成而保留的一份中間結果快取。你可以把它理解成：模型已經讀過、算過的一部分內容，不會每次都從頭重算，而是把關鍵結果先存起來，後面繼續接著用。這裡的 K 和 V，來自 Transformer 裡的 Key 和 Value。

為什麼這三個詞總是一起出現？因為：

32K、64K 決定你想讓模型一次記住多長內容
KV Cache 決定為了維持這段記憶，要額外占多少顯存
上下文越長，KV Cache 通常越大，顯存壓力也越高

所以很多長上下文變慢的問題，本質上並不是模型「不會算」，而是快取太大，把顯存擠到了臨界點。

二、為什麼 32K 和 64K 的速度會差這麼多

這裡用《三體》大約 3 萬字的文本做壓力測試，對比 32K 和 64K 兩種上下文設定。結果很誇張：在文件長度接近的情況下，64K 模式的速度顯著下降，總耗時也明顯拉長。

問題不在模型突然變笨，而在顯存邊界被撞到了。

當 32K 模式下，模型權重加快取還能基本塞進 8G 顯存裡，資料大多走顯卡顯存帶寬，速度還能維持在比較可用的區間。但一旦切到 64K，快取體積繼續上漲，總占用逼近甚至超過顯存上限，系統就會把部分資料擠到記憶體裡。

這時候真正掉下去的，不是算力，而是帶寬。

也就是說，很多人看到的是「上下文翻倍後速度暴跌」，本質上其實是資料路徑從顯存掉到了共享記憶體或系統記憶體，推理鏈路不再跑在高速通道上。

三、64K 還能不能跑，關鍵在 KV Cache 量化

第二個很關鍵的結論，是 KV Cache 量化對 8G 顯存使用者特別重要。

如果不改變模型本身，只針對快取做量化，長上下文下最直接的收益就是把快取占用壓縮下來，讓原本已經溢出的那部分重新回到顯存裡。這樣一來，64K 模式雖然依然比 32K 更吃資源，但至少不會直接跌進最慢的區間。

換句話說：

32K 更像是 8G 顯存的預設推薦區間
64K 不是完全不能跑
但如果不上快取量化，效能很容易從「能用」直接掉到「很難用」

如果你的目標是盡量穩定地跑長上下文，那優先順序通常應該是：

先確認顯存是否已經逼近上限
再決定是否開啟 KV Cache 量化
最後才去繼續嘗試更激進的吞吐量參數

四、GPU 占用不高，不代表顯卡沒幹活

這是一個很容易打破直覺的點。

很多人看到工作管理員裡 GPU 使用率只有二三十，就會懷疑：

是不是參數沒設對
是不是模型沒真正跑到顯卡上
是不是顯卡根本沒吃滿

但這組測試給出的判斷是，llama.cpp 這類推理很多時候首先卡的不是核心算力，而是顯存讀寫速度。

也就是說，顯卡核心可能很快就把一批計算做完了，但後面還得等下一批權重和快取資料搬過來。於是你看到的現象就會變成：

核心占用不算高
但整體速度還是上不去

這不是顯卡在偷懶，而是資料通路太窄。

所以看本地大模型速度時，不能只盯著 GPU Usage。顯存容量、顯存帶寬、快取是否溢出，往往更影響最終體驗。

五、調大吞吐量參數，確實可能再快一截

這裡還做了一個思路很清晰的測試：既然顯卡核心並沒有完全忙滿，那能不能透過調大吞吐量相關參數，讓顯卡一次處理更多資料，把並行能力進一步壓出來。

測試結果表明，這種做法確實有機會把速度再往上拉一段。

但這裡也有一個前提：顯存還得扛得住。

因為吞吐量相關參數調大之後，往往會帶來額外顯存占用。如果你本來就在 64K、高快取、顯存見底的狀態下繼續往上推，就很容易出現兩種情況：

直接崩潰
沒崩，但被迫進入更慢的共享記憶體模式

所以更穩妥的順序通常不是「先把參數拉滿」，而是：

先守住顯存邊界
再考慮吞吐量優化
每調一步都重新看速度和穩定性

六、CPU 執行緒不是越多越好

這也是整篇內容裡最值得記住的坑點之一。

很多人做本地推理調優時，容易下意識覺得執行緒越多越快，既然機器有那麼多執行緒，不用滿就像浪費。但實測給出的結果恰恰相反：在模型已經主要跑在顯卡上的情況下，強行把 CPU 執行緒拉高，效能反而會明顯變差。

原因不複雜。

在全顯卡運行時，CPU 更像是調度者和預處理協作者，而不是主力計算單元。這時候如果開太多執行緒，CPU 端的執行緒競爭、調度切換和上下文切換開銷都會變重，最終把本來應該更流暢的資料流打亂。

結果就是：

CPU 更忙了
但整體速度變慢了

所以在這種場景下，預設設定或者較低執行緒數，往往比一味拉滿更靠譜。

七、對 8G 顯存使用者更實用的一套思路

如果把上面的結論壓成一套更容易執行的思路，大概可以整理成這樣：

1. 先把 32K 當成預設目標

如果你用的是 8G 顯存顯卡，先別急著追 64K。32K 往往是速度、穩定性和顯存占用之間更現實的平衡點。

2. 想上 64K，先處理快取問題

不要先想「還能不能再榨一點速度」，而是先確認 KV Cache 有沒有量化、顯存是不是已經壓線。

3. 不要用 GPU 占用率判斷一切

低占用不一定代表設定錯了，也可能只是顯存帶寬在拖後腿。

4. 吞吐量優化可以做，但別越過顯存邊界

這類參數確實能帶來收益，但前提是顯存還有餘量。

5. CPU 執行緒先保守，再逐步測試

如果模型已經基本跑在顯卡上，CPU 執行緒並不是越高越好。先用預設值或低執行緒值測試，再看是否值得繼續調整。

結語

這組內容最有價值的地方，不只是給出幾個測試數字，而是把一個經常被忽略的事實講清楚了：

本地大模型調優，很多時候拼的不是「有沒有把所有參數開到最大」，而是你有沒有搞清楚瓶頸到底在算力、顯存容量、顯存帶寬，還是在 CPU 調度。

對 8G 顯存使用者來說，真正更穩的思路通常不是硬衝最長上下文，而是先守住顯存邊界，再決定要不要繼續往上加。

如果只記一句話，那就是：

32K 往往是 8G 顯存更穩的工作區間；64K 不是不能跑，但前提是你已經把 KV Cache 和顯存占用管住了。

KV Cache on KnightLi的博客