TGI v3 概覽

總結

效能飛躍：TGI 處理的 token 數量是 vLLM 的 3 倍，在長提示語上速度快 13 倍。零配置！

3 倍的 token 數量。

透過減少記憶體佔用，我們能夠比以前更動態地攝取更多的 token。單個 L4 (24GB) 可以在 llama 3.1-8B 上處理 30k token，而 vLLM 只能處理不到 10k。我們付出了大量努力來減少執行時記憶體佔用，其效果在較小的受限環境中表現最佳。

快 13 倍

在長提示語（200k+ token）上，對話回覆在 vLLM 中需要 27.5 秒，而在 TGI 中僅需 2 秒。這是怎麼做到的？我們保留了初始對話，因此當新的回覆進來時，我們幾乎可以立即回答。查詢的開銷約為 5 微秒。感謝 @Daniël de Kok 提供了這個強大的資料結構。

零配置

就是這樣。刪除你正在使用的所有標誌，你很可能會獲得最佳效能。透過評估硬體和模型，TGI 會仔細選擇自動值以提供最佳效能。在生產中，我們的部署中不再有任何標誌。我們保留了所有現有標誌，它們在特殊場景中可能派上用場。

基準測試

方法論

為確保結果準確可靠，我們採用了穩健的基準測試協議，解決了效能評估中的常見陷阱。具體來說：

1. 程式碼一致性：我們使用相同的程式碼庫來針對不同的引擎執行，確保任何效能差異都歸因於 LLM 本身，而不是測試框架中的變體。
2. 基於請求的度量：我們沒有透過傳送儘可能多的請求來測量每秒請求數 (RPS)，而是選擇了一種更一致的方法，即傳送固定數量的請求並測量伺服器完成所有請求所需的時間。這種方法避免了邊界效應，並提供了更準確的效能表示。
3. 實際組合：我們選擇了 LLM 和硬體配置的實際組合，因此我們為 70B 模型使用了 8xH100，而不是 8B 模型，因為這將是浪費金錢。
4. 實際場景：我們對啟用字首快取的引擎進行了基準測試，因此我們報告的是第二次執行的結果，而不是第一次執行的結果。在基準測試的第一次執行中，每個請求都是新的，因此字首快取不起作用，這會掩蓋使用它的實際好處。

注意：邊界效應是指基準測試結果不穩定，因為它取決於被測試引擎的細微細節。例如，一個系統每秒攝取 10 個 RPS，但在基準測試結束前 0.1 秒收到了一個最終請求，而這個請求需要整整 10 秒才能處理。那麼一個耗時 30 秒的基準測試將測量到 7.5 RPS 而不是預期的 10 RPS，因為那個單一查詢沒有與其他查詢並行化。另一個稍慢的引擎將在 0.1 秒後收到該請求，該請求將被基準測試丟棄，從而測量到較慢的系統反而更快。

有關基準測試的更多詳細資訊，我們建議查閱 k6 文件：https://grafana.com/docs/k6/latest/。

場景

我們選擇了一些場景來簡化描述，它們似乎準確地反映了更大的趨勢。

1. 小型場景：此場景包括來自 orca 資料集的前 200 個請求，這些請求被提示給模型。這 200 個請求總共 8k 個 token，代表了對話的開端。字首快取在此場景中影響非常有限，我們認為這是一個相對平衡的簡單用例基準測試。

2. 長場景：此場景包含 20 個請求，總計 200k 個提示 token，主要用於總結大塊文字。在實際場景中，當您反覆輸入大塊程式碼、大塊業務資料或文件並詢問簡單問題（摘要、分類或在哪裡可以找到某些資料）時，這非常有用。這個場景最接近許多專業用例，因為它在提示本身中包含了大量資訊。這些非常長的對話受益於我們最近的更改，因為我們支援更大的提示和更快的快取。

   硬體

   1. L4：這是單個 L4（24GB），代表小型甚至家庭計算能力。我們測試了 meta-llama/Meta-Llama-3.1-8B-Instruct。
   2. 4xL4：這是一種更強大的部署，通常用於 8B 模型（正在測試的模型）的超大型請求部署，或者它可以輕鬆處理所有 30GB 模型。在此基準測試中，我們測試了 meta-llama/Meta-Llama-3.1-8B-Instruct。
   3. 8xH100：這是可能的最強大的部署之一。我們測試了 meta-llama/Meta-Llama-3.1-70B-Instruct，因為它是該尺寸最具代表性的模型。Llama 3.3 在基準測試時尚未釋出（它是完全相同的模型，因此沒有區別）。

復現結果

執行基準測試的命令如下

1. 準備資料集

cd text-generation-inference/load_tests
make prepare_orca
python long.py

2. 啟動引擎

TGI: text-generation-launcher --model-id $MODEL_ID --num-shard $N --port 8000（或 Docker 版本）vLLM: vllm serve $MODEL_ID --tensor-parallel $N —enable-prefix-caching（或 Docker 版本）

3. 開始場景：小型：MODEL_ID=$MODEL_ID HOST=localhost:8000 k6 run load_tests/common.js 長型：MODEL_ID=$MODEL_ID HOST=localhost:8000 k6 run load_tests/long.js

結果

我們的基準測試結果顯示了顯著的效能提升，在使用字首快取時比 vLLM 快 13 倍，在不使用字首快取時最多快 30 倍。這些結果與我們的生產資料一致，並證明了我們最佳化的 LLM 架構的有效性。

原始結果

注意事項和限制

儘管我們的結果令人鼓舞，但仍有一些注意事項需要考慮

1. 受限的 kv-cache：如果部署缺少 kv-cache 空間，這意味著許多查詢將需要相同的 kv-cache 插槽，從而導致 kv-cache 爭用。您可以透過限制 --max-total-tokens 來減少單個查詢的影響。您還可以使用更多的 GPU 或更大的 GPU 來增加 kv-cache 的大小。
2. 副本：在單個端點後存在多個副本的場景中，來自特定使用者的每個查詢都沒有理由命中同一副本，因此快取將不存在，這意味著沒有速度優勢。您可以使用粘性會話負載平衡來強制每個使用者將其請求傳送到同一副本。請勿盲目應用此方法，這可能根本沒有必要。

技術見解

我們的效能提升可歸因於以下幾個關鍵因素

1. 新核心：我們的自定義核心，包括 flashinfer 和 flashdecoding，在長提示長度下提供改進的效能，並實現更高效的排程。
2. 字首快取：我們最佳化的字首快取結構即使對於長提示也能實現快速查詢匹配。開銷約為 6 微秒。
3. 分塊程式碼：我們的分塊程式碼能夠更精細地控制計算資源，確保最佳效能並減少 VRAM 使用。
4. 核心最佳化：我們實施了各種其他核心最佳化，包括更好的核心選擇。值得注意的是，我們實施了幾個涉及查詢簿記的小核心，這些核心在小型模型上特別高效。每個核心啟動都有幾毫秒的開銷，因此將它們融合在一起可以大大提高效能，當這種簿記相對於原始模型計算很重要時。這通常發生在特定模型的超大計算和特別小的模型上。
5. VRAM 效率：在處理超大請求（100k+ token）時，許多地方會開始成為巨大的記憶體消耗者。我們找出了最大的幾個，並找到了減少/重用或刪除它們的方法。最大的罪魁禍首可能是 logits 計算。Llama 3.1-8b 的 Logits 佔用 25.6GB（=100k token * 128k 詞彙 * 2 (f16)），這比整個模型 16GB 還要多。問題是，通常我們不需要每個提示的 logits，所以我們預設簡單地刪除了它們，並阻止使用者潛在地請求它們。我們認為這沒關係，因為它們主要由研究人員使用。您可以使用 --enable-prefill-logprobs 標誌再次啟用部署以擁有它們，但您將體驗到 token 提示大小的減少。

未來方向

雖然我們取得了顯著進展，但仍有改進的空間

1. 特殊模型：所有 LLM 都具有上述改進。某些特定功能集可能沒有（例如，某些量化、推測或 VLM 更難以相同程度的細節進行最佳化）。
2. KV 快取長期保留：解決 KV 快取長期保留是一個挑戰。目前設想了幾種解決方案，例如共享 KV 快取（如 redis 或 memcached）解決方案或創新的儲存方法。這是我們正在進行的研究領域。
3. 多模態模型：我們還在大量研究其他型別的模型，如音訊到音訊、影像/影片生成以及其他混合模型，我們認為這些模型在應用我們在 TGI 中應用的相同原理以最大化效能方面具有巨大潛力。

透過分享我們的基準測試方法、結果和技術見解，我們旨在為更高效、更有效的 LLM 的持續發展做出貢獻。