基準測試文字生成推理

在本部落格中，我們將探討 Text Generation Inference (TGI) 的小兄弟，即 TGI 基準測試工具。它將幫助我們瞭解如何超越簡單的吞吐量來分析 TGI，從而更好地理解權衡取捨，以便根據您的需求調整部署。如果您曾覺得 LLM 部署成本過高，或者您想調整部署以提高效能，那麼這篇部落格適合您！

我將向您展示如何在便捷的 Hugging Face Space 中完成此操作。您可以將結果用於 推理端點 或相同硬體的其他副本。

動機

為了更好地理解分析的必要性，我們先討論一些背景資訊。

大型語言模型（LLM）從根本上講效率不高。根據 解碼器的工作方式，每次生成都需要為每個解碼的 token 進行一次新的前向傳播。隨著 LLM 規模的增大，以及企業 採用率的飆升，人工智慧行業在建立新的最佳化和效能增強技術方面做得非常出色。

在 LLM 服務方面，已經有了數十項改進。我們看到了 Flash Attention、Paged Attention、流式響應、批處理改進、推測解碼、各種 量化、Web 伺服器改進、採用 更快的語言（抱歉 Python 🐍）等等。還有一些用例改進，如 結構化生成 和 水印，它們現在在 LLM 推理世界中佔有一席之地。問題在於，快速高效的實現需要越來越專業的技能才能實現 [1]。

Text Generation Inference 是 Hugging Face 的高效能 LLM 推理伺服器，旨在採用和開發最新的技術，以改進 LLM 的部署和使用。由於 Hugging Face 的開源合作伙伴關係，大多數（如果不是全部）主要的開源 LLM 在釋出當天即可在 TGI 中使用。

使用者通常會根據其用例要求有非常不同的需求。考慮 RAG 用例 中的提示和生成：

• 指令/格式
  • 通常很短，<200 個 token
• 使用者查詢
  • 通常很短，<200 個 token
• 多個文件
  • 中等大小，每個文件 500-1000 個 token，
  • N 個文件，其中 N<10
• 輸出中的答案
  • 中等大小，約 500-1000 個 token

在 RAG 中，擁有正確的文件對於獲得高質量響應至關重要，您可以透過增加包含更多文件的 N 來增加這種可能性。這意味著 RAG 通常會嘗試最大化 LLM 的上下文視窗以提高任務效能。相比之下，考慮基本聊天。典型的 聊天場景 的 token 數量明顯少於 RAG：

• 多輪對話
  • 2xTx50-200 token，T 輪
  • 2x 表示使用者和助手

鑑於我們有如此不同的場景，我們需要確保根據哪個場景更相關來相應地配置我們的 LLM 伺服器。Hugging Face 有一個 基準測試工具 可以幫助我們探索哪些配置最合理，我將解釋如何在 Hugging Face Space 上完成此操作。

先決條件

在我們深入瞭解工具之前，讓我們確保我們對一些關鍵概念有共同的理解。

延遲與吞吐量

• Token 延遲 – 處理並向用戶傳送 1 個 token 所需的時間
• 請求延遲 – 完全響應一個請求所需的時間
• 首次 Token 時間 - 從初始請求到第一個 token 返回給使用者的時間。這是處理預填充輸入和單個生成 token 所需時間的組合。
• 吞吐量 – 伺服器在設定時間內可以返回的 token 數量（在此示例中為每秒 4 個 token）

延遲是一個棘手的衡量標準，因為它不能說明全貌。您的生成可能很長，也可能很短，這對於您的實際伺服器效能而言意義不大。

重要的是要理解吞吐量和延遲是正交的度量，並且根據我們配置伺服器的方式，我們可以針對其中一個進行最佳化。我們的基準測試工具將透過資料視覺化幫助我們理解這種權衡。

預填充和解碼

這是 LLM 生成文字的簡化檢視。模型（通常）為每次前向傳播生成一個 token。在橙色的 預填充階段，完整提示（What is.. of the US?）被髮送到模型並生成一個 token（Washington）。在藍色的 解碼階段，生成的 token 被附加到前一個輸入中，然後此（... the capital of the US? Washington）被髮送到模型中進行另一次前向傳播。直到模型生成序列結束 token ()，此過程將繼續：透過模型傳送輸入，生成一個 token，將 token 附加到輸入。

我只包含了一個簡短的示例用於說明目的，但請注意，預填充只需要對模型進行一次前向傳播，而解碼可能需要數百次甚至更多。即使在我們的短示例中，我們也可以看到藍色箭頭多於橙色箭頭。現在我們可以明白為什麼從 LLM 獲取輸出需要花費這麼多時間了！由於多次前向傳播，解碼通常是我們花費更多時間思考的部分。

基準測試工具

動機

我們都見過工具、新演算法或模型的吞吐量比較。雖然這是 LLM 推理故事的重要組成部分，但它缺少一些關鍵資訊。至少（當然您可以更深入地研究），我們需要知道吞吐量和延遲才能做出好的決策。TGI 基準測試工具的主要優勢之一就是它具有這種能力。

另一個重要的思路是考慮您希望使用者獲得什麼樣的體驗。您更關心服務於許多使用者，還是希望一旦使用者與您的系統互動就能獲得快速響應？您是希望有更好的首次 Token 時間（TTFT），還是希望一旦使用者獲得第一個 Token 即使第一個 Token 延遲了，也能有飛快的 Token 生成速度？

以下是一些可能的情況。請記住，沒有免費的午餐。但是，只要有足夠的 GPU 和適當的配置，您幾乎可以獲得任何想要的體驗。

我關心…	我應該關注…
處理更多使用者	最大化吞吐量
使用者不離開我的頁面/應用	最小化 TTFT
適量使用者的使用者體驗	最小化延遲
全面均衡的體驗	限制延遲並最大化吞吐量

設定

基準測試工具隨 TGI 一起安裝，但您需要訪問伺服器才能執行它。考慮到這一點，我提供了這個空間 derek-thomas/tgi-benchmark-space，它結合了 TGI Docker 映象（固定到最新版本）和 Jupyter Lab 工作空間。它被設計為可複製的，所以如果它處於休眠狀態，請不要擔心。它將允許我們部署一個我們選擇的模型，並透過 CLI 輕鬆執行基準測試工具。我添加了一些筆記本，可以讓您輕鬆地跟著操作。歡迎深入瞭解 Dockerfile，瞭解它是如何構建的，特別是如果您想對其進行調整。

開始

請注意，由於其互動性，最好在 Jupyter Lab 終端而不是筆記本中執行基準測試工具，但我會將命令放在筆記本中，以便我可以進行註釋並易於跟隨。

1. 點選：
   • 在 `JUPYTER_TOKEN` 空間金鑰 中設定您的預設密碼（複製時應提示您）
   • 選擇您的硬體，請注意它應該與您想要部署的硬體相同。
2. 前往您的空間並使用密碼登入
3. 啟動 `01_1_TGI-launcher.ipynb`
   • 這將使用 Jupyter 筆記本啟動預設設定的 TGI。
4. 啟動 `01_2_TGI-benchmark.ipynb`
   • 這將啟動帶有演示設定的 TGI 基準測試工具。

主要組成部分

• 元件 1：批次選擇器及其他資訊。
  • 使用箭頭選擇不同的批次
• 元件 2 和 元件 4：預填充統計資訊和直方圖
  • 計算出的統計資料/直方圖基於 `—runs` 的次數。
• 元件 3 和 元件 5：預填充吞吐量與延遲散點圖
  • X 軸是延遲（越小越好）
  • Y 軸是吞吐量（越大越好）
  • 圖例顯示了我們的批處理大小。
  • 一個“理想”點將位於左上角（低延遲和高吞吐量）。

理解基準測試工具

如果您使用與我相同的硬體和設定，您應該會得到與圖 4 非常相似的圖表。基準測試工具向我們展示了在啟動 TGI 時給定的當前設定和硬體下，不同批次大小（使用者請求的數量，與我們啟動 TGI 時的語言略有不同）的吞吐量和延遲。瞭解這一點很重要，因為我們應該根據基準測試工具的發現來更新我們啟動 TGI 的設定。

元件 3 中的圖表在預填充較長時（例如 RAG）往往更有趣。它確實會影響 TTFT（顯示在 X 軸上），這是使用者體驗的重要組成部分。請記住，即使我們必須從頭開始構建 KV 快取，我們也可以在一個前向傳播中推送輸入 token。因此，在許多情況下，它每個 token 的速度通常比解碼快。

元件 5 中的圖表是我們在解碼時的情況。讓我們看看資料點的形狀。我們可以看到，對於批處理大小為 1-32 的情況，形狀大部分是垂直的，大約在 5.3 秒。這非常好。這意味著在不降低延遲的情況下，我們可以顯著提高吞吐量！那麼 64 和 128 會發生什麼呢？我們可以看到，雖然吞吐量在增加，但我們開始犧牲延遲。

對於這些相同的值，讓我們看看 元件 3 中的圖表發生了什麼。對於批處理大小為 32 的情況，我們看到 TTFT 仍然約為 1 秒。但是我們確實開始看到從 32 -> 64 -> 128 的線性增長，批處理大小增加 2 倍，延遲也增加 2 倍。此外，吞吐量沒有增加！這意味著我們並沒有從這種權衡中獲得太多好處。

如果您的批處理大小處於垂直區域，這很好，您可以免費獲得更多吞吐量並處理更多使用者。如果您的批處理大小處於水平區域，這意味著您受到計算限制，增加使用者只會延遲所有人而沒有吞吐量的好處。您應該改進您的 TGI 配置或擴充套件您的硬體。

既然我們對 TGI 在各種場景下的行為有了一些瞭解，我們就可以嘗試不同的 TGI 設定並再次進行基準測試。在決定一個好的配置之前，最好重複這個迴圈幾次。如果足夠感興趣，我們也許可以推出第二部分，深入探討聊天或 RAG 等用例的最佳化。

總結

跟蹤實際使用者行為很重要。當我們估算使用者行為時，我們必須從某個地方開始並做出有根據的猜測。這些數字選擇將對我們如何進行分析產生重大影響。幸運的是，TGI 可以在日誌中告訴我們這些資訊，所以一定要也去檢視一下。

完成探索後，請務必停止所有執行，以免產生額外費用。

• 在 `TGI-launcher.ipynb` Jupyter Notebook 中終止正在執行的單元格
• 在終端中按 `q` 鍵停止分析工具。
• 在空間的設定中點選暫停

結論

LLM 龐大且昂貴，但有多種方法可以降低成本。只要我們正確利用其功能，像 TGI 這樣的 LLM 推理伺服器就已經為我們做了大部分工作。第一步是瞭解正在發生什麼以及您可以做出哪些權衡。我們已經看到了如何使用 TGI 基準測試工具來做到這一點。我們可以將這些結果用於 AWS、GCP 或推理端點上的任何等效硬體。

感謝 Nicolas Patry 和 Olivier Dehaene 建立了 TGI 及其 基準測試工具。還要特別感謝 Nicholas Patry、Moritz Laurer、Nicholas Broad、Diego Maniloff 和 Erik Rignér 的寶貴校對。

參考文獻

[1] : Sara Hooker, 硬體彩票, 2020

[2] : Pierre Lienhart, LLM 推理系列：2. LLM 響應背後的兩階段過程, 2023