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 vergleichen die variablen Token-Kosten eines Cloud-Modells mit den fixen Monatskosten für GPU-Kapazität, Betrieb und Einführung.

Viele Unternehmen rechnen dabei zu früh mit dem 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-Service. Umgekehrt werden Token-Rechnungen oft unterschätzt, weil ein Pilot mit 5.000 Anfragen im Monat ganz anders aussieht als ein Service, den 1.200 Mitarbeitende täglich nutzen.

Die Grundformel für eigene Inferenz Kosten

Die Rechnung beginnt mit zwei Monatswerten. Der erste Wert sind die API-Kosten für denselben Workload. Der zweite Wert 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 jeweiligen Token-Preise des Cloud-Modells pro einer Million Tokens. Auf der anderen Seite steht G für die monatliche GPU-Kapazität, B für Betrieb und Bereitschaft, E für auf den Betrachtungszeitraum verteilte Einführungsaufwände und P für Plattformkosten wie Logging, Monitoring, Routing oder Backups.

Der Ausdruck „eigene Inferenz“ bedeutet dabei nicht zwingend Hardware im eigenen Keller. Für die meisten Mittelständler ist eine dedizierte oder reservierte GPU-Umgebung in einer europäischen Cloud die vernünftigere Variante. Sie behalten Datenraum und Modellversion unter Kontrolle, ohne ein Rechenzentrum betreiben zu müssen.

Ein Rechenbeispiel aus einem internen Wissensassistenten

Nehmen wir einen Wissensassistenten für Technik, Einkauf und Service. Pro Anfrage landen durchschnittlich 1.200 Eingabe-Tokens im Modell, weil der Assistent neben der Frage passende Handbuchauszüge erhält. Die Antwort umfasst im Mittel 300 Tokens. Ein Cloud-Modell kostet in diesem Beispiel 0,80 Euro pro Million Eingabe-Tokens und 4,00 Euro pro Million Ausgabe-Tokens.

Eine Anfrage kostet damit:

(1.200 / 1.000.000 × 0,80 Euro) + (300 / 1.000.000 × 4,00 Euro)
= 0,00216 Euro

Bei 2,4 Millionen Anfragen im Monat entstehen API-Kosten von 5.184 Euro, bevor eventuelle Kosten für Suchindex, Datenaufbereitung oder Observability hinzukommen.

Für eine belastbare europäische Inferenz-Umgebung kalkuliert das Unternehmen zwei reservierte GPU-Instanzen für zusammen 2.300 Euro monatlich. Eine Instanz allein wäre auf dem Papier günstiger, aber Ausfall und Wartungsfenster wären dann ein unnötiges Betriebsrisiko. Für Monitoring, Incident-Bearbeitung, Sicherheitsupdates und Modellpflege werden 1.200 Euro pro Monat angesetzt. Die Einführung von 18.000 Euro wird über 36 Monate verteilt, also mit 500 Euro monatlich gerechnet. Routing, Audit-Logs und die Plattform schlagen mit 300 Euro zu Buche.

Die eigene Inferenz kostet damit 4.300 Euro im Monat. Der Break-even liegt bei rund 1,99 Millionen Anfragen monatlich:

4.300 Euro / 0,00216 Euro je Anfrage = 1.990.741 Anfragen

Bei 2,4 Millionen Anfragen spart das Unternehmen knapp 884 Euro pro Monat. Das ist kein spektakulärer Betrag. Der Fall wird dennoch wirtschaftlich, wenn Kundendaten oder interne Kalkulationen verarbeitet werden und das Modell reproduzierbar bleiben muss. Dann kaufen Sie nicht nur niedrigere Grenzkosten, sondern eine Architektur, die zu Ihren Risikoanforderungen passt.

Die Auslastung entscheidet stärker als der GPU-Preis

Eine reservierte GPU-Kapazität rechnet sich nur, wenn sie tatsächlich 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 30 Tage. Montags zwischen 8:30 und 10:00 Uhr, nach einer Prozessänderung oder vor einem Monatsabschluss entstehen Lastspitzen, die das System trotzdem sauber bedienen muss.

Berechnen Sie die GPU-Anzahl daher aus der Spitzenlast. Die praktische Formel lautet:

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

Die Zielauslastung sollte bei produktiven Anwendungen nicht auf 100 Prozent gesetzt werden. Bei voller Auslastung steigen Antwortzeiten, Warteschlangen wachsen und ein einzelner Fehler zieht den ganzen Dienst herunter. Für einen Assistenten, der nach drei Sekunden antworten soll, ist eine Zielauslastung von 60 bis 70 Prozent oft deutlich realistischer.

Ein Beispiel: Ihr Modell liefert nach Quantisierung, also der gezielten Reduktion der Rechengenauigkeit zur Beschleunigung, effektiv 90 Tokens pro Sekunde je GPU. In der Spitze erwarten Sie 110 Tokens pro Sekunde. Bei 65 Prozent Zielauslastung benötigen Sie rechnerisch 1,88 GPUs. In der Praxis heißt das: zwei GPUs, zuzüglich einer klaren Regel, was bei einem Ausfall passiert. Wer diese Reserve aus der Rechnung streicht, optimiert keinen Kostenblock, sondern baut eine Störung ein.

Token-Zahlen müssen aus echten Logs kommen

Schätzwerte aus einem Workshop reichen für die Entscheidung nicht. Ziehen Sie mindestens vier 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 Retrieval-Augmented-Generation-System, kurz RAG, kann durch zu viele angehängte Dokumentseiten die Eingabe-Tokens verdoppeln, ohne dass die Antwort besser wird.

In einem Maschinenbauunternehmen sahen wir genau das: Der Wissensassistent gab zu jeder Frage acht Handbuchabschnitte an das Modell. Die Hälfte davon war fachlich irrelevant. Nach einer besseren Dokumentensuche sank der Mittelwert von 2.100 auf 950 Eingabe-Tokens. Bei API-Betrieb halbierte das direkt die Kosten. Bei eigener Inferenz reduzierte es vor allem die erforderliche Kapazität und verschob den Break-even nach unten.

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

Wann der Cloud-API-Betrieb die bessere Entscheidung bleibt

Bei kleinen oder stark schwankenden Mengen bleibt ein Cloud-Modell meistens günstiger. Ein HR-Tool, das monatlich 20.000 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. Das betrifft etwa anspruchsvolle, mehrstufige Analyseaufgaben mit unstrukturierten Quellen. Diese Fälle sind in vielen Unternehmen seltener als behauptet. Ein Dokumentenassistent, der Vertragsklauseln findet, oder ein Servicebot, der Ersatzteilnummern erklärt, braucht häufig kein Flaggschiffmodell. Ein gut evaluiertes Open-Weights-Modell, dessen Modellgewichte öffentlich verfügbar sind, reicht oft aus.

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

FAQ — typische Fragen zu eigene Inferenz Kosten

Rechnet sich eigene Inferenz schon bei 100.000 Anfragen im Monat?

Meistens nicht. Bei 100.000 kurzen Anfragen monatlich sind variable Token-Kosten oft niedriger als reservierte GPU-Kapazität samt Betrieb. Eine Ausnahme entsteht, wenn die Anfragen sehr lange Kontexte enthalten oder Daten die externe Verarbeitung ausschließen. Dann ist die Entscheidung primär regulatorisch, nicht rein finanziell.

Muss das Unternehmen GPUs kaufen, um eigene Inferenz zu betreiben?

Nein. Kaufhardware bindet Kapital, verlangt Ersatzteil- und Betriebswissen und passt schlecht zu einem schnelllebigen Modellmarkt. Für viele B2B-Unternehmen ist reservierte GPU-Kapazität in einer europäischen Cloud wirtschaftlicher. Die monatliche Rate ist kalkulierbar, und die Infrastruktur kann bei geänderter Last angepasst werden.

Welche Kosten fehlen in einer reinen Token-gegen-GPU-Rechnung?

Es 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.

Sinkt der Break-even automatisch, wenn offene Modelle kleiner werden?

Nicht automatisch, aber häufig. Kleinere Modelle benötigen weniger GPU-Speicher und liefern mehr Tokens pro Sekunde. Wenn die fachliche Qualität im Test ausreicht, sinken dadurch GPU-Kosten und Kapazitätsbedarf. Entscheidend ist der Test auf Ihren Dokumenten und Ihren Aufgaben, nicht ein Benchmark aus dem Internet.

Fazit

CFOs und CTOs im Rhein-Main-Gebiet sollten für jeden KI-Workload eine Monatsrechnung auf Basis echter Logs erstellen und dabei Spitzenlast, Betrieb sowie Einführungsaufwand vollständig ansetzen. Liegt Ihr Volumen über dem Break-even oder verlangen Datenklasse und Reproduzierbarkeit eine souveräne Umgebung, planen Sie eine europäische Inferenz-Architektur statt weiterer Token-Abhängigkeit. Besprechen Sie die KI-Potenziale für Ihr Unternehmen in einem Termin, wenn Sie diese Rechnung für konkrete Prozesse belastbar aufsetzen wollen.