Text Diffusion：文字生成不一定要
一個 token 一個 token 吐

先講結論：text diffusion 的重點不是「更會寫」，而是「互動延遲變了」

這支 talk 把 text diffusion 放在工程問題來看：autoregressive 模型一次只能根據過去 token 產生下一個 token，因此很適合串流，但也被「單向生成」限制住。Text diffusion 則是在一段文字上反覆去噪，模型每一步都能看見整段候選答案。

這帶來兩個直接差異：第一，它可以在生成途中修正前面寫錯的內容；第二，如果步數夠少，整段文字的產生延遲可能低到能改變 UI 形態。影片描述給出的關鍵數字是：用 24 個 denoising steps 產生 256 tokens，memory transfers 約比 autoregressive generation 少 10 倍。

Gemini Diffusion 第一次 forward pass 先答 60，接著變 49，最後在完成推理後修正成 39；這個「回頭修正」正是 bidirectional attention 和 autoregressive 生成的差異。— 本頁依 YouTube feed、影片 metadata 與官方描述整理；自動字幕 track 有列出但 timedtext 目前回空內容

推理題 demo 在說什麼

影片描述用同一道題開場：GPT-4o 答 40；Gemini 2.5 Flash 答 42，而且即使推理過程已經走錯仍固定答案；Gemini Diffusion 一開始答 60，再變成 49，最後修正為 39。重點不是哪個模型在單題上最準，而是生成機制帶來的錯誤修正能力。

Autoregressive 模型一旦吐出前面的 token，後面只能補救、解釋或重新開一段；diffusion 模型在同一輪生成裡持續更新整段答案。這比較像在草稿上反覆改稿，而不是從左到右打字。

速度來自 fewer memory transfers，不只是模型更小

Brendon Dillon 的工程論點是：如果 256 tokens 可以用 24 次 denoising step 產生，模型不需要為每個 token 都做一次序列式前進。影片描述把這個差距量化成約 10x fewer memory transfers，這對推理延遲很關鍵，因為現代 LLM serving 很常被 memory bandwidth 與 KV cache movement 卡住。

這也是為什麼 talk 把 2,000 tokens per second 當成一個產品分水嶺。當文字生成快到不像「等待模型輸出」，而像 UI 的即時素材，應用就不只是在聊天框裡跑得更快，而是可以每次點擊、每次語音指令都動態生成下一個畫面。

Demo 真正想展示的是新 UI，而不是新聊天機器人

官方描述列出四個 demo：即時生成 fake Wikipedia、帶有 AI comments 與 images 的 Reddit clone、每次點擊都生成下一個畫面的 operating system，以及 15 秒內用語音做出 todo app。這些 demo 的共同點是：使用者不是在等一段回答，而是在跟「即時生成的介面」互動。

如果 latency 足夠低，模型輸出就能從內容層進入介面層。這對 AI app 的啟發很直接：不要只把 fast model 當成更快的 autocomplete；要思考哪些產品流程原本因等待時間太長而不能生成，現在可以變成每一步都即時重組。

但 serving economics 還沒解決

影片也沒有把 text diffusion 包裝成全面取代 autoregressive。官方描述明講目前 trade-off：在大 batch sizes 下 throughput 較低，導致大規模服務成本仍然昂貴。也就是說，它可能很適合低延遲、互動性強、需要快速局部重寫的場景，但不一定是最高吞吐量的大量文本生成最佳解。

目前更務實的看法是：text diffusion 是一條值得追蹤的 serving frontier。它把「單次互動 latency」推得很低，但 production 團隊仍要用自己的 batch pattern、流量尖峰、成本上限和 UX 需求評估是否值得採用。

實務啟發：AI app 要重新定義「等待」