Skip to main content
GoModel obsługuje to samo API kompatybilne z OpenAI co proxy LiteLLM, więc większość aplikacji potrzebuje tylko nowego bazowego URL-a i klucza. Praca dotyczy konfiguracji gatewaya, a większość z niej wykonuje gomodel migrate litellm.

​
1. Konwersja konfiguracji

Najpierw wykonaj próbne uruchomienie (dry run). Wypisuje ono raport z migracji i wygenerowaną konfigurację i niczego nie zapisuje:
Następnie zapisz pliki:
Z Dockerem (obraz działa jako użytkownik inny niż root, więc przekaż swojego, aby móc zapisywać w zamontowanym katalogu):
--out zapisuje trzy pliki i odmawia ich nadpisania, chyba że przekażesz --force: Referencje os.environ/NAME stają się ${NAME}, więc środowisko, w którym już uruchamiasz LiteLLM, nadal działa. Pliki z include: są uwzględniane.

​
2. Przegląd raportu

Przeczytaj MIGRATION_REPORT.md, zanim skierujesz ruch. Raport zawiera trzy listy:
  • Review before switching traffic: rzeczy, które musisz dokończyć, takie jak guardrails, grupy dostępu do modeli czy callback Langfuse. Guardrails w GoModel są wyłączone, dopóki ich nie skonfigurujesz.
  • Not migrated: ustawienia bez odpowiednika w GoModel, wymienione pojedynczo. Nic nie jest pomijane po cichu.
  • Behavior changes: ustawienia, które zostały przekonwertowane, ale zachowują się nieco inaczej, na przykład strategie routingu.

​
3. Uruchomienie GoModel obok LiteLLM

Uruchom GoModel z wygenerowanymi plikami na innym porcie. Dodaj zmienne wymienione w raporcie w sekcji Environment (te, które LiteLLM już odczytywał przez os.environ/) do .env, tworząc ten plik, jeśli konwerter go nie zapisał. GoModel odmawia uruchomienia, dopóki zmienna odczytywana przez server.master_key nie jest ustawiona. Następnie wyślij kilka testowych requestów z modelami, których używają Twoi klienci:
compose.yaml
Ładuj .env przez env_file w Compose (lub przez wbudowany loader .env w GoModel, gdy uruchamiasz binarkę z tego katalogu). docker run --env-file odczytuje wartości dosłownie, więc zachowałby cudzysłowy, którymi .env otacza wartości takie jak dane uwierzytelniające w postaci JSON. Gdy uruchamiasz binarkę bezpośrednio, zmienna już wyeksportowana w Twojej powłoce, na przykład OPENAI_API_KEY, ma pierwszeństwo przed tą samą nazwą w .env.
GET /v1/models wypisuje te same nazwy modeli co LiteLLM. Następnie przenoś klientów po jednym zespole naraz.

​
4. Importowanie kluczy, zespołów i budżetów

LiteLLM przechowuje virtual keys, zespoły, użytkowników, organizacje i ich budżety w swojej bazie PostgreSQL. To samo polecenie je odczytuje, gdy zna bazę danych: z --database-url, w przeciwnym razie z general_settings.database_url w konfiguracji, a w ostateczności z DATABASE_URL. Wyłącznie odczytuje dane, w transakcji tylko do odczytu. Bez URL-a bazy danych konwertuje tylko konfigurację. Gdy GoModel działa już z przekonwertowaną konfiguracją, zaimportuj do niego dane:
Polecenie uwierzytelnia się za pomocą GOMODEL_MASTER_KEY, a w przeciwnym razie master key LiteLLM, i wymaga https dla GoModel na innej maszynie (--allow-http w zaufanej sieci, na przykład w sieci Compose). Bez --gomodel-url jedynie wypisuje import w raporcie. Uruchamiaj je ponownie, dopóki oba gatewaye działają równolegle: synchronizuje GoModel z LiteLLM. Klucze dostają aktualną ścieżkę, etykiety, dozwolone modele i datę wygaśnięcia, a klucze, które LiteLLM w międzyczasie zablokował lub które wygasły, są dezaktywowane. Dostęp do dashboardu przyznany i klucze dezaktywowane w GoModel pozostają bez zmian. Przed zapisaniem czegokolwiek polecenie sprawdza, czy w GoModel włączone są funkcje, których import potrzebuje, takie jak budżety (wymagające śledzenia użycia) i rate limity, i zatrzymuje się, jeśli któraś jest wyłączona. Reguły dla ścieżki są zapisywane przed jej kluczami; jeśli któraś zostanie odrzucona, te klucze są wstrzymywane, a polecenie kończy się błędem. Każdy klucz zachowuje swoją wartość sk-...: LiteLLM przechowuje tylko jej hash SHA-256, a GoModel importuje ten hash, więc GoModel nigdy nie ma do czynienia z samym kluczem. Wszystko inne trafia na ścieżkę użytkownika: Dostęp do modeli działa według reguł LiteLLM. Lista modeli użytkownika obejmuje jego klucze osobiste, ale nie klucze zespołów, które posiada, ponieważ tylko klucze osobiste znajdują się pod /users/<user>. Nazwy modeli są rozwiązywane na modele providerów, które za nimi stoją, ponieważ GoModel sprawdza model, na który rozwiązuje się model wirtualny; jeśli później skierujesz model wirtualny na inne modele, zaktualizuj dozwolone modele, które go wymieniały. max_budget lub rate limit równy 0 w LiteLLM odrzuca każdy request. Limity w GoModel muszą być dodatnie, więc taka ścieżka dostaje zamiast tego politykę modeli, do której nie pasuje żaden model. budget_duration jest mapowane na hourly, daily, weekly lub monthly (30d i 1mo stają się monthly, które resetuje się w miesiącach kalendarzowych), a inne okresy na stałe okno. Nie są importowane i są wymienione w raporcie:
  • zablokowane lub wygasłe klucze oraz klucze zablokowanych zespołów (dezaktywowane, jeśli wcześniejsze uruchomienie je zaimportowało);
  • budżety bez budget_duration: budżety w GoModel resetują się co okres;
  • wydatki: budżety startują od zera, a raport pokazuje obok każdego z nich bieżące wydatki w LiteLLM;
  • budżety członków zespołów oraz budżety i limity per model.

​
Co zmienia się dla klientów

​
Jak mapowane są ustawienia

Nazwy providerów są zgodne z konwencjami zmiennych środowiskowych GoModel: deployment używający domyślnej zmiennej klucza LiteLLM (OPENAI_API_KEY) staje się providerem openai, deployment odczytujący OPENAI_EU_API_KEY staje się openai-eu, a każdy deployment Azure staje się osobnym providerem, na przykład azure-gpt-4o-prod. Providery, których GoModel jeszcze nie obsługuje, takie jak Replicate czy SageMaker, są wymienione w raporcie w sekcji Not migrated.
Ostatnia modyfikacja 24 października 2026