使用 NVIDIA H100 為 Llama 2 70B 渦輪增壓

Perplexity 追求效能的動力，驅使我們採用 NVIDIA 和 AWS 所能提供的最新技術。在本篇部落格中，我們很高興能分享最新實驗的結果：比較 Llama 2 70B 在各種硬體與軟體設定下的推論表現。

我們的 LLM 推論平台 pplx-api 是建立在由開源函式庫所支援的尖端技術堆疊之上。自去年 10 月 pplx-api 公開測試以來，我們一直在處理擴充性方面的挑戰，並學習如何最佳化調整我們的組態以實現大規模擴充。這促使我們針對以下指導性問題進行了實驗：

在所有其他設定不變的情況下，將我們的 GPU 從 NVIDIA A100 切換至 NVIDIA H100，能獲得多少原始效能提升？

H100 原生支援的 8 位元浮點數 (fp8) 量化，能帶來多少效率提升？這種量化會產生多少精確度成本？

張量平行處理 (tensor parallelism) 和批次大小 (batch size) 如何影響延遲 (latency) 和權杖輸送量 (token throughput)？

綜上所述，哪種組態能在效能與成本效益之間取得最具擴充性的平衡？

實驗設定

我們將以下實驗作為一系列的本機基準測試來執行，以避免網路延遲。

關鍵指標：

延遲 (Latency)：推論伺服器產生完整回應所需的總時間。

輸送量 (Throughput)：推論伺服器在所有使用者和請求中，每 GPU 每秒能產生的輸出權杖數量。

常數：

以下因素會影響關鍵指標，因此我們在實驗的不同測試中保持這些因素的一致性。

AI 模型

效能會隨著 LLM 的規模而擴充。參數越多，所需的計算量就越大，進而導致推論變慢。例如，在其他設定相同的情況下，Llama 2 13B 比 Llama 2 70B 更快。我們在本實驗中堅持使用 Llama 2 70B，因為我們希望針對服務能力最強的開源模型進行最佳化。

輸入/輸出權杖資料集

每個範例請求/回應對中的輸入和輸出權杖數量可能會影響效能測量。一般而言，輸出權杖產生過程會主導整體回應時間。當取樣資料僅引發 LLM 的「是/否」回應時，相較於要求 LLM 撰寫論文的樣本，回應速度會更快。我們的資料集由合成請求組成，包含 1024 個輸入權杖，引發 512 個輸出權杖。選擇此分佈是為了符合我們觀察到的 Llama2 70B 公開部署流量分佈。

軟體版本

NVIDIA TensorRT-LLM (v0.5.0 版本) 是一個用於最佳化 LLM 推論的開源函式庫。它於 2023 年底發布，整合了 NVIDIA 的許多推論最佳化技術，並為本實驗的關鍵參數（批次大小、量化和張量平行處理）提供了靈活的自訂層。

變數

我們針對 4 個組態軸向進行了實驗：張量平行處理、GPU 架構、量化和最大批次大小。這些軸向彼此相關，因為它們各自代表了針對 GPU 記憶體這一關鍵瓶頸資源的取捨。

GPU 架構

第九代 Hopper (H100-HBM3-80GB / p5.48xlarge) GPU 架構相比前一代 Ampere (A100-SXM4-80GB / p4de.24xlarge) 具備 眾多 特色，包括 2 到 6 倍的計算速率和近乎 2 倍的 GPU 記憶體頻寬。GPU 記憶體頻寬是推論的關鍵指標，因為推論矩陣乘法的主要延遲瓶頸來自於將數 GB 的模型資料從 GPU 記憶體載入計算暫存器。基於這些統計數據，我們假設 NVIDIA H100 與 A100 的公平比較將在延遲和輸送量方面展現 2 倍的提升。

NVIDIA H100 與 A100 的另一個關鍵差異在於，H100 張量核心原生增加了對 8 位元浮點數 (fp8) 指令的支援，這為下方詳述的進一步最佳化開啟了大門。這就是我們特別針對 H100 使用 fp8 和 fp16 的原因。

為了保持本實驗中每個 GPU 的記憶體一致，我們堅持在 NVIDIA A100 和 H100 上都使用具備 8x80GB GPU 記憶體的節點。除了實現更高的批次大小外，GPU 記憶體之所以重要，是因為模型參數會在伺服器啟動期間載入 GPU 記憶體以供快速存取。例如，如果我們模型中的 700 億個參數每個都是 16 位元浮點數，則模型大小約為 140GB，這無法放入單一 GPU 中。因此需要張量平行處理，我們將在下方進行解釋。

張量平行處理 (Tensor Parallelism)

張量平行處理是指執行推論伺服器所消耗的 GPU 裝置數量。當我們分配一定數量的 GPU 時，TensorRT-LLM 會匯集它們的資源，協助我們達到執行 Llama2 70B 所需的最低記憶體預算。我們的假設是，與較高的張量平行處理相比，較低的張量平行處理會導致較高的延遲（因為用於滿足每個批次的資源較少），但每個 GPU 的輸送量會較高（因為利用率較好）。

量化

量化是降低類神經網路所使用權重和活化函數 (activations) 精確度的技術。當我們從 fp16 切換到 fp8 時，我們使用此技術將 GPU 記憶體消耗減半。這使得以更低的總 GPU 記憶體用量執行相同模型成為可能，從而實現更低的張量平行處理，進而提升輸送量。

量化的實作有降低精確度的可能性。因此，我們透過比較 WikiText 語料庫上的困惑度 (perplexity) 統計數據（衡量 LLM 預測句子中下一個權杖準確度的指標），來評估不同精確度的準確度。對於 8 位元浮點數和 8 位元權重搭配 8 位元活化函數與 SmoothQuant (w8a8 SQ)，與 WikiText 上的 fp16 相比，困惑度沒有顯著變化 (< 1%)，因此我們有信心繼續進行。然而，w4a16 在困惑度上表現出顯著的 7% 變化，這可能歸因於更低的精確度以及 int4 與 fp16 之間必要的動態轉換。

批次大小

透過批次處理實現平行化是從資源受限系統中榨取效能的經典策略。透過在類神經網路的每個前向傳遞中處理多個請求，批次處理已知能以犧牲部分延遲為代價來增加輸送量。批次處理還會導致更高的 GPU 記憶體消耗，因為管理注意力機制的 KV 快取大小會隨著批次大小線性成長。

放大

以 Llama 2 70B（擁有 80 層）為例，在 4096 背景大小下使用批次大小 32 的 fp16，KV 快取的大小高達 40 GB。這最終導致 Llama 2 70B fp16（僅權重就佔用了 140GB）無法舒適地放入張量平行處理 2 (TP-2) 下可用的 160GB GPU 記憶體中。

結果

我們掃描了實驗 4 個變數的相容組合，並在下方呈現最具啟發性的趨勢。

放大

當比較 H100 fp16 → fp8 以及 A100 fp16 → w8a8 (採用 SmoothQuant) 時，量化的延遲改進約為 10%。然而，與 fp16 相比，混合精確度 w4a16 在低批次大小下的表現實際上更好，但在高批次大小下的表現較差。這可能是由多種因素造成的，包括較少最佳化的計算核心、int4 與 fp16 之間的轉換時間，以及 w4a16 仍然使用 16 位元浮點數進行活化，導致 KV 快取的維度沒有節省空間。由於 w4a16 也表現出較低的準確度，我們得出結論：A100 應堅持使用 w8a8 SQ，而 H100 應使用 fp8。

放大

在我們的前兩張圖中，我們僅呈現 TP-8 的組態。當兩者都使用 fp16 / BS-128 / TP-8 時，H100 達到 A100 的 54% 延遲和 184% 輸送量；而當 H100 使用 fp8 時，這進一步改善為 49% 延遲和 202% 輸送量。這種效能提升可歸因於 H100 與 A100 之間計算能力和記憶體頻寬的增加。值得注意的是，在利用率可能較低的較小批次大小下，這種差異不太明顯。

隨著我們建立平台，我們希望在最大化輸送量的同時滿足使用者的特定延遲要求。因此，與其在相同批次大小下比較 A100 與 H100，我們比較兩者僅在滿足延遲要求的組態下的輸送量才更具意義。我們設定了完成 512 個輸出權杖的 25600ms 延遲上限，並發現 H100 / TP-8 / fp8 / BS-128 的輸送量是 A100 / TP-8 / fp16 / BS-64 的 251%，因為它能在更低的延遲下處理雙倍的批次大小。鑑於量化可節省 GPU 記憶體，我們現在需要評估張量平行處理如何增加下一層最佳化。

放大

在量化與架構方面，贏家顯而易見：H100 優於 A100，且低精確度量化改善了記憶體利用率、延遲和輸送量。然而，批次大小和張量平行處理在我們的關鍵指標中呈現取捨。較大的批次大小以增加延遲和記憶體消耗為代價來最佳化輸送量。另一方面，較高的張量平行處理增加了可用記憶體的總量並最佳化了延遲，但由於分散式矩陣乘法的同步成本，以及佔用了更多 GPU 資源，因此會在輸送量上做出取捨。

放大

我們實驗中最大化輸送量的組態是 H100 / fp8 / TP-2 / BS-128，達到每 GPU 每秒 767 個輸出權杖。這比 A100 / fp16 / TP-8 / BS-64 改善了 460%。然而，它的代價是延遲加倍（512 個輸出權杖約為 42000ms），因此它可能不適合作為生產組態。TP-4 BS-128（626 tok/sec/gpu，回應時間為 26188ms）和 TP-2 BS-32（435 tok/sec/gpu，回應時間為 18821ms）的結果可能在我們的關鍵指標上代表了更好的折衷方案。

結論

我們的結果顯示：

在相同組態下，使用 H100 相比 A100 可達到 54% 的延遲和 184% 的輸送量；而當 H100 利用其對 fp8 的原生支援時，數據更進一步改善至 49% 和 202%。

在符合延遲限制的前提下最大化輸送量時，H100 / fp8 / TP-8 / BS-128 可達到 A100 / fp16 / TP-8 / BS-64 的 251% 輸送量，因為它能以更快的速度處理雙倍的批次。

利用 H100 搭配 TP-2 與 fp8，我們可以達到 A100 / fp16 / TP-8 / BS-128 的 373% 輸送量，且延遲增加不到 10%。

對於 LLM 推論系統的營運商而言，批次大小與張量平行處理在輸送量與延遲之間呈現取捨關係。

這些結果使我們對在先前採用 A100 的硬體堆疊中全面轉換至 H100 GPU 充滿信心。我們很高興能證實 NVIDIA 所宣稱的效能提升，並期待他們在加速硬體方面的下一項突破。

下一步

我們最佳化的下一個領域是檢驗 結構化稀疏性 (structured sparsity) 和 int4 精確度對準確度和效能的影響，這可能會顯著降低 Llama 2 70B 的 GPU 記憶體佔用空間，並帶來高達 2 倍的延遲改善。我們很興奮能繼續這趟極速推論之旅，並希望能賦能使用者在我們的平台上建構強大的應用程式。

在短期內，pplx-api 將解除速率限制並提供更多自訂的 Perplexity LLM，包括一個具備事實基礎且由網際網路驅動的 LLM。

請至 perplexity.ai/pro 註冊 Perplexity Pro。取得我們尖端的 pplx-api 存取權限，並在您的專案中運用這些進階功能。在我們的 部落格 上了解更多關於 pplx-api 的資訊。

對形塑 AI 的未來感興趣嗎？我們正在招募！加入致力於大規模生成式 LLM 基礎建設的團隊。前往 Perplexity Careers 探索機會。

作者：

Aarash Heydari, Grigorii Alekseev, Kevin Hu, Denis Yarats