Zusammenfassung

  • Der Netzwerk-Stack von CoreWeave umfasst Scale-up-, Scale-out-, Speicher-, Mandanten-, Management-, Backbone- und private Verbindungsebenen; es handelt sich um eine Betriebsarchitektur, nicht um ein eigenständiges Produkt.
  • NVIDIA-Netzwerke und DPUs arbeiten mit CoreWeave-Software zusammen, um Beschleuniger zu planen, Mandanten zu isolieren und Daten in der Spezial-Cloud zu übertragen.
  • CoreWeave meldet 43 Rechenzentren, über 850 MW genutzte Leistung und rund 3,1 GW zugesicherte Kapazität; Microsoft trägt 67 % zum Umsatz 2025 bei, was sowohl Größe als auch Konzentration zeigt.
  • Die entscheidende Prüfung ist, ob die zugesicherte Leistung und Aufträge in zuverlässige, kundendiversifizierte Dienste umgewandelt werden können, bevor Finanzierungskosten, Leasing, Hardware-Veralterung und operative Komplexität sich summieren.

Das physische Wachstum beschleunigt sich schneller, als es eine typische Cloud-Regionenkarte abbilden kann

Zum 31. Dezember 2025 gab CoreWeave 43 Rechenzentren, mehr als 850 MW in Betrieb befindliche Leistung und etwa 3,1 GW zugesicherte Kapazität an. Die in Betrieb befindliche Zahl repräsentiert die damals nach Firmendefinition produktive Infrastruktur; die zugesicherte Zahl steht für künftige Ausbaurechte und Verpflichtungen, nicht für bereits installierte Kapazität.

Das Wachstum ist extrem steil: Ende 2023 waren es 10 Rechenzentren und etwa 70 MW; Ende 2024 waren es 32 und über 360 MW; Ende 2025 schließlich 43 und über 850 MW. Im ersten Quartal 2026 meldete das Unternehmen mehr als 1 GW in Betrieb und über 3,5 GW zugesicherte Kapazität. Dies zeigt ein industrialisiertes Expansionstempo – und wie schnell ältere Architekturen zur Minderheit werden können.

Strom allein ist eine Voraussetzung, kein fertiges Produkt. Zugesicherte Megawatt benötigen weiterhin Netzanschluss, Erzeugung oder Lieferung, hochdichte Verteilung, Kühlung, Gebäude, Netzwerkpfade, Beschleunigerlieferungen und Betriebsabnahmen. Jede Verzögerung auf einer dieser Ebenen kann Umsätze verschieben, während ein Teil der Kosten und Verpflichtungen bereits läuft.

Das Rechenzentrumsmodell ist gemischt. CoreWeave besitzt die Ausrüstung und kontrolliert große Teile des Rollouts, nutzt aber auch gemietete Einrichtungen und Drittdienstleister. Das beschleunigt die geografische Expansion, macht aber die Performance des Vermieters, Baufortschritte, Stromlieferungen und Vertragsbedingungen zu einem Teil der Plattformzuverlässigkeit.

Ein einzelner GPU macht noch keine Cloud

Ein Beschleuniger in einem bestromten Rack kann Code ausführen, liefert aber nicht automatisch das, wofür Kunden einen Cloud-Dienst bezahlen.

Trainings-Teams benötigen viele Beschleuniger, die wie ein einheitlicher Ressourcenpool arbeiten; Daten müssen mit ausreichender Geschwindigkeit vom Speicher in die Berechnung fließen; die kollektive Kommunikation darf den Job nicht überwiegend in Warten versetzen; verschiedene Mandanten müssen voneinander isoliert sein; der Scheduler muss wissen, welche Knoten, Links und Geräte gesund sind; Checkpoints müssen nach Ausfällen erhalten bleiben; Ingenieure brauchen Pfade in die Umgebung, und Nutzer benötigen Verbindungen zu anderen Clouds, Büronetzen und externen Diensten.

Erst wenn diese Pfade stabil reproduzierbar sind, wird das Cloud-Produkt real.

Daher kann das Netzwerk in der KI-Cloud nicht als bloßes Anhängsel der Berechnung betrachtet werden. In klassischen Unternehmensarchitekturen wird das Netz oft als System beschrieben, das Server verbindet; in der verteilten KI ist das Netz unmittelbar an der effektiven Rechenleistung beteiligt. Ein synchroner Job kann durch ein degradiertes Optikmodul, einen abnormal langsamen Beschleuniger, eine überlastete Rail oder einen Speicherpfad, der nicht schnell genug folgt, ausgebremst werden. Während der Job wartet, laufen Finanzierungs- und Nutzungskosten für teure Hardware weiter.

Das Netzwerkdesign beeinflusst daher sowohl Benchmarks als auch die Frage, ob jede finanzierte GPU-Stunde Wert generiert.

CoreWeave ist deshalb eine relevante Betrachtung, weil das Unternehmen diese Beziehung besonders klar zeigt. Es fokussiert sich auf Beschleuniger-Infrastruktur und behandelt GPUs nicht als kleinen Dienst in einem allgemeinen Cloud-Katalog, sodass die öffentlichen Materialien ausführlich auf Rack-Netzwerke, DPUs, Bare-Metal-Orchestrierung, gemanagte Supercomputer, dedizierte Leitungen und Fehlerbehebung eingehen. Diese Materialien belegen die Designabsicht und Produktarchitektur, sind aber keine vollständige Karte für jeden Standort, jede Hardware-Generation und jede Kundenbereitstellung.

Die wirklich nützliche Frage ist nicht, ob CoreWeave abstrakt über ein „schnelleres Netzwerk“ verfügt, sondern wie viele Netzwerktypen zusammenarbeiten müssen, damit ein KI-Workload zu einem zuverlässigen Dienst wird – und wer jede Schicht kontrolliert.

Was genau ist mit „CoreWeave-Netzwerk-Stack“ gemeint?

Diese Bezeichnung ist ein redaktioneller Sammelbegriff, keine eigene juristische Person und kein einzeln verkäufliches SKU. Rechtliche und wirtschaftliche Betreiberin ist CoreWeave, Inc., eine in Delaware eingetragene Gesellschaft mit Sitz in Livingston, New Jersey, gehandelt an der Nasdaq als CRWV. Der Netzwerk-Stack ist Teil der größeren CoreWeave Cloud Platform, die auch Compute, Speicher, Orchestrierung und Managed Services umfasst.

Verschiedene Namen entsprechen verschiedenen Schichten. Nimbus ist CoreWeaves DPU-basierte virtuelle Netzwerkarchitektur. Der CoreWeave Kubernetes Service (CKS) liefert gemanagtes Kubernetes auf Bare-Metal. SUNK bündelt Infrastruktur und Betrieb zu einem Managed-Supercomputer-Service. Mission Control fügt Überwachung, Wartung und Lebenszyklus-Management hinzu. Direct Connect stellt dedizierte Kundenleitungen bereit. NVLink, NVSwitch, Quantum, Spectrum‑X und BlueField sind NVIDIA-Technologien, die CoreWeave integriert – keine von CoreWeave erfundenen Protokolle oder Hardware.

Das Auseinanderhalten dieser Schichten vermeidet zwei häufige Fehler. Der erste Fehler ist, jedes Protokoll und Gerät innerhalb der Plattform CoreWeave zuzuschreiben; der Beitrag des Unternehmens liegt primär in Systemintegration, Qualifikation, Betrieb und in der Cloud-Software, die auf Zuliefertechnologie aufbaut. Der zweite Fehler ist, sich ein einheitliches Netz vorzustellen, das von jedem GPU bis zu jedem Kunden reicht.

Scale-up-Verbindungen innerhalb eines Racks, fabrikübergreifende Trainingsnetze, Speichernetze, VPC-Overlays, Managementpfade und das transatlantische Backbone erfüllen unterschiedliche Aufgaben, haben verschiedene Latenzziele und Fehlerdomänen und können nicht mit einer einzigen Bandbreitenzahl beschrieben werden.

Dieselbe Unterscheidung gilt für das Eigentum an den Vermögenswerten. CoreWeave stellt große Mengen an Ausrüstung bereit und betreibt sie, aber die Unterlagen des Unternehmens beschreiben auch Leasing, Drittrechenzentren, Stromverpflichtungen, Glasfaser-Kooperationen und Gerätefinanzierungen. Ein Dienst kann operativ hoch integriert sein, ohne dass CoreWeave das Gebäude, das Versorgungsunternehmen, jede Fernleitung oder jede Komponente im Rack besitzt. „Vertikale Integration“ ist nur dann aussagekräftig, wenn sie schichtübergreifende Koordination meint, und nicht mit vollständiger Autarkie verwechselt werden darf.

Von Atlantic Crypto zur Spezial-Cloud für Compute

CoreWeave wurde 2017 als The Atlantic Crypto Corporation gegründet und betrieb zunächst GPUs für Kryptowährungs-Workloads. Im September 2018 wandelte sich das Unternehmen von einer LLC in eine Delaware-Corporation um und firmierte im Dezember 2019 in CoreWeave um, um sich auf spezialisierte Cloud-Dienste zu konzentrieren.

Diese Historie wird mitunter verkürzend als „vom Mining zur KI“ erzählt, doch die wichtigere Kontinuität ist die Betriebskompetenz. Beide Geschäftsfelder verlangen vom Unternehmen, Beschleuniger zu beschaffen, Strom zu sichern, hochdichte Hardware zu warten und Arbeitslasten auf unterausgelastete Ressourcen zu lenken. CoreWeave hat die Beschaffungs- und Nutzungsökonomie von Beschleuniger-Assets erlernt, bevor die vollständige Cloud-Plattform stand.

Die Unterscheidung ist wesentlich, denn eine veränderte Nachfrage erzeugt nicht automatisch eine Cloud-Plattform. Mining-Workloads sind oft repetitiv und kommen mit einfacher Asset-Steuerung aus; visuelle Effekte, maschinelles Lernen und HPC benötigen hingegen andere Software, Datenbewegung, Isolation und Servicegarantien. CoreWeave musste eine komplette Steuerungsschicht hinzufügen, damit externe Kunden Ressourcen vertrauen können, die ihnen weder gehören noch die sie selbst inspizieren können.

In den frühen 2020er-Jahren baute das Unternehmen dedizierte Compute-, Speicher- und Kubernetes-Dienste auf. Bare-Metal-Kubernetes wurde eine der Hauptschnittstellen: Kunden orchestrieren Container direkt auf Beschleuniger-Servern, ohne eine traditionelle Virtualisierungsschicht dazwischen. Ende 2023 betrieb CoreWeave eigenen Angaben zufolge 10 Rechenzentren mit rund 70 MW in Betrieb; Ende 2024 waren es 32 Rechenzentren mit über 360 MW.

Die Expansion veränderte die Natur der Netzwerkfrage. Ein Betreiber mit zehn Standorten kann sich noch stark auf Expertenwissen und lokale Ausnahmen stützen; eine Cloud mit dreißig oder vierzig Standorten benötigt reproduzierbare Designs, softwaregesteuerte Richtlinien, eine einheitliche Qualifikation, gemeinsames Monitoring und die Fähigkeit, Kunden über Hardwaregenerationen hinweg zu migrieren, ohne die operative Einheitlichkeit zu verlieren.

Skalierung macht aus technischen Entscheidungen Governance-Fragen: Wer darf Änderungen genehmigen, wie schnell werden Ausnahmen entdeckt, und bildet jeder neue Standort wirklich die beabsichtigte Kontrollgrenze nach?

CoreWeave ging im März 2025 an die Börse. Das brachte nicht nur Eigenkapital, sondern auch einen Börsenprospekt und SEC-Einreichungen, die Einblicke in Einrichtungen, Kundenkonzentration, Schulden, Leasing, Interconnection-Architektur und Risiken geben. Der Netzwerk-Stack kann daher sowohl als technisches System als auch als Kapitalverpflichtung eines börsennotierten Unternehmens analysiert werden.

Die Arbeitslast bestimmt die Architektur

Das Training großer Modelle verteilt die Berechnung auf mehrere Beschleuniger und tauscht fortwährend lokale Ergebnisse aus. Das konkrete Kommunikationsmuster hängt von der Modellarchitektur, der Parallelisierungsmethode und der Software ab, aber das Infrastrukturproblem ist relativ stabil: Die effektive Geschwindigkeit des Ressourcenpools hängt sowohl von der lokalen Berechnung als auch von der kollektiven Kommunikation ab. Selbst wenn die Gesamtbandbreite eines Netzes hoch ist, können Stau, Topologie oder Tail-Latency die Synchronisationspunkte ausbremsen und teure Rechenleistung ungenutzt lassen.

Die Plattform muss auch Verkehr tragen, der nicht durch kollektive Kommunikation geprägt ist. Datensätze fließen in die Umgebung, Checkpoints werden aus dem GPU-Speicher in den Speicher geschrieben, das Steuerungssystem verteilt Jobs und Richtlinien, Ingenieure ziehen Logs, Inferenzdienste exponieren Endpunkte, und Backups oder Replikate können über Regionen hinweg bewegt werden. Die verschiedenen Verkehrstypen tolerieren Latenz und Paketverlust unterschiedlich. Behandelt man sie wie ein einziges undifferenziertes Netz, werden die Performance unvorhersehbar und Fehler schwer isolierbar.

Daraus ergibt sich ein geschichtetes Design: Scale-up-Links erzeugen eng gekoppelte Domänen innerhalb eines Rack-Systems; das Scale-out-Fabric verbindet verschiedene Racks; Speicherpfade liefern Daten an Workloads und bewahren Zustände; Mandantennetze stellen private Adressen und Richtlinien bereit; das Managementnetz erlaubt dem Betreiber, Hosts, DPUs, Switches und Wartungsprozesse zu steuern; das Backbone verbindet Standorte mit dem externen Ökosystem; dedizierte Kundenleitungen schließen CoreWeave an andere Managementdomänen an.

Diese Schichten interagieren, können einander aber nicht ersetzen. Fern-Glasfaser kann kein lokales GPU-Fabric ersetzen, weil die Signallaufzeit ein eng synchronisiertes Training über weite Entfernungen verhindert; NVLink-Domänen sind keine Kunden-VPCs; ein Overlay kann Adressunterschiede kaschieren, aber kein defektes Optikmodul im Underlay reparieren; Kubernetes versteht ohne Geräte-Plugins und Topologie-Informationen nicht von selbst, wie die einzelnen Rails und Switching-Pfade beschaffen sind.

Die Architektur ist daher im Kern eine Kette von Intent-Übersetzungen. Der Kunde fragt einen Cluster, Namespace, ein Netz oder einen Job an; das CoreWeave-Steuerungssystem bildet die Anfrage auf verfügbare Server, Fabrics, Speicher und Richtlinien ab; Nimbus übersetzt VPC-Intentionen in DPU- und Underlay-Zustände; Kubernetes und Slurm-bezogene Dienste übertragen Workload-Intentionen in Knoten- und Beschleunigerzuweisungen; Mission Control setzt Gesundheitssignale in Wartungsaktionen um. Der Kunde sieht einen Dienst, und die Plattform muss dafür sorgen, dass alle Übersetzungen konsistent bleiben.

Scale-up-Netzwerk innerhalb der Rack-Domäne

Ein Scale-up-Netzwerk verbindet Beschleuniger innerhalb eines hochintegrierten Systems. In den Rack-Scale-Designs von NVIDIA stellt NVLink eine hochbandbreitige GPU-zu-GPU-Kommunikation bereit, und NVSwitch übernimmt das Switching in der lokalen Domäne. CoreWeave integriert diese Technologien in bestimmten Systemen und Hardware-Generationen.

Entscheidend ist nicht nur die Marke, sondern die physische Nähe. Eine Scale-up-Domäne erlaubt es, Modell-Sharding und kollektive Kommunikation bei jedem Schritt ohne das allgemeine Rechenzentrumsnetz abzuwickeln, und lässt ein Rack eher wie ein großes Beschleunigersystem wirken denn wie eine Ansammlung unabhängiger Server. Gleichzeitig entsteht eine eigene Fehlerdomäne: Probleme mit Rack-internen Switches, Kabeln, Kühlung oder Komponenten können mehrere GPUs, die der Scheduler als zusammengehörig betrachtet, gleichzeitig beeinträchtigen.

Der CoreWeave-Börsenprospekt beschrieb, dass manche Cluster-Konfigurationen eine nicht blockierende GPU-Interconnect-Bandbreite von bis zu 3.200 Gbit/s bieten können. „Manche Cluster-Konfigurationen“ ist die wichtigste Einschränkung. Dieser Wert ist keine allgemeingültige SLA und beschreibt weder alle Standorte noch alle Generationen. Die tatsächlich vom Workload erzielte Bandbreite hängt außerdem von Software, Topologie, Nachrichtenmustern und dem Gesundheitszustand des gesamten Pfads ab.

Scale-up entschärft einen Engpass, erhöht aber an anderer Stelle die Dichte. Mehr Beschleuniger und mehr lokale Bandbreite steigern den Strombedarf, die Kühlanforderung und den Wartungsaufwand pro Rack. Steigt die Rechendichte, ohne dass das thermische Design und die Betriebsprozesse Schritt halten, lässt sich das System möglicherweise schwerer warten, und Engpässe verlagern sich in den Scale-out-Bereich und zum Speicher. Die Architektur muss als Ausbalancierung von Komponenten verstanden werden, nicht als Aufzählung maximaler Spezifikationen.

Scale-out-Fabric: InfiniBand und Ethernet parallel

Sobald ein Job die Scale-up-Domäne verlässt, gelangt er in das Scale-out-Fabric. Unterlagen und technische Materialien von CoreWeave erwähnen NVIDIA Quantum-2 InfiniBand, das Quantum-X800 XDR-800G-Fabric sowie Spectrum‑X Ethernet mit RoCE und RDMA. Dass InfiniBand und Ethernet nebeneinander existieren, ist wesentlich: CoreWeave legt die Plattform nicht auf eine einzelne Protokollfamilie fest.

InfiniBand für eng gekoppelte Cluster

InfiniBand zielt auf Kommunikation mit niedriger Latenz und direktem Speicherzugriff und ist im HPC-Umfeld lange etabliert. In KI-Clustern kann es den Overhead des Host-Prozessors reduzieren und Daten zwischen Beschleuniger-Hosts verschieben. Die NVIDIA-Quantum-Systeme liefern darüber hinaus Switching und Fähigkeiten für kollektive Kommunikation. CoreWeave integriert diese Fabrics in seine Cluster-Dienste, verkauft InfiniBand aber nicht als eigenständigen Telekommunikationsdienst.

Die öffentlichen Materialien legen nicht alle Topologien, Überbuchungsfaktoren, Adaptive-Routing-Richtlinien oder Kunden-Servicegrenzen offen. „Nicht blockierend“ kann sich nur auf ein bestimmtes Design beziehen, nicht auf die gesamte Flotte. Selbst ein gut geplantes Netz kann durch degradierte Optikmodule, ungeeignete Job-Platzierung, ungleichmäßige Verkehrsverteilung oder Software-Hotspots beeinträchtigt werden. Ein Käufer sollte nachfragen, mit welcher Hardwaregeneration, Topologie und Qualifikation der konkret zugewiesene Cluster arbeitet.

Spectrum‑X und RoCE bilden einen Ethernet-Pfad

Spectrum‑X ist die KI-orientierte Ethernet-Netzwerkplattform von NVIDIA. RoCE transportiert RDMA-Semantik über Ethernet, sodass Anwendungen direkten Speicherzugriff erhalten, während der Betreiber ein Ethernet-Fabric beibehält. CoreWeave setzt Spectrum‑X ein und bietet damit einen weiteren Scale-out-Pfad für Workloads und Hardwaregenerationen, die um dieses Ökosystem herum entworfen sind.

Vertrautheit mit Ethernet bedeutet nicht operative Einfachheit. RoCE-Performance hängt von Staukontrolle, Queue-Design, Paketverlustverhalten, Telemetrie und End-to-End-Tuning ab. Das Netz kann vertraute Ethernet-Rahmen verwenden und verlangt dennoch spezialisierte Ingenieursarbeit, um Head-of-Line-Blocking, Incast oder Instabilitäten in der kollektiven Kommunikation zu vermeiden. Der Wert einer integrierten Cloud liegt darin, einen großen Teil dieser Tuning-Last auf den Anbieter zu verlagern; das entsprechende Risiko besteht darin, dass Kunden keine direkte Sicht auf diese Entscheidungen haben.

Rail-optimierte Topologie und Job-Platzierung

Multi-Rail-Systeme gruppieren die zugehörigen NICs und Beschleuniger so, dass der kollektive Verkehr über relativ regelmäßige parallele Pfade läuft. Rail-Optimierung kann unnötigen Querverkehr vermeiden und die Bandbreite vorhersagbarer machen, setzt aber voraus, dass der Scheduler die physische Topologie versteht; falsche Knotenkombinationen zerstören den Designvorteil.

Rails bündeln auch Fehler. Degradiert eine Rail, kann jeder Knoten, der sie nutzt, zum Nachzügler werden, selbst wenn die übrigen Schnittstellen gesund sind. Das Betriebsteam muss zwischen einem Einzelserverausfall und einem gemeinsamen Netzfehler unterscheiden können. Darum sind Topologie-Telemetrie, Qualifikation und Wartung genauso wichtig wie die Port-Geschwindigkeit.

Nimbus verlagert die Cloud-Grenze auf die DPU

Ein Hochleistungs-Cluster-Fabric formt noch keine mandantenfähige Cloud. Kunden brauchen zudem private Adressen, Routing-Kontrolle, Internetzugang und Isolation. CoreWeaves Antwort darauf ist Nimbus: eine virtuelle Netzwerkarchitektur, die VPC-Funktionen auf DPUs auslagert. Die öffentliche Dokumentation erwähnt NVIDIA BlueField-3 DPUs und beschreibt in der Sicherheitsarchitektur VRF, VXLAN und EVPN Type-5-Routen.

Die DPU sitzt zwischen dem vom Kunden kontrollierten Compute und der vom Anbieter kontrollierten Infrastruktur – eine hochsensible Position. Sie kann virtualisierten Netzwerkverkehr verarbeiten, Segmentierung durchsetzen und die Host-CPU dem Workload überlassen; sie kann außerdem die Mandanten-Isolationsgrenze außerhalb des Betriebssystems platzieren, das der Kunde potenziell kontrolliert. Das ist daher sowohl eine Performance- als auch eine Sicherheitsentscheidung.

Wie sich ein VPC-Overlay zusammensetzt

VRF trennt eine Routing-Domäne von einer anderen; VXLAN transportiert Mandantensegmente über das gemeinsam genutzte physische Underlay; EVPN verteilt Erreichbarkeitsinformationen, und Type-5-Routen können IP-Präfixe aussenden, nicht nur MAC-Adressen. Zusammen ermöglichen diese Mechanismen CoreWeave, private Netze auf einer gemeinsam genutzten physischen Infrastruktur anzubieten.

Das Overlay beseitigt die Underlay-Abhängigkeiten nicht. Versagt die physische Erreichbarkeit, versagt auch das virtuelle Netz; Fehler in der Routenverteilung können Isolation oder Konnektivität in großem Maßstab zerstören; weist das DPU-Image oder das Richtliniensystem einen Defekt auf, kann sich ein fehlerhafter Zustand schnell über viele Hosts ausbreiten. Die Cloud-Abstraktion verlagert die Komplexität vom Kunden zum Anbieter, ohne dass die Komplexität verschwindet.

Die DPU als Teil der Vertrauensbasis

Nimbus trennt die Netzwerkfunktionen des Anbieters besser vom Kunden-Host, erhöht aber zugleich die Bedeutung von DPU-Firmware, Secure Boot, Schlüsseln, Richtlinienverteilung, Logging und Wiederherstellung. Ein Gerät, das Isolation erzwingt, muss beobachtbar und patchbar sein, ohne zu einem unkontrollierten Pfad in die Mandantenumgebung zu werden.

Diese Kontrollgrenze beeinflusst auch die Fehlersuche. Ein Konnektivitätsproblem kann vom Kunden-Workload, von Kubernetes-Richtlinien, der VPC-Konfiguration, der DPU-Software, der EVPN-Kontrollebene oder dem physischen Fabric herrühren. Das Support-Team benötigt schichtübergreifende Evidenz, ohne dass ein Mandant die Daten eines anderen einsehen darf. Die öffentlichen Materialien erklären die beabsichtigte Architektur, liefern aber keine flottenweit unabhängig geprüften Aufzeichnungen über Isolationsfehler und Wiederherstellungszeiten.

Bare-Metal-Kubernetes als Kundenkontrollschicht

Der CoreWeave Kubernetes Service liefert gemanagtes Kubernetes auf Bare-Metal-Infrastruktur und vermeidet eine traditionelle Virtualisierungsschicht zwischen Container-Plattform und GPU-Servern. Jeder Cluster erhält eine eigene VPC und integriert Hochleistungsnetzwerke sowie Speicher, die auf verteilte Workloads abgestimmt sind.

Bare-Metal entfernt eine Abstraktionsschicht, ist aber nicht mit Einfachheit gleichzusetzen. Kubernetes muss weiterhin GPUs erkennen, Geräte exponieren, Quotas durchsetzen, Pods platzieren und mit Netz- und Speicher-Plugins zusammenarbeiten. Die Plattform muss Node-Images, Treiber, Firmware, Container-Runtimes und Cluster-Upgrades mit den darunterliegenden Hardwaregenerationen in Einklang bringen. Der Kunde erhält eine vertraute API, und CoreWeave trägt die deutlich komplexere Kompatibilitätsmatrix.

Was Kubernetes entscheiden kann – und was nicht

Kubernetes kann anhand der ihm bekannten Informationen und Richtlinien entscheiden, wo ein Pod platziert wird, versteht aber nicht von selbst, wie jede Rail, jedes Optikmodul, jeder Switching-Pfad oder der Zustand der kollektiven Kommunikation beschaffen ist. CoreWeave muss Geräte-Plugins, Operatoren, Topologie-Informationen und Betriebskontrollen hinzufügen, damit die logische Platzierung mit den tatsächlich verfügbaren physischen Ressourcen übereinstimmt.

Netzwerkrichtlinien haben ebenfalls Grenzen. Eine Kubernetes-Policy kann den Verkehr zwischen Workloads einschränken, während VPC und DPU weiter gefasste Mandanten- und Routing-Grenzen setzen. Dass ein Policy-Objekt existiert, bedeutet nicht, dass der tatsächliche Paketpfad die beabsichtigte Regel auch durchsetzt; Konfiguration, Implementierung und Beobachtbarkeit müssen übereinstimmen.

SUNK macht aus Clustern gemanagte Supercomputer

SUNK wird als produktionsreifer Managed-Supercomputer-Service positioniert, der Infrastruktur, Hochleistungs-Fabric, Workload-Orchestrierung und CoreWeave-Betrieb zusammenbringt. Er richtet sich an Kunden, die eine große dedizierte Umgebung wünschen, ohne selbst die vollständige Anlage und ein Betriebsteam aufbauen zu müssen.

Das verschiebt die Verantwortungsschnittstelle. Der Kunde bleibt für Modellarchitektur, Code, Daten und Job-Richtlinien verantwortlich, während mehr von der Hardware-Lebenszyklus, der Cluster-Qualifikation und der Fehlerbehandlung zu CoreWeave übergeht. Es ähnelt eher einer gemanagten HPC-Einrichtung, die über Cloud-Ära-Verträge und Software bereitgestellt wird, als einem Pool vollständig austauschbarer Instanzen.

Mission Control macht aus Betrieb ein Produkt

Mission Control fügt Überwachung, Wartung, Reparatur und Lebenszyklus-Unterstützung hinzu. Je größer der Job, desto wichtiger wird diese Schicht: In einem kleinen Serverpark hat der Austausch einer Komponente überschaubare Auswirkungen; in einem hochgradig synchronisierten Ressourcenpool kann die Diagnose einer degradierten Verbindung darüber entscheiden, ob Tausende Beschleunigerstunden Wert schaffen.

CoreWeaves Materialien beschreiben proaktives Monitoring und operative Eingriffe – das belegt ein Leitbild, ist aber keine unabhängig geprüfte Uptime und liefert keine öffentliche Verteilung der mittleren Reparaturzeit. Da Zuverlässigkeit ein zentraler Grund dafür ist, weshalb Kunden einen Anbieter wählen statt selbst Cluster zu bauen, ist das Fehlen einer vollständigen Störungs-Historie selbst eine wichtige Informationsgrenze.

Speicher ist Teil der vernetzten Berechnung

Trainingsdaten, Checkpoints und Modell-Artefakte durchlaufen Speicherpfade, die den gesamten Workload begrenzen können. Selbst wenn die GPU-zu-GPU-Bandbreite extrem hoch ist, steht der Cluster still, wenn das Einlesen der Eingabedaten, das Schreiben von Checkpoints oder das Wiederherstellen von Zuständen nicht schnell genug geht. Die CoreWeave-Plattform umfasst Objekt- und Dateispeicher und beschreibt den Hochleistungs-Datentransfer als Teil des Dienstes.

Checkpoint-Verkehr hat besondere Muster. Viele Worker können zeitgleich Zustände sichern und erzeugen dadurch Verkehrsspitzen, die sich von der kollektiven Kommunikation unterscheiden. Teilt sich der Speicher die physische Ressource mit dem Trainings-Fabric, sind Isolation oder Kapazitätsplanung erforderlich; nutzt er ein separates Netz, muss die Plattform dennoch Fehler und Wiederherstellung auf beiden Pfaden koordinieren.

Speicher beeinflusst auch die Migrationsfähigkeit. Einen Modellwechsel zu CoreWeave kann es erfordern, große Datenmengen aus anderen Clouds oder privaten Umgebungen zu übertragen; der Umzug heraus kann Kosten, Zeit und vertragliche Reibung verursachen. „Zero Egress Migration“ ist ein kommerzieller Mechanismus von CoreWeave, um bestimmte Einwanderungskosten zu senken – keine technische Performance-Garantie und auch keine Aussage, dass jeder ausgehende Verkehr kostenfrei ist oder dass die Datenbewegung keine operativen Kosten verursacht.

Kunden sollten daher auf End-to-End-Evidenz bestehen. Spitzenwerte für Beschleuniger oder Netzwerk sind wertvoll, aber produktive Jobs umfassen auch Datenaufbereitung, Checkpoints, Modellregistrierung, Logs und Wiederherstellung. Ein Benchmark, der nur eine einzige Schicht testet, beantwortet nicht, wann der vollständige Job abgeschlossen ist oder wie hoch die Gesamtkosten ausfallen.

Das Backbone verbindet Regionen, ist aber kein synchroner Supercomputer

CoreWeave beschreibt ein Carrier-Grade-Backbone, das nordamerikanische und europäische Rechenzentren über Land- und Seekabel verbindet, und bietet direktes Peering sowie dedizierte Leitungen. In den Unterlagen werden Direct Connect mit 10, 100 und 400 Gbit/s genannt, je nach Standort und Verfügbarkeit.

Das Backbone hat eine andere Aufgabe als das lokale Scale-out-Fabric. Es kann Datensätze, Replikate, Checkpoints, Steuerungs- und Inferenzverkehr transportieren, Nutzer und andere Clouds anbinden sowie Wiederherstellung und Verteilung unterstützen. Die Signallaufzeit über große Entfernungen sorgt dafür, dass es entfernte Einrichtungen nicht zu einem Cluster mit niedriger Latenz für eng synchronisiertes Training machen kann.

Dedizierte Leitungen reduzieren eine Unsicherheit

Dedizierte Circuits können die Schwankungen des öffentlichen Internet-Routings verringern und klarere Kapazitäts- und Support-Grenzen schaffen, erzeugen aber keine vollständig private Ende-zu-Ende-Welt. Der Kundenzugang kann von Carrier, Cross-Connect und Rechenzentrumsbetreibern abhängen; Cloud-On-Ramps haben eigene Genehmigungs- und Konfigurationsprozesse; die Routenvielfalt und die Eigentumsverhältnisse an den Assets sind nicht an jedem Punkt vollständig offengelegt.

Daher kann CoreWeave nicht als Tier-1-Carrier bezeichnet werden. Das Unternehmen betreibt ein Backbone und nimmt am Peering teil, aber die vorliegenden Belege beweisen weder eine globale Siedlungsfreiheit noch das Eigentum an allen Glasfaserstrecken. Der Vorteil liegt in der tiefen Verbindung mit eigenen Rechenressourcen, nicht darin, das weltweite Telekommunikationsökosystem zu ersetzen.

Regionales Design führt zu unterschiedlicher Verfügbarkeit

Ende 2025 unterhielt CoreWeave Einrichtungen in sechs Ländern. Diese Zahl bedeutet nicht, dass jede Beschleunigergeneration, jedes Fabric, jeder Dienst und jede Leitungskapazität in jedem Land verfügbar ist. Regionen gehen in Phasen in Betrieb, denn die Abnahme von Strom, Kühlung, Netz, Hardware und Betrieb erfolgt nicht alle gleichzeitig.

Geografische Faktoren beeinflussen nicht nur die Latenz, sondern auch Data Governance, Nähe zu anderen Clouds, Personal, Stromquellen, Fehlerkorrelation und die Kontrolle über lokale Pfade. Für CoreWeave fügt jedes weitere Land rechtliche, versorgungstechnische und lieferkettenbezogene Koordinationsaufgaben hinzu. Die Netzexpansion ist ein Betriebsmodell, keine Landkarte gleichförmiger Boxen.

Zuverlässigkeit macht aus Kapital effektive Zeit

Die Finanzierungskosten der CoreWeave-Hardware laufen weiter, ob ein Job arbeitet oder wartet. Daher ist Zuverlässigkeit eine finanzielle Variable. Fabric-Ausfälle, GPU-Degradation, Speicherstillstände oder Planungsfehler verringern den fakturierbaren und effektiven Output, während Zinsen, Leasingraten und Stromverpflichtungen nicht stoppen.

Nachzügler sind schwerer zu handhaben als Totalausfälle

Total ausgefallene Knoten sind einfach zu erkennen, Nachzügler hingegen können weiterhin als online markiert sein, während sie jeden Synchronisationspunkt verlangsamen. Große Jobs benötigen Telemetrie, die Leistungsdegradation erkennt, nicht nur einen binären Gesundheitszustand. Scheduler und Betriebsteam müssen entscheiden, ob eine Komponente entleert, ersetzt oder weitergenutzt wird.

Die öffentlichen Informationen legen keine vollständige Job-Ausfallrate, Tail-Latency oder Nachzügler-Verteilung offen. Das beweist noch keine schlechte Zuverlässigkeit, schränkt aber einen unabhängigen Vergleich ein. Kunden müssen sich auf Verträge, eigene Workload-Tests und ihre operative Evidenz stützen, statt allein aus Architekturbildern Schlüsse zu ziehen.

Qualifikation ist ein Systemtest

Bevor CoreWeave einen Cluster für Kunden freigibt, muss das Unternehmen Server, Switches, Optikmodule, Kabel, Firmware, Treiber, Speicher und Orchestrierung gemeinsam validieren. Dass ein System bootet, reicht nicht; der aussagekräftige Test ist, ob die vollständige Topologie die erwarteten Workloads dauerhaft tragen kann, sich nach einem Fehler erholt und eine Reparatur keine neuen Inkonsistenzen schafft.

Qualifikation verändert sich über die Zeit. Dass eine Software-Firmware-Kombination einmal bestanden hat, heißt nicht, dass sie nach einem Upgrade unverändert funktioniert. Die raschen Generationswechsel bei NVIDIA zwingen CoreWeave, eine wachsende Kombinatorik zu unterstützen, während ältere Vertragsumgebungen weiter bedient werden. Betriebliche Reife zeigt sich darin, unter diesen Überlappungen Einheitlichkeit zu wahren, und nicht darin, jeden Standort zum Sonderfall zu machen.

Finanzierung ist ebenfalls eine Architekturschicht

Der Umsatz von CoreWeave für 2025 betrug 5,1 Milliarden US-Dollar, der Nettoverlust 1,2 Milliarden US-Dollar, die Barausgaben für Sachanlagenkäufe beliefen sich auf 10,3 Milliarden US-Dollar, und die verbleibende Leistungsverpflichtung am Jahresende lag bei 60,7 Milliarden US-Dollar. Dasselbe Dokument legte außerdem umfangreiche Gerätefinanzierungen, Schulden, Leasingverhältnisse und Infrastrukturverpflichtungen offen.

Diese Zahlen haben unterschiedliche Bedeutung. Umsatz ist bestätigter Serviceumsatz; der Cashflow aus Investitionstätigkeit ist eine Ausgabe für Investitionen, keine Bewertung der gesamten Flotte; der Nettoverlust zeigt, dass das hohe Wachstum noch keinen konsolidierten Gewinn abwirft; die verbleibende Leistungsverpflichtung repräsentiert künftige Vertragspflichten nach Rechnungslegungsregeln, nicht Bargeld auf der Bank und auch nicht bereits erbrachte Dienste.

Das erste Quartal 2026 zeigt gleichzeitig Nachfrage und Haltekosten

Für das am 31. März 2026 endende Quartal meldete CoreWeave einen Umsatz von 2,078 Milliarden US-Dollar, einen Nettoverlust von 740 Millionen US-Dollar, Zinsaufwendungen von 536 Millionen US-Dollar und – nach eigener Definition – einen Auftragsbestand von 99,4 Milliarden US-Dollar. Nachfragesichtbarkeit und hohe Finanzierungskosten traten im selben Quartal gemeinsam auf.

Der Auftragsbestand und die verbleibende Leistungsverpflichtung zum Jahresende sind nicht direkt austauschbar; sie unterscheiden sich in Definition und Stichtag. Beide verweisen auf künftige Vertragsnachfrage, aber damit daraus Umsatz wird, muss CoreWeave erst Einrichtungen, Strom, Hardware und Netzwerke in Betrieb nehmen und dann die Verträge erfüllen. Je größer der Auftragsbestand, desto größer die damit verbundenen Lieferverpflichtungen.

GPU-besicherte Finanzierungen verbinden Assets und Verträge

CoreWeave nutzt besicherte Kredite, Gerätefinanzierungen und kundengestützte Strukturen für sein Wachstum. Im Juni 2026 kündigte das Unternehmen eine Finanzierungsvereinbarung über 8,5 Milliarden US-Dollar an und bezeichnete sie als GPU-backed mit Investment-Grade-Rating. Sie vergrößert die Ausbaufähigkeit, ist aber kein Umsatz und bedeutet auch nicht, dass alle Schulden des Unternehmens über ein Investment-Grade-Rating verfügen.

Asset-basierte Finanzierungen können Schulden, Hardware und Vertrags-Cashflows in Einklang bringen, schränken aber auch die Verfügung über Sicherheiten, den Rollout und die Mittelverwendung ein. Beschleuniger, Switches und Optikmodule schreiben schneller ab als klassische Infrastruktur. Das Modell ist am stabilsten, wenn die Auslastung hoch ist und die Kundenverträge den Zeitraum abdecken, in dem die Geräte den größten wirtschaftlichen Wert haben.

Daher beeinflusst das Netzwerkdesign die Kreditqualität. Eine Topologie, die die Auslastung erhöht, steigert den Output der finanzierten Assets; Standortverzögerungen, chronische Nachzügler-Probleme oder Migrationsfehler senken ihn. Für CoreWeave sind System-Engineering und Bilanz-Engineering dasselbe Problem.

Kundenkonzentration ist auch eine Infrastrukturabhängigkeit

Microsoft trug 2025 67 % zum CoreWeave-Umsatz bei. Ein Anker-Kunde kann Nachfrage belegen, Finanzierungen stützen und den Anbieter zu Vorab-Beschaffungen bewegen, aber er stärkt auch die Verhandlungsmacht des Kunden und macht die Auslastung von einer einzigen Geschäftsbeziehung hochgradig abhängig.

CoreWeave hat zudem Beziehungen zu Kunden wie Meta und Anthropic offengelegt oder angekündigt. Flow Traders wählte CoreWeave im Juli 2026 für das Training eines Basismodells; Leidos kündigte eine Zusammenarbeit an, um KI für Verteidigungs-, nationale Sicherheits- und Geheimdienstaufgaben bereitzustellen. Die zugehörigen Quellen belegen die beschriebenen Verträge, Wahlentscheidungen oder Kooperationen, nicht aber, dass die Konzentration verschwunden ist oder alle angekündigten Kapazitäten produktiv sind.

Take-or-pay-Verträge verlagern Risiko, beseitigen es aber nicht

Mehrjährige Take-or-pay-Verträge erhöhen die Nachfragesichtbarkeit und können Finanzierungen stützen. Sie verlagern einen Teil des Auslastungsrisikos auf den Kunden, weil die Zahlung nicht gänzlich vom kurzfristigen Verbrauch abhängt; das Bau-, Strom-, Liefer-, Performance-, Bonitäts- und Neuverhandlungsrisiko bleibt jedoch bestehen.

Für den Kunden kehren solche Verträge einen Teil des Cloud-Versprechens um. Traditionelle Public Clouds betonen Elastizität und geringe Bindung; dedizierte KI-Cluster können dagegen längerfristige, infrastrukturähnliche Beziehungen verlangen, weil der Anbieter für den Kunden konkrete Kapazität aufbaut oder reserviert. Die Schnittstelle wirkt wie Cloud-Software, die zugrunde liegende Ökonomie gleicht eher einer Projektfinanzierung.

Behörden- und regulierte Workloads erhöhen die Sicherheitsanforderung

Die am 30. Juli 2026 angekündigte Leidos-Partnerschaft führt die Plattform an Verteidigungs- und Geheimdienstaufgaben heran. Die Partnerschaft selbst belegt nicht, dass bereits alle Genehmigungen, Zertifizierungen und Einsatzfreigaben vorliegen, aber sie macht deutlich, dass Lieferkettenkontrolle, Auditierung, Informationssicherheit und Betriebskontinuität zu noch wichtigeren Produktbestandteilen werden können.

DPU-erzwungene VPCs, dedizierte Leitungen und gemanagter Betrieb können ein Design mit hohem Sicherheitsanspruch unterstützen, ersetzen aber keine projektspezifischen Kontrollen, Personalforderungen, Datenverarbeitungsvorgaben und Regierungsfreigaben. Je näher die Plattform an missionskritische Workloads rückt, desto transparenter müssen die Verantwortungsgrenzen sein.

Softwarezukäufe strecken sich nach oben, eine gescheiterte Fusion zielt auf die physische Infrastruktur

2025 erwarb CoreWeave Weights & Biases, OpenPipe, marimo und Monolith AI. Weights & Biases erweitert die Modellentwicklung und Beobachtbarkeit, die übrigen Transaktionen stärken Inferenz, Notebooks und industrielle KI. Das bewegt das Unternehmen von der Infrastruktur weiter nach oben in den Entwicklungslebenszyklus.

Die strategische Logik ist klar: Ein Anbieter, der die Modell-Workflows besser versteht, kann die Nachfrage präziser vorhersagen, die Einstiegshürde für die Infrastruktur senken und Kunden an mehr Stellen binden. Die Integrationsrisiken sind ebenso klar: Softwaregeschäfte haben andere Release-Zyklen, Margenprofile und Kulturen als kapitalintensive Rechenzentren. Wenn CoreWeave versucht, Tools zu besitzen, die Kunden zuvor von unabhängigen Anbietern bezogen, kann es zu Produktüberlappungen und Partnerkonflikten kommen.

Die geplante Übernahme von Core Scientific hingegen zielte auf die physische Schicht. CoreWeave kündigte die Fusionsvereinbarung im Juli 2025 an, um die Kontrolle über Rechenzentrumskapazität und Leasing-Ökonomie zu stärken. Core Scientific beendete die Vereinbarung nach einer Aktionärsabstimmung am 30. Oktober 2025. CoreWeave hat Core Scientific nicht erworben.

Beide Arten von Transaktionen zeigen eine bidirektionale Integration: nach oben in die Entwicklersoftware und nach unten in die physische Kapazität. Die gescheiterte Fusion illustriert auch, dass sich Infrastrukturkontrolle nicht immer zum Wunschzeitpunkt einer Technologieplattform kaufen lässt; Aktionäre, Regulierungsbehörden, Finanzierungsstrukturen und Verträge können eine vertikale Integration blockieren.

Was CoreWeave kontrollieren kann – und was nicht

CoreWeave kontrolliert die Kundenplattform, viele Designentscheidungen, die Gerätequalifikation, die Orchestrierung und die Betriebsprozesse. Es kann bestimmen, wie Nimbus VPCs abbildet, wie Cluster präsentiert werden, welche Dienste das Unternehmen managed und wie Störungen behandelt werden; es kann Hardware im Voraus beschaffen und Einrichtungen auf Beschleunigerdichte hin auslegen.

NVIDIA kontrolliert die Roadmap für GPUs, NVLink, InfiniBand, Spectrum‑X und BlueField. Versorgungsunternehmen und Rechenzentrumspartner kontrollieren einen Teil der Strom- und Einrichtungslieferung; Glasfaser-Carrier, Exchanges und Clouds kontrollieren die externe Anbindung; Kreditgeber und Gerätefinanzierer beschränken das Kapital; Großkunden beeinflussen über Verträge die Kapazitätsplanung.

Dies ist kein CoreWeave-spezifischer Mangel, jede Cloud ist von Lieferketten abhängig. Besonders wichtig ist es hier, weil die Differenzierung von CoreWeave eng mit der raschen Einführung neuer NVIDIA-Systeme verknüpft ist und die Kapitalverpflichtungen im Verhältnis zur Unternehmensgeschichte sehr groß sind. Eine Verzögerung oder Roadmap-Änderung bei einem Zulieferer kann sich auf Kundenlieferungen und Finanzierungen durchschlagen.

Die Stärke der Plattform liegt in der Koordination dieser Grenzen; das Risiko liegt in korrelierten Abhängigkeiten: Ein und dieselbe Zulieferproduktgeneration, dasselbe Standortdesign oder derselbe Kundenplan können gleichzeitig mehrere Schichten betreffen. Integration reduziert die Zahl der Verträge, die ein Kunde managen muss, kann aber die Auswirkung eines Ausfalls auf Anbieterebene vergrößern.

Wettbewerbsposition: Die Spezial-Cloud ist eine Wahl der Verantwortungsverteilung

CoreWeave konkurriert mit Hyperscale-Clouds, anderen GPU-Spezial-Clouds, kundeneigenen Clustern sowie Kombinationen aus Colocation, Hosting und Integration. Der Vergleich darf sich nicht nur auf die GPU-Anzahl oder einen einzelnen Benchmark beschränken; Käufer vergleichen Hardwaregenerationen, Fabrics, Speicher, Scheduling, dedizierte Leitungen, Support, Vertragslaufzeiten, Geografie und die Gesamtkosten der Datenbewegung.

Vergleich mit Hyperscale-Clouds

AWS, Microsoft Azure, Google Cloud und Oracle bieten breitere Dienstleistungen, ein globales Ökosystem und größere Bilanzen und können KI-Infrastruktur mit Datenbanken, Sicherheit, Analytics und Unternehmenseinkauf verknüpfen. CoreWeaves Antwort lautet Spezialisierung: neuere NVIDIA-Generationen schneller einzuführen, Bare-Metal-Orchestrierung zu nutzen und die Plattform auf hochdichte Beschleuniger-Workloads auszulegen.

Spezialisierung kann Abstraktion verringern und die Validierung beschleunigen, führt aber auch zu einem engeren Zuliefer- und Fehlerprofil. Der Kunde erhält einen fokussierteren Anbieter und akzeptiert zugleich eine geringere Dienstebreite und eine jüngere Kapitalstruktur. Der richtige Vergleich muss sich auf konkrete Workloads beziehen, nicht auf Branchenetiketten.

Vergleich mit anderen Spezial-Clouds

Anbieter wie Lambda, Nebius und Crusoe überschneiden sich bei Beschleunigern, Clustern und Managed Services, unterscheiden sich aber in Geografie, Energiestrategie, Software-Portfolio, Eigentumsverhältnissen, Finanzierung und Anlagenkontrolle. „Neocloud“ ist ein Markt-Label und keine gemeinsame Architektur.

Die Börsenpublikationen machen die Größe und die Risiken von CoreWeave transparenter als bei vielen Wettbewerbern, beweisen aber keinen automatischen technischen oder wirtschaftlichen Vorteil. Weniger transparente Anbieter können kleiner und effizienter sein – oder einfach nur opaker. Transparenz darf nicht zu einem Performance-Ranking umgedeutet werden.

Vergleich mit eigenen privaten Clustern

Ein eigener Cluster gibt dem Kunden direkte Kontrolle über Hardware, Daten und Betrieb, verlangt aber auch Beschaffung, Strom, Einrichtung, Netzwerk, Speicher, Sicherheit, Firmware, Ersatzteile und Fachpersonal. CoreWeave verkauft die Übertragung des Großteils dieser Verantwortung an den Anbieter.

Die Verlagerung ist nicht vollständig. Der Kunde muss weiterhin Workloads entwerfen, Daten verwalten, Richtlinien setzen und das Anbieterrisiko bewerten; langfristige Bindungen verringern die Migrationselastizität. Das Risiko eines eigenen Clusters ist interne Unterauslastung, das Risiko von Cloud-Verträgen ist Anbieterabhängigkeit. Die wirtschaftliche Wahl lautet, welche Seite Schwankungen besser absorbieren und teure Systeme produktiv halten kann.

Flüssigkeitsgekühlte Switches zeigen, wohin der nächste Engpass wandern könnte

Im Juli 2026 veröffentlichte CoreWeave eine flüssigkeitsgekühlte Switch-Architektur, die nach eigenen Angaben die Netzwerkbandbreite pro Rack erhöht. Die Zahlen stammen aus dem unternehmenseigenen Design und den firmeneigenen Berechnungen, nicht aus einem unabhängigen Flotten-Benchmark, doch der Mechanismus ist bedeutsam: Wenn die Beschleunigerdichte steigt, kann die Leistungsaufnahme und die Abwärme von Switches und Optikmodulen selbst zur Rack-Begrenzung werden.

Die Flüssigkeitskühlung von Switches erlaubt es, bei begrenzter Rack-Leistung und begrenztem Platz mehr Netzwerkkapazität unterzubringen und unter Umständen die Verkabelung zu verkürzen; zugleich wird die Netzwerkinstandhaltung enger mit dem Flüssigkeitskühlsystem gekoppelt. Lecks, Pumpenausfälle oder Wartungsabläufe können dann Komponenten betreffen, die früher als konventionelle luftgekühlte Geräte behandelt wurden.

Dies verdeutlicht, dass Engpässe in der KI-Infrastruktur wandern. Schnellere GPUs brauchen mehr Scale-up-Bandbreite, mehr Rack-Bandbreite braucht dichteres Scale-out-Switching, dichteres Switching steigert Strom- und Kühlbedarf, und neue Einrichtungen müssen mit einer anderen elektromechanischen Auslegung reagieren. Ein einzelner Produktwechsel kann zum vollständigen Redesign eines Rechenzentrums werden.

Vera Rubin ist ein künftiger Übergang, keine Beschreibung der installierten Flotte

CoreWeave-Materialien vom Juli 2026 beschreiben die Vorbereitung auf NVIDIA Vera Rubin NVL72 und nennen Tokens-per-Megawatt-Messungen oder vorausschauende Aussagen im Vergleich zu Blackwell. Diese Aussagen sind CoreWeave und der jeweiligen Konfiguration zuzuordnen und können nicht so behandelt werden, als sei die gesamte Flotte zum Recherchezeitpunkt bereits damit bestückt.

Eine neue Generation verändert gleichzeitig Beschleuniger, Scale-up, Scale-out, Rack-Leistung, Kühlung, Firmware, Treiber, Orchestrierung und Qualifikation. Sie kann den Output pro Megawatt erhöhen, aber auch ältere Einrichtungen unpassend oder wettbewerbsschwächer machen. Dass CoreWeave neue Hardware schnell einführt, ist nur dann ein Vorteil, wenn das Unternehmen die Migration, die Auslastung und die Abschreibung alter Assets beherrscht.

Das vertieft zugleich die NVIDIA-Abhängigkeit. Früher Zugang kann Kunden und hochpreisige Verträge anziehen, setzt CoreWeave aber dem Zeitplan, der Preisgestaltung und den Architekturentscheidungen des Zulieferers aus. Eine Diversifizierung auf Kunden- oder Softwareebene bedeutet nicht automatisch eine Diversifizierung des physischen Stacks.

Auswirkungen auf die breitere digitale Infrastruktur

Die Expansion von CoreWeave reicht weit über die GPU-Vermietung hinaus. Gigawatt-Verpflichtungen treiben die Nachfrage nach Stromerzeugung, Netzanschlüssen, Transformatoren, Kühlung, Grundstücken und Bautätigkeit; hochgradige Fabrics erhöhen den Bedarf an Switches, Optikmodulen und Glasfaser; dedizierte Leitungen steigern die Nachfrage nach Carriern, Exchanges und Cloud-On-Ramps; Finanzierungen verlangen von Kreditgebern, schnell veraltende Technologie-Assets mit Langzeitverträgen zu bewerten.

Die Plattform verändert zudem, an welchen Stellen Internet-Verkehr entsteht. Eng gekoppeltes Training bleibt weitgehend im lokalen Fabric, aber Datensätze, Checkpoints, Modell-Artefakte, Inferenzanfragen und Entwicklungsprozesse bewegen sich kontinuierlich zwischen Clouds, Rechenzentren und Nutzern. Die sichtbare Internet-Wirkung ist vielleicht weniger ein einzelner riesiger Trainingsstrom als vielmehr eine dauerhafte Datenbewegung rund um die Trainingsumgebung.

Für die Gemeinden und Netze, die die Einrichtungen beherbergen, ist dies eine Entscheidung über Strom und Fläche. Das vorliegende Material enthält keine standortgenauen Daten und erlaubt keine unternehmensweiten Umweltaussagen, zeigt aber, dass in Betrieb und zugesicherte Leistung die zentralen Wachstumsindikatoren sind und Verzögerungen bei Strom und Bau als Geschäftsrisiken gelten.

Für Netzwerkingenieure zeigt diese Architektur, dass KI-Infrastruktur zu einer eigenen Disziplin wird. Kenntnisse in Routing und Switching bleiben nötig, doch sie verschmelzen mit kollektiven Kommunikationsbibliotheken, Beschleuniger-Topologien, Flüssigkeitskühlung, Scheduling und Projektfinanzierung. Wer Stau optimiert, schützt gleichzeitig die Job-Erfüllungsquote und die Schuldendienstfähigkeit.

Was die öffentliche Evidenz nicht zeigt

CoreWeave veröffentlicht Produktdokumentation, Technik-Blogs und Finanzberichte, dennoch bleibt der Netzwerk-Stack teilweise intransparent. In den verfügbaren Materialien fehlen eine vollständige Live-Topologie, ein standortgenaues Fabric-Inventar, Überbuchungstabellen, eine Eigentumskarte der Glasfaser, eine vollständige Störungshistorie oder unabhängige, Workload-spezifische Benchmark-Archive.

Diese Grenze muss die Darstellung prägen. Architekturdokumente belegen Mechanismen, SEC-Einreichungen belegen konsolidierte Finanzen und Risiken, Kundenmitteilungen belegen Auswahl oder Zusammenarbeit; keine dieser Quellen beweist allgemeingültige Workload-Ergebnisse, flottenweite Uptime oder niedrigere Gesamtkosten für jeden Käufer.

Dieselbe Vorsicht gilt für die Größenordnung: In Betrieb befindliche Leistung ist nicht gleich zugesicherte Leistung; der Auftragsbestand ist nicht Umsatz; angekündigte Telefonkonferenzen sind keine Ergebnisse; angekündigte Kundenvereinbarungen bedeuten keine tatsächliche Nutzung; geplante Übernahmen begründen kein Eigentum; künftige Hardware ist nicht die heutige Flotte.

Diese Unterscheidungen schwächen den Artikel nicht, sondern definieren die Informationslücken, mit denen ein professioneller Leser umgehen muss. CoreWeave verlangt von Kunden und Kapitalgebern, einem hochintegrierten System zu vertrauen, dessen wesentliche Details notwendigerweise privat bleiben. Die rationale Antwort ist weder blindes Lob noch vorschnelle Verurteilung, sondern die Forderung nach Evidenz auf der Ebene konkreter Verträge, Cluster und Standorte.

Kernbeurteilung

Das Produkt von CoreWeave wird oft als Rechenkapazität beschrieben, das tiefere Produkt ist jedoch die Koordination: zwischen Zulieferer-Roadmap und Rechenzentrumsbau, zwischen Scale-up und Scale-out, zwischen DPU-Richtlinien und Mandantenintentionen, zwischen Kubernetes-Scheduling und physischer Topologie, zwischen Speicher und Checkpoints, zwischen Backbone und Kundenzugang, zwischen langfristiger Finanzierung und kurzen Hardwarezyklen.

Diese Koordination kann echte Vorteile schaffen. Ein spezialisierter Anbieter kann Entscheidungen im Hinblick auf den vollständigen Workload treffen, ohne dass der Kunde mehrere Hersteller selbst kombinieren muss; er kann Systeme schneller validieren, Fehler rascher beheben und neue Generationen früher einführen als viele Unternehmen. Das rasche Wachstum belegt, dass große Kunden diese Verantwortungsverlagerung tatsächlich schätzen.

Dieselbe Integration bündelt aber auch die Konsequenzen. Ein einziges Fabric-Design, eine einzige Zuliefererverzögerung, ein einziger Richtlinienfehler, eine einzige Finanzierungsbeschränkung oder ein Wechsel beim Ankerkunden kann große Teile des Systems beeinträchtigen. CoreWeaves Zukunft hängt nicht von einer auffälligen Bandbreitenzahl ab, sondern davon, ob alle Schichten dauerhaft in der Lage sind, finanzierte Kapazität in verlässliche Kundenarbeit zu verwandeln.