- CommaAI effectue l’entraînement de tous ses modèles et le traitement des données dans son propre datacenter, et exploite directement une infrastructure d’environ 5 millions de dollars
- La dépendance au cloud peut entraîner une hausse des coûts et une perte de contrôle, tandis que l’exploitation de ses propres ressources de calcul permet d’améliorer la qualité de l’ingénierie et de réduire les coûts
- Le datacenter comprend environ 450 kW de puissance, 600 GPU, 4 PB de stockage SSD, ainsi qu’une architecture simple de refroidissement et de réseau
- La pile logicielle est conçue autour de Ubuntu + Salt, du stockage minikeyvalue (mkv), de l’ordonnanceur Slurm, de l’entraînement distribué PyTorch et du calcul distribué miniray
- Grâce à cette architecture, comma.ai automatise entièrement l’entraînement des modèles de conduite autonome et obtient des coûts environ 5 fois inférieurs à ceux du cloud
Pourquoi exploiter son propre datacenter
- Dépendre du cloud entraîne une augmentation des coûts et une dépendance au fournisseur
- Les entreprises du cloud rendent l’onboarding facile, mais l’offboarding difficile
- En cas d’usage continu, il est facile de se retrouver piégé dans une structure de coûts élevée
- Exploiter ses propres ressources de calcul favorise l’autonomie technologique et une culture d’ingénierie efficace
- Le cloud exige une gestion centrée sur les API et les systèmes de facturation, tandis qu’un datacenter demande de résoudre de vrais problèmes techniques autour de l’électricité, du calcul et de la bande passante
- Du point de vue de l’ingénierie ML, les contraintes sur les ressources poussent à l’optimisation du code et à des améliorations fondamentales
- Dans le cloud, on résout simplement le problème en augmentant le budget, alors qu’avec une infrastructure interne, les gains de performance sont indispensables
- Côté coûts, comma.ai indique avoir investi environ 5 millions de dollars ; ils estiment que faire le même travail dans le cloud aurait nécessité plus de 25 millions de dollars
Composants du datacenter
-
Alimentation électrique
- Consommation maximale de 450 kW, coût de l’électricité en 2025 de 540 112 dollars
- Le prix de l’électricité à San Diego atteint 0,40 dollar/kWh, soit environ trois fois la moyenne mondiale
- Un projet de production d’électricité en propre est évoqué pour l’avenir
-
Refroidissement
- Utilisation d’un refroidissement par air extérieur, plus efficace énergétiquement qu’un système CRAC
- Circulation de l’air assurée par deux ventilateurs d’admission et deux d’extraction de 48 pouces
- Boucle de contrôle PID pour ajuster automatiquement température et humidité (maintenues sous 45 %)
- La consommation électrique se situe à l’échelle de quelques dizaines de kW
-
Serveurs et stockage
- 75 TinyBox Pro (soit 600 GPU au total), conçus en interne
- Chaque machine dispose de 2 CPU + 8 GPU et sert à l’entraînement comme au calcul généraliste
- La fabrication interne facilite la maintenance
- Le stockage repose sur des Dell R630/R730, pour un total de 4 PB SSD
- Architecture non redondante, avec 20 Gbit/s en lecture par nœud
- Le réseau se compose de 3 commutateurs Z9264F 100 Gbit/s et de 2 commutateurs Infiniband
Infrastructure logicielle
-
Configuration de base
- Tous les serveurs utilisent Ubuntu + démarrage PXE et sont administrés avec Salt
- Une architecture à maître unique permet de maintenir 99 % de disponibilité
-
Stockage distribué — minikeyvalue (mkv)
- Les données de conduite destinées à l’entraînement sont stockées sur 3 PB de stockage non redondant
- 1 To/s en lecture, ce qui permet un entraînement direct sans cache
- Une baie de 300 To pour le cache et des baies de stockage redondant conservent les modèles et les métriques
- Chaque baie est gérée par un serveur maître unique
-
Gestion des tâches — Slurm
- Planifie les jobs d’entraînement PyTorch et les tâches distribuées miniray
-
Entraînement distribué — PyTorch + FSDP
- Exploitation de deux partitions d’entraînement reliées par un réseau Infiniband
- Un framework d’entraînement maison automatise la boucle d’entraînement
- Fournit un service de suivi des expériences de modèles
-
Calcul distribué — miniray
- Ordonnanceur de tâches open source léger, capable d’exécuter du code Python sur des machines inactives
- Plus simple que Dask, avec un serveur central Redis pour gérer les tâches
- Les workers GPU exécutent l’inférence via Triton Inference Server
- Peut monter en charge en parallèle sur des centaines de machines
- Exemple : le record du Controls Challenge a été atteint avec une heure d’utilisation du datacenter
-
Gestion du code — monorepo basé sur NFS
- L’ensemble de la base de code fait moins de 3 Go et est répliqué sur tous les postes de travail
- Au démarrage d’un job, le code local et les packages sont synchronisés, en moins de 2 secondes
- Garantit que tous les jobs distribués s’exécutent avec le même code et le même environnement
Pipeline d’entraînement intégré
- Chez comma, la tâche la plus complexe consiste à entraîner un modèle de conduite selon une approche on-policy
- Pour cela, il faut exécuter une conduite simulée avec les poids du modèle les plus récents afin de générer les données d’entraînement
- L’ensemble du pipeline peut être lancé avec la commande unique suivante
./training/train.sh N=4 partition=tbox2 trainer=mlsimdriving dataset=/home/batman/xx/datasets/lists/train_500k_20250717.txt vision_model=8d4e28c7-7078-4caf-ac7d-d0e41255c3d4/500 data.shuffle_size=125k optim.scheduler=COSINE bs=4
- L’exécution de cet entraînement mobilise toute l’infrastructure décrite plus haut
- Cette simple commande joue pourtant le rôle de coordinateur entre de multiples composants
Conclusion
- comma.ai parvient à réduire ses coûts et à gagner en autonomie technologique grâce à l’exploitation de son propre datacenter
- La même approche pourrait permettre à des entreprises ou à des particuliers de construire leur propre infrastructure
Aucun commentaire pour le moment.