當你是 LLM 時，沒有什麼是容易的：平坦延遲問題

人類走到廚房時幾乎不需要費力，但解微分方程會消耗大量能量。人的能量消耗與任務難度成正比，大語言模型卻恰恰相反：無論被問到“法國的首都是哪裡”，還是要求解釋量子計算的最新進展，模型生成每個 token 的代價都完全一樣——每次都執行一次完整的前向傳播，遍歷所有層、注意力頭和權重。預測“Paris”和“Qubit”在計算上是完全相同的事件。這不是效率問題，而是架構本身決定的，而這一特性滲透在人類與 LLM 的每一次互動中。

由於計算量完全均勻，模型在生成程式碼時也會出現荒誕的浪費：比如生成 Python 函式，在“for i in range(len(my_list”之後，下一個閉括號幾乎是確定性的，任何在 GitHub 程式碼上訓練過的模型都能以接近 100% 的機率預測到。但模型仍然要為這個閉括號、後面的冒號、換行和縮排等每個語法 token 支付全量的前沿模型計算成本。真正決定邏輯走向的關鍵 token 也只有同樣的價格。在多智慧體系統中，問題進一步放大：每個智慧體都在為每一個 token 支付完整的模型成本，包括那些根本不需要前沿模型參與的簡單 token。這就是所謂的“平坦延遲”問題，它無法透過堆硬體解決。

投機解碼提供了一條混合路線。一個小而廉價的草稿模型先快速生成 K 個 token，大型驗證模型再透過一次並行前向傳播檢查全部 K 個 token——不是 K 次，而是一次。如果草稿 token 與驗證模型本應生成的內容一致，就相當於用一次驗證的成本產出了 K 個 token。如果第 N 個 token 開始分叉，就接受前 N-1 個，用驗證模型的修正 token 替換第 N 個，然後丟棄剩餘草稿並繼續。最終輸出永遠等於大型模型單獨生成的結果，草稿模型不會汙染輸出質量。關鍵限制是草稿模型必須足夠快且足夠準：如果 10 個 token 能猜對 7 個，加速效果會非常明顯；如果接受率低於約 60%，多跑一個模型只會增加複雜度，卻換不回延遲收益。

投機解碼本身並非新概念，HuggingFace 中早已支援，技術上只需要在 generate() 裡傳入一個 assistant_model 引數。真正的難點在於草稿模型的配對：草稿模型和驗證模型必須共享同樣的分詞器和輸出分佈，實際只能使用同系列模型，或者驗證模型自身的蒸餾/量化版本。選錯配對，接受率就會崩潰，等於同時跑兩個模型卻沒有收益。大多陣列合都不適用，所以大多數團隊選擇放棄。Gemma 4 改變了這個局面。它內建的 MTP（多 token 預測）草稿器不是外掛的獨立模型，而是直接訓練進架構的預測頭。它共享主模型的 KV 快取和啟用值，不需要重新計算已有上下文，因此無論是操作上還是架構上都遠比 DIY 配對更高效。無需尋找相容模型，沒有分佈漂移，也不必額外維護第二個模型，輸出質量零下降的同時推理速度最高可提升 3 倍。

在作者看來，平坦延遲是所有 transformer 架構 LLM 與生俱來的結構性問題，投機解碼是當前最具意義的體系性答案。Gemma 4 則是第一個把這種能力作為原生特性廣泛交付的模型，而不是需要使用者自行拼裝的實驗專案。不過這只是第一步，更深層的挑戰——如何讓模型根據任務實際難度動態分配算力——仍然懸而未決。遊戲還沒有結束，只是剛剛變得有趣。