Das eigene Modell: Wann sich Open-Weight-LLMs gegen die API lohnen // nh labs

Eine Frage, die entschieden schien

Zwei Jahre lang gab es auf die Frage „Welches Modell nehmen wir?" eine fast reflexhafte Antwort: das beste, das man mieten kann. OpenAI, Anthropic, Google – API-Key holen, los. Das war keine Bequemlichkeit, sondern Vernunft. Der Abstand zwischen den Frontier-Modellen und allem darunter war so groß, dass die Alternative – ein Modell selbst betreiben – nach Ideologie roch. Nach „wir machen das aus Prinzip selbst", nicht nach einer wirtschaftlichen Entscheidung.

Dieser Abstand ist geschrumpft. Llama, Mistral, Qwen, DeepSeek, Gemma und ihre Verwandten erreichen heute für eine wachsende Zahl von Aufgaben eine Qualität, die vor zwei Jahren den geschlossenen Spitzenmodellen vorbehalten war. Damit stellt sich eine Frage neu, die viele längst abgehakt hatten: Wann lohnt es sich, ein Modell selbst zu betreiben, statt eine fremde API anzurufen?

Die ehrliche Antwort ist kein „immer" und kein „nie". Sie ist ein Entscheidungsrahmen – und es lohnt, ihn nüchtern durchzugehen, statt aus Prinzip auf eine Seite zu fallen.

Mieten oder besitzen – angewandt auf Intelligenz

Im Kern ist das keine neue Frage, nur ein neues Objekt. Mieten oder besitzen – diese Entscheidung trifft jedes Unternehmen ständig: Büro, Server, Fuhrpark. Neu ist, dass sie jetzt für die Intelligenz selbst ansteht.

Eine Frontier-API zu nutzen heißt: das beste Gehirn der Welt auf Abruf mieten. Man zahlt pro Nutzung, bekommt sofort das jeweils Neueste, kümmert sich um nichts dahinter. Ein Open-Weight-Modell selbst zu betreiben heißt: ein gut-genug-Gehirn besitzen, das man vollständig kontrolliert. Es ist nicht das schärfste am Markt, aber es gehört einem, läuft, wo man will, ändert sich nur, wenn man es will, und kostet pro Anfrage praktisch nichts mehr, sobald die Hardware steht.

Wie bei jeder Miet-oder-Kauf-Frage gibt es keine prinzipiell richtige Antwort. Es gibt nur die Frage, die zu wenige stellen: Was genau ist die Arbeitslast – und passt zu ihr eher Mieten oder Besitzen?

Wo sich der Eigenbetrieb lohnt

Mehrere Konstellationen kippen die Rechnung zugunsten des eigenen Modells – oft mehrere davon gleichzeitig.

Hohes, gleichmäßiges Volumen. Die Pro-Token-Ökonomie der API ist bei niedrigem Volumen unschlagbar: Man zahlt nur, was man nutzt. Sie kehrt sich um, sobald man eine GPU auslastet. Eine Anfrage, die über die API ein paar Cent kostet, kostet auf einer gut ausgelasteten eigenen Karte einen Bruchteil davon – weil sich die Fixkosten der Hardware über Millionen von Anfragen verteilen. Wer konstant und in großen Mengen klassifiziert, extrahiert, zusammenfasst oder übersetzt, erreicht einen Break-even, ab dem jede weitere Anfrage auf der eigenen Hardware fast umsonst ist.

Daten, die das Haus nicht verlassen dürfen. Manche Daten kann man nicht an eine fremde API schicken – nicht aus Prinzip, sondern aus Regulierung: Patientendaten, Verträge, personenbezogene Bestände unter strengen Residency-Vorgaben. Wenn die Daten das eigene Perimeter nicht verlassen dürfen, ist ein Modell, das im eigenen Rechenzentrum läuft, nicht die teurere Option – es ist die einzige.

Latenz, Offline, Edge. Jeder API-Call ist ein Netzwerk-Roundtrip in ein fremdes Rechenzentrum. Für eine Anwendung, die in Millisekunden antworten muss, die an einem Ort ohne verlässliches Netz läuft oder direkt auf einem Gerät – in der Fabrik, im Fahrzeug, am Point of Sale –, ist das ein Problem, das kein API-Vertrag löst. Ein lokales Modell antwortet, auch wenn die Leitung weg ist.

Vorhersagbare Kosten. Eine API-Rechnung schwankt mit der Nutzung, und der Anbieter ändert seine Preise, wann er will. Eine eigene GPU kostet jeden Monat dasselbe, egal wie oft sie rechnet. Für die Planung ist das ein Unterschied ums Ganze: feste Kosten statt einer Variable, die jemand anderes kontrolliert. Keine Überraschungsrechnung, keine Preis-Mail, die ein Geschäftsmodell über Nacht in Frage stellt.

Spezialisierung auf eine enge Aufgabe. Hier liegt der unterschätzteste Vorteil. Ein generisches Frontier-Modell ist auf alles halbwegs gut. Ein kleines offenes Modell, das man auf genau eine Aufgabe feinjustiert – die eigene Produktklassifikation, den eigenen Tonfall, das eigene Fachvokabular –, schlägt den generischen Riesen auf dieser einen Aufgabe regelmäßig: schneller, billiger, oft auch genauer. Man tauscht Allgemeinbildung gegen Tiefe in dem, was zählt.

Unabhängigkeit vom Fahrplan des Anbieters. Wer auf einer fremden API baut, baut auf deren Fahrplan: Modelle werden abgekündigt, Endpoints verschwinden, Rate-Limits ändern sich, das Verhalten verschiebt sich mit dem nächsten stillen Update. Ein Modell, dessen Gewichte man besitzt, läuft heute wie in drei Jahren – byte-identisch, solange man will. Für alles, was reproduzierbar und prüfbar sein muss, ist das kein Luxus, sondern Voraussetzung.

Wo die API weiter gewinnt

Genauso wichtig ist die andere Richtung – sonst baut man aus Prinzip eine Infrastruktur, die man nicht braucht.

Wenn man die absolute Spitze braucht. Bei den härtesten Aufgaben – mehrstufiges Schließen, komplexe Agenten, die neuesten Fähigkeiten Tage nach ihrer Veröffentlichung – führen die geschlossenen Frontier-Modelle weiter. Der Abstand ist geschrumpft, nicht verschwunden. Wenn die Aufgabe genau diese Spitze verlangt, ist Mieten nicht die bequeme, sondern die richtige Wahl.

Sprunghaftes oder geringes Volumen. Der Eigenbetrieb rechnet sich über Auslastung. Eine GPU, die meistens im Leerlauf steht, ist reine Kostenstelle – man bezahlt sie auch in den zwanzig Stunden am Tag, in denen niemand sie braucht. Bei schwankender, geringer oder noch unklarer Last gewinnt die API: Man zahlt nur die Spitzen, nicht das Warten dazwischen.

Wenn man die Inferenz-Infrastruktur nicht betreiben will. Ein Modell zu hosten heißt: GPUs bereitstellen, Kapazität planen, patchen, monitoren, für Uptime geradestehen. Das ist ein laufender Betrieb mit Bereitschaft und Verantwortung, kein einmaliges Setup. Wer dieses Geschäft nicht führen will – aus guten Gründen –, mietet besser.

Tempo zum ersten Prototyp. Nichts ist schneller als ein API-Key und drei Zeilen Code. Für die ersten Wochen eines Produkts, für das Validieren einer Idee, für alles, was vielleicht morgen wieder verworfen wird, ist der Eigenbetrieb der falsche Aufwand zur falschen Zeit. Erst mieten, lernen – und nur dann besitzen, wenn sich Volumen und Anforderung verfestigt haben.

Kleines Team ohne MLOps-Muskel. Ein eigenes Modell sinnvoll zu betreiben verlangt Können: Inferenz-Stacks, Evaluierung, Monitoring, das Wissen, wann ein Modell still schlechter wird. Fehlt dieses Können im Team und lässt es sich nicht aufbauen oder einkaufen, ist die selbstbetriebene Lösung kein Vorteil, sondern eine Quelle stiller Risiken.

Die ehrliche Kostenrechnung

Die häufigste Fehlkalkulation ist, GPU-Preis gegen Token-Preis zu stellen und beim Stundensatz der Karte aufzuhören. So einfach ist es nicht.

Auf die Seite des Eigenbetriebs gehören nicht nur die Hardware oder die GPU-Stunden in der Cloud, sondern:

die Ingenieure, die den Inferenz-Stack aufsetzen und am Laufen halten
der laufende Betrieb – Monitoring, Patching, Bereitschaft, Uptime
Evaluierung und Qualitätssicherung, damit niemand zu spät merkt, dass das Modell driftet oder ein Update die Ergebnisse verschiebt
der Leerlauf – jede Stunde, in der die teure Karte nichts tut
die Opportunitätskosten – dieselben Leute könnten am Produkt arbeiten statt an Infrastruktur

Erst mit diesen Posten ist der Vergleich fair. Und erst dann zeigt sich der eigentliche Punkt: Der Break-even ist keine Frage des Bauchgefühls, sondern eine Rechnung aus Volumen und Kontrollbedarf. Bei hohem, stetigem Volumen amortisiert sich der Eigenbetrieb schnell, und jede weitere Million Anfragen macht den Abstand größer. Bei niedrigem Volumen bezahlt man teure Hardware fürs Warten. Und der Kontrollbedarf – Compliance, Residency, Reproduzierbarkeit – kann die Rechnung allein kippen, auch wenn das Volumen sie nicht trägt: Manchmal ist der Eigenbetrieb teurer und trotzdem die einzig zulässige Option.

Das Muster, auf dem die meisten landen sollten

In der Praxis ist die Antwort selten „alles über die API" oder „alles selbst". Sie ist hybrid – und das ist kein Kompromiss aus Unentschlossenheit, sondern meist die beste Architektur.

Das Prinzip: nach Aufgabe routen. Die große, gleichförmige, sensible Masse – Klassifikation, Extraktion, erste Entwürfe, Standardübersetzungen, das billige Vorsortieren – läuft auf dem eigenen Open-Weight-Modell. Die seltenen, schweren, wirklich anspruchsvollen Fälle – das komplexe Schließen, der Grenzfall, die Aufgabe an der Spitze – gehen an die Frontier-API. Ein Klassifikator oder eine simple Heuristik entscheidet, was wohin geht.

Die Faustregel dahinter: Die langweiligen 80 % besitzen, die kritischen 20 % mieten. Das Volumen, das die eigenen Kosten frisst und die eigenen Daten berührt, holt man ins Haus. Die Spitzenleistung, die man selten, aber dann unbedingt braucht, kauft man pro Anfrage zu. So zahlt man die API nur für das, wofür sie unersetzlich ist – und nicht als Mautstelle für jede triviale Anfrage.

Die Checkliste

Bevor man baut, lohnt der nüchterne Durchgang durch fünf Fragen:

Volumen? Hoch und stetig genug, um eine GPU auszulasten? Dann spricht die Ökonomie für den Eigenbetrieb. Sprunghaft oder gering? Dann für die API.
Datenrestriktionen? Müssen die Daten aus Compliance-, Residency- oder Vertraulichkeitsgründen im eigenen Perimeter bleiben? Dann ist der Eigenbetrieb oft nicht Option, sondern Pflicht.
Fähigkeits-Obergrenze? Reicht ein gut-genug-Modell für die Aufgabe, oder braucht es die absolute Spitze? Je näher an der Grenze des Machbaren, desto eher die API.
Reife des Teams im Betrieb? Gibt es das Können, Inferenz zu betreiben, zu evaluieren, zu monitoren – oder lässt es sich aufbauen? Ohne diese Reife wird das eigene Modell zum Risiko.
Wie viel Kostenvorhersagbarkeit braucht das Geschäft? Sind feste, planbare Kosten wichtiger als minimaler Einstiegsaufwand? Dann zählt der Eigenbetrieb mehr, als die reine Token-Rechnung zeigt.

Mehrheitlich „Eigenbetrieb"? Dann lohnt der Aufbau – wahrscheinlich für einen Teil der Last. Mehrheitlich „API"? Dann ist Mieten die richtige, nicht die faule Wahl. Und in den meisten Fällen liegt die Antwort dazwischen: ein Teil hierhin, ein Teil dorthin.

Fazit

Dass Open-Weight-Modelle den Abstand zur Spitze verkürzt haben, macht den Eigenbetrieb nicht zur neuen Pflicht – es macht ihn zur ernsthaften Option, wo er vorher nach Ideologie aussah. Ein Modell selbst zu betreiben ist kein Bekenntnis und kein Gratis-Mittagessen. Es ist eine technische Verpflichtung mit laufendem Betrieb, die sich für bestimmte, gut verstandene Arbeitslasten auszahlt – und für andere eben nicht.

Die richtige Frage ist nicht „API oder eigenes Modell" als Glaubenssatz, sondern „welche Arbeitslast, und was passt zu ihr". Hohes Volumen, harte Datenrestriktionen, Latenz, vorhersagbare Kosten, eine eng spezialisierte Aufgabe – das spricht fürs Besitzen. Die absolute Spitze, sprunghafte Last, fehlender MLOps-Muskel, Tempo zum Prototyp – das spricht fürs Mieten. Und meistens spricht beides zugleich, für verschiedene Teile desselben Systems.

Genau diese Build-or-Rent-Entscheidung treffen wir bei nh labs mit unseren Kunden – ohne Ideologie, an der konkreten Arbeitslast entlang. Das Ziel ist nie „selbst hosten" oder „immer die API", sondern das richtige Werkzeug pro Aufgabe. Oft ist das ein Hybrid: die langweiligen 80 % im eigenen Haus, die kritischen 20 % gemietet.