Vendor-Lock-in bei OpenAI: was die Rechnung versteckt
OpenAI ist die bequeme Wahl - mit Preisliste in Bewegung, Modell-Deprecations alle sechs Monate und Embeddings, die nicht mehr wegwandern. Wie wir gegensteuern.
Stille Kosten
Drei Posten, die im Pitch-Deck nicht stehen
OpenAI hat die schönste Dev-Experience im Markt. Genau das ist der Köder. Wir sehen in Kundenprojekten regelmäßig drei Kostenposten, die im ersten Quartal niemanden interessieren - und im zweiten Jahr das Budget auffressen.
Warum OpenAI nicht „böse“ ist
Dieser Artikel ist keine Anti-OpenAI-Schrift. Wir nutzen die API selbst täglich, Function Calling ist exzellent, GPT-4o ist für viele Workloads das beste Preis-Leistungs-Verhältnis. Der Punkt ist ein anderer: Wer ausschließlich auf einen Anbieter setzt, baut sich eine Abhängigkeit, die später teuer wird - nicht weil der Anbieter böse ist, sondern weil Marktbedingungen sich ändern.
Was Lock-in konkret bedeutet
Vendor-Lock-in heißt nicht „wir können nicht weg“, sondern „der Wechsel kostet mehr, als er bringt“. Bei Cloud-Datenbanken war das jahrelang bekannt, bei LLM-Anbietern wird es jetzt sichtbar. Drei Mechanismen sind dabei besonders wirksam, und genau die schauen wir uns gleich an.
1. Token-Pricing in Bewegung
Die Preisliste ist kein Vertrag
OpenAI hat in den letzten drei Jahren mehrfach Preise angepasst - oft nach unten, manchmal aber auch differenziert nach oben: neue Modelle, neue Tiers, neue Berechnungsmodelle für Cached Tokens und Tool-Calls. Wer seine Kalkulation auf den Preis vom Quartalsanfang stützt, kalkuliert mit einem beweglichen Ziel.
Unsere Empfehlung: Token-Verbrauch pro Use-Case kontinuierlich messen, Budget-Alarme an die Token-Menge koppeln, nicht an den Euro-Betrag. Sonst rutscht ein Preisanpassungs-Zyklus durch, bevor das Controlling reagiert.
Wechselkurs API zu Modell-Generation
Neue Generationen sind günstiger pro Token, aber meist nicht 1:1 mit der alten kompatibel: anderes Tokenizer-Verhalten, anderes Prompt-Caching, andere Function-Calling-Konventionen. Aus „Preis fällt 30 Prozent“ wird oft „Aufwand für Re-Validierung kostet drei Wochen“.
LiteLLM als Abstraktions-Layer
Wir setzen in produktiven Setups standardmäßig auf LiteLLM oder einen vergleichbaren Proxy. Der Code-Layer ruft eine generische Chat-Completion auf, der Proxy entscheidet, welches Modell - OpenAI, Anthropic, Mistral, lokal - die Anfrage beantwortet. Das ist die Voraussetzung dafür, dass Preisänderungen oder Deprecations in Stunden behoben werden, nicht in Sprints.
2. Deprecations alle sechs Monate
Ihr Prompt von heute funktioniert in einem Jahr nicht mehr
OpenAI nimmt Modelle vom Markt: GPT-3.5-Turbo in mehreren Varianten, ältere Embedding-Modelle, Snapshot-Pinnings, die nach 24 Monaten abgeschaltet werden. Wenn Sie ohne Versionierungs-Plan bauen, bekommen Sie regelmäßig E-Mails mit der dringenden Bitte, in den nächsten zwölf Wochen Ihr Produktivsystem zu migrieren.
Das ist nicht boshaft - Modelle altern, neue sind besser. Aber es bedeutet: Jedes LLM-Feature in einem Produkt braucht einen Modell-Migrations-Pfad, eine Test-Suite gegen Prompt-Regression und einen Fallback-Modus. Wer das in der Architektur nicht vorsieht, betreibt Schulden mit Verzugszinsen.
Prompt-Regression-Tests als Pflicht
Wir legen für jedes LLM-Feature 30 bis 100 Eingabe-/Erwartungs-Paare an, die bei jedem Modellwechsel automatisch gegen den neuen Snapshot laufen. Tonalität, Schema-Treue, Halluzinations-Quote werden gemessen. Erst wenn das neue Modell die Grenzwerte einhält, schalten wir produktiv um.
Fallback-Modelle vom ersten Tag an
Jeder produktive LLM-Workflow bei uns hat mindestens ein primäres und ein sekundäres Modell - in der Regel ein OpenAI- und ein Anthropic-Modell, manchmal ergänzt um ein Open-Source-Modell. Wenn die primäre API ausfällt, übernimmt der Proxy automatisch. Das kostet im Aufbau einen halben Tag und ist im Ernstfall der Unterschied zwischen kurzer Störung und Ausfall.
Schon abhängig von einem Anbieter?
Wir machen eine Lock-in-Inventur und zeigen, was ein Anbieter-Wechsel realistisch kostet.
3. Embeddings bleiben drin
Die unsichtbare Mauer rund um den Vektor-Store
Wer ein RAG-Setup mit OpenAI-Embeddings aufbaut, erzeugt eine zweite, härtere Abhängigkeit: Alle Vektoren wurden mit einem bestimmten Embedding-Modell berechnet. Ein Wechsel auf einen anderen Anbieter (oder auch nur auf ein neueres OpenAI-Embedding-Modell) bedeutet: kompletter Vektor-Store muss neu berechnet werden.
Bei einem Wissens-Korpus mit 800.000 Chunks sind das je nach Größe ein paar hundert bis ein paar tausend Euro Embedding-Kosten - plus ein bis drei Tage Engineering-Aufwand für Re-Indexing und Reranker-Re-Tuning. Diese Migration steht nirgendwo in der Roadmap, bis sie nötig wird.
Embedding-Versioning als Disziplin
In unseren RAG-Setups bekommt jeder Chunk neben dem Vektor auch das Modell und die Version mitgespeichert. So lassen sich Vektoren aus zwei Generationen parallel halten, schrittweise migrieren und A/B testen. Ohne dieses Versioning ist jeder Embedding-Wechsel ein Big-Bang-Release - mit allen Risiken.
Re-Embed-Strategie für den Ernstfall
Wir definieren pro Projekt einen Re-Embed-Plan: Wie lange dauert eine vollständige Neuberechnung des Korpus? Was kostet sie bei aktuellem Preis? Welche Reranker-Konstellation gilt nach dem Wechsel? Diese Übung dauert eine halbe Stunde - und macht aus einer Migration einen Vorgang statt eines Projekts.
Bottom Line
Nicht „OpenAI vermeiden“. Sondern: so bauen, dass „OpenAI“ eine Konfigurations-Variable ist - keine Architektur-Entscheidung.
Artikel teilen
Wie tief sitzt Ihr Lock-in wirklich?
Wir prüfen Ihre Architektur auf API-Bindung, Embedding-Bindung und Prompt-Bindung - und schätzen die Wechselkosten in Tagen und Euro. Schriftliches Ergebnis, Fixpreis.