Model Lock-in: Die Abhängigkeit, die keiner einplant

Der Lock-in, den jeder kennt — und der, den keiner budgetiert

Jedes Team, das etwas auf sich hält, hat eine Meinung zu Vendor-Lock-in. Man diskutiert stundenlang, ob man sich mit einer proprietären AWS-Datenbank zu tief an einen Cloud-Anbieter kettet. Man wiegt ab, ob ein SaaS-Tool die eigenen Daten in ein Format sperrt, aus dem man später nicht mehr herauskommt. Es gibt Architekturprinzipien dafür, Blog-Posts, ganze Beraterkarrieren. Cloud-Lock-in und SaaS-Lock-in sind eingepreiste Risiken.

Und dann verkabelt dasselbe Team sein wichtigstes neues Produkt mit dem Modell eines einzigen Anbieters — die Prompts auf dessen Eigenheiten getunt, die Tool-Aufrufe in dessen JSON-Format gegossen, ein Fine-Tune auf dessen Basismodell trainiert, die Evals ausschließlich gegen dieses eine Modell laufen gelassen — und niemand nennt das ein Risiko. Es steht in keinem Architektur-Review, in keiner Kostenplanung, auf keiner Risikoliste.

Das ist die Abhängigkeit, die keiner einplant. Model-Lock-in ist Vendor-Lock-in, nur ohne die Wachsamkeit, die man Vendor-Lock-in sonst entgegenbringt. Und weil das Modell die Ebene ist, auf der die Wertschöpfung passiert — es schreibt die Antwort, trifft die Klassifikation, extrahiert die Daten —, sitzt der Anbieter am Ende an genau dem Hebel, der über die eigene Marge entscheidet.

Wie sich der Lock-in einschleicht

Niemand entscheidet an einem Montagmorgen, sich für immer an einen Anbieter zu binden. Der Lock-in entsteht als Summe vernünftiger Einzelentscheidungen, jede für sich richtig, in der Summe eine Fessel.

Prompts, die auf die Macken eines Modells getunt sind. Man fängt mit einem generischen Prompt an, und er funktioniert mittelmäßig. Also feilt man. Man merkt, dass dieses Modell besser antwortet, wenn man die Instruktionen in XML-Tags verpackt. Dass es Beispiele im System-Prompt braucht, wo ein anderes mit einer nackten Anweisung auskommt. Dass es bei einer bestimmten Formulierung zuverlässig, bei einer minimal anderen unzuverlässig wird. Nach drei Monaten ist der Prompt ein fein austariertes Instrument — abgestimmt auf die Idiosynkrasien dieses einen Modells. Auf einem anderen Modell fällt die Qualität spürbar ab, und niemand weiß mehr genau, welche der vierzig Prompt-Entscheidungen tragend sind und welche Aberglaube.

Anbieterspezifische Features. Hier wird es technisch bindend. OpenAIs Structured Outputs mit striktem JSON-Schema garantieren valides JSON auf eine Art, die kein offener Standard ist. Das Tool-Calling-Format unterscheidet sich zwischen den Anbietern nicht nur kosmetisch — die Struktur der Aufrufe, das Schema der Argumente, wie parallele Tool-Calls zurückkommen. Wer die eigene Agenten-Logik direkt gegen OpenAIs tools-Format baut, baut nicht gegen eine Abstraktion, sondern gegen eine konkrete API. Auf Anthropics Tool-Use-Format oder Googles Function-Calling zu wechseln ist dann kein Konfigurationswechsel, sondern eine Umschreibung.

Fine-Tunes auf genau einem Basismodell. Das ist die teuerste Falle, weil sie sich wie Fortschritt anfühlt. Man sammelt ein sauberes Trainingsset, fine-tuned auf gpt-3.5-turbo oder gpt-4o-mini, und die Ergebnisse sind hervorragend. Was man dabei baut, ist ein Asset, das man nicht besitzt: Die Gewichte gehören dem Anbieter, das Modell läuft nur auf seiner Infrastruktur, und es hängt an einem konkreten Snapshot. Kündigt der Anbieter dieses Basismodell ab — und das tut er —, ist der Fine-Tune nicht portierbar, sondern muss von Grund auf gegen ein neues Basismodell neu trainiert werden. Man hat kein Modell gebaut. Man hat eine Abhängigkeit trainiert.

Evals nur gegen ein Modell. Der stillste Mechanismus von allen. Man baut sich eine Test-Suite, um die eigene KI-Funktion zu messen — und lässt sie ausschließlich gegen das produktive Modell laufen, weil das ja das ist, was zählt. Damit ist die Eval-Suite kein neutrales Messinstrument mehr, sondern implizit gegen die Antwortmuster dieses einen Modells kalibriert. Man kann nicht mehr in einer Stunde beantworten, wie ein Wettbewerber-Modell auf derselben Aufgabe abschneidet. Die Frage „sollten wir wechseln?" wird unbeantwortbar, weil das Werkzeug fehlt, um sie zu beantworten. Und eine unbeantwortbare Frage stellt man irgendwann nicht mehr.

Der Tag, an dem die Rechnung kommt

Solange der Anbieter sich gutartig verhält, kostet der Lock-in nichts. Das ist die Falle: Die Rechnung kommt erst, wenn sich die Interessen auseinanderentwickeln — und dann kommt sie in drei Formen.

Der Anbieter erhöht die Preise. Inferenzpreise sind in den letzten Jahren überwiegend gefallen, und das verleitet zu der Annahme, sie fielen immer. Aber der Preis ist nicht der Punkt — die Preismacht ist es. Wer keine Ausstiegsoption hat, verhandelt nicht. Führt der Anbieter eine Prioritäts-Tier für dein Volumen ein, ändert die Preisstruktur für hohe Kontextfenster, oder streicht schlicht den Rabatt, den du eingeplant hattest, ist die Frage nicht, ob du das fair findest. Die Frage ist, was deine Alternative innerhalb von zwei Wochen ist. Ohne Portabilität lautet die Antwort: keine. Dein Anbieter hat dann direkten Zugriff auf deine Marge, und er weiß es.

Der Anbieter kündigt das Modell ab. Das ist keine hypothetische Sorge, das ist der Normalfall. OpenAI hat die alten gpt-4-0314- und gpt-3.5-turbo-0613-Snapshots abgekündigt, hat die gesamte Completions-Ära mit text-davinci-003 beerdigt, hat gpt-4-vision-preview in ein Nachfolgemodell überführt. Google hat die komplette PaLM-API mitsamt text-bison eingestellt und alle auf Gemini umgeleitet. Anthropic hat Claude 2 in den Ruhestand geschickt. Modelle haben Lebenszyklen von Monaten bis wenigen Jahren, nicht von Jahrzehnten. Wer auf einen konkreten Snapshot gepinnt hat — aus gutem Grund, weil Pinning die einzige Verteidigung gegen stille Verhaltensänderungen ist —, bekommt irgendwann eine E-Mail mit einem Abschaltdatum. Und dann läuft die Uhr, ob es gerade passt oder nicht.

Der Anbieter degradiert die Qualität still. Der heimtückischste Fall. Ein Modell hinter demselben API-Namen bekommt ein Update, und das Verhalten verschiebt sich — mal besser, mal schlechter, mal nur anders. Deine sorgfältig getunten Prompts waren gegen ein bewegliches Ziel kalibriert. Ohne eine Eval-Suite, die du auf Knopfdruck laufen lassen kannst, merkst du die Verschiebung nicht als Zahl, sondern als diffus steigende Support-Tickets drei Wochen später. Und selbst wenn du sie bemerkst: Was ist dein Zug, wenn du an genau dieses Modell gekettet bist?

Alle drei Fälle haben denselben Kern. Nicht das schlechte Verhalten des Anbieters ist das Problem — Anbieter verhalten sich vernünftig aus ihrer Sicht. Das Problem ist die Asymmetrie: Sie können handeln, und du kannst nur reagieren.

Portabilität als Ingenieursarbeit

Die gute Nachricht: Portabilität ist keine Frage der Hoffnung, sondern der Bauweise. Vier Maßnahmen, in aufsteigender Reihenfolge des Aufwands.

• Eine dünne Abstraktions- oder Gateway-Schicht. Statt aus dem ganzen Code direkt gegen die SDK eines Anbieters zu rufen, ruft man gegen eine schmale interne Schnittstelle, hinter der der Anbieter austauschbar ist. Man muss das nicht selbst bauen: LiteLLM stellt einen OpenAI-kompatiblen Proxy vor über hundert Anbieter, OpenRouter routet dieselbe Anfrage an unterschiedliche Modelle, das Vercel AI SDK abstrahiert die Provider-Unterschiede in einer gemeinsamen Schnittstelle, Cloudflares AI Gateway und Portkey sitzen als neutrale Vermittler dazwischen. Der Punkt ist nicht das konkrete Werkzeug, sondern dass der Anbietername an einer Stelle im Code steht, nicht an vierzig.
• Anbieteragnostische Prompts. Prompts so schreiben, dass sie auf ihrer Bedeutung tragen, nicht auf einem Modell-Trick. XML-Tags, wo sie strukturieren, aber nicht als Kult. Die tragenden Instruktionen von den kosmetischen trennen und dokumentieren, welche warum da sind. Ein Prompt, den man erklären kann, ist ein Prompt, den man portieren kann.
• Eine Eval-Suite, die gegen jedes Modell läuft. Das ist der Hebel mit dem höchsten Wirkungsgrad. Wer eine Test-Suite hat, die anbieterunabhängig gegen jedes beliebige Modell laufen kann, verwandelt die Frage „sollten wir wechseln?" von einem Glaubenskrieg in eine Messung über Nacht. Man sieht schwarz auf weiß, was ein Wechsel an Qualität kostet oder bringt — und genau diese Zahl ist der ganze Unterschied zwischen einer echten Ausstiegsoption und dem bloßen Gefühl, man hätte eine.
• Ein Open-Weight-Fallback. Wie wir in einem früheren Artikel über Open-Weight-LLMs gegen die API ausgeführt haben, ist die Lücke zur Spitze für viele Aufgaben inzwischen klein genug, dass ein selbst betriebenes Modell — Llama, Mistral, Qwen — eine realistische Rückfalloption ist. Man muss es nicht produktiv fahren. Es reicht, wenn die Architektur es könnte: Dann hat kein API-Anbieter mehr die Gewissheit, dass man keine Wahl hat. Und ein Fine-Tune auf einem Open-Weight-Modell liefert etwas, das ein gehosteter Fine-Tune nie liefert — Gewichte, die einem gehören.

Der Preis der Abstraktion

Jetzt die ehrliche Gegenseite, sonst wird aus einer richtigen Beobachtung ein teures Dogma. Portabilität ist nicht umsonst, und verfrühte Abstraktion ist ihre eigene Steuer.

Eine Abstraktionsschicht, die jeden Anbieter unterstützen soll, konvergiert unweigerlich gegen den kleinsten gemeinsamen Nenner. Genau die Features, die ein einzelnes Modell überlegen machen — OpenAIs striktes Structured-Output-Schema, das genau passende Tool-Calling-Verhalten, ein besonders großes Kontextfenster, das Prompt-Caching eines bestimmten Anbieters —, sind die Features, die durch die neutrale Schicht nicht durchpassen. Wer heute alles portierbar hält, verzichtet heute auf das Beste, was heute verfügbar ist — als Versicherung gegen einen Wechsel, den man vielleicht nie vollzieht.

Und diese Versicherung hat eine laufende Prämie: Tempo. Jede Indirektion, die man wartet, jeder Prompt, den man auf das Mittelmaß über mehrere Modelle abflacht, jede Eval, die man anbieterneutral doppelt hält, ist Zeit, die nicht ins Produkt fließt. Für viele Teams — besonders früh, besonders wenn ein Modell die Aufgabe klar am besten löst — schlägt „auf ein exzellentes Modell setzen und schnell sein" das Hedging um Längen. Ein Startup, das seinen Prototyp mit dem stärksten verfügbaren Modell in der halben Zeit baut, gewinnt mehr, als es durch theoretische Portabilität je verlieren würde.

Die Auflösung liegt nicht in einem Extrem. Lock-in ist kein Schalter, sondern ein Spektrum, und das Ziel ist nicht null Kopplung — das ist unbezahlbar und meist unnötig. Das Ziel ist ein billiger Ausstieg. Man darf tief das beste Feature eines Modells nutzen, solange man weiß, wo diese Kopplung sitzt und was ihr Ausbau kosten würde. Der teure Lock-in ist nie der bewusste; es ist der, den niemand auf der Liste hatte. Ein Fine-Tune, dessen Wiederbeschaffungskosten man kennt, ist eine Entscheidung. Ein Fine-Tune, von dem man erst beim Abkündigungs-Mail erfährt, dass er nicht portierbar ist, ist ein Unfall.

Fazit

Cloud-Lock-in und SaaS-Lock-in stehen auf jeder Risikoliste, weil Teams gelernt haben, sie zu fürchten. Model-Lock-in steht auf keiner, weil die Modell-Ebene neu ist und sich unter der Hand einschleicht — ein getunter Prompt hier, ein anbieterspezifisches Feature dort, ein Fine-Tune, der sich wie ein Asset anfühlt und in Wahrheit eine Abhängigkeit ist. Bis zu dem Tag, an dem der Preis steigt, das Modell abgekündigt wird oder die Qualität still wegrutscht — und man feststellt, dass man keinen Zug hat.

Die Lehre ist nicht, jede Kopplung zu vermeiden. Sie ist, Kopplung zu einer bewussten Entscheidung zu machen statt zu einem Betriebsunfall. Wisse, wo du gebunden bist, kenne den Preis, dich loszubinden, und halte diesen Preis niedrig genug, dass „wir wechseln" eine echte Option bleibt und kein frommer Wunsch.

Genau so arbeiten wir bei NH Labs. Wir setzen für jede Aufgabe das Modell ein, das sie am besten löst — inklusive der modellspezifischen Features, wenn sie den Unterschied machen. Aber darunter liegt immer eine dünne Abstraktion und eine portable Eval-Suite, die wir auf Knopfdruck gegen jedes Modell laufen lassen. So bleibt der Wechsel eine Messung von einer Nacht statt eines Rewrites von einem Quartal — und unsere Kunden bleiben nicht Geiseln einer einzigen Preisliste.