Hugging Face TRLの知識蒸留が本採用に──約30PRの改修を経て安定版へ、複数教師の非同期蒸留も追加

大きなモデルの知識を小さなモデルに移す「蒸留（distillation）」は、Hugging FaceのRLライブラリTRLでは長らく実験的機能（trl.experimental）の扱いだった。それが2026年8月、2つのマイナーリリースを通じて本採用の機能へ育っていく過程を、GitHubの一次リリースノートで確認した。

3行まとめ

• TRL v1.10.0（8/13）でDistillationTrainerが約30PRの改修を経てtrl.experimentalから本体パッケージへ昇格
• v1.11.0（8/26）で非同期蒸留AsyncDistillationTrainerと複数教師対応MOPDが実験的機能として追加、教師はHTTP越しのvLLMサーバーとしてのみ扱う
• 設定ファイルにはteacher_top_k（デフォルト8）・max_staleness（デフォルト4）など、教師の全語彙分布を送らずに済ませる仕組みの具体的なデフォルト値が確認できた

約30本のPRを経てtrl本体へ昇格

TRL v1.10.0（2026年8月13日公開）のリリースノートは、この昇格をこう説明している。

After a ~30-PR refactor that reshaped its data contract, loss path, generation stack, config surface, and tests, DistillationTrainer and DistillationConfig graduate from trl.experimental.distillation to the top-level trl package. Same import surface as SFT / DPO / GRPO / KTO. The old experimental path still works and emits a FutureWarning (removal in v2.0.0).

（データ契約・損失計算・生成スタック・設定面・テストを作り直した約30本のPRからなるリファクタを経て、DistillationTrainerとDistillationConfigはtrl.experimental.distillationからトップレベルのtrlパッケージへ昇格する。SFT・DPO・GRPO・KTOと同じインポート方法になる。旧来の実験的パスも引き続き動作しFutureWarningを出す（v2.0.0で削除予定））

インポート文は次のように変わる。

# Before
from trl.experimental.distillation import DistillationConfig, DistillationTrainer

# Now
from trl import DistillationConfig, DistillationTrainer

リファクタの中身についても、リリースノートは「シグネチャの列をpromptに切り替え（messages形式は非推奨）、生成スタックをGRPOのものに固定し、チャンク化されたJSD損失を配線してフル・ロジット経路を削除し、Ligerパスをチャンク化パスと共有できるよう整理し、log()・training_stepのタイミング・_save_checkpointをGRPOから流用し、テストスイートをGRPO形式に作り直した」と、具体的な作業内容を列挙している。同時にtrl distillationというCLIコマンドも追加され、Vision Language Model（VLM）への対応も同じリリースで加わった。

TRL公式ドキュメントの「DistillationTrainer」ページには、実際に動かせるクイックスタート例が掲載されている。教師モデルにQwen2.5-1.5B-Instruct、生徒モデルにQwen2.5-0.5B-Instructを使い、trl-lib/ultrafeedback-promptデータセットのプロンプトで蒸留する、というシンプルな例だ。

# train_distillation.py
from datasets import load_dataset
from trl import DistillationTrainer

dataset = load_dataset("trl-lib/ultrafeedback-prompt", split="train")
trainer = DistillationTrainer(
    model="Qwen/Qwen2.5-0.5B-Instruct",
    teacher_model="Qwen/Qwen2.5-1.5B-Instruct",
    train_dataset=dataset,
)
trainer.train()

同ページによれば、このトレーナーは「生徒モデル自身のオンポリシー生成（vLLMでの高速化も選択可）に対して、教師の完全な次トークン分布をメモリ効率の良いチャンク化JSD（Jensen-Shannon Divergence）損失で一致させる」設計で、教師の密な分布を一度に全展開しないという。コントリビューターはCarlos Miguel Patiño氏とクレジットされている。

v1.11.0：教師モデルをHTTPサーバーとして扱う非同期蒸留

1つ後のリリース、TRL v1.11.0（2026年8月26日公開）では、蒸留の仕組みがもう一段進む。リリースノートにはこうある。

Async on-policy distillation, architected like AsyncGRPOTrainer: a background rollout worker generates the student's own completions and scores them against a teacher served over HTTP, so generation and training overlap instead of alternating. The teacher is never loaded locally — just a vLLM server URL.

（AsyncGRPOTrainerと同じ設計の非同期オンポリシー蒸留：バックグラウンドのロールアウトワーカーが生徒モデル自身の補完を生成し、HTTP経由で提供される教師モデルに対してスコアリングする。生成と学習が交互ではなく重なって進む。教師モデルはローカルにロードされず、vLLMサーバーのURLだけを指定する）

さらに、複数の教師モデルを使い分ける「MOPD（multi-teacher on-policy distillation）」にも対応する。

Also supports MOPD (multi-teacher on-policy distillation): pass more than one entry in teacher_server_urls and route each sample to a teacher via a teacher_id column (e.g. a math teacher and a code teacher, each served independently).

（MOPD（複数教師によるオンポリシー蒸留）にも対応：teacher_server_urlsに複数のエントリを渡し、各サンプルをteacher_id列経由でどの教師に回すかを指定する。たとえば数学担当の教師とコード担当の教師を、それぞれ独立したサーバーとして用意できる）

リリースノートに掲載されているコード例では、teacher_server_urlsに2つのサーバーURL（http://teacher-math:8000とhttp://teacher-code:8000）を渡し、学習データセットの各行がteacher_id列でどちらの教師を使うかを指定する形になっている。この機能はまだtrl.experimental.async_distillationにあり、v1.10.0で本採用になったDistillationTrainerとは違い、実験的機能の位置づけのままだ。

AsyncDistillationConfigのソースコード（async_distillation_config.py）を実際に取得すると、リリースノートには出てこない具体的なデフォルト値と、その設計意図を記したdocstringが確認できた。

出典: trl/experimental/async_distillation/async_distillation_config.py（v1.11.0タグ、GitHub rawで直接取得）

teacher_top_kの仕組みは、非同期蒸留がなぜ「教師モデルをローカルにロードしない」設計で成立するのかを説明している。教師モデルの語彙分布を丸ごとHTTP越しに送るのではなく、上位k件の候補トークンとその対数確率だけをvLLMのprompt_logprobsから取得し、残りは1つの「尾のバケツ」にまとめて近似する。これにより、フルボキャブラリー（数万〜十数万トークン）を毎ステップ転送せずに済む、という設計だと読み取れる。

何が変わるのか

蒸留の従来のやり方は、教師モデルの出力をあらかじめ用意し、それを目標にして生徒モデルを学習させるオフライン方式か、教師モデルを生徒と同じプロセス内にロードして都度呼び出すオンライン方式が主だった。AsyncDistillationTrainerが持ち込むのは「教師モデルはHTTPの向こう側にいるサーバーでよく、生成と学習を同時並行で進める」という設計だ。教師モデルをローカルにロードしない分、生徒モデルの学習に使えるメモリを圧迫しない、という利点が読み取れる。ただし、この利点はリリースノートの記述から読み取れる範囲の解釈であり、Hugging Face自身がそう明言しているわけではない。

クイックスタート例もconfig.pyのデフォルト値も、自分では実行していない

本記事はTRLのv1.10.0・v1.11.0のリリースノート本文に加え、AsyncDistillationConfigのソースコードと公式ドキュメントのクイックスタート例を情報源としている。ソースコードを読んでデフォルト値とdocstringの説明までは確認したが、この記事を書いている自分の手元で、実際にQwen2.5-0.5B/1.5Bのペアを使ってDistillationTrainerを走らせたり、AsyncDistillationTrainerでHTTP越しの教師サーバーを立てて蒸留したりする検証は行っていない。MOPDで複数教師を使い分けた場合の具体的な効果（単一教師と比べた精度差など）についても、リリースノート・ソースコードのどちらにも数値による裏付けが示されておらず、本記事でも数字は示さない。teacher_top_kを8から増減させたときの分布近似の精度差についても、コード上のdocstring以上の実測データは確認できていない。

関連記事: ファインチューニング やり方・費用・いつ使うべきか【2026年入門】 / Hugging Face 使い方 / MAI Thinking 1──蒸留なしの新モデル

感想・指摘はコメント欄へ。