AI Engineer Europe 2026 · 演講 · 2026-06-04 · 28 分
文字擴散：低延遲的另一條路
Text Diffusion · Brendan O’Donoghue，Google DeepMind
Brendan 介紹 DeepMind 的文字擴散研究：從原理、硬體上為何延遲低，到自我修正與自適應運算等優點，以及吞吐量不足的代價。
概要
- 整塊精修取代逐字生成文字擴散把一段隨機 token 經過幾次去噪步驟逐步修成乾淨文字，而不是一次吐一個 token。
- 延遲低的原因在硬體自迴歸每個 token 都要搬一次整個網路與 KV cache，受限於記憶體頻寬；擴散的搬運次數少，Brendan 舉例 24 次產生 256 個 token，搬運少約 10 倍。
- 能回頭修錯模型看得到後面的 token。Brendan 示範一道算術題先猜錯、推理完再回頭改對；同一題當時的 ChatGPT 先答錯、推理完才道歉改口，Gemini 2.5 Flash 則把錯的答案一路帶進推理。
- 運算量可以自己調多給去噪步驟，品質大致跟著上升；模型也能自己決定何時結束，簡單的回覆步數少、困難的步數多。
- 最大缺點是吞吐量擴散在大批量服務時較早碰到算力上限，所以目前沒有人把它放進大型主力模型；Brendan 認為它適合不需批次處理的場景，例如裝置端。
原話
▶ 04:04“generates faster tokens per second because it makes much better use of the hardware, the TPU and the GPU”
生成速度更快，因為更能用好 TPU 與 GPU 這些硬體
▶ 10:42“it made a mistake but it was able to you know had another forward pass it was able to go through and fix that mistake”
它先錯了，但再跑一次前向傳遞就能回頭把錯修掉
▶ 14:14“easier prompts it could respond to quickly, and harder ones it decided itself to spend more time reasoning”
簡單的提示它很快就回，困難的它自己決定多花時間推理
▶ 16:12“it's not just the same thing faster”
不只是把同樣的事做得更快
▶ 25:33“you may as well pick the low latency one, because you don't have the throughput concerns”
那就不如選低延遲的，因為你沒有吞吐量的顧慮
延伸
- Brendan 說現代的推理模型也能補救自迴歸先猜錯的問題，但那只是把問題推給別的機制。
- 被問到能不能把擴散和其他做法混著用時，Brendan 說用噪聲訓練的模型就預期輸入是噪聲，要配合就得另外訓練、增加複雜度，所以團隊通常不這麼做，文獻裡倒是有不少嘗試。
章節
點時碼直接跳到原片的那一段。
- 從圖像擴散到文字擴散Brendan 說明文字擴散的做法：訓練時把乾淨句子加噪（離散時就是替換成隨機 token），讓網路學著修正，推論時從純隨機 token 逐步精修回乾淨句子。
- Gemini Diffusion 回顧Brendan 的團隊一年前釋出 Gemini Diffusion 研究預覽，開放給約 100k 人；對比 Gemini 2.0 Flash-Lite，品質相近、程式碼略占優，延遲好很多。
- 自迴歸與擴散的差別自迴歸一次產生一個 token；擴散先把整段（數百到數千 token）設成隨機噪聲，再用幾次去噪步驟整塊精修，過程中看得到後面的 token。
- 文字擴散的優點最大優點是推論更快、更能用滿 TPU 與 GPU；另有區塊內雙向注意力、可自我修正、可調整運算量，以及原地編輯。
- 最大缺點：大批量吞吐自迴歸模型單人慢，但能把大批查詢塞在一起、成本壓低；擴散多次跑同一批資料，較早碰到算力上限，所以目前沒有人把它放進大型主力模型。
- 為什麼延遲低GPU 與 TPU 的算力多、頻寬少，自迴歸每個 token 都要把整個網路與 KV cache 搬一遍而受限於記憶體；擴散若用 24 次產生 256 個 token，搬運次數少約 10 倍。
- Gemini Diffusion 的速度網頁上報的每秒約 2,000 個 token 已含 prefill；序列越長越能發揮，只產生一個 token 時則被 prefill 成本主導。
- 優點一：雙向推理與自我修正以一道算術題示範，答案在第一次前向傳遞先猜 60、第二次改 49、推理跑完後修成 39。同題當時的 ChatGPT 先答 40、推理完才改口，Gemini 2.5 Flash 先答 42 之後就不改了。
- 優點二：多算幾步品質更高給模型更多去噪步驟，在團隊內部追蹤的六個程式評測上品質大致單調上升。
- 優點三：自適應運算模型被訓練成自己決定何時結束：100 位圓周率 4 步、fizzbuzz 18 步、一段量子力學說明 31 步；越難的評測（GPQA diamond）用越久，MBPP 則很快。
- 優點四：原地編輯因為不是依序生成，模型能看到整體再填補缺口；Brendan 先用圖像舉例，再示範修程式 bug、加文件說明，以及在故事中補一段。
- 低延遲開出的新應用團隊內部做的示範：即時生成的 Wikipedia 與 Reddit（圖片由另一個圖像模型補上）、整個即時生成的作業系統，以及外部使用者用語音在約 15 秒內做出待辦清單 app。
- 問答：訓練、蒸餾與步數RL 用的資料與自迴歸相同，只是演算法要調；蒸餾可行；模型越大需要的步數越少。
- 問答：長度與區塊式生成最簡單的做法是固定視窗長度，區塊內擴散、區塊之間自迴歸；prefill 與一般相同，區塊大小可以是 32、512 或一千。
- 問答：混合與離散空間目前文獻裡多數文字擴散是離散擴散，也有人做過潛在空間版本；Brendan 說團隊的做法一律是離散 token 進、token 出。
- 問答：適合的場景裝置端不必和上千個查詢一起批次處理，吞吐量不是問題；Brendan 說團隊已參與 Alphabet 內幾個裝置端應用，例如手機與機器人，品質相近時就不如選低延遲的。
名詞
- Brendan O’Donoghue
- Google DeepMind 的 research scientist，研究文字擴散
- Gemini Diffusion
- Brendan 的團隊一年前釋出的研究預覽，用擴散而非自迴歸的方式生成文字
- 離散擴散
- 加噪方式是把 token 換成詞彙表裡的隨機 token；Brendan 說目前文獻裡多數文字擴散屬於這一類
- 自迴歸
- 一次產生一個 token、後一個以前面的為條件的標準做法
- KV cache
- 推論時要從記憶體搬進運算核心的快取，是自迴歸受記憶體限制的原因之一
- prefill
- 先處理輸入上下文的階段；只產生很少 token 時，它會主導總成本
- 自適應運算
- 模型被訓練成自己判斷何時完成，簡單問題用少量步驟
- 原地編輯
- 固定住部分內容，讓模型填補缺口，例如在程式碼或故事中補一段
