Résumé

  • La pile réseau de CoreWeave couvre les couches scale-up, scale-out, stockage, locataires, gestion, backbone et connectivité privée; c’est une architecture d’exploitation, pas un produit distinct
  • Les fabric NVIDIA et les DPU s’associent au logiciel CoreWeave pour planifier les accélérateurs, isoler les locataires et déplacer les données dans un cloud spécialisé
  • CoreWeave a déclaré 43 centres de données, plus de 850 MW actifs et environ 3,1 GW contractés; Microsoft a fourni 67 % du chiffre d’affaires 2025, ce qui illustre à la fois l’échelle et la concentration
  • L’épreuve consiste à transformer la puissance contractée et le carnet de commandes en service fiable et diversifié avant que les coûts de financement, les baux, l’obsolescence du matériel et la complexité opérationnelle ne s’accumulent

Le parc physique a grandi plus vite qu’une carte de régions cloud ordinaire ne le laisse penser

Au 31 décembre 2025, CoreWeave a déclaré 43 centres de données, plus de 850 MW de puissance active et environ 3,1 GW de puissance contractée. Le chiffre actif décrit l’infrastructure en exploitation selon la définition de l’entreprise à cette date. Le chiffre contracté décrit les droits et engagements pour un déploiement futur. Il ne doit pas être présenté comme une capacité installée.

La progression a été rapide: 10 centres de données et environ 70 MW actifs fin 2023; 32 centres de données et plus de 360 MW fin 2024; 43 centres de données et plus de 850 MW fin 2025. Au premier trimestre 2026, CoreWeave a déclaré plus de 1 GW actif et plus de 3,5 GW contractés. Ces chiffres montrent une entreprise qui tente de faire croître installations et opérations à une vitesse industrielle. Ils montrent aussi à quelle vitesse l’architecture d’hier peut devenir une minorité du parc.

La puissance est une condition préalable, pas un produit fini. Un mégawatt contracté exige encore l’interconnexion, la production ou l’alimentation du réseau, une distribution électrique à haute densité, le refroidissement, la disponibilité des bâtiments, les chemins réseau, la livraison des accélérateurs et l’acceptation opérationnelle. Un retard dans l’une de ces couches peut reporter le chiffre d’affaires alors que certaines obligations commencent plus tôt.

Le modèle de centres de données est mixte. CoreWeave possède des équipements et contrôle d’importants déploiements, mais elle utilise aussi des installations louées et des fournisseurs tiers. Cela peut accélérer l’expansion géographique et éviter de construire chaque coquille. Cela fait aussi de la performance du propriétaire, des calendriers de construction, de la fourniture d’électricité et des conditions contractuelles des éléments de la fiabilité de la plateforme.

Un GPU n’est pas encore un cloud

Un accélérateur placé dans un rack alimenté peut exécuter du code, mais il ne fournit pas à lui seul ce que les clients achètent à un cloud. Une équipe d’entraînement a besoin que de nombreux accélérateurs se comportent comme une seule allocation. Les données doivent arriver du stockage au débit requis. Les opérations collectives doivent traverser les GPU sans que la plus grande partie du travail attende sur la communication. Les locataires doivent rester séparés. Les planificateurs doivent savoir quels nœuds, liens et dispositifs sont sains. Les points de contrôle doivent survivre aux pannes.

Les ingénieurs ont besoin d’une voie vers l’environnement, et les utilisateurs d’une voie vers d’autres clouds, bureaux et services. Un produit cloud ne commence que lorsque ces chemins deviennent reproductibles.

C’est pourquoi le réseau d’un cloud IA ne peut pas être traité comme un accessoire du calcul. Dans une architecture d’entreprise ordinaire, le réseau est souvent décrit comme le système qui relie les serveurs. Dans l’IA distribuée, le réseau participe directement au calcul efficace. Un travail synchrone peut être retardé par une optique dégradée, un accélérateur lent, une voie saturée ou un chemin de stockage qui ne suit pas le rythme. La facture du matériel inactif continue pendant que le travail attend. La conception du réseau n’affecte donc pas seulement les performances de référence, mais l’économie de chaque heure de GPU financée.

La plateforme de CoreWeave est un sujet utile parce qu’elle expose cette relation avec une clarté inhabituelle. L’entreprise se spécialise dans l’infrastructure d’accélérateurs plutôt que de présenter les GPU comme un petit service parmi d’autres dans un cloud généraliste. Ses documents publics décrivent donc les fabric de rack, les unités de traitement de données, l’orchestration bare-metal, les supercalculateurs gérés, la connectivité privée et la réparation opérationnelle avec plus de détails qu’un simple catalogue d’instances. Ces descriptions sont des preuves d’intention de conception et d’architecture produit.

Elles ne constituent pas une carte complète de chaque site, génération ou déploiement client.

Qualifier le réseau de CoreWeave de rapide est trop abstrait pour être utile. La question pertinente est de savoir combien de réseaux distincts doivent coopérer avant qu’une charge de travail d’IA devienne un service fiable—et quelle partie contrôle chacun d’eux.

Ce que nomme exactement la « pile réseau de CoreWeave »

L’expression est un parapluie éditorial, pas une entité juridique ni une référence produit vendue séparément. L’opérateur juridique et économique est CoreWeave, Inc., une société du Delaware dont le siège est à Livingston, dans le New Jersey, cotée au Nasdaq sous le symbole CRWV. La pile réseau s’inscrit dans la plateforme cloud CoreWeave au sens large, qui comprend aussi le calcul, le stockage, l’orchestration et les services gérés.

Plusieurs noms décrivent des couches différentes. Nimbus est l’architecture de réseau virtuel de CoreWeave fondée sur les DPU. CoreWeave Kubernetes Service, ou CKS, fournit du Kubernetes bare-metal géré. SUNK regroupe infrastructure et opérations sous forme de service de supercalculateur géré. Mission Control ajoute la supervision, la réparation et le support du cycle de vie. Direct Connect fournit la connectivité privée des clients. Des noms NVIDIA tels que NVLink, NVSwitch, Quantum, Spectrum-X et BlueField désignent des technologies du fournisseur que CoreWeave intègre plutôt que des inventions dont CoreWeave est propriétaire.

Séparer ces couches évite deux erreurs courantes. La première consiste à attribuer à l’entreprise chaque protocole ou dispositif de la plateforme. La contribution de CoreWeave est l’intégration système, la qualification, les opérations et le logiciel cloud autour de la technologie du fournisseur. La seconde consiste à imaginer un fabric uniforme s’étendant de chaque GPU à chaque client. Les liens locaux scale-up, les fabric d’entraînement entre racks, les réseaux de stockage, les overlays VPC, les chemins de gestion et un backbone transatlantique ont des objectifs, des budgets de latence et des domaines de panne différents.

Ils ne doivent pas être réduits à un seul chiffre de bande passante.

La même discipline s’applique à la propriété. CoreWeave déploie et exploite des équipements importants, mais ses documents décrivent aussi des baux, des centres de données tiers, des engagements de puissance, des relations de fibre et du financement d’équipements. Un service peut être intégré sur le plan opérationnel sans que l’entreprise possède le bâtiment, le service public, l’itinéraire longue distance ou chaque composant du rack. « Verticalement intégré » n’est utile que s’il signifie un contrôle coordonné sur de nombreuses couches, et non une autosuffisance totale.

D’Atlantic Crypto au calcul spécialisé

CoreWeave a commencé en 2017 sous le nom de The Atlantic Crypto Corporation. Son activité initiale utilisait des actifs GPU pour des charges de travail de cryptomonnaie, et l’entreprise est passée d’une LLC à une société du Delaware en septembre 2018. Elle a adopté le nom CoreWeave en décembre 2019 en se tournant vers le calcul cloud spécialisé.

L’origine est parfois réduite à un contraste amusant entre minage de cryptomonnaies et intelligence artificielle. La continuité la plus importante est opérationnelle. Les deux activités exigent qu’un propriétaire acquière des accélérateurs, sécurise l’électricité, maintienne un matériel dense en fonctionnement et oriente les charges vers la capacité sous-utilisée. La jeune entreprise a appris l’économie d’une flotte d’accélérateurs avant d’avoir construit les systèmes de location, de réseau, de stockage et de support d’un cloud.

Cette distinction importe parce qu’un changement de demande ne produit pas automatiquement une plateforme. Les charges de minage peuvent être comparativement répétitives et tolérer un modèle d’actifs simple. Les effets visuels, l’apprentissage automatique et le calcul haute performance exigent des logiciels, des mouvements de données, une isolation et des garanties de service différents. CoreWeave a dû ajouter les couches qui permettent à des clients externes de faire confiance à des ressources qu’ils ne possèdent pas et ne peuvent pas inspecter physiquement.

Au début des années 2020, l’entreprise a développé des services spécialisés de calcul, de stockage et Kubernetes. Le Kubernetes bare-metal est devenu une interface importante: les clients pouvaient planifier directement des travaux conteneurisés sur des serveurs d’accélérateurs sans passer d’abord par une couche de machines virtuelles classique. Fin 2023, CoreWeave déclarait 10 centres de données et environ 70 MW de puissance active. Fin 2024, elle déclarait 32 centres de données et plus de 360 MW.

L’expansion a changé la nature du problème réseau. Un opérateur de dix sites peut encore s’appuyer beaucoup sur la connaissance experte et les exceptions locales. Un cloud de trente ou quarante sites a besoin de conceptions reproductibles, d’une politique contrôlée par logiciel, d’une qualification commune, d’une supervision partagée et d’un moyen de faire passer les clients d’une génération de matériel à l’autre sans perdre la cohérence opérationnelle.

L’échelle transforme les bons choix d’ingénierie en questions de gouvernance: qui peut approuver un changement, à quelle vitesse les exceptions sont détectées, et si chaque nouveau site reproduit les frontières de contrôle prévues.

CoreWeave a réalisé son introduction en bourse en mars 2025. L’introduction a fait plus qu’ajouter des capitaux propres. Elle a produit des preuves dans le prospectus et auprès de la SEC sur les installations, la concentration de la clientèle, la dette, les baux, l’architecture d’interconnexion et le risque. Ce dossier permet d’étudier la pile réseau à la fois comme système technique et comme engagement d’entreprise cotée.

La charge de travail qui détermine l’architecture

L’entraînement de grands modèles répartit le calcul entre accélérateurs et échange à plusieurs reprises des résultats partiels. Le schéma de communication exact dépend de l’architecture du modèle, de la méthode de parallélisation et du logiciel, mais le problème d’infrastructure est stable: la vitesse utile de l’allocation dépend de la communication collective autant que du calcul local. Un fabric qui semble rapide en agrégat peut encore gaspiller de la capacité si la congestion, la topologie ou la latence de queue ralentit les points de synchronisation qui maintiennent le travail ensemble.

La pile doit aussi servir un trafic qui ne se comporte pas comme une opération collective. Les ensembles de données entrent dans l’environnement. Les points de contrôle quittent la mémoire GPU et atterrissent dans le stockage. Les systèmes de contrôle distribuent les travaux et les politiques. Les ingénieurs récupèrent les journaux. Les services exposent des points de terminaison d’inférence. Les sauvegardes et les réplicas peuvent traverser les régions. Chaque classe a une tolérance différente au délai et à la perte.

Traiter tout cela comme un seul réseau indifférencié rendrait la performance difficile à prévoir et les pannes difficiles à isoler.

Ceci produit une conception en couches. Les liens scale-up créent un domaine étroitement couplé à l’intérieur d’un système à l’échelle du rack. Les fabric scale-out relient de nombreux systèmes entre racks. Les chemins de stockage alimentent et persistent la charge de travail. Un réseau locataire donne aux clients un adressage privé et une politique. Un réseau de gestion donne à l’opérateur le contrôle des hôtes, DPU, commutateurs et flux de réparation. Un backbone relie les installations et les écosystèmes externes. Des circuits privés clients connectent le cloud à d’autres domaines administratifs.

Les couches interagissent, mais elles ne sont pas interchangeables. La fibre longue distance ne peut pas remplacer un fabric GPU local car le délai de propagation rend à lui seul l’entraînement étroitement synchronisé entre sites distants difficile. Un domaine NVLink ne peut pas servir de VPC client. Un overlay peut masquer les différences d’adressage mais ne peut pas réparer une optique défaillante dans l’underlay. Kubernetes peut planifier un pod sans comprendre chaque rail physique, sauf si la plateforme fournit des informations de topologie et des intégrations de dispositifs.

L’architecture est donc une chaîne d’intentions traduites. Un client demande un cluster, un espace de noms, un réseau ou un travail. Les systèmes de contrôle de CoreWeave mappent cette demande sur les serveurs, le fabric, le stockage et la politique disponibles. Nimbus mappe l’intention VPC sur l’état DPU et underlay. Kubernetes et les services liés à Slurm mappent l’intention de charge sur les nœuds et accélérateurs. Mission Control mappe les signaux de santé sur des actions de réparation. Le client voit un service; la plateforme doit maintenir la cohérence des traductions.

Le réseau scale-up dans le domaine à l’échelle du rack

Le réseau scale-up connecte les accélérateurs à l’intérieur d’un système étroitement intégré. Dans les conceptions rack-scale de NVIDIA, NVLink fournit une communication GPU-GPU à haute bande passante et NVSwitch assure la commutation dans ce domaine local. CoreWeave intègre ces technologies dans certains systèmes et générations sélectionnés.

La propriété importante n’est pas une marque mais la proximité. Un domaine scale-up permet aux partitions de modèle et aux opérations collectives d’échanger des données sans traverser le fabric ordinaire du centre de données à chaque étape. Cela peut faire ressembler un rack à un grand système d’accélérateurs plutôt qu’à une collection de serveurs indépendants. Cela crée aussi un domaine de panne distinct: un commutateur, un câble, un problème de refroidissement ou un défaut de composant à l’intérieur du rack peut affecter de nombreux GPU que le planificateur attendait pour fonctionner ensemble.

Le prospectus de CoreWeave décrivait des configurations de cluster sélectionnées avec une bande passante d’interconnexion GPU sans blocage atteignant jusqu’à 3 200 gigabits par seconde. L’expression « configurations de cluster sélectionnées » porte l’essentiel du poids probant. Elle n’établit pas un niveau de service universel et ne doit pas être utilisée pour décrire chaque site ou génération d’accélérateurs. La bande passante effective disponible pour une charge dépend aussi du logiciel, de la topologie, du schéma de messages et de la santé du chemin complet.

La conception scale-up rétrécit un goulot d’étranglement tout en augmentant la densité ailleurs. Plus d’accélérateurs et plus de bande passante locale accroissent les exigences de puissance, de refroidissement et de maintenabilité du rack. Un système qui concentre le calcul sans conception thermique et opérationnelle correspondante peut être plus difficile à réparer ou déplacer le goulot vers les liens scale-out et le stockage. L’architecture doit être lue comme un équilibre entre composants, pas une séquence de spécifications maximales.

Les fabric scale-out: InfiniBand et Ethernet sont tous deux présents

Dès qu’un travail franchit la limite scale-up, il entre dans un fabric scale-out. Les documents publics et techniques de CoreWeave décrivent l’InfiniBand NVIDIA Quantum-2, le fabric Quantum-X800 XDR 800 Gbit/s et le Spectrum-X Ethernet utilisant RoCE et RDMA. La présence d’InfiniBand et d’Ethernet est significative: l’entreprise ne réduit pas l’identité de sa plateforme à une seule famille de protocoles.

InfiniBand pour les clusters étroitement couplés

InfiniBand est construit autour d’une communication à faible latence orientée mémoire directe à distance et a une longue histoire dans le calcul haute performance. Dans un cluster IA, il peut déplacer des données entre hôtes d’accélérateurs en évitant une partie des frais généraux de traitement hôte. Les systèmes Quantum de NVIDIA ajoutent des capacités de commutation et d’opérations collectives adaptées aux grands travaux synchrones. CoreWeave intègre ces fabric dans des offres de cluster plutôt que de vendre InfiniBand comme service de transport séparé.

Les preuves publiques ne divulguent pas chaque topologie, taux de sursouscription, politique de routage ou limite de service. « Sans blocage » peut décrire une conception particulière, pas toute la flotte. Même un fabric bien conçu peut souffrir d’optiques dégradées, d’un mauvais placement, d’un trafic inégal ou d’un comportement logiciel créant des points chauds. Les acheteurs devraient donc demander quelle génération matérielle, quelle topologie et quelle qualification s’appliquent au cluster qu’ils reçoivent.

Spectrum-X et RoCE comme chemin Ethernet

Spectrum-X est la plateforme réseau IA orientée Ethernet de NVIDIA. RoCE transporte la sémantique RDMA sur Ethernet, permettant aux applications d’utiliser la communication en mémoire directe tandis que l’opérateur conserve un fabric Ethernet. L’utilisation de Spectrum-X par CoreWeave donne à la plateforme un chemin scale-out alternatif pour les charges et générations de systèmes conçus autour de cet écosystème.

La familiarité avec Ethernet ne doit pas être confondue avec une exploitation sans effort. La performance de RoCE dépend du contrôle de congestion, de la conception des files d’attente, du comportement de perte, de la télémétrie et de la configuration de bout en bout. Un réseau peut utiliser des trames Ethernet familières et exiger quand même une ingénierie spécialisée pour éviter le blocage de tête de ligne, l’incast ou une performance collective instable. La valeur d’un cloud intégré est que le fournisseur assume une grande partie de ce réglage. Le risque correspondant est que le client ait moins de visibilité directe sur les choix.

Topologie optimisée par rails et placement

Les systèmes multi-rails regroupent les interfaces réseau et accélérateurs correspondants afin que le trafic collectif suive des chemins parallèles réguliers. Une conception optimisée par rails peut réduire les traversées inutiles et rendre la bande passante plus prévisible. Elle exige aussi que le planificateur comprenne la topologie: placer un travail sur la mauvaise combinaison de nœuds peut contrecarrer la conception physique.

Les rails peuvent concentrer les pannes. Si un rail se dégrade, chaque nœud utilisant ce chemin peut devenir un traînard même si les autres interfaces restent saines. Le système opérationnel doit détecter la différence entre un serveur en panne et une dégradation réseau partagée. C’est une raison pour laquelle la télémétrie, la qualification et la réparation conscientes de la topologie comptent autant que la vitesse brute des ports.

Nimbus déplace la frontière du cloud sur le DPU

Un fabric de cluster haute performance ne crée pas à lui seul un cloud multi-locataires. Les clients ont besoin d’adresses privées, de contrôle de routage, d’accès Internet et d’isolation vis-à-vis des autres clients. La réponse de CoreWeave est Nimbus, une architecture de réseau virtuel qui décharge les fonctions VPC vers des unités de traitement de données. La documentation publique identifie les DPU NVIDIA BlueField-3 et décrit les VRF, VXLAN et routes EVPN Type 5 dans l’architecture de sécurité.

Le DPU occupe une position privilégiée entre le calcul contrôlé par le client et l’infrastructure contrôlée par le fournisseur. Il peut traiter le trafic de réseau virtuel, appliquer la segmentation et réserver les ressources CPU de l’hôte pour la charge. Il peut aussi maintenir une frontière de location en dehors du système d’exploitation que le client peut contrôler. Cette séparation est à la fois une décision de performance et de sécurité.

Comment l’overlay VPC est assemblé

Une instance de routage et de transfert virtuel sépare un domaine de routage d’un autre. VXLAN transporte les segments locataires sur un underlay physique partagé. EVPN distribue la joignabilité, et les routes Type 5 peuvent annoncer des préfixes IP plutôt que seulement des adresses MAC individuelles. Ensemble, ces mécanismes permettent à CoreWeave de présenter un réseau privé tout en utilisant une infrastructure physique commune en dessous.

L’overlay n’élimine pas la dépendance à l’underlay. Si la joignabilité physique échoue, le réseau virtuel échoue avec elle. Si la distribution des routes est erronée, l’isolation ou la joignabilité peut se rompre à grande échelle. Si une image DPU ou un système de politique contient une erreur, de nombreux hôtes peuvent recevoir rapidement le même mauvais état. L’abstraction cloud réduit la complexité du client en la déplaçant dans l’infrastructure du fournisseur; elle ne supprime pas la complexité.

Le DPU fait partie de la base de confiance

Nimbus réduit l’exposition des fonctions réseau du fournisseur à l’hôte client, mais il augmente l’importance du firmware DPU, du démarrage sécurisé, des clés, de la distribution des politiques, des journaux et de la récupération. Un dispositif qui applique l’isolation doit être observable et corrigible sans devenir un chemin incontrôlé vers l’environnement locataire.

Cette frontière de contrôle affecte aussi la gestion des incidents. Une panne de connectivité peut provenir de la charge client, de la politique Kubernetes, de la configuration VPC, du logiciel DPU, du plan de contrôle EVPN ou du fabric physique. Les équipes de support ont besoin de preuves qui traversent ces couches sans donner à un locataire la visibilité sur un autre. La documentation publique explique l’architecture prévue, mais elle ne publie pas de registre indépendant à l’échelle de la flotte des pannes d’isolation ou des délais de réparation.

Kubernetes bare-metal comme surface de contrôle client

CoreWeave Kubernetes Service fournit du Kubernetes géré sur infrastructure bare-metal. La conception évite une couche classique de machine virtuelle d’abord entre la plateforme de conteneurs et les serveurs GPU. Chaque cluster reçoit son propre VPC, et le service intègre le réseau et le stockage haute performance pour les charges distribuées.

Le bare-metal réduit une couche d’abstraction, mais il ne rend pas le système simple. Kubernetes doit découvrir les GPU, exposer les dispositifs, appliquer les quotas, placer les pods et interagir avec les plugins réseau et stockage. La plateforme doit coordonner les images de nœuds, pilotes, firmware, runtimes de conteneurs et mises à niveau de cluster avec la génération matérielle sous-jacente. Un client gagne une API familière tandis que CoreWeave hérite d’une matrice de compatibilité exigeante.

Ce que Kubernetes peut décider—et ce qu’il ne peut pas

Kubernetes peut décider où un pod doit s’exécuter selon les informations et politiques disponibles pour le planificateur. Il ne connaît pas automatiquement chaque rail, optique, chemin de commutateur ou condition de performance collective. CoreWeave doit ajouter des plugins de dispositifs, des opérateurs, des informations de topologie et des contrôles opérationnels pour qu’une décision logique de planification corresponde à une allocation physique viable.

La politique réseau est également limitée. Les politiques Kubernetes peuvent restreindre le trafic autorisé entre charges, tandis que les contrôles VPC et DPU fournissent des frontières plus larges de location et de routage. Un objet de politique n’est pas une preuve que le chemin de paquets applique la règle prévue. Configuration, implémentation et observation doivent concorder.

SUNK transforme un cluster en supercalculateur géré

SUNK est positionné comme une offre de supercalculateur géré en production. Il combine infrastructure, fabric haute performance, orchestration des charges et opérations CoreWeave pour les clients qui veulent un grand environnement dédié sans construire eux-mêmes l’installation complète ni l’équipe d’exploitation.

Le service modifie la répartition des responsabilités. Un client garde l’architecture du modèle, le code, les données et la stratégie de travaux, mais une plus grande partie du cycle de vie du matériel, de la qualification des clusters et de la réponse aux incidents passe à CoreWeave. Le résultat ressemble à une installation HPC gérée livrée via des contrats et des logiciels de l’ère cloud plutôt qu’à un pool ordinaire d’instances interchangeables.

Mission Control fait des opérations une partie du produit

Mission Control ajoute supervision, maintenance, réparation et support du cycle de vie. Son importance est plus facile à voir quand un travail est grand. Remplacer un composant défectueux dans un petit pool de serveurs peut avoir une conséquence limitée; diagnostiquer un lien dégradé dans une allocation étroitement synchronisée peut déterminer si des milliers d’heures d’accélérateur sont utiles ou gaspillées.

Les documents de service de CoreWeave décrivent une supervision proactive et une intervention opérationnelle. Cela établit le modèle prévu, pas une disponibilité vérifiée de manière indépendante ni une distribution publique du temps moyen de réparation. L’absence d’un recensement complet des incidents est importante car la fiabilité est l’une des principales raisons pour lesquelles les clients paient un fournisseur plutôt que de construire eux-mêmes le cluster.

Le stockage fait partie du calcul en réseau

Les données d’entraînement, les points de contrôle et les artefacts de modèle circulent à travers des chemins de stockage qui peuvent contraindre la charge complète. Un cluster avec une bande passante GPU-GPU exceptionnelle peut encore caler s’il ne peut pas lire les entrées, écrire les points de contrôle ou récupérer l’état assez vite. La plateforme CoreWeave inclut un stockage objet et fichier et décrit le mouvement de données haute performance comme faisant partie du service.

Le trafic de points de contrôle crée un schéma opérationnel particulier. De nombreux workers peuvent avoir besoin de persister l’état à intervalles coordonnés. Cela peut produire des rafales dont le calendrier diffère de la communication collective. Si le trafic de stockage partage des ressources physiques avec le fabric d’entraînement, la conception a besoin d’isolation ou de planification de capacité. S’il utilise un réseau séparé, la plateforme doit encore coordonner la panne et la récupération sur les deux chemins.

Le stockage affecte aussi la portabilité. Déplacer un modèle vers CoreWeave peut exiger d’importants transferts entrants depuis un autre cloud ou un environnement privé. Le déplacer vers l’extérieur peut créer des coûts, du temps et des frictions contractuelles. « Zero Egress Migration » est le mécanisme commercial de CoreWeave pour réduire certains coûts de migration vers sa plateforme; il ne doit pas être confondu avec une garantie technique, une sortie gratuite universelle ou une preuve que le mouvement de données n’a aucun coût opérationnel.

Un client qui évalue la pile devrait donc demander des preuves de bout en bout. Les résultats de pointe des accélérateurs et du fabric sont utiles, mais la charge de production inclut la préparation des ensembles de données, les points de contrôle, l’activité du registre de modèles, les journaux et la récupération. Un benchmark qui isole une seule couche ne peut pas répondre à la question économique de la vitesse d’exécution complète du travail.

Le backbone relie les régions, pas un supercalculateur synchrone unique

CoreWeave décrit un backbone de qualité opérateur reliant des centres de données en Amérique du Nord et en Europe sur de la fibre terrestre et sous-marine, avec un peering direct et des services de connectivité privée. Le dossier de l’entreprise liste des options Direct Connect à 10, 100 et 400 Gbit/s, selon le lieu et la disponibilité.

Le backbone sert un objectif différent du fabric scale-out local. Il peut déplacer des ensembles de données, réplicas, points de contrôle, trafic de contrôle et trafic d’inférence entre régions. Il peut connecter les utilisateurs et d’autres clouds. Il peut soutenir la récupération et la distribution. Le délai de propagation longue distance signifie qu’il ne transforme pas des installations distantes en un seul fabric d’entraînement à faible latence pour les travaux étroitement couplés.

La connectivité privée réduit un type d’incertitude

Un circuit dédié peut éviter une partie de la variabilité de routage de l’Internet public et fournir une frontière de capacité et de support plus claire. Il ne crée pas un monde de bout en bout entièrement privé. L’accès client peut dépendre d’un opérateur, d’un cross-connect et d’un exploitant de centre de données. Les on-ramps cloud ont leur propre acceptation et configuration. La diversité des routes et la propriété physique ne sont pas entièrement divulguées pour chaque site.

CoreWeave ne doit donc pas être décrite comme un opérateur de niveau 1. Elle exploite un backbone et fait du peering, mais les preuves fournies n’établissent pas une joignabilité mondiale sans règlement ni la propriété de chaque chemin de fibre. Son avantage est un accès intégré à son propre parc de calcul, pas le remplacement de l’écosystème mondial des opérateurs.

La conception régionale crée des choix de disponibilité

CoreWeave a déclaré des installations dans six pays fin 2025. Un nombre d’installations ne signifie pas que chaque génération d’accélérateurs, fabric, service ou vitesse de connectivité privée est disponible dans chaque pays. Les régions s’ouvrent par étapes parce que la puissance, le refroidissement, le réseau, le matériel et la préparation opérationnelle n’arrivent pas au même instant.

Pour les clients, la géographie affecte plus que la latence. Elle affecte la gouvernance des données, la proximité cloud, les effectifs, la source d’électricité, la corrélation des pannes et le partenaire qui contrôle le chemin local. Pour CoreWeave, chaque nouveau pays ajoute une coordination juridique, de services publics et de chaîne d’approvisionnement en plus de la capacité. L’expansion géographique du réseau est donc un modèle d’exploitation, pas une carte de boîtes identiques.

La fiabilité est la conversion du capital en temps utile

Le matériel de CoreWeave reste financé qu’un travail progresse ou attende. La fiabilité est par conséquent une variable financière. Un défaut de fabric, un GPU dégradé, un blocage de stockage ou une erreur de planificateur peut réduire la production facturable et utile tandis que les intérêts, les baux et les obligations d’électricité continuent.

Les traînards comptent plus que les pannes complètes

Un nœud en panne est visible. Un traînard peut rester techniquement vivant tout en ralentissant chaque point de synchronisation. Les grands travaux ont donc besoin d’une télémétrie capable de détecter une performance dégradée, pas seulement une santé binaire. Le planificateur et l’équipe d’exploitation doivent décider s’il faut drainer, remplacer ou continuer à utiliser le composant.

Le dossier public ne fournit pas une distribution complète des pannes de travaux, de la latence de queue ou de l’incidence des traînards. Cette absence ne prouve pas une mauvaise fiabilité, mais elle limite la comparaison indépendante. Les clients doivent s’appuyer sur les contrats, les tests de charge et leurs propres preuves opérationnelles plutôt que d’extrapoler à partir de diagrammes d’architecture.

La qualification est un test système

Avant d’exposer un cluster, CoreWeave doit qualifier ensemble serveurs, commutateurs, optiques, câbles, firmware, pilotes, stockage et orchestration. Réussir un test de démarrage est insuffisant. Le test utile est de savoir si la topologie complète soutient la charge prévue, survit aux pannes et peut être réparée sans créer de nouvelle incohérence.

La qualification a aussi une dimension temporelle. Une conception qui fonctionnait avec un ensemble logiciel et firmware peut se comporter différemment après une mise à niveau. L’introduction rapide de nouvelles générations NVIDIA augmente le nombre de combinaisons que CoreWeave doit supporter pendant que des environnements contractés plus anciens restent en service. La maturité opérationnelle est la capacité à gérer ce chevauchement sans transformer chaque site en exception unique.

La finance est une couche de l’architecture

CoreWeave a déclaré 5,1 milliards de dollars de chiffre d’affaires pour 2025 et une perte nette de 1,2 milliard de dollars. Elle a payé 10,3 milliards de dollars en espèces pour des biens et équipements au cours de l’année. Fin d’année, les obligations de performance restantes étaient de 60,7 milliards de dollars. Le même dossier décrivait d’importants engagements de financement d’équipements, de dette, de location et d’infrastructure.

Ces chiffres décrivent des choses différentes. Le chiffre d’affaires est le revenu de service comptabilisé. L’argent payé pour les biens et équipements est un flux d’investissement sortant, pas une valorisation de toute la flotte installée. Une perte nette montre que la croissance n’a pas encore produit de rentabilité consolidée. Les obligations de performance restantes représentent des performances futures contractées selon les règles comptables, pas de l’argent en banque ni un service déjà livré.

Le premier trimestre 2026 a montré la demande et le coût de portage ensemble

Pour le trimestre clos le 31 mars 2026, CoreWeave a déclaré 2,078 milliards de dollars de chiffre d’affaires, une perte nette de 740 millions de dollars et 536 millions de dollars de charges d’intérêts. Elle a aussi déclaré un carnet de commandes de 99,4 milliards de dollars selon sa définition. Les résultats démontrent une forte visibilité de la demande et une lourde charge de financement sur la même période.

Le carnet de commandes n’est pas directement interchangeable avec les obligations de performance restantes de fin d’année. Les définitions et le calendrier diffèrent. Les deux indiquent une demande future contractée, mais la conversion dépend de la capacité de CoreWeave à mettre en service installations, puissance, matériel et capacité réseau, puis à satisfaire les contrats. Plus le carnet est impressionnant, plus l’obligation de livraison qui y est attachée est grande.

Le financement adossé aux GPU aligne les actifs et les contrats

CoreWeave a utilisé des prêts garantis, du financement d’équipements et des structures adossées à des clients pour financer l’expansion. En juin 2026, elle a annoncé une facilité de financement de 8,5 milliards de dollars décrite comme adossée aux GPU et notée investment grade pour la transaction nommée. La facilité élargit la capacité de déploiement; ce n’est pas du chiffre d’affaires et cela n’établit pas une note investment grade pour chaque obligation de l’entreprise.

Le financement adossé à des actifs peut aligner la dette sur le matériel et les flux de trésorerie contractés. Il peut aussi créer des restrictions sur les garanties, le déploiement et l’utilisation de la trésorerie. Les accélérateurs, commutateurs et optiques vieillissent rapidement par rapport à de nombreux actifs d’infrastructure traditionnels. Le modèle de financement fonctionne le mieux lorsque l’utilisation reste élevée et que les contrats clients durent plus longtemps que la période où l’équipement est le plus précieux économiquement.

La conception du réseau affecte donc la qualité du crédit. Une topologie qui génère une meilleure utilisation améliore la production productive des actifs financés. Un site retardé, un problème persistant de traînards ou une migration ratée peut la réduire. Dans le modèle de CoreWeave, l’ingénierie système et l’ingénierie de bilan ne sont pas deux histoires séparées.

La concentration des clients est aussi une dépendance d’infrastructure

Microsoft a représenté 67 % du chiffre d’affaires 2025 de CoreWeave. Un grand client d’ancrage peut justifier la capacité, soutenir le financement et donner au fournisseur la confiance d’acheter l’équipement tôt. La même concentration donne au client un pouvoir de négociation et rend l’utilisation sensible à une seule relation commerciale.

CoreWeave a annoncé ou rapporté des relations avec d’autres clients, notamment Meta et Anthropic, tandis que Flow Traders a choisi l’entreprise pour l’entraînement de modèles fondation en juillet 2026 et Leidos a annoncé une collaboration pour l’IA de défense, de sécurité nationale et de renseignement. Ces déclarations établissent des contrats, des sélections ou des collaborations au niveau décrit par les sources. Elles ne prouvent pas que la concentration a disparu ni que chaque capacité annoncée est déjà déployée.

Les contrats take-or-pay transfèrent le risque sans l’éliminer

Les contrats take-or-pay pluriannuels peuvent donner à CoreWeave une visibilité sur la demande et soutenir le financement. Ils transfèrent une partie du risque d’utilisation du fournisseur au client parce que les paiements engagés ne reposent pas uniquement sur la consommation à court terme. Ils ne suppriment pas le risque de construction, de puissance, de livraison, de performance, de crédit ou de renégociation.

Pour les clients, le contrat inverse une partie de la promesse du cloud. Le cloud public traditionnel met l’accent sur la consommation élastique et l’engagement limité. Un cluster IA dédié peut exiger une relation plus longue, plus proche de l’infrastructure, parce que le fournisseur a construit ou réservé une capacité spécifique. Le service peut ressembler à un logiciel cloud à l’interface tout en se comportant comme un financement de projet en dessous.

Le travail de défense et réglementé relève le seuil d’assurance

La collaboration avec Leidos du 30 juillet 2026 étend la plateforme vers des missions de défense et de renseignement. Une telle collaboration n’établit pas chaque autorisation, certification ou déploiement requis pour un travail réglementé. Elle indique que la sécurité, le contrôle de la chaîne d’approvisionnement, l’auditabilité et la continuité opérationnelle peuvent devenir des parties plus importantes du produit CoreWeave.

Un VPC appliqué par DPU, une connectivité privée et des opérations gérées peuvent soutenir une conception haute assurance. Ils ne remplacent pas les contrôles spécifiques au programme, les exigences de personnel, le traitement des données et l’approbation du gouvernement. Plus l’entreprise se rapproche de charges sensibles à la mission, plus ses frontières de responsabilité doivent être transparentes.

Les acquisitions déplacent la pile vers le haut tandis que la fusion ratée pointait vers le bas

Au cours de 2025, CoreWeave a acquis Weights & Biases, OpenPipe, marimo et Monolith AI. Weights & Biases a ajouté des outils de développement de modèles et d’observabilité; les autres acquisitions ont élargi les capacités d’inférence, de notebook et d’IA industrielle. Ces transactions déplacent CoreWeave au-dessus de l’infrastructure brute, plus loin dans le cycle de vie du développement.

La logique stratégique est claire. Un fournisseur qui comprend les workflows de modèles peut améliorer la prévision de la demande, rendre l’infrastructure plus facile à consommer et retenir les clients sur plus d’étapes du développement. Le risque d’intégration est tout aussi clair. Les entreprises logicielles ont des cycles de publication, des marges et des cultures différents des opérations de centres de données financées. Un chevauchement de produits et des conflits de partenaires peuvent apparaître si CoreWeave essaie de posséder des outils que les clients obtenaient auparavant de fournisseurs indépendants.

L’acquisition proposée de Core Scientific pointait dans l’autre direction. CoreWeave a annoncé un accord de fusion en juillet 2025 qui aurait accru son contrôle sur la capacité des centres de données et l’économie des baux. Core Scientific a résilié l’accord le 30 octobre 2025 après le vote de ses actionnaires. CoreWeave n’a pas acquis l’entreprise.

Ensemble, les transactions révèlent une stratégie d’intégration à double sens: monter vers le logiciel pour développeurs et descendre vers la capacité physique. La fusion ratée montre aussi que le contrôle de l’infrastructure ne peut pas toujours être acheté au calendrier voulu par la plateforme. Les actionnaires, les régulateurs, le financement et la structure contractuelle peuvent bloquer la logique technique de l’intégration verticale.

Ce que CoreWeave contrôle—et ce qui reste hors de sa frontière

CoreWeave contrôle la plateforme client, de nombreux choix de conception, la qualification des équipements, l’orchestration et les processus d’exploitation. Elle peut choisir comment Nimbus mappe les VPC, comment les clusters sont présentés, quels services sont gérés et comment les incidents sont traités. Elle peut acheter du matériel tôt et organiser les installations autour de la densité d’accélérateurs.

NVIDIA contrôle les feuilles de route critiques des GPU, NVLink, InfiniBand, Spectrum-X et BlueField. Les services publics et partenaires de centres de données contrôlent une partie de la puissance et de la livraison des installations. Les opérateurs de fibre, les bourses et les fournisseurs cloud contrôlent une partie de la connectivité externe. Les prêteurs et financiers d’équipements contraignent l’utilisation du capital. Les grands clients influencent la planification de la capacité par les contrats.

Ce n’est pas un défaut propre à CoreWeave. Chaque cloud dépend de fournisseurs et d’installations. La concentration est importante parce que la différenciation de CoreWeave est étroitement liée au déploiement rapide des systèmes NVIDIA et parce que ses engagements de capital sont inhabituellement importants par rapport à son historique d’exploitation. Un retard ou un changement de feuille de route chez un fournisseur peut se propager à la livraison client et au financement.

La force de la plateforme est la coordination à travers ces frontières. Son risque est la dépendance corrélée: la même génération de fournisseur, la même conception de site ou le même programme client peut affecter plusieurs couches à la fois. L’intégration réduit le nombre de contrats qu’un client doit gérer, mais elle peut augmenter l’impact d’une panne au niveau du fournisseur de services.

Position concurrentielle: un cloud spécialisé est un choix de responsabilité

CoreWeave concurrence les cloud hyperscale, d’autres clouds GPU spécialisés, les clusters appartenant aux clients et des combinaisons de colocation, d’hébergement et d’intégration gérée. La comparaison ne peut pas être réduite au nombre de GPU ou à un benchmark. Les acheteurs comparent la génération matérielle disponible, le fabric, le stockage, la planification, la connectivité privée, le support, la durée du contrat, la géographie et le coût total du mouvement de données.

Face aux cloud hyperscale

AWS, Microsoft Azure, Google Cloud et Oracle offrent de vastes portefeuilles de services, des écosystèmes mondiaux et de grands bilans. Ils peuvent combiner l’infrastructure IA avec des bases de données, la sécurité, l’analytique et des achats d’entreprise déjà utilisés par les clients. La contre-position de CoreWeave est la spécialisation: intégration plus rapide de générations NVIDIA sélectionnées, orchestration bare-metal et plateforme conçue autour de charges d’accélérateurs à haute densité.

La spécialisation peut réduire l’abstraction et raccourcir la qualification. Elle peut aussi créer un profil de pannes et de fournisseurs plus étroit. Un client qui choisit CoreWeave peut gagner un fournisseur concentré sur la charge tout en acceptant moins d’étendue de services et une structure de capital plus jeune. La bonne comparaison est spécifique à la charge, pas catégorique.

Face aux autres clouds spécialisés

Lambda, Nebius, Crusoe et d’autres fournisseurs d’infrastructure IA se chevauchent dans l’approvisionnement en accélérateurs, les clusters et les services gérés. Leurs différences incluent la géographie, la stratégie énergétique, le portefeuille logiciel, la propriété, la structure de capital et le degré de contrôle des installations. « Neocloud » est une étiquette de marché, pas une architecture commune.

Les documents d’entreprise cotée de CoreWeave donnent des preuves inhabituellement détaillées sur l’échelle et le risque. Ils n’établissent pas à eux seuls une technologie ou une économie supérieure. Un concurrent avec moins de divulgation peut être plus petit, plus efficace ou simplement plus opaque. L’analyse ne doit pas transformer la transparence en classement de performance.

Face à la construction d’un cluster privé

Un cluster appartenant au client donne à l’acheteur un contrôle direct sur le matériel, les données et les opérations. Il exige aussi des achats, de la puissance, des installations, du réseau, du stockage, de la sécurité, du firmware, des pièces de rechange et du personnel spécialisé. CoreWeave vend le transfert d’une grande partie de ce fardeau.

Le transfert est incomplet. Les clients conçoivent toujours les charges, gèrent les données, fixent les politiques et évaluent le risque du fournisseur. Les engagements à long terme peuvent réduire la flexibilité de déplacement. Un cluster privé risque la sous-utilisation chez le client; un contrat cloud risque la dépendance au fournisseur. Le choix économique est de savoir quelle partie est la mieux équipée pour absorber la variabilité et garder le système coûteux productif.

La commutation refroidie par liquide montre où le prochain goulot peut se déplacer

En juillet 2026, CoreWeave a publié du matériel décrivant une commutation refroidie par liquide conçue pour augmenter la densité de bande passante réseau par rack. L’affirmation est liée à l’architecture et aux calculs de l’entreprise plutôt qu’à un benchmark indépendant à l’échelle de la flotte. Le mécanisme est néanmoins important: à mesure que la densité d’accélérateurs augmente, les commutateurs et optiques consomment assez d’énergie et produisent assez de chaleur pour faire partie du problème de refroidissement du rack.

Refroidir un commutateur par liquide peut permettre plus de capacité réseau dans une enveloppe de rack contrainte et réduire le besoin d’éloigner la commutation. Des chemins plus courts peuvent simplifier le câblage et préserver la densité. La conception couple aussi la maintenance réseau au système de refroidissement liquide. Une fuite, un problème de pompe ou une procédure de service peut affecter des composants auparavant gérés comme des équipements réseau refroidis par air.

Le changement illustre un schéma plus large. Les goulots de l’infrastructure IA migrent. Des GPU plus rapides créent une demande de plus de bande passante scale-up. Plus de bande passante de rack crée une demande de commutation scale-out plus dense. Une commutation plus dense augmente les exigences de puissance et de refroidissement. Les nouvelles installations ont alors besoin de conceptions mécaniques et électriques différentes. Une génération de produit n’est donc pas une mise à niveau de serveur; cela peut être une refonte du centre de données.

Vera Rubin est une transition future, pas une description du parc installé

Le matériel de CoreWeave de juillet 2026 décrit la préparation des systèmes NVIDIA Vera Rubin NVL72 et fait des affirmations mesurées par l’entreprise ou prospectives sur les tokens par mégawatt par rapport à Blackwell. Ces affirmations doivent être attribuées à CoreWeave et à la configuration nommée. Elles n’établissent pas la disponibilité sur toute la flotte à la date de coupure de la recherche.

Une nouvelle génération change plusieurs couches à la fois: accélérateur, fabric scale-up, bande passante scale-out, puissance de rack, refroidissement, firmware, pilotes, orchestration et qualification. Elle peut améliorer la production par mégawatt tout en rendant les installations existantes inadéquates ou moins compétitives. La capacité de CoreWeave à adopter rapidement du nouveau matériel est une force stratégique seulement si elle peut gérer la migration, l’utilisation et la dépréciation sur des actifs contractés plus anciens.

La transition approfondit aussi la dépendance à NVIDIA. Un accès précoce peut attirer des clients et soutenir des contrats premium. Il peut exposer l’entreprise au calendrier, aux prix et aux décisions d’architecture du fournisseur qu’elle ne contrôle pas. La diversification au niveau des clients ou du logiciel ne diversifie pas nécessairement la pile physique.

L’effet plus large de la pile sur l’infrastructure numérique

L’expansion de CoreWeave affecte des marchés bien au-delà de la location de GPU. Les engagements en gigawatts créent une demande de production, d’interconnexion au réseau, de transformateurs, de refroidissement, de terrains et de construction. Les fabric à haut radix créent une demande de commutateurs, optiques et fibre. La connectivité privée crée une demande de capacité opérateur, de présence d’échange et d’on-ramps cloud. Les structures de financement créent une demande de prêteurs capables de valoriser une technologie vieillissante rapidement par rapport à des contrats à long terme.

La plateforme change aussi l’endroit où le trafic Internet apparaît. Le trafic d’entraînement étroitement couplé reste surtout à l’intérieur des fabric locaux, mais les ensembles de données, points de contrôle, artefacts de modèle, requêtes d’inférence et workflows de développeurs se déplacent entre clouds, centres de données et utilisateurs. L’impact visible sur Internet peut donc venir moins d’un flux d’entraînement géant que de mouvements persistants autour de l’environnement d’entraînement.

Pour les communautés et les réseaux électriques qui accueillent des installations, la pile est une décision d’électricité et d’utilisation des sols. Le dossier de recherche ne fournit pas assez de preuves au niveau des sites pour une conclusion environnementale à l’échelle de l’entreprise. Il établit que la puissance active et contractée sont des mesures importantes de la croissance de l’entreprise et que les retards dans la puissance ou la livraison des installations sont des risques commerciaux.

Pour les ingénieurs réseau, l’architecture montre que l’infrastructure IA devient une discipline à part entière. La connaissance du routage et de la commutation reste nécessaire, mais elle rencontre désormais les bibliothèques collectives, la topologie des accélérateurs, le refroidissement liquide, la planification des charges et le financement de projet. La personne qui règle la congestion peut protéger à la fois l’achèvement du travail et le service de la dette.

Ce que les preuves publiques ne peuvent pas montrer

CoreWeave publie de la documentation produit, des blogs techniques et des dépôts financiers, mais la pile reste partiellement opaque. Aucune topologie complète actuelle, inventaire de fabric par site, table de sursouscription, carte de propriété de fibre, historique d’incidents ou archive indépendante de benchmarks charge par charge n’est publique dans le matériel fourni.

Cette frontière devrait changer la façon dont les affirmations sont formulées. La documentation d’architecture peut établir des mécanismes. Les dépôts SEC peuvent établir des faits financiers et de risque consolidés. Les communiqués clients nommés peuvent établir une sélection ou une collaboration. Aucune de ces sources ne prouve un résultat universel de charge, une disponibilité à l’échelle de la flotte ou un coût total inférieur pour chaque acheteur.

La même prudence s’applique à l’échelle. La puissance active n’est pas la puissance contractée. Le carnet de commandes n’est pas le chiffre d’affaires. Un appel de résultats futur planifié n’est pas un résultat. Un accord client annoncé n’est pas la même chose qu’une utilisation active. Une acquisition proposée n’est pas une propriété. Une future génération de matériel n’est pas la flotte actuelle.

Ces distinctions n’affaiblissent pas le profil. Elles identifient la véritable lacune d’information qu’un lecteur professionnel doit gérer. CoreWeave demande aux clients et aux fournisseurs de capital de faire confiance à un système intégré dont les détails les plus précieux sont nécessairement privés. La réponse rationnelle n’est pas de supposer l’excellence ou l’échec. C’est d’exiger des preuves au niveau du contrat, du cluster et du site considérés.

Le jugement central

Le produit de CoreWeave est souvent décrit comme une capacité de calcul. Le produit plus profond est la coordination. Elle doit coordonner les feuilles de route des fournisseurs avec la construction des centres de données, les liens scale-up avec les fabric scale-out, la politique DPU avec l’intention locataire, la planification Kubernetes avec la topologie physique, le stockage avec le comportement des points de contrôle, la connectivité backbone avec l’accès client, et la finance à long terme avec de courtes générations matérielles.

Cette coordination peut créer un véritable avantage. Un fournisseur spécialisé peut faire des choix sur toute la charge au lieu de demander au client d’assembler des fournisseurs séparés. Il peut qualifier les systèmes, réparer les défauts et introduire de nouvelles générations plus vite que beaucoup d’entreprises seules. La croissance rapide de la plateforme suggère que de grands clients valorisent ce transfert de responsabilité.

La même intégration concentre les conséquences. Une conception de fabric, un retard de fournisseur, une erreur de politique, une contrainte de financement ou un changement de client d’ancrage peut affecter une grande partie du système. L’avenir de l’entreprise ne dépend pas d’un seul chiffre de bande passante. Il dépend de la capacité de toutes les couches à continuer de convertir la capacité financée en travail client fiable.