V100 原始 GGUF vs 預打包權重快取
這篇比較 V100 上原始 GGUF Q4_K 佈局與預打包權重快取，幫你判斷該省顯存還是換取更快的解碼推論。
這篇比較 V100 上原始 GGUF 與預打包權重快取，幫你在顯存壓力和解碼速度之間做決定。
這篇是寫給正在調 V100 小批次解碼推論的人，重點是判斷 Q4_K 權重該保留原始 GGUF 佈局，還是多付一次預打包成本，換成更適合 GPU 的快取格式。
一張表看懂
訂閱 AI 趨勢週報
每週精選模型發布、工具應用與深度分析，直送信箱。不定期，不騷擾。
不會寄垃圾信，隨時可取消。
| 比較維度 | 原始 GGUF 佈局 | 預打包權重快取 |
|---|---|---|
| 初始化成本 | 不需額外 VRAM，載入時不必重排 | 需離線或啟動時預打包，常見多 1 到 2 倍載入時間 |
| 顯存佔用 | 最省，基本跟原始 GGUF 區塊一致 | 較高，實務上常多出 5% 到 20% 記憶體 |
| 核心效率 | 常受限於解包、位址運算與不規則讀取 | 可減少整數運算，讓 warp 讀取更連續 |
| 適合批次 | 在 M=1 到 4、顯存緊時仍可接受 | 解碼穩定、權重反覆重用時通常更有利 |
| V100 相容性 | 當 occupancy 與快取壓力已偏緊時較保守 | 若能用記憶體換指令數，通常更划算 |
| 常見結果 | 可當穩定基線，但 Q4 解包重的 GEMM 常留 10% 到 30% 空間 | 若核心是指令瓶頸，常比原始佈局更有效 |
原始 GGUF 佈局
原始 GGUF 是比較保守的選擇，因為它保留量化區塊的原樣，不會再吃一份額外顯存。對 V100-32GB 來說，這點很重要，因為你還得同時塞 KV cache、活躍張量和其他工作區；只要快取預算已經卡得很緊，原始佈局就會變成最安全的基線。
代價是，每個 token 的內迴圈都要做比較重的工作：解開 nibble、讀 scale 與 min、算位址、處理不規則存取。Volta 上這些成本常表現在 L1/TEX、LSU 和整數管線壓力，而不一定是 DRAM 吞吐先滿。若 Nsight 顯示你不是吃滿記憶體頻寬，原始佈局通常就是第一個該懷疑的地方，但要先看 register 數與 shared memory，因為它們也會把 occupancy 壓下來。
預打包權重快取
預打包快取最適合權重會在很多解碼步重複使用，而且批次很小、你希望每次 GEMM 都盡量簡單的情境。對 M=1 到 4 來說，這通常代表把資料重排成 warp 可以連續讀取的形式，讓 scales 和 mins 跟 nibble 串流分開，或在顯存允許時先展成 fp16 或 fp32。重點不是把模型變小，而是把內迴圈變得更少分支、更少指令。
在 V100 上，真正好的快取格式通常是配合 kernel tile 形狀，而不是只看儲存好不好看。若 kernel 以 warp 尺寸沿著輸入通道串流，K-major 分塊常比較有利；如果輸出欄位的分配方式讓 threads 能重用同一個解量化區塊，N-major 也可能更好。實務上，保留 quant block 的連續性、把 scales/mins 獨立存成緊湊 side array，並只預展開會被多次 MAC 重用的值，常常是最平衡的做法。
V100 上真正重要的是什麼
對 Volta 的 Q4 解碼核心來說，最大收益通常先來自減少指令數和修正存取模式，再來才是調 cache modifier。若你的 kernel 已經大約是每執行緒 48 個 register、每個 block 16 KB shared memory，那 occupancy 只是其中一部分；更關鍵的是解包與位址運算有沒有拉長關鍵路徑。這種情況下，少幾個整數運算常比微調 L1 政策更有感。
像 .cg 或 .ca 這類 cache load modifier 值得測，但通常不是我在 V100 上會先動的第一個槓桿。當同一份 metadata 會被鄰近 warps 重用時，它們可能有幫助；但如果你的存取模式不吻合，也可能造成 cache 汙染。比較好的做法，是先用 microbenchmark 分出瓶頸到底在 register、shared memory、整數解包，還是純粹的記憶體佈局。
LM head 與取樣
如果你已經把模型主體優化到一定程度，greedy decode 再把完整 vocab logits 傳回 CPU，通常就不是最好的端到端做法。假如 LM head 已經吃掉大約 8%，logits 取樣再吃 4%，那麼改成 GPU 端 argmax，只回傳 token ID，會是更乾淨的路徑。這樣可以少掉大量主機往返，也能把解碼迴圈留在裝置端，對 batch 只有 4、延遲比吞吐更重要的情境尤其有利。
如果你想要最小改動，可以先保留 cuBLAS 做 LM head，再另外加一個 GPU reduction kernel 來做 argmax 或 top-k。若你追求的是最低延遲，就把 LM head 和 reduction 融合，避免完整 logits tensor 真的落到 CPU 端。答案取決於你能承受多少工程風險，但對 V100 的正式解碼來說，主機複製通常是最不值得保留的那一段。
怎麼選
選原始 GGUF，如果你的顯存已經很吃緊、快取預算正在逼你做取捨，而且你想先保留最穩的路徑。當模型還要跟大型 KV cache 共存，或你還在釐清瓶頸到底是解包、occupancy，還是別的地方時，它會是比較安全的預設。
選預打包權重快取，如果同一批權重會在很多解碼步裡持續熱用，而且你有足夠顯存去容納更貼近 kernel 的資料排法。這比較適合願意用一些載入複雜度和顯存，換更簡單內迴圈的工程團隊，特別是 Nsight 已經指出瓶頸偏向指令數與位址壓力，而不是頻寬時。
選 GPU 端 argmax 與只回傳 token，如果你現在還在把完整 logits 傳回 CPU。這個改動通常比繼續調主機端 sampler 更值得，尤其是在小批次、正式推論、延遲敏感的流程裡。
在 V100 上，預設推薦是先用預打包快取處理最熱的 GEMM 路徑，但只要顯存壓力高到會擠掉更重要的權重或 KV 空間，答案就會回到原始 GGUF。