AtomicBot 的 llama.cpp 分支，兩條路都加速
4 項改動看懂 AtomicBot 的 llama.cpp 分支：Gemma 4、Qwen 3.6、TurboQuant KV 與權重壓縮，最快可達 30-50% 吞吐提升。
這篇整理 AtomicBot 的 llama.cpp 分支如何同時從推理流程和記憶體壓縮兩端提速，幫你判斷 Gemma 4、Qwen 3.6、TurboQuant KV 與權重壓縮哪個最值得先試。
AtomicBot-ai 的 atomic-llama-cpp-turboquant 分支主打不換整套 serving 架構，也能把 tokens per second 往上推。依 repo 的 matrix bench，Gemma 4 的短提示吞吐最高可多 30-50%，TurboQuant 路徑則宣稱 KV 壓縮約 4.3 倍。讀完這 4 項，你大致就能判斷自己該先碰哪一條加速線。
| 項目 | 最佳場景 | 報告增益 | 主要限制 |
|---|---|---|---|
| Gemma 4 MTP | Gemma 4、頻寬受限 | 約 30-50% 短提示吞吐 | 需要 assistant head |
| Qwen 3.6 NextN | Qwen 3.6 dense / MoE | 35B-A3B 約 24-36%，27B dense 約 5-7% | 需 combined *_MTP.gguf |
| TurboQuant KV | 記憶體壓力大 | 約 4.3 倍 KV 壓縮 | turbo3 設定效果較佳 |
| TurboQuant 權重 | 部署空間緊 | 低位元權重壓縮 | 依 backend 有取捨 |
1. Gemma 4 的 MTP 先把短提示拉快
訂閱 AI 趨勢週報
每週精選模型發布、工具應用與深度分析，直送信箱。不定期，不騷擾。
不會寄垃圾信，隨時可取消。
這個分支最醒目的能力，是替 Gemma 4 加上 Multi-Token Prediction 的 speculative decoding。它透過 --mtp-head 載入官方 gemma4_assistant head，讓 draft 與驗證重疊執行，短提示時最容易看到吞吐提升。
repo 的 matrix bench 顯示，Gemma 4 26B-A4B 與 31B 在 f16 KV 下，可拿到約 30-50% 的 throughput 增益。它也刻意避開常見 draft model 的額外成本，不需要第二個 context、第二個 tokenizer 或第二份 KV cache。
- 支援 Gemma 4 E2B、E4B、26B-A4B、31B
- 建議 assistant quant：
Q4_K_M - 非同步流程用
llama_decode_mtp_async與llama_decode_mtp_wait - 最適合頻寬先卡住、不是算力先卡住的工作負載
2. Qwen 3.6 的 NextN 走更直接的提速路線
如果你跑的是 Qwen，這個分支提供 NextN speculative decoding，透過 --spec-type nextn 和 --model-draft 啟用。draft context 直接重用 target 的 llama_model，所以不必再掛第二次 mmap，部署也比獨立 assistant model 乾淨。
repo 提到，Qwen 3.6 35B-A3B MoE 可提升約 24-36%，27B dense 在 MacBook Pro M4 Max 單槽測試下約 5-7%。如果你想要速度變快，但不想把 serving pipeline 改得太複雜，這條線很實用。
- 對應 Qwen 3.6 27B dense 與 35B-A3B MoE
- 使用合併後的
*_MTP.ggufdraft - 可搭配 AtomicChat Qwen 3.6 UDT collection
- draft tensor 固定在
Q8_0，提升接受穩定性
3. TurboQuant KV 壓縮，先把記憶體壓力降下來
TurboQuant 是這個分支的另一條主線，重點放在 KV cache 壓縮。它採用 WHT 旋轉的低位元量化，並為 Metal TurboFlash、CUDA、Vulkan、HIP 提供 backend 原生 kernels。當 context 變長或 batch 壓力升高時，這種做法特別有感。
專案宣稱 -ctk turbo3 -ctv turbo3 可達約 4.3 倍 KV 壓縮。對 memory-bound 的模型來說，這通常比單純追求算力更有效，因為它直接減少了記憶體流量與 device 端工作集。
-ctk turbo3 -ctv turbo3
--draft-block-size 3
-ngl 99 -ngld 994. TurboQuant 權重壓縮，讓模型先瘦身再上線
除了 KV cache，這個分支也支援低位元權重壓縮，像 TQ4_1S、TQ3_1S 這類格式。這讓你在 inference 開始前就先把 footprint 壓小，對筆電、小型 GPU，或 CPU-GPU 混合部署都很實際。
它不只是省硬碟空間。更小的權重通常代表較快載入、更低記憶體壓力，也更容易和既有 GGUF 流程搭配。如果你本來就熟悉 llama.cpp 的模型格式，這一項最容易直接試跑。
- 常見格式：
TQ4_1S、TQ3_1S - 適合模型大小本身就是瓶頸的場景
- 可和量化 assistant head 一起使用
- 仍沿用同一套 llama.cpp serving 流程
5. 多模態與快取整理，讓混合工作流少一點摩擦
這個分支也把 speculative decoding 延伸到多模態服務。README 提到 --mmproj 可以和 MTP、NextN 或 Eagle3 一起在單槽載入，文字輪次享受 draft 加速，圖片輪次則回到一般 target decoding。
另一個實用細節是 -hf 下載的 Hugging Face cache 位置改成標準路徑，方便和其他工具共用，也比較不會在不同環境之間留下難整理的模型檔。
- 單槽支援多模態加 speculative decoding
- 文字輪次可走 draft acceleration
- 圖片輪次維持 target decoding
- Hugging Face cache 位置更貼近標準工具習慣
怎麼挑
如果你跑 Gemma 4，而且瓶頸是記憶體頻寬，先試 MTP，再看 TurboQuant KV。若你主要是 Qwen 3.6，用 NextN 會更直接，尤其是 35B-A3B MoE，repo 報告的提升最明顯。兩種情況都一樣，這個分支的價值在於不離開 llama.cpp，就能先拿到一段可觀的加速。
如果你最在意的是縮小記憶體占用，先從 TurboQuant KV 和權重壓縮下手。若你的工作負載以文字為主、又特別在意短提示延遲，MTP 會是最值得先試的一項。若你同時處理圖文混合流量，多模態路徑可以看，但圖片輪次仍會比較像一般 target decoding。