AngelSlim 評価：量子化と投機的デコーディングを1つのリポジトリに束ねた腾讯の圧縮ツールキット
Model compression toolkit engineered for enhanced usability, comprehensiveness, and efficiency.
ひと目でわかる
- これは何？
- AngelSlim は PTQ 量子化、QAT 蒸留、投機的デコーディング、疎な注意機構を同じツリーに同居させたモデル圧縮ツールキットである。便利さの代わりに、どの手法がどのモデルで検証済みなのかを利用者側が確かめる必要がある。
- 誰に向いている？
- AngelSlim が向くのは、Hunyuan 系や Qwen3 系の重みを自前で圧縮し、量子化・投機的デコーディング・蒸留を別々のリポジトリで管理したくないチームである。逆に、単一モデルの INT4 量子化だけが目的なら、llm-compressor や AutoAWQ のほうが工程は短い。
- 商用利用できる？
- まず確認が必要です。このリポジトリのライセンスは自動分類の対象外なので、商用利用の前に LICENSE ファイルを読んでください。
- 今もメンテナンスされている？
- されています。最後のコミットは 11 日前です。
- 何の言語で書かれている？
- 主に Python です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
AngelSlim が埋めようとしている穴は「手法の散在」である
大規模モデルを小さくする作業は、実際には複数の独立した工程に分かれている。重みを低ビット化する量子化、教師モデルから生徒モデルへ知識を移す蒸留、下書きモデルで本命モデルの推論回数を減らす投機的デコーディング、長い文脈の Prefill を削る疎な注意機構。それぞれ別の研究グループが別のリポジトリで公開し、設定ファイルの書き方も評価スクリプトの呼び方もばらばらである。AngelSlim はこの4系統を1つの Python パッケージにまとめ、量子化アルゴリズム側では FP8-Static、SmoothQuant、NVFP4、W4A8-FP8、DAQ、TEQUILA、Sherry、STQ1_0 といった名前が同じツリーの下に並ぶ。README が掲げる「more accessible, comprehensive, and efficient」という表現は、要するにこの散在を減らすという主張である。対象読者は、研究用のスクリプトをそのまま本番パイプラインに持ち込みたくない ML エンジニアと、社内のモデルを特定の推論エンジン向けに変換する必要があるインフラ担当者になる。
量子化の入口は scripts/ptq と configs 配下のモデル別ディレクトリ
量子化まわりの構成は、アルゴリズムの実装とモデル別の設定が分離されている。README の更新履歴では、FP8-Static と SmoothQuant の Hunyuan 系 MoE 対応が scripts/ptq へのリンクで示され、FLUX の量子化とキャッシュは configs/flux、Seed-OSS は configs/seed_oss というディレクトリで案内されている。つまり新しいモデルを圧縮するときの出発点は、自分のモデル名に近い configs 配下のディレクトリを探し、そこにある設定を scripts/ptq のエントリに渡すという流れになる。対応モデルは Hunyuan 0.5B/1.8B/4B/7B、Qwen2.5VL の 3B/7B/32B/72B、DeepSeek-R1/V3、Kimi-K2、Qwen3-VL、Qwen3-Omni、GLM-4.6 と幅広いが、これはあくまで README が列挙している範囲であり、各モデルでどのアルゴリズムの組み合わせが検証済みかは個別のドキュメントを参照する必要がある。設定ファイルの粒度で対応状況が変わる点は、この種のツールキットでは珍しくないが、利用者にとっては「モデル名が載っている＝自分の構成で動く」ではないことを意味する。
投機的デコーディングは Eagle3 と DFlare で性格が分かれる
投機的デコーディング関連は、v0.3 で Eagle3 の学習と配備が全規模の LLM/VLM/Audio モデルに対してサポートされたと告知され、その後 DFlare としてブロック拡散型の投機的デコーディングが公開された。README は DFlare について「layer-wise fusion」を備え、最大 5.52 倍のエンドツーエンド高速化をうたうと記載している。加えて D-Cut という検証深さを適応的に刈り込む手法、SpecExit という推論の早期終了アルゴリズムも同じ系統に並ぶ。ここで注意したいのは、Eagle3 は下書きモデルを学習させる工程を含むのに対し、D-Cut や SpecExit は既存の投機的デコーディング構成に対する調整として位置づけられる点である。学習が必要な手法はデータセットと計算資源を要求し、調整型の手法は設定変更で試せる。同じ「投機的デコーディング」という見出しの下でも導入コストが一桁違うので、README の更新履歴を上から順に試す進め方は避けたほうがよい。
蒸留と QAD は Megatron-Core 依存という制約を持つ
蒸留は full-precision の HuggingFace モデルと、量子化済みの QAT 形式モデルの両方を対象にサポートされていると README は説明している。さらに scale-only の量子化対応蒸留（QAD）が Megatron-Core 上で Qwen3-MoE と Hunyuan 系に対して提供され、TP/EP/CP/SP の分散学習に対応すると記載されている。ここは AngelSlim の性格が最もはっきり出る部分で、Megatron-Core を前提とする機能は既存の Megatron ベースの学習基盤を持っているチームでなければ実質的に使えない。逆に HuggingFace モデル向けの蒸留はその制約から外れる。ドキュメントのディレクトリ構成も features/distill と features/qad/mcore_qad.md に分かれており、前者は比較的軽量、後者は分散環境前提という住み分けが読み取れる。自分のクラスタで Megatron-Core を動かしていないなら、QAD の節は読まなくてよい。
動かすまでの手順と、確認しておきたい設定の場所
リポジトリの構成から読み取れる導入手順は次のとおりである。まずリポジトリを取得し、Python 環境を用意してパッケージをインストールする。量子化を試す場合は scripts/ptq 配下のスクリプトを、対象モデルに対応する configs 配下のディレクトリ（例として configs/flux、configs/seed_oss）の設定と組み合わせて実行する。投機的デコーディングの学習は features/speculative_decoding/eagle および dflare のドキュメント、蒸留は features/distill、Megatron-Core 上の QAD は features/qad/mcore_qad.md がそれぞれ入口になる。配備済みの重みを試したいだけなら、Hugging Face の AngelSlim 組織配下に Qwen3-32B_nvfp4、Qwen3-235B-A22B_nvfp4、Hy-MT1.5-1.8B-2bit、Hy-MT1.5-1.8B-1.25bit、HY-1.8B-2Bit などが公開されているので、自分で圧縮する前にこれらの重みで推論エンジン側の動作を確認するほうが早い。README には具体的な pip コマンドや CLI の引数までは書かれていないため、正確なコマンドは readthedocs の該当ページを参照する必要がある。ここで推測でコマンドを書くことはしない。
1.25 bit と 2 bit の実運用はカーネル対応に律速される
AngelSlim の売りの一つは極端な低ビット化である。HY-1.8B-2Bit や Hy-MT1.5-1.8B-1.25bit といった重みが公開され、STQ1_0 は 1.25 bit モデル向けのカーネルとして llama.cpp に PR #22836 が出されていると README に記されている。ここには明確な制約がある。低ビットの重みは、それを解釈できるカーネルが推論エンジン側に存在しなければ動かない。PR が上流にマージされていなければ、利用者はフォークした llama.cpp をビルドするか、パッチを自前で維持することになる。また README が挙げる Hunyuan 4 の 770B 級モデルを 1.5TB から 214 GiB まで圧縮し、ノート PC とサーバーの組み合わせで 1.02 tokens/s を出したという記述は、あくまで公開されたブログとガイドラインに基づく事例であり、汎用的な速度保証ではない。圧縮率が上がるほど、量子化誤差の影響はモデルとタスクに依存して大きくなる。SWE-bench Pro で 0.7% の性能低下という数字も、そのタスクにおける結果であって、自分の用途にそのまま当てはまるとは限らない。
vLLM や llm-compressor と何が違うのか
比較対象として最も自然なのは llm-compressor である。llm-compressor は量子化に焦点を絞り、HuggingFace の transformers と compressed-tensors 形式を軸に、対応アルゴリズムと保存形式を明確に定義している。AngelSlim は量子化に加えて投機的デコーディングの学習フレームワーク、蒸留、疎な注意機構までを1つのツリーに含む点で範囲が広い。代わりに、llm-compressor が提供するような保存形式の統一や、量子化以外の機能を切り離したシンプルさは AngelSlim にはない。vLLM との関係も似ている。SpecExit は vLLM への PR #27192 として提供されており、AngelSlim は推論エンジンそのものではなく、推論エンジンに渡す前段の圧縮と学習を担う。したがって「AngelSlim か vLLM か」という選択は成立しない。正しい問いは「圧縮と下書きモデルの学習を AngelSlim で行い、推論を vLLM に任せる構成が自分のモデルで成立するか」である。
ライセンス表記の不明点と、更新頻度が意味する保守コスト
GitHub のメタデータ上、AngelSlim のライセンスは NOASSERTION と表示されており、OSI 承認ライセンスとして自動判定されていない。リポジトリに LICENSE ファイルが存在しても、その内容が標準的な条項と一致しない、あるいは複数の条項が混在している可能性がある。商用利用や再配布を検討する場合、この点は法務確認の対象になる。ここで法的助言はできないが、メタデータの表示だけを根拠に「オープンソースだから自由に使える」と判断するのは避けたい。保守コストの面では、リリースが v0.2.0（2025年11月）、v0.3.0（2026年1月）、v0.5.0（2026年6月）と進み、README の更新履歴も 2025年8月から2026年9月までほぼ毎月埋まっている。活発であることは事実だが、裏返せば API と設定ファイルの形が変わり続けるということでもある。特定のバージョンに固定して運用するか、追従する担当を決めておかないと、configs 配下の設定が次回の更新で動かなくなる事態は十分に起こりうる。
編集部の結論
AngelSlim が向くのは、Hunyuan 系や Qwen3 系の重みを自前で圧縮し、量子化・投機的デコーディング・蒸留を別々のリポジトリで管理したくないチームである。逆に、単一モデルの INT4 量子化だけが目的なら、llm-compressor や AutoAWQ のほうが工程は短い。採用前に確認すべきは3点で、第一に LICENSE ファイルの実際の条項（リポジトリのメタデータは NOASSERTION であり、GitHub 上ではライセンスが確定していない）、第二に自分の対象モデルが configs/ 配下に存在するか、第三に圧縮後の重みを動かすランタイム側の対応状況である。特に STQ1_0 の 1.25 bit カーネルは llama.cpp への PR #22836 として提案中と README に記されており、上流に取り込まれていなければ自前でパッチを当てる前提で計画を立てることになる。
コミュニティノート