OpenRouter vs. direkter Zugriff: So wählen Sie die Art Ihrer LLM-Aufrufe

Die drei Wege, einen LLM-Aufruf umzusetzen

1) Direkte Anbieter-API

Sie integrieren den Endpunkt eines einzelnen Anbieters und übernehmen den Rest: Wiederholungsversuche, Fallbacks, Nutzungserfassung, Schlüsselrotation und Failover.

Das ist der unkomplizierteste Weg, wenn:

• Sie bereits wissen, welches Modell Sie verwenden möchten,
• Latenz wichtig ist,
• Compliance eine kürzere Anbieterkette verlangt,
• und Ihr Anfrageaufkommen stabil genug ist, um innerhalb der Limits eines einzigen Anbieters zu planen.

2) Gateway / Aggregator / Relay

Sie senden Anfragen an eine Zwischenschicht, die sie an einen von vielen Anbietern weiterleitet. OpenRouter ist das bekannteste Beispiel, doch das Muster geht über ein einzelnes Unternehmen hinaus.

Das ist attraktiv, wenn:

• Sie über eine einzige Integration verschiedene Modelle nutzen möchten,
• Sie Fallback-Routing benötigen,
• Sie häufig mit Modellen experimentieren,
• oder Sie nicht mehrere Anbieter-SDKs und Abrechnungskonten verwalten möchten.

3) Selbst hosten

Sie betreiben ein offenes Modell auf Ihrer eigenen Infrastruktur, in der Regel hinter Ihrem eigenen Router.

Das ist die beste Wahl, wenn:

• die Kontrolle über Ihre Daten nicht verhandelbar ist,
• das Volumen hoch genug ist, um die Hardware auszulasten,
• oder Sie vorhersehbare Kosten pro Token benötigen und den Betriebsaufwand tragen können.

Was sich in der Praxis ändert

Diesen Punkt übersehen viele: Die beste Wahl hängt in der Regel nicht allein vom reinen Token-Preis ab. Es geht um die gesamte Kette möglicher Ausfälle.

Die Tabelle verdeckt eine wichtige Wahrheit: Ein Gateway spart selten auf magische Weise Geld. Es spart Geld, wenn es übermäßige Komplexität verhindert, Ausfallzeiten reduziert oder Aufgaben automatisch an das günstigste ausreichend gute Modell weiterleiten lässt.

Wo sich die Kosten tatsächlich verändern

Wenn Sie für alles ein einziges Modell verwenden, sind direkte Aufrufe oft am einfachsten und günstigsten. Die meisten realen Systeme sind jedoch komplexer:

• Der Chat im Produkt verwendet ein Premiummodell,
• Support-Entwürfe verwenden ein günstigeres Modell,
• Zusammenfassungen verwenden ein kleines, schnelles Modell,
• und Lastspitzen erfordern zusätzliche Kapazität.

Hier kann ein Relay helfen. Nicht, weil seine Listenpreise niedriger sind, sondern weil es Ihnen ermöglicht, Routing-Entscheidungen zentral zu treffen.

Eine einfache Richtlinie könnte so aussehen:

{
  "primary": "anthropic/claude-sonnet-4.6",
  "fallbacks": [
    "openai/gpt-5.5",
    "google/gemini-3"
  ],
  "cheap_path": "openai/haiku-class",
  "timeout_ms": 8000,
  "retry_on": ["rate_limit", "timeout", "upstream_5xx"]
}

Diese Konfiguration ist nicht anbieterspezifisch; sie zeigt die Struktur eines sinnvoll aufgebauten Routers. In der Praxis entstehen Einsparungen dadurch, dass Sie Verschwendung vermeiden:

• Senden Sie nicht jede Extraktionsaufgabe an Ihr teuerstes Modell,
• wiederholen Sie Anfragen an einen unzuverlässigen Anbieter nicht endlos,
• halten Sie nicht eine zweite Integration nur für die 2% des Traffics am Leben, die freitags Lastspitzen verursachen.

Ein häufiger Fallstrick: Wenn Ihre App Tool-Aufrufe oder Seiteneffekte hat, können Wiederholungsversuche Aktionen doppelt ausführen. Wenn ein Gateway eine Anfrage nach einem Timeout wiederholt, kann das Modell denselben Funktionsaufruf erneut ausgeben. Ohne Idempotenzschlüssel und sorgfältig gestaltete Tools wird aus einem „hilfreichen Fallback“ ein „Ticket doppelt erstellt“ oder eine „Zahlung zweimal abgebucht“.

Wann ein Gateway wirklich hilft

Ich würde zu einem Aggregator oder Relay greifen, wenn mindestens einer dieser Punkte zutrifft:

• Sie lernen Ihre Arbeitslast noch kennen. Am Anfang wissen Sie nicht, ob GPT-5.5, Claude Opus 4.8, Sonnet 4.6, Gemini 3 oder ein offenes Modell für Ihre Aufgabe am besten geeignet ist.
• Sie möchten nach Aufgabe routen, nicht nach Anbieter. Ein Klassifikator kann kurze Prompts an ein günstiges, schnelles Modell senden und Aufgaben mit langem Kontext an ein Modell wie Fable 5, wenn es tatsächlich besser dafür geeignet ist.
• Sie brauchen eine schnelle Fallback-Lösung. Wenn ein Anbieter beginnt, Anfragen durch Ratenbegrenzungen einzuschränken, kann das Relay den Traffic verlagern, bevor Ihre Nutzer es bemerken.
• Sie möchten keine fünf Abrechnungssysteme. Eine Rechnung und eine Integration sind einfacher als das Jonglieren mit mehreren Schlüsseln, Kontingenten und Ausgaben-Dashboards.
• Sie benötigen eine Abstraktionsschicht für mandantenfähige Produkte. Ein Gateway ermöglicht Ihnen, Anbieter im Hintergrund auszutauschen, ohne Ihre App neu zu schreiben.

Das ist besonders nützlich, wenn Ihr Team klein ist. Ich habe erlebt, dass Startup-Teams mehr Zeit mit der Implementierung anbieterspezifischer Wiederholungslogik verbracht haben als damit, Mehrwert für ihr Produkt zu schaffen. Ein Relay kann diese Arbeit an einer Stelle bündeln.

Wann der direkte Weg die bessere Wahl ist

Direkte Anbieter-APIs sind meist die bessere Wahl, wenn Ihnen einer der folgenden Punkte wichtig ist:

• Geringstmögliche Latenz. Ein Netzwerksprung weniger zählt, wenn das Latenzbudget Ihres Produkts knapp ist. Wenn Sie eine Interaktion mit 300 ms anstreben, die sich „sofort“ anfühlt, kann zusätzlicher Netzwerk- und Routing-Aufwand einen schmerzhaft großen Teil davon aufbrauchen.
• Strenge Compliance-Grenzen. Jeder zusätzliche Auftragsverarbeiter bedeutet eine weitere Geschäftsbeziehung, weitere Aufbewahrungsregeln und eine weitere Vertragsprüfung.
• Anbieterspezifische Funktionen. Manche Anbieter stellen Funktionen bereit, die Aggregatoren entweder durch Vereinheitlichung verschwinden lassen oder erst verspätet unterstützen.
• Hohes, vorhersehbares Volumen. Sobald die Nutzung stabil ist, kann eigenes Routing günstiger sein als die Bezahlung einer Zwischenschicht.
• Klarere Support-Wege. Wenn etwas ausfällt, gibt es weniger gegenseitige Schuldzuweisungen.

Der verborgene Vorteil ist Klarheit im Betrieb. Bei einem direkten Aufrufpfad lässt sich die Ursache eines Fehlers leichter eingrenzen. Wenn ein Aufruf fehlschlägt, liegt es meist an Ihrem Code oder am Anbieter. Bei einem Gateway müssen Sie zusätzlich prüfen, ob das Relay, dessen Routing-Schicht oder der nachgelagerte Anbieter verantwortlich war.

Self-Hosting ist eine andere Herausforderung

Offene Modelle selbst zu hosten bedeutet nicht einfach „eine günstigere API, aber auf meinem Server“. Es ist eine Herausforderung für das gesamte System.

Sie müssen Folgendes berücksichtigen:

• GPU-Dimensionierung und -Auslastung,
• Bündelung von Anfragen,
• Quantisierung,
• Auslastung des KV-Caches,
• automatische Skalierung,
• Warmstarts,
• Sicherheitsfilter,
• Modellaktualisierungen
• und Rollback-Verfahren.

Der Vorteil ist Kontrolle. Wenn Ihre Arbeitslast stabil und hoch genug ist, kann Self-Hosting wirtschaftlich attraktiv sein. Die Rechnung geht aber nur auf, wenn Sie die Hardware auslasten. Ungenutzte GPUs sind teuer. Dasselbe gilt für den Entwicklungsaufwand, der nötig ist, damit ein Stack zur Modellbereitstellung auch unter Last zuverlässig funktioniert.

Ein weiterer häufiger Fallstrick sind Veränderungen der Qualität. Ein offenes Modell mag heute für Zusammenfassungen gut genug sein, doch Ihre Evaluationen können scheitern, wenn sich Prompt-Länge, Stilanforderungen oder Tool-Nutzung ändern. Gehen Sie nicht davon aus, dass „offen“ automatisch „günstig genug, um eine verwaltete API zu ersetzen“ bedeutet.

Ein praktischer hybrider Ansatz

In realen Systemen ist die beste Architektur oft eine Mischung:

# direct path for latency-sensitive traffic
export LLM_ROUTE=direct
export LLM_PROVIDER=anthropic
export LLM_MODEL=claude-sonnet-4.6

# relay path for experimental or burst traffic
export LLM_ROUTE=gateway
export LLM_MODEL=openai/gpt-5.5

Und innerhalb der App:

def choose_route(task_type, tenant_tier, prompt_tokens):
    if task_type == "tool_calling":
        return {"route": "direct", "model": "anthropic/claude-sonnet-4.6"}
    if prompt_tokens > 120_000:
        return {"route": "gateway", "model": "openai/gpt-5.5"}
    if tenant_tier == "free":
        return {"route": "gateway", "model": "openai/haiku-class"}
    return {"route": "direct", "model": "google/gemini-3"}

Dieser Ansatz hält den kritischen Pfad einfach und bietet Ihnen dennoch Spielraum beim Routing. Meiner Erfahrung nach landen Teams nach dem ersten Monat im Produktionsbetrieb oft hier: direkte Aufrufe für die zentrale Nutzererfahrung, ein Gateway für Experimente und zusätzliche Kapazität, Self-Hosting nur dort, wo die wirtschaftlichen oder datenschutzbezogenen Vorteile eindeutig sind.

Datenschutz, Latenz und Vertrauen

Hier werden technische Fragen zu Fragen der Richtlinien.

Datenschutz

Ein Gateway verändert Ihre Vertrauensgrenze. Selbst wenn Prompts an den nachgelagerten Anbieter weitergeleitet werden, müssen Sie weiterhin folgende Fragen beantworten:

• Protokolliert das Relay Prompts?
• Wie lange werden sie aufbewahrt?
• Welche Unterauftragsverarbeiter können sie einsehen?
• Können Sie bestimmte Mandanten auf einen eingeschränkten Pfad beschränken?
• Wird die feste Bindung an eine Region unterstützt?

Bei regulierten Arbeitslasten reicht „der Anbieter hat korrektes Verhalten versprochen“ nicht aus. Sie brauchen schriftliche Nachweise und eine Architektur, die dazu passt.

Latenz

Ein Relay fügt einen weiteren Netzwerksprung hinzu. Das macht die App nicht automatisch langsam, erhöht aber die Unsicherheit. Wenn Ihre App viele Anfragen austauscht und Token-Streaming wichtig ist, kann jede zusätzliche Schicht die Zeit bis zum ersten Token weniger vorhersehbar machen.

Anfragelimits

Bei direkten Integrationen sind Sie den Anbieterlimits unmittelbar ausgesetzt. Gateways können das abfedern, indem sie Traffic auf mehrere Anbieter verteilen, aber sie können auch eigene Drosselungen einführen. Mit anderen Worten: Sie tauschen möglicherweise ein Limit gegen ein anderes. Der Vorteil ist Elastizität, nicht Immunität.

Meine Entscheidungsregel

Wenn ich die Entscheidung auf einen Satz verdichten müsste: Nutzen Sie direkte Aufrufe, wenn Sie das Modell kennen und Ihnen der Aufrufpfad wichtig ist; nutzen Sie ein Gateway, wenn Ihnen Wahlmöglichkeiten und Ausfallsicherheit wichtig sind; setzen Sie auf Self-Hosting, wenn Kontrolle und konstante Auslastung die Betriebskosten rechtfertigen.

Ein paar konkrete Faustregeln:

• Beginnen Sie mit direkten Aufrufen, wenn Sie Ihre erste Funktion für den Produktionsbetrieb veröffentlichen und nur ein Modell benötigen.
• Fügen Sie ein Gateway hinzu, wenn Sie mindestens zwei unterschiedliche Modellklassen haben oder wenn Failover in der Nachbereitung von Vorfällen zum Thema wird.
• Setzen Sie erst auf Self-Hosting, wenn Sie reale Auslastungszahlen und einen klaren Grund haben, den Stack selbst zu betreiben.
• Nutzen Sie ein Gateway für Routing-Experimente, aber halten Sie Ihren kritischen Pfad idempotent.
• Messen Sie die Gesamtkosten, nicht nur den Token-Preis.

Praktische Empfehlungen

• Bevorzugen Sie direkte APIs für möglichst geringe Latenz, einfaches Debugging und bestmöglichen anbieterspezifischen Support.
• Bevorzugen Sie ein Gateway bzw. einen Aggregator wenn Sie Routing über mehrere Modelle, Fallback-Abdeckung oder eine einzige Integration für viele Anbieter benötigen.
• Bevorzugen Sie Self-Hosting nur dann, wenn Sie die Hardware auslasten können und die betriebliche Komplexität akzeptieren.
• Etablieren Sie Idempotenz und einen disziplinierten Umgang mit Wiederholungsversuchen bevor Sie automatische Fallbacks hinzufügen.
• Vergleichen Sie Gesamtkosten: Tokens, Aufschläge, Wiederholungsversuche, Entwicklungszeit und Wiederherstellung nach Vorfällen.
• Bewahren Sie Datenschutz und Aufbewahrung von Anfang an in der Entscheidung, nicht erst, wenn der Einkauf danach fragt.
• Nutzen Sie eine hybride Architektur wenn Ihr Workload sowohl Premium- als auch Standardpfade umfasst.

Wenn Sie möchten, kann ich daraus eine Version mit klareren Positionen für eine bestimmte Zielgruppe machen, etwa für Startup-Gründer, Plattformteams oder Unternehmensteams mit hohen Compliance-Anforderungen.