進行您自己的 LLM 端點基準測試
本文提供 Databricks 建議的筆記本範例，以基準檢驗 LLM 端點。 它也包含一個簡短的簡介，介紹 Databricks 如何執行 LLM 推理，並將延遲和輸送量計算為端點效能指標。
在 Databricks 上，LLM 推論會測量基礎模型 API 在預配置吞吐量模式下的每秒處理令牌數。 請參閱 在配置輸送量中，每秒令牌數範圍的意義是什麼？。
效能評定範例筆記本
您可以將下列筆記本匯入 Databricks 環境，並指定要執行負載測試的 LLM 端點名稱。
基準測試 LLM 端點
LLM 推斷簡介
LLM 會在雙步驟程式中執行推斷：
- 預先填入，where 輸入提示中的令牌會平行處理。
- 解碼，where 文本是以自回歸的方式逐個生成； 每個產生的令牌都會附加至輸入，並送回模型，以 generate 下一個令牌。 當 LLM 輸出特殊停止令牌或符合使用者定義條件時，產生就會停止。
大部分的生產應用程式都有延遲預算，而 Databricks 建議您在延遲預算的情況下將輸送量最大化。
- 輸入令牌數目會對處理要求所需的記憶體產生重大影響。
- 輸出令牌的數目主導整體回應延遲。
Databricks 會將 LLM 推斷分成下列子計量：
- 第一個字元出現時間（TTFT）：指的是使用者輸入查詢後，開始看到模型輸出的速度。 在即時互動中，回應的等候時間很低，但在離線工作負載中則較不重要。 此指標受到處理提示所需時間的影響，然後在此基礎上生成第一個輸出標記 generate。
- 每個輸出令牌 時間（TPOT）：為查詢系統的每個使用者 generate 輸出令牌的時間。 此計量會對應每位使用者如何感知模型的「速度」。 例如，每個令牌 100 毫秒的 TPOT 意味著每秒 10 個令牌，或每分鐘約 450 個字，比一般人讀得更快。
根據這些計量，可以定義總延遲和輸送量，如下所示：
- 延遲 = TTFT + （TPOT） * （要產生的標記數目）
- 輸送量 = 每秒輸出的令牌數量，涵蓋所有併發請求
在 Databricks 上，LLM 服務端點能夠擴展，以符合用戶端所傳送的多個並行請求負載。 延遲和輸送量之間有取捨。 這是因為，在 LLM 服務端點上，並發請求可以同時被處理。 在低並行要求負載下，延遲是可能最低的。 不過，如果您增加要求負載，延遲可能會增加，但輸送量可能會上升。 這是因為每秒可處理兩個值令牌的要求，時間少於兩倍。
因此，控制系統中的平行要求數目，是平衡延遲與輸送量的核心。 如果您有低延遲的使用案例，您想要將較少的並行要求傳送至端點，以保持低延遲。 如果您有高吞吐量的應用案例，您會希望透過大量的並發請求來讓端點飽和，因為即便犧牲延遲，更高的吞吐量也是值得的。
- 高吞吐量使用案例可能包括批次推論和其他非使用者面向的任務。
- 低延遲使用案例可能包括需要立即回應的即時應用程式。
Databricks 基準檢驗控管
先前共用的 基準檢驗範例筆記本 是 Databricks 的基準檢驗工具。 筆記本會顯示所有請求和吞吐量指標的 總 延遲，並繪製在不同數量的平行請求下吞吐量與延遲的曲線。 Databricks 端點自動調整策略會在延遲與輸送量之間取得平衡。 在筆記本中，您會發現當更多使用者同時查詢端點時，延遲和吞吐量會增加。
不過，您也會開始看到，當平行要求數目增加時，吞吐量會開始趨於平穩，達到每秒約 8000 個 Tokens 的 limit。 發生這個瓶頸的原因是端點的配置輸送量限制了可進行的處理程序數量和平行請求數量。 當超出端點可同時處理的請求數量時，隨著更多請求在佇列中等待，總延遲會繼續增加。
如需了解有關 Databricks 在 LLM 效能基準測試方面的哲學的更多詳細信息，請參閱 LLM 推論效能設計：最佳實踐部落格。