LLM、DiffusionGemma を RTX 5090 で動かしてみた
拡散モデルでテキストを「描く」
Google が出した DiffusionGemma を手元の RTX 5090 で実際に動かして数日触ってみた。結論から言うと「速さは本物、でも用途を間違えると崩壊する、クセの強い面白いやつ」だった。実測した数字と、触ってわかった向き不向きを正直に書いておく。
そもそも何が違うのか
ふつうの LLM（自己回帰モデル）は、文章を左から右へ1トークンずつ順番に生成する。「次の単語」「その次の単語」と一個ずつ確定させていくので、どうしても逐次処理のボトルネックがある。
DiffusionGemma は画像生成の拡散モデルと同じ発想で、256トークンの「キャンバス」を一気に並列で生成し、ノイズだらけの状態から数十回のパスで全体を同時に磨き上げて文章にする。左右どちらも見ながら（双方向アテンション）一括で書くので、原理的にめちゃくちゃ速い。
モデル自体は26B（総パラメータ）のうち実際に動くのは3.8BだけのMoE構成。重みは量子化版で17GBくらいなので、5090（32GB）には余裕で乗る。
速さは誇張じゃなかった
Google は「RTX 5090 で 700+ トークン/秒」と謳っていた。半信半疑だったが、実測したら本当に出た。
僕の環境（RTX 5090・量子化版）でのリクエスト単体の生成速度はこんな感じ：
コード生成: 約 730 トークン/秒
英語の長文エッセイ: 約 690 トークン/秒
日本語の長文: 約 540 トークン/秒
短い返答: 100〜370 トークン/秒（短いと逆に不利、後述）
比較対象として、同じ5090で動かしている Gemma 4 12B（投機デコード入りでチューン済み）が 160 トークン/秒くらい。つまり 3.5〜4.5倍速い。2000字くらいの日本語解説が5〜7秒で出てくるのは、正直ちょっと感動する。
ちなみに、サーバーのログに出てくる「Committed token throughput: 17 t/s」みたいな数字に最初だまされた。あれは30秒の集計ウィンドウの平均で、リクエストの待ち時間も込みの値。実際の生成バーストは桁違いに速いので、体感速度を知りたければリクエスト単体の wall time を測るのが正しい。
ハマったところ
すんなりは動かなかった。WSL2 環境だと、vLLM が「WSLではピンメモリが使えない」という古い前提でハードコードしていて、それが新しい実行ランナーの要求と衝突して起動時にクラッシュした。実際には今の WSL2 + 新しいドライバならピンメモリは普通に動くので、その判定を握りつぶすパッチを当てて回避。
あとVRAM。最初メモリ使用率を高めに設定したら、ウォームアップ中に「device not ready」で落ちた。使用率を少し下げて、同時リクエスト数を絞ったら安定した。vLLM は設定した上限までKVキャッシュを先に「予約」する仕様なので、メモリがカツカツに見えても実は予約しているだけ、というのも理解しておくと混乱しない。コンテキスト長を伸ばしても予約の割り方が変わるだけでVRAMは増えなかった。
致命的なクセ：マルチターン創作は崩壊する
ここが一番大事な発見。
試しに「AIを使ったトリックで完全犯罪を行う知能犯のミステリー小説を書いて」と投げて、出力のたびに「続けて」と繋いでいったら、4ターン目あたりから文章が壊れ始めた。
具体的には、まず読点が増殖し始める。「資産を、君の、口座へ、移動させる、ことに、」みたいに、全部の文節がブツ切りになる。5ターン目には前に書いた段落をほぼ丸ごと再放出するループに入り、6ターン目には「に、に、に、に、……」が延々と続いて完全に崩壊した。
これは設定で直る問題じゃない。拡散モデルはキャンバス全体を双方向で同時に磨くので、コンテキストに自分が吐いた変なトークンが溜まると、それを「正しいパターン」として参照してしまって、エラーが複利で増幅する。自己回帰モデルみたいに1トークンずつ軌道修正する仕組みがないから、自分の出力を食い続けるマルチターン創作はこのモデルの最悪ケースなのだ。
1ターン目のミステリーは普通に読める品質だっただけに、継続で崩れていくのは見ていて切なかった。
品質はそもそも Gemma 4 未満
Google 自身が「品質は標準の Gemma 4 より低い」と明言している通り、単発の出力でも細かいトークン化けが散発する。
「パラダイムシフト」が「ダイダイシフト」になる
光速を聞いたら「約29万9792万458メートル」と返ってきた（正しくは約2億9979万2458メートル。桁がぐちゃぐちゃ）
「離みません」「されます」みたいな微妙な誤字
論理構成や文章の骨格はちゃんとしているのに、固有名詞や数値がポロッと壊れる。なので事実の正確さが要る文章には絶対使えない。
長く書かせるコツ
拡散モデルは「この文章はもう完結した」と判断するとすぐ終わってしまう。なので普通に「長く書いて」と頼んでもわりとあっさり終わる。
プロンプトを変えて実測したら、はっきり差が出た：
素朴に「詳しく書いて」: 約1700字
「8000字以上で」と字数指定: 約3600字
章立てを8章分指定して「全部書き切れ」: 約5300字
「重要な出来事を50個、必ず全部」と列挙を強制: 約5600字
「結論やまとめを書かず、途中で終わってよい、とにかく分量を最大化して」: 上限の8600字まで到達
ダントツで効いたのが最後の「結論を書くな」パターン。完結させようとする力をプロンプトで抑えると、上限までずっと書き続ける。「未完了のリスト」を作らせるのも終わりにくくて有効だった。
結局どう使うのが正解か
数日触ってたどり着いた使い分けはこう：
向いてる（速度全振りで使える）
単発の要約・下書き・ブレスト
構造化された一発出力（リスト、解説、章立て記事）
とにかく量を速く出したいドラフト作業
向いてない（おとなしく従来モデルを使う）
マルチターンの創作・長編の継続執筆 → 崩壊する
数値や固有名詞の正確さが要る文書 → 化ける
高品質が要求される清書
要するに「速い代わりに雑」なので、人間が後で直す前提の高速ドラフトマシンとして割り切ると最高に便利。一発で投げて一発で受け取る、を繰り返す使い方がハマる。
まとめ
DiffusionGemma は、テキスト生成における拡散モデルという新しいアプローチが、コンシューマGPU1枚で実用速度に達したことを見せてくれる面白い実験モデルだった。700トークン/秒は伊達じゃない。
ただ「拡散だから速い」の裏側には「拡散だから自己修正できない」という構造的な弱点があって、それがマルチターン創作の崩壊という形でくっきり出た。速さと引き換えに何を失っているのかが、触ってみてはっきり腑に落ちた。
新しいパラダイムのモデルは、ベンチマークの数字だけ見ても本質はわからない。実際に動かして、壊れ方まで含めて観察すると、そのモデルが何者なのかが見えてくる。今回はそれを強く実感した数日だった。
速度が正義の場面では、間違いなく強力な選択肢になる。