開發者審計 443 個 GGUF 模型：64 個實際精度與檔名不符，llama.cpp 靜默替換導致 IQ2 膨脹至 4.5 bpw

據 Reddit r/LocalLLaMA 社群開發者實測，在審計 25 個開源庫中的 443 個 GGUF 量化模型後，發現有 64 個模型的實際精度與檔名標示不符。 此現象源於 `llama.cpp` 的 `llama-quantize` 工具限制：k-quants 與 i-quants 要求張量的第一維度必須能被 256 整除。若無法整除，工具會自動替換為相容的 32 區塊格式（如 i-quants 替換為 IQ4_NL，k-quants 替換為 Q4_0），導致實際權重佔用約 4.5 bpw（bits per weight），而非使用者要求的低位元類型。 這項靜默替換機制自 2023 年的 PR #3747 引入，雖然量化過程會在日誌中印出警告，但最終生成的 GGUF 檔名、模型卡（model card）與元資料仍會保留原先設定的低位元名稱（例如 IQ2_XXS）。 受影響的具體案例包含： - **Nemotron-3.5-Lightning**：因其 n_embd 為 2688，專家寬度為 1856 與 3712，導致約 99% 的參數被強制替換。其四個 IQ2 級別的模型檔名標示為 2.06 至 2.56 bpw，但實際測量皆高達 4.58 bpw。 - **Qwen3.8-Flash-Next**：51.9% 的參數被替換，標示為 1.56 bpw 的 UD-IQ1_S 檔案實際測量為 3.28 bpw。 - **Nemotron-3-Super-120B**：23 個量化級別中有 18 個包含替換格式。 審計也指出，MiniMax-M2.1、bartowski 的 Ornith-1.5 以及標準的 Llama 與 Qwen 模型則未受影響，顯示此問題取決於模型本身的張量維度架構，而非上傳者的操作失誤。開發者已編寫並開源一款僅依賴 Python 標準函式庫的檢測工具，可透過 Hugging Face 的範圍請求（range requests）直接讀取標頭檔來確認 GGUF 的實際 bpw。