Ne louez pas le cloud, possédez-le

 (blog.comma.ai)
11 points par GN⁺ 2026-02-06 | 3 commentaires | Partager sur WhatsApp
  • 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

À lire aussi

3 commentaires

 
kaydash 2026-02-06

La mémoire coûte cher !
 
harryhan2435 2026-02-12

MDRRRRRRRRRRRRRR
 
GN⁺ 2026-02-06
Avis sur Hacker News

  • Dans notre secteur, la question propriété vs cloud se situe aux deux extrémités d’un spectre
    ① Le cloud demande peu d’investissement initial (capex) et peu de personnel, mais les coûts d’exploitation (opex) sont élevés et variables
    ② Le Managed Private Cloud, c’est ce que nous faisons : nous le gérons sur une base open source, pour environ 50 % moins cher qu’AWS
    ③ Le Rented Bare Metal est un modèle qui remplace le financement du matériel, et coûte 90 % de moins qu’AWS
    ④ Acheter directement puis faire de la colocation est l’option la moins chère si l’on a les compétences techniques et la taille suffisante
    Des acteurs comme Hetzner fonctionnent avec un ROI sur 3 ans, et les options 3 et 4 conviennent aux entreprises de grande taille ou à celles dont l’infrastructure est stratégique
    Pour les startups, l’option 1 est réaliste, et pour les PME, l’option 2 l’est davantage (lithus.eu)

    • Le problème, c’est que la structure de coûts du cloud ne vient pas seulement du prix du matériel, mais du fait qu’elle pousse vers des architectures complexes, ce qui accroît les inefficacités
      Les « services managés » d’AWS sont structurés de sorte que plus l’utilisateur améliore l’efficacité de ses serveurs, plus les revenus d’AWS baissent
      Une architecture simple avec 4 serveurs Java sur EC2 et une base de données répliquée serait bien plus efficace
      Au final, les factures AWS absurdes apparaissent quand on abuse d’une multitude de services

    • (derek@ de Carolina Cloud) Nous aussi, nous préférons le modèle (4), mais les utilisateurs qui manquent de compétences techniques restent bloqués dans les options 1 à 3 et se retrouvent piégés dans la structure à coût élevé du cloud public
      On parle de « paiement à l’usage », mais en réalité il y a des frais de base et des minimums de consommation, ce qui revient bien plus cher (carolinacloud.io)

    • Hetzner est une option séduisante
      Devoir gérer soi-même des services comme Postgres ou un VPN peut être un frein, mais à partir de 10 000 à 15 000 dollars par mois, c’est plus avantageux qu’AWS
      Il y a des risques, mais ils valent la peine d’être pris

    • Je loue un serveur bare metal à 500 dollars par mois, et cela ne me prend que quelques heures de gestion par an
      C’est peut-être parce que mes besoins sont simples, mais j’ai l’impression que c’est bien mieux qu’un cloud inutilement complexe

    • Nous avons migré vers la colocation il y a 2 ans, et nous avons maintenant plus de capacité pour 30 % du coût
      Nous bénéficions aussi des baisses de prix différées sur la RAM et le stockage
      En revanche, il faut faire un peu plus attention à la gestion de la conformité

  • Avant, on appelait simplement ça un datacenter
    Le concept existait déjà avant le cloud, et au fond c’est toujours la même répétition entre propriété vs location et centralisation vs décentralisation
    Quand une entreprise choisit un extrême, elle finit par retomber sur les mêmes problèmes

    • Ce qui est intéressant, c’est que le cloud plaisait aux équipes financières en raison de ses avantages fiscaux
      Mais avec une loi récente (OBB) qui permet de passer le CapEx en charges, on voit souffler un vent de retour à l’on-prem

    • Dans ce cas, pourquoi n’existe-t-il pas de véritable alternative cloud compétitive sur les prix ?
      AWS et Azure dominent le marché, donc ils n’ont aucune incitation à baisser leurs prix, et Google traîne un risque important d’arrêt de services

    • Avant le cloud, les équipes d’infrastructure internes constituaient le goulot d’étranglement
      Le cloud a standardisé cela et simplifié les choses avec un système de facturation unifié
      En dehors des États-Unis, l’approvisionnement en serveurs était aussi plus lent, ce qui donnait au cloud un véritable avantage de rapidité

    • Les datacenters on-prem impliquent une charge opérationnelle importante et consomment beaucoup de ressources d’ingénierie
      C’est pour cela que ce débat revient sans cesse

    • La vraie innovation du cloud, c’est d’avoir « rendu explicite le coût de chaque service »
      Au lieu de se demander « à qui faut-il demander ? », tout est devenu accessible via API
      Le contexte est bien résumé dans ce texte

  • Même dans une région comme San Diego, où le contrôle de la température est plus simple, le refroidissement par air extérieur est risqué
    L’humidité et les polluants détériorent rapidement les serveurs
    À la place, des solutions comme les refroidisseurs à roue enthalpique (kyotocooling) sont efficaces et consomment peu d’énergie par rapport à leur performance thermique
    Il faut faire attention : le refroidissement par air extérieur peut raccourcir considérablement la durée de vie du matériel

    • Certains ont toutefois obtenu de très bons résultats avec une bonne filtration et un taux d’humidité maintenu sous 45 %

    • Je ne savais même pas qu’il fallait penser à tout cela
      Donc moi, j’utilise simplement le cloud — cela permet d’éviter ce genre de « risques inconnus »

  • Faire coexister on-prem et cloud est une approche réaliste
    On peut confier l’infrastructure critique à un cloud de confiance, et faire tourner des jobs Slurm sur ses propres serveurs
    La colocation reste une option valable, et il faut aussi envisager le HPC pour la recherche
    En Norvège, même les entreprises privées peuvent utiliser des HPC de recherche contre paiement

    • J’ai exploité deux fermes de serveurs en Italie, sur deux sites, gérées par 5 employés, avec une disponibilité proche de 100 %
      Pour 800 000 euros par an, cela nous a permis d’éviter 7 à 8 millions d’euros de dépenses cloud

    • Beaucoup de développeurs croient à tort qu’ils ne savent pas héberger eux-mêmes
      En réalité, c’est plus simple qu’on ne l’imagine, et il y a aussi du plaisir à résoudre les problèmes techniques

    • Si l’on loue de l’espace chez des acteurs comme Equinix ou Global Switch, l’alimentation, le refroidissement, le câblage, etc. sont tous pris en charge
      Il est donc tout à fait possible d’avoir soi-même des salles serveurs sur deux sites

    • Nous utilisons encore Azure pour les services destinés aux utilisateurs
      Pour les services web qui n’ont pas besoin de GPU, le cloud reste plus efficace
      GitHub reste également un service digne de confiance que nous utilisons toujours

    • (sur le ton de la plaisanterie) Il nous est déjà arrivé qu’un démon Postgres s’emmêle dans un pool Slurm et fasse partir Rust dans tous les sens
      Nous avons fini par stabiliser le tout, mais du point de vue d’un ingénieur matériel, le monde du logiciel est chaotique

  • Au début d’un projet, on démarre sur AWS à 250 dollars par mois, puis quand on atteint 30 000 dollars mensuels, on passe à la colocation
    L’essentiel, c’est la capacité à calculer les coûts — un bon ingénieur doit pouvoir s’appuyer dessus pour faire des propositions à la direction

    • Au-delà du simple calcul, il faut aussi réfléchir aux talents que l’on veut attirer et au type d’entreprise que l’on veut construire
      Si l’entreprise entraîne des modèles de ML, il peut être plus pertinent de posséder sa propre infrastructure

    • Mais dans la plupart des entreprises, les ingénieurs n’ont pas leur mot à dire sur le choix de la plateforme
      Dans 99,999999 % des cas, la direction a déjà décidé et se contente de le notifier

  • Au début de ma carrière, le cloud allait de soi, mais aujourd’hui l’on-prem revient à la mode
    Dans 10 ans, le mouvement inverse reviendra peut-être à son tour

    • D’après mon expérience, les équipes qui poussaient l’on-prem ont toujours sous-estimé la fatigue liée à la maintenance
      Dans des environnements comme les startups, où il faut développer vite, cela finit plutôt par freiner
      En revanche, dans des entreprises entrées en mode maintenance, l’on-prem était efficace
      Avec l’âge, ce qui compte devient « aller vite et rester dans le budget », et l’attrait de l’infrastructure auto-opérée diminue

    • Cette tendance actuelle n’est pas qu’un simple cycle technologique, mais aussi une réaction à une société où l’on ne possède plus rien
      De la musique au logement en passant par la voiture, tout est devenu abonnement, et les entreprises cherchent elles aussi à reprendre leur souveraineté informatique

    • Ce cycle a toujours existé
      Mainframe → PC → salle serveurs → cloud → edge computing : c’est encore une répétition de la centralisation ↔ décentralisation
      Quand les technologies et les priorités changent, le mouvement repart dans l’autre sens
      Le jour où l’on recommencera à dire « le réseau est l’ordinateur », on aura bouclé un tour de plus

    • (blague) La prochaine étape sera peut-être l’espace (Skynet)

  • Si la plupart des entreprises évitent l’on-prem, c’est avant tout pour une question de gestion du risque
    Une bonne entreprise concentre les risques sur son avantage concurrentiel central
    Il faut juger cela non pas seulement en coût brut, mais en coût ajusté au risque

    • Mais aujourd’hui, on peut se demander si les entreprises ont encore réellement la capacité d’évaluer correctement ce risque
      Après tout, la compétitivité-prix fait elle aussi partie des éléments de différenciation

    • L’essentiel est de rester concentré sur son cœur de métier
      Si cela n’aide pas à mieux vendre un produit difficile à vendre, il ne faut pas perdre son temps avec un datacenter
      Google fait figure d’exception, parce que son infrastructure est elle-même un avantage produit

    • Au final, c’est le plus souvent l’opex qui bat le capex

  • Le véritable avantage de l’on-prem, c’est la liberté, le contrôle et la vie privée
    Ce n’est pas seulement une question d’argent, c’est comme posséder sa maison plutôt que la louer

    • D’ailleurs, dans le texte d’origine, le coût n’était traité qu’en dernier, et ce sont surtout les autres avantages qui comptent

  • Dans les années 2010, la doctrine façon MBA, c’était « mettez tout dans le cloud »
    Transférer les risques et les coûts à un tiers était présenté comme la bonne réponse
    Mais en pratique, notre propre datacenter était bien moins cher, et le rythme d’augmentation des abonnements logiciels était largement supérieur à celui du matériel

    • Bien sûr, AWS dispose de datacenters redondants dans le monde entier, donc son niveau de résilience n’est pas comparable
      Mais une fois pris en compte les coûts salariaux et de gestion, comparer uniquement les coûts bruts n’a plus grand sens
      Une seule tornade peut suffire à faire disparaître une entreprise, donc au final il faut raisonner en valeur au regard du risque