- Construction en propre d’un cluster de stockage en plein centre de San Francisco avec pour objectif de stocker des données vidéo représentant 90 millions d’heures, afin du préentraînement de modèles pour la résolution de problèmes d’usage informatique
- Choix d’une approche on-premise permettant d’exploiter une infrastructure de stockage de 30 PB pour 354 k$ par an (500 millions de wons). À titre de comparaison, AWS reviendrait à 12 M$ (17 milliards de wons), soit environ 34 fois moins cher
- Contrairement à la plupart des clouds publics, l’accent n’est pas mis sur la haute disponibilité et l’intégrité, avec une stratégie assumant la tolérance à la perte de données en raison de la nature des données d’entraînement
- Exploitation avec un logiciel simple basé sur Rust et Nginx et gestion via un programme maison de 200 lignes, plutôt qu’avec des systèmes complexes comme Ceph ou MinIO
- Le projet a permis d’acquérir un savoir-faire concret sur des sujets comme le déploiement physique, la configuration réseau et la gestion du câblage, avec plusieurs essais et erreurs réalistes
Introduction et contexte
- Le préentraînement de modèles destinés à l’usage informatique nécessite de très grands volumes de données vidéo
- Alors qu’un LLM textuel classique (ex. : LLaMa-405B) peut se contenter d’environ 60 To de données, l’entraînement sur vidéo exige 500 fois plus d’espace de stockage
- En utilisant un cloud public comme AWS, la facture annuelle atteindrait 12 millions de dollars, mais la location d’un centre de colocation et une construction en propre ont permis de ramener ce coût à environ 354 000 dollars
- Le fait d’héberger soi-même ces volumes massifs de données a permis de résoudre un problème où le coût des données était la contrainte principale
Pourquoi construire soi-même
- Le cloud met l’accent sur la très haute fiabilité, la redondance et l’intégrité des données, mais les données de préentraînement ne sont pas critiques au point qu’une perte de 5 % soit inacceptable
- Cette caractéristique permet d’adopter des exigences de fiabilité bien plus souples que dans une entreprise classique (application de 2 nines au lieu de 13 nines)
- Le prix du stockage est fixé bien au-delà de son coût réel
- Les données étant le principal poste de dépense, il a été jugé plus avantageux, dans un cadre suffisamment prévisible, de construire un datacenter local
Comparaison des coûts : cloud vs construction en propre
- Coûts récurrents mensuels : Internet 7 500 $ + électricité 10 000 $ = 17 500 $ au total
- Coûts ponctuels : disques durs 300 000 $, châssis 35 000 $, nœuds CPU 6 000 $, installation 38 500 $, main-d’œuvre 27 000 $, réseau et autres frais d’installation 20 000 $ → 426 500 $ au total
- En incluant l’amortissement sur 3 ans, le coût fixe mensuel est calculé à 29 500 $
- AWS : 1 130 000 $/mois, Cloudflare R2 : 270 000 $/mois, construction en propre : 29 500 $/mois
- AWS : environ 38 $/To/mois
- Cloudflare : environ 10 $/To/mois
- Construction en propre : 1 $/To/mois
- Dans l’entraînement de grands modèles, même Cloudflare a rencontré des problèmes de rate limiting sous forte charge interne, tandis que leur environnement maison a résolu cela via une liaison dédiée à 100 Gbit/s
Mise en place et processus
- Pour aller vite, planification d’un
Storage Stacking Saturday(S3) avec l’aide de proches et l’intervention de prestataires spécialisés
- En 36 heures, 2 400 disques durs ont été montés en rack, finalisant un matériel de 30 PB
- Le logiciel repose sur Rust (écriture, 200 lignes) + nginx (lecture) + SQLite (suivi des métadonnées)
- Ceph, MinIO, Weka, Vast, etc. n’ont pas été retenus pour des raisons de complexité et de coût (complexité, absence de nécessité, charge de maintenance, etc.)
- Tous les disques sont formatés en XFS
Retours d’expérience et enseignements du projet
Ce qui a bien fonctionné
- Application pertinente du compromis redondance/performance, permettant de quasiment saturer le réseau 100G
- Déploiement à proximité physique, garantissant une facilité de débogage et de maintenance
- Fournisseurs trouvés sur eBay mais achats réalisés directement auprès de vendeurs individuels, avec insistance sur la nécessité de garanties
- Les avantages d’une liaison Internet 100G sont nombreux, et les problèmes réseau sont plus faciles à déboguer en interne
- Une gestion de câblage de haute qualité a grandement aidé à résoudre les problèmes par la suite
- Adoption d’un principe de simplification plutôt que de systèmes de stockage open source complexes, afin de minimiser la maintenance
- Les prévisions de temps et de coûts de main-d’œuvre se sont révélées exactes, et les économies ont été clairement confirmées
Difficultés et essais/erreurs
- L’usage de front loaders a rendu fastidieuse l’installation manuelle, un par un, des 2 400 HDD
- Densité de stockage insuffisante ; un choix de densité plus élevée dans la conception initiale aurait pu réduire le travail
- Le daisy chain crée des goulots d’étranglement ; l’idéal est une connexion HBA séparée pour chaque châssis
- Pour les composants réseau, la compatibilité entre marques est importante, en particulier pour les transceivers optiques
- Les expérimentations et réglages réseau ont pris du temps ; la configuration a privilégié les performances et la praticité plutôt que DHCP/NAT (seules des exigences minimales de pare-feu/lien sécurisé ont été appliquées)
- L’importance de l’accessibilité physique ainsi que du câblage des moniteurs/claviers pendant l’installation s’est fait sentir
Idées à essayer
- Utiliser KVM et IPMI pour améliorer l’efficacité de l’administration à distance
- Recommandation de constituer un réseau Ethernet d’administration séparé
- Surprovisionnement réseau à envisager (par ex. un réseau interne en 400G)
- Avec des serveurs de plus forte densité (Supermicro 90 disques / HDD 20 To, etc.)
réduction du nombre de racks, baisse de la consommation électrique, gains liés à la concentration CPU, etc.
Comment construire soi-même
Configuration de stockage
- 10 nœuds CPU head node (Intel RR2000, etc., avec recommandation de double Intel Gold 6148 / 128 Go de RAM ECC DDR4 par serveur)
- Pour les fonctions très gourmandes en CPU (comme ZFS), il est possible de choisir du matériel plus performant
- 100 châssis DS4246 (24 HDD chacun)
- 2 400 HDD 3,5" (de préférence des disques SAS, pour l’avantage en vitesse)
- Combinaison possible de plusieurs capacités (12 To, 14 To, etc.), les grandes capacités étant plus avantageuses pour le déploiement et la revente d’occasion
- Rails / supports de montage, câblage des équipements et câbles
- Plusieurs crash carts (moniteur + clavier) pour le débogage des problèmes réseau
Infrastructure réseau
- Switchs 100GbE (Arista d’occasion, etc., avec ports QSFP28)
- HBA pour chaque serveur (recommandation : Broadcom 9305-16E, etc.), avec schéma de connexion entre ports HBA et châssis
- Cartes réseau (Mellanox ConnectX-4, etc., impérativement en mode Ethernet)
- Câbles DAC/AOC — en tenant compte des distances entre racks, le DAC offre des avantages de compatibilité
- Recommandation de passer par des fournisseurs livrant les head nodes CPU avec HBA/NIC déjà installés
- Câbles série, réseau Ethernet d’administration séparé (alternative avec adaptateur sans fil de secours + mini-switch)
Exigences du datacenter
- 3,5 kW de consommation par baie, avec l’hypothèse d’une configuration 4U×10 + 2U×1 sur une base 42U
- 3 PB par baie, avec 1 baie 42U supplémentaire pour les switchs ou remplacement par un châssis 1U
- Cross-connect dédié 100G (généralement une paire de fibres QSFP28 LR4) ; vérification préalable indispensable de la compatibilité de format et de marque
- Un site proche du bureau (colocation recommandée) permet une intervention physique rapide en cas de problème et optimise la productivité du débogage et de l’exploitation
Conseils pour la configuration initiale
- Après une configuration initiale du switch en console locale, vérifier d’abord la configuration des ports uplink 100GbE ainsi que la compatibilité des transceivers optiques
- Si nécessaire, connecter directement la fibre de l’ISP à la NIC pour confirmer le link-up, puis migrer vers le switch
- Pendant l’installation d’Ubuntu, il est plus simple de finaliser la configuration réseau des nœuds avec Netplan
- Une fois la connexion Internet des nœuds établie, procéder dans l’ordre connexion d’un câble par DS4246 → formatage/montage → vérification de l’état afin de détecter tôt les problèmes de câblage et les disques défectueux
Points d’attention sur les performances, la stabilité et la sécurité
- Avec l’hypothèse de sécurité d’un usage exclusivement dédié aux données d’entraînement, exploitation simplifiée avec IP publique en direct + pare-feu de ports +
nginx secure_link
- Pour des données clients, cette configuration est inadaptée ; DHCP/NAT/pare-feu segmenté sont indispensables
- Le daisy chain simplifie l’administration et le câblage, mais provoque des goulots d’étranglement de bande passante ; dans la mesure du possible, il est recommandé d’utiliser un HBA dédié par châssis
- Les transceivers optiques sont fortement soumis au verrouillage de marque ; il est possible de se fournir à la fois chez FS.com et sur Amazon, mais il faut vérifier rigoureusement la correspondance des spécifications et des marques
Conclusion et portée
- Avec un stockage maison ultra-économique à 1 $/To/mois, le préentraînement vidéo sur 30 PB devient réaliste, avec une réduction des coûts de 10 à 38 fois par rapport au cloud
- Une architecture simple et une proximité terrain ont réduit le temps et les risques, tandis qu’une liaison dédiée 100G a éliminé les goulots d’étranglement I/O
- À l’ère des grands modèles multimodaux et vidéo, l’avantage compétitif central réside dans une infrastructure de données massive à faible coût, et cette approche fournit une référence concrète qu’une petite équipe peut aussi mettre en œuvre
Conclusion et coopération
- Si vous avez construit un cluster de stockage similaire en vous appuyant sur cet article, partagez vos améliorations et votre retour d’expérience
- Recrutement en cours pour la recherche en IA autour du préentraînement à grande échelle de modèles d’usage informatique, de la généralisation et de l’alignement avec les valeurs humaines (contact : jobs@si.inc)
1 commentaires
Commentaires sur Hacker News
Au début de ma carrière, l’on-premise était la norme. Le matériel qui dure longtemps finit par recevoir beaucoup d’attention, et chaque serveur accumule son propre historique. Avec le temps, quand les performances du matériel ne suffisent plus, il faut passer par les équipes internes pour choisir un nouveau matériel dans une liste existante, puis faire approuver des coûts supplémentaires, ce qui est pénible. Le processus de remplacement du matériel, ou la transition vers de nouveaux équipements en séparant soigneusement ceux qu’on a chéris comme des animaux de compagnie, peut aussi retarder des projets. Quand le cloud est arrivé, je me suis dit : « désormais, il faut tout passer dans le cloud ». Mais avec le temps, soi-même et son organisation oublient comment gérer directement du matériel, et au final, si on ne ravive pas ces compétences, le cloud, qui était un bon choix, devient peu à peu moins attractif. Donc merci de permettre de développer à nouveau ces compétences.
Nous sommes dans une situation un peu particulière. Dès le départ, nous n’avions pas les moyens d’assumer en OPEX l’hyperscale cloud, donc nous avons été contraints de développer nos propres compétences en interne. Ce n’est pas si difficile que ça en pratique, et nous allons probablement continuer ainsi encore un moment. Cela dit, le problème d’accumulation d’état mentionné plus haut commence effectivement à apparaître.
Dans mes souvenirs, l’on-premise a toujours été moins cher. Il y avait aussi l’avantage de supprimer de nombreux obstacles logistiques et d’avoir la commodité d’une seule facture. À l’époque où le cloud était à la mode, le conseil était toujours d’utiliser l’on-premise, et de ne recourir au cloud que lorsque le trafic montait ou descendait brutalement. Mais l’usage d’extension temporaire est devenu peu à peu un usage permanent, et les développeurs se sont mis à dépendre du fait de pouvoir lancer immédiatement de nouvelles machines. Aujourd’hui, tout le monde considère le cloud comme l’état par défaut. Dans ce processus, nous avons perdu la base nécessaire pour bien percevoir les coûts réels, et l’écart de coût entre cloud et on-premise s’est de plus en plus creusé.
Docker est un excellent outil pour faire des serveurs autre chose que des animaux de compagnie. Un serveur dans un rack devient simplement un nœud K3 ou K8 de plus, donc on ne le traite plus comme un pet. J’aime vraiment beaucoup cet aspect. On pourrait dire quelque chose de similaire des VM, mais au final la VM elle-même devient un pet. Bien sûr, on peut créer des images ou faire des snapshots, mais ce n’est pas la même transformation que celle qu’on ressent avec Docker.
Une question lancée à moitié pour rire : et si on retentait ce genre de défi ?
Une startup qui a suffisamment d’argent pour acheter tranquillement un domaine .inc de deux lettres a trop de financement. C’est le même phénomène que de compter combien de chaises Aeron il y a dans les bureaux d’une startup. Ce n’est pas un bon signal.
Les domaines .inc de deux lettres non utilisés se vendent 2 300 $ par an, ce qui ne représente même pas 5 % du coût d’un développeur.
Je me demande si un nom de domaine en .inc a une quelconque valeur réelle.
Article amusant, lecture très satisfaisante par procuration. J’aurais juste aimé voir un peu plus de photos pour rendre l’expérience encore plus sympa.
J’ai apprécié le niveau de détail technique. J’ai une question : comment s’est passée la recherche d’un espace de colocation ? Est-ce que vous êtes passés par un broker, et après négociation, de combien le prix réellement payé différait-il du devis initial ?
Le billet de blog de Discord lié est aussi intéressant. C’est surtout sérieux, mais il y avait aussi ce passage amusant : quand un but était marqué pendant la Coupe du monde, cela apparaissait immédiatement dans les graphes de monitoring, ce qui permettait à l’équipe de prétendre qu’elle regardait le match pendant une réunion pour des raisons professionnelles de supervision. Il était aussi cité comme preuve d’un usage réel du système, ou comme base pour dire que Discord stockait les messages avec un volume de stockage « inférieur au pétaoctet ». J’imagine qu’en calculant à partir de la taille et du nombre de nœuds mentionnés dans cet article, l’ancien cluster faisait environ 708 To et la nouvelle installation environ 648 To, avec marge de croissance incluse.
Le stockage lui-même est très bon marché. En revanche, je ne comprends pas bien la partie entraînement et configuration réseau. J’ai lu dans un autre commentaire que les GPU ne sont pas tous au même endroit. Dans ce cas, il faut échanger les données d’entraînement entre plusieurs sites avec seulement du 100 Gbit/s. J’ai peur que cela ne crée un goulot d’étranglement pendant le préentraînement.
Avec une charge de travail de cette taille, il est tout à fait possible d’obtenir des devis privés chez AWS ou d’autres clouds. Dans le cas de S3, il est possible d’avoir un devis distinct dès 0,5 Po. Cela ne veut pas dire que le coût total serait inférieur au fait de tout gérer soi-même, mais comparer les prix retail d’un CSP avec du matériel acheté sur eBay + du travail gratuit (hors pizza) n’est pas une comparaison entièrement équitable.
Sur AWS ou dans le cloud, le vrai sujet clé, c’est le coût d’egress. Même en essayant de négocier, ils ne lâchent absolument rien sur ce point. Pour l’entraînement IA, c’est à un niveau pratiquement inutilisable. Les devis de Cloudflare sont parmi les moins chers pour du stockage objet en bucket managé. En construisant son propre cluster, l’écart avec les services managés s’est réduit, et le fait de construire soi-même donne aussi un certain pouvoir de négociation. Cela dit, les buckets managés sont largement surdimensionnés pour du simple stockage de préentraînement. Glacier offre un bon rapport coût/efficacité pour l’archivage, mais il n’existe pas encore de produit vraiment adapté à l’usage ML.
Tu penses à quel genre d’accord concrètement ? On peut vraiment obtenir plus de 50 % de réduction ?
J’ai pris plaisir à participer à l’installation des disques. Manipuler réellement un tel volume de données, c’est l’expérience la plus excitante :P
Aucune mention du taux de panne des disques. Je suis curieux de savoir dans quel état est le système après quelques mois.
J’avais déjà partagé une expérience similaire : lors de la mise en place de plusieurs baies de disques, nous avons eu une vague massive de pannes. Nous avions terminé l’installation dans le rack un vendredi après-midi, puis laissé tourner tout le week-end un simple script shell de test de lecture/écriture sans y toucher. En revenant le lundi, presque la moitié des disques étaient morts, sans aucun log. Impossible de savoir s’il y avait eu un problème de striping, si le stress test les avait fait lâcher, ou autre chose. C’était un lot défectueux en sortie d’usine, et plusieurs clients du même fournisseur s’étaient plaints. Le fabricant a tout remplacé, et seul le passage en production a été retardé. Après cela, plus aucune panne pendant un an.
Le taux de panne des disques a énormément baissé au cours des dix dernières années. Avant, on en remplaçait parfois plus de dix par semaine ; aujourd’hui, c’est rare. À mon avis, il suffit de regarder les statistiques de disques durs de Backblaze.
Ils ont dit que ce cluster utilisait des disques enterprise ; à vouloir économiser à court terme, on risque d’y perdre gros ensuite. J’ai essayé d’utiliser des disques d’occasion pour un serveur perso, et la variabilité de performances était tellement forte que ce n’était pas terrible.
Bonne remarque.