Model Not Found bei OpenAI-kompatiblen APIs: Ursachen, Lösungen und Debug-Checkliste

Sie haben Ihre Base-URL auf einen OpenAI-kompatiblen Anbieter umgestellt, eine Anfrage gesendet und folgende Antwort erhalten:

{
  "error": {
    "message": "The model `gpt-4o` does not exist or you do not have access to it.",
    "type": "invalid_request_error",
    "code": "model_not_found"
  }
}

Dies ist einer der häufigsten Fehler beim Wechsel zwischen OpenAI-kompatiblen API-Anbietern. Das Anfrageformat ist kompatibel — aber die Model-ID ist es nicht.

„OpenAI-kompatibel" bedeutet, dass das Anfrageformat funktioniert. Es bedeutet nicht, dass jede Model-ID bei jedem Anbieter identisch ist.

Kurzfassung

• „Model not found" bedeutet in der Regel, dass die gesendete Model-ID nicht mit der erwarteten ID des Anbieters übereinstimmt.
• OpenAI-kompatibel ≠ gleiche Model-IDs. Jeder Anbieter hat seine eigene Benennung.
• Prüfen Sie immer: (1) Base-URL, (2) Model-ID, (3) API-Key-Geltungsbereich, (4) Modellverfügbarkeit.
• Nutzen Sie die folgende Debug-Matrix, um die Ursache in unter 5 Minuten einzugrenzen.

Warum dieser Fehler auftritt

Die Kompatibilität endet jedoch beim Anfrageformat. Die Model-IDs sind anbieterspezifisch:

Debug-Matrix: Ursache in 5 Minuten eingrenzen

Arbeiten Sie diese Checkliste der Reihe nach ab. Stoppen Sie, sobald Sie die Abweichung gefunden haben.

Die häufigsten Abweichungen

Abweichung 1: Model-ID nach dem Wechsel der Base-URL nicht geändert

Dies ist die mit Abstand häufigste Ursache. Sie migrieren von OpenAI zu einem anderen Anbieter:

# Vorher: direkt OpenAI
client = OpenAI(api_key="sk-...")

# Nachher: zu einem anderen Anbieter gewechselt, aber dieselbe Model-ID beibehalten
client = OpenAI(
    api_key="your-provider-key",
    base_url="https://api.another-provider.com/v1"  # Geändert
)

response = client.chat.completions.create(
    model="gpt-4o",  # ← Diese Model-ID funktioniert möglicherweise nicht beim neuen Anbieter
    messages=[{"role": "user", "content": "Hello"}]
)

Abweichung 2: Anbieter verwendet Namespace-basierte Model-IDs

Einige Anbieter versehen Model-IDs mit dem ursprünglichen Herstellerpräfix:

# OpenAI direkt
model = "gpt-4o"

# OpenRouter
model = "openai/gpt-4o"

# Manche Anbieter verwenden eigene Aliase
model = "gpt-4o-2024-08-06"

Abweichung 3: Modell bei diesem Anbieter nicht verfügbar

Nicht jeder OpenAI-kompatible Anbieter unterstützt jedes Modell:

• Ein Anbieter unterstützt möglicherweise Claude, aber keine GPT-Modelle
• Ein Anbieter unterstützt möglicherweise Textmodelle, aber keine Bild- oder Videomodelle
• Ein neu veröffentlichtes Modell ist möglicherweise nicht überall am ersten Tag verfügbar

Abweichung 4: Modell eingestellt oder umbenannt

KI-Modelle werden häufig aktualisiert. Eine Model-ID, die letzten Monat funktioniert hat, kann eingestellt sein:

gpt-4-turbo → kann je nach Anbieter weiterleiten oder fehlschlagen
claude-3-opus-20240229 → ältere Version, möglicherweise ersetzt

So überprüfen Sie die richtige Model-ID

Option A: Models-Endpunkt aufrufen

curl https://api.your-provider.com/v1/models \
  -H "Authorization: Bearer YOUR_API_KEY"

Dies gibt die Liste der für Ihr Konto verfügbaren Modelle zurück. Suchen Sie in der Antwort nach Ihrem Zielmodell.

Option B: Dokumentation des Anbieters prüfen

Jeder seriöse Anbieter hat eine Modelllistenseite. Überprüfen Sie vor dem Wechsel:

1. Die exakte Model-ID-Zeichenkette
2. Ob ein Namespace-Präfix erforderlich ist
3. Ob das Modell in Ihrem Tarif verfügbar ist
4. Ob das Modell in Ihrer Region verfügbar ist

Option C: Minimale Testanfrage senden

curl https://api.your-provider.com/v1/chat/completions \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "your-model-id",
    "messages": [{"role": "user", "content": "test"}],
    "max_tokens": 5
  }'

Wenn eine gültige Antwort zurückkommt, ist Ihre Model-ID korrekt. Wenn „model not found" zurückgegeben wird, verwenden Sie die vom Anbieter empfohlene Model-ID.

Robuste Modellauswahl aufbauen

In Produktionssystemen sollten Model-ID-Abweichungen keine harten Fehler verursachen. Folgende Muster helfen:

Muster 1: Model-ID-Zuordnungsschicht

Pflegen Sie eine Zuordnung zwischen Ihren internen Modellnamen und anbieterspezifischen IDs:

MODEL_MAP = {
    "fast-chat": {
        "openai": "gpt-4o-mini",
        "openrouter": "openai/gpt-4o-mini",
        "evolink": "gpt-4o-mini",
    },
    "strong-chat": {
        "openai": "gpt-4o",
        "openrouter": "openai/gpt-4o",
        "evolink": "gpt-4o",
    },
    "reasoning": {
        "openai": "o3",
        "openrouter": "openai/o3",
        "evolink": "o3",
    }
}

def get_model_id(capability: str, provider: str) -> str:
    return MODEL_MAP[capability][provider]

Muster 2: Einheitliche API mit normalisierten Model-IDs verwenden

Anstatt eine eigene Zuordnungsschicht zu pflegen, können Sie ein Gateway verwenden, das standardisierte Model-IDs akzeptiert und das Provider-Routing intern übernimmt.

Mit EvoLink können Sie vertraute Model-IDs verwenden, ohne sich um anbieterspezifische Benennungen kümmern zu müssen:

from openai import OpenAI

client = OpenAI(
    api_key="your-evolink-key",
    base_url="https://api.evolink.ai/v1"
)

# Standard-Model-IDs verwenden — EvoLink übernimmt die Zuordnung
response = client.chat.completions.create(
    model="gpt-4o",
    messages=[{"role": "user", "content": "Hello"}]
)

Oder lassen Sie den Smart Router das beste Modell für Ihre Arbeitslast wählen:

response = client.chat.completions.create(
    model="evolink/auto",
    messages=[{"role": "user", "content": "Hello"}]
)

Muster 3: Model-IDs beim Start validieren

Warten Sie nicht auf eine Benutzeranfrage, um zu entdecken, dass eine Model-ID falsch ist:

async def validate_models_on_startup(client, required_models: list[str]):
    """Ruft /v1/models beim Start auf und überprüft, ob alle erforderlichen Modelle existieren."""
    available = await client.models.list()
    available_ids = {m.id for m in available.data}

    for model in required_models:
        if model not in available_ids:
            raise RuntimeError(
                f"Model '{model}' not found on provider. "
                f"Available: {sorted(available_ids)}"
            )

Kurzreferenz: OpenAI-kompatibel heißt nicht identisch

Dieser Unterschied ist die Hauptursache der meisten „model not found"-Fehler beim Anbieterwechsel.

Verwandte Artikel

• Fix OpenRouter 429 "Provider Returned Error" — wenn das Modell gefunden wird, aber der Anbieter einen Fehler zurückgibt
• Best OpenRouter Alternatives in 2026 — Anbieter und deren Modellabdeckung vergleichen
• How to Reduce 429 Errors in Agent Workloads — Rate Limits handhaben, nachdem Sie Model-IDs korrigiert haben

FAQ

Warum funktioniert „gpt-4o" bei OpenAI, aber nicht bei meinem neuen Anbieter?

Wie finde ich die richtige Model-ID für meinen Anbieter?

Kann ich dieselbe Model-ID bei allen OpenAI-kompatiblen Anbietern verwenden?

Nicht zuverlässig. Während einige Anbieter dieselben IDs wie OpenAI akzeptieren, verwenden viele andere Namenskonventionen. Pflegen Sie entweder eine Zuordnungsschicht oder verwenden Sie ein Gateway wie EvoLink, das Model-IDs für Sie normalisiert.

Was, wenn die Model-ID gestern noch funktioniert hat, aber heute nicht mehr?

Das Modell wurde möglicherweise eingestellt, umbenannt oder aus Ihrem Tarif entfernt. Prüfen Sie das Changelog und die Ankündigungen des Anbieters. Der Modell-Lebenszyklus ist bei KI schneller als bei herkömmlichen APIs.

Ist „model not found" immer ein Model-ID-Problem?

Meistens, aber nicht immer. Es kann auch bedeuten: (1) Ihr API-Key hat keinen Zugriff auf dieses Modell, (2) das Modell ist in Ihrer Region nicht verfügbar, oder (3) das Modell erfordert einen höheren Abonnementtarif.

Wie verhindere ich Model-Not-Found-Fehler in der Produktion?

Drei Strategien: (1) Model-IDs beim Anwendungsstart validieren, (2) eine Model-ID-Zuordnungsschicht pflegen oder ein normalisierendes Gateway verwenden, (3) Fallback-Logik implementieren, die ein alternatives Modell versucht, wenn das primäre „not found" zurückgibt.