Skip to content
DigitalNeuron
Chips & Infrastruktur

AWS führt Modell-Caching ein, um Kaltstarts bei der Inferenz auf SageMaker HyperPod zu verkürzen

AWS hat Modell-Caching für Amazon SageMaker Inference auf HyperPod angekündigt, das Modellgewichte und Container-Images vorlädt, um die Startzeit von Pods von zig Minuten auf Sekunden zu senken.

Von DigitalNeuron Desk2 Min. Lesezeit

Kurze Antwort

Was hat AWS zur Verkürzung von Inferenz-Kaltstarts auf Amazon SageMaker HyperPod angekündigt?

AWS hat Modell-Caching für Amazon SageMaker Inference auf HyperPod eingeführt. Die Funktion lädt Modellgewichte und Container-Images vorab auf die Cluster-Knoten, sodass Pods mit rund 7 GB/s von lokalem NVMe-Speicher statt über das Netzwerk lesen können. Dadurch beginnen Pods laut AWS in der Regel innerhalb von Sekunden statt zig Minuten mit der Verarbeitung von Traffic.

Das Wichtigste

  • Laut AWS erfordert die Bereitstellung eines LLM auf SageMaker HyperPod zwei aufeinanderfolgende Downloads, bevor ein Pod Traffic bedienen kann: zunächst das Container-Image des Inferenzservers aus Amazon ECR, dann die Modellgewichte aus einer Speicherquelle wie Amazon S3, FSx for Lustre oder dem HuggingFace Hub.
  • Große Modelle wie DeepSeek-R1 mit über 600 GB können laut AWS 30 Minuten oder länger bis zur Einsatzbereitschaft benötigen, und bei jedem Scale-out-Vorgang wiederholt sich derselbe Download-Zyklus.
  • AWS erklärt, dass Modell-Caching Modellgewichte und Container-Images vorab auf Cluster-Knoten lädt, bevor Pods sie benötigen, sodass Pods mit rund 7 GB/s von lokalem NVMe-Speicher statt über das Netzwerk lesen können.
  • AWS zufolge umfasst die Funktion einen Weights-Cache, der aktiviert wird, indem man einer InferenceEndpointConfig- oder JumpStartModel-Ressource modelCacheConfig mit weightsCache hinzufügt; dies veranlasst den HyperPod Inference Operator, eine ModelDataCacheConfig-Ressource zu erstellen und die Gewichte vorab herunterzuladen.
  • AWS zufolge lassen sich die beiden Funktionen des Modell-Cachings gemeinsam oder getrennt aktivieren.

Amazon Web Services hat Modell-Caching für Amazon SageMaker Inference auf HyperPod angekündigt – eine Funktion, die verkürzen soll, wie lange Inferenz-Pods brauchen, bis sie Traffic verarbeiten können.

Das Kaltstart-Problem

Laut AWS liegt zwischen der Anforderung eines Pods und dessen Bereitschaft, Anfragen zu bearbeiten, beim Einsatz eines großen Sprachmodells auf SageMaker HyperPod eine spürbare Lücke. AWS führt diese Lücke auf zwei aufeinanderfolgende Downloads zurück: das Container-Image des Inferenzservers aus Amazon Elastic Container Registry sowie die Modellgewichte aus einer Speicherquelle wie Amazon S3, Amazon FSx for Lustre oder dem HuggingFace Hub.

Container-Images für Server wie vLLM oder LMI seien mehrere Gigabyte groß und benötigten laut AWS 5 bis 7 Minuten zum Herunterladen, da sie GPU-Treiber, CUDA-Bibliotheken und das Serving-Framework bündeln. Anschließend lädt der Inferenzserver die Modellgewichte herunter. Ein 145-GB-Modell auf Amazon S3 könne je nach Netzwerkbedingungen mehr als 20 zusätzliche Minuten in Anspruch nehmen, so AWS, und ein Modell mit über 600 GB, etwa DeepSeek-R1, könne insgesamt bis zu 30 Minuten oder mehr dauern.

AWS weist zudem darauf hin, dass sich dieser Download-Zyklus bei jedem neuen Pod im Rahmen eines Scale-out-Vorgangs wiederholt. In dem von AWS genannten Beispiel fordert ein HorizontalPodAutoscaler bei einem Traffic-Spitzenwert fünf neue Pods an, die alle unabhängig voneinander den gesamten Download-Ablauf durchlaufen. Zwar reagiere die Autoscaling-Richtlinie mitunter binnen Sekunden, doch bis tatsächlich zusätzlicher Traffic bedient werden könne, vergingen laut AWS 25 bis über 30 Minuten, da jeder Pod zunächst seine Downloads abschließen müsse.

So funktioniert Modell-Caching

Modell-Caching lädt laut AWS Daten vorab auf die Knoten, bevor Pods eingeplant werden, und umfasst zwei unabhängige Funktionen, die gemeinsam oder getrennt aktiviert werden können.

Eine davon, der Weights-Cache, lädt Modellgewichte laut AWS vorab auf lokalen NVMe-Speicher auf jedem Knoten. Den Einrichtungsprozess beschreibt AWS so: Man fügt einer InferenceEndpointConfig- oder JumpStartModel-Ressource modelCacheConfig mit aktiviertem weightsCache hinzu und wendet diese an. Nach der Anwendung erstelle der HyperPod Inference Operator automatisch eine ModelDataCacheConfig-Ressource und beginne, die Modellgewichte aus der konfigurierten Quelle herunterzuladen, etwa aus Amazon S3.

Bei aktiviertem Modell-Caching können Pods laut AWS mit rund 7 GB/s von lokalem NVMe-Speicher lesen, statt sie über das Netzwerk herunterzuladen. Dadurch beginnen Pods laut AWS in der Regel innerhalb von Sekunden statt zig Minuten mit der Verarbeitung von Traffic.

Quelle: AWS Machine Learning Blog, „Reduce inference cold starts on Amazon SageMaker HyperPod with model caching“, veröffentlicht am 10. September 2026.

Häufige Fragen

Welches Problem adressiert Modell-Caching laut AWS?
AWS zufolge schließt es die Lücke zwischen der Anforderung eines Pods auf SageMaker HyperPod und dessen Bereitschaft, Traffic zu bedienen – eine Lücke, die auf aufeinanderfolgende Downloads von Container-Image und Modellgewichten zurückzuführen sei.
Um wie viel schneller starten Pods laut AWS mit aktiviertem Modell-Caching?
AWS zufolge beginnen Pods bei aktiviertem Modell-Caching in der Regel innerhalb von Sekunden statt zig Minuten mit der Verarbeitung von Traffic.
Welche zwei Funktionen umfasst Modell-Caching?
AWS beschreibt einen Weights-Cache, der Modellgewichte vorab auf lokalen NVMe-Speicher auf jedem Knoten lädt, als eine von zwei unabhängigen Funktionen, die gemeinsam oder getrennt aktiviert werden können; der vorliegende Auszug der Ankündigung geht auf die zweite Funktion nicht im Detail ein.
Wie wird der Weights-Cache aktiviert?
AWS zufolge fügt man einer InferenceEndpointConfig- oder JumpStartModel-Ressource modelCacheConfig mit aktiviertem weightsCache hinzu, woraufhin der HyperPod Inference Operator eine ModelDataCacheConfig-Ressource erstellt und beginnt, die Gewichte aus der konfigurierten Quelle herunterzuladen.

Quellen

  1. Reduce inference cold starts on Amazon SageMaker HyperPod with model caching | Artificial IntelligenceAmazon Web Services (AWS)
Schlagwörterawssagemakerhyperpodinferencemodel-cachingamazon-bedrock

Passend dazu

Analyse: Ein offenes Modell selbst hosten — die Rechnung, die darüber entscheidet, und die Kosten, die niemand einplant

Nur bei hoher, gleichmäßiger Auslastung. Eigenes Hosting verwandelt variable Kosten pro Token in feste Stundenkosten — das lohnt sich, solange die Beschleuniger durchgehend ausgelastet sind, und rächt sich empfindlich, sobald sie leerlaufen. Ein ehrlicher Vergleich bepreist den gesamten Stack — Beschleuniger-Stunden, Redundanz, Entwicklungszeit und die Evaluationsarbeit, die nötig ist, um zu bestätigen, dass das kleinere Modell ausreicht — gegen die API-Rechnung für denselben Traffic. Souveränität, Datenresidenz und Latenzuntergrenzen sind eigenständige Gründe, die eigenes Hosting unabhängig von dieser Rechnung rechtfertigen können.

6 Min. Lesezeit

Warum verbraucht KI so viel Strom?

KI-Beschleuniger verbrauchen pro Rack weitaus mehr Strom als herkömmliche Server, und diese Leistung muss kontinuierlich bereitgestellt, gekühlt und bezahlt werden. Das Training eines großen Modells ist ein einmaliger Spitzenbedarf; die Bereitstellung für Millionen von Benutzern ist eine permanente Last, und die Inferenz dominiert den Energieverbrauch über die Lebensdauer eines eingesetzten Modells.

4 Min. Lesezeit