一貫性拡散言語モデル：最大14倍の高速化、品質損失なし

概要

Diffusion Language Models (DLMs) は、従来の Autoregressive (AR) LMs に代わる新しい生成方式。 CDLM はDLMの効率化を実現し、 高速推論・低レイテンシ を達成。 並列生成 や ブロック単位のKVキャッシュ 活用が特徴。 精度維持しつつステップ数削減 を可能に。 数学・コーディングタスク で高いスループットと実用性を示す。

Diffusion Language Models (DLMs)の概要

DLMs は、部分的にマスクされたシーケンスを 複数回のサンプリングで段階的に復元 する言語モデル
1トークンずつ生成するAR方式と異なり、 複数トークンを同時に確定 できる並列生成手法
双方向コンテキスト の活用により、 テキストインフィリングやリファインメント など新しい能力を実現
推論の可視化 ：CDLM、従来DLM、ARモデルの挙動比較

DLMの課題とCDLMのアプローチ

標準DLMの非効率性
- KVキャッシュ非対応 ：全双方向アテンションにより、各ステップで全文脈を再計算する必要
- 高リファインメントステップ数 ：高品質生成には多くのステップが必要、ステップ削減は品質低下を招く
CDLMの解決策
- ブロック単位のKVキャッシュ を可能にし、推論コストを大幅削減
- 少ないステップでも高品質生成 を保つための後処理学習レシピ

DLM推論とCDLMの学習方法

DLM推論 ：完全マスク状態から始め、各ステップで部分的にトークンを確定
- 各ステップで 現在のノイズ付きシーケンス と プロンプト から クリーンなシーケンス分布 を予測
CDLM学習プロセス
1. トラジェクトリ収集
  - ドメイン固有プロンプトでDLM推論を実行し、 トークンごとのデコード履歴 ・ 隠れ状態 ・ 正解テキスト を記録
  - 例：生成長L_g=256、ブロックサイズB=32、全N=L_gステップ（各ステップで1トークン確定）
2. ブロック因果生徒モデルとアテンションマスク
  - トラジェクトリ抽出時は全双方向アテンション、CDLM学習時は ブロック単位因果マスク を適用
  - プロンプト、確定済みブロック、現在のブロックにのみアテンション
  - 正確なブロック単位KVキャッシュ を実現
3. 学習目的（損失関数）
  - 蒸留損失 ：新たにアンマスクされた位置で、教師DLMの分布に生徒を一致させる
  - 一貫性損失 ：同一ブロック内でマスク状態が続く位置に対し、途中状態とブロック完了状態の生徒予測を整合
  - 補助DLMマスク復元損失 ：ランダムにマスクした正解テキストで通常のマスク復元学習
4. 推論時の動作
  - ブロック単位のAR方式 でデコード、プロンプトと確定済みブロックのKVキャッシュを再利用
  - 各ブロック内で 信頼度閾値による並列確定 ・ 終了トークンで早期停止
  - 追加ハイパーパラメータ不要 な堅牢なデフォルト推論パイプライン

CDLM–Dreamの性能評価

大幅なステップ削減 ：CDLM–Dreamは、ベンチマークで約4.1倍～7.7倍のリファインメントステップ削減を達成
レイテンシ大幅短縮 ：GSM8K-CoTで最大11.2倍、MBPP-Instructで14.5倍のレイテンシ改善
高スループット ：多くのタスクで Tokens Per Second が最高値
品質維持 ：短縮したステップ数でも、パス率や精度がほぼ維持
ナイーブなステップ削減との比較
- 単純なステップ数削減は精度大幅低下
- CDLMは同等ステップ数でも精度維持し、キャッシュ活用でレイテンシ半減

システム・ハードウェア観点での分析

AI（Arithmetic Intensity）比較
- ARデコーディング ：小バッチでメモリボトルネック、バッチ増加でAI上昇
- 従来DLM ：全ステップで全シーケンス処理、計算負荷が高い
- CDLM（ブロックDLM） ：ARより高AI、従来DLMより低AIの中間領域
  - 小バッチ環境で効率的 な並列化とメモリアクセスのバランス

考察・結論

表現力と効率性の両立
- 全双方向アテンションは推論コスト高だが、CDLMは ブロック内双方向性 と KVキャッシュ を両立
- ローカルなリファインメント能力 （インフィリング等）を維持
スケーラビリティ
- CDLMは 任意のブロック拡散モデル に後付け可能
- より強力なDLM教師からのトラジェクトリ収集で今後の発展に期待
まとめ
- CDLMは、DLMの高速化・効率化を実現するトレーニング手法
- ブロック内一貫性の強制 と ブロック因果生徒の微調整 で、推論ステップ削減・精度維持・高スループットを達成
- 数学・コーディングタスク での実証的な有効性

参考文献

[1] Beyond Next-Token Prediction: A Performance Characterization of Diffusion versus Autoregressive Language Models
[2] Block Diffusion: Interpolating Between Autoregressive and Diffusion Language Models
[3] Fast-dLLM: Training-free Acceleration of Diffusion LLM by Enabling KV Cache and Parallel Decoding

Hackerたちの意見

Googleも似たような研究を進めてるみたいだね。なんでまだGPT40のスケール版を出さないんだろう？

└

おそらく高いからだろうね。でも、実際にスケールできる人たちから「これを空高くスケールしよう！」って実験がもっとあればいいのに。

実際に机の下のマシンで動かせるような拡散言語モデルって、誰かやってるのかな？もっと「伝統的な」.ggufオプション（まあ、クオンツ）は、驚くほど弱いハードウェアでも実用的だし、拡散が次のステップになるかもって希望を持たせるものも見かけるけど、今のところは早期の研究プロトタイプばかりだね。

└

拡散画像モデルを運用した経験から言うと、これがすぐに主流になるとは思えないな。パラレルデコーディングは、いいパラレルGPUやNPUがあれば素晴らしいけど、CPUだとめっちゃ遅いからね。

└

より専門的なタスク（クエリの書き換え）に取り組んでたんだけど、めちゃくちゃ速いよ。今は自動回帰デコーディング用に多くの推論コードが整備されてるけど、拡散はまだ成熟してない。Ollamaやllama cppがそれをサポートしてるかは分からないな。

└

拡散モデルは全然違う精製プロセスを持ってるから、今のソフトウェアはそれに対応してないんだよね。だから、自分のマシンでこのモデルを使う方法を探すのに苦労してる。誰かがやる前に、自分で何か作れるか試してみようかな…

もっとこういう研究があって、モデルをどんどん大きくするよりもスピードを上げる方向に進んでほしいな。

└

両方やればいいじゃん！スケーリングの法則は本物だよ！でも、処理速度が遅いことを意味するわけじゃないし。

└

主要なAI企業（オープンリリースしないところ）は、モデルのパラメータ数を教えなくなったのに気づいた？パラメータ数は、GPT-3まではプロプライエタリモデルの優秀さを測る指標だったけど、それ以降急に止まったよね。それに、収益を上げるプレッシャーが高まってるのに、推論価格がかなり下がってるのも面白い。Opus 4.6は$25/MTok、Opus 4.1は$75/MTok、Opus 4やOpus 3と同じ。OpenAIのo1は$60/MTok、o1 proは$600/MTok、gpt-5.2は$14/MTok、5.2-proは$168/MTok。あと、GPT-4が1.8Tの領域にいるって噂があったけど、今では1Tの中国モデルがそれに匹敵するか超えてるっていうのも注目だね。中国がその効率改善の独占を持ってるとは思えないし、フロンティアモデルがこの1.5年で実際に大きく成長したとは思えない。むしろ、昔のフロンティアモデルよりもパラメータ数が少ない可能性もあるよ。

└

同じことだよ。パラメータを量子化する？「大きい」モデルは速く動く。MOEベースモデルの蒸留？「大きい」モデルは小さいモデルとして動く。もしそれが言いたいことなら、パラメータ数を減らしても誰も得しないよ。実際のパフォーマンスを求めてるってより、トランスフォーマーモデルが嫌いなだけじゃない？

Taalasの16,000トークン毎秒の加速が、ほぼ同等のLlama 8Bモデルと同じ日にリリースされたのは痛いだろうね！拡散LMをどこまでスケールできるのか気になるな。ブラウザ内のモデルで遊んでみたけど、速度が辛いよ。 https://taalas.com/products/

└

これは全く関係ない話だよ。これは一般的な最適化で、TaalasのはSRAM上で小さな8Bモデルを動かすASICなんだ。でも、Taalasの製品がどうスケールするのか気になるね。一つの小さなモデルのためにカスタムチップを作るのは、何十億人のユーザーのためにトリリオンサイズのモデルを動かすのとは違うから。大体、8Bパラメータごとに53Bトランジスタが必要だよ。2Tパラメータモデルだと、スケールが線形だと仮定して13兆トランジスタが必要になる。1つのチップが2.5kWの電力を使う？それはH100 GPUの4倍だね。どうしてそんなに電力を消費するんだろう？フロンティアモデルが1.5兆モデルだと仮定すると、それを動かすにはN5ウェーハチップ全体が必要になる。しかも、モデルに何か変更が必要になったら、チップに物理的に印刷されてるから変更できないんだ。だから、何年も何も変えずにこのモデルを使うって分かってる時にやることだね。でも、エッジ推論には非常に興味深い技術だよ。ロボットや自動運転は、電力消費が大幅に減れば、遠い未来にこれを活用できるかも。ロボットの中で2.4kWのチップが動くのは現実的じゃないから、150Wのチップくらいが妥当かもね。

└

これ試してみたけど、マジでヤバい。天才的なLLMが2、3個いるよりも、高校卒業したLLMの軍団を使ってエージェントアプリを作りたいわ。これは全く新しいAIのパラダイムだね。

└

これヤバいね！

└

これめっちゃ速いね（ほぼ瞬時）。何か裏があるの？リターンキーを押す前に答えが出てたよ！

拡散モデルがプログラミングで制約デコーディングと一緒に使われないのはなんでだろう？自動回帰モデルを使うよりも、絶対にこっちの方が理にかなってると思うんだけど。

└

拡散モデルは、対称アーキテクチャの中で言語の因果関係を推測する必要があるんだよね（情報が前後に流れるから）。自動回帰モデルは情報が一方向にしか流れないから、制御がかなり簡単になる。英語の段落の中で、2文目が1文目の前に来ることはほとんどないし、そうじゃないと意味が通らないことが多い。たまに問題にならないこともあるけど（そういう場合は並列生成が有効だと思う）、エッジケースが全ての利益の源なんだよね。

ジェミニ拡散モデルの進捗が気になるな。去年の5月にプレビューがあって、すごく速かったけど、それ以降何も聞いてないんだよね。

このポストトレーニングのレシピは、DINOトレーニング（教師/生徒、ストップグラディエントの使用）を思い出させる部分が多いな。最近のleJEPA SigREG正則化の研究が、シンプルなポストトレーニングに関連してるかもしれないな。

AR LLMの出力トークンの半分が事前定義されたjsonスキーマを生成するために使われるのがすごく気になる。インフィリングに拡散を使えるオプションがあったらいいな。

└

これに関して学んだトリックの一つは、LLMのI/Iにcsvを使って、境界層でjson csvを翻訳することだった。

拡散モデルの論文はいつも面白いけど、トークンを挿入したり削除したりするメカニズムが必要だと思う。この記事の図の例では、「British munchkin cats _ _ and ...」って固定されちゃうと、「British munchkin cats are a new and controversial breed.」には行けないんだよね。「cats」と「and」の間に正しいトークン数がないから。コーディングの文脈では、モデルがその位置で全くあり得る括弧やカンマをサンプリングすると、文法的に正しい拡張ができなくなっちゃう。

└

確か、いくつかの研究者がこの種のことのために混合AR+拡散モデルに取り組んでるはず。

└

出力の初期ドラフトがあるのが、このタイプのモデルの魅力の一部だと思う。

└

でも、「インフィリング」問題はAR LLMにとっては解決されてるわけじゃないから、ちょっと変な批判だよね。それに、AR LLMの論理を拡散モデルに当てはめてるし。AR LLMは次のトークンの確率を求めてるだけ（条件付き確率の連鎖）だけど、拡散LLMは出力全体の確率を一度にモデル化してるからね。だから、適切にトレーニングされてれば、無効な出力につながるトークン構造は極めて低い確率になるはずだよ。

└

このブログ記事では、あなたが言ってる問題を解決するブロック拡散について触れてるよ。

└

まあ、そうだけど、この点に関しては左から右への生成の方が全然マシだよね。「British cats」って言ったら、「British munchkin cats」には行けないし、左側のトークンはもう決まっちゃってるから。それが一種の特徴でもあるし。拡散は画像に使われるんだよね？だから、キッチンカウンターのすぐ隣にドアの画像が形成され始めたら、そこに冷蔵庫を挿入することはできないって言ってるようなもんだよ。まあ、もしかしたらそのレイアウトはもう決まってるから「したくない」だけかもしれないけど。

ハクソク