開源社區(qū)的一位開發(fā)者Georgi Gerganov發(fā)現(xiàn)，自己可以在M2 Ultra上運行全F16精度的34B Code Llama模型，而且推理速度超過了20 token/s。

畢竟，M2 Ultra的帶寬有800GB/s。其他人通常需要4個高端GPU才能做到！

而這背后真正的答案是：投機采樣（Speculative Sampling）。

Georgi的這一發(fā)現(xiàn)，瞬間引爆AI圈大佬的討論。

Karpathy轉(zhuǎn)發(fā)評論道，「LLM的投機執(zhí)行是一種出色的推理時間優(yōu)化」。

「投機采樣」加速推理

在這個例子中，Georgi借助Q4 7B quantum草稿模型（也就是Code Llama 7B）進行了投機解碼，然后在M2 Ultra上使用Code Llama34B進行生成。

簡單講，就是用一個「小模型」做草稿，然后用「大模型」來檢查修正，以此加速整個過程。

GitHub地址：https://twitter.com/ggerganov/status/1697262700165013689

根據(jù)Georgi介紹，這些模型的速度分別為：

- F16 34B：~10 token/s

- Q4 7B：~80 token/s

如下是沒有使用投機采樣，標準F16采樣示例：

然而，加入了投機采樣策略后，速度可達~20 token/s。

Georgi表示，當然，速度會因生成的內(nèi)容而異。但這種方法在代碼生成方面似乎效果很好，因為大多數(shù)詞庫都能被草稿模型正確猜出。

如果使用「語法采樣」的用例也可能從中受益匪淺。

投機采樣能夠?qū)崿F(xiàn)快速推理的背后具體如何實現(xiàn)？

Karpathy根據(jù)此前谷歌大腦、UC伯克利、DeepMind的三項研究，做出了解釋。

論文地址：https://arxiv.org/pdf/2211.17192.pdf

論文地址：https://arxiv.org/pdf/1811.03115.pdf

論文地址：https://arxiv.org/pdf/2302.01318.pdf

這取決于以下不直觀的觀察結(jié)果：

在單個輸入token上轉(zhuǎn)發(fā)LLM所需的時間，與在K個輸入token上批量轉(zhuǎn)發(fā)LLM所需的時間相同（K比你想象的要大）。

這個不直觀的事實是因為采樣受到內(nèi)存的嚴重限制，大部分「工作」不計算，而是將Transformer的權(quán)重從VRAM讀取到芯片上緩存中進行處理。

因此，如果要完成讀取所有權(quán)重的工作，還不如將它們應(yīng)用到整批輸入向量中。、

我們之所以不能天真地利用這一事實，來一次采樣K個token，是因為每N個token都取決于，我們在第N-1步時采樣的token。這是一種串行依賴關(guān)系，因此基線實現(xiàn)只是從左到右逐個進行。

現(xiàn)在，巧妙的想法是使用一個小而廉價的草稿模型，首先生成一個由K個token組成的候選序列——「草稿」。然后，我們將所有這些信息一起批量送入大模型。

根據(jù)上述方法，這與只輸入一個token的速度幾乎一樣快。

然后，我們從左到右檢查模型，以及樣本token預(yù)測的logits。任何與草稿一致的樣本都允許我們立即跳轉(zhuǎn)到下一個token。

如果有分歧，我們就會扔掉草稿模型，承擔做一些一次性工作的成本（對草稿模型進行采樣，并對后面的token進行前向傳遞）。

這在實踐中行之有效的原因是，大多數(shù)情況下，draft token都會被接受，因為是簡單的token，所以即使是更小的草稿模型也能接受它們。

當這些簡單的token被接受時，我們就會跳過這些部分。大模型不同意的困難token會「回落」到原始速度，但實際上因為有額外的工作會慢一些。

所以，總而言之：這一怪招之所以管用，是因為LLM在推理時是受內(nèi)存限制。在「批大小為1」的情況下，對感興趣的單個序列進行采樣，而大部分「本地 LLM」用例都屬于這種情況。而且，大多數(shù)token都很「簡單」。

HuggingFace的聯(lián)合創(chuàng)始人表示，340億參數(shù)的模型在一年半以前的數(shù)據(jù)中心之外，看起來非常龐大和難以管理。現(xiàn)在是筆記本就可以搞定了。

現(xiàn)在的LLM并不是單點突破，而是需要多個重要組件有效協(xié)同工作的系統(tǒng)。投機解碼就是一個很好的例子，可以幫助我們從系統(tǒng)的角度進行思考。