Ab welchem Token-Volumen wird Self-Hosting günstiger als eine API?

Das hängt von der Auslastung ab, es gibt also keine einzige Zahl. Grob gesagt kann Self-Hosting Premium-APIs schon bei einigen Millionen Token pro Monat auf einer gut ausgelasteten GPU schlagen, aber günstige Budget-APIs zu unterbieten erfordert zig bis hunderte Millionen pro Monat. Ein gängiger Faustregel-Richtwert liegt bei einigen Millionen Token pro Tag, dauerhaft aufrechterhalten – darunter gewinnt meist eine API.

Was kostet der Betrieb einer H100 pro Monat?

Eine H100 auf Abruf kostet auf spezialisierten GPU-Clouds rund 1,50–3,00 $/Stunde (auf Hyperscalern mehr), sodass eine dedizierte 24/7-Instanz je nach Anbieter-Tier etwa 1.000–5.000 $ pro Monat kostet. Diese Fixkosten sind das, was das Token-Volumen decken muss, damit sich Self-Hosting rechnet.

Warum entscheidet die GPU-Auslastung über die Wirtschaftlichkeit des Self-Hostings?

Weil die GPU gleich viel kostet, ob sie beschäftigt oder im Leerlauf ist. Gut ausgelastet können die Kosten pro Million Token unter einen Dollar sinken; bei niedriger Last (etwa 10 %) steigen die realen Kosten pro Token um etwa das Zehnfache, was Self-Hosting oft teurer macht als eine Premium-API. Eine ungenutzte GPU ist pure Verschwendung – die Auslastung ist die mit Abstand wichtigste Variable.

Ist Self-Hosting günstiger als eine Budget-API wie ein gehostetes kleines Modell?

In der Regel nur bei sehr hohem Volumen. Budget-APIs sind aggressiv bepreist, daher erfordert es, sie per Self-Hosting zu unterbieten, typischerweise zig bis hunderte Millionen Token pro Monat bei guter Auslastung. Gegenüber Premium-APIs kommt der Schnittpunkt viel früher. Vergleichen Sie mit der konkreten API, die Sie sonst verwenden würden, nicht mit einem generischen Tarif.

Wie stark senkt Quantisierung die Self-Hosting-Kosten?

Erheblich. FP8 verdoppelt den Durchsatz bei minimalem Qualitätsverlust grob, und INT4 kann ihn grob verdreifachen und dabei das Modell so verkleinern, dass es auf eine kleinere, günstigere GPU passt. Bei einem großen Modell kann das die Kosten pro Million Token um die Hälfte oder mehr senken – Quantisierung ist einer der wirkungsstärksten Kostenhebel beim Self-Hosting.

Welche versteckten Kosten entstehen beim Selbst-Hosten eines LLMs?

Der Betrieb. Über die GPU-Rechnung hinaus zahlt man für MLOps-Engineering (ein sechsstelliges Gehalt), Modell-Update-Zyklen (jeweils Wochen Arbeit) sowie den Inferenz-Server, die Treiberverwaltung, Autoscaling und Monitoring. Diese Posten schlagen routinemäßig mit einem Mehrfachen der reinen Hardwarekosten zu Buche und sind genau das, was die meisten naiven Break-even-Rechnungen weglassen.

Kann ich Self-Hosting und APIs kombinieren, um Kosten zu optimieren?

Ja – hybrid ist meist der klügste Ansatz. Führen Sie hohes, gleichmäßiges Volumen auf lokaler oder eigener Inferenz aus, mittlere, vorhersehbare Workloads auf einem dedizierten Endpunkt und unregelmäßigen oder niedrigen Traffic (sowie alles, was Frontier-Qualität erfordert) auf einer Pay-per-Token-API. Routing nach Wirtschaftlichkeit nimmt die Einsparungen des Self-Hostings mit, ohne für ungenutzte GPUs bei stoßartiger Arbeit zu zahlen.

← Resources

By Jordan Malik — Staff Engineer, Inference · 2026-06-02 · GUIDE

Wann das eigene Hosting von LLMs wirklich günstiger ist als eine API

Ein LLM selbst zu hosten ist nur oberhalb eines Token-Volumens günstiger als eine API, und dieses Volumen hängt vollständig von der GPU-Auslastung ab: Es gibt keine einzige Break-even-Zahl. Dieser Leitfaden zeigt die echte Rechnung, warum Batching und Quantisierung entscheiden, die versteckten Betriebskosten und warum ein Hybridansatz meist die richtige Antwort ist.

Es gibt keine einzige Break-even-Zahl

Die ehrliche Antwort auf die Frage «Wann ist Self-Hosting günstiger?» ist eine Spanne, die von der Auslastung abhängt, keine Zahl. Deshalb gehen veröffentlichte Schätzungen um Größenordnungen auseinander: Sie setzen unterschiedliche GPU-Preise, Auslastungsgrade und Vergleichs-APIs voraus.

Die nützliche Faustregel: Self-Hosting schlägt Premium-APIs tendenziell schon bei einem relativ bescheidenen, gleichmäßigen Volumen (einige Millionen Token pro Monat auf einer gut ausgelasteten GPU), aber günstige Budget-APIs zu unterbieten erfordert deutlich mehr (zig bis hunderte Millionen pro Monat). Ein grober Richtwert liegt bei einigen Millionen Token pro Tag, dauerhaft aufrechterhalten. Darunter gewinnt fast immer eine API.

Die GPU-Rechnung

Self-Hosting bedeutet, eine GPU zu mieten oder zu besitzen, und diese Fixkosten sind das, was Ihr Token-Volumen «füllen» muss. Eine H100 auf Abruf kostet auf spezialisierten Clouds rund 1,50–3,00 $/Stunde (auf Hyperscalern mehr), sodass eine dedizierte 24/7-H100 je nach Anbieter-Tier in der Größenordnung von 1.000–5.000 $ pro Monat liegt.

Diese monatliche Fixrate fällt an, ob Sie die GPU nutzen oder nicht – deshalb sind die Kosten pro Million Token nur bei hoher Auslastung günstig. Gut ausgelastet kann ein mittelgroßes Modell deutlich unter einen Dollar pro Million Token kommen; bei 10 % Last steigen die realen Kosten pro Token etwa um das Zehnfache – genug, um Self-Hosting teurer zu machen als eine Premium-API. Eine ungenutzte GPU ist der schnellste Weg, das Kostenargument zu verlieren.

Batching und Quantisierung entscheiden

Zwei Stellschrauben bewegen den Break-even stärker als alles andere. Kontinuierliches Batching (dank moderner Inferenz-Server) ist der wirtschaftliche Motor: Viele Anfragen gleichzeitig auf derselben GPU zu bedienen kann die Kosten pro Token drastisch senken; der Wechsel von einer Anfrage pro Mal zu großen Batches kann den Durchsatz um Größenordnungen verbessern. Ungleichmäßiger Traffic mit geringer Parallelität füllt die Batches nicht aus und läuft um ein Mehrfaches schlechter als im Spitzenbetrieb, weshalb sich stoßartige Workloads schlecht selbst hosten lassen.

[Quantisierung](/articles/llm-quantization-explained-gguf) ist die andere Stellschraube: FP8 verdoppelt den Durchsatz bei minimalem Qualitätsverlust grob, und INT4 kann ihn grob verdreifachen und dabei das Modell so verkleinern, dass es auf eine kleinere, günstigere GPU passt. Zusammen können Batching und Quantisierung die Kosten pro Token um ein Mehrfaches verschieben.

Die versteckten Kosten: der Betrieb

Die GPU-Rechnung ist nicht die ganze Rechnung. Der Betrieb schlägt routinemäßig mit einem Mehrfachen der reinen Hardwarekosten zu Buche: Ein MLOps-Ingenieur bedeutet ein sechsstelliges Gehalt, und jeder Modell-Update-Zyklus – Neu-Quantisierung, Tests, erneutes Deployment – sind Wochen Arbeit. «Kostenlose» Open-Weight-Modelle können Hunderttausende Dollar pro Jahr an Engineering-Aufwand verbergen, sobald man Inferenz-Server, Treiber- und CUDA-Verwaltung, Autoscaling und Monitoring einrechnet.

Das ist der Posten, der die naive Self-Hosting-Rechnung zum Scheitern bringt. Die Kosten pro Token laut Datenblatt setzen voraus, dass die GPU sich selbst betreibt; in Wirklichkeit muss jemand sie am Laufen halten, und diese Person gibt es nicht umsonst.

Wann die API klar gewinnt (und die nicht-kostenbezogenen Faktoren)

Eine API ist die richtige Wahl bei niedrigem oder unregelmäßigem Volumen, unvorhersehbarem Traffic, Teams ohne internes MLOps-Know-how und jedem Bedarf an Modellen mit Frontier-Qualität, die man nicht selbst betreiben kann. Einer Schätzung zufolge ist eine API für die große Mehrheit der Anwendungsfälle die bessere Wahl, und die API-Preise fallen weiter, was den Self-Hosting-Break-even im Laufe der Zeit immer weiter nach oben verschiebt.

Zwei Faktoren liegen vollständig außerhalb der Kostenrechnung: Latenz und Datenschutz. Self-Hosting gewinnt bei Datenresidenz, regulierten Workloads und vorhersehbarer In-Region-Latenz, unabhängig von der Token-Ökonomie; siehe unseren [Leitfaden zu On-Premise](/articles/on-premise-ai-for-enterprise). Diese Faktoren können Self-Hosting selbst dann rechtfertigen, wenn die reine Kostenrechnung es nicht tut.

Routing nach Wirtschaftlichkeit mit osFoundry

Die pragmatische Antwort ist hybrid: nach wirtschaftlichen Kriterien routen, nicht nach Ideologie. Hohes, gleichmäßiges Volumen gehört auf lokale oder eigene Inferenz, wo das Füllen der GPU-Batches die Kosten pro Token senkt. Mittlere, vorhersehbare Workloads passen auf einen dedizierten GPU-Endpunkt: auslastungsfreundlicher Durchsatz, ohne Hardware zu besitzen oder den vollen Betriebsmultiplikator zu tragen. Unregelmäßiger, niedriger oder unvorhersehbarer Traffic sowie alles, was Frontier-Qualität erfordert, bleibt auf Pay-per-Token-BYOK-APIs.

osFoundry übernimmt automatisch die Stellschrauben, die den Break-even wirklich bewegen – Quantisierung, Batching und Tier-Routing – und ermöglicht es, denselben Workload lokal, auf einem dedizierten Endpunkt oder über eine BYOK-API auszuführen. So nehmen Sie die Einsparungen dort mit, wo Self-Hosting gewinnt, ohne selbst CUDA, Autoscaling oder die Auslastungsrechnung zu verwalten. (Unsere [BYOK-Kostenaufschlüsselung](/articles/byok-vs-managed-ai-cost-breakdown) behandelt die API-Seite der Gleichung.)

Frequently asked questions

Ab welchem Token-Volumen wird Self-Hosting günstiger als eine API?: Das hängt von der Auslastung ab, es gibt also keine einzige Zahl. Grob gesagt kann Self-Hosting Premium-APIs schon bei einigen Millionen Token pro Monat auf einer gut ausgelasteten GPU schlagen, aber günstige Budget-APIs zu unterbieten erfordert zig bis hunderte Millionen pro Monat. Ein gängiger Faustregel-Richtwert liegt bei einigen Millionen Token pro Tag, dauerhaft aufrechterhalten – darunter gewinnt meist eine API.
Was kostet der Betrieb einer H100 pro Monat?: Eine H100 auf Abruf kostet auf spezialisierten GPU-Clouds rund 1,50–3,00 $/Stunde (auf Hyperscalern mehr), sodass eine dedizierte 24/7-Instanz je nach Anbieter-Tier etwa 1.000–5.000 $ pro Monat kostet. Diese Fixkosten sind das, was das Token-Volumen decken muss, damit sich Self-Hosting rechnet.
Warum entscheidet die GPU-Auslastung über die Wirtschaftlichkeit des Self-Hostings?: Weil die GPU gleich viel kostet, ob sie beschäftigt oder im Leerlauf ist. Gut ausgelastet können die Kosten pro Million Token unter einen Dollar sinken; bei niedriger Last (etwa 10 %) steigen die realen Kosten pro Token um etwa das Zehnfache, was Self-Hosting oft teurer macht als eine Premium-API. Eine ungenutzte GPU ist pure Verschwendung – die Auslastung ist die mit Abstand wichtigste Variable.
Ist Self-Hosting günstiger als eine Budget-API wie ein gehostetes kleines Modell?: In der Regel nur bei sehr hohem Volumen. Budget-APIs sind aggressiv bepreist, daher erfordert es, sie per Self-Hosting zu unterbieten, typischerweise zig bis hunderte Millionen Token pro Monat bei guter Auslastung. Gegenüber Premium-APIs kommt der Schnittpunkt viel früher. Vergleichen Sie mit der konkreten API, die Sie sonst verwenden würden, nicht mit einem generischen Tarif.
Wie stark senkt Quantisierung die Self-Hosting-Kosten?: Erheblich. FP8 verdoppelt den Durchsatz bei minimalem Qualitätsverlust grob, und INT4 kann ihn grob verdreifachen und dabei das Modell so verkleinern, dass es auf eine kleinere, günstigere GPU passt. Bei einem großen Modell kann das die Kosten pro Million Token um die Hälfte oder mehr senken – Quantisierung ist einer der wirkungsstärksten Kostenhebel beim Self-Hosting.
Welche versteckten Kosten entstehen beim Selbst-Hosten eines LLMs?: Der Betrieb. Über die GPU-Rechnung hinaus zahlt man für MLOps-Engineering (ein sechsstelliges Gehalt), Modell-Update-Zyklen (jeweils Wochen Arbeit) sowie den Inferenz-Server, die Treiberverwaltung, Autoscaling und Monitoring. Diese Posten schlagen routinemäßig mit einem Mehrfachen der reinen Hardwarekosten zu Buche und sind genau das, was die meisten naiven Break-even-Rechnungen weglassen.
Kann ich Self-Hosting und APIs kombinieren, um Kosten zu optimieren?: Ja – hybrid ist meist der klügste Ansatz. Führen Sie hohes, gleichmäßiges Volumen auf lokaler oder eigener Inferenz aus, mittlere, vorhersehbare Workloads auf einem dedizierten Endpunkt und unregelmäßigen oder niedrigen Traffic (sowie alles, was Frontier-Qualität erfordert) auf einer Pay-per-Token-API. Routing nach Wirtschaftlichkeit nimmt die Einsparungen des Self-Hostings mit, ohne für ungenutzte GPUs bei stoßartiger Arbeit zu zahlen.