DiffusionGemma 把文字生成從逐 Token 改成整段去噪，Google 想把開源模型速度戰從雲端拉回本地 GPU

Google 這次丟出的不是又一個小幅升級版 大型語言模型，而是直接去碰生成流程本身。DiffusionGemma 不再像一般模型那樣逐個 token 往右吐字，而是先鋪出一整塊 256 token 的畫布，再反覆去噪，把一段文字一起收斂出來。對開發者來說，這條路若真的成立，意義不只是「更快」而已，而是本地執行、互動式編輯、程式補全與代理工作流的延遲預期都可能被重寫。

更重要的是，Google 沒有把這件事只留在研究論文或閉門預覽。DiffusionGemma 已經同步上架 Hugging Face、Kaggle、Model Garden，也給出 vLLM、Transformers、SGLang、MLX 與 NVIDIA NIM 的部署路徑。這等於把去年只在 Gemini Diffusion 預覽裡露過臉的想法，正式送進公開模型市場，直接接受工程可用性的檢驗。和先前偏重筆電端部署與 多模態 實用性的 Gemma 4 12B 把原生音訊、多模態與 16GB 本地部署綁在一起，Google 想把代理式 AI 往筆電下沉 相比，DiffusionGemma 的核心主張已經從「能不能放得下」進一步變成「能不能快到改變用法」。

這次發表最關鍵的地方，在於 Google 對瓶頸的判斷。傳統自回歸模型的延遲問題，很多時候不是模型不夠大，而是 GPU 每生成一個 token 都得反覆把權重從記憶體搬進來，整個流程非常吃 memory bandwidth。DiffusionGemma 的設計則是故意把工作量改成大塊平行計算，讓 GPU 的 tensor cores 可以吃到更滿的負載。官方說法是，它把 bottleneck 從記憶體頻寬轉回純算力，因此同一張卡上才能出現 4x 到 5x 的速度提升；Hugging Face 模型卡給出的條件也很直接，低 batch 情境下可超過每秒 1,100 token，這已經不是微調級別的優化，而是整個解碼節奏換了一種打法。

DiffusionGemma 的工程選擇也很值得看。它延續 Gemma 4 的 26B A4B Mixture-of-Experts 底座，但實際推論只啟用 3.8B 參數，總層數 30 層，採用 8 個 active experts、128 個 total experts 加 1 個 shared expert 的稀疏配置。真正的變化在 decoder：模型先用因果式 encoder 吃進 prompt 並建立 cache，再讓 decoder 以雙向注意力一次看完整個 canvas，反覆去噪與修正。這帶來兩個直接好處。第一，它不像自回歸模型那樣一旦先吐錯就只能硬著頭皮往下接，而是可以在後續步驟裡把低信心位置重新噪化再改掉；第二，因為同一塊文字能彼此互看，像 code infilling、格式補全、表格閉合、行內編修這種「前後文要一起算」的任務，理論上會比單向生成更自然。

Google 甚至特別拿 Sudoku 當示範，不是因為數獨多有商業價值，而是因為它剛好暴露這類模型與傳統自回歸架構的差異。自回歸模型從左到右生成時，很難在早期位置同時滿足後面格子的限制；DiffusionGemma 則可以讓整個盤面在每次去噪時互相傳遞資訊，必要時再把不穩定的位置洗回去重算。官方展示裡，經過簡單 SFT 後的版本可以把數獨成功率拉到 80%，而且從 48 步提早在 12 步停止。這不代表它突然變成最佳解題模型，但至少說明這套架構真正想搶的不是聊天花樣，而是對「全局一致性」比較敏感的生成任務。

如果只看 benchmark，DiffusionGemma 也不是一個只剩速度沒有能力的特例。模型卡列出的指標裡，MMLU Pro 為 77.6%、AIME 2026 無工具為 69.1%、LiveCodeBench v6 為 69.1%、GPQA Diamond 為 73.2%，長上下文的 MRCR v2 128k 測試平均則為 32.0%。這些數字還談不上重寫前沿能力排行榜，但已經足以說明它不是把品質大幅換掉才換來速度。Google 這次真正想推的論點更像是：在公開模型戰場裡，夠強的能力如果能配上極低延遲，很多工作流會寧可接受「不是最頂分」但「回應快得多」的模型，尤其是互動編輯、提示詞 反覆試跑、代理工具呼叫與本地 API 服務這些場景。

開發者社群對這件事有一個很實際的外部檢查。Simon Willison 在 NVIDIA 提供的免費 NIM 端點上跑了這個模型，4.4 秒回傳 2,409 token，換算下來也接近每秒 500 token。這當然不是官方宣稱的理想峰值，但它至少說明「幾百 token/s」不是只存在於投影片。再加上 NVIDIA 自己也立刻跟進，把 DiffusionGemma 包裝成從 RTX 4090、5090 到企業級 Hopper、Blackwell 都能吃的本地與雲端方案，這代表硬體與推論框架供應鏈願意一起推，不把它只當成 Google 自家的研究秀場。

這也讓它和一般開源模型競爭時的判準出現位移。過去很多團隊評估本地模型，第一個問題通常是「單次任務品質夠不夠」，第二個問題才是「吞吐量撐不撐得住」。DiffusionGemma 反而把順序倒過來，逼大家先面對一個更產品化的問題：如果延遲能明顯低到讓人敢把模型放進互動介面、編輯器側邊欄、文件即時重寫或代理迴圈裡，那麼同樣一個任務，使用者願不願意接受略低於最強閉源模型的答案質量？這對開源生態尤其重要，因為開源模型真正難追上的從來不只是 benchmark，而是「用起來像不像正式產品」。當回應速度夠高，很多原本只適合離線批次的模型能力，會開始有機會進入半即時的工作流。

從這個角度看，DiffusionGemma 並不只是 Google 在試另一種生成演算法，也是在替開源模型市場試一種新的商業位置。它可能不是所有任務上的最佳答案，但非常可能成為某些工作流裡最順手的答案，例如大型文件的局部改寫、程式碼片段補洞、結構化輸出整理、圖文混合輸入後快速回覆，或需要反覆短回合互動的本地代理。若之後社群能把量化、蒸餾、微調與 serving 配套補齊，DiffusionGemma 最終帶來的影響，未必是 Google 自己多賣出多少模型，而是整個公開模型圈對「速度本身是不是一種核心能力」的答案，可能會被它往前推一大步。

真正可能被改寫的，是開源 生成式AI 的競爭維度。這一波公開模型原本最常比的是參數量、上下文長度、benchmark 分數與單位成本，但 DiffusionGemma 把「互動速度」重新抬上桌，而且不是靠縮模型，而是靠換生成方法。對要做本地代理、內部知識助手、即時程式補全或低延遲 檢索增強生成 產品的團隊來說，若模型能在單卡上維持更高輸出吞吐，整條產品設計都會變得不一樣。延遲更低代表 UI 可以更像即時工具，而不是每一次回覆都像在等雲端批次工作結束。

但這條路也還沒被宣告證明。首先，DiffusionGemma 雖然量化後可以塞進 24GB VRAM 級別，可是原始 26B 模型仍然不算輕，真正能舒服跑它的本地設備，和大多數一般消費級筆電仍有距離。其次，它每塊 canvas 最多 256 token，長文生成仍然要靠 block-autoregressive 方式一塊一塊往前接，代表 diffusion 並沒有徹底消滅序列性，只是把瓶頸挪到更大的 block 上。再者，模型卡也明寫推論會依任務難度決定去噪步數，簡單與結構化任務可以很早停，但複雜推理不一定能一直吃到最漂亮的吞吐量。換句話說，這不是免費午餐，而是一個非常有吸引力、但仍待大量真實負載驗證的新折衷。

Google 這一步最值得重視的地方，不是單一模型會不會立刻壓倒所有自回歸對手，而是它把「文字 diffusion 能不能成為實際產品架構」這件事，從研究辯論推進到了工程市場。如果接下來更多框架、量化版本與社群微調快速跟上，DiffusionGemma 很可能會讓開源模型競賽從「誰最像閉源前沿模型」改成「誰最適合真正放進工作流」。而一旦速度、可部署性與全局修正能力被證明能同時成立，下一輪本地 機器學習 與 智能體化 AI 工具的節奏，恐怕就不會再完全由逐 token 的老遊戲規則決定了。