Analyse: Ein offenes Modell selbst hosten — die Rechnung, die darüber entscheidet, und die Kosten, die niemand einplant

Die Debatte über Self-Hosting ist in ungewöhnlichem Maße anfällig für schlechte Argumente auf beiden Seiten. Das eine Lager hält es für selbstverständlich, dass eigene Infrastruktur günstiger ist, weil die Modellgewichte kostenlos sind. Das andere hält es für ebenso selbstverständlich, dass niemand eigene Beschleuniger betreiben sollte, weil die Hyperscaler eine Auslastung erreichen, an die man selbst niemals herankommen werde.

Beide beschreiben dieselbe Kurve, nur von unterschiedlichen Enden aus. Gehostete Inferenz verursacht variable Kosten, Self-Hosting dagegen Fixkosten, und bei jeder realen Entscheidung geht es darum, wo eine konkrete Arbeitslast im Verhältnis zum Schnittpunkt liegt.

Die Struktur des Vergleichs

Bringen wir beide Seiten auf dieselbe Einheit.

Eine gehostete API rechnet pro Token ab. Zehn Millionen Eingabe- und zwei Millionen Ausgabe-Token pro Tag kosten einen vorhersehbaren Betrag, und die Rechnung steigt und fällt linear mit der Nutzung. An einem ruhigen Wochenende sinkt sie.

Beim Self-Hosting wird jede Betriebsstunde eines Beschleunigers berechnet, unabhängig davon, ob eine Anfrage eingeht. Die Mietpreise für aktuelle Rechenzentrums-GPUs liegen bei den meisten Anbietern im niedrigen einstelligen Dollarbereich pro Stunde und Karte, wobei sie je nach Region, Vertragsbindung und Anbietersegment stark variieren. Bei eigener Hardware werden daraus Investitionskosten zuzüglich Strom, Kühlung und Abschreibung; nach der Amortisierung ergibt sich meist eine ähnliche Größenordnung. Entscheidend ist, dass beides pro Stunde und nicht pro Token anfällt.

Die Rechnung sieht also so aus:

Was Teams häufig überrascht, ist die zweite Zeile. Ein Cluster, der für Spitzenlast dimensioniert ist und im Durchschnitt zu 15 % ausgelastet wird, bezahlt rund um die Uhr für Spitzenkapazität, obwohl der Datenverkehr nur schubweise eintrifft. Der Vergleich der Tokenpreise, der bei Volllast günstig aussah, liegt beim tatsächlichen Durchschnitt um den Faktor sechs daneben.

Durchsatz ist eine Eigenschaft der Software

Der häufigste Analysefehler besteht darin, den Durchsatz als eine von der Hardware bestimmte Größe zu behandeln. Mindestens ebenso stark wird er vom Serving-Stack bestimmt.

Batching ist der wichtigste Faktor. Wer auf einem großen Beschleuniger immer nur eine Anfrage bearbeitet, lässt den Großteil seiner Leistung ungenutzt. Kontinuierliches Batching, bei dem neue Anfragen einem bereits laufenden Batch hinzugefügt werden, statt auf dessen Abschluss zu warten, kann den Durchsatz auf derselben Karte um ein Vielfaches erhöhen. Ein Kostenmodell für Self-Hosting, das auf Benchmarks mit Einzelanfragen beruht, wird um genau dieses Vielfache danebenliegen.

Quantisierung verändert, was in den Speicher passt. Werden die Modellgewichte mit 8-Bit- oder 4-Bit-Präzision bereitgestellt, sinkt der Speicherbedarf erheblich. Dadurch kann ein Modell statt zwei Karten nur noch eine benötigen. Eine Karte ist gegenüber zwei nicht nur 50 % günstiger, sondern zugleich entfällt eine ganze Klasse komplexer Verbindungsprobleme. Moderne Verfahren zur Quantisierung nach dem Training arbeiten bei vielen Aufgaben häufig nahezu verlustfrei. Doch „häufig“ und „viele“ sind hier entscheidende Einschränkungen: Das Ergebnis muss mit dem eigenen Evaluationsdatensatz geprüft werden, denn Qualitätseinbußen sind aufgabenspezifisch und werden von einem Durchschnittswert verdeckt.

Die Modellgröße ist der Hebel mit der größten Wirkung. Die Wirtschaftlichkeit des Self-Hostings hängt meist davon ab, ein Modell zu betreiben, das klein genug ist, um zahlreiche gleichzeitige Anfragen pro Beschleuniger zu bedienen. Gerade die stetigen Fortschritte des Open-Weight-Ökosystems bei kleinen Modellen haben Self-Hosting für gewöhnliche Produkte praktikabel gemacht. Eine Aufgabe, die tatsächlich ein Modell auf Frontier-Niveau erfordert, bringt eine völlig andere Hardware-Rechnung und ein deutlich schwächeres Argument für Self-Hosting mit sich.

Die vier fehlenden Posten der ersten Kalkulation

Alle ersten Self-Hosting-Kalkulationen, die ich gesehen habe, weisen dieselben Lücken auf.

Redundanz. Ein einzelner Knoten ist eine Demo. Für den Produktivbetrieb braucht es mindestens zwei in unterschiedlichen Ausfalldomänen sowie Reserven für einen rollierenden Neustart. Das ist keine Korrektur um 10 %; häufig verdoppelt sich der Hardwareposten schon vor jedem Wachstum des Datenverkehrs.

Arbeitszeit der Entwickler. Jemand konfiguriert den Serving-Stack, optimiert die Batch-Parameter, richtet die automatische Skalierung ein, schreibt die Zustandsprüfungen, kümmert sich um das Treiber-Upgrade, das den Kernel beschädigt, und wird alarmiert, wenn der Durchsatz um zwei Uhr morgens einbricht. Bei realistisch angesetzten Vollkosten dieser Person übersteigt bereits ein Bruchteil eines Entwicklerjahres häufig den gesamten GPU-Posten einer mittelgroßen Arbeitslast. Dieser Posten wird am häufigsten ausgelassen, obwohl er oft den Ausschlag gibt.

Evaluation. Self-Hosting bedeutet meist den Wechsel zu einem kleineren Modell. Damit ändert sich die Qualität, und um zu bestätigen, dass sie akzeptabel bleibt, braucht es einen Evaluationsdatensatz, einen Vergleichslauf und das Urteilsvermögen zur Interpretation der Ergebnisse. Das ist echte Arbeit, sie fällt an, bevor sich die ersten Einsparungen einstellen, und wiederholt sich bei jedem Modell-Upgrade.

Die Tretmühle der Upgrades. Gehostete APIs verbessern sich, ohne dass man selbst tätig werden muss. Ein selbst gehosteter Stack verbessert sich nur, wenn jemand die Arbeit übernimmt: die neue offene Version evaluiert, die Serving-Parameter erneut optimiert, den Evaluationsdatensatz noch einmal durchlaufen lässt und die Migration plant. Dieser Aufwand sollte als wiederkehrender Posten eingeplant werden, denn genau das ist er.

Wann Self-Hosting eindeutig gewinnt

All das ist kein Argument gegen Self-Hosting. Es gibt ein bestimmtes Profil, bei dem es eindeutig die richtige Wahl ist.

Stetiges, hohes und vorhersehbares Volumen. Batch-Klassifizierung, Pipelines zur Dokumentenverarbeitung, Erzeugung von Embeddings, Moderationswarteschlangen: Arbeitslasten, die kontinuierlich laufen und Beschleuniger auslasten. Sie sind die besten Self-Hosting-Kandidaten überhaupt, und dass viele von ihnen mit kleinen Modellen auskommen, stärkt das Argument zusätzlich.

Eine Aufgabe, die eng genug für ein kleines Modell ist. Klassifizierung, Extraktion, Weiterleitung, strukturierte Verschlagwortung, Übersetzung innerhalb eines festen Fachgebiets. Erledigt ein sorgfältig ausgewähltes kleines Modell die Aufgabe in akzeptabler Qualität, ist der wirtschaftliche Abstand pro Anfrage zu einer Frontier-API gewaltig.

Offline- oder Air-Gap-Betrieb. Es steht um keinen Preis eine API zur Verfügung. Die Entscheidung fällt aus anderen Gründen.

Gründe jenseits der Kosten

Einige der stärksten Argumente für Self-Hosting sind von der Kalkulation unabhängig.

Datenresidenz und regulatorische Vorgaben. Wo Daten eine Rechtsordnung oder Netzwerkgrenze nicht verlassen dürfen, ist Self-Hosting häufig die einzige regelkonforme Architektur. Das bleibt auch dann richtig, wenn sie mehr kostet.

Eine harte Untergrenze bei der Latenz. Für die Netzwerkumlaufzeit zu einem gehosteten Endpunkt gibt es eine Untergrenze, die bei lokaler Inferenz entfällt. Bei interaktiven Anwendungen mit knappen Latenzbudgets, etwa Sprache, Echtzeitassistenz oder Vervollständigung im Editor, kann diese Untergrenze eine zwingende Anforderung und nicht bloß ein Optimierungsthema sein.

Stabiles Verhalten. Ein gehostetes Modell kann sich im laufenden Betrieb verändern; ein festgeschriebener lokaler Checkpoint nicht. Bei Systemen, die sorgfältig auf das konkrete Verhalten eines Modells abgestimmt wurden, hat diese Stabilität einen Wert, der auf keiner Rechnung erscheint.

Unabhängigkeit von der Roadmap eines Anbieters. Zeitpläne für die Einstellung von Angeboten, Ratenlimits, regionale Verfügbarkeit und Nutzungsbedingungen werden von anderen festgelegt. Wer die Modellgewichte besitzt, beseitigt diese Abhängigkeit, übernimmt dafür aber die Verantwortung für alles Übrige.

Die Lösung, bei der die meisten Teams landen

In der Praxis liegt das häufigste Ergebnis im Produktivbetrieb zwischen den beiden Polen. Es handelt sich um eine Routing-Architektur: Ein kleines, selbst gehostetes Modell bearbeitet den großen, gut verstandenen und volumenstarken Teil des Datenverkehrs; ein gehostetes Frontier-Modell übernimmt den schwierigen Rest, also mehrdeutige Fälle, lange Dokumente und Anfragen, bei denen Qualität wichtiger ist als Kosten.

Damit lassen sich die meisten Einsparungen erzielen, denn im volumenstarken Teil steckt das meiste Geld. Zugleich bleibt eine Qualitätsobergrenze erhalten, die das kleine Modell allein nicht erreichen kann. Auch bei Störungen ist das Verhalten robust: Fällt der lokale Cluster aus, wird der Datenverkehr zu höheren Kosten auf die API umgeleitet, statt dass es zu einem Ausfall kommt.

Auf eines sollte man bestehen: Die Entscheidung muss auf realen Zahlen beruhen. Messen Sie Ihre eigene Auslastungskurve, ermitteln Sie den Durchsatz bei aktiviertem Batching, kalkulieren Sie den Entwicklungsaufwand mit einem realen Gehalt und berücksichtigen Sie die Evaluationsarbeit. Dann wird die richtige Antwort meist offensichtlich. Wer darauf verzichtet, verteidigt am Ende eine Position, die bereits feststand, bevor überhaupt Daten vorlagen.