DiffusionGemma登場、1秒1500トークンの高速生成

DiffusionGemma Technical Report

▲ 158gmays40 HNでの議論
DiffusionGemma登場、1秒1500トークンの高速生成

GoogleのDiffusionGemmaチームは、拡散モデルを用いた実験的なオープンウェイト言語モデル「DiffusionGemma」の技術報告書を公開した。従来の自己回帰モデルが1トークンずつ生成するのに対し、DiffusionGemmaは256トークンのブロックを並列に洗練することで、単一のNVIDIA H100 GPU上で毎秒約1500トークンを生成する。これは最先端の投機的復号を用いた自己回帰モデルよりも大幅に高速だ。モデルはGemma 4のMixture-of-Experts版（アクティブパラメータ38億、総パラメータ252億）を基に、総トレーニングトークン予算の10%未満でファインチューニングされた。思考モード、マルチモーダル入力、長いコンテキストにも対応し、自己回帰生成も可能だという。

「DiffusionGemmaは、生成速度とモデル能力のトレードオフにおいて新たなパレート最前線を確立する」
原文を読む →HNでの議論RSS

HNでの議論

40
  1. kamranjon

    共有したいと思って投稿しました。Diffusion Gemmaがどう動くかを理解するのに本当に役立つリソースを見つけました: https://newsletter.maartengrootendorst.com/p/a-visual-guide-...

    私にとって本当に興味深かったのは、このモデルをゼロから訓練する必要がなく、既存のMOEチェックポイントをそのまま使ったことです:

    「デコーダーのみのモデル（Gemma 4 26B A4B）をデノイザーに変換するには、トークン生成時に直接使われないもの、つまり全トークンのロジットを利用することができます！」

    このリリースに期待を抱かせるのは、同じ変換が他のオープンモデルにも適用できる可能性があり、既存のローカルモデルの拡散バージョンがたくさん登場するかもしれないということです。これはわくわくする話です！

  2. mmastrac

    ここ数ヶ月かけて、これをmacOS用に再実装しました: https://github.com/mmastrac/diffgemma

    このモデルはとても気に入っていて、推論もかなり得意です。また、自分のニーズに合わせて柔軟に調整することもできます。メモリ帯域幅よりも計算能力が高いマシンを想定して設計されていますが、Metal上では非常に良い性能を発揮すると思います。

    M3クラスのマシンで約15トークン/秒まで出せていますが、M5では私がアクセスできないハードウェアによる性能向上がきっとあるはずです。

    他のGemmaのMTPヘッドを使ってMTPを実装しようとしましたが、性能を向上させることはできませんでした。ドラフトモデルから拡散キャンバスに事前シードする方法について、興味深い研究の余地があります。適切なドラフターを使えばDiffusionGemmaは私のマシンで20〜30トークン/秒に達しますが、これまでの速度を超えるように2つを組み合わせることはできていません。

  3. mike_hearn

    これらのモデルがコーディングに優れるようになれば、言語、コンパイラ、テストスイートランナーの仕組みを根本から見直す必要が出てくるでしょう。「AIがすべてを変える」というのは今や決まり文句ですが、実際にその通りだと思います。

    モデルが1500トークン/秒で推論しコードを書けるなら、プロンプトがアクティブな間は完全にCPU時間がボトルネックになるはずです。そうでなければ、競合他社に対して実時間で遅れを取ることになります。しかし、私たちの開発スタック全体は、プログラマーがCPUを待つのではなく、考えること、話すこと、コードを書くことにほとんどの時間を費やすという考えに基づいています（CIクラスターの溶融は痛い例外ですが）。

    私が想像しているのは、コンパイルとインタープリタでの実行を重ね合わせることができるハイブリッドモードのようなもので、LLMが変更を提案し、他のモジュールに影響する型エラーが並行して見つかる間に、即座にユニットテストを実行し始めるというものです。そしてテストは常にシャーディングされ、ローカル開発でもリモートクラスターで実行されるでしょう。

    明らかに、このアプローチはある程度JVMを人気にした理由です。Javaはコンパイルが非常に速いのは、javacが型チェック以上のことをほとんどせず、型システムが単純だからです。その後、JVMが実行と並行してコンパイルの重い処理を行います。そのため、Javaは起動時間が遅いという評判がありますが、JVMのターンアラウンド時間はC++やSwift、Rustなどと比べて本当に優れていることがあります。また、起動時間の痛みの多くは、古いSpringのような貧弱なフレームワークによるものです。

  4. RandyOrion

    メモリ制約のある自己回帰デコードとは対照的に、拡散デコードは計算制約にすることができます。かなりの計算能力を持ちながらメモリが非常に小さいデバイス、例えばNVIDIAのコンシューマー向けGPUなどは、拡散デコードから大きな恩恵を受ける可能性があります。

    性能面では、拡散デコードは自己回帰デコードよりも大幅に劣るべきではないと思います。https://arxiv.org/html/2604.11035 を参照してください。

    ローカルLLMユーザーとして、まともな性能を持つ小さな拡散LLM/VLMがもっと登場するのを本当に望んでいます。

  5. anentropic

    魅力的な結果ですね...ARモデルに対する精度の差を縮める余地はあると思いますか？あるいは「双方向推論と自己修正」を活用して全体的な優位性を築くことはできるでしょうか？

この日のほかの記事

2026-08-20