透過 24 小時負載測試提升發佈穩定性
隨著 LiteLLM 的採用持續成長，外界對可靠性、效能與營運安全性的期待也隨之提高。要滿足這些期待，不能只靠以正確性為中心的測試，還需要驗證系統在真實世界條件下，隨時間推移會如何表現。
這篇文章介紹 LiteLLM Observatory，這是我們打造的一套長時間執行的發佈驗證系統，用來在回歸問題到達使用者之前將其攔截。
我們為何打造 Observatory
LiteLLM 處於外部提供者、長時間存活的網路連線，以及高吞吐量工作負載的交會點。雖然我們的單元測試與整合測試在驗證正確性方面表現非常出色，但它們並不是為了找出只有在長時間運作後才會出現的問題而設計的。
在 v1.81.3 中發現的一個微妙生命週期邊界案例，強化了我們對這個領域需要更強發佈驗證的認知。
一個真實世界的生命週期邊界案例
在 v1.81.3 中，我們釋出了一個針對 HTTP 用戶端記憶體洩漏的修正。這項變更通過了單元測試與整合測試，並且在短時間執行時表現正確。
浮現出的問題不是由某一行錯誤的邏輯所造成，而是由多個元件隨著時間互動的方式所導致：
- 快取的
httpx用戶端被設定為 1 小時 TTL - 當快取過期時，底層 HTTP 連線如預期般被關閉
- 較高層級的用戶端持續保留該連線的參照
- 後續請求失敗並出現：
Cannot send a request, as the client has been closed
變更前（含 bug）：
| 提供者 | 請求數 | 成功 | 失敗 | 失敗率 |
|---|---|---|---|---|
| OpenAI | 720,000 | 432,000 | 288,000 | 40% |
| Azure | 692,000 | 415,200 | 276,800 | 40% |
變更後（已修正）：
| 提供者 | 請求數 | 成功 | 失敗 | 失敗率 |
|---|---|---|---|---|
| OpenAI | 1,200,000 | 1,199,988 | 12 | 0.001% |
| Azure | 1,150,000 | 1,149,982 | 18 | 0.002% |
我們接下來的重點，是要成為第一個偵測到問題的一方，即使這些問題沒有被單元測試涵蓋。LiteLLM Observatory 的設計目標，是在發佈驗證期間，針對我們自己正式環境部署中的真實流量模式，找出只有在這些情境下才會出現的延遲回歸、OOM，以及失敗模式。
Observatory 如何運作
LiteLLM Observatory 是一項測試服務，會對我們的 LiteLLM 部署執行長時間測試。我們透過傳送 API 請求來觸發測試，而在測試完成後，結果會自動傳送到 Slack。
測試如何執行
-
開始測試：我們向 Observatory API 傳送請求，內容包括：
- 要測試哪個 LiteLLM 部署（URL 和 API 金鑰）
- 要執行哪個測試（例如，
TestOAIAzureRelease） - 測試設定（要測試哪些模型、執行多久、失敗門檻）
-
智慧排隊：
- 系統會檢查我們是否正嘗試執行完全相同的測試超過一次
- 如果已經有重複的測試正在執行或排隊中，我們會收到錯誤，以避免浪費資源
- 否則，測試會加入佇列，並在有可用容量時執行（預設最多可同時執行 5 個測試）
-
即時回應：API 會立即回應——我們不會等待測試完成。測試可能會執行數小時，但請求本身會在毫秒內完成。
-
背景執行：
- 測試會在背景中執行，對我們的 LiteLLM 部署發出請求
- 它會追蹤請求成功率與失敗率的變化
- 測試完成時，結果會自動貼到我們的 Slack 頻道
範例：OpenAI / Azure 可靠性測試
TestOAIAzureRelease 測試的設計目的是找出一類只會在長時間執行後才浮現的 bug：
- 持續時間：連續執行 3 小時
- 行為：在指定模型之間輪替（例如
gpt-4和gpt-3.5-turbo），持續發出請求 - 為什麼是 3 小時：這有助於找出 HTTP 用戶端在長時間使用後退化或失效的問題（例如在 LiteLLM v1.81.3 中觀察到的 bug）
- 通過 / 失敗標準：如果失敗請求少於 1%，測試即通過；如果失敗率超過 1%，測試即失敗，且我們會在 Slack 中收到通知
- 關鍵細節：整個執行期間都重複使用同一個 HTTP 用戶端，讓我們能偵測只會在長時間重複使用下才會出現的生命週期相關 bug
我們何時使用它
- 部署前：在將新的 LiteLLM 版本推進到正式環境之前執行測試
- 例行驗證：定期排程執行（每日或每週），及早找出回歸問題
- 問題調查：當我們懷疑有部署問題時，按需執行測試
- 長時間失敗偵測：找出只有在持續負載下才會出現的 bug，超出短暫冒煙測試所能揭露的範圍
與單元測試互補
單元測試仍然是我們開發流程的基礎部分。它們快速且精確，但無法涵蓋：
- 真實的提供者行為
- 長時間存活的網路互動
- 資源生命週期邊界案例
- 與時間相關的回歸問題
LiteLLM Observatory 透過在類似正式環境的實際運作情境中驗證系統，來補足單元測試的不足。
展望未來
可靠性是一項持續的投資。
LiteLLM Observatory 是我們正在打造的多個系統之一，目的是持續提高發佈品質與營運安全性的標準。隨著 LiteLLM 演進，我們的驗證工具也會跟著演進，並從真實世界的使用情況與所學到的經驗中獲得指引。
我們會在前進的同時，持續公開分享這些改進。