4 篇文章 含有標籤「engineering」

最後更新：2026 年 6 月

在過去一年中，我們從使用者與社群聽到同樣的聲音：他們想要能執行的最快、最輕量的 AI 閘道。我們聽到了。現在我們正透過將 LiteLLM 遷移到 Rust 來回應，並承諾將額外負擔降到低於 1ms、記憶體低於 100MB 的可部署二進位檔。到了這次遷移完成時，您將擁有一個純 Rust 伺服器，能承載您 100% 的 AI 流量，且每個熱路徑操作（包含驗證與速率限制）都在 Rust 中執行。

之所以重要，是因為在真實負載下，CPU 與記憶體會隨著並行度上升，而 pods 會在最糟糕的時候被 OOM-kill。今天 LiteLLM Python proxy 在負載下的記憶體峰值約為 359MB，而這個成本會隨著您執行的每個 pod、區域與重試而倍增。

我們已經在基準測試中看到成效。Rust 閘道的吞吐量約為 15x（每秒 453 到 6,782 個請求），使用的記憶體約少 11x（359MB 到 32MB），且將每次請求的額外負擔從 Python 路徑上的約 7.5ms 降到約 0.05ms，遠低於我們承諾的 1ms。

您會得到什麼​

您部署單一 Rust 二進位檔。它使用約 65MB 的記憶體，閘道額外負擔維持在 1ms 以下，而您的設定中沒有任何東西會改變：相同的 config.yaml、相同的資料庫、相同的用戶端 API、相同的提供者。您保留 LiteLLM 對 100+ 個 LLM 提供者的涵蓋，並透過一個 OpenAI 相容 API 提供，包含 /chat/completions、/messages、/responses，以及 LiteLLM 今天支援的其他每個 LLM 端點，如今成為您能自行主機部署的最快、最輕量 LLM 閘道。

這不是 v2，也不是重寫。沒有新的主要版本需要遷移，也沒有任何東西要您更改。熱路徑下的執行階段會變得更快、更輕量，而您的設定會維持完全不變。

我們會以謹慎的方式發布。每條路由只有在通過我們完整的對等與端到端測試套件後才會移到 Rust，且會先在正式環境執行，然後下一條路由才開始。穩定性是優先事項，我們以每次發佈零回歸為目標。

我們的目標是用代理程式將公司的生產力提升 10 倍。

三週前，我們開始打造一個能夠承接 30% 工程票券的代理程式。以下是截至目前我們的所學。

最後更新：2026 年 4 月

企業級 AI 閘道部署幾乎每個請求都會經過 Redis：速率限制、快取查詢、支出追蹤。當 Redis 健康時，其延遲貢獻只有個位數毫秒 — 使用者幾乎感受不到。當它劣化時，正式環境 AI 閘道無論如何都需要保持運作。

在 100+ 個 pod 上大規模執行 LiteLLM，意味著必須在故障模式出現之前先為它們設計。簡單的情況是 Redis 完全中斷：快速失敗、轉而使用資料庫、持續提供請求。困難的情況 — 也是會讓閘道停擺的情況 — 是 緩慢的 Redis：仍可接受連線、仍有回應，但每次操作都要 20-30 秒才逾時。

CI/CD v2 現已於 LiteLLM 上線。

承接我們的 安全事件 路線圖，CI/CD v2 為 LiteLLM 導入了隔離環境、更強的安全防護欄，以及更安全的發佈分離。

有哪些變更​

• 安全掃描與單元測試在隔離環境中執行。
• 驗證與發佈分離到不同的儲存庫，讓攻擊者更難取得發佈憑證。
• PyPI 發佈採用 Trusted Publishing——這表示發佈時不會使用長效憑證。
• 不可變更的 Docker 發佈標籤——這表示發佈後無法竄改 Docker 發佈標籤 了解更多。注意：也規劃了 GHCR docker 發佈的相關工作。
• 使用 Cosign 進行 Docker 映像簽章——所有發佈映像都已簽署，因此使用者可以自行驗證它們確實來自我們。

驗證 Docker 映像簽章​

從 v1.83.0-nightly 開始，所有發布到 GHCR 的 LiteLLM Docker 映像都會使用 cosign 簽署。每個發佈都使用相同的金鑰簽署，該金鑰在 commit 0112e53 中引入。

使用固定的 commit hash 驗證（建議）：

commit hash 在密碼學上不可變，因此這是確保您使用原始簽署金鑰的最強方式：

cosign verify \
  --key https://raw.githubusercontent.com/BerriAI/litellm/0112e53046018d726492c814b3644b7d376029d0/cosign.pub \
  ghcr.io/berriai/litellm:<release-tag>

使用 release tag 驗證（方便）：

本儲存庫中的標籤受到保護，並解析為相同的金鑰。此選項較容易閱讀，但仰賴標籤保護規則：

cosign verify \
  --key https://raw.githubusercontent.com/BerriAI/litellm/<release-tag>/cosign.pub \
  ghcr.io/berriai/litellm:<release-tag>

請將 <release-tag> 替換為您要部署的版本（例如 v1.83.0-stable）。

預期輸出：

The following checks were performed on each of these signatures:
  - The cosign claims were validated
  - The signatures were verified against the specified public key

接下來是什麼​

接下來，我們計劃：

• 採用 OpenSSF（這是一組專案應遵守的安全標準，用來展現強健的安全態勢——了解更多）

  • 我們已將 Scorecard 和 Allstar 加入我們的 Github

• 將 SLSA Build Provenance 加入我們的 CI/CD pipeline——這表示我們允許使用者獨立驗證發佈確實來自我們，並防止發佈在公開後遭到靜默修改。

我們希望這將意味著您可以放心，您所使用的發佈是安全且確實來自我們的。

原則​

新的 CI/CD pipeline 反映了以下列出的原則，並設計得更安全且更可靠：

• 限制 每個套件可以存取的內容
• 減少 敏感環境變數的數量
• 避免 已遭入侵的套件
• 防止 發佈遭竄改

如何協助：​

協助我們規劃 4 月的穩定性衝刺——https://github.com/BerriAI/litellm/issues/24825