Oxide lève $445M de Série D pour développer une infrastructure cloud détenue par l’entreprise

L’expérience cloud devient quelque chose que les entreprises peuvent acheter et exploiter dans leurs propres installations. Oxide Computer Company a levé 445 M$ de Série D pour développer cette proposition : un système informatique intégré qui combine matériel et logiciel open source dans une infrastructure que ses clients possèdent.

L’annonce du 9 octobre identifie Eclipse comme l’investisseur principal, avec la participation d’investisseurs existants dont US Innovative Technology Fund, Riot Ventures et Jane Street. De nouveaux investisseurs comprennent Atreides Management et AMD Ventures. Oxide indique qu’elle a atteint la rentabilité plus tôt cette année et qu’elle utilisera le capital pour sécuriser les composants et augmenter la production alors que la demande dépasse la capacité. Le PDG Steve Tuck affirme que la capacité de fabrication a été multipliée par vingt au cours des douze derniers mois — un chiffre de capacité déclaré par l’entreprise, plutôt qu’une mesure de croissance du chiffre d’affaires. L’annonce de financement cadre l’investissement autour de l’augmentation des livraisons.

Pourquoi une entreprise de matériel rentable a besoin de davantage de capitaux

Profitabilité et liquidités disponibles pour l’expansion sont deux choses différentes lorsqu’une entreprise doit construire des systèmes physiques. Dans leur communiqué d’entreprise accompagnant, les cofondateurs Bryan Cantrill et Steve Tuck expliquent que la rentabilité d’Oxide provient d’opérations informatiques ordinaires, après prise en compte des composants, de la fabrication, des salaires et d’autres coûts.

Ils décrivent également un carnet de commandes qui nécessite des dépenses initiales importantes. La génération de liquidités existante et les facilités d’endettement pourraient soutenir le règlement de ce carnet, indiquent-ils, mais rendraient l’entreprise plus prudente quant à la prise de nouvelles demandes et à l’absorption des perturbations d’approvisionnement. La levée de fonds en actions offre à Oxide davantage de marge pour s’engager dans la fabrication avant que les clients ne reçoivent leurs systèmes.

Cela rend l’histoire du financement exceptionnellement concrète. Le prochain test consiste à savoir si le pouvoir d’achat supplémentaire et la capacité de production se traduiront par des installations rapides, un support fiable et une adoption client durable. Une levée importante fournit les ressources nécessaires à ce travail ; l’exécution en déterminera le résultat.

Ce que signifie réellement un cloud détenu par l’entreprise

L’unité d’achat d’Oxide est une armoire complète plutôt qu’un ensemble de serveurs, d’appliances de stockage, d’équipements réseau et de licences de virtualisation sélectionnés indépendamment. Sa documentation produit décrit un plan de contrôle intégré avec une API, un portail web et des SDK pour provisionner des machines virtuelles, du stockage en blocs et du réseau virtuel.

La distinction importe pour les personnes qui développent des applications. La possession d’équipements physiques ne doit pas forcément impliquer l’ouverture d’un ticket chaque fois qu’un développeur a besoin d’une machine. Un plan de contrôle commun peut rendre l’infrastructure disponible via le logiciel tout en laissant l’organisation responsable de l’emplacement des équipements.

L’intégration modifie également le problème d’approvisionnement. Les clients évaluent un système avec un comportement matériel et logiciel coordonné, plutôt que de concevoir chaque interface eux-mêmes. Ils doivent néanmoins examiner le support du fournisseur, les voies de mise à jour, les exigences d’infrastructure et le coût du remplacement de capacité au fil du temps.

À l’intérieur de la pile : virtualisation, stockage et réseau

L’architecture d’Oxide est plus précise que ne le suggère le terme cloud privé. Son guide hyperviseur et stockage décrit Helios, son système d’exploitation hôte basé sur illumos, et Propolis, un hyperviseur en espace utilisateur écrit en Rust construit autour du moniteur de machine virtuelle open source bhyve. Les systèmes d’exploitation invités utilisent des interfaces matérielles virtuelles familières.

Le stockage est mis en pool sur l’ensemble de l’armoire. Les disques virtuels distribués conservent trois copies sur des disques physiques séparés dans des compute sleds distincts, et le trafic de stockage est chiffré entre l’hôte invité et les hôtes hébergeant ces copies. L’objectif est d’intégrer la résilience dans la conception de la plateforme, plutôt que de laisser cette tâche d’intégration entièrement aux équipes applicatives.

L’architecture réseau sépare le trafic de gestion du réseau applicatif. Le Packet Transformation Engine d’Oxide gère des fonctions telles que le routage, le pare-feu et la traduction d’adresses entre les machines virtuelles et les interfaces physiques. Les connexions de commutateurs redondantes assurent la disponibilité, tandis que les constructions de cloud privé virtuel offrent des frontières réseau logiques pour les charges de travail.

Ces mécanismes répondent à des objectifs distincts. La réplication traite les pannes de stockage ; le chiffrement protège le trafic ; la politique réseau contrôle la communication. Les acheteurs doivent examiner chacun en fonction de leurs propres exigences, plutôt que de considérer une armoire intégrée comme une garantie globale de sécurité ou de disponibilité.

Processeurs AMD et les charges de travail IA autour des GPU

La participation d’AMD a un lien technique direct. Les spécifications actuelles d’Oxide répertorient des compute sleds de deuxième génération utilisant des processeurs AMD EPYC 9005, avec des configurations atteignant 192 cœurs physiques et 1,5 TiB de mémoire par sled, ainsi que deux connexions réseau 100 GbE. La capacité dépend de la configuration sélectionnée ; le total du matériel physique diffère également des ressources disponibles pour les charges de travail invitées.

Pour les équipes d’IA, ces ressources couvrent une partie importante de l’infrastructure entourant l’exécution des modèles. La page d’infrastructure IA d’Oxide met en avant l’ingénierie des données, l’apprentissage automatique classique, la recherche et la recherche de similarité, ainsi que des charges de travail d’inférence basées sur le CPU sélectionnées. Elle souligne la compatibilité avec des outils tels que Spark, Airflow, Ray et XGBoost, ainsi que l’automatisation pilotée par API.

C’est une façon utile d’évaluer sa pertinence pour les applications agentiques. Un système qui recherche de manière répétée les dossiers d’entreprise, traite des documents et interroge des services métier a besoin de bases de données, de mémoire, de stockage et de calcul à usage général, en plus de tout accélérateur de modèle. Placer ces services de soutien à proximité des données d’entreprise peut simplifier certaines architectures.

Cela ne prouve pas qu’une armoire CPU puisse remplacer l’infrastructure GPU pour chaque tâche d’IA. Les équipes devraient évaluer leurs modèles réels, leurs charges de travail de recherche, leurs objectifs de latence et de concurrence. La répartition appropriée entre CPU, accélérateurs et services externes dépend de l’application.

Le support de Kubernetes mérite un examen approfondi

La familiarité avec le cloud dépend également des outils environnants. Dans un post d’ingénierie du 13 août, Oxide a décrit des intégrations pour Rancher, Talos Linux via Omni et Cluster API, ainsi qu’un gestionnaire de contrôleur cloud reliant les informations des nœuds Kubernetes aux instances Oxide.

Ce post distinguait également les capacités livrées du travail en cours. Le branchement à chaud des disques et un plugin natif Container Storage Interface étaient encore en cours de développement lors de la publication, tandis que la discussion sur le réseau de services expliquait l’approche d’équilibrage de charge disponible. Il s’agit de détails d’implémentation datés, de sorte que les acheteurs devraient vérifier l’état de la dernière version plutôt que de supposer des limitations permanentes ou une parité complète avec un service cloud public géré.

La leçon plus large est qu’une plateforme d’infrastructure pilotée par API et un écosystème d’applications entièrement géré constituent des couches distinctes. Une évaluation d’achat devrait inclure l’intégration du stockage, les mises à jour de clusters, l’observabilité et la répartition des responsabilités opérationnelles.

La décision de propriété dépend toujours des charges de travail

Unite.AI a également abordé l’IA privée et le rapatriement du cloud via une infrastructure hébergée. Oxide propose une voie différente dans la même discussion : l’achat du système intégré lui‑même.

Pour des charges de travail prévisibles et constamment utilisées, la propriété peut faciliter la planification des dépenses de capacité. Le calcul doit encore prendre en compte l’électricité, le refroidissement, le personnel, le support, le financement, la capacité de réserve et les cycles de renouvellement. L’élasticité du cloud public peut rester précieuse lorsque la demande est incertaine ou que les exigences évoluent rapidement.

La série D d’Oxide offre à son modèle de cloud détenu par l’entreprise une piste de production beaucoup plus longue. Les preuves les plus significatives à ce stade seront opérationnelles : systèmes livrés, charges de travail migrées avec succès et clients constatant que la pile matérielle et logicielle combinée répond à leurs besoins au fil du temps.