AngelSlim：騰訊把量化、投機解碼與蒸餾收進同一個倉庫之後

壓縮工具箱要解決的是腳本散落問題，不是演算法問題

大型模型壓縮的難處很少在公式本身。FP8、INT4、NVFP4 這些量化格式，學術界與各家框架都有實作；投機解碼的草稿模型訓練流程也已經被討論了好幾年。真正耗掉工程時間的是另一件事：同一個團隊要同時維護量化腳本、草稿模型訓練腳本、蒸餾流程，以及對應不同模型結構的設定檔，而這些東西往往散在好幾個 repo、好幾種啟動方式裡。AngelSlim 的定位就是把它們收進同一個倉庫。README 開頭寫得很直白，它自稱是「a more accessible, comprehensive, and efficient toolkit for large model compression」，重點在 comprehensive 這個字。從 repo 結構看，量化、投機解碼、蒸餾、稀疏注意力各有自己的 features 文件目錄，設定則集中在 configs 底下，依模型分資料夾，例如 configs/flux、configs/seed_oss。這種安排的意義是：當你要對一個新模型做壓縮，起點不是空白檔案，而是複製一份既有模型目錄再改。目標讀者因此很清楚，是手上已經有模型權重、需要自己跑壓縮流程的團隊，而不是只想找一個現成推論服務的人。

倉庫裡同時住著兩條技術路線：改權重與改解碼

把 AngelSlim 的發布紀錄按時間排開，會看到兩條平行的線。第一條是改變權重本身，包括 FP8-Static、W4A8-FP8、NVFP4、2-bit、1.25-bit 等量化格式，以及 DAQ、TEQUILA、Sherry 這些量化演算法，還有蒸餾與量化感知蒸餾。第二條不動權重，改的是生成過程，包括 Eagle3 草稿模型訓練、DFlare 的區塊擴散投機解碼、D-Cut 的自適應驗證深度剪枝，以及 SpecExit 的推理提前退出。第三條比較邊緣，是 Stem 這類稀疏注意力演算法，針對長上下文 Prefill 階段動態挑選 top-k key block。這三條線共用同一個 repo，但彼此幾乎不互相依賴。對使用者的實際影響是：你不太可能同時用到三條線，採用時應該只挑一條深入，把其他目錄當成不相關的程式碼。反過來說，這種聚合也讓 repo 的維護表面積變大，任何一個模組的相依套件升版，都可能讓其他模組的安裝說明過期。

量化流程的實際入口是 configs 目錄與 ptq 腳本

README 沒有給出完整的安裝指令，能確認的執行入口有兩處。一是 configs 目錄，依模型分資料夾，README 明確點名 configs/flux 與 configs/seed_oss 兩個路徑。二是 scripts/ptq，README 在提到 Hy3 的 FP8-Static 與 SmoothQuant 支援時，連到 scripts/ptq 這個目錄。也就是說，量化這條線的操作方式是設定驅動：你在 configs 底下找到對應模型的目錄，調整裡面的設定，再透過 scripts 底下的腳本執行。這種設計的好處是流程可重跑，設定進版本控制之後，別人能複現同一組量化參數。壞處是文件必須跟上，因為設定鍵的語意不會寫在程式碼註解以外的任何地方。文件站是 angelslim.readthedocs.io，README 對不同功能的連結指向不同路徑，例如 Eagle3 指向 features/speculative_decoding/eagle/index.html，Stem 指向 features/sparse_attention/stem.html，DFlare 指向 features/speculative_decoding/dflare.html，蒸餾指向 features/distill/index.html。這些路徑本身透露了 repo 的資訊架構，也意味著查文件時要按功能模組去找，而不是找一份統一的快速開始。

已發布與已支援是兩種不同的完成度

讀發布紀錄時要區分兩種措辭。一種是「We have released」，後面通常接一個演算法名稱與論文連結，例如 DAQ、TEQUILA、Sherry、SpecExit、D-Cut、Stem、DFlare，這類項目有自己的分支或子目錄，例如 Sherry 的程式碼在 sherry 分支的 Sherry 目錄，TEQUILA 在 tequila 分支的 TernaryQuant 目錄。另一種是「We now support」，後面接的是既有流程擴展到新模型或新格式，例如 FP8-Static 支援 Hy3、NVFP4 支援 Qwen3 系列、量化支援 GLM-4.6 與 Qwen3-VL。兩者的差別在於前者是新增能力，後者是既有能力覆蓋更多模型。對採用者來說，後者通常風險較低，因為底層流程已經跑過其他模型；前者則需要自己驗證論文實作與 repo 程式碼是否一致。這也是為什麼光看發布頻率不能判斷成熟度，同一個 repo 裡，一個已經支援多個模型家族的量化流程，和一個剛發布的稀疏注意力演算法，實務上的穩定程度不會一樣。

授權標示為 NOASSERTION，這件事本身就是採用門檻

GitHub 對這個倉庫的授權標示是 NOASSERTION，意思是平台無法從倉庫內容自動判定授權條款。這不等於沒有授權，也不等於授權有問題，但它確實意味著你不能從 metadata 得到答案，必須自己打開倉庫根目錄的 LICENSE 檔逐條確認。對個人研究或內部實驗，這通常不是阻礙；對要把量化後的權重放進商業產品、或要把訓練腳本併入公司內部流程的團隊，這是第一個要釐清的問題。另一個容易混淆的點是模型權重與程式碼的授權可能不同。README 提到多個已發布權重，包括 Hy-MT1.5-1.8B 的 2-bit 與 1.25-bit 版本、HY-1.8B-2Bit、Qwen3-32B-NVFP4 與 Qwen3-235B-A22B-NVFP4，這些權重託管在 Hugging Face 與 ModelScope 的 AngelSlim 組織下，各自的授權要分別確認。程式碼可用不代表衍生權重可用，反過來也一樣。

什麼情況下這個工具箱是錯的選擇

如果你的需求是「把一個已經量化好的模型跑起來」，AngelSlim 幫不上忙。它產出的是壓縮後的權重與執行壓縮的腳本，不是推論服務。README 提到 214 GB 的 Hy4 preview GGUF 能在筆電 4090 加四張 A4000 的組合上跑出 1.02 tokens/s，但那個部署路徑走的是 Prima.cpp，不是 AngelSlim 本身，README 也把它標為 deployment guideline。第二種不適合的情況是模型不在支援清單裡。量化流程高度依賴模型結構，MoE 與稠密模型的處理方式不同，VLM 與純文字模型也不同，README 列出的支援範圍集中在 Hunyuan、Qwen3、Qwen2.5VL、DeepSeek-R1/V3、Kimi-K2、GLM-4.6、Seed-OSS、FLUX 這些家族。第三種情況是團隊沒有能力驗證壓縮後的品質。發布紀錄裡的數字，例如 0.7% 的 SWE-bench Pro 效能下降、DFly 相對 AR 的 2.40 倍加速、D-Cut 在高併發下最多 15.7% 的吞吐提升，都是專案方在特定設定下量測的結果，你的模型、你的資料分布、你的硬體不會自動複製這些數字。沒有自己的評估流程，量化就只是把不確定性往後推。

與 llama.cpp 量化路線的差別在於訓練端與部署端的分工

拿 llama.cpp 的量化工具鏈來對比最能說明定位差異。llama.cpp 的量化是部署導向：把權重轉成 GGUF 格式，在 CPU 或混合裝置上執行，流程相對單一，工具與執行引擎綁在一起。AngelSlim 涵蓋的範圍更靠近訓練端，量化只是其中一環，它同時處理投機解碼的草稿模型訓練、蒸餾、量化感知蒸餾，甚至量化感知蒸餾在 Megatron-Core 上的分散式訓練，支援 TP/EP/CP/SP 並行。兩者並非互斥，README 提到 STQ1_0 的 1.25-bit kernel 曾以 PR 形式提交到 llama.cpp（PR #22836），而 Hy4 preview 的部署走的是 Prima.cpp。這說明 AngelSlim 的產出可以流向其他執行引擎，它自己不承擔推論服務的角色。如果你的團隊已經在用 llama.cpp 或 vLLM 部署，AngelSlim 的價值在於上游的壓縮與訓練流程；如果你要的是一條從權重到服務的完整路徑，這個 repo 只覆蓋前半段。

維護成本落在設定檔與分支上，不在主線程式碼

這個倉庫的維護模式有一個明顯特徵：部分演算法程式碼放在獨立分支，例如 Sherry 在 sherry 分支、TEQUILA 在 tequila 分支，主線的 configs 與 scripts 則持續吸收新模型的支援。對使用者的實際影響是，你要用的功能可能不在 main 分支上，升級時得同時追蹤主線與該功能分支的變化。發布節奏可以從版本號看出輪廓，v0.2.0 在 2025 年 11 月，v0.3.0 在 2026 年 1 月，v0.5.0 在 2026 年 6 月，中間隔了將近五個月，但發布紀錄的更新頻率遠高於版本號，2026 年上半年幾乎每個月都有新支援或新演算法。這意味著如果你按版本號升級，會錯過不少模型支援；如果你跟著 main 分支走，就得接受設定檔與腳本介面可能變動。實務上的做法是鎖定一個 commit，把對應的 configs 目錄一起複製進自己的專案，而不是直接依賴 repo 路徑。這樣即使上游改了設定鍵，你的流程仍可重跑。

編輯結論

AngelSlim 適合已經鎖定特定壓縮路線、需要一份可重跑的訓練或量化腳本的團隊，尤其是要處理 Hunyuan、Qwen3 這類在 repo 內有對應 configs 目錄的模型。若你只是想在單張消費級顯卡上跑一個小模型，或需要一套穩定 API 的推論引擎，這個 repo 不是那個東西，它的產出是權重與腳本，不是服務。動手前先確認三件事：你要的模組在 README 裡是「已發布」還是「已支援」，兩者對應的完成度不同；對應的 configs 或 scripts 子目錄是否真的存在於 main 分支；以及倉庫的 LICENSE 檔實際內容，因為 GitHub 標示為 NOASSERTION，代表無法從 metadata 判定授權條款，商用前必須自行核對原始檔案。

官方來源

1. Issues
2. Project website
3. README
4. Releases
5. Tencent/AngelSlim on GitHub