【2026 最新】DiffusionGemma 是什麼？看懂 256-token Canvas 與本機 A/B Test

你熟悉的自回歸 LLM（例如 Gemma 4）像打字機：先寫第一個 token，再根據前文寫下一個，一路由左往右。可是 Google 在 2026 年 6 月公開的 DiffusionGemma，做法更像一群編輯同時改同一張草稿紙——先鋪出一整塊雜訊，再反覆重寫不確定的位置，直到文字成形。

這篇專為第一次接觸 diffusion language model（擴散語言模型）的讀者寫。你會看懂 256-token Canvas 怎麼運作、官方速度數字真正代表什麼，以及怎麼在同一台機器上，把 DiffusionGemma 與自回歸 Gemma 4 做一組不作弊的 A/B Test。本文不把官方或社群數字冒充 AlphaLab 實測；你拿到的是可重跑的流程與判讀方法。

先說結論：DiffusionGemma 用速度換取什麼？

DiffusionGemma ＝先把 256 格草稿紙填滿隨機 token，再整頁反覆校稿；定稿一塊後，才接下一塊。

這個設計讓同一次模型前向運算可以處理多個位置，而不是每次只產生一個新 token。代價也很直接：第一段文字要等整塊草稿收斂，開頭可能比較慢；Google 自己的評測也顯示，它目前的整體品質仍落後自回歸 Gemma 4。最適合它的問題不是「TPS 最高就是不是最好」，而是：在你的硬體、提示與任務上，省下的等待時間，值不值得交換品質與穩定性？

DiffusionGemma 適合拿來做什麼？

• 本機互動：單人或低併發的程式助理、文字整理與批次改寫，重點是單一請求儘快完成。
• 需要整段回看的生成：模型可在一個 Canvas 內重新改寫前面尚未提交的位置，適合觀察「先有草稿、再收斂」的效果。
• 模型研究：想比較自回歸與擴散解碼，而不是只比較兩個品牌名稱。
• 工具工作流測試：同時量速度、JSON 格式與 tool call，而不是把 token/s 當成唯一成績。

如果你第一次設計模型評測，可以先讀 AI Evals 新手指南；如果你關心量化後的本機品質，再搭配 Unsloth Dynamic 3.0 實驗方法，會更容易分清楚「解碼架構」與「量化精度」兩種變因。

256-token Canvas 怎麼從雜訊變成文字？

① 先讀懂 Prompt：「題目仍是由左往右編碼」

DiffusionGemma 並不是把所有東西都丟進一團雜訊。它先用自回歸編碼器處理你的 Prompt，建立可重用的 KV cache（模型對前文的工作筆記），再開始生成新的 256-token 區塊。換句話說，題目先讀好，答題草稿才鋪開。

② 鋪滿 Canvas：「不是一排固定 [MASK]」

很多圖解會把擴散文字模型畫成一格格遮罩，但 DiffusionGemma 官方文件描述的起點是從整個詞彙表抽出的均勻隨機 token。所以你看到的心智圖應該是「亂碼草稿」，不是 256 個永遠相同的空白貼紙。

③ 反覆去噪：「不只補字，也能改字」

每一步，模型同時估計多個位置應該是什麼。信心較高的 token 逐漸留下；不確定的位置可以再次變亂、重新選字。官方建議的上限是每塊 48 步，adaptive stopping（自適應停止）通常會依任務在約 12～16 步收斂。停止條件同時要求 Canvas 平均 entropy 低於 0.005，且連續兩步的最高機率 token 預測完全相同；它不是保證每次都走固定步數。

④ 提交區塊：「定稿後才能接下一張」

一塊 256 token 收斂後，模型把它提交到 KV cache，再開下一塊 Canvas。這也解釋了兩個常見誤會：它不是一次平行寫完整篇文章；前一塊一旦提交，後一塊也不是無限制回頭重寫全文。

把這四步串起來，就是：讀 Prompt → 鋪 256 格雜訊 → 多輪去噪 → 提交區塊 → 下一塊。想把這種「機制假設」變成可量測實驗，可參考 Agent Skill 路由 A/B Test的單一變因原則。

官方 benchmark 告訴我們什麼？

先看速度。vLLM 的 DiffusionGemma recipe 在單張 H100、concurrency 1 的 SPEED-Bench 快照中，DiffusionGemma 的平均單請求生成速度為 1,282 token/s，自回歸 Gemma 4 為 205 token/s；但 TTFT（第一個 token 出現前的等待）則是 489 ms 對 53 ms。兩件事可以同時成立：開頭更慢，整段完成更快。

再看品質。Google 模型卡的同表比較中，DiffusionGemma 在 MMLU-Pro 為 77.6，自回歸 Gemma 4 為 82.6；LiveCodeBench v6 為 69.1 對 77.1；Tau2 平均為 56.2 對 68.2。這些是 Google 發布時的模型評測，不是所有真實任務的總結，但足以提醒你：平行產生更多 token，不等於每一個 token 都更好。

技術報告在單張 H100、FP8、PG-19（4,096 input／1,024 output）的測試中，自回歸模型約到 32 個 concurrent requests 才開始取得 throughput 優勢；作者也明言尚未針對 batch 大於 1 最佳化，真實服務流量仍待驗證。因此，家用工作站的單人互動結果，不應直接外推成高流量 API 的成本結論。

本機 A/B Test：先把兩邊鎖在同一條起跑線

以下把 Docker image 鎖定為 vLLM 0.24.0，並在同一張 Blackwell GPU 上依序執行。官方 recipe 對 DiffusionGemma／Gemma 4 NVFP4 分別列出 24GB／16GB 最低 VRAM，但這只是 recipe metadata，不等於 AlphaLab 已證明任一 24GB 顯卡都能在 8,192 context、max-num-seqs 4下穩定運作。這組基線以 32GB 的桌機版 RTX 5090 為較保守起點；若 24GB 顯卡發生 OOM，必須把兩邊一起降為 max-num-seqs 1，或一起縮短 context，並記錄變更。

為控制變因，兩邊都採 RedHatAI／LLM Compressor 的 DiffusionGemma與 Gemma 4 NVFP4 權重 checkpoint，且不強制 FP8 KV cache；兩個 checkpoint 的設定都是 BF16 model dtype，也沒有內嵌 KV quantization scheme，因此 vLLM 的 auto KV cache 維持 BF16。命令同時鎖定相同 image、V2 runner、context、sequence cap、GPU memory ratio、generation config 與 thinking mode。這是控制組設定，不是兩個官方 recipe 各自的極限調校；截至 2026 年 8 月 21 日，AlphaLab 尚未在對應 GPU 實機執行。

# A 組：DiffusionGemma；32GB Blackwell 控制基線，NVFP4 權重 + auto/BF16 KV
docker run --rm --gpus all --network host --ipc=host \
  -e VLLM_USE_V2_MODEL_RUNNER=1 \
  -v ~/.cache/huggingface:/root/.cache/huggingface \
  vllm/vllm-openai:v0.24.0@sha256:251eba5cc7c12fed0b75da22a9240e582b1c9e39f6fbc064f86781b963bd814f \
  --model RedHatAI/diffusiongemma-26B-A4B-it-NVFP4 \
  --revision c333706ed87619f80159b1f0c5685b71dfafeea8 \
  --max-model-len 8192 --max-num-seqs 4 \
  --gpu-memory-utilization 0.85 \
  --generation-config vllm \
  --hf-overrides '{"diffusion_sampler":"entropy_bound","diffusion_entropy_bound":0.1}' \
  --diffusion-config '{"canvas_length":256}' \
  --enable-auto-tool-choice --tool-call-parser gemma4 \
  --reasoning-parser gemma4 \
  --default-chat-template-kwargs '{"enable_thinking":true}' \
  --port 8000

# B 組：Gemma 4 自回歸基線；同機器、NVFP4 權重與 auto/BF16 KV
docker run --rm --gpus all --network host --ipc=host \
  -e VLLM_USE_V2_MODEL_RUNNER=1 \
  -v ~/.cache/huggingface:/root/.cache/huggingface \
  vllm/vllm-openai:v0.24.0@sha256:251eba5cc7c12fed0b75da22a9240e582b1c9e39f6fbc064f86781b963bd814f \
  --model RedHatAI/gemma-4-26B-A4B-it-NVFP4 \
  --revision 5557756b8dce33ac72f2bd702b11729fdba3b839 \
  --max-model-len 8192 --max-num-seqs 4 \
  --gpu-memory-utilization 0.85 \
  --generation-config vllm \
  --enable-auto-tool-choice --tool-call-parser gemma4 \
  --reasoning-parser gemma4 \
  --default-chat-template-kwargs '{"enable_thinking":true}' \
  --port 8000

兩個容器不要同時搶 GPU；先跑 A、記錄結果、停止，再跑 B。若不是 Blackwell，不要直接套用 NVFP4 指令；先依 GPU 架構、VRAM 與 recipe 明列的相容硬體選 checkpoint。Hopper 可考慮 recipe 列出的 FP8／BF16 路徑，其他 GPU 不可只因名稱有 BF16／FP8 就假設可跑。

四個固定條件

1. 固定 Prompt：至少 30 題，包含摘要、程式、JSON 與工具呼叫；A、B 順序隨機，避免只挑好看的案例。
2. 固定生成設定：同樣的 system prompt、thinking 模式、temperature、top-p、seed、最大輸出 token 與 tool schema；top-k 只在兩個 endpoint 都明確支援時才固定，並保存逐請求參數。相同數值只代表輸入控制一致，不代表 entropy-bound diffusion sampler 與自回歸 sampling 的內部機制相同。
3. 固定負載：先以 concurrency 1 比互動體感，再另跑 2 與 4；不要把不同併發混成一個 TPS。
4. 固定評分：速度由程式記錄；品質交給不知道模型名稱的評審，先寫 rubric 再看答案。

別只量 TPS：四個分數才看得出能不能用

1. 速度：TTFT、E2E、輸出長度一起看

記錄 TTFT、整體完成時間（E2E）、輸出 token 數與每請求生成速度。DiffusionGemma 可能回答更短；若只看「一秒吐幾個 token」，短答案和長答案會讓比較失真。先做三次暖機，再把至少 30 題各跑三輪，報中位數與 p95，不要只挑最快一次。

2. 品質：先定 rubric，再做盲評

摘要題可評關鍵點覆蓋、事實正確與冗贅；程式題可跑單元測試；開放題則把模型名稱遮住再評。若想了解排行榜為什麼不能直接代替你的任務，可讀 AI 模型排行榜怎麼看。

3. Structured output：用 parser 判定，不用肉眼

要求模型輸出固定 JSON schema，程式端依序檢查：能否解析、欄位是否齊全、型別是否正確、是否多出禁止欄位。技術報告只展示一個把 schema 寫進 Prompt 的 JSON extraction 案例在兩步收斂；單一案例不能推得你題庫的成功率，所以這一欄必須自己逐題計算。

還要分清楚「Prompt 要求 JSON」與 runtime 的 constrained decoding。截至 2026 年 8 月 21 日，vLLM 已用合併的 PR #45468讓 DiffusionGemma 的 guided JSON schema 請求明確回傳 HTTP 400，因為現有 grammar FSM 假設 token 由左往右推進。這個版本下應測 prompt-only JSON，再用外部 parser、schema validator、retry 或自回歸 fallback；不要把「能生成 JSON」寫成「server 保證 JSON 合法」。

4. Tool call：驗名稱、參數，也驗「該不該呼叫」

每題先寫 expected tool、必要參數與可接受值，再統計正確呼叫率、漏叫率、誤叫率。vLLM recipe 明確提醒 DiffusionGemma 的 function calling 在 thinking mode 表現較好；因此 A、B 都應開啟相同 thinking 設定。這裡的 parser／API 路徑不保證模型選對工具或參數合法，仍要外部驗證。這也呼應 AI Agent Harness的核心觀念：模型輸出只是零件，解析、驗證與重試才決定工作流能否落地。

怎麼選：DiffusionGemma 還是自回歸 Gemma 4？

選 DiffusionGemma，如果：

• 你的核心場景是單人或低併發，而且更在意整段回答完成時間。
• 你有支援相應精度的 GPU，也願意為 diffusion state buffer 保留記憶體。
• 你的 JSON、程式與 tool call 都有自動測試，能量出退步而不是憑感覺。
• 你想研究「先整塊草稿、再反覆修訂」這種不同的生成路線。

選自回歸 Gemma 4，如果：

• 你要更快看到第一個 token，串流開頭的體感比整段完成更重要。
• 你的任務把品質、長推理或工具可靠度放在速度之前。
• 你要服務較高併發，或現有部署已針對自回歸批次處理最佳化。
• 你的 GPU／runtime 不符合 DiffusionGemma recipe，且不想為一個實驗改基礎設施。

五個最容易讓 A/B Test 失真的坑

1. 把官方峰值當成自己速度：GPU、精度、runtime、Prompt 長度與併發不同，數字就不是同一場比賽。
2. 把遮罩當成真實起點：教學圖可以用空格表示未知，但 DiffusionGemma 的 uniform-state diffusion 從隨機 token 開始。
3. 只看平均值：互動服務至少要保留 p50、p95 與輸出長度；平均數會藏住慢尾端。
4. 兩邊設定不同：一邊 thinking、一邊 non-thinking，或沒有鎖定 image、runner、權重 revision 與 KV cache 精度，得到的就不只是解碼架構差異。
5. 先看答案再訂標準：看完喜歡哪個答案才寫 rubric，會把偏好包裝成評測。

DiffusionGemma 常見問題

1. DiffusionGemma 是圖片擴散模型嗎？

不是。它的輸出是文字，借用的是「從雜訊逐步去噪」的生成思想。模型可以接收文字、圖片與影片輸入，但本文討論的是 text output 的 block diffusion 解碼。

2. 256-token Canvas 等於每次一定輸出 256 token 嗎？

不一定。Canvas 是內部工作的固定區塊；模型仍可遇到結束 token，回答也可能短於 256 token。長回答則會提交一塊後再開下一塊。

3. 去噪一定要跑 48 步嗎？

不用。48 是官方建議上限；自適應停止會依不確定性提早結束，官方文件描述的常見範圍約為 12～16 步。

4. 它一定比自回歸模型快嗎？

不一定。低併發、較長輸出與合適 GPU 比較容易發揮平行生成；第一 token、短回答、高併發或不同 runtime 都可能改變結論。

5. 一張 RTX 5090 可以跑嗎？

桌機版可以。Google 發布文宣報告桌機版 GeForce RTX 5090（32GB）可跑且達 700+ token/s；這是 Google 的特定設定數字，不是 AlphaLab 重現，也不能外推到 24GB RTX 5090 Laptop GPU。vLLM recipe 的 24GB 是變體 metadata；本文這組 8,192 context、4 sequences、BF16 KV 控制基線仍以 32GB 為較保守起點。

6. 它支援 structured output 與 tool calling 嗎？

Prompt-only JSON 與 native function calling 有；guided structured output 則要分開看。截至 2026 年 8 月 21 日，vLLM 對 DiffusionGemma 的 response_format.json_schema／structured_outputs會明確回 HTTP 400。工具呼叫有 parser／API 路徑，但不保證選對工具或參數合法；兩者都要外部驗證。

7. 可以直接當 OpenAI 相容 server 嗎？

可以。本文鎖定的 vllm-openai:v0.24.0映像會提供 /v1/chat/completions；用 OpenAI SDK 把 base_url 指到 http://localhost:8000/v1即可呼叫。

8. 新手第一個實驗該跑什麼？

先跑 10 題摘要、10 題 JSON、10 題 tool call。固定 concurrency 1，記錄 TTFT、E2E、解析成功率與盲評分數；確認流程可靠後，再擴到更多題與併發。

五個重點帶走

1. DiffusionGemma 的核心不是「一次寫完整篇」，而是反覆修訂一個 256-token 區塊。
2. 起點是隨機 token 雜訊，不是單純排列 256 個固定遮罩。
3. 它可能第一 token 較慢、整段完成較快；TTFT 與 E2E 要分開量。
4. 官方評測顯示速度優勢伴隨品質差距，所以 JSON 與 tool call 也要計分。
5. 公平 A/B 的關鍵是同硬體、同 image／runner、同權重量化與 KV 精度、同題庫、同設定，再用盲評回答「值不值得換」。