Llama-2-70B 是一個具吸引力、可作為 GPT-3.5 替代方案的選擇，但如果你在尋找低成本的語言模型，可能不值得偏離 OpenAI 的 API。

在考量價格與延遲時：

不應將 Llama‑2 用於以補全為主的工作負載

相較之下，Llama 更適合由提示詞主導的任務，例如分類。以下情況下，使用 Llama-2 也可能合適：

1. 你的工作負載沒有提示詞 tokens（這聽起來不直覺，但我們稍後會解釋）
2. 您正在執行批次處理任務

否則，GPT-3.5 應該更便宜、速度也更快。

先說明一下，選擇使用 Llama 而非 GPT-3.5 的一個理由是微調能力。不過在這篇文章中，我們只探討成本與延遲。我沒有把 Llama‑2 與 GPT‑4 做比較，因為它更接近 3.5 等級的模型。基準測試結果也證實了這點：

我將在延遲大致相近的前提下，透過比較提供 Llama-2-70B 與 GPT-3.5-turbo 的服務成本，來證明這些論點。我們在兩張 80GB 的 A100 GPU 上部署 Llama，因為這是將 Llama 放入記憶體（以 16 位元精度）所需的最低配置 3。

在 2 張 A100 顯卡上，我們發現 Llama 在完成 tokens 的價格劣於 GPT-3.5。我們推測在 8 張 A100 上可能具備價格競爭力，但代價是不可接受的高延遲。

另一方面，就提示詞 tokens 而言，Llama 的成本比 GPT-3.5 低超過 3 倍。

Transformer 數學概論

透過一些簡單的數學推導，我們將針對 Llama‑2 說明以下結論。對於序列長度為$N$、批次大小為$B$的情況：

$140$源自模型參數數量的兩倍，而 320 KB/s 則是透過一些運算推得。下一節將說明我們如何得到這些數值。

還有其他論文與（或）部落格文章對 transformer 數學有極好的解說。就推論而言，Kipply 的文章是很好的參考。我也認為，是 Scaling Laws 普及了用於計算 transformer FLOPs 的簡化公式。

為了驗證這些數字，我們先從 Llama 的架構細節開始。隱藏維度為 4096、注意力頭數為 64、層數為 80，每個注意力頭的維度為 128：

計算 model FLOPs

一次前向傳播所需的 FLOPs 數約為$≈2P$，其中$P$為模型的參數數量。在我們的模型中，每個參數都屬於某個權重矩陣$M∈R^{m×n}$；對於每個輸入權杖，每個矩陣都會與表示該權杖的向量執行一次矩陣乘法。

對於每個$M$，我們在左側以維度為$x$的向量$m$相乘。該向量與矩陣的乘法需要的總 FLOPs 為$2mn 6$，亦即權重矩陣中項目數的 2 倍。Transformer 所有權重矩陣中的項目總數即為參數總數$P$，因此（不含注意力機制）總 FLOPs 為$2P$。

對於像 Llama 這樣的大型模型，在（相對）較短序列的情況下，注意力機制對 FLOPs 的貢獻可忽略不計。對於每一層與每個注意力頭，其注意力運算為：

$Q^TK$需要將一個$d_{head}$向量乘上一個$d^{head}×N$矩陣，計算量為$2dheadN$FLOPs。縮放因子與 Softmax 可忽略不計。最後，將 Attention 向量與$V$相乘需額外$2d_{head}N$FLOPs。對所有 attention head 與層加總後得到$4⋅d_{model}⋅nl⋅N=1.3⋅N$MFLOPs。因此，對於我們最長的 8192 序列，attention 仍僅占整體 140 GFLOPs 中的 10.5 GFLOPs。其占比足夠小，為簡化起見可忽略。

完成補全的記憶體需求高於提示詞

在產生 tokens 時，我們需要為每個權杖重新讀取整個模型的權重以及 KV-cache。這是什麼意思？為了進行任何矩陣乘法，我們需要將各個矩陣的權重從 RAM 載入到 GPU 的暫存器中。當獨立的矩陣足夠多時，實際載入權重會成為瓶頸，而非矩陣乘法本身。因此，讓我們比較一下在提示詞與補全中，權杖在模型中的處理路徑。

使用 Transformer 產生 tokens 的記憶路徑

為了說明這點，我們可以沿著（非常粗略勾勒的）一個簡單的單層 transformer 在產生一批 tokens 時所走的流程來看：

1. 我們讀取輸入的嵌入矩陣，$W_e$，並為批次中的每個輸入計算對應的嵌入向量。
2. 我們從記憶體讀取各個$W_q,W_k,W_v$矩陣，為批次中的每個輸入計算$q_i,k_i,v_i$（向量）。
3. 我們執行注意力運算——需要讀取快取的鍵與值。這會為每個輸入產生一個向量。
4. 我們從記憶體讀取$W_o$，並與前一步的輸出相乘
5. 我們讀取步驟 1 的輸出並將其加到步驟 4 的輸出上，接著執行 LayerNorm。
6. 讀取$W_{ff_1}$並相乘，得到第一個前饋層的輸出。
7. 我們讀取$W_{ff_2}$並相乘，得到第二個前饋層的輸出。
8. 我們讀取第 5 步的輸出並將其加到第 7 步的輸出中，然後執行層正規化（layer norm）。
9. 我們讀取反嵌入層，$W_{e}^{T}$接著進行矩陣與矩陣相乘，得到批次中每個輸入的權杖對數機率。
10. 我們抽樣下一個權杖，並將其回傳至步驟 1。

來盤點記憶體需求。於步驟 1、2、4、6、7 與 9，我們大致各讀取一次模型的所有參數；在步驟 3，會讀取每個批次元素的 KV 快取；各步驟中還會讀取與模型大小相比可忽略的中介啟動值。因此，記憶體頻寬需求為 Model Weights + KV Cache。當我們增加批次大小時，除 KV 快取外，記憶體需求大致維持不變！稍後我們會再談到這點。請注意，這是每個 token

在 Transformer 中處理提示詞 tokens 的記憶路徑

在處理提示詞時，我們只需讀取一次整個模型的權重，但會承受注意力機制的記憶體開銷。請考慮一批序列通過同一個 transformer 的大致流程：

1. 我們讀取輸入的嵌入矩陣 We，並為批次中的每個序列計算相應的嵌入矩陣。
2. 我們從記憶體讀取各個$W_q,W_k,W_v$矩陣，以計算$Q_i,K_i,V_i$（皆為矩陣）
3. 我們執行注意力機制
4. 我們從記憶體讀取 Wo，並與前一步的輸出相乘
5. 讀取步驟 1 的輸出，將其與步驟 4 的輸出相加，然後執行層正規化（LayerNorm）
6. 我們讀取$W_{ff_1}$並相乘，得到第一個前饋層的輸出
7. 讀取$W_{ff_2}$並相乘，得到第二個前饋層的輸出
8. 我們讀取第 5 步的輸出，將其加入第 7 步的輸出，然後執行 LayerNorm
9. 我們讀取反嵌入層$W_u=W_{e}^{T}$，然後相乘以取得提示詞序列的權杖對數機率（logprobs）

在步驟 1、2、4、6、7 中，我們會讀取模型的所有參數。在步驟 3，我們執行 attention 運算；使用 FlashAttention 時，對於合理長度的序列與批次大小，其所需的記憶體頻寬遠低於讀取模型權重。在所有步驟中，我們都會讀取 activations，這些矩陣相較於模型大小可忽略不計（同樣適用於合理長度的序列與／或批次）。請注意，這是對所有 tokens的記憶體需求。

重點是：在處理提示詞時，每個權杖所需的記憶體明顯少於在產生 tokens 時，因為對於提示詞，我們會在序列維度上對矩陣乘法進行批次運算！

模型權重所需的記憶體頻寬

使用 16 位元精度的模型權重會占用$2⋅70=140$GB 記憶體。

KV 快取所需的記憶體頻寬

我們的 KV 快取大小，指的是神經網路中所有層、所有 head 針對先前所有 tokens 的所有 key 與 value 的總大小；換算下來，每個 token 與每個批次元素約需 320 MB。

Llama 2 決定移除多頭注意力（multi-head attention）。不過，他們並未改用多查詢注意力（multi-query attention），而是採用分組查詢注意力（grouped query attention），以提升效能。如此一來，鍵與值使用 8 個 head（或群組），$ng$多頭注意力常見的 128 個，或多查詢注意力的 1 個。

對於$N$tokens，我們的 KV 快取大小為$2 n_g n_l d_{\text{head}} N = 1.6 N \cdot 10^5$。使用 16 位元精度，則為$320N$KB。給定批次大小$B$，則為$320⋅NB$KB。

對於補全，這表示每個權杖的記憶體需求為：

對於較短的序列／小批次，第一項佔主導；否則第二項會大得多。不過，由於我們只有 160 GB 記憶體且模型佔用 140 GB，在我們的實驗中，KV 快取會對記憶體頻寬帶來些微的開銷。

提示詞的記憶體頻寬約為：

通訊開銷

為求簡化，我們忽略通訊成本，因為將模型並行納入考量會讓問題大幅複雜化。我們可以合理假設，其帶來的額外延遲不足以顯著影響我們的任何計算（尤其是因為我們只把 Llama 分拆到 2 張 GPU 上）。

提示詞處理成本相當低

提示詞處理，或稱首個權杖時間（time to first token），是 Transformer 推論中效率最高的部分，且相較於 GPT-3.5，你應可預期價格將降低約三分之一。

對於具有$P$個參數且提示詞長度為$N$的模型，處理一個提示詞所需的記憶體約為$2P$位元組，計算量為$2PN$FLOPs。由於 A100 可進行 312 TFLOPs 的矩陣乘法（matmul）並提供 2 TB/s 的記憶體頻寬，當序列長度 N>156 時，我們將受限於計算能力。 9

在 A100 上，FLOPs 利用率通常會在略低於 70% 的 MFU 封頂，約為 200 TFLOPs。2 張 80 GB 的 A100 成本約為每小時 $4.42，折合每秒約 $0.0012。Llama 的 FLOPs 需求為 140 TFLOPs/token。根據 2 張 A100 的總 FLOPs，我們可以推算每秒可處理的 tokens 數量如下：

價格為：

$0.00042／每 1K tokens

相較於 GPT-3.5 的 $0.0015，這根本是超值！更精確地說，價格幾乎降了 4 倍！

延遲表現也相當不錯！在我們使用 2 張 GPU、批次大小為 1 的設定下，我們應能在 170ms 內處理 512 tokens，並在 530ms 內處理 1536 tokens。

我們以實際數據驗證這些主張。我們使用 Hugging Face 的 text-generation-inference repo 的內部分支來衡量 Llama‑2 的成本與延遲。

如我們所見，價格明顯優於 GPT-3.5 的 $0.0015/每 1k tokens！看起來在較長序列的首個 token 輸出時間上我們稍有落後，不過解法相當直接。將 Llama 的併行從跨 2 個 GPT 擴增到跨 8 個 GPT，幾乎可帶來 4 倍加速，這代表 Llama-2 在提示詞表現上全面勝過 GPT-3.5！

產生 tokens 的速度很慢且成本極高

理論上，在補全任務上有可能達到與 GPT-3.5 相近的競爭性定價，但實際上你多半會更吃虧。

在產生 tokens 時，系統會從計算受限轉為記憶體受限。11. 假設批次大小為 1，來估算可達到的吞吐量。

每張 80 GB 的 A100 其記憶體峰值頻寬為每個 GPU 2 TB/s。不過，與 FLOPs 利用率類似，在推論工作負載中實際表現通常只有約 60–70%（約 1.3 TB/s）。由於在小批次下 KV 快取幾乎可忽略，我們在兩張 A100 上的吞吐量將為：

我們的新價格差多了。以 $0.0012/秒 計算，我們的成本是……

$0.066 / 每 1K tokens

以 GPT-3.5 等級的模型來說，這樣的價格與速度實在糟糕！但別忘了先前提到的批次大小注意事項。我們目前受限於記憶體瓶頸，因此可以在不影響生成速度的情況下提高批次大小。批次越大，成本越低。

我們無法將其無限放大，因為 KV 快取最終會占滿所有 GPU 記憶體。所幸，分組查詢注意力（grouped-query attention）能緩解此問題。對於 N tokens、批次大小為$B$，且為 16 位元精度時，我們的快取大小為$3.2⋅N⋅B⋅105$位元組（Bytes）。在 4096 tokens 的情況下，批次大小為 1 時相當於 1.3 GB 記憶體。我們的 2×A100 機器共有 160 GB 空間。模型占用其中 135 GB，僅剩 25 GB 可供 KV 快取使用。由於記憶體儲存上的額外效率損耗，對於較長序列長度時，我們的最大批次大小約為 8。

在（約）8 倍速度提升的情況下，我們可預期價格為$0.00825 / 每 1K tokens。這仍不如 GPT-3.5-turbo 有利，但已更接近。對於較短的序列長度（總計 1K tokens），我們應可將批次大小提高到 32，價格則為$0.00206 / 每 1K tokens。理論上，這與 GPT-3.5-turbo 具有競爭力。

另一種做法是增加 GPU 數量。租用 8 張 80 GB 的 A100，可得到 1.28TB 記憶體。扣除模型權重後，剩餘超過 1TB 的記憶體可用於 KV 快取，表示可支援批次大小大於 512 個 tokens。請注意，我們實際上不會看到成本下降 512 倍，因為 KV 快取現在占用的記憶體頻寬是模型大小的 8 倍，因此更接近成本下降 64 倍。

增加運算資源也能解決延遲問題。GPT-3.5 約可達 70 TPS。將 model 從 2 張 GPU 拆分至 8 張，應可達到約 74.4 tokens/s。

在進行這項實驗時，我們無法使用 8 張 A100，不過先來看看使用兩張 80GB A100 時的數據：

實測生成效能

就記憶體頻寬的計算而論，這些數字大致符合預期。

如我們所見，增加批次大小會讓每 1K tokens 的成本幾乎線性下降。不過，我們的價格仍與 GPT-3.5 的 $0.002/1K tokens 有一段差距——尤其是在較長序列長度時。

大型批次會帶來難以接受的延遲

以大型批次執行生成可達到與 GPT-3.5 相近的競爭性定價，但會拉長首個權杖出現的時間。隨著我們增加批次大小，成本會線性下降，但首個權杖出現的時間也會線性增加。

將批次大小設為 64，定價就能優於 GPT-4。不過，批次大小為 64 也會帶來：

• 首個 tokens 產生時間接近3 秒，而且只用了 512 tokens！
• 以 3596 tokens 為例，批次大小 64 的處理時間為20.1 秒。

因此，相較於 OpenAI 的 API，適合採用 Llama‑2 的工作負載類型包括：

1. 提示詞很長，但幾乎沒有生成任何 tokens —— 處理純提示詞其實相當簡單。
2. 在提示詞極少甚至沒有的情況下產生 tokens —— 我們可將批次大小調整至 >64，並在不增加延遲的前提下，達到可與 GPT-3.5-turbo 價格相媲美的水準。
3. 對延遲不敏感的離線批次處理作業。

要提高批次大小，前提是要有穩定且龐大的工作負載，但多數新創公司並不具備！對大多數使用者與多數工作負載而言，使用量往往高度突發。當然，一個可行的方案是對按需 GPU 進行 Auto 自動擴縮（可向上/向下擴展），但即便如此，平均來看你大概只能期望每張 GPU 達到最大吞吐量的 50%——尤其還要考量冷啟動時間。

我們建議：提示詞密集的任務使用開源模型，而將生成密集的任務交給如 GPT-3.5 這類的閉源模型。

量化（Quantization）

大多數量化方法都是有損的，這意味著會有一些效能下降。我們很可能透過 8 位元量化達到大致具競爭力的效能，並讓所有估算數字的價格降低一半！量化與不完美的資源使用率大致相互抵消，也就是說，同時考量兩者後，我們預期價格將與我們’的實測結果相近！

然而，多數開源量化方法的目標，是讓模型能在少量／小型的消費級 GPU 上輕鬆部署，而非追求在大規模環境中的最佳吞吐量。

有多個開源程式庫能在維持效能的同時，進一步將量化精度降低。不過，這些程式庫的優化重點是讓模型能在少量／小型、非資料中心的 GPU 上提供服務，而非追求大規模的吞吐量。更具體地說，它們針對低批次推論情境進行優化（主要是批次大小為 1）。即使在最佳情況下能提供 3–4 倍的加速，換算後的成本仍約為每 1K tokens 收費 $0.017。

位元與位元組

Bits and Bytes 提供（實質上）無失真量化，意即效能幾乎無差異。不過，它的主要優勢在於降低記憶體用量，而非提升速度。以近期的 NF4 表示法為例，其加速僅體現在矩陣乘法（matmul）速度上，而非推論吞吐量。就實證來看，大家似乎並未在這方面量到明顯的加速。

其在更大批次上的擴展表現仍不明確。

Llama.cpp

我認為 Llama.cpp 主要對 Apple 硬體做了最佳化。他們也支援 CUDA，並支援用於推論的快速 4 位元精度，但我懷疑在這裡採用過於單純的量化會讓效能顯著下滑。

此外，此函式庫也針對小批量場景進行了最佳化。

GPT‑Q

GPT-Q 是另一個量化庫。我還沒測試過 GPT-Q，但打算稍後進行。希望我們能在這方面看到價格減半！

再度強調，該實作已針對低批次情境進行最佳化。此外，論文中所報告的 >3 倍加速僅適用於 3 位元量化，而這對我們的使用情境而言誤差過大。

封閉原始碼的模型究竟為何更便宜？

封閉原始碼的模型有多種方法可大幅加速推理

量化（Quantization）

如前所述，有多種穩健的開源量化方法，但我懷疑 OpenAI 的量化實作在大型批次處理上的最佳化更到位。

專家混合模型（Mixture of Experts）

普遍認為 GPT-4 採用了「專家混合」（Mixture of Experts, MOE）15。若 GPT-3.5-turbo 也採用 MOE，則在相同效能水準下，你可以部署一個小得多（因此更快）的模型

預測式取樣

推測式取樣是另一個有趣的技巧，透過讓較小的模型連續預先草擬多個 tokens，來繞過語言模型緩慢的解碼時間。請注意，在極限情況下，這不會帶來顯著的throughput提升，但能大幅降低延遲。供參考，這個repo實作了它的簡化版本。

大規模推論的巧妙技巧

在大規模執行推理時，OpenAI 很可能會採用一些進階做法，例如先配置多個 8-GPU 節點來為一批請求進行預填（prefill），再配置單個 8-GPU 節點為該批請求生成 tokens。這讓他們能兼得兩者優勢：既能使用大於 64 的批次大小，又能維持極低的首個 token 輸出延遲。

結語

我們已將這些發現用於指導我們在 Anysphere 何時與如何採用開源模型的決策。

總而言之，我們發現對於分類或重新排序（reranking）

加入 Anysphere，和我們一起打造未來！

我們正在打造Cursor——一款以 AI（人工智慧）為先的程式碼編輯器。當我們從根本上重新想像開發環境時，能處理許多極具挑戰且有趣的問題。比如，以 OpenAI 的 API 價格的一小部分來微調並提供模型服務；或設計全新抽象，以便透過 OpenAI 的 API 建立複雜的鏈與 Agents。

我們是總部位於舊金山、由 OpenAI 支持的 9 人小型團隊。若有興趣，歡迎來信至hiring@anysphere.co。

或者，如果你想聊聊語言模型，歡迎在Twitter私訊我。

附錄

以下是關於 Llama‑2‑70B 延遲的測量資料點表格，以及一些額外的計算後指標