「如今，LLM(大語言模型)并不是單點突破的 —— 而是需要多個重要組件有效協同工作的系統。Speculative decoding 是幫助我們從系統角度思考的一個很好的例子。」愛丁堡大學博士生符堯表示道。

圖片來自網絡/侵刪

　　符堯上述觀點評論的是特斯拉前 AI 總監、年初重回 OpenAI 的 Andrej Karpathy 剛剛發布的一條推特。

　　人形機器人公司 1X Technologies 的 AI 副總裁 Eric Jang 評價道：「Karpathy 很好的解釋了 LLM 的 speculative execution。其他自回歸模型可能會以類似的方式加速。連續(擴散)模型可能從 K 步中獲益較少(可能在第 1 步后偏離猜測)，但可以將其應用于 VQ-latents 的離散代碼。」

圖片來自網絡/侵刪

　　看完上述評價，我們大概也了解了，Karpathy 說的「Speculative execution」，這是優化技術的一類，采用這個技術的計算機系統會根據現有信息，利用空轉時間提前執行一些將來可能用得上，也可能用不上的指令。如果指令執行完成后發現用不上，系統會拋棄計算結果，并回退執行期間造成的副作用(如緩存)。

　　為了讓大家更好的理解 Karpathy 的內容。我們先介紹一下「Speculative decoding」方法，對后續理解更加有益，其主要用于加速大模型的推理。據了解，GPT-4 泄密報告也提到了 OpenAI 線上模型推理使用了它(不確定是否 100%)。

　　關于「Speculative decoding」，已有幾篇重要文獻可供參考，這也是 Karpathy 為了寫這則推特所參考的論文，包括谷歌今年 1 月發表的論文《Fast Inference from Transformers via Speculative Decoding》、DeepMind 今年 2 月發表的論文《Accelerating Large Language Model Decoding with Speculative Sampling》，以及谷歌等機構 2018 年的論文《Blockwise Parallel Decoding for Deep Autoregressive Models 》 。

　　簡單來說，「Speculative decoding」使用兩個模型：一個是原始目標模型稱為大模型，另一個是比原始模型小得多的近似模型稱為小模型。主要思想是先讓小模型提前解碼多個 token 進行猜測，并將它們作為單個 batch 輸入到一個大模型中進行審核修正，其效果和直接用大模型解碼等價。如果小模型猜測的不準確，那么大型模型會放棄小模型預測的 token，繼續使用大型模型進行解碼。

　　由于小模型計算量小，從而大大減少了內存訪問需求。

　　介紹完「Speculative decoding」，我們再回到 Karpathy 的推特。Karpathy 是針對下面內容回復的。

　　Karpathy 表示：對于 LLM 來說，「Speculative execution」 是一種極好的推理 — 時間優化方法。

　　它取決于以下方面：在單個輸入 token 上分發 LLM 所花費的時間與在批處理中分發 K 個輸入 token 所花費的時間一樣多。產生這樣的原因是因為采樣嚴重受內存限制：模型運行時的大部分工作不是在做計算，而是從 VRAM 讀取 transformer 的權重到片上緩存進行處理。如果你要做的工作是來讀取這些權值，你可以把它們應用到一整批輸入向量上。

　　但是我們不能一次性采樣一批 K 個 token，因為每 N 個 token 都取決于我們在第 N-1 步采樣的 token。由于存在串行依賴性，因此基線實現只是從左到右逐一進行。

　　現在最聰明的想法是使用一個小而便宜的草稿模型(draft model)，先生成 K 個 token 候選序列，即一個「草稿」。然后用大模型批量的將輸入組合在一起。速度幾乎與僅輸入一個 token 一樣快。接著從左到右遍歷模型和樣本 token 預測的 logits。任何與「草稿」一致的樣本都允許立即跳到下一個 token。如果存在分歧，那么就丟棄「草稿」并承擔一些一次性工作的成本(對「草稿」進行采樣并為所有后續 token 進行前向傳遞)。

　　這種方法起作用的原因在于，很多「草稿」token 都會被接受，因為它們很容易，所以即使是更小的草稿模型也能得到它們。當這些簡單的 token 被接受時，我們會跳過這些部分。大模型不同意的 hard token 會回落到原始速度，但由于一些額外的工作，實際上速度會慢一些。

　　Karpathy 表示，這個奇怪的技巧之所以有效，是因為 LLM 在推理時受到內存限制，在對單個序列進行采樣的 batch size=1 設置中，很大一部分本地 LLM 用例都屬于這種情況。因為大多數 token 都很「簡單」。
　　（邯鄲小程序）