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 richtig so, denn Cloud-KI-APIs verdichten Monate an Infrastrukturarbeit auf einen Nachmittag, und kein vernünftiges Team richtet einen Serving-Stack ein, bevor das Produkt sich bewiesen hat. Aber „richtige erste Wahl“ und „richtige dauerhafte Wahl“ sind zwei verschiedene Behauptungen: Bei einer bestimmten Klasse von Workloads fangen Rechnung, Datengrenze und Abhängigkeit irgendwann an, für eigene Infrastruktur zu sprechen. Die interessante Frage lautet deshalb nicht, ob man wechselt, sondern welche Workloads, wann und auf welchem Weg - ohne dass am Ende das ganze Unternehmen an einem Rack Hardware hängt.
Die drei Kräfte
Die erste Kraft ist die Kostenform, nicht die Kostenhöhe. Nutzungsbasierte Preise bedeuten, dass die Rechnung eine Gerade durch Ihre Nutzung zieht: Jeder neue Kunde, jedes Feature, das das Modell aufruft, und jeder automatisierte Hintergrundjob schiebt Sie ein Stück weiter darauf. Erfolg verschärft das, weil die Rechnung genau dann wächst, wenn das Produkt funktioniert. Die absolute Zahl ist dabei weniger wichtig als die Form: Wer in seinen Stückkosten eine Gebühr pro Aufruf an einen Dritten trägt, hat ein Stück seiner Marge dauerhaft ausgelagert, zu einem Preis, den er nicht selbst festlegt. Eigene Inferenz dreht die Form um, weil Kapitalkosten und vergleichsweise flache Betriebskosten an die Stelle des Zählers treten; jenseits einer gewissen Auslastung kostet jeder weitere Aufruf fast nichts mehr. Wo dieser Schnittpunkt liegt, beantworten Sie empirisch mit Ihrem eigenen Traffic und nicht mit einer Zahl aus einem Blogbeitrag.
Die zweite Kraft ist die Datengrenze. Jeder Prompt ist ein Export: Kundendaten, Vertragsklauseln, medizinische Notizen, Code - was immer der Workload berührt, verlässt Ihre Infrastruktur und läuft über einen Verarbeiter, den Sie über Papier prüfen und nicht über Zugriff. Verträge, Aufbewahrungsklauseln und regionales Hosting mildern das, und für viele Workloads mildern sie es genug. Manche Daten sind allerdings so heikel, weil reguliert, anwaltlich geschützt oder wettbewerbskritisch, dass die sauberste Compliance-Geschichte zugleich die kürzeste ist: Die Daten verlassen das Haus nie. Dieses Argument wird mit jedem Workload stärker, der tiefer in den Kern des Unternehmens rückt.
Die dritte Kraft ist die leiseste: die Entscheidungen anderer. Eine nutzungsbasierte API ist eine Abhängigkeit, deren Roadmap Sie nicht steuern. Modelle werden nach dem Zeitplan des Anbieters abgekündigt, und der Nachfolger verhält sich, so fähig er sein mag, anders als der Vorgänger, auf den Sie Ihre Prompts und Evals abgestimmt haben. Rate-Limits, Kapazitäten und Preise ändern sich per Ankündigung. Nichts davon ist Böswilligkeit, sondern schlicht der Preis dafür, Abnehmer zu sein. Ein System, das still zur Kerninfrastruktur geworden ist, verdient dieselbe Prüfung wie jeder andere einzelne Lieferant im kritischen Pfad.
Die Rechnung wächst genau dann, wenn das Produkt funktioniert. Nicht die Höhe der Kosten erzwingt das Gespräch, sondern ihre Form.
Das ehrliche Gegenargument
Eigene Infrastruktur ist häufiger die falsche als die richtige Entscheidung, und die Ausnahmen gehören klar benannt. Bei überschaubarem Volumen ist die nutzungsbasierte Abrechnung günstiger als das Ops-Gehalt, das Sie zusätzlich tragen müssten; das Schnittpunkt-Argument schneidet in beide Richtungen. Braucht Ihr Workload tatsächlich 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, wird aus dem Hardwarekauf eine verlässliche Quelle von Ausfällen. Der Wechsel ergibt Sinn, wo drei Bedingungen zusammenkommen: anhaltendes Volumen, Workloads, die Open-Weight-Modelle in der geforderten Qualität bewältigen, und die betriebliche Reife, das Gekaufte auch zu betreiben - oder ein Partner, der sie mitbringt.
Was der Eigenbetrieb tatsächlich verlangt
Die Arbeit ist konkret und selten spektakulär. Am Anfang steht die Dimensionierung: Inferenz-Hardware wählt man anhand des realen Traffics aus, also anhand von Modellgröße, Kontextlängen, Latenzzielen und Spitzenlast, nicht anhand eines Datenblatts. Die Modellauswahl ist eine Evaluationsübung und keine Leaderboard-Lektüre: Open-Weight-Kandidaten laufen auf einem Evaluationsset, das aus Ihrem tatsächlichen Workload stammt, denn der einzige Benchmark, der zählt, ist Ihrer. Der Serving-Stack aus Inferenzserver, Batching, Quantisierung und Failover ist heute ausgereiftes offenes Tooling, bleibt aber ein System, das betrieben werden muss - mit dem Monitoring, dem Alerting und der Upgrade-Disziplin, die jedes Produktivsystem verlangt. Dazu tritt die Qualitätstelemetrie neben die üblichen Dashboards: Eigene Modelle verbessern sich nicht unbemerkt unter Ihnen, sie verschlechtern sich aber auch nicht unbemerkt, weil Sie das Tempo bestimmen und damit auch die Pflicht tragen, Abweichungen zu sehen.
Ein Prinzip hält das Ganze zusammen: die Cloud-Basislinie. Bevor ein Workload umzieht, wird sein heutiges Verhalten gemessen, also Qualität auf dem Evaluationsset, Latenz und Kosten je Arbeitseinheit. Der eigene Stack verdient sich den Workload, indem er diese Basislinie vor der Umstellung nachweislich erreicht oder schlägt. Ohne Basislinie ist die Migration ein Vertrauensvorschuss, auf den ein Streit folgt. Mit ihr ist sie ein Benchmark-Ergebnis, auf das eine Entscheidung folgt.
Ein Workload nach dem anderen, wie bei jedem Rollout
Das Muster, das trägt, ist dasselbe wie bei jedem riskanten Ersatz: inkrementell, umkehrbar, gemessen. Workloads ziehen einzeln um, die risikoärmsten zuerst, also interne Werkzeuge und Batch-Verarbeitung vor allem, was Kunden berührt. Jeder Workload fährt zunächst Schatten-Traffic auf dem eigenen Stack, während die API maßgeblich bleibt; halten die Benchmarks unter realer Last, wird umgestellt, und die API bleibt Rückfallebene, bis das Vertrauen verdient und nicht unterstellt ist. Es ist das Strangler-Muster, angewandt auf Inferenz, und es sorgt dafür, dass das Unternehmen nie einen schlechten Tag davon entfernt ist, alles auf neue Hardware gesetzt zu haben. Genau so verläuft ein Projekt, das wir derzeit durchführen: eigene Inferenz-Hardware, spezifiziert anhand gemessener Workloads, Migration Workload für Workload, jede Umstellung an ihrer Cloud-Basislinie geprüft.
Ein Nebeneffekt dieses Vorgehens verdient Erwähnung: Die Evaluationssets, die Basislinien und das Routing, die für die Migration entstehen, verbessern dauerhaft, wie Sie KI betreiben. Am Ende des Projekts wissen Sie, was jeder Workload braucht, was er auf welcher Grundlage kostet und wie Sie ihn erneut verlagern. Die nächste Preisänderung eines Anbieters oder die nächste Modellabkündigung ist damit eine Tabellenübung statt eines Feuerwehreinsatzes. Wer sich diese Wahlfreiheit einmal erarbeitet hat, profitiert dauerhaft davon.
Der Endzustand ist meist hybrid
Das gehört ausdrücklich gesagt, 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 je 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 Wirkung entfalten. Experimentelle Features, sprunghafte Lasten und alles, was wirklich ein Frontier-Modell verlangt, bleiben auf nutzungsbasierten APIs, wo Elastizität und Fähigkeit den Preis pro Aufruf wert sind. Die eigene Infrastruktur wird zur Basislinie, und die API wird das, was sie immer hätte sein sollen: eine Premium-Option, zu der man bewusst greift, und kein Standard, in den man hineingerutscht ist. Die Routing-Schicht, die das möglich macht, ist dünn, verändert aber die Verhandlungsposition vollständig, weil jeder Workload einen zweiten Ort hat, an dem er laufen kann - und jeder Anbieter das weiß.
Die Entscheidung in Kurzform
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. Fangen Sie an zu messen, sobald die Rechnung ein Posten wird, nach dem die Geschäftsführung fragt: Erstellen Sie das Evaluationsset, erfassen Sie die Basislinien, rechnen Sie den Schnittpunkt mit Ihren eigenen Zahlen durch. Wechseln Sie erst, wenn ein Workload alle drei Prüfungen 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. Unternehmen, die das richtig machen, behandeln eigene KI-Infrastruktur nicht als Statement, sondern wie jede andere Entscheidung zwischen Eigenbau und Miete: mit einer Basislinie, einem Benchmark und einem umkehrbaren Weg.