Was kostet ein eigenes Sprachmodell wirklich? API vs. Eigenbetrieb
„Wir wollen unser eigenes Sprachmodell betreiben“ – diesen Satz höre ich oft. Dahinter stecken meist zwei Fragen: Ist das günstiger als eine API? Und behalten wir damit die Kontrolle über unsere Daten? Die erste lässt sich rechnen, die zweite ist oft wichtiger.
Inhalt
Das Wichtigste in Kürze
- Bei kleinen und mittleren Volumina ist eine API fast immer günstiger. Eigenbetrieb hat hohe Fixkosten, die erst bei dauerhaft hoher Last aufgehen.
- Wo der Break-even liegt, hängt vor allem an Tokens pro Anfrage, API-Preis und Auslastung – nicht an der Zahl der Nutzer.
- Der stärkste Grund für Eigenbetrieb ist selten der Preis, sondern Kontrolle: über Daten, Verfügbarkeit und Modellversionen.
- Ein Gateway macht die Entscheidung umkehrbar: vertrauliche Anfragen lokal, alles andere per API – je Anfrage geregelt.
Die falsche Frage: „Was kostet ein Modell?“
Ein Sprachmodell hat keinen festen Preis. Was Sie bezahlen, ist Rechenleistung für Text – gemessen in Tokens. Ein Token ist ein Wortbestandteil; ein deutsches Wort entspricht häufig ein bis zwei Tokens. Jede Anfrage besteht aus Eingabe-Tokens (Ihre Frage, Anweisungen, mitgeschickte Dokumente) und Ausgabe-Tokens (die Antwort).
Damit verschiebt sich die Frage. Nicht „Was kostet das Modell?“, sondern: Wie viele Tokens verarbeiten Sie pro Monat – und wie gleichmäßig? Bei einer API zahlen Sie genau diese Menge. Beim Eigenbetrieb zahlen Sie für Kapazität, egal ob sie genutzt wird oder nicht.
Diese zwei Kostenstrukturen – verbrauchsabhängig gegen fix – sind der Kern jeder Entscheidung. Alles andere sind Details, die den Schnittpunkt verschieben.
Wie sich API-Kosten zusammensetzen
API-Anbieter rechnen pro Million Tokens ab, meist getrennt nach Eingabe und Ausgabe. Ausgabe-Tokens sind in der Regel deutlich teurer, weil das Modell sie einzeln erzeugen muss. Für eine erste Kalkulation genügt ein Mischpreis, der das typische Verhältnis Ihrer Anwendung abbildet.
Unterschätzt werden fast immer die Eingabe-Tokens. Typische Treiber:
- Systemanweisungen, die bei jeder Anfrage mitgeschickt werden – schnell einige Hundert Tokens.
- Mitgelieferter Kontext bei Wissensassistenten (RAG): fünf Textabschnitte à 400 Tokens sind 2.000 Tokens, bevor überhaupt gefragt wurde.
- Gesprächsverlauf in Chats, der mit jeder Runde wächst.
- Mehrstufige Abläufe wie Agenten, die ein Modell pro Aufgabe mehrfach aufrufen.
Dazu kommen Nebenkosten, die in keiner Preisliste stehen: Wiederholungen bei Fehlern, Testläufe für die Qualitätssicherung und Embeddings für die Suche. Sie sind meist klein, aber nicht null.
Was Eigenbetrieb wirklich kostet
„Eigenbetrieb“ heißt in der Praxis selten, Hardware zu kaufen. Realistischer ist ein gemieteter GPU-Server in einem europäischen Rechenzentrum oder ein Server in Ihrem eigenen. Darauf läuft ein offenes Modell mit einem Inferenz-Server – etwa vLLM für hohen Durchsatz oder Ollama für einfache, kleinere Setups.
Die Kosten bestehen aus drei Blöcken:
- Infrastruktur: Servermiete, abhängig von GPU-Typ und Speicher. Sie fällt jeden Monat an – auch nachts und am Wochenende, wenn kaum jemand fragt.
- Betrieb: Updates, Monitoring, Sicherheits-Patches, Modellwechsel, Bereitschaft bei Störungen. Dieser Posten wird am häufigsten vergessen.
- Einrichtung: einmalig – Auswahl und Test des Modells, Deployment, Anbindung, Lasttests.
Entscheidend ist die Kapazität. Ein Server verarbeitet nur eine bestimmte Menge Tokens pro Sekunde. Weil Anfragen nicht gleichmäßig über den Tag verteilt sind, müssen Sie für Lastspitzen planen, nicht für den Durchschnitt. Reicht ein Server nicht mehr, kommt der nächste hinzu – die Kosten steigen in Stufen.
Die Beispielrechnung
Der folgende Rechner bildet beide Kostenstrukturen ab. Die Annahmen sind bewusst vorsichtig gewählt und stehen offen in der Tabelle darunter. Verschieben Sie die Regler – oder klicken Sie direkt ins Diagramm.
Bei 50 Tsd. Anfragen ist die API um 2.300 € pro Monat günstiger.
Anfragen pro Monat (logarithmische Skala)
Annahmen dieser Beispielrechnung
| GPU-Server (Miete) | 1.800 € / Monat | 1 Server mit einer 80-GB-GPU, EU-Rechenzentrum, Strom inklusive |
|---|---|---|
| Betrieb & Wartung | 800 € / Monat | Updates, Monitoring, Bereitschaft – anteilig, unabhängig von der Serverzahl |
| Kapazität je Server | ca. 1,5 Mrd. Tokens / Monat | offenes Modell bis ca. 30 Mrd. Parameter mit vLLM, mittlere Auslastung inkl. Lastspitzen |
| API-Mischpreis | einstellbar | Durchschnitt aus Eingabe- und Ausgabe-Tokens; 3 € entspricht grob einem Modell der Mittelklasse |
| Nicht enthalten | – | einmalige Einrichtung, Anwendungsentwicklung, Qualitätsunterschiede zwischen Modellen |
Ein Rechenbeispiel in Worten
Nehmen wir einen internen Wissensassistenten für 300 Mitarbeitende an. Jede Person stellt an einem Arbeitstag im Schnitt zehn Fragen, das sind bei 21 Arbeitstagen rund 63.000 Anfragen im Monat. Mit mitgeliefertem Kontext kommen pro Anfrage etwa 3.000 Tokens zusammen – insgesamt also knapp 190 Millionen Tokens.
Bei einem Mischpreis von 3 € je Million Tokens kostet das per API rund 570 € im Monat. Der eigene GPU-Server liegt mit den Annahmen oben bei 2.600 € – und wäre dabei nur zu einem Bruchteil ausgelastet. Rein finanziell ist die Sache hier eindeutig. Erst wenn derselbe Server zusätzlich Dokumente klassifiziert, E-Mails vorsortiert und weitere Anwendungen bedient, verschiebt sich das Bild.
Drei Beobachtungen, die unabhängig von den genauen Preisen gelten:
- Unterhalb des Break-even ist die API klar im Vorteil. Mit den Standardannahmen liegt er bei mehreren Hunderttausend Anfragen pro Monat. Viele interne Anwendungen im Mittelstand bleiben deutlich darunter.
- Tokens pro Anfrage verschieben den Schnittpunkt stark. Ein Wissensassistent mit viel Kontext erreicht den Break-even bei weit weniger Anfragen als ein einfacher Klassifizierer.
- Bei sehr günstigen API-Modellen gibt es keinen Break-even. Liegt der API-Preis unter den Grenzkosten eines eigenen Servers, lohnt sich Eigenbetrieb rein finanziell nie – dann zählen nur noch andere Gründe.
Kosten sind selten das entscheidende Argument
In den Gesprächen, die ich führe, ist der Preis fast nie der eigentliche Auslöser. Die wichtigeren Gründe für Eigenbetrieb oder europäische Anbieter sind:
- Vertraulichkeit: Konstruktionsdaten, Verträge, Personaldaten oder Gesundheitsdaten sollen das Haus nicht verlassen – unabhängig davon, was ein Vertrag zusichert.
- Rechtliche Klarheit: Verarbeitung in der EU vereinfacht die Bewertung nach DSGVO und die Abstimmung mit Datenschutz und Betriebsrat.
- Stabilität: Ein selbst betriebenes Modell ändert sich nur, wenn Sie es ändern. Bei APIs werden Modellversionen regelmäßig abgekündigt.
- Unabhängigkeit: Preise, Nutzungsbedingungen und Verfügbarkeit liegen bei Ihnen, nicht bei einem einzelnen Anbieter.
Dem stehen echte Nachteile gegenüber: Sie tragen die Verantwortung für Betrieb und Sicherheit, und die stärksten Modelle sind teils nur per API verfügbar. Deshalb ist die Antwort selten „entweder – oder“.
Welche Modelle für den Eigenbetrieb infrage kommen
Offene Modelle mit frei verfügbaren Gewichten haben in den letzten Jahren stark aufgeholt. Für den Eigenbetrieb gibt es heute Modellfamilien in vielen Größen – von kompakten Modellen, die auf einer einzelnen GPU schnell laufen, bis zu sehr großen Modellen, die mehrere GPUs benötigen. Eine grobe Orientierung:
- Kleine Modelle eignen sich gut für klar umrissene Aufgaben: Klassifizieren, Informationen aus Dokumenten extrahieren, kurze Zusammenfassungen.
- Mittlere Modelle tragen die meisten Assistenz- und Wissensanwendungen, wenn der Kontext gut aufbereitet ist.
- Sehr große Modelle lohnen sich im Eigenbetrieb selten; hier ist der Abstand zu API-Angeboten bei Kosten und Aufwand am größten.
Zwei Punkte werden oft übersehen: Erstens unterscheiden sich die Lizenzen offener Modelle teils erheblich – manche schränken die kommerzielle Nutzung ein. Zweitens reduziert Quantisierung den Speicherbedarf deutlich, kann aber die Qualität beeinflussen. Beides gehört in die Testphase, nicht in die Annahmen.
Der pragmatische Weg: hybrid mit Gateway
Statt sich früh festzulegen, binden Sie alle Anwendungen an ein Gateway an – zum BeispielLiteLLM. Es bietet eine einheitliche Schnittstelle für lokale Modelle und verschiedene API-Anbieter. Regeln entscheiden je Anfrage, wohin sie geht.
Das hat mehrere Vorteile:
- Vertrauliche Inhalte werden per Regel an das lokale Modell geleitet – unabhängig davon, welche Anwendung fragt.
- Kosten werden sichtbar: Das Gateway protokolliert Tokens je Anwendung und Abteilung und kann Budgets durchsetzen.
- Ausfallsicherheit: Fällt ein Anbieter aus, übernimmt automatisch ein anderes Modell.
- Umkehrbarkeit: Sie können mit einer API starten und später einzelne Anwendungen auf eigene Infrastruktur verlagern, ohne Code anzufassen.
Checkliste für Ihre Entscheidung
- Datenklassen festlegen: Welche Inhalte dürfen zu welchem Anbieter? Das ist die Grundlage aller Routing-Regeln.
- Volumen schätzen: Anfragen pro Monat und Tokens pro Anfrage – lieber aus einem Pilot als aus Annahmen.
- Lastprofil verstehen: Gleichmäßige Last spricht für Eigenbetrieb, stark schwankende eher für eine API.
- Qualität prüfen: Testfälle aus Ihrem Alltag gegen mehrere Modelle laufen lassen, bevor Sie Kosten vergleichen.
- Betrieb klären: Wer aktualisiert, überwacht und reagiert auf Störungen? Ohne Antwort ist Eigenbetrieb keine Option.
- Umkehrbar bauen: Gateway von Anfang an – dann ist keine Entscheidung endgültig.
Ein eigenes Sprachmodell ist kein Prestigeprojekt, sondern eine Betriebsentscheidung. Wer sie mit echten Nutzungsdaten trifft und die Architektur offen hält, liegt selten falsch – egal, in welche Richtung es am Ende geht.