賢いAIは、なぜ
一語ずつしか書けないのか。
これまでの言語モデルは、文章を左から一語ずつ順番に紡いでいました。その「順番待ち」をやめ、文章をまとめて整えるのが DiffusionGemma。手元のPCで、生成速度が最大4倍に——その仕組みを図解で解きほぐします。
速さを縛っていたのは
「順番待ち」だった
GPT も Claude も Gemma も、これまでの大規模言語モデル（LLM）はすべて 自己回帰（Autoregressive）という方式で文章を作ってきました。直前までに書いた語を見て、次の一語を予測する——その繰り返しです。100語の回答なら、原理的に 100回の順番待ちが発生します。
ここが見落とされがちな弱点でした。GPU をどれだけ速くしても、「次の語は前の語が決まらないと出せない」という逐次性そのものは飛ばせません。とりわけクラウドではなく手元のPCで動かすとき、この一語ずつの待ち時間が、体感速度を決める一番の重しになっていたのです。
| 自己回帰（従来） | 拡散（DiffusionGemma） |
|---|---|
| 左から一語ずつ順に生成 | 枠全体をまとめて並列に整える |
| 出力語数の分だけ前進が必要 | 数ステップで複数の語を同時確定 |
| 長い回答ほど待ち時間が伸びる | ローカル生成で最大 4 倍の高速化 |
| 逐次のため並列化しにくい | 1ステップで最大256トークンを並列に |
文章を、左から書くのではなく、
霧の中から一度に浮かび上がらせる。
拡散は、こう書く
画像生成の「拡散モデル」と同じ発想です。まず全体をノイズで埋め、それを少しずつ整えて文章を立ち上げます。
ノイズで埋める
まず出力する場所を、意味のない「ノイズ」のトークンで一面に埋めます。自己回帰のように左端から書き始めるのではなく、回答全体の“下書きの枠”を最初に確保するイメージです。
まとめて整える（デノイズ）
各ステップで枠の全体を見渡し、ノイズを正しい語へと少しずつ置き換えます。このとき一語ずつではなく、複数の語を一度に確定できるのが自己回帰との決定的な違いです。
数回で立ち上がる
整える操作を数ステップ繰り返すと、霧が晴れるように文章が現れます。出力語数が増えても繰り返しの回数は大きく変わらないため、長い回答ほど速さの恩恵が効いてきます。
なぜ、手元のPCで
4倍も速くなるのか
速さの正体は二つ。「動かす脳を絞る」MoE と、「まとめて出す」拡散ヘッドの組み合わせです。
カギは MoE（Mixture of Experts／専門家混合）です。26B という大きな本体を持ちながら、一度の処理で実際に動かすのは 3.8B 分だけ。質問に応じて必要な“専門家”だけを起こすので、消費電力も計算量も抑えられます。だからこそ、データセンターではなく手元のGPUでも現実的に動きます。
そこに 拡散ヘッドが乗ります。自己回帰が「N語を出すのにN回前進」だったのに対し、拡散は1ステップで最大256トークン分をまとめてデノイズします。つまり繰り返しの回数を、出力の長さから切り離せる。これが、長文ほど効く高速化の理屈です。
手元で、すぐ試せる
Apache 2.0 のオープンウェイトとして公開され、主要ツールに初日から対応しています。
ローカルGPUで動かす
RTX を積んだPCなら、API課金もトークン上限も気にせず生成できます。NVIDIA が RTX / DGX Spark 向けに最適化済みです。
既存パイプラインに差す
Hugging Face Transformers・vLLM・Unsloth に day-zero 対応。いま動いている構成にそのまま組み込めます。
エッジ・オンプレ推論
クラウドに送れない社内データも、手元で完結。通信遅延のないエッジ推論との相性も良好です。
これは、転換点になる
テキスト生成に拡散を使う試みは、これまで Mercury（Inception）のような専門スタートアップの実験段階にとどまっていました。今回 大手フロンティアラボが、汎用LLM規模で初めてテキスト拡散アーキテクチャを実装・公開したことが、業界的なターニングポイントです。「速さは品質とのトレードオフ」という前提そのものが、揺らぎ始めています。
もちろん、最先端モデルの品質に全面的に並ぶわけではありません。速さと品質をどう使い分けるか——その選択肢が増えた、と捉えるのが現実的です。クラウドAPIで十分な人には誤差でも、ローカル環境派・エッジ推論を見据える人にとっては、確かな一手になります。