ドラフトトークンを並列生成する拡散モデル方式「DFlash」をGemmaで試した

これまでの記事（概念編・実装/検証編）で、LLMの生成を高速化する「MTP（Multi-Token Prediction）」という技術について解説してきました。簡単におさらいすると、軽量な「ドラフトモデル」が先に何トークンかまとめて予測しておき、本体のモデルがそれを一気にチェックする、という仕組みでしたね。予測が当たっていればそのぶん一足飛びに進めるので、体感速度が上がります。

このドラフトモデルの作り方にもいくつか方式があって、今回取り上げる「DFlash」は、画像生成でおなじみの拡散モデル(Diffusion Model)を使って、複数のトークンを一つずつでなく一気にまとめて予測する、という珍しいアプローチを取っています。対応モデルの幅広さや、既存方式のEAGLE-3を大きく上回る速度が謳われていて、期待の持てる技術です。

ただ、こうしたベンチマークは公式が用意した環境で測られていることが多く、手元のGPUで、しかもすでに専用のMTPモデルが用意されている相手(Gemma-4純正のAssistantモデル)とぶつけたときにどうなるかは、あまり見かけません。

そこで今回は、実装・検証編と同じ環境(RTX 3060 12GB、llama.cpp、同一のJavaScriptコーディングタスク)で、DFlashをGemma-4-12B-itのAssistantモデルと直接比較してみました。結果を先に言うと、DFlashはAssistantモデルに届きませんでした。ただその負け方が技術的に筋の通ったもので、DFlashの得意・不得意の輪郭がはっきり見えたので、ここから先はその中身を掘り下げていきます。

概要

新しいトークン予測技術として、以下の2つが立て続けに登場しました。

• 中国のDeepSeek社：DSparkというトークン予測技術
• カリフォルニア大学サンディエゴ校内Z-lab：DFlashというトークン予測技術

前者のDSpark^[1]は、自らリリースするDeepSeek-V4の推論を高速化することを目的にリリースされており、対応モデルもDeepSeek-V4/DeepSeek-V4-Flashのみとなっています。

これに対して、後者のDFlashは実に多くのモデルに対応しており、それぞれ専用のDFlashモデルというものが登場しています。Googleの純正MTPモデルであるAssistantのようにアドオンする形で適用することにより、トークン予測を実現するという仕組みになっているようです。

• Gemma-4シリーズ (12B, 26B-A4B, 31B)
• MiniMax-M2.7
• MiniMax-M2.5
• Qwen 3.6シリーズ(35B-A3B, 27B)
• Qwen3.5シリーズ (4B, 9B, 35B-A3B, 27B, 122B-A10B, 397B-A17B)
• Qwen3シリーズ (4B, 8B, Coder-30B-A3B)
• Kimi-K2.6
• GLM-5.1-FP8
• gpt-oss (20B, 120B)
• LLaMa3.1-8B-Instruct

Z-labとは、カリフォルニア大学サンディエゴ校(UCSD)で助教授を務める、Zhijian Liu氏が統括するラボであり^[2]、同時にNVIDIA社のリサーチサイエンティストも兼任しているそうです。アルゴリズム・システム・アプリケーションの各層にわたる包括的な革新を通じて、AIの小型化・高速化・効率化の実現に向けて活動しています。

今回は、このDFlash技術を使用することで、どの程度出力が高速化するのか、その動作検証も交えながら理解を深めたいと思います。

DFlashモデルによるトークン予測方式

DFlashは、「DFlash: Block Diffusion for Flash Speculative Decoding」^[3]という論文で紹介されています。

そもそもトークン投機予測については、割と以前から提唱されている論文があり、最初にリリースされた論文は2023年にGoogle Deepmindが発表している「Accelerating Large Language Model Decoding with Speculative Sampling」^[4]があります。

それらはひっそりと改善を継続しつつ、2025年にEAGLE-3というMTPドラフトモデルに昇華されてきつつも、実は自己回帰型から抜け出せずにおり、結局は大幅な速度改善にはつながってないと感じていたようです。

昨今、画像生成AIではよく用いられるDiffusion Modelというノイズ除去機構を備えた仕組みがLLMの領域にも参入してくるようになり、当初はMeta LLaDaというモデルから始まり、日本でもKDDI傘下のELYZA Labチームが「ELYZA-Diffusion-Instruct-1.0-Dream-7B」^[5]というモデルをリリースしています。

そうしたDiffusion Modelの特性をMTPドラフトモデルに持ち込んだのがZ-labのDFlashという技術です。大まかな仕組みは下図の通りです。

図1 DFlashのメカニズム

仕組みを見てみると、Gemmaに実装されていたAssistantモデルの作りに似ていますが、大きく異なるのは、ドラフトモデル内で行われるトークン予測の仕組みそのものです。後半のトークン評価方式部分はかなりGemmaのそれに酷似しています。

DFlashの場合、まずKVCacheは独立して構成されていますので、従来通りN+1トークンをメインモデルが予測したとき、その状態情報をもってKVCacheを更新します。この更新情報から抽出されたデータをDFlashモデル内のKVCacheへ注入するところから処理が開始されます。

Gemma Assistantではこの予測処理を非常に小さなニューラルネットワークを用いて高速かつ逐次的に実行し、予測トークンを必要数分だけ生み出したのち、評価ロジックに回していきます。

これに対してDFlashモデルでは小さなニューラルネットワーク内で自己回帰型モデルではなく、Diffusionモデルが構成されています。ここで、まさに画像を生成するかのように必要な予測トークンを順序正しく一斉に作成します。その時間はトークン長上限が多ければ多いほど時間がかかりますが、少なくとも逐次型よりも圧倒的に速い速度で作り上げられます。後続の処理は従来通り因果アテンションを使用したマスク処理で並行実行された結果が出力され、その結果に基づいて同時出力してよいトークンが決まるという仕組みです。

そのため、大きく速度面に寄与するであろうポイントは下図中央部分の青枠・赤枠で囲んだ部分で差がついてくることになります。

図2 Gemma AssistantモデルとDFlashモデルとの違い

llama.cppでの実行方法

まずは、モデルファイルを入手するところから始めます。

hf download google/gemma-4-12B-it
hf download z-lab/gemma4-12B-it-DFlash

llama.cppは今回 build 9850 を使用しています。最新のllama.cppを入手しておくと安心です。その中のPython言語で作られた変換ツールを使用して、各モデルをGGUFフォーマットに変換します。まずは本体モデルのGGUF変換を実施します。

$ python convert_hf_to_gguf.py \
~/.cache/huggingface/hub/models--google--gemma-4-12B-it/snapshots/cxxxxxx...a/ \
--outtype bf16 --outfile gemma-4-12B-it-b16.gguf

次に、DFlashモデルをGGUF変換します。

ここで重要になってくるのが、「--target-model-dir」の存在です。DFlashモデルを変換する際は、メインモデルを参照させる必要があります。この中のパラメータをもとにDFlashモデルが変換されて出力されます。

$ python convert_hf_to_gguf.py \
~/.cache/huggingface/hub/models--google--gemma-4-12B-it/snapshots/cxxxxxx...a/ \
--outtype bf16 --outfile models/gemma-4-12B-it-DFlash-b16.gguf \
--target-model-dir \
~/.cache/huggingface/hub/gemma-4-12B-it-qat-q4_0-unquantized/snapshots/c202...a/

以下のようなメッセージが出てうまく行かない場合、別途Huggingfaceから google/gemma-3-12b-it のリポジトリから tokenizer.model を直接ダウンロードし、これをキャッシュディレクトリに配置する必要がありますのでご注意ください。

INFO:hf-to-gguf:DFlash: Using tokenizer from target model: /home/aiuser/.cache/huggingface/hub/models--google--gemma-4-12B-it/snapshots/5854...7ced3

Traceback (most recent call last):
  File "/data/user_data/aiuser/llama.cpp/conversion/qwen.py", line 57, in set_vocab
    self._set_vocab_sentencepiece()
  File "/data/user_data/aiuser/llama.cpp/conversion/base.py", line 1589, in _set_vocab_sentencepiece
    tokens, scores, toktypes = self._create_vocab_sentencepiece()
  File "/data/user_data/aiuser/llama.cpp/conversion/base.py", line 1606, in _create_vocab_sentencepiece
    raise FileNotFoundError(f"File not found: {tokenizer_path}")
FileNotFoundError: File not found: /home/aiuser/.cache/huggingface/hub/models--google--gemma-4-12B-it/snapshots/585...ced3/tokenizer.model

あとは、これらを量子化することで4bit量子化モデルが作成されます。

$ /opt/llama/bin/llama-quantize \
models/gemma-4-12B-it-b16.gguf models/gemma-4-12B-it-q4_0.gguf q4_0

$ /opt/llama/bin/llama-quantize \
models/gemma-4-12B-it-DFlash-b16.gguf models/gemma-4-12B-it-DFlash-q4_0.gguf q4_0

実行時は、以下の引数を追加して実行します。DFlashモデルの場合、Drafter-MTPモデルは外部からアドオンする形になりますので、model-draft引数によりそのファイルを指定することでMTPを有効化します。

/opt/llama/bin/llama-server --model /opt/llama/models/gemma-4-12B-it-q4_0.gguf \
--model-draft /opt/llama/models/gemma-4-12B-it-DFlash-q4_0.gguf \
-t 4 --prio 2 --temp 1.0 --top-p 0.95 --top-k 64 --host 0.0.0.0 --port 8001 \
--device CUDA0 -mg 0 -sm layer --fit on -fa on -c 163840 -ctv q8_0 -ctk q8_0 \
--no-warmup --no-cache-prompt --cache-ram 0 \
--spec-type draft-dflash --spec-draft-n-max 4 --spec-draft-device CUDA0 \
--chat-template-kwargs '{"enable_thinking":true}'

引数の概要：

• --model-draft <gguf file>： Draft Modelの指定
• -sm layer： 複数CUDAデバイス搭載時のモデルディスパッチ方法
  • 執筆時点ではレイヤー単位の分散のみサポート
• --spec-type draft-dflash： 投機デコーディングのタイプ指定
  • タイプがDFlashであることを宣言し、DFlashへ対応できるようにします
• --spec-draft-n-max 4： 最大でいくつ先のトークンまで予測するか
  • 大きくしすぎると失敗時のペナルティが増えます
• --spec-draft-device CUDA0： ドラフト処理するデバイス
  • 複数CUDAデバイス搭載時は必要

検証：Gemma-4-12B-itにおけるDFlashの使用

検証環境

以下の簡易検証環境を用いて実験を行いました。

• 機種: hp Z440 Workstation改
  • CPU: Intel® Xeon® E5-2690 v4 x1
  • RAM: 48GB DDR4 RDIMM
  • SSD: Intel® DC S3700 Datacenter SSD (400GB SATA SSD)
  • GPU: NVIDIA GeForce RTX 3060 (Ampere 12GB GDDR6 VRAM)
• CUDA: 13.1
• Engine: llama.cpp Build 9574
  • Model: gemma-4-12B-it（https://huggingface.co/google/gemma-4-12B-it）
    • まず、モデルベースとしてGoogle Deepmindが開発した、量子化前提の学習処理を施したGemma-4-12b-it-QATモデルを使用します。
  • Drafter-Model: gemma-4-12B-it-DFlash（https://huggingface.co/z-lab/gemma4-12B-it-DFlash）
    • Z-labが提供する、Gemma-12B向けのDFlashモデルを採用します
    • 最大予測トークン数は4に設定しています(前回検証時と同じ設定を行ったうえで比較します)
  • KV Cache: 8bit Quantized（VRAMに効率よく収めるため、KVキャッシュを8ビット量子化しています）
  • Context Size: 163,840 tokens（VRAMに効率よく収めるため、コンテキストサイズを160kに制限しています）
  • Prompt-Cache: Off
  • Reasoning: On

テストケース

• 目的：Assistant利用・DFlash利用での速度推移を計測・比較します
  • 計測対象は速度のみとします。推論された内容は一切考慮しません
  • 書き出し時の時間、トークン量、トークン速度を計測します(これらの値は、llama.cppから出力されるログに記述される値を採用します)
• 手法：llama.cpp Webフロントエンドを使用し、以下の4ターンで質問

1. ブロック崩しのJavaScriptコードを書いて（HTML形式で）。
2. もっとかっこよくして。
3. ボールの動きを少しゆっくりにして。
4. バグチェックと最適化をして。

リソース消費状況

メモリリソースの使用状況は以下の通りとなりました。

表1 各MTP方式の違いによるメモリ消費量一覧

そのうち、MTPモデルが使用したメモリ容量は以下の通りとなり、およそ倍程度のメモリ消費量となりました。

表2 各MTP方式の違いによるMTPモデルに対するメモリ使用量合計値

この要因は主に、KVキャッシュの使い方の違いと言えます。AssistantモデルはKVキャッシュ自体をGemmaメインモデルと共有しています。これに対してDFlashでは、個別にKVキャッシュを保有します。そのため、Gemmaメインモデルと同様のキャッシュ構造をDFlashモデルにも保有させる必要があることが大きな要因となっています。

トークン速度比較結果（Assistant vs DFlash）

前回検証時と同様に、ターン毎のトークン取り込み速度比較を行いました。
結果として、トークン取り込みに関してはAssistantモデル使用時と大きなスループット差は発生していませんでした。

図3 トークン読み込み処理時の速度遷移

ターン毎の出力速度については、明らかにAssistantモデルのほうが勝っており、DFlashモデルは10～20tps程度遅れて推移するような状況となりました。

図4 トークン出力処理時の速度推移

以下は、上記グラフのもととなった実際の計測量です。Timeの単位はmsである点に注意してください。

表3 実際にログから確認された各種データ

全体的にDFlashを使った場合の推論時間はAssistantモデルを使った場合に比べて20秒以下の遅れが生じていました。今回、Assistantモデルがすでに一定の効率化が図れているような構成であったため、Diffusionモデルによる長所があまり目立たなかった可能性があります。

前回同様に、各ターンにおけるトークン出力速度の変化をグラフ化しました。

出力が後のほうが速度上昇している点はAssistantモデル・DFlashモデル共に同じ傾向ですが、全体的にAssistantモデルのほうが速度が速いことが確認できました。

図5 Assistantモデルによるトークン速度推移

図6 DFlashモデルによるトークン速度推移

また、DFlashモデル使用時の出力トークン速度について、およそ1700トークンをピークとしてその後わずかに速度が低下しているような傾向が一部のケースで確認されました。

トークン受け入れ率結果確認

前回検証と同様に、トークン受け入れ確率についても確認してみましょう。

表4 DFlashにおけるトークン受け入れ率

これをAssistant使用時のものと比較すると以下のようになります。

表5 トークン受け入れ率の比較（左がAssistantモデル、右がDFlashモデル）

このことから、DFlashでの結果が振るわなかったのは、どうやらAcceptanceが低かったことが原因のようです。今後、モデルチューニングがもう少し進み、より高速に処理できるDiffusionモデルが構成できるようになれば、あるいはAssistantモデルを超えることがあるかもしれません。

何とか改善できないか試してみる

本検証を通じてDFlashモデルがAssistantモデルにはちょっと及ばなさそうだということが確認されました。しかし、パラメータを修正することでもしかしたら速くなるんじゃないか？ということで、以下のことを考えて試してみました。

予測トークン数を大幅に引き上げてみる

現在、予測トークン量は4に設定しています。そもそもDFlashが用いる予測トークンの上限は前回Assistant検証時と同等のパラメータである4に設定していました。この値を大幅に引き上げたらうまく行くかもしれません。そこで、以下のように --spec-draft-n-max の値を4から15へ引き上げてみました。

/opt/llama/bin/llama-server --model /opt/llama/models/gemma-4-12B-it-q4_0.gguf \
--model-draft /opt/llama/models/gemma-4-12B-it-DFlash-q4_0.gguf \
-t 4 --prio 2 --temp 1.0 --top-p 0.95 --top-k 64 --host 0.0.0.0 --port 8001 \
--device CUDA0 -mg 0 -sm layer --fit on -fa on -c 163840 -ctv q8_0 -ctk q8_0 \
--no-warmup --no-cache-prompt --cache-ram 0 \
--spec-type draft-dflash --spec-draft-n-max 15 --spec-draft-device CUDA0 \
--chat-template-kwargs '{"enable_thinking":true}'

そうして実行して結果は以下の通りとなりました。

prompt eval time = 122.83 ms / 31 tokens ( 3.96 ms per token, 252.39 tokens per second)
eval time = 48833.63 ms / 1893 tokens ( 25.80 ms per token, 38.76 tokens per second)
total time = 48956.46 ms / 1924 tokens
graphs reused = 1444
draft acceptance = 0.10901 ( 1174 accepted / 10770 generated), mean len = 2.64

なんと全くの逆効果で、Acceptanceが下がり、その結果速度は逆に低下しました。

かなりたくさんのトークンを予測して生成してくれたようですが、ことごとく却下されており、どうやら予測長を長くするだけではダメなようです。

実は、上記ログの中に出ていた mean_len=2.64 というものが出ていたのですが、どうやらこれが「Acceptされたトークン数は大体これぐらい」という意味のようです。平均を確認してみると、3.38が記録されており、そもそもどうやらこのモデルにおいては --spec-draft-n-max の値は4が適切だったようです。

Gemma-4-12B-it-QATモデルをベースに組みなおしてみる

では、モデルの出力精度自体を引き上げてみればどうでしょうか。ということで、それに挑んでDFlashモデルを作成してみたらということで試しました。

今回使用したモデルは、手動で同じ量子化レベルを施す必要がありそうだったため、AssistantモデルのようにUnsloth Dynamic 2.0を用いた量子化モデルを適用させることが出来ませんでしたので、代わりにGemma-4-12B-it-QATモデルを使用することで、性能改善する可能性があるのではないかと考え、DFlashモデル含めて再構築をしてみました。

結果は以下の通りで、残念ながら期待通りの結果とはなりませんでした。あまりに出力速度が遅かったため、2ターン終了時で計測作業は中断しています。

prompt eval time = 475.69 ms / 31 tokens ( 15.34 ms per token, 65.17 tokens per second)
eval time = 102682.33 ms / 1963 tokens (52.31 ms per token, 19.12 tokens per second)
total time = 103158.02 ms / 1994 tokens
graphs reused = 1953
draft acceptance = 0.00025 ( 2 accepted / 7844 generated), mean len = 1.00

全くダメです。さらに遅くなりました。Acceptanceを見ると、今まで見たことない数字が並んでいました。0.00025=0.25%しかAcceptできてないということです。mean_len=1.00ということは、内訳を見てもわかるわけですが、GenerateしたトークンのほぼすべてがRejectされたということを示していて、そもそもDFlashを入れないほうがいいよということを示しているようなものです。

どうしてGemma-4-Assistantモデルを超えられなかったか？

どうやらZ-labが提供していたDFlashモデルは、あくまでGemma-4-12B-itバニラモデルにしか適用できない代物だったようです。残念・・そういう意味であれば、各モデルにきちんとMTPモデルが用意されているAssistantモデルのほうが使い勝手においてもよさそうです。

こうなってしまった要因としては、Gemma-4-Assistantのドラフトモデルの動きが高速すぎて、DFlashのドラフトモデルの速度を上回ってしまった点が考えられます。

前半で述べているように、従来のMTPドラフトモデルとDFlashの速度的なアドバンテージは、トークン候補の出力に関するところであり、この部分をDiffusionモデルを使用することで「一括出力」できることにありました。これに対してGemma-Assistantモデルにおいては以下の機能が非常に有効に働き、Diffusionモデルのアドバンテージを相殺したものと推察しています。

• KVキャッシュ共有機構
• 非常に小さなAttention機構

まず、Gemma-AssistantではKVキャッシュを共有する機構が初めから備わっていますが、DFlashではKVキャッシュは独立しており、その都度インジェクションを行わなければなりません。この部分においてアドバンテージはGemma-Assistant側にあります。

加えてGemma-Assistantの隠れ次元数はわずか1,024次元となっており、4層構造となっています。本書末尾に記載していますが、DFLashモデルの隠れ次元数はメインモデルと等しい3,840次元、5層構造となっており、計算量は圧倒的にGemma-Assistantモデルのほうが軽量になります。

いくらDFlashモデルがDiffusionモデルで一括出力できるといっても、計算量が多ければそれだけ出力にはより多くの時間を割くことになります。

今回の場合においてはGemma-Assistantモデルのほうが既に最適化された仕組みを持ってしまっていたため、優位に立つことが出来なかったと判断するべきでしょう。

そもそもDFLashが対抗馬として挙げていたのはEAGLE3モデルであり、今回のGemma-Assistantはそれと比べても先鋭過ぎたと言えるかもしれません。

しかし、今回は既存側に軍配が上がりましたが、もしかしたらQwen3.5であればもっと有意な結果が出たかもしれません。

まとめ

今回は、前回紹介した「MTP」という技術を独自に派生させた技術としてカリフォルニア大学サンディエゴ校（UCSD）内の研究チーム、Z-labがリリースしているDFlashという技術を紹介しました。Diffusionモデルをドラフトモデルに適用するというとてもチャレンジングな内容でしたが、今回はGemmaの純正ドラフトモデルであるAssistantの成績を上回ることはできませんでした。

原因を追跡してみると、トークン受け入れ率が純正ドラフトモデルと比較すると低く、そのことによるペナルティが大きく影響しているようでした。この確率を引き上げるための何らかの方策が理解できないことには、さらなる速度向上は難しいかもしれないと現時点では判断しています。

また、相手が悪かったとも感じています。Gemma-4 Assistantモデルは実用性を重視しており、Gemma-4が持つ共有KVキャッシュ技術をフル活用しており、これに対してDFlashでは従来通り独立したKVキャッシュへ書き込みに幾分どうしてもオーバーヘッドが生じてしまうので、それがスループット低下要因に傾いたのではないかと感じました。

LLMでDiffusionモデルを生かす取り組みもLLaDaやDreamというモデルが有名ですけれども、最近になってGoogle自体もDiffusion Gemmaというチャレンジングなモデルを登場させています。現在このDiffusion Gemmaについても動作確認等進めております。驚くほどのスループットをたたき出しておりますので、こちらもその興奮をそのままお送り出来たらなと記事を執筆中です。

現在Coding Agentの利用が増えるとともにLLMのスループットを問題視する声がよく聞かれており、VRAM高騰の影響もあってUnifiedメモリでも相応のスループットをもって動作するモデルの登場がかなり切望されている状況でもあります。

こうした研究は失敗してナンボの世界とも言われてる領域でもあり、今この瞬間にも新たな技術が誕生していたりします。何とかついていくべく、今後もこうした技術のウォッチを続けていきたいと思います。

参考文献

DFlash: Block Diffusion for Flash Speculative Decoding
Jian Chen, Yesheng Liang, Zhijian Liu
https://arxiv.org/pdf/2602.06036

Accelerating Large Language Model Decoding with Speculative Sampling
DeepMind: Charlie Chen, Sebastian Borgeaud, Geoffrey Irving, Jean-Baptiste Lespiau, Laurent Sifre and John Jumper
https://arxiv.org/pdf/2302.01318

DeepSeek-V4: Towards Highly Efficient Million-Token Context Intelligence
DeepSeek-AI
https://arxiv.org/pdf/2606.19348

[Speculative decoding] feat: add DFlash support
https://github.com/ggml-org/llama.cpp/pull/22105

補足情報

Gemma-4-12b-it-DFlashのモデル構造およびメインモデル接続

Gemma-4-12B-itに対してMTP機能を付与するDFlashモデルは、Gemma-4-Assistantモデルのアーキテクチャとは異なり、完全に分離したモデル（AssistantはKVキャッシュを共有している）となっています。アクティベーション関数等考慮しますと、どちらかと言うとQwenモデルに近似していると言えます。ただ、表記的にLA/GAとしているのは、位置づけとしてLA=SlidingWindowAttention、GA=FullAttentionで構成されており、こちらはGemma-4の構成を踏襲しているためです。

• 最大コンテキストサイズ: 256kトークン
• 全体で5ブロック構成(4+1の1グループ構成)
• HiddenSize: 3,840
• FFN方式: Dense
  • Activation関数: SiLU
  • Activation次元: 7,680

予測の過程では、生成される状態ベクトルのうち第1, 10, 19, 27, 36, 45層から各ベクトルを取得し、これらを連結・正規化しておきます。この情報をKVインジェクションによりドラフト側のKVキャッシュへ投入します。

ドラフトモデルへの入力には、確定したNトークンのEmbedding（埋め込み）ベクトルと予測数分のMASKトークンを結合した状態情報を、クエリ（Query）として用います。

本手法はアシスタントモデルとは異なり、非因果アテンションを採用しており、内部的にMasked Diffusionを使用する点が大きく異なります。

この仕組みによって予測トークン分を一斉に導出することが可能になり、その後の処理はアシスタントモデルと同様のロジックに従って承認（Accept）されたトークンを出力するような構成を取っています。

EAGLE3とは？

EAGLE3とは、EAGLE(Extrapolation Algorithm for Greater Language Model Efficiency)シリーズのバージョン3にあたるものであり、論文として以下のものが公開されています。

• EAGLE ( https://arxiv.org/pdf/2401.15077.pdf )
• EAGLE2 ( https://arxiv.org/pdf/2406.16858 )
• EAGLE3 ( https://arxiv.org/pdf/2503.01840 )

これら論文の第一著者である北京大学のYuhui Li氏を中心に、北京大学・マイクロソフトリサーチ、ウォータールー大学/ベクター研究所の共同研究チームによって開発が進められており、オープンソースコミュニティでは、SafeAILabという団体名で活動しています。

EAGLEモデルについても後継モデルの開発は行われており、SafeAILabからはEAGLE3.1が2026年5月に、AWS AI Labsのチームで研究・開発されているモデルとしてP-EAGLE(Parallel-Drafting EAGLE)が開発されており、こちらは2026年2月にリリースされているようです。

いずれも、従来未だ因果アテンションがボトルネックになっていたことを課題としてとらえており、その部分をいかに並列化するかに焦点を当て改良がおこなわれているようです。

脚注

1. https://arxiv.org/pdf/2606.19348

2. https://zhijianliu.com/, https://z-lab.ai/

3. https://arxiv.org/pdf/2602.06036

4. https://arxiv.org/pdf/2302.01318

5. https://huggingface.co/elyza/ELYZA-Diffusion-Instruct-1.0-Dream-7B