Pexon Consulting | 9 Min. Lesezeit | 14.07.2026
TL;DR
Der Wechsel von Anthropic oder OpenAI zu einem self-hosted LLM ist kein Neubau. Über eine OpenAI-kompatible Schnittstelle und ein Gateway wie LiteLLM tauschst du in vier Schritten nur den Endpunkt, nicht den Code. Pexon Consulting (80 Mitarbeiter, Microsoft Partner, DSGVO) plant und betreibt die Migration. Der Lock-in sitzt tiefer im Prozess als im Code.
Der Lock-in ist flacher, als alle denken
Die kurze Antwort auf „wie tief stecke ich bei Anthropic fest“: weniger tief, als die Rechnung vermuten lässt. Die API von Anthropic ist strukturell der von OpenAI sehr ähnlich, und beide lassen sich hinter einer einheitlichen Schnittstelle abbilden. Der technische Wechsel ist in Stunden gemacht, nicht in Monaten.
Der echte Lock-in sitzt woanders. Er sitzt in den Prompts, die auf ein bestimmtes Modellverhalten getunt sind, in den Eval-Sets, die niemand gepflegt hat, und in der Angst, dass ein offenes Modell schlechter liefert. Genau diese drei Punkte lösen wir in der Migration, nicht die API-Anbindung.
Unsere klare Position: Wer heute produktiv auf einer kommerziellen API läuft, sollte spätestens jetzt ein Gateway davorsetzen, auch ohne sofort zu migrieren. Das kostet fast nichts und macht jeden späteren Wechsel zur Konfigurationsfrage statt zum Projekt.
Warum überhaupt weg von der API
Es gibt drei Gründe, und nur einer davon ist der Preis. Wir sortieren sie nach Häufigkeit, wie wir sie bei Kunden sehen.
Datensouveränität steht an erster Stelle. Kundendaten, Akten oder Konstruktionsdaten dürfen bei vielen unserer Kunden das Haus nicht verlassen und schon gar nicht zu einem US-Anbieter fließen. Ein deutsch gehostetes Modell löst das an der Wurzel, unabhängig vom Preis.
Planbare Kosten stehen an zweiter Stelle. Eine API-Rechnung, die mit jedem erfolgreichen Feature steigt, ist für einen CFO schwer zu budgetieren. Fixkosten auf eigener Hardware geben Ruhe, sobald das Volumen groß genug ist.
Kontrolle über das Modell steht an dritter Stelle. Wer auf einer kommerziellen API läuft, lebt mit Modell-Deprecations, geänderten Antwortformaten und Rate-Limits. Ein eingefrorenes Open-Weight-Modell ändert sich nur, wenn du es willst. Für regulierte Prozesse mit Freigabe-Zyklen ist das ein handfester Vorteil.
Welches offene Modell die kommerziellen ersetzt
Die offene Modell-Landschaft hat 2026 zu den Flaggschiffen aufgeschlossen. Die kurze Antwort: Für die allermeisten Enterprise-Aufgaben gibt es einen offenen Ersatz, der nah genug dran ist.
Zur Einordnung der Frische: GLM 5.2 kam im Juni 2026 mit einem Kontextfenster von einer Million Token und ist das erste Open-Weight-Modell, das GPT-5.5 auf SWE-Bench Pro schlägt. DeepSeek V4 erschien am 24. April 2026 als Preview. MiniMax M3 folgte am 1. Juni 2026 mit nativem Bild- und Video-Input. Die Lücke zu den kommerziellen Modellen ist bei Standardaufgaben praktisch geschlossen.
Wir raten trotzdem davon ab, blind das größte Modell zu nehmen. Für einen internen Assistenten reicht meist ein 30B-Modell, das auf zwei GPUs läuft, statt eines 235B-Modells, das ein H200-Cluster braucht. Modellgröße kostet Hardware, und die meisten Aufgaben brauchen sie nicht.
Die Migration in vier Schritten
Wir migrieren nie mit einem harten Schnitt. Das Muster ist immer dasselbe: erst absichern, dann parallel testen, dann schrittweise umschalten.
Schritt 1: Gateway vorschalten. Zwischen Anwendung und kommerzielle API kommt ein Gateway wie LiteLLM. Der Anwendungscode spricht ab jetzt nur noch mit dem Gateway, nicht mehr direkt mit Anthropic. Das ändert am Verhalten nichts, schafft aber die Umschaltstelle. Details dazu im LLM-Gateway und Modell-Routing.
Schritt 2: Offenes Modell schatten-testen. Das self-hosted Modell läuft parallel über einen OpenAI-kompatiblen vLLM-Endpunkt. Wir schicken echte Anfragen im Schatten an beide Modelle und vergleichen die Antworten, ohne dass der Nutzer etwas merkt. Hier zeigt sich, wo das offene Modell abweicht und welche Prompts nachjustiert werden müssen.
Schritt 3: Nach Aufgabe routen. Statt alles auf einmal umzuschalten, routen wir zuerst die unkritischen und hochvolumigen Aufgaben auf das eigene Modell. Klassifikation und Extraktion wandern zuerst, das komplexe Reasoning bleibt vorerst auf der API. Das senkt sofort die Kosten und hält das Risiko klein.
Schritt 4: Umschalten und API abschalten. Wenn die Evals stabil sind, wird der letzte Verkehr umgeleitet und die kommerzielle API abgeklemmt. Weil alles über das Gateway läuft, ist das eine Konfigurationsänderung und jederzeit reversibel.
Der Kern der Sache im Code: derselbe Aufruf, nur eine andere Basis-URL.
from openai import OpenAI
# Vorher: kommerzielle API
# client = OpenAI(base_url="https://api.openai.com/v1", api_key=OPENAI_KEY)
# Nachher: self-hosted, OpenAI-kompatibel über das Gateway
client = OpenAI(base_url="https://llm.intern.example.de/v1", api_key=GATEWAY_KEY)
antwort = client.chat.completions.create(
model="qwen3-30b", # statt "gpt-5.2"
messages=[{"role": "user", "content": "Fasse dieses Dokument zusammen."}],
)Die zugehörige Gateway-Konfiguration hält beide Welten parallel, damit das Routing pro Aufgabe entscheidet:
# litellm config: kommerziell und self-hosted nebeneinander
model_list:
- model_name: qwen3-30b
litellm_params:
model: openai/qwen3-30b
api_base: http://vllm-intern:8000/v1
- model_name: fallback-cloud
litellm_params:
model: anthropic/claude-sonnet-4-6Was nach dem Umschalten bleibt
Migration ist nicht der Endpunkt, sondern der Anfang des Betriebs. Zwei Dinge müssen ab Tag eins stehen, sonst holt der Betrieb die Ersparnis wieder ein.
Das erste ist Modell-Monitoring. Ein self-hosted Modell hat keinen Anbieter, der die Qualität überwacht. Du brauchst eigene Evals und ein Tracing, das Ausreißer sichtbar macht. Wie das mit Token-Tracking zusammenspielt, steht im Beitrag zu LLM-Kosten mit LangFuse kontrollieren.
Das zweite ist ein Update-Prozess. Offene Modelle erscheinen im Wochentakt. Du musst nicht jedem Release folgen, aber du brauchst einen Weg, ein neues Modell zu testen und kontrolliert einzuspielen, ohne den Produktivbetrieb zu stören. Genau dafür ist das Gateway aus Schritt eins da.
Häufig gestellte Fragen
Ist der Wechsel von Anthropic zu einem self-hosted LLM aufwendig?
Der technische Wechsel ist gering, weil die APIs strukturell ähnlich sind und ein Gateway sie hinter einer einheitlichen Schnittstelle abbildet. Der Aufwand steckt im Nachjustieren der Prompts und im Aufbau von Evals, nicht in der Anbindung. Mit dem Vier-Schritte-Muster aus Shadow-Test und schrittweisem Routing bleibt das Risiko klein und jederzeit reversibel.
Was ist eine OpenAI-kompatible API und warum ist sie wichtig?
Eine OpenAI-kompatible API spricht dasselbe Format wie OpenAI, egal welches Modell dahinter läuft. vLLM stellt so einen Endpunkt für self-hosted Modelle bereit. Der Vorteil: Du tauschst nur die Basis-URL und den Modellnamen, der restliche Code bleibt unverändert. Das ist der stärkste Schutz gegen Vendor-Lock-in.
Ist ein offenes Modell wie Qwen oder GLM schlechter als GPT oder Claude?
Für Standardaufgaben wie Zusammenfassung, Extraktion und Klassifikation praktisch nicht mehr. GLM 5.2 schlägt bei Coding-Benchmarks inzwischen kommerzielle Modelle. Beim komplexesten agentischen Reasoning liegen GPT und Claude noch leicht vorn. Für die meisten Enterprise-Workflows ist die offene Klasse ausreichend.
Kann ich einzelne Aufgaben auf der API lassen und den Rest self-hosten?
Ja, und das ist meist der klügste Weg. Über das Gateway routest du hochvolumige, unkritische Aufgaben auf das eigene Modell und behältst komplexes Reasoning bei Bedarf auf der kommerziellen API. Dieser hybride Betrieb senkt die Kosten sofort und hält die Qualität dort hoch, wo sie zählt.
Bleiben meine Daten bei einem self-hosted LLM wirklich im Haus?
Ja, wenn das Modell auf eigener oder deutsch gehosteter Infrastruktur läuft. Anders als bei einer kommerziellen API verlässt kein Prompt und keine Antwort das eigene Netz. Genau das ist für regulierte Branchen wie Versicherung, Energie und Banking der eigentliche Grund für die Migration.
Nächster Schritt
Der erste konkrete Schritt ist immer das Gateway. Wir setzen es vor deine bestehende API und richten den Shadow-Test ein, damit du siehst, wie nah ein offenes Modell an deinem heutigen Anbieter liegt.
Verwandte Themen
→LLM selbst hosten statt API: die Kostenrechnung dahinter
→Wie viele GPUs dein eigenes Modell pro Nutzer braucht
