Von der OpenAI-API zu souveräner Inferenz: die Migration in der Praxis

Freitag, 17 Uhr: eine geänderte Zeile Code, ein gutes Gefühl

Ein Freitagnachmittag, der Sprint-Review ist durch, und ein Backend-Entwickler bei einem Zürcher Versicherer probiert aus, wonach ihn sein CTO seit Wochen fragt: weg von der OpenAI-API, hin zu einem selbst betriebenen Endpoint. Er öffnet die Config, ersetzt base_url="https://api.openai.com/v1" durch die IP seines frisch aufgesetzten vLLM-Servers, tauscht den API-Key, ersetzt den Modellnamen, und der Chat-Assistent in der internen App antwortet. Sofort, ohne dass irgendwo im restlichen Code etwas anderes angefasst werden musste. Er schliesst den Laptop mit dem Gefühl, gerade in zwanzig Minuten ein Sourcing-Problem gelöst zu haben, das die Rechtsabteilung seit einem Quartal beschäftigt.

Montagmorgen sieht die Sache anders aus. Der Extraktions-Task, der bisher zuverlässig sauberes JSON lieferte, produziert jetzt in jedem zehnten Fall ein Objekt mit einem erklärenden Satz davor. Der Function-Call, der Kundendaten an ein internes Tool weiterreichte, benennt plötzlich ein Feld falsch. Und die Kosten-Kalkulation, die deutlich günstiger versprochen hatte, muss neu gerechnet werden, weil das offene Modell mit einem anderen Tokenizer zählt und pro Token mehr braucht. Nichts davon ist ein Beinbruch, aber es ist der Unterschied zwischen Migration in einer Stunde und Migration, die man ernst nimmt. Genau darum geht es hier: nüchtern, ohne Marketing-Filter, was beim Wechsel von OpenAI oder Anthropic auf souveräne, selbst betriebene Inferenz wirklich passiert.

Der einfache Teil: warum der Umstieg überhaupt reizt

Der Grund, warum diese Geschichte so beginnt, ist kein Zufall. Serving-Engines wie vLLM, TGI oder SGLang bilden die OpenAI-API praktisch 1:1 nach, inklusive /v1/chat/completions, /v1/completions und in vielen Fällen auch /v1/embeddings. Wer sein Produkt mit dem offiziellen OpenAI-SDK oder mit LangChain, LlamaIndex oder einem selbstgebauten HTTP-Client gebaut hat, muss tatsächlich oft nur base_url und api_key austauschen. Request- und Response-Schema, Streaming über Server-Sent Events, sogar die Fehlercodes orientieren sich am gleichen Vorbild. Das ist kein Marketing-Trick, sondern ein handfester technischer Vorteil, den man OpenAI zugutehalten muss: Sie haben mit ihrer API einen De-facto-Standard gesetzt, an dem sich die gesamte offene Inferenz-Welt inzwischen orientiert.

Das ist auch der Grund, warum dieser Artikel überhaupt nötig ist. Weil der erste Schritt so reibungslos funktioniert, entsteht schnell der Eindruck, die ganze Migration sei damit erledigt. Ein Demo läuft, ein Proof-of-Concept überzeugt das Management, und dann wird der Umstieg für den produktiven Traffic geplant, als wäre es ein Config-Change wie jeder andere. Genau diese Erwartungshaltung ist das eigentliche Risiko, nicht die Technik an sich, sondern die Annahme, dass mit dem funktionierenden Demo bereits alles gesagt ist. Die Realität liegt dazwischen: Der Umstieg ist machbar, oft sogar gut machbar, aber er verdient dieselbe Sorgfalt wie jeder andere Wechsel einer kritischen Abhängigkeit.

Der eigentliche Grund: warum du das überhaupt tust

Bevor wir zu den Tücken kommen, lohnt sich der Blick auf das Warum, denn das entscheidet, wie viel Aufwand gerechtfertigt ist. An erster Stelle steht für die meisten Schweizer Unternehmen die Datenhoheit: Kundenanfragen, interne Dokumente oder medizinische Daten verlassen bei einer US-Cloud-API faktisch die eigene Kontrolle, selbst wenn vertraglich no training on your data zugesichert wird. Was genau das rechtlich und technisch bedeutet, haben wir in einem eigenen Artikel aufgedröselt (kurz gesagt: Kontrolle über die Infrastruktur ist etwas anderes als ein Vertragsversprechen).

Der zweite Treiber ist Kostenplanbarkeit. Token-basierte Abrechnung skaliert linear mit dem Erfolg deines Produkts: je mehr es genutzt wird, desto teurer wird genau das, was du willst. Ein selbst betriebener Endpoint auf gemieteter oder eigener Hardware kostet dagegen, was er kostet, unabhängig vom Volumen. Bei stabilem bis hohem Traffic kippt die Rechnung oft deutlich zugunsten von Bare-Metal-GPUs oder Managed Inference. Drittens: keine Rate-Limits, die dir von aussen auferlegt werden, wenn ein Produkt viral geht oder ein Kunde plötzlich zehnmal mehr Volumen fährt. Und viertens: kein Deprecation-Zwang. Wenn OpenAI ein Modell abkündigt, hast du ein festes Zeitfenster, um zu migrieren, ob es dir passt oder nicht. Bei einem selbst gehosteten offenen Modell entscheidest du, wann und ob du wechselst.

Die Tücken, die dir keiner erzählt (Teil 1): Prompts und Tool-Calling

Hier beginnt der Teil, der in Sales-Decks gerne übersprungen wird. Offene Modelle folgen Instruktionen anders als GPT-4o oder Claude, nicht grundsätzlich schlechter, aber anders trainiert, anders ausgerichtet, mit anderen Prioritäten im Post-Training. Ein System-Prompt, der bei GPT-4o zuverlässig ein bestimmtes Antwortformat erzwingt, kann bei Llama oder Qwen ignoriert oder nur teilweise befolgt werden. Manche offenen Modelle neigen stärker zu Präambeln (Gerne helfe ich dir dabei…) oder zu Erklärtext rund um strukturierte Ausgaben, den man explizit unterdrücken muss. Das bedeutet in der Praxis: jeder produktive Prompt muss gegen das neue Modell neu getestet werden, nicht nur überflogen. Wer glaubt, ein Prompt sei modellagnostisch, weil er einmal für GPT-4 geschrieben wurde, wird beim ersten Regressionstest eines Besseren belehrt.

Noch heikler wird es beim Tool- beziehungsweise Function-Calling. OpenAI und Anthropic haben hier über mehrere Modellgenerationen sehr viel Feinschliff investiert: Schema-Treue, korrekte Parameter-Typen, sauberes Escaping bei verschachtelten Objekten. Nicht jedes offene Modell und nicht jede Serving-Engine unterstützt Tool-Calling gleich gut. Manche Kombinationen aus Modell und Engine bieten gar kein natives Tool-Calling und emulieren es nur über Prompt-Engineering, was die Zuverlässigkeit spürbar senkt. Andere unterstützen es nativ, brechen aber bei komplexeren, verschachtelten Schemas ein. Hier hilft constrained decoding respektive guided JSON: Die Serving-Engine zwingt das Modell auf Token-Ebene, valide JSON gemäss Schema zu erzeugen, anstatt nur zu hoffen, dass es sich daran hält. vLLM, TGI und andere bieten das inzwischen an, aber es muss aktiv konfiguriert werden und ist nicht bei jedem Modell gleich robust. Wer viel mit Agenten und mehrstufigem Tool-Calling arbeitet, sollte das vor der Migration ausgiebig testen, dazu später mehr, auch im Kontext von AI-Agents.

Die Tücken, die dir keiner erzählt (Teil 2): Feature-Lücken und Tokenizer

Neben Prompt-Verhalten gibt es handfeste Feature-Lücken, die man kennen muss, bevor man sich festlegt. Strukturierte Outputs im Sinne von OpenAIs response_format mit striktem JSON-Schema sind nicht bei jeder Engine-Modell-Kombination gleich vollständig implementiert: manche unterstützen nur einfache JSON-Modi, andere echte Schema-Validierung inklusive additionalProperties: false. Vision-Fähigkeiten sind bei offenen Modellen vorhanden, aber die Auswahl an wirklich guten multimodalen offenen Modellen ist kleiner als bei reinen Text-Modellen, und nicht jede Serving-Engine unterstützt Bild-Inputs im OpenAI-kompatiblen Format gleich sauber. Sehr lange Kontextfenster, wie sie manche proprietären Modelle inzwischen bieten, sind bei offenen Alternativen zwar auch verfügbar, aber oft mit spürbaren Qualitätseinbussen gegen Ende des Kontexts. Und Embeddings-Endpoints laufen bei offenen Stacks meist über ein separates Modell und einen separaten Endpoint, nicht gratis mitgeliefert wie bei einem API-Anbieter mit riesigem Modell-Katalog. Welche Engine für welchen Use Case am meisten Sinn ergibt, haben wir im Vergleich zwischen vLLM, Ollama und TGI im Detail durchgespielt.

Ein Punkt, der regelmässig unterschätzt wird: Kontextfenster und Tokenizer unterscheiden sich zwischen Modellfamilien, und das hat direkte Folgen. Ein Prompt, der bei GPT-4o mit seinem Tokenizer 3'000 Tokens umfasst, kann bei einem Llama- oder Qwen-Modell mit anderem Vokabular 3'400 oder 2'700 Tokens ergeben, je nach Sprache sogar deutlich mehr, weil manche Tokenizer für Deutsch oder Schweizerdeutsch weniger effizient sind als für Englisch. Wer Kosten- oder Latenz-Budgets fest verplant hat, muss diese Zahlen neu ziehen, nicht einfach übernehmen. Und schliesslich: Mit dem Umstieg wandert die Betriebsverantwortung zu dir: Verfügbarkeit, Skalierung bei Lastspitzen, Patches, Modell-Updates, GPU-Ausfälle. Genau das ist der Teil, den Managed Inference dir abnimmt, aber es ist wichtig, ihn als eigenständigen Faktor zu benennen und nicht wegzudiskutieren, nur weil die API-Kompatibilität so einfach aussah.

Der Migrationspfad, der tatsächlich funktioniert

Nach allem, was oben steht, sollte klar sein: Ein Big-Bang-Umstieg an einem Freitagnachmittag ist der falsche Ansatz für produktiven Traffic. Was stattdessen funktioniert, ist ein Vorgehen in klaren, überprüfbaren Schritten.

• Golden-Set bauen: Sammle 50 bis 200 echte, repräsentative Requests aus deinem Produktivbetrieb, inklusive Edge Cases, langer Inputs, Tool-Calls und schwieriger Formatierungsanforderungen. Ohne diese Referenz fliegst du blind.
• Offenes Modell auswählen: Nicht das grösste oder das gerade meistdiskutierte Modell, sondern das, das zu deinem Use Case passt: Sprachqualität, Tool-Calling-Fähigkeit, Lizenz, Grösse. Eine strukturierte Vorgehensweise dazu findest du in unserem Artikel zur Auswahl offener Modelle.
• Endpoint aufsetzen: Serving-Engine wählen, Quantisierung und Batching-Parameter konfigurieren, Monitoring einrichten. Eine Schritt-für-Schritt-Anleitung dazu liefert unser Artikel zum Aufsetzen eines LLM-Endpoints.
• Schattenweise vergleichen: Sende produktive Requests parallel an OpenAI und an dein neues Setup, ohne dass Nutzer etwas davon merken. Vergleiche die Antworten anhand deines Golden-Sets, automatisiert oder mit menschlichem Review bei kritischen Fällen.
• Prompts nachziehen: Basierend auf den Abweichungen justierst du System-Prompts, Few-Shot-Beispiele und gegebenenfalls die Schema-Definitionen fürs Tool-Calling, gezielt, nicht pauschal.
• Traffic schrittweise umschalten: Erst 5 %, dann 25 %, dann 50 %, mit Monitoring auf Fehlerraten, Latenz und im Idealfall auch auf Business-Metriken wie Abbruchraten im Chat. Erst wenn diese Werte über mehrere Tage stabil sind, folgt die vollständige Umstellung.

Dieser Pfad dauert je nach Use Case zwischen zwei Wochen und zwei Monaten, deutlich länger als die zwanzig Minuten aus der Eingangsszene, aber immer noch ein Bruchteil der Zeit, die eine schlecht vorbereitete Migration kostet, wenn sie in Produktion scheitert und zurückgerollt werden muss.

Machbar, aber nicht ohne Sorgfalt

Die gute Nachricht zuerst: Für Standard-Anwendungsfälle (Chat-Assistenten, RAG-Pipelines, Textklassifikation, einfache Extraktion) ist die Migration von OpenAI oder Anthropic auf ein souverän betriebenes offenes Modell heute unkompliziert. Die technische Kompatibilität ist gross, die verfügbaren offenen Modelle sind für diese Aufgaben ausgereift, und der Aufwand hält sich mit einem sauberen, schrittweisen Vorgehen in vertretbaren Grenzen. Die schlechte Nachricht, falls man sie so nennen will: Bei starkem, mehrstufigem Tool-Calling, bei exotischen Feature-Anforderungen wie sehr langen Kontexten oder bei strikten strukturierten Outputs solltest du genau hinschauen, bevor du eine Deadline dafür festlegst. Nicht, weil es unmöglich ist, sondern weil es funktioniert im Demo und es funktioniert zuverlässig unter Produktionslast mit echten Edge Cases zwei verschiedene Aussagen sind.

Was wir dir nicht verkaufen wollen, ist das Bild einer Migration ohne jede Reibung. Was wir dir stattdessen anbieten: den Betrieb der eigentlichen Infrastruktur abzunehmen, damit du dich auf Prompts, Evaluierung und Produkt konzentrieren kannst statt auf GPU-Ausfälle und Skalierung um drei Uhr morgens. Mit Managed Inference bekommst du einen produktionsreifen, OpenAI-kompatiblen Endpoint auf Schweizer Infrastruktur, betrieben und überwacht von uns: der einfache Teil bleibt einfach, und für den Rest sind wir da.