別再只盯著“AO”兩家的新模型大戰(zhàn)了！

就在剛剛，谷歌悶頭干了件大事：

把生成圖片的擴散模型，拿來寫文字了，而且一出手就是4倍加速。

新模型名為DiffusionGemma，它直接拋棄了傳統(tǒng)自回歸那套“逐Token生成”的打字機模式，而是像“印刷機”一樣工作——

一次鋪開256個token的“畫布”，從隨機噪聲出發(fā)，多輪去噪，整段文字同時浮現(xiàn)。

靠這套新模式，DiffusionGemma在生成速度方面交出了亮眼的成績：

單塊H100上每秒1000+ tokens，消費級RTX 5090上700+，比同規(guī)格自回歸模型快了4倍。

更關(guān)鍵的是，這個26B參數(shù)的MoE模型，推理時只激活3.8B參數(shù)，量化后18GB顯存就能裝下。

翻譯過來就是，一張4090就能本地跑。

目前DiffusionGemma采用允許商用的Apache 2.0開源協(xié)議，權(quán)重可在Hugging Face直接下載。

天下武功，唯快不破

說到這估計大家都明白了，DiffusionGemma身上最大的標(biāo)簽無疑就是“快”。

有多快呢？成績單說話。

在同一塊H100上（fp8，batch size=1），DiffusionGemma跑出了1000+ tokens/s，而采用標(biāo)準(zhǔn)自回歸的Gemma 4 26B A4B加上MTP加速也只有300+ tokens/s——

速度拉開近4倍。

而要理解DiffusionGemma為什么快，咱得先說說當(dāng)前大模型為什么“慢”。

今天的主流大模型，不管是GPT、Claude還是Gemini，底層都是自回歸架構(gòu)——就像一臺打字機，從左到右，一個token一個token地敲出來。每生成一個新詞，都要重新加載一遍幾十億參數(shù)的模型權(quán)重。

在云端，這不是大問題。服務(wù)器可以同時處理上千個用戶請求，把硬件利用率拉滿。

但如果你在本地跑模型，場景就完全不同了——

只有你一個人在用，GPU的大量算力其實在空轉(zhuǎn)，等著一個字一個字地往外蹦。

工程師管這叫“內(nèi)存帶寬瓶頸”（memory-bandwidth bound）。

而為了解決這一問題，DiffusionGemma就盯上了擴散模型。

回想一下，擴散模型在生成圖片時，是不是直接對整張圖的所有像素同時去噪——

沒錯，其工作方式就是一次性對一整塊token同時操作，天然“并行”。

這意味著GPU一次性接到一大塊并行計算任務(wù)，Tensor Core火力全開，不再干等。計算瓶頸從“內(nèi)存搬不過來”變成了“算力夠不夠”，而算力恰恰是GPU最不缺的東西。

具體到DiffusionGemma，原理和Stable Diffusion一樣，只不過去噪得到的不是圖片，而是文字。

Step 1：鋪開一張全是隨機占位符的256個token的畫布。
Step 2：多輪迭代去噪，高置信度的token先鎖定，再用它們當(dāng)上下文線索去修正其余部分。
Step 3：整段文字收斂為最終輸出。

用谷歌自己的比喻，這是從單線程的打字機，升級成了整版印刷的印刷機。

看看下面這個Hugging Face制作的DiffusionGemma文本到3D SVG演示，可以直觀感受逐步生成的過程——

模型不是從第一行代碼寫到最后一行，而是整塊SVG代碼同時浮現(xiàn)、同時修正，最終收斂成一把完整的3D寶劍。

雙向注意力：不止是快

速度之外，DiffusionGemma身上還有一個點值得關(guān)注：雙向注意力。

傳統(tǒng)自回歸模型只能往前看，模型在生成第N+1個token時，只能看到第1到第N個token，看不到自己還沒寫出來的未來內(nèi)容。

而DiffusionGemma的256個token同時生成，每個token都能看到畫布上所有其他token，前后文同時可見。

這就帶來了一個自回歸模型很難做到的能力——實時自我糾錯。

模型邊生成邊評估整段文字的一致性，發(fā)現(xiàn)不對立刻修正，不用等全寫完再回頭改。

這里谷歌舉了個直觀例子：數(shù)獨。

數(shù)獨本質(zhì)是“后面的數(shù)影響前面的數(shù)”，自回歸模型由于只能往前看，所以做起來極痛苦。

但DiffusionGemma微調(diào)后成功率從0%飆到80%。

所以，如果未來接觸到代碼補全、行內(nèi)編輯、復(fù)雜markdown格式化……這些“需要前后文同時協(xié)調(diào)”的場景，擴散模型無疑更有結(jié)構(gòu)性優(yōu)勢。

谷歌CEO皮猜：DiffusionGemma是一匹“賽馬”

不過這也并不是說擴散模型就千好萬好。

其最大局限在圖像生成領(lǐng)域也已得到驗證，那就是速度和質(zhì)量的平衡——

去噪步數(shù)越少速度越快，但質(zhì)量越差；步數(shù)越多質(zhì)量越好，但速度優(yōu)勢也就越小。

質(zhì)量方面，和同參數(shù)量的Gemma 4 26B A4B相比，DiffusionGemma在多項基準(zhǔn)上確實存在差距。

谷歌也很坦誠，生產(chǎn)環(huán)境推薦標(biāo)準(zhǔn)Gemma 4，DiffusionGemma面向的是速度敏感的本地交互場景。

所以，或許正如谷歌CEO皮猜所言，DiffusionGemma目前更像一匹“賽馬”——

先把速度提起來。

它目前只是谷歌對下一代模型形態(tài)的一次實驗：

如果不再執(zhí)著于一個token一個token往外生成，而是讓模型充分利用現(xiàn)代GPU的并行算力，大模型的速度上限究竟還能被推到多高？

而且說實話，谷歌也不是第一個嘗試驗證這條路線的人。

早在今年2月，初創(chuàng)公司Inception Labs就發(fā)布了擴散文本模型Mercury 2，號稱比Claude、Gemini快5到10倍，是業(yè)內(nèi)第一個真正投產(chǎn)的擴散語言模型。

谷歌自己去年I/O上也展示過Gemini Diffusion實驗，當(dāng)時采樣速度達(dá)到每秒1479 token，但之后沉寂了一整年，外界一度猜測“跑不起來”。

直到現(xiàn)在，DiffusionGemma卷土重來，并且NVIDIA從RTX到H100全線給它護航——

4090到H100到DGX Spark全覆蓋，vLLM、MLX、Unsloth、NeMo全部支持，llama.cpp也在路上。

只能說，嘴上說著“實驗性”，身體卻很誠實。

谷歌這次給DiffusionGemma配上的資源和生態(tài)支持，顯然不是來做技術(shù)Demo的。

從模型到推理框架，再到硬件生態(tài)，DiffusionGemma已經(jīng)拿到了足夠多的支持。

至于它最終能不能挑戰(zhàn)自回歸模型的主流地位，現(xiàn)在還沒人知道。

但至少，谷歌把這條路真正開源了。

HuggingFace：
https://huggingface.co/unsloth/diffusiongemma-26B-A4B-it-GGUF
使用指南：
https://unsloth.ai/docs/models/diffusiongemma