Contexte du neocloud
Le marché du neocloud, initialement né comme solution de secours face à la pénurie de GPU, évolue vers un modèle où les startups IA choisissent leurs fournisseurs en fonction de la latence, de la capacité de rafale et de l’ouverture des interfaces. L’exemple de LlamaIndex illustre ce glissement : il ne possède aucun cluster GPU et dépend d’une capacité garantie pour traiter des flux de documents en « bursts ». Son trafic se compose aujourd’hui d’environ 75 % d’inférence et 25 % d’entraînement, avec le traitement de millions de pages de documents chaque jour pour des clients du secteur financier, juridique et assurantiel.
Impact du câblage et de l’alimentation des GPU
Selon Lukas Biewald, vice‑président senior de l’IA chez CoreWeave, la façon dont les puces sont interconnectées et alimentées peut modifier la latence de plusieurs ordres de grandeur. Cette affirmation repose sur deux leviers techniques : le réseau interne entre les GPU et la distribution d’énergie. Un réseau à haut débit, conforme aux protocoles standards recommandés par Nvidia, minimise les temps de transfert de données entre les cartes, alors qu’une alimentation stable évite les fluctuations de fréquence qui allongent les cycles de calcul. CoreWeave a ainsi développé CoreWeave Forge, une couche logicielle qui unifie entraînement, inférence, évaluation et développement d’agents dans un environnement partagé, permettant de tester différentes topologies de câblage sans modifier le matériel sous‑jacent.
Ouverture versus solutions propriétaires
Contrairement aux hyperscalers comme Amazon Web Services, qui imposent des API propriétaires compliquant la migration des charges de travail, CoreWeave adopte les protocoles de réseau ouverts préconisés par Nvidia. Cette approche facilite l’intégration avec d’autres clouds (AWS, GCP) et réduit les frais de verrouillage technologique. En pratique, les clients peuvent déplacer leurs modèles entre environnements sans réécrire le code d’accès aux GPU, ce qui accélère le déploiement d’applications sensibles à la latence.
Limites et perspectives
Bien que les déclarations de CoreWeave indiquent des gains « d’ordres de grandeur », l’article ne fournit pas de mesures chiffrées de latence ni de benchmarks comparatifs. L’absence de données précises empêche d’évaluer la reproductibilité de ces améliorations sur d’autres architectures ou fournisseurs. De plus, la dépendance à une infrastructure spécialisée peut introduire de nouveaux points de défaillance, notamment au niveau de l’alimentation électrique qui, si mal dimensionnée, risque de provoquer des throttlings imprévus. Enfin, la capacité de burst, bien que cruciale pour les charges de travail irrégulières, nécessite une gestion dynamique des ressources qui n’est pas détaillée dans le discours de CoreWeave.
