DiffusionGemma——把文字生成從自迴歸換成擴散去噪

你已經知道 transformer 怎麼把一段 prompt 編碼成向量、知道 attention 在算什麼。這篇不重講那些。這篇要回答的是一個更窄、也更新的問題：當 Google 在 2026 年 6 月把 DiffusionGemma 丟出來、宣稱它「在 GPU 上文字生成快了最多 4 倍」、而且「能在生成途中回頭改掉自己已經寫出的字」時——它到底改了哪一塊機制？讀完你會知道：擴散語言模型的一次 forward pass 在算什麼、為什麼它能並行產出整塊 token、為什麼它能自我修正、這套做法用什麼換什麼，以及為什麼它特別吃 NVIDIA GPU 的胃口。

逐字落筆的代價——自迴歸解碼為什麼天生是序列的

先把今天所有主流 LLM 的解碼方式攤開，因為 DiffusionGemma 替換掉的就是這一塊。標準的 Gemma、GPT、Llama 都是 autoregressive（自迴歸）：給定前面所有 token，模型算出下一個 token 的機率分布，採樣一個，把它接到序列尾端，然後拿這條變長了一格的序列再餵一次模型，算下下一個。第 N 個 token 的生成，在定義上依賴第 N-1 個的結果。

這個依賴鏈有一個無法迴避的後果：生成 100 個 token 就要做 100 次 forward pass，而且這 100 次不能並行——第 50 次必須等第 49 次的採樣結果落定才能開始。你沒辦法用「多塞一張 GPU」把這條鏈拆開，因為它是資料依賴，不是算力不足。

更關鍵的是，這 100 次 forward pass 每一次都很「浪費」。為了算第 51 個 token，模型要把前 50 個 token 的 key / value 全部讀進來做 attention。這些 KV 早就算好、躺在 KV cache 裡，這一步幾乎不做新的矩陣乘法，主要時間花在「把 cache 從 HBM 搬到 SM」。用一句話總結它的性能瓶頸：自迴歸解碼是 memory-bound（受記憶體頻寬限制）的工作。GPU 的算力多半閒著，卡在等記憶體。

NVIDIA 的那篇 blog 把這件事講得很直白：傳統 LLM「一次生成一個 token，每個新字都依賴前一個字」，而這個依賴讓單次請求的延遲幾乎完全由 forward pass 的次數決定。你想讓一段 256 字的回覆快一倍，唯一的辦法是讓每次 forward pass 快一倍——但每次 pass 本來就沒在認真算，它在等記憶體。這是一條撞死的路。

值得把這個 memory-bound 的處境再講清楚一點，因為它是後面所有加速論述的對照組。一次自迴歸 decode step 的時間大致拆成兩塊：把模型權重從 HBM 讀進 SM、以及把已生成 token 的 KV cache 從 HBM 讀進來。在 batch size 為 1 的單使用者情境，這兩塊都是「讀一堆資料、做很少的乘加、吐出一個 logits 分布」。算術強度（arithmetic intensity，每讀一個 byte 做幾次浮點運算）很低，低到 GPU 的 tensor core 大半時間在空轉等資料。這也是為什麼 batch 很多請求能拉高自迴歸的總吞吐——把多個請求的權重讀取攤平——但對「單一請求的延遲」毫無幫助：那條 256 步的依賴鏈還是得一步步走。

業界這幾年為了打這條鏈想了不少招：speculative decoding 用一個小模型先猜幾個 token、大模型一次驗證一批；Medusa 之類的方法在模型上多接幾個 head 同時預測未來幾個位置。這些都是在「不改變自迴歸本質」的前提下，盡量把序列鏈壓短。它們有效，但天花板就在那裡——本質上你還是在一條因果鏈上猜測加驗證，猜錯了要回退。擴散語言模型走的是另一條路：乾脆放棄逐字因果，從一開始就把整塊當成一個並行的去噪問題來解。

整段一起沖洗——擴散語言模型把「生成」改寫成「去噪」

擴散模型這個詞你可能在影像生成那邊聽過：Stable Diffusion 從一張純雜訊的圖開始，反覆「去噪」，每一步把圖片推得更清晰一點，跑個 20~50 步收斂成一張圖。DiffusionGemma 做的是同一件事，只是把「像素」換成「token」。

但這裡有個重要的技術差異不能含糊帶過。影像擴散是在連續空間裡加減高斯雜訊——像素值是浮點數，你可以對它加一點點雜訊、再去掉一點點。文字不是連續的，token 是離散的符號，你沒辦法對「貓」這個 token 加 0.1 的高斯雜訊。所以文字擴散用的不是連續雜訊，而是一種離散的腐化過程：把 token「遮掉」（mask）或「替換成隨機 token」。Google 的文件把 DiffusionGemma 的方案稱為 uniform-state diffusion——畫布起手是「由隨機占位 token 鋪滿」的均勻雜訊態，去噪過程就是反覆把這些占位符替換成模型有把握的真實 token。所謂「加噪」與「去噪」，在文字這邊其實是「遮蔽程度」與「還原程度」的來回。

這個離散性正是擴散語言模型過去幾年一直做不太好的原因，也是 DiffusionGemma 這次值得停下來看的地方：把一個生產級、26B 規模、建立在 Gemma 4 骨幹上的擴散文字模型做到「在消費級顯卡上可用」，是這個方向第一次真正落到工程師桌面上，而不是停在 arxiv 的 toy model。

它的生成過程分三個階段。第一，模型起手是一張「由隨機占位 token 鋪滿的畫布（canvas）」——對 DiffusionGemma 來說，這張畫布固定是 256 個 token 寬。第二，模型對這整張畫布做多次 forward pass，每一次「把已經有把握的 token 鎖定，並用它們當作線索去精修其餘的位置」。第三，反覆幾輪之後，「整段序列突然對焦（snap into focus）」，收斂成通順的輸出。

注意這裡的根本差異：自迴歸的一次 forward pass 只產出 1 個 token；擴散的一次 forward pass 同時碰 256 個 token。Google 的開發者文件用的詞是「一次起草一整段 256 字的段落」。生成 256 字不再需要 256 次序列 pass，而是十幾次到幾十次「整塊去噪」pass——而且每一次 pass 內部的 256 個位置是並行算的。

把這件事換算成計算特性就很有意思了：把一整塊 256 token 推過 transformer，是一個結結實實的大矩陣乘法。它不在等記憶體，它在拼命算。Google 的文件原話是這套做法「把瓶頸從記憶體頻寬轉移到算力（shifts the bottleneck from memory bandwidth to compute）」。NVIDIA 的版本講得更白：「把一整塊 256 token 並行拉過 transformer 是 compute-bound 的工作——這正是 NVIDIA GPU 為之而生的東西。」memory-bound 變成 compute-bound，是這次 4 倍加速的真正來源，不是模型變小了。

用幾行 pseudocode 把兩種解碼的主迴圈擺在一起，差異會更刺眼：

// 自迴歸：序列長度 = forward pass 次數
tokens = [BOS]
for step in 1..256:
    logits = model(tokens)        // 整條序列餵進去，只取最後一格
    next   = sample(logits[-1])
    tokens.append(next)           // 接到尾端，永久定稿
// → 256 次序列相依的 pass

// 擴散：去噪步數 = forward pass 次數（≪ 序列長度）
canvas = random_tokens(256)       // 整塊雜訊起手
for step in 1..16:
    logits = model(canvas)        // 256 個位置一次全算（bidirectional）
    conf   = confidence(logits)   // 每個位置的把握程度
    canvas = update(canvas, logits, conf)   // 高把握鎖定，低把握 re-noise
// → 約 16 次並行的 pass，內部 256 位置同時算

注意第二段那行 canvas = update(...) 同時做了兩件自迴歸版本根本沒有的事：把高把握的位置鎖定下來當作後續的 context，把低把握的位置打回雜訊重來。自迴歸版本的 tokens.append(next) 只能往前加、不能回頭。這兩行的差異，就是「逐字落筆」與「整段沖洗」的全部分野。

下面這個 widget 把這個「整塊一起浮現」的動態畫出來。自迴歸是逐格點亮的；擴散是整塊從亂碼裡同時收斂。按 play，看 256 格畫布怎麼一步步從隨機 token 對焦成文字——這是靜態圖永遠表達不出來的時間維度。

play to watch a 256-token canvas converge · toggle 自迴歸 vs 擴散

▷ play ↺ reset 自迴歸 擴散 pass 0 · 已定稿 0 / 256

把 play 在兩個模式各按一次，你會直接看到那條依賴鏈消失：自迴歸模式下游標一格一格往右爬，擴散模式下整塊同時變深。這不是視覺花招——它就是兩種模型 forward pass 次數差異的字面寫照。

一次 pass 寫一格 vs 一次 pass 寫一塊——把兩種解碼擺在同一塊畫布上

上面那段動態講的是「過程」，下面這個對照講的是「單位」。同樣要產出一段文字，兩種模型在「一次 forward pass 換到多少 token」這件事上差了兩個數量級的概念。拖動中間的分隔線，左邊是自迴歸的視角、右邊是擴散的視角，看同一塊輸出在兩種解碼下被切成什麼形狀。

drag divider · 左 自迴歸逐字 · 右 擴散整塊

右半邊那行「attention = bidirectional」是整套機制裡最該記住的字。自迴歸模型用的是 causal attention——第 N 個位置只准看它左邊的 token，這是它能逐字生成的前提，也是它無法回頭改字的根源。擴散去噪用的是 bidirectional attention：在去噪這個階段，畫布上每一個 query 位置都能 attend 到所有其他位置，包括它「右邊」尚未定稿的位置。這個雙向性，是下一節要講的自我修正能力的全部來源。

能回頭改字——bidirectional attention 怎麼讓模型修掉自己的錯

自迴歸有一個結構性的悲劇：一旦採樣了一個 token、把它接進序列，它就永遠定稿了。如果第 10 個字選錯了，導致第 30 個字怎麼接都不通順，模型沒有任何機制回去改第 10 個字——它只能在錯誤的前提上繼續往下寫。這就是為什麼自迴歸模型有時會「一條道走到黑」，明明開頭跑偏了還硬把句子寫完。

這個悲劇的根源就是 causal attention。為了能逐字生成，自迴歸模型在訓練與推論時都強制「第 N 個位置只能看 1 到 N-1」——它從定義上看不到自己的右邊，因為右邊還沒生出來。這個約束讓它可以用 KV cache 高效推進，但也鎖死了它「事後回頭」的可能。你不能要求一個只能看左邊的模型去修正左邊，因為當它在處理右邊時，左邊早已是不可變的歷史。自迴歸的高效與不可修正，是同一個設計選擇的一體兩面。

擴散去噪沒有這個約束，因為它的每一個 token 在每一次 pass 都是「暫定」的，不是「定稿」的。Google 的文件描述了一個很具體的機制：在某次去噪 pass 裡，「如果一個 token 的置信度掉下來了，sampler 可以把它重新加噪（re-noise）並替換掉」——這是自迴歸模型沒有的能力。換句話說，第 5 步看起來對的字，到第 9 步發現跟周圍對不上，模型可以把它打回雜訊狀態，下一輪重新去噪。文件用「高置信度的 token 幫忙解析相鄰位置，導致整段序列突然對焦」來形容這個彼此校正的過程。

下面這張靜態圖把「re-noise 一個低置信度 token」的瞬間畫出來。關鍵在於：因為是雙向 attention，左右兩邊已經鎖定的高置信 token 一起對中間那個搖擺的位置施加約束，把它從錯誤的候選拉回正確的候選。

這也解釋了為什麼擴散在某些「需要全局一致性」的任務上特別漂亮。Google 的開發者文件給了一個量化例子：用 Sudoku（數獨）做 supervised fine-tuning，base model 解題成功率大約 0%，SFT 之後拉到 80%，而且推論步數同時下降——fine-tune 過的模型 12 步就解出來，base model 要 48 步。數獨是個經典的「全局約束滿足」問題：填一格要同時滿足行、列、宮三個約束，逐字往右填的自迴歸天生不擅長，能來回改格子的擴散正中下懷。

這個數獨數字有兩層意思，分開讀比較不會誤會。第一層是「能不能解對」：base 的 0% 到 SFT 的 80%，說明擴散的去噪框架本身不會自動會解數獨，得透過 fine-tune 教它把「填格→檢查約束→改格」這個迴圈映射到去噪步驟上。第二層、也是更有趣的一層是「要去噪幾步才解出來」：48 步降到 12 步。這代表 fine-tune 不只提升了正確率，還讓模型學會「更快收斂」——每一步去噪推進得更果斷，少了很多來回搖擺。對工程師來說這是個訊號：擴散模型的「步數」不是固定常數，它跟任務、跟 fine-tune 都有關，可以被優化。

反過來講，這也劃出了擴散不擅長的邊界。如果任務本質就是「嚴格從左到右、後文強烈依賴前文的精確值」——例如逐字背誦一段已知文本、或產生一個每個 token 都不容出錯的長串 ID——擴散的並行假設反而幫倒忙：它一開始對整塊的猜測會彼此干擾，要花很多步才能把一條本來該是嚴格序列的東西收斂好。自迴歸在這種「天生序列」的任務上，逐字落筆的劣勢反而變成優勢。沒有一種解碼策略對所有任務都贏。

步數就是旋鈕——品質與延遲怎麼用去噪步數換算

到這裡你可能會問：既然擴散一次 pass 就碰 256 個 token，那一步搞定不就好了？不行。一步去噪等於要求模型從純雜訊直接猜出整段話，品質會崩。去噪步數是擴散模型最核心的旋鈕——步數越多，每一步只需把序列推進一點點，收斂越穩、品質越高，但延遲也越高；步數越少，越快，但越容易留下沒對焦的雜訊。

這跟自迴歸的「步數 = 序列長度」是完全不同的成本曲線。自迴歸你沒得選，256 個 token 就是 256 步。擴散讓你把「要花幾步」變成一個可調參數，在品質和延遲之間滑動。拖下面這條滑桿，看去噪步數怎麼同時牽動相對延遲與輸出品質——兩條曲線往相反方向走，sweet spot 落在中間某處。

drag · 去噪步數 1→64 → 看品質與延遲反向移動

去噪步數 = 16 步

為什麼一步去噪不行、值得再從機率的角度看一眼。模型在每一步只能輸出「在當前已知資訊下，每個位置各自的邊際分布」。若整塊幾乎全是雜訊，每個位置的條件資訊極少，模型只能各自獨立地猜——但語言的字與字之間高度相關，獨立猜出來的一整塊拼在一起多半不通順。多走幾步的價值在於：第一步把少數最有把握的字鎖定，這些字立刻變成第二步其餘位置的 context，於是第二步的條件分布變窄、更準。這就是 Google 文件講的「高置信度的 token 幫忙解析相鄰位置」。步數提供的，本質上是「讓資訊在位置之間逐步傳播」的輪數。

關於品質有一句話必須說在前面，免得這篇讀起來像 Google 的新聞稿：DiffusionGemma 整體輸出品質低於標準的 Gemma 4。Google 自己在 blog 裡寫得很清楚——它「不適合追求最高品質的 production 應用」。這不是 4 倍加速白拿的午餐，而是用一截品質換來的延遲。它的定位是「速度優先、品質可接受」的場景：互動式草稿、code 補全的快速候選、需要低延遲回饋的 agent 內迴圈。

把這個取捨放回上面那條曲線看：曲線是飽和的，意味著從 4 步加到 16 步，品質提升很明顯；從 16 步加到 64 步，品質只多擠出一點點，延遲卻線性翻了 4 倍。理性的部署選擇是踩在拐點附近——這也正是 DiffusionGemma 用「十幾步」跑完 256 token 的原因。它不是跑滿步數追品質頂點，而是停在「品質夠用、速度還快」的位置。換句話說，那個 4 倍加速本身就已經內含了一個品質取捨的選擇：你願意接受略低的品質，所以你可以停在低步數，所以你快。把步數拉到讓品質追平 Gemma 4，那個 4 倍大概也就不見了。

為什麼這顆模型特別吃 NVIDIA——本地跑起來的數字

把規格擺上來。DiffusionGemma 建立在 Gemma 4 的骨幹上，是一個 26B 的 Mixture-of-Experts（MoE）模型，但推論時每一步只啟用 3.8B 參數。授權是 Apache 2.0。量化之後「能舒服地塞進 18GB VRAM 上限」，這意味著它跑得進一張消費級顯卡。NVIDIA 提到的量化格式是 NVFP4。day-zero 就支援 Hugging Face Transformers、vLLM，以及用 Unsloth 做 fine-tuning；vLLM 那條路提供 OpenAI 相容的本地 serving，可以配置 entropy bound 與 canvas 長度等參數。

MoE 這個選擇值得單獨拆一下，因為它跟擴散的計算特性配得很巧。26B 總參數、推論啟用 3.8B，意思是這顆模型有一大堆 expert，但每個 token（或每塊去噪）只路由到其中一小部分。對自迴歸 MoE，這主要是省算力；對擴散 MoE，它同時壓住了「一次要把 256 個位置都推過去」的算力帳——你不是把整個 26B 都對 256 個位置乘一遍，而是只動用被路由到的 3.8B。這讓「整塊並行」在算力上仍然付得起，也是它能塞進 18GB、在 RTX 5090 上跑出 700+ tokens/sec 的前提之一。總參數大保住了模型容量（品質），啟用參數小保住了單步成本（速度），擴散的並行性則保住了 forward pass 次數少（延遲）——三者疊起來才湊出那張吞吐表。

真正有意思的是吞吐量數字，以及它們為什麼長這樣。下面這張表把三家來源公布的硬體數字攤開（可點欄位排序）。

click column header to sort · 4 columns × 4 rows

硬體	tokens / sec	記憶體	來源
NVIDIA H100（單卡）	1000	—	Google / NVIDIA
GeForce RTX 5090	700	18GB VRAM 內	Google
DGX Spark（GB10）	150	128GB 統一記憶體	NVIDIA
DGX Station	2000	748GB coherent	NVIDIA

把表往「為什麼」推一層。自迴歸是 memory-bound，所以它的瓶頸是 HBM 頻寬——換更快的記憶體才會快，加算力沒用。擴散把那次 256-token 的 forward pass 變成 compute-bound 的大矩陣乘法，瓶頸轉到 GPU 的浮點算力（以及 NVFP4 這類低精度格式的 tensor core 吞吐）。NVIDIA 那句「這正是 NVIDIA GPU 為之而生的東西」不是公關話術——它在陳述一個架構事實：擴散的 workload 形狀，剛好對齊了現代 GPU 大量閒置的平行算力。這也是為什麼一張 RTX 5090 都能跑出 700+ tokens/sec，而同尺寸的自迴歸模型在同一張卡上會卡在記憶體頻寬。

再補一個容易被加速數字蓋掉的細節：超過 256 token 的序列怎麼辦？DiffusionGemma 用的是 block autoregressive diffusion——畫布固定 256 寬，一塊去噪收斂後，「模型把它提交進 KV cache」，再「初始化下一塊新的 256-token 畫布，以先前已提交的歷史為條件」。所以它在「塊內並行去噪」與「塊間自迴歸推進」之間做了個混血：塊內享受並行與自我修正，塊間仍是因果順序。長文本不是無限並行，而是一塊一塊往前推。prompt 的吞入則用 causal attention 做 prefill 寫 KV cache，只有去噪階段才切到 bidirectional——兩種 attention 在同一顆模型裡分工。

這個混血架構有一個務必記住的後果：自我修正只在「塊內」有效。一旦某塊去噪收斂、提交進 KV cache，它就跟自迴歸一樣定稿了——後面的塊只能以它為條件，無法再回頭改它。所以 256 這個畫布寬度不只是個吞吐參數，它也是「自我修正的作用範圍」。一個錯誤如果跨越塊邊界才顯現（前一塊寫的某個設定，到下一塊才發現矛盾），模型同樣救不回來。這也解釋了為什麼 Google 把畫布定在 256 而不是更小：太小的塊會讓自我修正的窗口太窄、跨塊矛盾變多；太大的塊則讓單次 forward pass 的算力與記憶體成本爆掉。256 是這條取捨線上的一個工程選點。

把整個推論生命週期串起來，DiffusionGemma 在一次請求裡其實切換了兩種 attention 模式：吞 prompt 時是 causal attention 的 prefill / incremental prefill，把 prompt 的 KV 寫進 cache，這一段跟普通自迴歸模型沒兩樣；進入生成後才切到 bidirectional 的去噪，讓畫布上每個 query 並行 attend 到所有位置。理解這點對讀懂吞吐數字很關鍵：那些 700、1000、2000 tokens/sec 量的是「去噪生成階段」的吐字速度，prompt 很長時的 prefill 仍然要付 causal 那一段的帳。對「短 prompt、長輸出」的互動場景，擴散的加速最明顯；對「長 prompt、短輸出」的場景，加速會被 prefill 稀釋。

對「下週要不要動手用它」的工程判斷，落點大概是這樣：如果你的場景對延遲敏感、對絕對品質容忍度高（互動式補全、草稿生成、agent 的快速內迴圈、結構化約束問題如解謎/排程），DiffusionGemma 用一張消費級卡就能跑出自迴歸吃不到的吞吐，值得試。如果你的場景是「一句都不能錯」的 production 文案或 reasoning，Google 自己都說它品質低於 Gemma 4，先別替換主力模型。它是工具箱裡多出來的一把快刀，不是萬用刀的升級。

Mental model：自迴歸是一隻手逐字落筆、寫過不能改；擴散去噪是讓整段話從雜訊裡同時對焦，每個字在定稿前都還能被鄰居拉回去——把生成從 memory-bound 的序列鏈，換成 compute-bound 的並行收斂，速度與「可回頭改字」就是這一換得來的。