TGI v3 概覽

總結

效能飛躍：在處理長 Prompt 時，TGI 的 Token 處理量是 vLLM 的 3 倍，速度快上 13 倍。而且無需任何設定！

Token 處理量提升 3 倍。

透過減少記憶體佔用，我們能夠比以往處理更多、更動態的 Token。單張 L4 (24GB) 顯卡在執行 llama 3.1-8B 時可處理 30k 個 Token，而 vLLM 僅能勉強達到 10k。我們投入了大量工作來縮減執行時期的記憶體佔用，這些優化在小型、受限的環境中效果最為顯著。

速度提升 13 倍

在處理長 Prompt（超過 200k 個 Token）時，vLLM 的對話回覆需要 27.5 秒，而 TGI 僅需 2 秒。原因為何？我們保留了先前的對話內容，因此當新的回覆請求到來時，我們幾乎可以瞬間完成回應。查找的開銷僅約 5us。感謝 Daniël de Kok 提供的強大資料結構。

無需設定 (Zero config)

就是這樣。移除你現有的所有旗標參數，你很可能就能獲得最佳效能。TGI 會透過評估硬體與模型，仔細選擇自動化參數以提供最佳效能。在生產環境中，我們目前的部署已不再使用任何旗標參數。我們保留了現有的所有參數，以備在利基場景中或許能派上用場。

基準測試

方法論

為了確保結果準確可靠，我們採用了一套穩健的基準測試協議，解決了效能評估中常見的問題。具體如下：

1. 一致的程式碼：我們在不同的引擎上使用相同的程式碼庫進行測試，確保任何效能差異皆源自 LLM 本身，而非測試框架的差異。
2. 基於請求的測量：我們不採用盡可能多地發送請求來測量每秒請求數 (RPS)，而是選擇更一致的方法：發送固定數量的請求，並測量伺服器完成所有請求所需的時間。這種方法避免了邊界效應，能更準確地代表效能。
3. 實際配置組合：我們選擇了實際的 LLM 與硬體配置組合，例如，我們使用 8xH100 運行 70B 模型，而不是 8B 模型，那樣會浪費資源。
4. 實際場景：我們在開啟 Prefix Caching（字首快取）的情況下對引擎進行基準測試，因此我們回報的是第二次運行的結果，而非第一次。在基準測試的第一次運行中，每個請求都是全新的，導致 Prefix Caching 無法發揮作用，進而掩蓋了其在實際應用中的優勢。

註：邊界效應是指當基準測試結果取決於被測引擎的細節時，測試變得不穩定。例如，一個系統持續處理 10 RPS，但在基準測試結束前 0.1 秒收到最後一個請求，且該請求需要整整 10 秒才能處理。那麼一個 30 秒的基準測試會測量出 7.5 RPS 而非預期的 10，因為該單一查詢沒有與其他查詢並行處理。另一個稍慢的引擎可能會在 +0.1 秒收到該請求，基準測試會將其忽略，進而測出該較慢的系統反而較快。

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

場景

我們選擇了幾個場景來簡化說明，這些場景似乎能準確反映更大的趨勢。

1. 小型場景：此場景包含來自 Orca 資料集的前 200 個請求作為模型的 Prompt。這 200 個請求總計 8k 個 Token，代表了對話啟動場景。Prefix Caching 在此場景中的影響非常有限，我們認為這對於簡單的使用案例來說是一個相對平衡的基準測試。

2. 長型場景：此場景包含 20 個請求，總計 200k 個 Prompt Token，本質上是要求對大段文字進行摘要。在實際應用中，當您重複輸入大段程式碼、大量商業資料或文件並詢問相關問題（摘要、分類或查找資料）時，這非常有意義。此場景最接近許多專業使用案例，即將大量資訊包含在 Prompt 本身中。這些超長對話正是我們近期變更受益最大的部分，因為我們實現了更大的 Prompt 支援與更快的快取速度。

   硬體

   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

結果

我們的基準測試結果顯示了顯著的效能增益：在開啟 Prefix Caching 的情況下，速度比 vLLM 快 13 倍，而未開啟時則高達 30 倍。這些結果與我們的生產數據一致，證明了我們優化後的 LLM 架構之有效性。

原始結果

注意事項與限制

雖然我們的結果很有前景，但仍有一些注意事項需考量：

1. 受限的 KV-Cache：如果部署環境缺乏 KV-Cache 空間，代表許多查詢將爭奪相同的 KV-Cache 槽位，導致衝突。您可以透過限制 --max-total-tokens 來減少單一查詢的影響，也可以增加更多的 GPU 或更大的 GPU 來擴展 KV-Cache 容量。
2. 複本 (Replication)：在多個複本位於單一端點後方的場景中，來自特定使用者的每個查詢沒有理由都命中同一個複本，因此快取將不存在，意味著沒有速度提升。您可以使用「黏性階段」(Sticky Sessions) 負載平衡來強制每個使用者將其請求發送到同一個複本。但請勿盲目使用，這可能在某些情況下並非必要。

技術洞察

我們的效能增益歸功於幾個關鍵因素：

1. 新核心 (Kernels)：我們的自訂核心，包含 flashinfer 與 flashdecoding，在長 Prompt 長度下提供了改善後的效能，並實現了更有效率的排程。
2. Prefix Caching：我們優化後的 Prefix Caching 結構允許快速的查詢比對，即使對於長 Prompt 也是如此。其開銷大約為 6us。
3. 分塊程式碼 (Chunking Code)：我們的分塊程式碼能夠更精細地控制運算資源，確保最佳效能並降低 VRAM 使用量。
4. 核心優化：我們實作了各種其他核心優化，包括更好的核心選擇。特別是我們實作了幾個涉及查詢簿記 (bookkeeping) 的小核心，這些核心在小型模型上特別高效。每次核心啟動都有數毫秒的開銷，因此將它們融合在一起，在簿記工作相對於原始模型計算顯得重要時，可大幅提升效能。這通常發生在相對於特定模型過度配置的運算資源上，特別是小型模型。
5. VRAM 效率：在處理超大型請求（100k+ Token）時，有很多地方會變成記憶體消耗大戶。我們找出了最大的幾個並設法減少、重複使用或刪除它們。最大的罪魁禍首可能是 logits 計算。Llama 3.1-8B 的 Logits 佔用了 25.6GB（=100k Token * 128k 詞彙量 * 2 (f16)），這比 16GB 的完整模型還要大。事實上，通常我們不需要所有的 Prompt Logits，因此我們直接將其移除，並預設取消使用者請求這些資料的能力。我們認為這沒問題，因為它們大多僅被研究人員使用。若要重新啟用，可使用 --enable-prefill-logprobs 旗標，但您的 Prompt Token 大小上限將會縮減。

未來方向

儘管我們取得了重大進展，但仍有改善空間：

1. 特殊模型：並非所有 LLM 都享有上述提到的所有改進。某些特定功能集可能尚未支援（例如某些量化、推測解碼或 VLM 模型，要以同等細節進行優化較為困難）。
2. KV-Cache 長期保留：解決 KV-Cache 的長期保留是一個挑戰。目前已設想了一些解決方案，例如共用 KV-Cache（如 Redis 或 Memcached）或創新的儲存方法。這是我們持續研究的領域。
3. 多模態模型：我們也正在深入研究其他類型的模型，例如音訊轉音訊、影像/影片生成，以及其他混合模型，我們認為將在 TGI 中應用的相同原則套用於這些模型，將具有極大的效能提升潛力。

透過分享我們的基準測試方法、結果與技術洞察，我們旨在為開發更高效、更強大的 LLM 做出貢獻。 在 GitHub 上更新