Eigene Inferenz Kosten berechnen: Ab wann sich GPUs statt Tokens lohnen

Eigene Inferenz Kosten lohnen sich erst bei planbarer, ausreichend hoher Last und einem Workload, der auf einem passenden offenen Modell stabil läuft. Der Break-even ist keine Glaubensfrage: Sie stellen die variablen Token-Kosten eines Cloud-Modells den festen Monatskosten für GPU-Kapazität, Betrieb und Einführung gegenüber.

Viele Unternehmen rechnen dabei zu früh den Preis einer einzelnen GPU gegen einen API-Preis. Das führt in die falsche Richtung. Eine GPU ohne Monitoring, Absicherung, Modellbetrieb und jemanden, der bei einem nächtlichen Fehler reagiert, ist kein produktiver KI-Dienst. Umgekehrt werden Token-Rechnungen unterschätzt, weil ein Pilot mit ein paar tausend Anfragen im Monat ganz anders aussieht als ein Dienst, den die gesamte Belegschaft täglich nutzt.

Die Grundformel für eigene Inferenz Kosten

Die Rechnung beginnt mit zwei Monatswerten. Der erste sind die API-Kosten für den Workload. Der zweite sind die Vollkosten der eigenen Inferenz auf europäischer Infrastruktur, etwa auf reservierter GPU-Kapazität bei STACKIT.

API-Kosten pro Monat = N × ((T_in / 1.000.000 × P_in) + (T_out / 1.000.000 × P_out)) + F_api

Eigene Inferenz Kosten pro Monat = G + B + E + P

Break-even-Anfragen pro Monat = (G + B + E + P) / API-Kosten je Anfrage

Dabei steht N für die monatliche Zahl der Anfragen, T_in für die durchschnittlichen Eingabe-Tokens und T_out für die durchschnittlichen Ausgabe-Tokens. P_in und P_out sind die Token-Preise des Cloud-Modells je Million Tokens, F_api feste Nebenkosten wie Kontingente oder Support. Auf der anderen Seite steht G für die monatliche GPU-Kapazität, B für Betrieb und Bereitschaft, E für den auf den Betrachtungszeitraum verteilten Einführungsaufwand und P für Plattformkosten wie Logging, Monitoring, Routing und Backups.

„Eigene Inferenz“ bedeutet nicht zwingend Hardware im eigenen Keller. Für die meisten Mittelständler ist reservierte GPU-Kapazität in einer europäischen Cloud die vernünftigere Variante. Sie behalten Datenraum und Modellversion unter Kontrolle, ohne ein Rechenzentrum zu betreiben.

Rechenbeispiel: ein interner Wissensassistent

Nehmen wir einen Wissensassistenten für Technik, Einkauf und Service. Jede Anfrage bringt neben der Frage passende Handbuchauszüge mit, die Eingabe ist also um ein Vielfaches länger als die Antwort. Das ist typisch für Retrieval-Augmented Generation, kurz RAG, und der Grund, warum der Preis für Eingabe-Tokens hier stärker wiegt als der für Ausgabe-Tokens.

Setzen Sie die gemessenen Durchschnittswerte in die Formel ein, erhalten Sie die API-Kosten je Anfrage und daraus die Monatskosten bei Ihrem Volumen. Noch nicht enthalten sind Suchindex, Datenaufbereitung und Observability.

Auf der anderen Seite kalkulieren Sie für eine belastbare europäische Inferenz-Umgebung zwei reservierte GPU-Instanzen, nicht eine. Eine Instanz wäre auf dem Papier günstiger, aber Ausfall und Wartungsfenster wären dann ein Betriebsrisiko, das niemand haben will. Dazu kommen ein fester Monatsbetrag für Monitoring, Incident-Bearbeitung, Sicherheitsupdates und Modellpflege, der über den geplanten Nutzungszeitraum verteilte Einführungsaufwand sowie Routing, Audit-Logs und Plattform.

In einem solchen Fall liegt der Break-even häufig nur knapp unter dem tatsächlichen Volumen. Die monatliche Ersparnis ist dann kein spektakulärer Betrag. Der Fall wird trotzdem wirtschaftlich, wenn Kundendaten oder interne Kalkulationen verarbeitet werden und das Modell reproduzierbar bleiben muss. Sie kaufen dann niedrigere Grenzkosten und zugleich eine Architektur, die zu Ihren Risikoanforderungen passt.

Die Auslastung entscheidet stärker als der GPU-Preis

Reservierte GPU-Kapazität rechnet sich nur, wenn sie arbeitet. Der häufigste Fehler in Business Cases ist, den Monatsdurchschnitt als Kapazitätsbedarf zu nehmen. Mitarbeiter stellen ihre Fragen aber nicht gleichmäßig über den Monat verteilt. Montagmorgen, nach einer Prozessänderung oder vor dem Monatsabschluss entstehen Lastspitzen, die das System sauber bedienen muss.

Berechnen Sie die GPU-Anzahl deshalb aus der Spitzenlast:

Benötigte GPUs = Spitzen-Tokens pro Sekunde / (effektive Tokens pro Sekunde je GPU × Zielauslastung)

Die Zielauslastung gehört bei produktiven Anwendungen deutlich unter Volllast. Bei voller Auslastung steigen Antwortzeiten, Warteschlangen wachsen, und ein einzelner Fehler zieht den ganzen Dienst herunter. Für einen Assistenten, der in wenigen Sekunden antworten soll, ist eine spürbare Reserve realistischer als eine ausgereizte Karte.

Kommt bei der Rechnung ein Wert knapp unter zwei heraus, heißt das in der Praxis: zwei GPUs plus eine klare Regel, was bei einem Ausfall passiert. Wer diese Reserve aus der Rechnung streicht, optimiert keinen Kostenblock. Er baut eine Störung ein. Noch ein Hinweis zur Messgröße: Die effektiven Tokens pro Sekunde je GPU hängen vom Modell und von der Quantisierung ab, also der gezielten Reduktion der Rechengenauigkeit zur Beschleunigung. Messen Sie diesen Wert mit Ihrem Modell, nicht mit dem Datenblatt.

Token-Zahlen müssen aus echten Logs kommen

Schätzwerte aus einem Workshop reichen für die Entscheidung nicht. Ziehen Sie mehrere Wochen aus den Logs des bestehenden Systems oder aus einem realistischen Pilot. Messen Sie Anfragen pro Stunde, Eingabe-Tokens, Ausgabe-Tokens, Antwortzeit und Fehlerquote. Besonders wichtig sind die längsten Prompts: Ein RAG-System kann durch zu viele angehängte Dokumentseiten die Eingabe-Tokens verdoppeln, ohne dass die Antwort besser wird.

In einem Maschinenbauunternehmen haben wir genau das gesehen. Der Wissensassistent gab zu jeder Frage eine ganze Reihe Handbuchabschnitte an das Modell, etwa die Hälfte davon fachlich irrelevant. Nach einer besseren Dokumentensuche schrumpfte die durchschnittliche Eingabe auf weniger als die Hälfte. Bei API-Betrieb halbiert das direkt die Kosten. Bei eigener Inferenz senkt es vor allem die erforderliche Kapazität und schiebt den Break-even nach unten.

Bevor Sie GPUs buchen, räumen Sie also Prompt und Suche auf. Schlechte Datenaufbereitung mit teurer Hardware zu kaschieren, ist ein klassischer Architekturfehler.

Was kostet Individualsoftware Mittelstand-Unternehmen wirklich? Die Posten jenseits von GPU und Token

In einer reinen Token-gegen-GPU-Rechnung fehlen regelmäßig Datenaufbereitung, Modellupdates, Sicherheitsprüfungen, Monitoring, Logging und Tests gegen fachliche Fehler. Rechnen Sie auch den Aufwand ein, wenn ein Modell eine falsche Antwort gibt und ein Fachbereich die Ursache nachvollziehen muss. Ein Produktionssystem braucht einen Audit-Trail, keine bloße Chat-Oberfläche. Diese Posten fallen bei API-Betrieb und bei eigener Inferenz gleichermaßen an. Sie verschieben den Break-even kaum, entscheiden aber darüber, ob sich das Gesamtprojekt rechnet.

Kaufhardware ist dabei selten die Antwort. Sie bindet Kapital, verlangt Ersatzteil- und Betriebswissen und passt schlecht zu einem Modellmarkt, der sich alle paar Monate dreht. Reservierte Kapazität in einer europäischen Cloud hat eine kalkulierbare Monatsrate und lässt sich bei geänderter Last anpassen.

Wann der Cloud-API-Betrieb die bessere Entscheidung bleibt

Bei kleinen oder stark schwankenden Mengen bleibt ein Cloud-Modell meistens günstiger. Ein Werkzeug für die Personalabteilung, das monatlich einige tausend interne Textentwürfe erstellt, braucht keine dauerhaft reservierte GPU-Kapazität. Auch für Experimente ist die API der schnellere Weg: Modell auswählen, Kostenlimit setzen, testen, stoppen. Kein Beschaffungsprozess, kein Betriebsteam, keine vorab gebundene Kapazität.

Cloud-Modelle sind außerdem sinnvoll, wenn eine Aufgabe tatsächlich die Leistung eines proprietären Spitzenmodells verlangt, etwa bei mehrstufigen Analysen über unstrukturierte Quellen. Diese Fälle sind seltener als behauptet. Ein Dokumentenassistent, der Vertragsklauseln findet, oder ein Servicebot, der Ersatzteilnummern erklärt, braucht in der Regel kein Flaggschiffmodell. Ein gut evaluiertes Open-Weights-Modell, dessen Gewichte öffentlich verfügbar sind, reicht oft aus. Entscheidend ist der Test auf Ihren Dokumenten und Ihren Aufgaben, nicht ein Benchmark aus dem Internet.

Der saubere Weg ist ein Router vor den Modellen. Er prüft Datenklasse, Risiko, erwartete Komplexität und Kostenbudget. Personaldaten oder sensible Vertragsdaten bleiben auf europäischer Infrastruktur, eine unkritische Recherche darf eine externe API nutzen. Diese Trennung ist kein Marketingversprechen, sondern ein überschaubares Stück Systemdesign mit nachvollziehbaren Regeln im Audit-Trail.

Stellen Sie diese Monatsrechnung für einen konkreten Prozess auf, mit echten Logs, Spitzenlast, Betrieb und Einführungsaufwand. Wenn Sie dafür einen zweiten Blick wollen, buchen Sie einen Potenzial-Check: eine halbe Stunde, kostenlos, und Sie gehen mit einer belastbaren Einschätzung heraus, ob Volumen und Datenklasse bei Ihnen für eigene Inferenz sprechen oder ob die API vorerst der bessere Weg bleibt.