Jedes Unternehmen, das in den letzten drei Jahren KI in Produktion gebracht hat, hat gleich angefangen: ein API-Schlüssel, eine nutzungsbasierte Rechnung und ein Modell, das jemand anderes betreibt. Das war die richtige Entscheidung. Cloud-KI-APIs verdichten Monate an Infrastrukturarbeit auf einen Nachmittag, und kein vernünftiges Team baut einen Serving-Stack, bevor das Produkt sich bewiesen hat. Aber „richtige erste Wahl“ und „richtige dauerhafte Wahl“ sind zwei verschiedene Behauptungen — und bei einer bestimmten Klasse von Workloads beginnen Rechnung, Datengrenze und Abhängigkeit irgendwann, für eigene Infrastruktur zu sprechen. Die interessante Frage ist nicht, ob man wechselt. Sondern welche Workloads, wann, und wie man sie verlagert, ohne das Unternehmen auf ein Rack Hardware zu verwetten.
Die drei Kräfte
Die erste Kraft ist die Kostenform, nicht die Kostenhöhe. Nutzungsbasierte Preise bedeuten: Die Rechnung ist eine Gerade durch Ihre Nutzung — jeder neue Kunde, jedes Feature, das das Modell aufruft, jeder automatisierte Hintergrundjob schiebt Sie darauf weiter. Erfolg macht es schlimmer — die Rechnung wächst genau deshalb, weil das Produkt funktioniert. Die absolute Zahl ist weniger wichtig als die Form: Ein Unternehmen, dessen Stückkosten eine Gebühr pro Aufruf an einen Dritten enthalten, hat ein Stück seiner Marge ausgelagert, dauerhaft, zu einem Preis, den es nicht selbst festlegt. Eigene Inferenz kehrt die Form um — Kapitalkosten plus vergleichsweise flache Betriebskosten —, sodass jenseits einer gewissen Auslastung jeder zusätzliche Aufruf fast nichts kostet. Wo dieser Schnittpunkt liegt, ist eine empirische Frage, die Sie mit Ihrem eigenen Traffic beantworten, nicht mit einer Zahl aus irgendeinem Blogbeitrag.
Die zweite ist die Datengrenze. Jeder Prompt ist ein Export: Kundendaten, Vertragsklauseln, medizinische Notizen, Code — was immer der Workload berührt, verlässt Ihre Infrastruktur und durchläuft einen Verarbeiter, den Sie über Papier prüfen statt über Zugriff. Verträge, Aufbewahrungsklauseln und regionales Hosting mildern das; für viele Workloads mildern sie es genug. Aber manche Daten sind radioaktiv genug — reguliert, privilegiert, wettbewerblich sensibel —, dass die sauberste Compliance-Geschichte die kürzeste ist: Die Daten verlassen das Haus nie. Dieses Argument wird jedes Mal stärker, wenn ein Workload tiefer in den Kern des Unternehmens wandert.
Die dritte Kraft ist die leiseste: die Entscheidungen anderer. Eine nutzungsbasierte API ist eine Abhängigkeit, deren Roadmap Sie nicht kontrollieren. Modelle werden nach dem Zeitplan des Anbieters abgekündigt, und der Nachfolger — so fähig er sein mag — verhält sich anders gegenüber den Prompts und Evals, die Sie auf seinen Vorgänger abgestimmt haben. Rate-Limits, Kapazität und Preise ändern sich per Ankündigung. Nichts davon ist Böswilligkeit; es ist das, was es heißt, stromabwärts zu sitzen. Ein System, das still zur Kerninfrastruktur geworden ist, verdient dieselbe Prüfung, die Sie jedem anderen einzelnen Lieferanten im kritischen Pfad zukommen lassen würden.
Die Rechnung wächst genau deshalb, weil das Produkt funktioniert. Die Kostenform, nicht die Kostenhöhe, erzwingt das Gespräch.
Das ehrliche Gegenargument
Eigene Infrastruktur ist öfter die falsche Entscheidung als die richtige, und die Ausnahmen verdienen es, klar benannt zu werden. Ist Ihr Volumen überschaubar, ist die nutzungsbasierte Abrechnung günstiger als das Ops-Gehalt, das Sie zusätzlich bräuchten — das Schnittpunkt-Argument schneidet in beide Richtungen. Braucht Ihr Workload wirklich die Fähigkeiten eines Frontier-Modells, halten Open-Weight-Alternativen womöglich noch nicht mit, und kein Hardwarekauf schließt eine Qualitätslücke. Und wenn niemand im Team GPUs, Treiber, Serving-Software und Kapazitätsplanung als vollwertige betriebliche Verantwortung übernehmen kann, verwandelt der Hardwarekauf eine Rechnung in einen Ausfallgenerator. Der Wechsel ergibt Sinn am Schnittpunkt dreier Bedingungen: anhaltendes Volumen, Workloads, die Open-Weight-Modelle in der benötigten Qualität bewältigen, und die betriebliche Reife, das Gekaufte zu betreiben — oder ein Partner, der sie mitbringt.
Was Eigenbetrieb tatsächlich bedeutet
Die Arbeit ist konkret und größtenteils unglamourös. Die Dimensionierung kommt zuerst: Inferenz-Hardware wird gegen Ihren realen Traffic ausgewählt — Modellgröße, Kontextlängen, Latenzziele, Spitzenlast — nicht gegen ein Datenblatt. Die Modellauswahl ist eine Evaluationsübung, keine Leaderboard-Lektüre: Open-Weight-Kandidaten laufen gegen ein Eval-Set, das aus Ihrem tatsächlichen Workload gebaut ist, denn der einzige Benchmark, der zählt, ist Ihrer. Der Serving-Stack — Inferenzserver, Batching, Quantisierung, Failover — ist heute ausgereiftes offenes Tooling, aber er ist ein System, das betrieben werden will, mit dem Monitoring, dem Alerting und der Upgrade-Disziplin, die jedes Produktivsystem verlangt. Und Qualitätstelemetrie tritt neben die üblichen Dashboards: Eigene Modelle verbessern sich nicht still unter Ihnen, aber sie verschlechtern sich auch nicht still — Sie besitzen das Tempo, also besitzen Sie auch das Bemerken.
Eine Disziplin hält das Ganze zusammen: die Cloud-Baseline. Bevor ein Workload umzieht, wird sein aktuelles Verhalten gemessen — Qualität auf dem Eval-Set, Latenz, Kosten pro Arbeitseinheit. Der eigene Stack verdient sich den Workload, indem er diese Baseline nachweislich erreicht oder schlägt, vor der Umstellung. Ohne Baseline ist die Migration ein Vertrauensvorschuss, gefolgt von einem Streit. Mit ihr ist sie ein Benchmark-Ergebnis, gefolgt von einer Entscheidung.
Migrieren wie beim Deployment: ein Workload nach dem anderen
Das Muster, das funktioniert, ist dasselbe wie bei jedem riskanten Ersatz: inkrementell, umkehrbar, gemessen. Workloads ziehen einzeln um, die risikoärmsten zuerst — interne Werkzeuge und Batch-Verarbeitung vor allem, was Kunden berührt. Jeder Workload fährt Schatten-Traffic auf dem eigenen Stack, während die API maßgeblich bleibt; halten die Benchmarks unter realer Last, wird umgestellt, mit der API als Rückfallebene, bis Vertrauen verdient statt unterstellt ist. Es ist das Strangler-Muster, angewandt auf Inferenz, und es bedeutet: Das Unternehmen ist nie einen schlechten Tag davon entfernt, alles auf neue Hardware gesetzt zu haben. Das ist die Form eines Projekts, das wir gerade jetzt durchführen: eigene Inferenz-Hardware, spezifiziert gegen gemessene Workloads, Migration Workload für Workload, jede Umstellung an ihrer Cloud-Baseline gemessen.
Ein Nebeneffekt dieser Vorgehensweise verdient Erwähnung: Die Eval-Sets, Baselines und das Routing, die Sie für die Migration bauen, verbessern dauerhaft, wie Sie KI betreiben. Sie beenden das Projekt mit dem Wissen, was jeder Workload braucht, was er auf jeder Grundlage kostet und wie man ihn erneut verlagert — womit die nächste Preisänderung oder Modellabkündigung eines Anbieters eine Tabellenübung ist statt eines Feuerwehreinsatzes. Optionalität zahlt sich, einmal gebaut, immer weiter aus.
Der Endzustand ist meist hybrid
Es lohnt sich, das ausdrücklich zu sagen, weil die Debatte meist als Entweder-oder geführt wird: Fast niemand landet vollständig außerhalb der Cloud, und das ist kein Scheitern der Migration. Der stabile Endzustand ist für die meisten Unternehmen eine Routing-Entscheidung pro Workload. Workloads mit hohem Volumen, gutem Verständnis und sensiblen Daten laufen auf eigener Infrastruktur, wo die flache Kostenform und die kurze Compliance-Geschichte ihre Arbeit tun. Experimentelle Features, sprunghafte Lasten und alles, was wirklich ein Frontier-Modell braucht, bleiben auf nutzungsbasierten APIs, wo Elastizität und Fähigkeit den Preis pro Aufruf wert sind. Die eigene Infrastruktur wird zur Grundlinie; die API wird, was sie immer hätte sein sollen — eine Premium-Option, zu der man bewusst greift, kein Standard, in den man hineingedriftet ist. Die Routing-Schicht, die das möglich macht, ist dünn, aber sie verändert die Verhandlungsposition vollständig: Jeder Workload hat ein Zuhause, in das er umziehen kann, und jeder Anbieter weiß es.
Die Entscheidung, komprimiert
Bleiben Sie auf nutzungsbasierten APIs, solange das Volumen klein ist, solange Sie Fähigkeiten brauchen, die nur Frontier-Modelle bieten, oder solange niemand den Betrieb übernehmen kann. Beginnen Sie zu messen, sobald die Rechnung ein Posten wird, nach dem die Geschäftsführung fragt: Bauen Sie das Eval-Set, erfassen Sie die Baselines, berechnen Sie den Schnittpunkt mit Ihren eigenen Zahlen. Wechseln Sie, wenn ein Workload alle drei Tests besteht — anhaltendes Volumen, erreichbare Qualität auf Open-Weight-Modellen, ein Verantwortlicher für die Infrastruktur —, und verlagern Sie ihn auf die langweilige Art: eine benchmark-gesicherte Umstellung nach der anderen. Die Unternehmen, die das richtig machen, behandeln eigene KI-Infrastruktur nicht als Statement. Sie behandeln sie wie jede andere Bauen-oder-Mieten-Entscheidung: mit einer Baseline, einem Benchmark und einem umkehrbaren Weg.