Wie GPU-Auslastung dich in die Irre führt — und was wirklich idle läuft

Ein Blick auf das GPU-Dashboard zeigt eine stabile Auslastung von 40 %. Die Hardware ist online, die Cluster-Gesundheit grün. Doch hinter der Ziffer verbirgt sich ein teures Missverständnis: Die 40 % sind ein Durchschnittswert über einen längeren Zeitraum. Sie verbergen die Realität, dass das System nach jedem Lastspitzen für Stunden nahezu ungenutzt bleibt — während die Rechenleistung weiter abgerechnet wird.

Das Problem ist nicht die Auslastung selbst, sondern die falsche Interpretation der Zahlen. Denn die angezeigte GPU-Nutzung berücksichtigt weder die tatsächliche Rechenaktivität noch die tatsächliche Nachfrage. Sie ist ein Relikt aus einer Zeit, in der Hardware-Reservierungen und Compute-Leistung synonym verwendet wurden — ein Denkfehler, der heute zu massiven Kostenineffizienzen führt.

Warum GPU-Auslastung trügt

Viele Monitoring-Tools vermischen zwei grundverschiedene Konzepte: die Speicherbelegung und die Rechenaktivität. Ein GPU-Beschleuniger kann voll beladen sein — mit Modellgewichten im VRAM, vorbereiteten Tensoren und einem aktiven Inferenz-Engine — und gleichzeitig keine einzige Berechnung durchführen. Das Kubernetes-Modell für GPU-Ressourcen behandelt die Zuweisung als binären Zustand: Entweder ist eine GPU zugewiesen oder nicht. Doch zwischen diesen beiden Zuständen liegt ein grauer Bereich: die reine Speicherreservierung ohne Compute-Last.

Beladen ≠ aktiv. Eine GPU, die ein Modell in ihrem Speicher hält, ist kein arbeitender GPU-Beschleuniger. Sie ist ein teurer Platzhalter. Doch genau diese Annahme führt dazu, dass Teams ihre Infrastruktur für Spitzenlasten auslegen — und dabei die tatsächliche Nachfrage ignorieren. Die Folge: Cluster, die monatelang kaum genutzt werden, aber trotzdem voll bezahlt werden müssen.

Die drei Arten von GPU-Idle — und warum sie unterschiedlich schmerzen

Nicht jede ungenutzte GPU ist gleich problematisch. Bevor Lösungen gesucht werden, muss geklärt werden, welcher Idle-Modus vorliegt — denn jeder erfordert eine andere Herangehensweise.

• Batch-Idle

Die Zeit zwischen Trainingsläufen. Das Cluster bleibt aktiv, weil der Cold-Start von Modellen zu kostspielig ist. Diese Lücken summieren sich über Wochen und Monate zu reinen Leerlaufkosten — obwohl die Hardware eigentlich pausieren könnte.

• Inference-Idle

Das Modell ist geladen, der Inferenz-Engine läuft im Hintergrund — doch die Anfragen kommen in einem Tempo, das deutlich unter der geplanten Kapazität liegt. Die GPU-Auslastung zeigt eine volle Reservierung an, doch die tatsächliche Rechenleistung ist minimal. Ein klassischer Fall von Überdimensionierung.

• Provisionierungs-Idle

Die teuerste Form des Leerlaufs. Hier wurde die Infrastruktur für eine Nachfrage geplant, die nie eintritt — sei es ein geplanter Lastpeak in drei Monaten oder ein großes Modell, das erst in sechs Wochen benötigt wird. Die Hardware läuft, die Kosten laufen mit, doch die eigentliche Nutzung bleibt aus.

Allen drei Idle-Modi gemeinsam ist ein zentraler Fehler: Die Nachfragekurve wurde nie korrekt modelliert.

Der wahre Ursprung des Problems: Ein Planungsversagen

Die gängige Diagnose bei niedriger GPU-Auslastung lautet: bessere Scheduling-Tools, optimierte Ressourcenverteilung, dynamische Skalierung. Doch diese Ansätze behandeln nur die Symptome — nicht die Ursache.

Der Kern des Problems liegt in der falschen Annahme, dass die Auslastung das primäre Problem sei. In Wahrheit ist die geringe Auslastung lediglich ein Symptom für eine fehlerhafte Kapazitätsplanung. Die eigentliche Frage lautet: Warum wurde die Infrastruktur für eine Nachfrage dimensioniert, die nie eingetreten ist?

Drei typische Fehler in der Prognose:

• Die Nachfragekurve wurde nie modelliert.

Teams planen oft für theoretische Spitzenlasten — ohne die tatsächliche Verteilung der Anfragen über den Tages- oder Wochenverlauf zu messen. Der Peak ist real, aber selten.

• Parallelität wurde angenommen, nicht gemessen.

Viele Planungen basieren auf der Annahme, wie schnell ein einzelner Request verarbeitet werden kann — statt zu messen, wie viele Requests gleichzeitig eintreffen und wie sich diese Last über die Zeit verteilt.

• Speicherbelegung wurde mit Durchsatz verwechselt.

Eine GPU, die ein 70-Milliarden-Parameter-Modell im VRAM hält, ist kein GPU-Beschleuniger, der an seiner Kapazitätsgrenze arbeitet. Sie ist ein teurer Speicherplatz.

• Ausführungsbudgets wurden nie definiert.

Ohne klare Limits expandiert die Infrastruktur ungebremst — weil der vorhandene Spielraum großzügig bemessen wurde. Der Fehler lag nicht im Scheduling, sondern in der initialen Dimensionierung.

Die Mathematik hinter dem Leerlauf: Ein teures Beispiel

Nehmen wir ein GPU-Cluster mit acht NVIDIA A100-Beschleunigern. Die monatlichen Gesamtkosten belaufen sich auf etwa 38.000 Euro. Bei einer durchschnittlichen Auslastung von nur fünf Prozent ergibt sich folgendes Bild:

• Monatliche Cluster-Kosten: 38.000 Euro
• Durchschnittliche Auslastung: 5 %
• Tatsächlich produktive Compute-Leistung: 1.900 Euro
• Idle-Kosten pro Monat: 36.100 Euro
• Jährlicher Planungsfehler: 433.200 Euro

Das ist kein leicht ineffizientes Cluster. Das ist eine Architekturentscheidung, die jährlich sechsstellige Summen verschwendet — und das nur, weil die Nachfrage nie korrekt erhoben wurde.

Warum Scheduler das Problem nicht lösen können

Der übliche Lösungsansatz für niedrige GPU-Auslastung besteht darin, bessere Scheduling-Tools einzusetzen: Volcano für Workload-Management, KEDA für Autoscale-Funktionen oder DCGM-basierte Monitoring-Lösungen. Diese Tools sind wertvoll — doch sie beheben nicht das zugrunde liegende Problem.

Schedulers optimieren die Ausführung von Arbeit, die bereits korrekt provisioniert wurde. Sie können keine falsche Nachfrageprognose korrigieren. Wenn ein Cluster für eine zehnmal höhere Anfragelast ausgelegt wurde, als tatsächlich eintritt, wird ein noch so optimierter Scheduler nur eine effizienter idle laufende Infrastruktur liefern — nicht aber die Kosten senken.

Schedulers verteilen Arbeit. Sie heilen keine falschen Planungsannahmen.

Die Lösung muss bereits in der Planungsphase ansetzen — bevor die Hardware überhaupt bestellt wird. Sie erfordert eine ehrliche Auseinandersetzung mit der tatsächlichen Nachfragekurve, gemessen an realen Produktionsdaten, nicht an theoretischen Maximalwerten.

Fazit: Die Architektur muss sich ändern

Der GPU-Auslastungsmythos ist kein Problem der Auslastung selbst. Es ist ein Symptom für eine fehlerhafte Nachfrageprognose, die sich in falschen Infrastrukturentscheidungen manifestiert. Die gängige Praxis, Speicherbelegung mit Compute-Aktivität gleichzusetzen, führt zu Clustern, die mehr kosten als sie nutzen.

Die Teams, die dieses Problem lösen, tun dies nicht durch den Einsatz ausgefeilterer Scheduler. Sie planen ihre Infrastruktur basierend auf echten Nachfragekurven, messen die Parallelität von Requests statt sie zu schätzen, und behandeln eine GPU mit geladenem Modell nicht als arbeitende Einheit, sondern als teuren Speicherplatz.

Die nächste Generation effizienter KI-Infrastrukturen wird nicht durch bessere Scheduling-Algorithmen entstehen — sondern durch bessere Daten über die tatsächliche Nachfrage. Der erste Schritt dorthin ist simpel: Zeichne die Nachfragekurve nicht in deinem Kopf, sondern auf Papier — und plane danach.