20 篇文章 含有標籤「product」

LiteLLM Auto Router 現在支援 Laya 和 Bespoke Nimble 作為自架分類器。在您的基礎架構上執行任一模型，以選擇由哪個 completion model 處理每個請求。您的應用程式仍會呼叫相同的 router endpoint。

LiteLLM 閘道課程會帶您了解閘道、Router 和 SDK 如何協同運作。我們為部署 LiteLLM 的開發者與平台團隊，以及想在開啟 pull request 前先了解程式碼的貢獻者所設計。

您的閘道會告訴您團隊在 AI 上花了多少錢。它不會告訴您這些支出產生了什麼。

**LiteLLM ROI 計算器 會比較閘道支出與團隊交付的工程工作。**它會從 LiteLLM 讀取每位使用者的支出、使用您選擇的模型估算每個已合併拉取請求的工時，並依電子郵件配對對象。結果只會得到一個數字：每個預估工程時數的支出。

感謝所有參加我們 9 月 town hall 的朋友。我們介紹了產品中的安全性更新、穩定性更新與新功能，包括預設在 Rust 上執行的 OCR，以及超過我們 8 月設定的 80% 目標的測試覆蓋率。

TypeSafe AI 的 Jev 今天在 v1.103.0-rc 上線 LiteLLM。Jev 是一個決策模型：它回傳選擇、分數或是/否機率，而不是文字，因此它有自己的 evaluate endpoint，而不是 /chat/completions。LiteLLM 會以記錄與成本追蹤來代理該 endpoint。

機器人先查詢天氣，接著查看商店的營業時間。使用者問：「商店幾點關門？」機器人仍然把先前的天氣報告送給模型，儘管它已經無助於回答這個問題。

TypeSafe Jev 可協助 LiteLLM 找出不再需要的工具結果。LiteLLM 會在呼叫模型之前，以簡短提示取代這些結果。這稱為壓縮，可減少長對話所使用的輸入 token。

共享代理程式可以保留個別身分、存取與支出控制。

當財務代理程式服務多個業務單位時，平台團隊需要一致的方法來識別每個請求的發起者、套用正確的模型與工具權限，並歸屬支出。LiteLLM 讓這些脈絡在共享代理程式工作流程中保持可用，因此每個業務單位都能在各自的存取與預算政策下運作。

LiteLLM 為此工作流程提供一個統一的控制平面，涵蓋 Agent Gateway、Model Gateway 與 MCP Gateway。團隊可以共享相同的代理程式基礎架構，同時讓存取權、憑證、支出與稽核資料都繫結到正確的呼叫者。

Heuristic v1 會為七個提示信號評分，包括推理語言、程式碼、技術詞彙與提示長度。您可以針對路由器所處理的流量調校這些信號。

Heuristic v2，LiteLLM 的新 AutoRouter 分類器，效率最高可比 Heuristic v1 高 45%：以更低成本，在更短時間內解決更多任務。 只有分類器改變了。

感謝所有參加我們八月 town hall 的人。我們在會中分享了本月的安全性與穩定性工作，以及最新的產品更新：79 項安全修補、375 項 bug 修復、142 個功能 commit、新任安全總監、公開狀態儀表板，以及來自 production 的 Auto-Router 結果。

v1.97 對 auto router 做了三項變更。

• LLM 分類器現在會接收一段先前對話輪次，預設為三輪。這將追問分類的準確率從 14% 提升到 78%，成本最高為每 1,000 次請求 $0.61，且不增加額外延遲。
• 新的 Benchmarks 檢視會以 all-frontier 基準為您的路由流量定價並回報差異，這些節省現在也會出現在 Cost Optimization 總計中。
• session affinity 現在預設為關閉，這符合我們先前的文章所示：這會導致品質變差，且沒有成本改善。

感謝所有參與我們 7 月線上大會的人。我們藉此分享本月的安全與穩定性工作，以及最新的產品更新：38 項安全修補、317 項錯誤修正、140 個功能提交，重點包括新的 Rust 基準測試與 Autorouter V2 的推出。

Router plugins 現已可在 LiteLLM 上使用。每個插件都會接收路由內容、加以擴充，然後在 router 做出最終決策之前將其傳給下一個插件。

這股推動力來自 autorouter 討論（#32168）：團隊希望將自己的訊號（語言偵測、網域分類、租戶政策、預算上限）層疊到路由之上，而不必等待每一項都進入核心。這個插件擴充功能讓團隊能在維持 LiteLLM 路由核心穩定的同時完成這些變更。

Auto Router v2 將複雜度、語義與自適應路由整合為單一 auto_router/complexity_router。現在只需一份設定即可涵蓋啟發式評分、LLM 分類、詞彙或語義關鍵字規則，以及以 Thompson sampling 抽樣的階層池。

這項推動來自社群。在 discussion #32168 中，使用者指出這三種路由策略都應該收斂成單一 Auto Router。使用可設定訊號與權重的單一路由器，能讓 API 保持簡潔，同時讓路由引擎在內部演進，而不是強迫您一開始就選定某種模式。

營運層面的另一半則來自 discussion #32172：可預測性在可除錯性上勝過聰明作法。將能力類別對應到模型的固定、版本化映射，才能在事後回答「為什麼今天這個回應成本高了 4 倍」。

在過去兩週，我們處理了兩個重大的產品品質問題：

1. MCP Gateway 沒有單一的憑證解析類別。
2. 透傳 API 的記憶體消耗過高。

在同一期間，我們總共推出了 134 個錯誤修正。這篇文章先介紹這兩個重大變更，接著說明其餘的 AI 工程與可靠性工作、完整細目，以及我們接下來要做什麼。

感謝所有參加我們 June town hall 的人。

這個月有三個數字最能代表：24 項安全修正、94 個 Bug 修正，以及 78 項功能提交。以下各節將逐一說明，並介紹我們對零已回報回歸的公開承諾，以及 LiteLLM 閘道逐步遷移至 Rust 的進展。

Harness 是提供者鎖定的下一個前沿。LiteLLM 的設計初衷是讓模型提供者之間能夠輕鬆切換。然而，隨著模型越來越飽和，下一個競爭領域就會變成 harness 與受管理的代理程式。為了讓您更容易在 harness 層切換提供者，我們推出 Lite-Harness SDK。這是一個簡單的 TypeScript+Python SDK，讓開發者能像切換模型一樣切換 harness。

感謝所有參加我們 5 月 town hall 的人。

我們涵蓋了安全強化、版本發布編號變更、新產品發布（MCP 工具集、on-behalf-of OAuth）、效能提升，以及我們迄今最大的一次投注——LiteLLM Agent Platform。

我們正在推出 LiteLLM Managed Agents Platform —— 一個簡單、可自行架設的基礎架構平台，用於在正式環境中執行多個代理程式。

感謝所有參加我們 4 月 town hall 的朋友。

我們在這次會議中分享了 CI/CD v2 的改進、產品穩定性工作，以及接下來在可靠性與產品藍圖上的優先事項。