<!-- Canonical URL: https://ask.atlascloud.ai/pl/migrate-openrouter-requests-to-openai-compatible-api -->

# Co zmienia się przy migracji żądań OpenRouter do innego API zgodnego z OpenAI?

> Zmiana bazowego URL i klucza API to dopiero początek migracji z OpenRouter. Standardowe pola czatu często są przenośne, ale identyfikatory modeli, nagłówki i rozszerzenia routingu OpenRouter, fallbacki, streaming, rozliczanie użycia, dane multimodalne, błędy i limity szybkości trzeba przetestować za adapterem dostawcy.

<!-- Canonical URL: https://ask.atlascloud.ai/migrate-openrouter-requests-to-openai-compatible-api -->

# Co zmienia się przy migracji żądań OpenRouter do innego API zgodnego z OpenAI?

Dla prostej chat completion migracja może zacząć się od nowego bazowego URL, klucza API i ID modelu. Zachowanie produkcyjne wykracza jednak poza kształt żądania. Routing, nagłówki, slugi modeli, fallbacki, metadane i wybór dostawcy specyficzne dla OpenRouter wymagają świadomego zastąpienia, a streaming i wywołania narzędzi testów kontraktowych.

Traktuj zgodność z OpenAI jako wspólny dialekt transportu, nie obietnicę identycznych katalogów, rozszerzeń, rozliczeń i operacji.

## Zinwentaryzuj faktycznie używany kontrakt

Przeszukaj kod, konfigurację i logi pod kątem wszystkich pól wysyłanych do OpenRouter. Udokumentowana konfiguracja OpenAI SDK używa `https://openrouter.ai/api/v1`, uwierzytelniania bearer i opcjonalnych nagłówków atrybucji. Aplikacje mogą też używać rozszerzeń routingu i fallbacków.

Przed zmianą utwórz inwentarz:

| Obszar | Często przenośne | Zwykle wymaga sprawdzenia |
|---|---|---|
| Żądanie czatu | `messages`, temperatura, limit wyjścia | Nieobsługiwane parametry i wartości domyślne |
| Modele | Intencja aplikacji | Slug modelu dostawcy |
| Narzędzia | Nazwa funkcji i schemat JSON | Wywołania równoległe, strictness, streaming argumentów |
| Routing | Brak | Preferencje dostawcy, fallbacki, transforms |
| Nagłówki | Wzorzec autoryzacji | Atrybucja i metadane OpenRouter |
| Użycie | Liczby tokenów | Koszty, cache, lookup żądania |
| Operacje | Rodziny statusów HTTP | Limity, ponowienia, timeouty, treść błędów |

## Najpierw wprowadź adapter dostawcy

Nie rozrzucaj nowego URL i sluga modelu po kodzie. Ukryj różnice za jednym adapterem i wystaw aliasy aplikacyjne.

```python
from openai import OpenAI

def make_client(base_url: str, api_key: str) -> OpenAI:
    return OpenAI(base_url=base_url, api_key=api_key)

MODEL_MAP = {
    "coding_default": {
        "openrouter": "provider/model-slug",
        "target": "target-model-id",
    }
}
```

Adapter powinien także tłumaczyć pola opcjonalne, normalizować błędy i emitować wspólny schemat zdarzeń.

## Zastąp semantykę modeli i routingu

Zgodność z OpenAI nie standaryzuje identyfikatorów modeli. Zmapuj każdy alias aplikacji na model docelowy i sprawdź długość kontekstu, narzędzia, strukturalne wyjście, modalności i ceny w aktualnym katalogu.

OpenRouter obsługuje routing i fallbacki, które inna brama może wyrażać inaczej lub wcale. Zdecyduj, czy odtworzysz zasady w orkiestracji, użyjesz routera celu, czy celowo je usuniesz. Ciche zmiany mogą wpłynąć na koszt i jakość.

## Usuń lub przetłumacz rozszerzenia OpenRouter

Przejrzyj nagłówki i pola body specyficzne dla OpenRouter. Opcjonalne nagłówki atrybucji zwykle można usunąć. Preferencje dostawców, tablice fallbacków, plugins, transforms i sterowanie metadanymi wymagają jawnego mapowania.

W testach odrzucaj nieznane rozszerzenia. Ciche pominięcie pola może ukryć zmianę zachowania.

## Testuj kontrakt narzędzi i streamingu

Wywołania narzędzi często różnią nominalnie zgodne API. Testuj:

* akceptację nazw funkcji i schematów JSON;
* tryby tool choice i wywołania równoległe;
* przyrostowe zdarzenia argumentów;
* finish reasons i pola refusal;
* niepoprawne argumenty i ponowienia.

Dla streamingu porównuj sparsowane sekwencje zdarzeń, nie surowe fragmenty. Uwzględnij anulowanie, błąd w połowie, końcowe użycie, puste delty i ponawianie połączeń.

## Odbuduj księgowanie użycia i kosztów

OpenRouter dokumentuje metadane generacji z modelem, dostawcą, użyciem tokenów i kosztem całkowitym. Inna brama może zwracać użycie w completion, przez osobny endpoint albo wymagać wyceny po stronie klienta.

Normalizuj dane we własnej księdze:

```json
{
  "request_id": "internal_123",
  "provider_request_id": "external_456",
  "gateway": "target",
  "model": "resolved-model-id",
  "input_tokens": 1200,
  "output_tokens": 340,
  "cost_usd": 0.0123
}
```

Oddzielaj szacunki od uzgodnionych opłat. Przed migracją agentów produkcyjnych ponownie sprawdź egzekwowanie budżetu.

## Zweryfikuj kształty żądań multimodalnych

Obsługa obrazu, audio i wideo zależy od modelu i endpointu. Dwie bramy mogą obsługiwać modalność, ale różnić się schematem części treści, uploadem, dostępem URL, zadaniami asynchronicznymi lub obiektami wyjściowymi.

Zbuduj fixtures dla każdej używanej modalności. Udane żądanie tekstowe nie dowodzi zgodności mediów.

## Przetestuj zachowanie operacyjne

Zmierz nagłówki limitów, statusy do ponowienia, timeouty, kolejki, kontrolę regionów, idempotency, logowanie i wsparcie. Korzystaj z aktualnej dokumentacji celu.

Praktyczne wdrożenie ma cztery bramki:

1. Odtwórz offline złoty zestaw żądań.
2. Uruchom bezpieczny shadow traffic bez skutków dla użytkownika.
3. Włącz mały canary niskiego ryzyka.
4. Zwiększaj udział tylko przy zachowaniu progów błędów, opóźnień, kosztów i wyników.

Zachowaj jednoznaczny rollback, dopóki nowa ścieżka nie przejdzie reprezentatywnego obciążenia.

## Oceń, czy konsolidacja się opłaca

OpenRouter jest dobrym wyborem, gdy jego szeroki katalog LLM i kontrola routingu pasują do produktu. Brama pełnomodalna, taka jak Atlas Cloud, może uprościć stos przez jedną relację zgodną z OpenAI dla tekstu, obrazu i wideo. Obie opcje nadal wymagają testów modeli i funkcji.

Wybieraj na podstawie zmierzonych wymagań workloadu, nie najmniejszej różnicy w kodzie.

## Podsumowanie

Przy migracji ruchu OpenRouter zmień konfigurację klienta, a potem sprawdź każde niestandardowe założenie o modelach, routingu, narzędziach, streamingu, użyciu i operacjach. Adapter i złote testy utrzymują odwracalność i ujawniają regresje semantyczne.

## FAQ

### Czy mogę migrować z OpenRouter, zmieniając tylko base_url i api_key?

Czasem dla prostego żądania czatu, ale integracje produkcyjne zwykle zależą też od slugów modeli, routingu, nagłówków, streamingu, pól użycia lub semantyki fallbacków.

### Które pola OpenRouter najczęściej nie są przenośne?

Preferencje routingu dostawców, tablice fallbacków, nagłówki atrybucji, transforms, plugins i metadane OpenRouter to typowe punkty migracji. Trzymaj je poza podstawowym modelem żądania.

### Czy API zgodne z OpenAI używają tych samych nazw modeli?

Nie. Zgodność zwykle dotyczy kształtu żądania, a nie katalogu. Jawnie mapuj aliasy aplikacji na aktualne identyfikatory modeli każdej bramy.

### Jak testować streaming po migracji?

Zapisuj sekwencje zdarzeń dla fragmentów tekstu, argumentów narzędzi, finish reasons, użycia, anulowania i błędów. Porównuj zdarzenia po parsowaniu, nie surowe fragmenty bajtów.

### Jaki jest najbezpieczniejszy sposób wdrożenia migracji?

Użyj adaptera, odtwórz złoty zestaw żądań, uruchom bezpieczny shadow traffic, a następnie mały canary z progami wycofania dla błędów, opóźnień, kosztów i asercji wyników.

### Kiedy zespół powinien pozostać przy OpenRouter?

Gdy szeroki katalog LLM, kontrola routingu i istniejące narzędzia operacyjne są cenniejsze niż konsolidacja gdzie indziej. Decyzję opieraj na zmierzonych potrzebach, nie tylko deklaracjach zgodności.
