Dauerlast- vs. Burst-Inferenz im Kostenvergleich: Wann On-Prem gewinnt und wann die Cloud rettet

Ein Inferenz-Server mit vier GPUs verbraucht denselben Strom, belegt denselben Platz im Rack und wird nach demselben Plan abgeschrieben – ganz gleich, ob er täglich zwanzig Millionen oder zwanzigtausend Token ausliefert. Die Karten wissen nicht, dass sie im Leerlauf sind. Die Buchhaltung schon. Genau diese Asymmetrie – Fixkosten auf der On-Premises-Seite, Grenzkosten auf der Cloud-Seite – ist der ganze Grund dafür, dass die richtige Antwort auf die Frage „Sollen wir on-prem gehen?“ ebenso sehr von der Form Ihres Traffics abhängt wie von dessen Volumen.

T01 hat die Rechnung pro Karte an einem einzigen Auslastungspunkt durchgespielt. T02 stellt die Kosten pro Million Token bei Volllast den Cloud-APIs gegenüber. Dieser Artikel (T03) ist der, den Ihr CFO wirklich lesen sollte: Was passiert mit diesen Zahlen, wenn der Traffic stoßweise auftritt, wenn er dauerhaft anliegt – und wie baut man ein System, das auf keiner der beiden Seiten Geld verbrennt?

Die Zielgruppe sind alle, die bereits zu dem Schluss gekommen sind, dass der Workload on-prem passen könnte, und nun entscheiden müssen, wie viel davon on-prem laufen soll – und was den Rest auffängt.

Die Fixkostenfalle

Cloud-Inferenz skaliert die Kosten mit der Nutzung. Ein einzelner Llama-70B-Aufruf bei einem OpenRouter-Anbieter kostet Sie rund €0.50–€2.00 pro Million Token (je nach Tarifstufe und Anbieter). Kein Traffic, keine Kosten. 10× so viel Traffic, 10× so hohe Kosten. Der Zusammenhang ist linear und beginnt bei null.

On-Premises-Inferenz funktioniert genau umgekehrt. Eine Box mit 4× RTX Pro 6000 Blackwell (T01 beziffert die 3-Jahres-TCO auf rund €58k all-in – amortisierte Capex, Strom, Chassis-Anteil, Wartung) kostet diese €58k, ob sie eine Million Token ausliefert oder eine Billion. Die Grenzkosten des 200-millionsten Token in einem Monat entsprechen exakt denen des zweiten: die kWh Strom, die seine Berechnung gekostet hat, und sonst nichts. Die Capex sind versunkene Kosten, sobald die Box geliefert ist.

Die buchhalterische Konsequenz ist brutal und wird von Käufern selten verinnerlicht:

(Gleiche Hardware, gleiche TCO von €14.4k pro Karte über drei Jahre; nur der Nenner ändert sich.)

Der Cloud-Preis für Llama 70B FP8 liegt 2026 je nach Anbieterstufe im Band €0.50–€1.50/Mtok. Lesen Sie die Tabelle mit dieser Zahl im Hinterkopf noch einmal. Bei 5% Dauerauslastung ist die On-Premises-Box teurer als jede Cloud-Option, die es gibt. Bei 30% zieht sie mit den teuersten Anbietern gleich. Ab 60% gewinnt sie die Rechnung klar.

Die Falle: Kunden stellen die Capex der aktuellen Last gegenüber und stellen sechs Monate später fest, dass diese aktuelle Last 8% der Box ausgemacht hat. Die Hardware hat nichts falsch gemacht. Die Dimensionierung schon.

Wie die Auslastung im Produktivbetrieb wirklich aussieht

Uns liegen öffentliche Daten sowie eigene Messungen aus den Kentino AI Installationen vor, die wir betreiben oder besuchen – und das Bild ist 2026 branchenweit konsistent:

Die Kernzahlen aus Produktivinstallationen und Betreiberbefragungen: Die meisten Teams, die ihre eigene Inferenz betreiben, melden 20–40% durchschnittliche GPU-Auslastung, wobei ausgereifte Setups in Richtung 40–65%kriechen. Alles dauerhaft über 65% ist entweder reine Batch-Arbeit oder ein Cluster, der so heiß läuft, dass die nächste Traffic-Spitze in der Queue landet. Unter 20% heißt: Die Box läuft vor allem, um sich selbst zu finanzieren, nicht, um Nutzer zu bedienen.

Die Zahl, die Käufer immer überrascht: Ein interaktiver Workload – ein Chatbot, ein Coding-Assistent, ein Kundensupport-Bot – hält so gut wie nie mehr als 30% dauerhaft. Der Grund ist das Tageslicht. Selbst ein globales Produkt hat Randzeiten; ein regionales Produkt hat jeden Tag 14 Stunden geringer Last. Die Rechnung bestraft das hart.

Dauerlast-Workloads – das Brot-und-Butter-Geschäft

Die On-Premises-Ökonomie geht sauber auf, wenn Sie die GPUs den größten Teil des Tages beschäftigt halten können. Grob nach Häufigkeit, in der wir sie auf Kentino AI Installationen sehen:

• Coding-Assistent / IDE-Backend für ein Team ab 30 Entwicklern. Gleichmäßige Werktagslast 09:00–18:00, leichtere Abende, am Wochenende nahezu null. Im Wochenmittel 20–30%, mit Spitzen von 60–80% während der Arbeitszeit.
• Kundensupport- / Vertriebs-Chatbot mit Traffic rund um die Uhr. Der Tagesrhythmus folgt der bedienten Region; globale Produkte landen bei 25–35% Dauerauslastung, regionale bei 15–25%.
• RAG- / Semantiksuche-Backend das eine interne Wissensdatenbank indexiert und ausliefert. Die Abfragerate ist mäßig gleichmäßig; die Neuindexierung ist ein geplanter Nachtjob, der die Box auf 95% treibt. Kombinierte Auslastung 30–50%.
• Batch-Verarbeitung – nächtliche Zusammenfassung der Dokumente des Vortags, wöchentliche Autolabeling-Läufe, monatliche Klassifizierungsläufe über einen Korpus. Reine Queue-Arbeit, 70–90% Auslastung, solange die Queue nicht leer ist, ausgelegt auf vollständigen Durchlauf.
• Inferenz für Roboterflotten – mehrere Einheiten greifen während der Betriebszeiten auf denselben VLM-Endpunkt zu und stehen außerhalb still (I01, I06).

Das Muster: Dauerlast-Workloads decken entweder genug Zeitzonen ab, um den Tag zu füllen, oder haben Batch-Anteile, die die Lücken bewusst schließen. Das Schließen dieser Lücken ist der größte TCO-Hebel, den ein Kunde ziehen kann – und der am häufigsten übersehene. Eine Box, die 12 Stunden am Tag interaktiven Chat bei 30% bedient und nachts Autolabeling bei 90% fährt, liegt im Mittel bei rund 60% – doppelte effektive Auslastung, halbe Kosten pro Token.

Burst-Workloads – wo On-Premises wehtut

Die Gegenform ist ein Workload, der für ein kurzes Fenster enorme Kapazität braucht und die restliche Zeit fast nichts. Beispiele, die uns regelmäßig begegnen:

• Marketingkampagne / Content-Produktionsschub. Varianten für eine Werbekampagne in N Märkten innerhalb von 48 Stunden erzeugen – danach einen Monat lang nichts.
• Virale Momente. Eine Consumer-App startet ein Feature, wird in einem Tech-Newsletter erwähnt, der Traffic liegt sechs Stunden lang 50× über Normal und ist am nächsten Morgen zurück auf Basisniveau.
• Demo- und Pilotveranstaltungen. Ein Messestand, der drei Tage lang Live-Inferenz-Demos fährt – danach wieder null.
• Periodische Batch-Jobs mit festem Zeitfenster. Ein monatlicher Compliance-Scan über einen gesamten Dokumentenkorpus, der bis zu einer regulatorischen Frist abgeschlossen sein muss.
• Analysen zu Wahlabenden oder Live-Events – ein Fenster von 12–48 Stunden, in dem das Volumen 100× über Normal liegt.

Rechenbeispiel. Ein Workload benötigt 10 Millionen generierte Token. Über 24 Stunden verteilt sind das aggregiert rund 116 Tok/s – eine einzelne L4 schafft das. In ein Ein-Stunden-Fenster gepresst sind es 2,778 Tok/s – dafür braucht es eine 4-GPU-Box mit Pro 6000 unter Volllast oder rund sechs L4.

Dieselben 10 Millionen Token verlangen also entweder eine Karte rund um die Uhr oder sechs Karten für eine Stunde. Bei Burst-Workloads steht die On-Premises-Kapazität 23 von 24 Stunden still. Die TCO-Rechnung bricht zusammen: Diese Sechs-Karten-Box kostet bei 4% Auslastung im Maßstab der obigen Tabelle €13–25/Mtok. Ein Cloud-Burst zu €1.50/Mtok bedient dieselbe Last für insgesamt €15. Der Break-even ist nicht einmal in Sichtweite.

Die unausweichliche Schlussfolgerung: Die On-Premises-Dimensionierung auf die Spitzenlast auszulegen ist der häufigste Fehlkauf, den wir sehen. Kunden wollen, dass die Box den Worst Case am Dienstagnachmittag abdeckt, und kaufen deshalb 4× so viele GPUs, wie sie in einer normalen Woche brauchen. Die Rechnung kommt in Form von Capex, die sich nicht zurückholen lässt, und einer zu 90% ungenutzten Flotte.

Das Hybrid-Muster

Die ehrliche Architektur für einen echten Produktiv-Workload mit beiden Lastformen lautet: On-Premises-Grundlast plus Cloud-Überlauf für die Spitzen.

Hybrid-Routing: zuerst on-prem, Cloud-Überlauf nur, wenn die Queue-Tiefe den konfigurierten Schwellwert überschreitet.

Die richtige Routing-Logik lautet nicht „Schicke X% in die Cloud, den Rest on-prem.“ Sie lautet zuerst on-prem, Cloud nur, wenn on-prem an der Kapazitätsgrenze ist. Das Signal ist die Queue-Tiefe oder die KV-Cache-Auslastung auf vLLM-Seite (K03 behandelt die Metriken), kein statischer Split.

Konkretes Rezept mit vLLM:

1. Stellen Sie dem On-Premises-Cluster einen Router voran, der /v1/chat/completionsbereitstellt. NGINX, HAProxy, der vLLM Router oder ein kleines eigenes Gateway funktionieren alle.
2. Exponieren Sie vllm:num_requests_waiting als Messgröße für die Queue-Tiefe. Schwellwert etwa bei 8–16 Wartenden pro Replica, bevor der Fallback greift.
3. Routen Sie beim Überlauf auf einen Cloud-Endpunkt mit demselben Modellnamen. OpenRouter, Together und Fireworks liefern alle Modelle der Llama-Klasse. Legen Sie einen als primär und einen als Backup fest, damit Sie nicht mit einem einzelnen Anbieter ausfallen.
4. Markieren Sie Überlauf-Anfragen in Ihrer Observability, damit Sie täglich sehen, welchen Anteil Sie extern bezahlen. Liegt er an den meisten Tagen über 15%, ist Ihre On-Premises-Kapazität zu klein; liegt er wochenlang unter 1%, ist sie zu groß.

Die ökonomische Logik: Capex einmal für die Last zahlen, die immer anliegt, und variable Cloud-Preise für die Spitzen. Gut umgesetzt bringt das die effektive Auslastung der On-Premises-Box auf 50–70% (der Routing-Schwellwert ist die Stellschraube), während die Zusagen zur Tail-Latenz auch während der Bursts eingehalten werden.

Cold Start: die Realität des Autoscalings

Die naive Cloud-Antwort auf stoßweise Last lautet „skaliere den On-Premises-Cluster automatisch“ – im Leerlauf null Replicas, bei Bedarf hochfahren. Für LLM-Serving scheitert das aus einem Grund gründlich: der Ladezeit des Modells.

Llama 70B FP8 (~75 GB Gewichte) von einer Gen5-NVMe zu laden, dauert bei theoretischen Leseraten von 12–14 GB/s 30–60 Sekunden reine I/O-Zeit . Rechnen Sie CUDA-Kernel-Kompilierung, das Aufwärmen des vLLM-Schedulers und die Vorbelegung des KV-Cache hinzu, und eine frische Replica ist bereit für ihre erste Anfrage 60–120 Sekunden nach dem Start des Pods. Kleinere Modelle helfen proportional – ein 8B-Modell ist in 5–10 Sekunden da –, aber alles jenseits von 30B liegt im Bereich „Nutzer laufen in den Timeout“.

Für Batch-Workloads ist das unproblematisch. Für interaktive Workloads ist es fatal. Zwei Minuten Latenz für genau die Anfrage, die das Hochskalieren ausgelöst hat, sind nicht akzeptabel.

Die Gegenmaßnahmen, nach Aufwand sortiert:

• Halten Sie N Replicas dauerhaft warm. Das Minimum, das Ihre Durchschnittslast trägt. Skalieren Sie bei Bedarf hoch , aber niemals auf null herunter. Um das Minimum-Warm-Muster herum bauen ausgereifte Betreiber ganze Produkte.
• vLLM Sleep Mode. Neuere vLLM-Versionen unterstützen einen „Sleep“-Zustand, in dem die Gewichte im GPU-Speicher bleiben, die Engine aber Rechenressourcen freigibt. Das Aufwachen ist 18–20× schneller als ein frisches Laden. Nützlich, wenn mehrere Modelle sich GPUs teilen, aber immer nur eines läuft.
• Vorgewärmter Modell-Cache auf gemeinsam genutztem NVMe / NFS. Gewichte einmal in einen schnellen lokalen Cache ziehen, den alle Replicas einbinden. Das erste Laden passiert einmal beim Cluster-Start; weitere Replicas sind in Sekunden oben.
• Zeitgesteuerte Skalierung nach Tageszeit. Um 08:30 vorab hochskalieren, in Erwartung des Traffics um 09:00. Das einfachste und wirksamste Muster für vorhersehbare Tagesrhythmen. CronJobs, die kubectl scale aufrufen, sind unmodern, funktionieren aber.
• NVIDIA NIM Operator mit vorgebauten TRT-LLM-Engines. Vorab gebaute Engines, auf Platte zwischengespeichert, bei Bedarf geladen. Schnellerer Cold Start als eine frische Kompilierung, bei 70B aber weiterhin im Bereich von Dutzenden Sekunden.

Für die Kentino AI Kundschaft – kleine Flotten, vorhersehbare Nutzungsmuster – lautet die richtige Antwort fast immer N warme Replicas + zeitgesteuerte Skalierung + Cloud-Überlauf. Scale-to-Zero ist etwas für Serverless-Plattformen, bei denen jemand anderes den Cold Start ausbadet.

Autoscaling: HPA – aber auf welcher Basis?

Der Kubernetes-HPA nutzt standardmäßig CPU- und Speichermetriken. Beide sind für GPU-Inferenz falsch. Ein vLLM-Pod kann bei 5% CPU stehen und zu 100% überlastet sein oder bei 95% CPU laufen und sauber bedienen. Die Metrik, die Sie tatsächlich brauchen, ist eine von diesen:

Das richtige Werkzeug, um das in Kubernetes zu verdrahten, ist KEDA (Kubernetes Event-Driven Autoscaling): Es kann Prometheus-Abfragen direkt konsumieren und an einen HPA weiterreichen. Der vLLM Production Stack bringt eine erstklassige KEDA-Integration mit, und dasselbe Muster funktioniert mit KServe auf OpenShift AI.

Ein funktionierendes ScaledObject für die Skalierung nach Queue-Tiefe:

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: vllm-llama70b
spec:
  scaleTargetRef:
    name: vllm-llama70b
  minReplicaCount: 2     # immer warme Untergrenze
  maxReplicaCount: 6     # Obergrenze vor Cloud-Überlauf
  pollingInterval: 15
  cooldownPeriod: 300    # kein Flattern bei unruhiger Queue
  triggers:
  - type: prometheus
    metadata:
      serverAddress: http://prometheus:9090
      query: avg(vllm:num_requests_waiting)
      threshold: '5'     # ø 5 Wartende pro Replica → hochskalieren

Zwei Lehren aus dem Produktivbetrieb, die wir auf die harte Tour gelernt haben:

1. cooldownPeriod ist genauso wichtig wie der Trigger. Eine unruhige Queue führt zu ständigem Hoch- und Herunterskalieren, und jedes Hochskalieren bezahlt den Cold Start. 5 Minuten sind ein vernünftiges Minimum.
2. minReplicaCount sollte auf das Lasttal ausgelegt sein, nicht auf null. Die beiden Pods, die um 03:00 im Leerlauf stehen, sind genau die Pods, die die Spitze um 09:00 ohne Timeout abfangen.

Horizontal oder vertikal skalieren

Eine subtile Architekturentscheidung bei der Dimensionierung: Kaufen Sie mehr Boxen (horizontal) oder mehr GPUs pro Box (vertikal)?

Für Inferenz-Workloads mit stoßweisem Traffic gewinnt horizontal fast immer. Zwei 4-GPU-Boxen lassen sich als vier DP=2-Replicas betreiben, verkraften den Ausfall einer Box ohne Serviceverlust und erlauben es, Kapazität in Hälften statt in ganzen Einheiten zu skalieren. Vertikal ist die richtige Wahl für Training und für sehr große Single-Model-Inferenz, bei der TP die GPUs in einer elektrischen Domäne braucht.

Die psychologische Falle „Die GPU ist im Leerlauf, und ich zahle trotzdem dafür“

Kunden, die die Installation zum ersten Mal besuchen, rufen oft das Grafana-Dashboard auf, sehen dienstags um 14:30 eine GPU-Auslastung von 18% und fragen, warum sie für Hardware bezahlt haben, die 80% der Zeit nichts tut.

Die ehrliche Antwort lautet: Bei jedem latenzsensiblen Workload ist ein gewisser Leerlauf der Preis für niedrige Tail-Latenz. Eine Box mit 95% Dauerauslastung hat eine Queue. Eine Queue bedeutet Anfragelatenz. Wer 300 ms Time-to-First-Token will, bekommt auf derselben Box nicht zusätzlich 95% Auslastung. Entscheiden Sie sich.

Der Kompromiss, der sich sehr wohl optimieren lässt, ist das Verlagern fester Arbeit in die Leerlauffenster:

• Batch-Jobs (Autolabeling, Dokumentenextraktion, Embedding-Erzeugung für neue Inhalte), nachts eingeplant, wenn der Chatbot ruhig ist.
• Fine-Tuning-Läufe am Wochenende, wenn keine Nutzer aktiv sind.
• Periodische Neuindexierung von Vektorspeichern in den frühen Morgenstunden.

Das ist die Disziplin, die On-Premises-Box als Asset mit doppeltem Zweckzu behandeln: tagsüber latenzsensibles interaktives Serving, nachts Batch-Arbeit. Gut gemacht weist dieselbe Hardware, die im interaktiven Dashboard 25% Auslastung zeigt, im Gesamt-Workload-Dashboard 65% aus. Der CFO sieht Letzteres.

Was keine Lösung ist: die Anfragerate künstlich hochzutreiben, um „beschäftigt auszusehen“. Kunden versuchen das gelegentlich. Es verschlechtert die Tail-Latenz, macht das Monitoring nutzlos und ändert nichts an der Rechnung.

Die Entscheidungsmatrix

Die Form des Workloads bestimmt die richtige Architektur stärker als das Volumen. Ordnen Sie Ihre Situation der nächstliegenden Zeile zu:

Zwei Dinge macht diese Matrix richtig, die Ad-hoc-Planung falsch macht:

• Reine Burst-Workloads gehören in die Cloud. Hardware für einen Workload zu kaufen, der vier Stunden im Monat läuft, ist grob fahrlässig.
• Der Hybrid aus dauerhafter Grundlast und Burst will fast immer beides. Der Versuch, sich für nur eines von beiden zu entscheiden, geht meist daneben.

Die ehrliche Einschätzung

Die meisten Kentino Kunden sollten mit 30–50% Dauerauslastung on-prem planen und alles darüber per Cloud-Überlauf abfangen. Die Kunden, die on-prem auf 60–80% Auslastung kommen, sind die, die neben dem interaktiven Betrieb Batch-Arbeit fahren – Autolabeling nachts, Fine-Tuning am Wochenende, Embedding-Erzeugung in den frühen Morgenstunden. Die Kunden, die bei 10–15% Auslastung liegen, sind die, die auf die Spitze dimensioniert haben.

Der teuerste Einzelfehler ist der Kauf für den Worst Case am Dienstagnachmittag. Der zweitteuerste ist der Gang in die reine Cloud, obwohl die Dauerlast die Capex in 14 Monaten zurückgezahlt hätte. Die richtige Antwort liegt fast immer dazwischen: eine kleinere On-Premises-Box als ursprünglich spezifiziert, mit einem Cloud-Überlaufpfad für die Spitzen.

Gegenprobe zur Rechnung: Bei Cloud-Preisen von €0.50/Mtok und einer 4-GPU-Box mit Pro 6000 für €58k über 3 Jahre amortisiert sich die Box bei rund 14 Milliarden ausgelieferten Token. Gleichmäßig verteilt sind das ~150 Tok/s aggregierte Dauerlast – für die Box bei 25–35% Auslastung gut erreichbar. Darunter mieten. Darüber besitzen. Es ist derselbe Break-even-Punkt, den T01 und T02 aus der Perspektive pro Karte und pro Token erreichen.

Dies ist Teil des Kentino Wiki, einer Referenzreihe zu KI-Compute, Robotik und den Systemen, die beides verbinden. Kommentare und Korrekturen willkommen unter info@kentino.com.