Hugging Face、大規模実行可能な知識蒸留手法を公開
本文の状態
日本語全文を表示中
詳細モードで約11分の本文を読めます。
同じ出来事の情報源
この情報源を基点に整理
Hugging Face Blog
Multiverse Computing の研究者らが、知識蒸留プロセスにおける計算リソースと時間を劇的に削減する技術的アプローチを提示した。
Continue in AI NEW LAB
このニュースを、実務の判断につなげる
AI NEW LABで、試したことや先に確認したい条件を共有できます。まずはログインなしで読めます。
AI NEW LABで論点を見るAI深層分析を開く2026年8月10日 19:53
AI深層分析
キーポイント
コスト削減手法の発表
Multiverse Computing の研究者らが、知識蒸留プロセスにおける計算リソースと時間を劇的に削減する技術的アプローチを提示した。
大規模展開の実現可能性
従来のコスト制約を打破することで、大規模なモデルやデータセットに対する知識蒸留の適用範囲が拡大すると示唆している。
Hugging Face での公開
この技術的知見は Hugging Face Blog を通じてコミュニティに共有され、開発者による実装や検証を促す形で行われた。
教師モデルのメモリ負荷削減
教師モデルのトップKロジットを事前にキャッシュすることで、学習中に教師モデルをメモリ上に保持する必要がなくなる。
新しいKLダイバージェンス損失関数
語彙サイズ×シーケンス長の行列を実体化しない効率的な計算手法により、VRAM使用量を大幅に削減する。
重要な引用
Making Knowledge Distillation Cheap Enough to Run at Scale
Multiverse Computing
Antonio Tiene
Iker García-Ferrero
Ali Hashemi
編集コメントを表示
編集コメント
計算リソースの制約が AI モデル開発の主要な障壁となっている中、蒸留コストを下げ大規模化を可能にする手法は実用面で極めて価値が高い。Hugging Face のプラットフォーム上でこの知見が共有されることは、オープンな技術進歩の加速に寄与する。
Source Article
元記事を日本語で読む
本文に関係しない購読案内、埋め込み通知、サイト内プロモーションは除いています。
知識蒸留(Knowledge distillation)は、より小さな学生モデルを訓練して、大きな教師モデルの性能に近づける手法として機械学習分野ではよく知られています。最近、gpt-oss、Qwen、GLM、Kimi といったオープンソースの大規模言語モデル(LLM)が台頭したことで、この手法は再び主要な研究テーマとなっています。
これらの超大型モデルをデプロイするには莫大なコストがかかります。例えば、最近の Kimi-K3 モデル は 2.8 兆個のパラメータを持ち、ロードするだけで VRAM を約 3TB も必要とします。そのため、これらのモデルを圧縮して小型化し、知識蒸留を通じて元の能力を回復させる手法が標準的なプラクティスとなっています。Nvidia(Nemotron 3 Puzzle 75B)や Multiverse Computing(Hypernova 60B)といった企業も、高品質な圧縮モデルを相次いでリリースしています。
蒸留ステップは最終的な品質を決定する最も重要な要素ですが、通常はパイプラインの中で最もコストがかかる部分でもあります。教師モデルと学生モデルの両方をメモリに保持し、すべてのトークンに対して語彙全体にわたる確率分布を生成するには膨大な VRAM が必要となり、数百台の GPU と慎重なテンソル並列化戦略がなければ実現できないのが現状です。
最新の論文 Efficient Knowledge Distillation for LLMs: Offline Top-K Logits and a Fused Chunked KL Loss では、この課題を 2 つのシステム変更によって解決しています。1 つ目は、教師モデルの上位 K 個のロジット(Top-K logits)を一度だけキャッシュし、学生モデルと同時並行でメモリ上に保持する必要をなくす手法です。2 つ目は、語彙サイズ×シーケンス長の行列を明示的に生成することなく計算できる新しいメモリエフィicientな KL 発散損失関数です。
これにより、PyTorch や NVIDIA Megatron-Bridge のデフォルト実装と比較して VRAM 使用量を劇的に削減できます。これらの改善により、単一の GPU で長文コンテキストの修復が可能になり、大規模な実験も現実的なコストで実施できるようになります。
なぜ蒸留による回復処理が高コストになるのか
標準的な手法であるオンライン蒸留では、Kullback-Leibler 分散損失(KL 損失)を用いて教師モデルと生徒モデルを同時にメモリ上に保持します。各学習ステップで教師モデルは完全な順伝播を実行して出力分布を生成し、生徒モデルはその分布に追従するように訓練されます。これは教師の完全な分布が利用可能であるため最も表現力豊かな設定ですが、一方でメモリーと計算コストが最も高くなるのも事実です。トークン位置ごとに完全な語彙サイズのテンソル 2 つを保持する必要があり、学習中に教師の挙動が変わらないにもかかわらず、すべてのステップで再計算を行わなければならないからです。
具体的な例として、gpt-oss-120b の語彙サイズは 201,088 トークンです。シーケンス長が 32K、バッチサイズが 4 の場合、教師の確率テンソル単体でも 4 × 201,088 × 32,768 という形状になります。bfloat16 で計算すると、このテンソルだけで約 50GB の VRAM を消費します。これに勾配、活性化値、モデルの重み、オプティマイザの状態を加えると、蒸留の単一学習イテレーションで VRAM は最大約 250GB に達し、H200 や B200 GPU が提供する容量さえも超えてしまいます。本稿では、KL 損失を再定式化してデータをチャンク単位で処理することで、このコストをほぼゼロに抑える方法を示します。
*Dense KL は最大約 250GB に達し、単一の H200 の 141GB という容量を超えます。一方、融合されたチャンク化損失はそのような急激なピークを生じず、最大でも約 128GB で収まります。出典:論文 Figure 1。
システム変更の 2 つのポイント
オフライン蒸留。 各ステップで教師モデルを再計算するのではなく、その出力は一度だけ計算して、各位置における最も確率の高い上位 100 トークンをキャッシュし、学生モデルはそのキャッシュに対して訓練します。教師モデルは訓練中にメモリ上に保持する必要がなく、キャッシュが作成された後は再度実行する必要もありません。そのため、同じキャッシュを多数の検証実験で再利用できます。
融合され、チャンク化された KL 損失。 なぜこの損失計算自体が高コストになるのかを理解するために、その実態を想像してみましょう。シーケンス内のすべてのトークン位置と、語彙内のすべての単語に対して、学生モデルの予測が教師モデルとどれだけ乖離しているかを示す数値が必要です。これをグリッドとして配置すると、1 行が語彙項目に対応し、1 列がシーケンスの各位置に対応します。語彙サイズが 10 万語を超え、シーケンスも長い場合、このグリッドは膨大な規模になります。デフォルトの KL 損失計算では、単一の数値を生成する前に、この全体を構築してしまいます。
同じ数学的性質を持つ損失を計算する 3 つの方法を比較します:
- Dense KL は教科書的なアプローチです。キャッシュされた上位 100 のロジットから教師モデルの完全な確率グリッドを再構築し、学生モデル自身の対数確率の密なグリッドと比較します。これはオンライン蒸留がすでにどのように動作しているかに最も近い形式であり、正しさの確認のためのベースラインとして使用しますが、メモリ上には語彙×シーケンスのグリッドを 2 重に保持することになります。
Forward-chunked KL は、教師モデルをスパースな状態に保ちます。これは、各位置でキャッシュされたトップ 100 のロジットのみを使用し、それを密なグリッドに展開しないことを意味します。損失は断片ごとに計算され、シーケンス位置の断片を一度に一つずつ処理します。これにより、密な教師モデルと密な比較が不要となり、ベンチマークでは 3 つの方法の中で最も高速であることが確認されています。ただし、この手法にも盲点があります。学生モデル自身のロジット、つまりモデルの出力層が生み出すグリッドは、依然として完全な状態で計算され、逆伝播のために保持されるため、シーケンス長に対してメモリ使用量が急激に増加してしまいます。
Fused chunked KL は私たちの主な貢献であり、さらに一歩進んで、モデルの出力投影を損失計算に直接統合します。これにより、学生モデルの完全なロジットグリッドは一切生成されません。シーケンスを断片ごとに処理し、隠れ状態からその断片のロジットへ投影し、結果を累積された損失に折りたたみ、次の断片に進む前にその断片を破棄します。逆伝播では、各断片を保存するのではなく、必要に応じてその場で再計算します。この手法のコストは、投影処理を順伝播と逆伝播の 2 回行う点ですが、その代わりとして、ピークメモリ使用量はシーケンス長に対して線形に増加するだけで、完全な語彙サイズとシーケンスサイズの積による急激なスパイクは発生しません。
以下の GIF は、密なアプローチと融合断片化アプローチの違いを示しています。前者は比較グリッド全体を構築して保持しますが、後者は一度に一つの断片のみを構築して破棄するため、メモリ使用量は単一の断片を超えて増加することはありません。
チャンク化された損失の実装をオープンソース化しました:github.com/CompactifAI/Full-Chunked-KL-Loss
実務における変化
以下の表で、オンライン知識蒸留と先ほど説明した3つのオフライン損失実装の4つの設定を比較しています。H200 GPU 1台上で、教師モデルに Llama 3.1 8B Instruct、生徒モデルに 3.2B の Llama を使用し、コンテキスト長を 8K トークンとして評価した結果です。オフラインの実行ではトークンごとにキャッシュされた上位 100 個のロジットのみを使用しているにもかかわらず、4 つの設定ともほぼ同等のトレーニング損失に収束しました。
| 手法 (8K コンテキスト、単一 H200) | ピークメモリ | 反復時間 | スループット |
|---|---|---|---|
| オンライン蒸留 | 102.8 GB | 25.9 s | 237 TFLOP/s |
| オフライン、密度 KL | 78.3 GB | 18.5 s | 331 TFLOP/s |
| オフライン、前方チャンク化 KL | 61.8 GB | 18.4 s | 335 TFLOP/s |
| オフライン、融合チャンク化 KL | 58.3 GB | 20.2 s | 304 TFLOP/s |
4 つの手法すべてで損失曲線がほぼ完全に重なり、キャッシュされた上位 100 のロジットを用いたオフライン蒸留は、オンライン蒸留に対して損失がないことを裏付けています。出典:論文 Figure 2。
このシーケンス長では、融合チャンク化損失はまだ最速の選択肢ではありません。追加の逆伝播投影コストが速度を少し落としているためです。しかし、その真価はコンテキスト長が伸びた際に発揮され、次のセクションで示されます。
長いコンテキスト長へのスケーリング
スケーリングパターンをより鮮明に確認するため、トランスフォーマー本体を持たない玩具の出力投影ネットワーク(損失カーネルのみ)で孤立ベンチマークを実行しました。32K トークンでは、密な損失でのピークメモリが 85.2 GiB であるのに対し、完全チャンク化バージョンでは 5.45 GiB に低下し、15.6 倍の削減となりました。また、密な損失は 64K トークン以降で完全に失敗します。
256K トークンでは、完全チャンク化損失が 11.6 GiB を使用するのに対し、次点となる他のチャンク化バリアントは 134.2 GiB を必要とし、その長さでの 1 イテレーションあたりの速度は約 3.3 倍速くなります。
GPT-OSS 20B モデルを 32,768 トークンのコンテキストで蒸留する際、融合損失によって解放されたメモリにより、セットアップを 4 つの GPU ノードから 1 つに縮小できました。ステップ時間は 57.0 秒から 12.23 秒へ短縮され、約 5 倍高速化されました。また、GPU あたりのスループットは 74.2 TFLOP/s から 345.7 TFLOP/s に向上しました。
生成された学生モデル
大規模な知識蒸留キャンペーンを可能にしたのは、効率的なオフライン設定です。その結果得られたコンパクトな学生モデルは、教師モデルである Llama 3.1 8B Instruct を約 32 億パラメータまで圧縮したものですが、BoolQ や HellaSwag では教師モデルの精度をほぼ維持しています。MMLU でもスコア差は約 9 ポイント以内で、パラメータ数は半分以下です。
*学生モデルはサイズが半分に減っても、短いコンテキストでの精度をほとんど維持します。出典:論文 Figure 6.*
この研究は、Multiverse Computing が進めている「大規模展開に適した蒸留と修復を実現する」取り組みの一部です。単発のレシピとしてではなく、チームが低コストで反復改善できる仕組みを提供することを目指しています。論文ではさらに、損失関数の選択やシーケンスパッキングが回復品質にどう影響するかといった追加の実験結果も紹介されています。
融合されたチャンク化損失の閉形式勾配や、完全なトレーニング設定など、技術的な詳細を知りたい方は、論文全文をご覧ください。あるいは、当社のチームにご連絡いただければ、ご自身の蒸留パイプラインへの適用についてもご相談できます。
また、チャンク化損失の実装をオープンソース化しました:github.com/CompactifAI/Full-Chunked-KL-Loss
原文を表示
Knowledge distillation, training a smaller student model to match the performance of a larger teacher, is a well-known technique in Machine Learning. With the recent wave of open-source Large Language Models, such as gpt-oss, Qwen, GLM, or Kimi, it has become a mainstream research topic again. Deploying these very large models is expensive: the recent Kimi-K3 model has 2.8 trillion parameters and needs roughly 3TB of VRAM just to load. Compressing them into smaller models and recovering the original capabilities through knowledge distillation has therefore become standard practice, with companies like Nvidia (Nemotron 3 Puzzle 75B) or Multiverse Computing (Hypernova 60B) recently releasing high-quality compressed models.
The distillation step is what decides most of the final quality, but it's also usually the most expensive part of the pipeline. Keeping both the teacher and student loaded, and producing a probability distribution over the entire vocabulary for every token, requires enormous amounts of VRAM, typically feasible only with hundreds of GPUs and careful tensor-parallelism strategies. Our latest paper, Efficient Knowledge Distillation for LLMs: Offline Top-K Logits and a Fused Chunked KL Loss, tackles this with two systems changes: caching the teacher's top-K logits once so the teacher never has to sit in memory alongside the student, and a new, memory-efficient KL-divergence loss that avoids ever materializing the full vocabulary-size × sequence-length matrix, cutting VRAM use far below what the default implementations in libraries like PyTorch or NVIDIA Megatron-Bridge achieve. Together, these two changes cut training cost enough to make long-context healing possible on a single GPU, and cheap enough to make large-scale experimentation practical.
Why distillation recovery is expensive
The standard setup, *online* distillation using the Kullback-Leibler divergence loss (KL loss), keeps both the teacher and the student loaded at the same time. At every training step, the teacher runs a full forward pass to produce its output distribution, and the student is trained to match it. This is the most expressive setup, since the full teacher distribution is available, but it is also the most memory- and compute-intensive: two full-vocabulary tensors have to be held per token position, and the teacher has to be recomputed on every single step even though its behavior does not change across a training run.
As a practical example, gpt-oss-120b has a vocabulary of 201,088 tokens. At a sequence length of 32K and batch size 4, the teacher-probability tensor alone has shape 4 × 201,088 × 32,768; in bfloat16, that's already about 50GB of VRAM for a single tensor. Add gradients, activations, model weights, and optimizer states, and a single training iteration of distillation can peak at roughly 250GB of VRAM, more than even an H200 or B200 GPU can provide. In this post, we show that reformulating the KL loss to process the data in chunks reduces this cost to almost nothing.
*Dense KL spikes to roughly 250GB, above a single H200's 141GB capacity. The fused chunked loss never forms that spike and peaks at about 128GB. Source: paper Figure 1.*
Two systems changes
Offline distillation. Instead of recomputing the teacher at every step, we compute its output once, cache the top-100 most likely tokens per position, and train the student against that cache. The teacher never has to sit in memory during training and does not need to be run again once the cache exists, so the same cache can be reused across many ablations.
A fused, chunked KL loss. To see why the loss itself is expensive, picture what it actually builds: for every token position in a sequence and every word in the vocabulary, the loss needs a number describing how much the student's prediction disagrees with the teacher's. Laid out as a grid, that's one row per vocabulary entry and one column per sequence position, for a vocabulary of 100K+ words and a long sequence, that grid is enormous, and the default way of computing a KL loss builds the whole thing before it can produce a single number.
We compare three ways of computing this same loss, all mathematically equivalent:
- Dense KL is the textbook approach. It rebuilds a full, dense teacher-probability grid from the cached top-100 logits and compares it against the student's own dense grid of log-probabilities. This is the version closest to how online distillation already works, so we use it as our correctness baseline, but it holds the full vocabulary × sequence grid in memory, twice over.
- Forward-chunked KL keeps the teacher sparse (only its cached top-100 logits per position, never expanded into a dense grid) and computes the loss piece by piece, one slice of sequence positions at a time. This removes the dense teacher and the dense comparison, and turns out to be the fastest of the three methods in our benchmarks. It still has one blind spot, though: the student's own logits, the grid produced by the model's output layer, are still computed in full and kept around for the backward pass, so memory still grows steeply with sequence length.
- Fused chunked KL, our main contribution, goes a step further and fuses the model's output projection directly into the loss computation. It never produces the student's full logits grid at all: it processes one chunk of the sequence at a time end to end, projecting hidden states to logits for that chunk, folding the result into the running loss, and discarding the chunk before moving to the next one. The backward pass recomputes each chunk on the fly instead of storing it. The cost is doing that projection twice, once forward, once in backward, but in exchange, peak memory grows only linearly with sequence length instead of spiking with the full vocabulary × sequence size.
The GIF below shows the difference between the dense and fused-chunked approaches: one builds the whole comparison grid and holds onto all of it, the other builds and discards one slice at a time, so memory never grows beyond a single chunk.
We have open-sourced the chunked-loss implementation: github.com/CompactifAI/Full-Chunked-KL-Loss
What this changes in practice
The table below puts all four setups head to head: online distillation, and the three offline loss implementations just described. Comparing them on a single H200 GPU with Llama 3.1 8B Instruct as teacher and a 3.2B Llama model as student at an 8K token context, all four reach near-identical training loss, even though the offline runs train against only the cached top-100 logits per token.
| Method (8K context, single H200) | Peak memory | Iteration time | Throughput |
|---|---|---|---|
| Online distillation | 102.8 GB | 25.9 s | 237 TFLOP/s |
| Offline, dense KL | 78.3 GB | 18.5 s | 331 TFLOP/s |
| Offline, forward-chunked KL | 61.8 GB | 18.4 s | 335 TFLOP/s |
| Offline, fused chunked KL | 58.3 GB | 20.2 s | 304 TFLOP/s |
The loss curves overlap almost exactly across all four methods, confirming offline distillation with top-100 cached logits is lossless relative to online distillation. Source: paper Figure 2. At this sequence length, the fused chunked loss is not yet the fastest option, its extra backward-pass projection costs a bit of speed, but its real advantage only shows up as context length grows, which the next section demonstrates.
Scaling to long context lengths
To see the scaling pattern more starkly, we ran an isolated benchmark on a toy output-projection network (no transformer body, just the loss kernel). At 32K tokens, peak memory falls from 85.2 GiB with the dense loss to 5.45 GiB with the fully chunked version, a 15.6× reduction, and the dense loss fails outright from 64K tokens onward. At 256K tokens, the fully chunked loss uses 11.6 GiB against 134.2 GiB for the next-best chunked variant, and is about 3.3× faster per iteration at that length.
Distilling a GPT-OSS 20B model at a 32,768-token context, the memory freed by the fused loss let the setup shrink from four GPU nodes down to one. Step time fell from 57.0 to 12.23 seconds, about 5× faster, and throughput per GPU rose from 74.2 to 345.7 TFLOP/s.
The resulting student
The efficient offline setup is what made a large-scale distillation campaign affordable in the first place. The resulting compact student, distilled from Llama 3.1 8B Instruct down to about 3.2B parameters, retains most of the teacher's accuracy on BoolQ and HellaSwag, stays within about nine points of it on MMLU, at less than half the parameter count.
*The student retains most of the teacher's short-context accuracy at less than half the size. Source: paper Figure 6.*
This work is part of Multiverse Computing's ongoing research into making distillation and healing practical to run at scale, not just as a one-off recipe, but as something teams can iterate on cheaply. The paper also covers additional ablations, such as how the choice of loss function and sequence packing affect recovery quality.
Want the full technical details, including the closed-form gradient behind the fused chunked loss and the complete training configuration? Read the full paper, or get in touch with our team to talk about applying this to your own distillation pipelines.
We have also open-sourced the chunked-loss implementation: github.com/CompactifAI/Full-Chunked-KL-Loss
関連記事
今日のまとめ
AIデイリーブリーフで今日の重要ニュースをまとめ読み