不用4個H100！340億參數Code Llama在Mac可跑，每秒20個token，程式碼產生最拿手

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

M2 Ultra的頻寬達到了800GB/s，這在其他人通常需要使用4個高階GPU才能實現的情況下

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

喬治的發現立刻引發了人工智慧界大佬們的討論

#Karpathy轉發評論道，「LLM的投機執行是一種出色的推理時間優化」。

「投機取樣」加速推理

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

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

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

根據Georgi的介紹，這些模型的速度分別如下：

F16 34B：每秒約10個令牌

需要進行改寫的內容是：Q4 7B：每秒約80個令牌

##以下是一個沒有使用投機取樣的標準F16取樣範例：

在加入投機取樣策略之後，速度可以達到每秒約20個標記

根據Georgi的說法，產生內容的速度可能會有所不同。然而，這種方法在程式碼產生方面似乎非常有效，因為大多數詞庫都能被草稿模型正確猜測

#使用「語法取樣」的用例也有可能從中受益匪淺

投機取樣是如何實現快速推理的？

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

請點擊以下連結查看論文：https://arxiv.org/pdf/2211.17192.pdf

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

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

這取決於以下不直觀的觀察結果：

在單一輸入token上轉發LLM所需的時間，與在K個輸入token上批量轉發LLM所需的時間相同（K比你想像的要大）。

這個不直覺的事實是因為取樣受到記憶體的嚴重限制，大部分「工作」不計算，而是將Transformer的權重從VRAM讀取到晶片上快取進行處理。

#

為了完成讀取所有權重的任務，最好將它們應用於整個批次的輸入向量

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

現在，一個巧妙的想法是使用一個小而便宜的草稿模型，首先產生一個由K個標記組成的候選序列－「草稿」。然後，我們將所有這些資訊一起批次送入大模型

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

然後，我們從左到右檢查模型，以及樣本token預測的logits。任何與草稿一致的樣本都允許我們立即跳到下一個token。

如果存在分歧，我們將放棄草稿模型，並承擔進行一些一次性工作的成本（對草稿模型進行採樣，並對後續的標記進行前向傳遞）

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

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

所以，總而言之：這怪招之所以管用，是因為LLM在推理時是受記憶體限制。在「批次大小為1」的情況下，對感興趣的單一序列進行取樣，而大部分「本地 LLM」用例都屬於這種情況。而且，大多數token都很「簡單」。

HuggingFace的共同創辦人表示，340億參數的模型在一年半以前的資料中心之外，看起來非常龐大且難以管理。現在只需使用筆記型電腦就可以輕鬆處理了

#現在的LLM並不是單點突破，而是需要多個重要元件有效協同工作的系統。投機解碼就是一個很好的例子，可以幫助我們從系統的角度思考。

#

以上是不用4個H100！340億參數Code Llama在Mac可跑，每秒20個token，程式碼產生最拿手的詳細內容。更多資訊請關注PHP中文網其他相關文章！