gomodel migrate litellm erledigt den Großteil davon.
1. Die Konfiguration konvertieren
Führen Sie zuerst einen Probelauf (Dry Run) durch. Er gibt den Migrationsbericht und die erzeugte Konfiguration aus und schreibt nichts:--out schreibt drei Dateien und verweigert das Überschreiben, sofern Sie nicht
--force übergeben:
os.environ/NAME-Referenzen werden zu ${NAME}, sodass die Umgebung, mit der
Sie LiteLLM bereits betreiben, weiterhin funktioniert. include:-Dateien werden
mitverarbeitet.
2. Den Bericht prüfen
Lesen SieMIGRATION_REPORT.md, bevor Sie Traffic senden. Der Bericht enthält
drei Listen:
- Review before switching traffic: Dinge, die Sie abschließen müssen, etwa Guardrails, Model Access Groups oder einen Langfuse-Callback. Guardrails in GoModel sind deaktiviert, bis Sie sie konfigurieren.
- Not migrated: Einstellungen ohne Entsprechung in GoModel, einzeln aufgeführt. Nichts wird stillschweigend verworfen.
- Behavior changes: Einstellungen, die konvertiert wurden, sich aber etwas anders verhalten, etwa Routing-Strategien.
3. GoModel neben LiteLLM betreiben
Starten Sie GoModel mit den erzeugten Dateien auf einem anderen Port. Fügen Sie die im Bericht unter Environment aufgeführten Variablen (diejenigen, die LiteLLM bereits mitos.environ/ gelesen hat) zu .env hinzu und legen Sie die
Datei an, falls der Konverter keine geschrieben hat. GoModel verweigert den
Start, solange die Variable, die server.master_key liest, nicht gesetzt ist.
Senden Sie dann einige Test-Requests mit den Modellen, die Ihre Clients
verwenden:
compose.yaml
.env über env_file in Compose (oder über den eigenen .env-Loader
von GoModel, wenn Sie das Binary aus diesem Verzeichnis starten).
docker run --env-file liest Werte wörtlich und würde daher die
Anführungszeichen beibehalten, die .env um Werte wie Inline-JSON-Zugangsdaten
setzt. Wenn Sie das Binary direkt ausführen, hat eine bereits in Ihrer Shell
exportierte Variable wie OPENAI_API_KEY Vorrang vor demselben Namen in .env.
GET /v1/models listet dieselben Modellnamen auf wie LiteLLM. Stellen Sie dann
die Clients Team für Team um.
4. Keys, Teams und Budgets importieren
LiteLLM speichert Virtual Keys, Teams, Benutzer, Organisationen und deren Budgets in seiner PostgreSQL-Datenbank. Derselbe Befehl liest sie ein, wenn er die Datenbank kennt:--database-url, andernfalls general_settings.database_url
aus der Konfiguration, andernfalls DATABASE_URL. Er liest nur, und zwar
innerhalb einer schreibgeschützten Transaktion. Ohne Datenbank-URL konvertiert
er nur die Konfiguration.
Sobald GoModel mit der konvertierten Konfiguration läuft, importieren Sie in die
laufende Instanz:
GOMODEL_MASTER_KEY, andernfalls mit dem
Master-Key von LiteLLM, und benötigt https für ein GoModel auf einem anderen
Rechner (--allow-http in einem vertrauenswürdigen Netzwerk, etwa einem
Compose-Netzwerk). Ohne --gomodel-url führt er den Import nur im Bericht auf.
Führen Sie ihn erneut aus, während beide Gateways parallel laufen: Er bringt
GoModel auf den aktuellen Stand von LiteLLM. Keys erhalten ihren aktuellen Pfad,
ihre Labels, erlaubten Modelle und ihr Ablaufdatum, und Keys, die LiteLLM
inzwischen gesperrt hat oder die abgelaufen sind, werden deaktiviert. In GoModel
gewährter Dashboard-Zugriff und dort deaktivierte Keys bleiben unverändert.
Bevor der Befehl etwas schreibt, prüft er, ob in GoModel die für den Import
benötigten Features aktiviert sind, etwa Budgets (die die Nutzungserfassung
voraussetzen) und Rate-Limits, und bricht ab, wenn eines davon ausgeschaltet
ist. Regeln für einen Pfad werden vor dessen Keys geschrieben; wird eine Regel
abgelehnt, werden diese Keys zurückgehalten, und der Befehl endet mit einem
Fehler.
Jeder Key behält seinen sk-...-Wert: LiteLLM speichert davon nur einen
SHA-256-Hash, und GoModel
importiert diesen Hash,
sodass GoModel den Key selbst nie verarbeitet. Alles andere landet auf einem
User Path:
Der Modellzugriff folgt den Regeln von LiteLLM. Die Modellliste eines Benutzers
gilt für dessen persönliche Keys, nicht für die Team-Keys, die er besitzt, da nur
persönliche Keys unter
/users/<user> liegen. Modellnamen werden in die
dahinterliegenden Provider-Modelle aufgelöst, da GoModel das Modell prüft, in das
ein virtuelles Modell aufgelöst wird; wenn Sie ein virtuelles Modell später auf
andere Modelle richten, aktualisieren Sie die erlaubten Modelle, die es genannt
haben.
Ein max_budget oder Rate-Limit von 0 lehnt in LiteLLM jeden Request ab.
Limits in GoModel müssen positiv sein, daher erhält dieser Pfad stattdessen eine
Modellrichtlinie, auf die kein Modell passt.
budget_duration wird auf hourly, daily, weekly oder monthly abgebildet
(30d und 1mo werden beide zu monthly, das nach Kalendermonaten
zurückgesetzt wird), andere Dauern auf ein festes Zeitfenster. Nicht importiert
und im Bericht aufgeführt werden:
- gesperrte oder abgelaufene Keys sowie Keys gesperrter Teams (deaktiviert, falls ein früherer Lauf sie importiert hat);
- Budgets ohne
budget_duration: Budgets in GoModel werden in jedem Zeitraum zurückgesetzt; - Ausgaben: Budgets starten bei null, und der Bericht zeigt die aktuellen Ausgaben aus LiteLLM neben jedem Budget an;
- Budgets von Teammitgliedern sowie Budgets und Limits pro Modell.
Was sich für Clients ändert
Zuordnung der Einstellungen
Provider-Namen folgen den Umgebungskonventionen von GoModel: Ein Deployment, das
die Standard-Key-Variable von LiteLLM (
OPENAI_API_KEY) verwendet, wird zum
Provider openai, eines, das OPENAI_EU_API_KEY liest, wird zu openai-eu, und
jedes Azure-Deployment wird zu einem eigenen Provider, etwa azure-gpt-4o-prod.
Provider, die GoModel noch nicht unterstützt, etwa Replicate oder SageMaker,
werden im Bericht unter Not migrated aufgeführt.