使用 NVIDIA H100 為 Llama 2 70B 提速

Perplexity 嘅答案引擎對效能嘅追求，推動我哋採用 NVIDIA 同 AWS 所提供嘅最新技術。喺呢篇網誌中，我哋好高興同大家分享最新實驗嘅結果：喺唔同嘅硬件同軟件設定下對 Llama 2 70B 推理進行嘅比較。

我哋嘅 LLM 推理平台 pplx-api 係建基於由開源程式庫支援嘅先進技術疊層上。自從 pplx-api 喺 10 月開始公開測試以嚟，我哋一直喺度應付規模擴展嘅挑戰，並學習如何最好咁調整我哋嘅組態以實現大規模擴展。呢個促使我哋帶住以下嘅引導問題嚟進行實驗：

喺所有其他設定保持唔變嘅情況下，將我哋嘅 GPU 由 NVIDIA A100 切換到 NVIDIA H100 所帶嚟嘅原始效能提升係幾多？

H100 新增原生支援嘅 8 位元浮點數 (fp8) 量化，其效率提升係幾多？呢種量化嘅準確度成本係幾多？

張量平行同批次大小會點樣影響延遲同權杖輸送量？

綜合以上各點，邊個組態可以喺效能同成本效益之間取得最具可擴展性嘅平衡？

我哋將以下實驗作為一系列本地基準測試嚟運行，以避免網絡延遲。

延遲：推理伺服器生成其完整回應所需嘅總時間。

輸送量：推理伺服器喺所有用戶同請求中，每秒、每個 GPU 可以生成嘅輸出權杖數量。

以下因素會影響關鍵指標，因此我哋喺實驗嘅唔同試驗中保持呢啲因素一致。

效能隨 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 記憶體呢個關鍵樽頸資源嘅取捨。

第九代 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 記憶體中以便快速存取。例如，如果我哋模型中嘅 70 億個參數每一個都係 16 位元浮點數，咁呢個模型嘅大小大約係 140GB，無法容納在單個 GPU 上。因此需要張量平行，我哋將在下文解釋。

張量平行係指用於運行推理伺服器嘅 GPU 裝置數量。當我哋分配一定數量嘅 GPU 時，TensorRT-LLM 會將佢哋嘅資源池化在一起，以幫助我哋達到運行 Llama2 70B 所需嘅最低記憶體預算。我哋嘅假設係，與較高嘅張量平行相比，較低嘅張量平行會導致較高嘅延遲（由於消耗較少嘅資源嚟滿足每個批次），但由於更好嘅利用率，每個 GPU 嘅輸送量會更高。

量化係減少神經網絡所使用嘅權重同激發中精確度嘅過程。當我哋從 fp16 切換到 fp8 時，我哋使用呢種技術嚟將 GPU 記憶體消耗減半。呢個使得以更低嘅總 GPU 記憶體使用量運行相同模型成為可能，從而實現更低嘅張量平行，進而提升輸送量。

量化嘅實現有可能降低準確度。因此，我哋通過比較喺 WikiText 語料庫上嘅困惑度統計數據（衡量 LLM 預測句子中每個下一個權Token準確程度嘅指標），評估咗不同精確度嘅準確度。對於 8 位元浮點數同具有 8 位元激發及 SmoothQuant (w8a8 SQ) 嘅 8 位元權重，與 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 個變數嘅兼容組合，並喺下面呈獻最具啟發性嘅趨勢。

圖 1 - 具有唔同批次大小嘅請求喺五種唔同組態下嘅延遲，全部採用張量平行 8，呢個喺擁有 8 個可用 GPU 嘅情況下產生最佳延遲。喺每個組態中，當批次大小從 1 增加到 32 時，延遲通常會加倍，而從 32 增加到 128 時又會再次加倍。在足夠大的批次大小下，H100 與 A100 相比大約將延遲減半。A100 使用混合精確度，因為該架構缺乏對 fp8 的原生支援。帶有 SmoothQuant (SQ) 的 w8a8 旨在類似於 fp8。

當比較 H100 fp16 → fp8 同 A100 fp16 → w8a8 配合 SmoothQuant 時，量化嘅延遲改善大約喺 10% 左右。然而，與 fp16 相比，混合精確度 w4a16 實際上在低批次大小下表現更好，在高批次大小下表現更差。這可能是由於多種因素造成的，包括較不優化的運算核心、int4 和 fp16 之間的轉型時間，以及 w4a16 仍然將 16 位元浮點數用於激發的事實，導致 KV 快取的尺寸沒有節省。由於 w4a16 也表現出較低的準確度，我哋得出結論：我哋應該堅持為 A100 使用 w8a8 SQ，為 H100 使用 fp8。

圖 2 - 跨越具有唔同架構、量化同批次大小嘅 TP-8 組態嘅輸送量。對於每個架構和量化，批次大小被選擇為滿足 25600ms（512 個權Token為每秒 20 個權Token）延遲要求的最大值，以便我哋比較具有相似延遲的組態。在此要求下，使用相同量化 (fp16) 的帶有 BS-128 的 H100 達到 A100 BS-64 的 228% 輸送量，甚至儘管批次大小加倍，仍具有更低嘅回應延遲。使用 fp8 的量化將呢個係數提高到 251%。

喺我哋嘅首兩張圖中，我哋只呈獻 TP-8 嘅組態。當兩者都使用 fp16 / BS-128 / TP-8 時，H100 實現咗相較於 A100 54% 嘅延遲同 184% 嘅輸送量，當在 H100 上使用 fp8 時，呢個進一步改善為 49% 嘅延遲同 202% 嘅輸送量。效能嘅呢種改善可以歸因於 H100 同 A100 之間運算能力同記憶體頻寬嘅增加。值得注意的是，在利用率可能較低的較低批次大小下，這種差異不太明顯。

當我哋構建平台時，我哋希望在最大化輸送量嘅同時，滿足用戶嘅某些延遲要求。因此，與其在相同批次大小下比較 A100 與 H100，不如僅在滿足延遲要求嘅組態下比較佢哋嘅輸送量實際上更有意義。我哋為完成 512 個輸出權Token設定咗 25600ms 延遲嘅截止點，並發現 H100 / TP-8 / fp8 / BS-128 產生了相較於 A100 / TP-8 / fp16 / BS-64 251% 嘅輸送量，因其能夠以更低嘅延遲處理雙倍嘅批次大小。鑑於量化提供了 GPU 記憶體節省，我哋現在需要評估張量平行如何能夠增加下一層最佳化。

圖 3 - H100 fp8 喺唔同批次大小同張量平行下嘅延遲。當批次大小從 1 增加到 32 時，延遲通常會加倍，而從 32 增加到 128 時又會再次加倍。當批次大小相等時，TP-2 的速度始終約為 TP-8 的兩倍。將張量平行加倍嘅同時將批次大小加倍，可使延遲保持相對穩定，因為每個 GPU 處理嘅批次數量保持均勻。

當談到量化和架構時，有明顯的贏家：H100 壓倒 A100，而降低精確度的量化改善咗記憶體利用率、延遲同輸送量。然而，批次大小和張量平行喺我哋嘅關鍵指標中呈現出一種取捨。較大嘅批次大小以增加延遲和記憶體消耗為代價來最佳化輸送量。另一方面，較高嘅張量平行增加了可用記憶體的總體池並最佳化了延遲，但由於分散式矩陣乘法的同步成本以及憑藉鎖定更多 GPU 資源，而與輸送量進行了取捨。

圖 4 - H100 fp8 喺唔同批次大小同張量平行下嘅輸送量。最高輸送量嚟自 TP-2 BS-128，達到 A100/TP-8/fp16/BS-64 基線嘅 460%。然而，TP-2 BS-128 亦係圖 3 中最慢嘅結果。

我哋實驗中輸送量最大化嘅組態係 H100 / fp8 / TP-2 / BS-128，達到每秒每個 GPU 767 個輸出權Token。呢個係相較於 A100 / fp16 / TP-8 / BS-64 460% 嘅改善。然而，呢個代價係延遲加倍——對於 512 個輸出權Token接近 42000ms——因此它可能不適合作為生產組態。TP-4 BS-128（在 26188ms 回應時間下為 626 tok/sec/gpu）同 TP-2 BS-32（在 18821ms 回應時間下為 435 tok/sec/gpu）嘅結果可能代表咗我哋關鍵指標上更好嘅取捨。

我哋嘅結果表明：

給定相同組態，使用 H100 相比 A100，我哋達到 54% 嘅延遲同 184% 嘅輸送量，當 H100 利用其對 fp8 嘅原生支援時，呢個分別改善為 49% 同 202%。

在受限於延遲限制的情況下最大化輸送量時，H100 / fp8 / TP-8 / BS-128 產生了相較於 A100 / TP-8 / fp16 / BS-64 251% 嘅輸送量，因為它可以更快嘅速度處理雙倍嘅批次。

利用帶有 fp8 嘅 H100 配合 TP-2，我哋可以實現 A100 / fp16 / TP-8 / BS-128 373% 嘅輸送量，且延遲增加不到 10%。

批次大小和張量平行對 LLM 推理系統的操作員而言，在輸送量同延遲之間呈現出一種取捨。

呢啲結果令我哋對全面轉向先前由 A100 驅動嘅硬件堆疊中嘅 H100 GPU 感到有信心。我哋很高興能夠確認 NVIDIA 所宣傳嘅效能提升，並期待佢哋喺加速硬件方面嘅下一個突破。

我哋下一個最佳化嘅前沿係審查結構化稀疏度同 int4 精確度嘅準確度同效能影響，這可以顯著減少 Llama 2 70B 嘅 GPU 記憶體佔用空間，並帶來高達 2 倍嘅延遲改善。我哋很高興能夠繼續極速推理嘅旅程，並希望賦能我哋嘅用戶喺我哋嘅平台上構建強大嘅應用程式。

在短期內，pplx-api 將解除速率限制並提供更多自訂嘅 Perplexity LLM，包括一個由互聯網支援且具有事實基礎嘅 LLM。

登記加入 Perplexity Pro，網址為 perplexity.ai/pro。獲取使用我哋先進 pplx-api 嘅權限，並喺你嘅項目中善用呢啲先進功能。喺我哋嘅網誌上發現更多關於 pplx-api 嘅資訊。

有興趣塑造 AI 嘅未來？我哋正在招聘！成為推動大規模、生成式 LLM 基礎設施嘅團隊嘅一部分。喺 Perplexity Careers 探索機會。

Aarash Heydari, Grigorii Alekseev, Kevin Hu, Denis Yarats

實驗設定

關鍵指標：

常數：

AI 模型

輸入/輸出權杖資料集

軟件版本

變數

GPU 架構

張量平行

量化

批次大小

結果

結論

下一步

作者：