一個請求的生命週期

高階架構

Clients (OpenAI SDK, LangChain, curl)

Authorization: Bearer sk-...

LiteLLM Gateway:4000

1

Auth and budget checksvirtual key: cache first, database on miss

2

Rate limitingrpm / tpm for key, user, team, and server

PostgreSQLkeys, teams, spend

Rediskey cache, rate-limit counters

3

Routerload balancing, fallbacks, retries

4

Provider translationlitellm SDK, OpenAI format in and out

provider-native request

LLM providers

OpenAIAnthropicBedrockVertex100+ more

After the response is returned to the client, spend logging, rate-limit accounting, and logging callbacks all run as asynchronous background tasks; no database write sits in the request path.

請求流程

1. 使用者送出請求：流程在使用者向 LiteLLM Proxy Server（Gateway）送出請求時開始。

2. 虛擬金鑰：在這個階段，會檢查請求中的 Bearer 代幣，以確保其有效且未超出預算。這裡是每個請求執行的檢查清單

   • 2.1 檢查 Virtual Key 是否存在於 Redis Cache 或 In Memory Cache
   • 2.2 如果不在快取中，則在 DB 中查找 Virtual Key

3. 速率限制：[https://github.com/BerriAI/litellm/blob/main/litellm/proxy/hooks/parallel_request_limiter_v3.py] 會檢查以下元件的 速率限制（rpm/tpm）：

   • 全域伺服器速率限制
   • Virtual Key 速率限制
   • 使用者速率限制
   • Team 限制

4. LiteLLM proxy_server.py：包含 /chat/completions 和 /embeddings 端點。對這些端點的請求會透過 LiteLLM Router 傳送

5. LiteLLM Router：LiteLLM Router 會處理 LLM API 部署的負載平衡、備援與重試。

6. litellm.completion() / litellm.embedding(): litellm Python SDK 用於以 OpenAI API 格式呼叫 LLM（轉換與參數對應）

7. 請求後處理：在回應傳回給用戶端後，會執行以下 非同步 任務：

   • 記錄到 Lunary、MLflow、LangFuse 或其他記錄目的地
   • parallel request limiter 會更新以下項目的 rpm/tpm 使用量：
     • 全域伺服器速率限制
     • Virtual Key 速率限制
     • 使用者速率限制
     • Team 限制
   • _ProxyDBLogger 會更新 LiteLLM 資料庫中的支出／使用量。以下是每個請求在 DB 中追蹤的所有內容

路由器：備援與重試

Unified call.completion, .embeddings, and every other unified endpoint

1

function_with_fallbackscatches failures; moves to the next model group in fallbacks

2

function_with_retriesretries on another available deployment in the same group

3

litellm.completionmakes the provider API call

model group: gpt-4odeployments sharing one model_name, load balanced

deployment 1deployment 2deployment 3

Retries stay inside the model group that failed; fallbacks leave it for the next group in your fallbacks configuration.

上方步驟 5 會將請求交給 LiteLLM Router，其負責負載平衡、備援與重試。所有統一端點（.completion、.embeddings 等）都以相同方式流經它。

請求首先進入 function_with_fallbacks，它會以 try-except 包裝呼叫，以便在主要部署失敗時備援到另一個部署。接著會傳遞到 function_with_retries，它會再次包裝呼叫，並在請求失敗時，對同一模型群組中的可用部署進行重試。最後，function_with_retries 會呼叫像 litellm.completion 或 litellm.embeddings 這類基礎的 litellm 統一函式，實際向 LLM API 發出請求。

model_group 是一組共享相同 model_name 的 LLM API 部署，並可在其之間進行負載平衡。

圖片 URL 處理

Request contains an image URL

Does the target provider accept URLs?

Yespass through

URL forwarded unchangedprovider fetches the image itself

Noconvert

1

Download the imageup to 50MB (MAX_IMAGE_URL_DOWNLOAD_SIZE_MB)

2

Send base64 to the providerconversion cached, up to 10 images in memory

有些 LLM API 不接受圖片 URL，但接受 base64 字串。對於這些 API，LiteLLM 會偵測請求中的 URL，檢查目標 API 是否支援 URL；若不支援，則會下載圖片並改為將 base64 字串傳送給提供者。最多可將 10 張已轉換圖片快取於記憶體中，以降低重複呼叫的延遲，而單次下載上限為 50MB（可透過 MAX_IMAGE_URL_DOWNLOAD_SIZE_MB 設定）。

常見問題

1. DB 交易是否與請求的生命週期綁定？
   • 否，DB 交易不會與請求的生命週期綁定。
   • 虛擬金鑰是否有效的檢查，若不在快取中，會依賴 DB 讀取。
   • 其他所有 DB 交易都會在背景工作中非同步執行