DiffusionGemma：Google 把擴散模型帶進文字生成

Google DeepMind 發布了 DiffusionGemma，這是 Gemma 系列裡一個很有實驗味道的新分支。它不是繼續沿著傳統自回歸大模型「一次預測一個 token」的路線往前推，而是把擴散模型的思路引入文字生成：先生成一塊帶雜訊的文字畫布，再透過多輪去噪把整段內容逐步收斂出來。

官方給它的定位很明確：這是一個實驗性開放模型，適合研究和開發者探索低延遲、本地互動式文字生成工作流，不是用來全面替代標準 Gemma 4 的生產品質模型。

先看關鍵資訊

項目	DiffusionGemma
發布時間	2026-06-10
模型性質	實驗性開放模型
基礎	Gemma 4 backbone + Gemini Diffusion research
架構	26B total Mixture of Experts，推理時啟用 3.8B 參數
生成方式	文字擴散，按 256-token canvas 並行去噪
授權	Apache 2.0
速度目標	在專用 GPU 上最高約 4x 文字生成速度提升
典型硬體	量化後可在高階消費級獨立 GPU 的 18GB VRAM 範圍內部署
取得方式	Hugging Face、Kaggle、Google Cloud Model Garden

這裡最值得注意的是兩點：第一，它不是小模型，而是一個 26B MoE；第二，它推理時只啟用 3.8B 參數，並且把生成瓶頸盡量從記憶體頻寬轉向算力。

它和普通 LLM 最大區別是什麼

傳統自回歸 LLM 像打字機：從左到右，一個 token 接一個 token 地生成。這個方式穩定、成熟，也適合高品質長文字輸出，但本地單使用者推理時會遇到一個現實問題：GPU 很多時候沒有被充分餵飽，瓶頸常常在反覆讀取權重和逐 token 解碼。

DiffusionGemma 換了另一個思路。它先建立一個 256 token 的隨機占位畫布，然後多輪並行 refinement。每一輪裡，畫布上的 token 可以互相看見，模型不是只看前文，而是能在一個區塊內做雙向注意力。

這帶來三個直接結果：

生成不是嚴格從左到右，而是整塊文字一起收斂。
模型可以在生成過程中修正前面位置的錯誤。
對程式碼填空、行內編輯、格式閉合、數獨這類非線性約束任務更自然。

換句話說，DiffusionGemma 不是在追求「同樣路線上的更大模型」，而是在測試另一種文字生成路徑：把文字當成一塊可以反覆打磨的畫布。

為什麼它可能更快

官方反覆強調的關鍵點是：DiffusionGemma 試圖把瓶頸從 memory bandwidth 轉向 compute。

自回歸模型每生成一個 token 都要反覆存取模型權重。對於單使用者、本地推理、低 batch 的場景，GPU 算力不一定能被充分利用。DiffusionGemma 一次處理 256 token canvas，給 GPU 更大塊的並行工作，讓 tensor cores 更容易跑起來。

官方給出的資料是：

單張 NVIDIA H100 上可超過 1000 tokens/s。
NVIDIA GeForce RTX 5090 上可超過 700 tokens/s。
在專用 GPU 上文字生成速度最高約 4x。

不過這個速度結論有邊界。官方也提醒，DiffusionGemma 的加速優勢主要適合本地、低併發、單加速卡、低到中等 batch 的推理場景。如果是高 QPS 雲端服務，自回歸模型可以透過大批量請求把算力吃滿，DiffusionGemma 的並行解碼優勢會變小，甚至可能帶來更高服務成本。

這點很重要：它更像是給「本地即時互動」開的新路線，而不是所有部署場景的通用加速器。

架構上怎麼工作

開發者文件裡給了更具體的解釋。DiffusionGemma 的生成過程可以分成兩種階段：

Prefill / Incremental Prefill

使用 causal attention 讀取 prompt，並把上下文寫入 KV cache。對於長文字，模型會在每個 256-token block 完成後，把結果提交進 KV cache，再處理下一塊。
Denoising

使用 bidirectional attention 對目前 canvas 做迭代去噪。目前區塊裡的 query token 可以看見畫布上的其他 token，也可以利用已經寫入 KV cache 的歷史上下文。

這種設計被稱為 block autoregressive denoising。它不是完全放棄順序性，而是在長文字上保留區塊與區塊之間的順序穩定性，同時讓每個區塊內部並行生成。

這個折中很合理：如果完全並行，長文字一致性會很難；如果完全自回歸，又回到逐 token 瓶頸。DiffusionGemma 選擇的是「區塊間順序、區塊內擴散」。

適合哪些場景

DiffusionGemma 最適合的不是普通聊天，而是那些需要低延遲、快速改寫、局部補全、全域約束的互動場景。

比較典型的方向包括：

行內編輯：使用者改一句話，模型快速補出局部替換。
程式碼 infilling：不是從檔案開頭一直寫到結尾，而是在中間填缺口。
Markdown / JSON / XML 這類格式閉合：模型能同時看整塊輸出，更容易修正括號、標籤、列表結構。
非線性文字結構：例如圖、表格、數獨、胺基酸序列、數學圖結構等。
本地即時工具：需要「打字時就更新」的開發者工具、編輯器外掛、桌面 AI 助手。

官方開發者指南還給了一個數獨 fine-tuning 範例。基礎模型本身並不是專門訓練來解數獨的，成功率接近 0%；但用簡單的 JAX SFT recipe 微調後，數獨任務正確率提升到 80%，同時推理步數下降。這個例子想說明的不是「它適合解數獨」，而是雙向去噪更適合處理強約束、多變數、需要全域一致性的任務。

不適合哪些場景

DiffusionGemma 仍然是實驗模型，不能只看速度。

官方說得很直白：因為它優先考慮速度和並行布局生成，整體輸出品質低於標準 Gemma 4。對於要求最高品質的應用，仍建議部署標準 Gemma 4。

它也不一定適合這些場景：

高品質長文寫作。
高併發雲端 API 服務。
對輸出穩定性和事實準確性要求極高的生產任務。
主要依賴 Apple Silicon 統一記憶體架構的本地推理。

最後一點也來自官方說明：DiffusionGemma 的加速依賴加速器的高 arithmetic intensity。Apple Silicon 這類統一記憶體架構在推理中常常更受顯存/記憶體頻寬約束，可能看不到相對自回歸模型的同等加速。

部署和工具鏈

DiffusionGemma 已經可以從 Hugging Face 取得權重，也可以透過 Kaggle 和 Google Cloud Model Garden 存取。官方開發者指南裡給出了 vLLM 的本地 OpenAI-compatible server 範例：

1
2
3
4
5
6
7
8
9


vllm serve google/diffusiongemma-26B-A4B-it \
  --max-model-len 262144 \
  --max-num-seqs 4 \
  --gpu-memory-utilization 0.85 \
  --attention-backend TRITON_ATTN \
  --generation-config vllm \
  --hf-overrides '{"diffusion_sampler": "entropy_bound", "diffusion_entropy_bound": 0.1}' \
  --diffusion-config '{"canvas_length": 256}' \
  --enable-chunked-prefill

官方提到的生態還包括：

vLLM
Hugging Face Transformers
SGLang
MLX
Hackable Diffusion
Unsloth
NVIDIA NeMo
NVIDIA NIM

另外，官方表示 llama.cpp 支援即將到來。對於本地模型玩家來說，這個訊號很關鍵，但在真正支援落地前，仍要以實際可執行工具鏈為準。

和 Gemma 4 的關係

DiffusionGemma 不是 Gemma 4 的替代品，更像是 Gemma 4 家族上的一條實驗分支。

可以這樣理解：

標準 Gemma 4：更適合品質優先的生產輸出。
DiffusionGemma：更適合速度優先、低延遲、本地互動、非線性生成的探索。

它建立在 Gemma 4 backbone 和 Gemini Diffusion 研究之上，但目標不是單純提高 benchmark，而是驗證文字擴散能否改變開發者工作流。尤其是那些過去被自回歸生成方式卡住的互動形態，例如即時編輯器、程式碼中間補全、結構化內容即時修正。

值得關注的原因

DiffusionGemma 值得關注，不是因為它立刻成為「最強文字模型」，而是因為它把文字生成的底層假設往旁邊挪了一步。

過去幾年，文字模型幾乎預設走自回歸路線。這個路線很成熟，但它也天然把輸出變成線性過程：先寫前面，再寫後面，早寫錯的內容很難回頭改。擴散式文字生成提供了另一種可能：先搭出一個整體，再反覆修正局部，讓整塊內容一起變清楚。

這對開發者工具尤其有想像空間。真實編輯不是從空白文件開始一路往下寫，而是插入、刪除、補全、改格式、修局部、補中間。DiffusionGemma 的結構更貼近這種「局部編輯 + 全域約束」的場景。

小結

DiffusionGemma 是一個實驗性開放模型，核心看點是用文字擴散和區塊內並行去噪替代傳統逐 token 生成。它在專用 GPU、本地低併發、即時互動場景下可能帶來明顯速度優勢，也更適合行內編輯、程式碼補全、結構化文字和多變數約束任務。

但它不是 Gemma 4 的生產品質替代品。現階段更適合研究、工具原型和開發者實驗。真正選型時，可以把它放在「低延遲互動模型」這一欄，而不是「通用最強大模型」這一欄。

參考資料：