Zum Hauptinhalt springen

Lebenszyklus einer Anfrage

High-Level-Architektur​

Anfrage-Workflow​

  1. Benutzer sendet Anfrage: Der Prozess beginnt, wenn ein Benutzer eine Anfrage an den LiteLLM Proxy Server (Gateway) sendet.

  2. Virtuelle Schlüssel: Zu diesem Zeitpunkt wird das Bearer-Token in der Anfrage überprüft, um sicherzustellen, dass es gültig und im Rahmen seines Budgets ist. Hier ist eine Liste der Prüfungen, die für jede Anfrage durchgeführt werden

    • 2.1 Prüfen, ob der virtuelle Schlüssel im Redis-Cache oder im In-Memory-Cache vorhanden ist
    • 2.2 Wenn nicht im Cache, virtuellen Schlüssel in der DB nachschlagen

  3. Ratenbegrenzung: Der MaxParallelRequestsHandler überprüft die Ratenbegrenzung (rpm/tpm) für die folgenden Komponenten

    • Globale Server-Ratenbegrenzung
    • Ratenbegrenzung des virtuellen Schlüssels
    • Benutzer-Ratenbegrenzung
    • Team-Limit

  4. LiteLLM proxy_server.py: Enthält die Endpunkte /chat/completions und /embeddings. Anfragen an diese Endpunkte werden über den LiteLLM Router geleitet

  5. LiteLLM Router: Der LiteLLM Router kümmert sich um Lastverteilung, Fallbacks und Wiederholungsversuche für LLM-API-Bereitstellungen.

  6. litellm.completion() / litellm.embedding(): Das litellm Python SDK wird verwendet, um die LLM im OpenAI API-Format aufzurufen (Übersetzung und Parameterzuordnung)

  7. Nachbearbeitung der Anfrage: Nachdem die Antwort an den Client zurückgesendet wurde, werden die folgenden asynchronen Aufgaben ausgeführt

Häufig gestellte Fragen​

  1. Ist eine DB-Transaktion an den Lebenszyklus der Anfrage gebunden?
    • Nein, eine DB-Transaktion ist nicht an den Lebenszyklus einer Anfrage gebunden.
    • Die Prüfung, ob ein virtueller Schlüssel gültig ist, hängt von einem DB-Lesevorgang ab, wenn er nicht im Cache ist.
    • Alle anderen DB-Transaktionen sind asynchron in Hintergrundaufgaben