CoreWeave: Inference-Autoscaling 8- bis 10-mal schneller als bei einer großen Allzweck-Cloud

Was CoreWeave getestet hat

CoreWeave hat in Benchmarks seinen Inference-Dienst mit einem der beliebtesten Allzweck-Cloud-Anbieter verglichen, den das Unternehmen nicht nennt. Die Tests umfassten die Startzeit von Containern, die Netzwerkgeschwindigkeit und die Gesamtlatenz beim Autoscaling. Nach Angaben des Unternehmens wirken sich alle drei auf die Inference-Leistung aus.

Als Modell diente EleutherAIs GPT-J-6B. CoreWeave wählte es, weil es ein gängiges Modell mittlerer Größe mit 6B Parametern ist und auf einer breiten Palette von GPUs läuft. Zudem sei es nicht bildbasiert, was es nach Darstellung des Unternehmens für Benchmarks von LLM-basierter Machine-Learning-Inference geeignet mache.

Die Ergebnisse laut CoreWeave

Das Unternehmen nennt drei zentrale Ergebnisse:

• Container-Start: Bei CoreWeave lag der Durchschnitt bei etwa 30 bis 45 Sekunden, bei der Allzweck-Cloud bei etwa 120 bis 150 Sekunden. CoreWeave spricht von einer 3- bis 5-fachen Verbesserung.
• Übertragung aus dem Objektspeicher: Die durchschnittliche Übertragungsgeschwindigkeit lag bei CoreWeave bei 700MB/s, beim Speicher der Allzweck-Cloud in derselben Region bei 72MB/s. CoreWeave bezeichnet das als 3- bis 5-mal schneller und sagt, in einigen Fällen seien bis zu 12Gb/s möglich.
• Gesamtlatenz beim Autoscaling: Bei CoreWeave lag der Durchschnitt bei 45 bis 70 Sekunden, bestehend aus 30 bis 45 Sekunden für den Container-Start und 15 bis 25 Sekunden zum Laden des Modells aus dem beschleunigten Objektspeicher. Bei der Allzweck-Cloud waren es 270 bis 390 Sekunden, zusammengesetzt aus 120 bis 150 Sekunden Startzeit und 150 bis 240 Sekunden Modellladezeit.

Aus den Gesamtwerten zum Autoscaling folgert CoreWeave, dass ML-Inference auf seiner Plattform 8- bis 10-mal schneller läuft. Es handelt sich um eigene Tests des Unternehmens, der Vergleichsanbieter wird nicht genannt.

Warum die Architektur aus Sicht von CoreWeave den Unterschied macht

CoreWeave argumentiert, der Unterschied liege in der zugrunde liegenden Infrastruktur. Die meisten Allzweck-Cloud-Anbieter böten verwaltetes Kubernetes an, das über einen Hypervisor läuft, also ein Programm zur Verwaltung virtueller Maschinen. Da diese Schicht auf dem Betriebssystem aufsetze, könne sie nicht direkt mit der Hardware kommunizieren, was die Effizienz verringern könne, so CoreWeave.

Der Stack von CoreWeave basiert auf Bare-Metal-Rechenleistung. Die Kubernetes-Schicht sitzt fast direkt auf der Hardware, nötig ist lediglich ein schlankes Betriebssystem. Das Unternehmen nennt das Serverless Kubernetes. Zusätzlich lassen sich virtuelle Maschinen innerhalb von Kubernetes-Containern betreiben. Bei klassischen Cloud-Setups kann das Hochfahren neuer Instanzen laut CoreWeave mehr als 5 bis 10 Minuten dauern.

Das Unternehmen verweist auch auf Unterschiede in den Abläufen. In einer Allzweck-Cloud müssten Nutzer zunächst über genügend Rechenkontingent verfügen, und für eine Erhöhung seien mitunter Anfragen sowie Gespräche über Pläne und Budget nötig. Das sei vor allem für kleinere Kunden einschränkend. Pods würden üblicherweise auf virtuellen Maschinen gestartet, und bei einer Standard-Container-Concurrency von 1 werde jeder Pod einer VM zugewiesen, was zu Verzögerungen führe. Außerdem könne der KNative-Activator beim Skalieren wegen begrenzter Puffer-Warteschlangen möglicherweise nicht alle eingehenden Anfragen einreihen, sodass einige in ein Timeout laufen.

Bei CoreWeave könnten Pods dagegen ohne Start einer virtuellen Maschine hochgefahren werden, und Nutzer könnten bedarfsgerecht über zehn bis tausende GPUs hinweg hoch- und wieder herunterskalieren. Zudem kommt Tensorizer zum Einsatz, ein Open-Source-Tool, mit dem sich ein PyTorch-Modell schnell von HTTP/HTTPS- und S3-Endpunkten laden lässt.

Was das für Nutzer bedeutet

CoreWeave stellt die Ergebnisse in den Kontext der Nutzererfahrung: Schnelleres Autoscaling bedeute schnellere Antworten und besseren Zugang zu Rechenleistung auf Abruf bei Lastspitzen. Allzweck-Clouds seien den Anforderungen unvorhersehbarer Inference-Workloads weniger gewachsen, und die Wahl der Infrastruktur wirke sich zudem auf den Preis aus.

Für Teams, die Modelle für Nutzer bereitstellen, lässt sich aus der Quelle mitnehmen, dass Hochskalierungszeit und Modellladegeschwindigkeit bei Lastspitzen die Reaktionsfähigkeit dominieren können. Da die Zahlen aus Tests des Anbieters selbst stammen, mit nur einem Modell mittlerer Größe und gegen einen ungenannten Konkurrenten, sollten Teams eigene Vergleiche mit ihren Workloads durchführen.