Kimi K3 GGUF / MXFP4：最大開源模型被社群量化後，真正問題不是幾 bit，而是保留哪些能力
Threads 討論 Kimi K3 2.8T / 896 experts 上架後，Hugging Face 社群快速出現 GGUF、llama.cpp 與 vision 支援。本文查證 moonshotai/Kimi-K3 與 Unsloth GGUF model card，整理 MXFP4、Q4/Q8 體積差與部署 caveat。
Kimi K3 一推出，Hugging Face 社群很快把這個 2.8T 參數、896 experts 的巨型 open-weight multimodal model 拆成多條可運行路線：原始 safetensors、Unsloth GGUF、llama.cpp fork、vision support，以及不同 quantization 取捨。這件事的重點不是「一般人能不能裝」，而是全球分散式模型工程社群已經能在幾天內完成量化、移植、修補與推理路線探索。
other / kimi-k3，不是 MIT / Apache。已查證重點
| 來源 | 事實 | Caveat |
|---|---|---|
| moonshotai/Kimi-K3 | open-weight、native multimodal agentic model；KDA + Attention Residuals；Stable LatentMoE activates 16 out of 896 experts。 | 需要 trust_remote_code 類型部署風險評估；license 是 Kimi-K3 custom license。 |
| Unsloth/Kimi-K3-GGUF | 提供 GGUF；model card 寫明 Q8 / full precision lossless 只比 Q4 大約 50GB，且有 vision support。 | 需使用 Unsloth 的 llama.cpp PR fork 或 Unsloth Studio；不是 vanilla llama.cpp 保證支援。 |
| Threads 社群觀察 | Unsloth 保留全部 experts 用低位元 GGUF；另有社群剪枝路線保留原生 MXFP4。 | 剪枝 / expert removal 的品質需 benchmark 驗證；容量變小不等於能力保留。 |
為什麼 Q4 / Q8 體積差不大
Kimi K3 原始設計已使用 MXFP4 weights / MXFP8 activations 的量化感知訓練，因此「Q4」與「Q8」在這類模型上不是傳統 dense FP16 → 4-bit 的簡單概念。Unsloth model card 明確寫到 full precision lossless Q8 只比 Q4 大約 50GB，原因在於大部分 expert 權重本來就已是 MXFP4 形式。
真正要問的不是幾 bit
- 保留全部 experts：容量大，但較接近原模型能力分布。
- 剪掉 experts：容量小，可能更容易本地部署，但能力、長尾知識與多模態表現可能受損。
- GGUF / llama.cpp 路線：降低運行門檻，但 kernel、vision、long context、MoE routing 都可能需要專門 patch。
Kate 判斷
對 Allen 來說，Kimi K3 本地部署短期仍不是「工作站就能輕鬆跑」的級別；594GB 起跳、768GB RAM 才安全的說法方向合理。但這篇值得收錄，因為它展示了開源模型生態的速度：官方釋出後，社群會自動補上 quantization、runtime、剪枝、benchmark 與工具鏈，這是封閉模型沒有的分散式研發複利。