Transformers 新增 GGUF 壓縮推論路徑，首波聚焦 Apple Silicon

Hugging Face 於 9 月 22 日公布 Transformers 的 GGUF 壓縮權重推論路徑，讓開發者在 Python 模型與生成介面內使用 ggml 的 Metal 核心。首波聚焦 Apple Silicon 的單一對話，以及 Qwen3.5 密集與混合專家架構；公告亦列出相容的 Qwen3.8 權重。目前須從主分支安裝，尚不能假設一般穩定版套件已具備完整支援。[官方公告](https://huggingface.co/blog/transformers-llama-cpp-quants)

關鍵在權重的執行方式。舊式匯入會先把量化權重展開，新路徑則讓矩陣運算直接讀取壓縮區塊，降低完整展開所需的記憶體。載入時指定 `gguf_file`，後續仍能沿用生成與評測流程；若找不到相容的量化核心，載入器會退回反量化，部署者必須核對實際記憶體占用。[GGUF 文件](https://huggingface.co/docs/transformers/main/en/quantization/gguf)

生成迴圈也減少 CPU 與 GPU 互等。相關實作把裝置端的停止旗標非同步複製，留待下一步讀取，讓主機繼續排入運算；因此可能多跑一步，再裁掉多出的 token、輸出紀錄及快取。這需要可回捲的快取，不能推定所有生成模式都適用。[實作與限制](https://github.com/huggingface/transformers/pull/47975)

官方在配備 32 GB 統一記憶體的 M2 Max 測試三款權重，稱吞吐量接近 llama.cpp。不過，後者只量測生成 128 個 token，取三次平均；Transformers 則包含 12-token 提示的預填充，取三次預熱後的最佳值。兩組統計口徑不同，尚不足以宣稱效能相同。[測試方法](https://huggingface.co/blog/transformers-llama-cpp-quants)

對研究者而言，這條路徑方便在同一個 PyTorch 模型中檢查中間輸出、修改解碼規則並評估量化誤差。工程上仍須留意壓縮推論目前限於 MPS，其他架構可能沿用反量化；需要補齊長度的批次也無法套用所有捷徑。下一步應觀察穩定版納入時間、批次支援，以及中文長文與程式任務的品質、延遲和峰值記憶體。[支援範圍](https://huggingface.co/docs/transformers/main/en/quantization/gguf)

針對中文應用，建議用相同對話模板、輸出上限及抽樣設定，比較原始與量化權重的品質；長文件則分別記錄首字等待時間與後續生成速度。測試也應涵蓋冷啟動和持續服務，避免僅依預熱後的短提示測速估算使用者體感。這些是仍待完成的部署驗證，並非公告已提供的中文實測結果。