前言

DiffusionGemma 是 Google 最新的開放權重語言模型，它改變了文字生成的方式：與其逐一輸出 token，不如並行地細化整個 token 區塊。這種方法承諾帶來顯著的速度提升 — 基準測試顯示在 NVIDIA H100 上超過 1,000 tokens per second — 並以 Apache 2.0 授權釋出，權重可在 Hugging Face 取得。該模型旨在加速像程式碼補全、結構化輸出與其他受限條件較多的任務。然而，目前實際價值受到缺少執行時元件與配置障礙的限制。本文總結 DiffusionGemma 的運作方式、為何其架構不同，以及日常使用者與開發者要有效運行它所需的條件。

Lazy bag

DiffusionGemma 透過從帶噪音的 token 區塊開始並反覆細化它們來生成文字，從而啟用 大規模並行 的生成。它在高階 GPU 上 非常快 並且免費釋出，但需要一個特定的 drafter/執行時整合，大多數公開工具包尚未提供，因此對大多數使用者來說並非即插即用。

主體

Google 的 DiffusionGemma 標誌著語言生成實驗的一個顯著轉變。傳統大型語言模型（LLM）使用自回歸架構：token 依序產生，每個 token 都以先前的 token 為條件。DiffusionGemma 採用來自擴散式影像生成的不同範式：它從一個帶噪音或佔位的 token 畫布開始，在多個步驟中細化該畫布，直到出現連貫的文字區塊。這允許模型生成大塊的連續文字 — 在 DiffusionGemma 的情況下，每次前向傳遞可處理 256-token 的區塊 — 並充分利用 GPU 的並行能力。

這種設計的實際好處是速度。在像 NVIDIA H100 這類經過優化的硬體上，Google 報告吞吐量超過 1,000 tokens per second，他們將其定位為大約比相應的自回歸 Gemma 變體快四倍。在消費級 GPU（例如 NVIDIA GeForce RTX 5090）上，他們報告持續的性能為每秒數百 token，對於許多工作負載來說，這仍然比序列解碼有顯著改進。

在架構上，擴散生成在細化過程中引入了雙向注意力。不同於在生成期間無法注意未來 token 的自回歸模型，DiffusionGemma 的迭代細化讓每個 token 都能觀察並影響區塊中其他 token。這一特性對於後續內容會約束先前內容的任務特別有用 — 例如程式碼補全、表格或 JSON 等結構化輸出，以及受限推理任務。Google 用數獨微調展示了這一點：基礎模型在原始拼圖上表現不佳，但經任務專用微調後的變體能正確解出許多拼圖，說明在適當微調下模型的潛力。

儘管前景可期，但發布伴隨著實務上的警示。該模型需要一個互補的輕量級 drafter 元件以實現高效的本地推理。drafter 能並行提出候選 token 區塊，接著主模型在單次前向傳遞中驗證或細化這些候選 — 這種設定有時稱為 speculative decoding。雖然研究與部分商業方案已展示這如何解鎖數倍加速，但 DiffusionGemma 所需的 drafter 實作與執行時整合尚未出現在許多廣泛使用的開放執行時中。

具體來說，像 mlx-lm（Apple Silicon 的 MLX）與 LM Studio 等熱門開放工具鍊與執行時並不包含 DiffusionGemma 所需的特定 drafter 模組。嘗試通過其他生態系統運行該模型時可能會遇到配置限制：例如，在 NVIDIA 的 NIM 服務上，模型被預配置為 8,192-token 的上下文窗口設定，這阻止了某些代理框架（如 Hermes Agent）初始化，因為它們的預設需要更大的窗口。實際上，模型的原生設計支援更大的上下文（Google 的資料提到 256K 的上下文容量），但預設執行時參數可能誤導並阻礙代理化使用。

這些障礙意味著，儘管在正確配置的硬體上原始吞吐量數據令人印象深刻，許多開發者與研究人員在重現這些結果前仍會遇到摩擦。缺少 drafter 原始碼、需要 speculative decoding 框架，以及為代理或長上下文配置所需的手動重新設定，是當前的主要痛點。社群工具鍊與第三方整合通常落後於釋出；在這些補齊之前，大多數使用者會發現要「有效」運行 DiffusionGemma 仍是一項不容易的工程任務。

誰會先受益？建立延遲敏感工具的開發者 — 嵌入式編輯器、程式碼完成引擎與結構化生成服務 — 在能整合適當 drafter 與調校時會覺得其速度特性很有吸引力。模型的雙向注意力模式也開啟了新的研究方向：遠距位置彼此依賴的問題（蛋白質序列、數學構造、圖結構與長格式結構化輸出）可能特別受惠於擴散式生成。

DiffusionGemma 採用開放授權（Apache 2.0）很重要：它加速了實驗、分支與社群工具鍊的貢獻。早期跡象已顯示社群興趣 — 在像 llama.cpp 的專案中出現了草案移植與 PR — 隨著執行時加入 drafter 支援與 speculative decoding 原語，這個模型在 Google 以外的環境中會變得更容易運行。但就目前而言，缺少執行時支援與預設配置問題的組合意味著模型在實際世界的可用性仍在成長中。

總而言之，DiffusionGemma 在重新思考語言生成的權衡方面是一個重要步驟：它以並行細化取代序列解碼，在合適的硬體上帶來可觀的加速，同時在生成期間啟用雙向上下文。眼前的限制是後勤與工具面，而非理論上的問題，因此隨著社群與執行時供應商補齊缺失的整合元件，預期會迅速改善。當那時到來，模型的性能主張將可被更廣泛的開發者與研究人員所利用。

關鍵見解表

未包含任何廣告或宣傳內容。此處的目標是對 DiffusionGemma 的技術變化、權衡與採用的即時障礙提供中立且實用的概述。