Das Modell-Laden frisst die teure TPU-Stunde
Bei KI-Inferenz auf GKE mit TPUs ist das Modell-Laden der teuerste Moment. Warum Cold-Start und Host-Speicher die Cloud-Rechnung treiben.
Auf einer TPU-VM mit vier Chips kostet jede Minute Geld. Als Google ein 449 Gigabyte grosses Modell in einem dokumentierten Benchmark erst nach über zehn Minuten antwortbereit hatte, zahlte der Node für Rechenleistung, die noch gar nicht rechnete. Genau dieser Startmoment entscheidet bei KI-Inferenz auf Google Kubernetes Engine über die reale Cloud-Rechnung.
Das Wichtigste in Kürze
- Der Ladevorgang ist der Kostentreiber. Für ein 480-Milliarden-Parameter-Modell fiel die Ladezeit auf einer TPU von über 630 auf unter 280 Sekunden, sobald die Gewichte direkt aus dem Objektspeicher gestreamt werden statt über den lokalen Umweg.
- Der Host-Speicher halbiert sich. Der klassische Ladepfad belegte in Spitze 881 Gigabyte Host-RAM, das Streaming kam mit 436 aus. Der Unterschied ist reserviertes Budget, das ein Node-Pool sonst dauerhaft vorhalten muss.
- Die Ursache steckt in der Architektur. TPU-Nodes haben keine lokalen SSDs. Der klassische Ladeweg belegt kurzzeitig die doppelte Modellgröße im Arbeitsspeicher. Wer das ignoriert, bezahlt es über Overprovisioning und träge Skalierung.
Verwandt:Kubernetes-FinOps: Die Hebel gegen 70 Prozent Cluster-Verschwendung / 4 Prozent im Rechenzentrum, 54 am Kraftwerk
Warum die teure TPU wartet, bevor sie rechnet
Ein Accelerator kostet pro Stunde, egal ob er Token generiert oder ein Modell in den Speicher schiebt. Bei kleinen Modellen fällt das kaum auf. Bei einem Modell mit hunderten Gigabyte Gewichten wird der Ladevorgang zur längsten Phase im Lebenszyklus eines Pods.
Das trifft direkt das Autoscaling. Skaliert ein Cluster bei Lastspitzen hoch, muss jeder neue Pod erst sein Modell laden, bevor er den ersten Request beantwortet. Dauert das mehrere Minuten, entsteht ein Dilemma. Entweder die Skalierung reagiert zu spät und Nutzer warten. Oder das Team hält teure Reserve-Kapazität dauerhaft warm. Beide Wege verbrennen TPU-Stunden.
Die Rechnung ist unbequem. Ein Node, der zehn Minuten lädt und danach eine Stunde arbeitet, verliert rund ein Siebtel seiner bezahlten Laufzeit an einen Vorgang, der keinen einzigen Token produziert.
Der versteckte Speicher-Aufschlag beim Start
Der klassische Ladeweg auf einer TPU führt über den Host-Arbeitsspeicher. Das Modell wird zunächst vollständig in den CPU-Speicher gelesen, dort für die Chips zerlegt und erst dann übertragen. Für PyTorch-Modelle ohne spezialisierte Ladelogik bedeutet das eine Speicherspitze von rund der doppelten Modellgröße, weil Checkpoint und aufbereitete Kopie kurzzeitig nebeneinander liegen.
Diese Doppelbelegung ist der eigentliche Kostenpunkt. Ein Node-Pool muss so dimensioniert werden, dass er die Spitze überlebt, nicht den Normalbetrieb. Reserviert wird also für einen Moment, der nur beim Start auftritt.
TPU-Nodes ohne lokale SSD zwingen zur Entscheidung
Anders als viele GPU-Instanzen haben TPU-Nodes keinen schnellen lokalen Datenträger, von dem sich ein Modell laden liesse. Die Gewichte kommen aus dem Objektspeicher oder von angehängten Volumes. Das verschärft den Zielkonflikt zwischen Ladezeit, Speicherkosten und dem Risiko, dass ein Node beim Start den Arbeitsspeicher überläuft.
Der Ausweg, den Google für diesen Fall dokumentiert, ist der offene Run:ai Model Streamer. Er umgeht den lokalen Umweg und schiebt die Gewichte parallel aus dem Objektspeicher direkt in den Chip-Speicher. Für den allgemeinen Fall nennt die Dokumentation bis zu sechsfach schnellere Ladezeiten gegenüber konventionellen Methoden. Der oben gemessene TPU-Fall lag bei gut Faktor zwei. Den TPU-Pfad unterstützt vLLM ab Version 0.18.0.
Wichtig für die Einordnung: Der gemessene Sprung auf Faktor zwei gilt dem beschriebenen Fall grosser PyTorch-Modelle. Für Modelle mit bereits optimierter Ladelogik ist der Gewinn kleiner. Wer den Streamer plant, sollte den eigenen Modelltyp prüfen, nicht die Benchmark-Zahl übernehmen.
Welche Hebel Plattform-Teams wirklich haben
Die erste Entscheidung ist der Ladepfad selbst. Streaming aus dem Objektspeicher senkt die Speicherspitze und macht kleinere, günstigere Node-Pools möglich. Das wirkt doppelt: schnellere Pod-Bereitschaft für die Skalierung, weniger reservierter Arbeitsspeicher pro Node.
Der zweite Hebel ist der Cache. Ein persistenter Compilation-Cache im Objektspeicher verkürzt Folgestarts spürbar, weil die aufwendige Vorbereitung nicht bei jedem Pod neu läuft. Für zonale Beschleunigung lässt sich ein Lese-Cache vor den Objektspeicher schalten.
Der dritte Hebel ist Planung. Echtes Scale-to-zero bleibt auf TPUs teuer, weil jeder Kaltstart den vollen Ladevorgang bezahlt. Für schwankende Last ist selektive Elastizität mit vorgewärmten Reserve-Pods oft günstiger als das reine Hoch- und Runterskalieren. Wer die Betriebskosten von KI-Infrastruktur ernst nimmt, etwa im Umfeld des Google Cloud Summit DACH 2026, kommt an dieser Rechnung nicht vorbei.
Häufige Fragen
Was ist der Run:ai Model Streamer?
Der Run:ai Model Streamer ist eine quelloffene Komponente, die Modellgewichte parallel aus einem Objektspeicher wie Cloud Storage direkt in den Speicher eines Accelerators lädt. Er umgeht den lokalen Datenträger und den Umweg über den Host-Arbeitsspeicher, wodurch grosse Modelle schneller und mit geringerer Speicherspitze startklar sind.
Warum ist der Cold-Start bei TPU-Inferenz ein Kostenproblem?
Ein Accelerator kostet pro Stunde, auch während er ein Modell lädt. Dauert der Ladevorgang bei grossen Modellen mehrere Minuten, verzögert das die Skalierung und zwingt Teams entweder zu langsamer Reaktion oder zu teurer Reserve-Kapazität. Beide Optionen erhöhen die Kosten pro tatsächlich beantwortetem Request.
Ab welcher vLLM-Version läuft der Streamer auf TPU?
Für den TPU-Pfad ist vLLM in Version 0.18.0 oder neuer nötig. Für GPUs unterstützt der Streamer die Anbindung an Cloud Storage bereits ab Version 0.11.1. Aktiviert wird er über ein zusätzliches Flag im Startbefehl.
Gilt der Faktor-zwei-Gewinn für jedes Modell?
Nein. Die gemessene Halbierung von Ladezeit und Speicherspitze bezieht sich auf grosse PyTorch-Modelle, die den klassischen Ladepfad über den Host-Speicher nehmen. Modelle mit bereits inkrementeller Ladelogik profitieren weniger. Vor der Umstellung lohnt ein Test mit dem eigenen Modell.
Wie hängt Modell-Ladezeit mit dem Autoscaling zusammen?
Jeder neu gestartete Pod muss sein Modell laden, bevor er Anfragen beantwortet. Ist diese Phase lang, reagiert die automatische Skalierung träge auf Lastspitzen. Kürzere Ladezeiten machen Pods schneller bereit, senken den Bedarf an vorgehaltener Reserve und verbessern die Auslastung der bezahlten Accelerator.
Lesetipps der Redaktion
cloudmagazinHöhere PUE-Grenzen und längere Fristen: Wie die EnEfG-Novelle die Rechenzentrums-Pflichten lockertcloudmagazinKI-Anbindung wird enterprise-reif: Das Model Context Protocol unter der Linux FoundationcloudmagazinFast auf Spitzenniveau, günstiger und über drei Kontinente trainiertMehr aus dem MBF Media Netzwerk
MyBusinessFutureKI im Mittelstand vom Pilot zur SkalierungDigital ChiefsDrei KI-Budgets, keine gemeinsame RechnungSecurityTodayWas ist ISO 27001? Definition, Zertifikat und AbgrenzungBildquelle: KI-generiert (Juli 2026)
