Cost, Billing, and Ops13 octobre 2026Flatkey Team

Architecture de cluster GPU : calcul, réseau, stockage et plan de contrôle

Un guide pratique d’architecture de cluster GPU pour les nœuds de calcul, le réseau, le stockage, le plan de contrôle Kubernetes ou Slurm, l’observabilité et les tests d’acceptation.

L’architecture d’un cluster GPU, c’est la forme de l’ensemble du système, pas seulement le nombre de GPU. Un cluster de production doit coordonner les nœuds de calcul, le réseau haut débit, le stockage, un ordonnanceur, les contrôles d’accès, la télémétrie et les chemins de récupération avant de pouvoir transformer des accélérateurs coûteux en entraînements utiles ou en inférence fiable.

La question pratique est simple : votre équipe peut-elle déplacer les données, planifier les jobs, récupérer après les échecs et mesurer les coûts assez vite pour garder les GPU occupés ? Sinon, un cluster doté de meilleures cartes peut tout de même offrir une économie moins bonne qu’un service GPU managé plus petit ou qu’une API de modèle.

Ce guide donne aux équipes de plateforme IA un modèle de travail pour l’architecture de cluster GPU : ce qui appartient à la couche de calcul, ce que le réseau doit prouver, comment le stockage et le checkpointing s’intègrent, comment Kubernetes ou Slurm devient le plan de contrôle, et quoi tester avant de louer ou d’acheter une capacité multi-nœuds.

La règle pratique de Flatkey est de commencer par la limite de la charge de travail. Si le produit n’a besoin que de sorties de modèle, évaluez d’abord un parcours cloud GPU vs API de modèle. Si vous avez besoin de poids personnalisés, de contrôle du placement, d’un entraînement de longue durée ou d’une infrastructure de service privée, concevez alors le cluster GPU autour des exigences de calcul, de réseau, de stockage et de plan de contrôle de la charge de travail.

Réponse rapide sur l’architecture de cluster GPU

Un cluster GPU utile comporte quatre plans :

Plan	Ce qu’il gère	Panne fréquente en cas d’omission
Calcul	Serveurs GPU, ratio CPU/RAM, NVMe local, topologie GPU, pilotes, CUDA, conteneurs, allocation MIG ou GPU complet	L’équipe achète le bon modèle de GPU mais la mauvaise forme de nœud, la mauvaise configuration mémoire ou la mauvaise pile de pilotes.
Réseau	NVLink/NVSwitch intra-nœud, InfiniBand inter-nœuds, RoCE, EFA, Ethernet, placement, DNS, ingress, limites de service mesh	Les jobs multi-nœuds passent à l’échelle de façon médiocre parce que le « réseau rapide » n’a jamais été validé avec un vrai all-reduce ou du trafic de service.
Stockage	Préparation des jeux de données, poids de modèle, écritures de checkpoint, système de fichiers partagé, stockage objet, scratch local, snapshots, sauvegarde, nettoyage	Les GPU restent inactifs pendant le chargement des données, les checkpoints bloquent l’entraînement, ou la reprise après redémarrage prend trop de temps.
Plan de contrôle	Kubernetes, Slurm, Kueue, Volcano, Ray, accès utilisateur, quotas, observabilité, balises de facturation, politique de sécurité, réponse aux incidents	Les jobs s’exécutent, mais personne ne peut expliquer le temps d’attente en file, l’équité d’allocation, les échecs ou le coût unitaire.

Une architecture de cluster gpu multi-nœuds réussit lorsque ces plans sont conçus ensemble. Un calcul sans fabric est une capacité isolée. Une fabric sans stockage ne fait que déplacer les goulots d’étranglement. Kubernetes sans quota, télémétrie et runbooks n’est qu’un mécanisme de lancement.

Diagramme d’architecture de cluster GPU

Utilisez ce diagramme comme cadre de revue avant de comparer des fournisseurs ou d’approuver la conception d’un rack.

                  utilisateurs / CI / trafic produit / clients API
                                  |
                                  v
        +------------------------------------------------------+
        | plan de contrôle                                     |
        | Ordonnanceur Kubernetes ou Slurm, files, quotas,     |
        | secrets, accès au registre, politique, télémétrie,   |
        | facturation                                          |
        +------------------------------------------------------+
              |                    |                    |
              v                    v                    v
   +-------------------+   +-------------------+   +-------------------+
   | nœud de calcul gpu|   | nœud de calcul gpu|   | nœud de calcul gpu|
   | GPUs, CPU, RAM,   |   | GPUs, CPU, RAM,   |   | GPUs, CPU, RAM,   |
   | NVMe local, NICs  |   | NVMe local, NICs  |   | NVMe local, NICs  |
   +-------------------+   +-------------------+   +-------------------+
              \                  |                  /
               \                 |                 /
                v                v                v
        +------------------------------------------------------+
        | fabric haut débit                                   |
        | NVLink/NVSwitch à l’intérieur du nœud ; InfiniBand, |
        | RoCE, EFA, ou Ethernet entre les nœuds ; placement  |
        | et routage                                           |
        +------------------------------------------------------+
                                  |
                                  v
        +------------------------------------------------------+
        | stockage et chemin des données                       |
        | stockage objet, système de fichiers partagé, scratch |
        | local, cache de modèle, checkpoints, snapshots,      |
        | sauvegardes                                          |
        +------------------------------------------------------+

Pour un diagramme d’architecture de cluster gpu Kubernetes, ajoutez les objets spécifiques à Kubernetes autour du plan de contrôle :

administrateurs du cluster -> images de nœuds -> GPU Operator / plugin de périphérique -> nœuds GPU
équipes applicatives       -> namespace -> quota -> file de jobs -> Pod / Job / RayJob
finance                     -> labels -> export d’utilisation -> coût par job / équipe / modèle
sécurité                    -> secrets -> politique d’image -> politique réseau -> journaux d’audit

Le diagramme est volontairement simple. Le but n’est pas de représenter chaque service. Le but est d’identifier les responsabilités manquantes avant que le cluster ne devienne une dépendance de production.

Commencez par la charge de travail, pas par le rack

Avant de choisir Kubernetes, Slurm, une réservation cloud ou un fournisseur bare metal, rédigez une fiche de charge de travail d’une page.

Champ	Ce qu’il faut définir
Type de charge de travail	Pré-entraînement, ajustement fin, inférence par lots, inférence en ligne, embeddings, récupération, génération d’images/vidéos, simulation ou notebooks de recherche.
Framework	PyTorch, JAX, TensorFlow, vLLM, SGLang, TensorRT-LLM, Ray, Slurm, Kubernetes Jobs ou services personnalisés.
Cible GPU	H100, H200, B200, A100, L40S, RTX PRO, séries AMD MI, ou une plage acceptable.
Forme du nœud	GPU par nœud, mémoire GPU, cœurs CPU, RAM système, NVMe local, nombre de NIC et enveloppe de puissance.
Forme de mise à l’échelle	Nœud unique, entraînement synchrone multi-nœuds, inférence sharded, file de traitement par lots ou plateforme mixte.
Sensibilité réseau	Performances all-reduce requises, tolérance à la latence, besoins en groupes de placement, isolation du trafic et chemin de sortie.
Sensibilité au stockage	Taille du jeu de données, taille des poids du modèle, fréquence des checkpoints, cible de restauration, besoins du système de fichiers et région du stockage objet.
Périmètre d’exploitation	Qui possède les pilotes, les images, la politique du planificateur, la télémétrie, le support, les correctifs, l’accès utilisateur et la réponse aux incidents.
Dénominateur métier	Coût par exécution d’entraînement terminée, coût par sortie d’inférence acceptée, utilisation en GPU-heure ou mois GPU réservé.

Si vous ne pouvez pas remplir ce tableau, ne signez pas encore un contrat de capacité long. Louez une tranche plus petite, exécutez des benchmarks et transformez les logs en note d’achat. Le guide de location de cluster GPU fournit la liste de contrôle côté acheteur une fois que la forme de l’architecture est claire.

Plan de calcul : les nœuds GPU ne sont pas interchangeables

Le plan de calcul définit ce qu’un job peut réellement utiliser. Une spécification de calcul complète comprend plus que « 8x H100 » ou « cluster B200 ».

Demandez :

Le modèle de GPU, la taille de la mémoire et PCIe versus SXM le cas échéant.
Le nombre de GPU par nœud et la topologie intra-nœud.
Le modèle de CPU, le nombre de CPU, la RAM système et la disposition NUMA.
La capacité NVMe locale et le débit attendu.
Le nombre de NIC, la vitesse des NIC et la prise en charge éventuelle des chemins GPU-direct.
Le cycle de vie du pilote, de CUDA, du runtime de conteneurs et de l’image OS.
La politique d’allocation MIG, vGPU, time-slicing ou GPU complet.
L’homogénéité des nœuds et la politique de remplacement.

La topologie intra-nœud est importante parce que huit GPU dans un serveur ne sont pas équivalents à huit nœuds à GPU unique. La conception du nœud détermine la pression mémoire, les goulots d’étranglement CPU, la vitesse de staging local et le coût des communications inter-nœuds.

La documentation de l’opérateur GPU Kubernetes de NVIDIA est utile ici, car elle montre comment les pilotes, le NVIDIA Container Toolkit, le device plugin, la télémétrie DCGM et les composants associés peuvent être gérés comme une pile de cluster plutôt que comme une configuration ponctuelle de nœud. La documentation du device plugin Kubernetes explique le point d’extension général utilisé pour exposer les périphériques du fournisseur comme ressources planifiables.

Plan réseau : prouvez le fabric avec un benchmark

L’entraînement multi-nœuds et le serving à haut débit dépendent du réseau. Une spécification de cluster doit indiquer le fabric et le test d’acceptation, et pas seulement le chiffre de bande passante.

Demandez :

Les détails NVLink ou NVSwitch intra-nœud.
La conception InfiniBand, RoCE, EFA ou Ethernet inter-nœuds.
Le nombre et la vitesse des NIC par nœud.
La garantie de placement et le domaine de défaillance.
Le ratio de sursouscription.
La prise en charge de GPUDirect RDMA le cas échéant.
Le modèle de mise en réseau des conteneurs et de l’hôte.
L’observabilité des erreurs de fabric, des retransmissions, de la congestion et des pannes de nœuds.

Utilisez un test d’acceptation avant le début de l’engagement :

test d’acceptation réseau :
  exécuter NCCL all_reduce sur chaque nœud loué
  enregistrer la bande passante, la latence, les IDs de nœud, le modèle GPU, le pilote, CUDA, la version NCCL
  répéter après installation de l’image de conteneur de production
  sauvegarder les logs et les comparer à la topologie annoncée par le fournisseur

NVIDIA NCCL et les tests NCCL sont des références standard pour valider le comportement des communications collectives dans les charges de travail GPU distribuées. L’objectif n’est pas de courir après un seul chiffre de benchmark. L’objectif est de détecter des nœuds mal assortis, un mauvais placement, de la congestion du fabric ou une dérive du pilote/du conteneur avant qu’une exécution d’entraînement complète n’échoue.

Pour l’inférence, le test réseau doit inclure le chemin réel du trafic : entrée des requêtes, communication entre fragments du modèle, comportement du KV-cache le cas échéant, récupérations depuis le stockage et sortie. Un fabric d’entraînement qui semble solide en isolation peut quand même produire une mauvaise latence utilisateur si la pile de serving traverse trop de frontières réseau.

Plan de stockage : garder les données, poids et checkpoints hors du chemin critique

Le stockage est l’endroit où de nombreux plans d’architecture de cluster GPU deviennent coûteux. Le devis GPU est visible. Le chemin de données est souvent caché jusqu’à la première exécution en production.

Concevez le stockage autour de quatre flux :

Flux	Question d’architecture
Staging du jeu de données	Combien de temps faut-il pour déplacer le jeu de données depuis le stockage objet, le système de fichiers distant ou l’entrepôt de données vers les nœuds ?
Poids du modèle	Où sont mis en cache les poids de base, les poids ajustés, les fichiers tokenizer et les artefacts du moteur ?
Checkpoints	À quelle fréquence les checkpoints sont-ils écrits, quelle est leur taille et combien de temps prend la restauration après une panne de nœud ?
Sorties et journaux	Où vont les artefacts générés, les métriques, les traces et les journaux d’audit, et quelle politique de rétention s’applique ?

Pour l’entraînement, le débit des checkpoints et le temps de restauration sont des sujets d’architecture, pas des détails de sauvegarde. Pour l’inférence, le chargement des poids du modèle, la montée en température du cache local et le comportement des volumes persistants influencent le temps de déploiement et le temps de basculement.

La documentation NVIDIA sur GPUDirect Storage est une source utile lorsque l’architecture nécessite un chemin de données direct entre un stockage local ou distant et la mémoire GPU. Tous les clusters n’ont pas besoin de GPUDirect Storage, mais les équipes qui déplacent de grands ensembles de données ou des checkpoints devraient décider explicitement si la pile de stockage est ordinaire, optimisée, ou un goulot d’étranglement qu’elles acceptent.

Plan de contrôle : Kubernetes, Slurm, ou les deux ?

Le plan de contrôle transforme le matériel en plateforme. Il décide qui peut exécuter quoi, quand les jobs démarrent, comment les échecs sont réessayés, et comment les équipes comprennent l’utilisation.

Architecture de cluster GPU Kubernetes

Kubernetes convient aux plateformes GPU qui ont besoin de déploiement de services, d’espaces de noms multi-locataires, de workflows natifs des conteneurs, d’automatisation pilotée par API, de politiques et d’une intégration avec l’observabilité cloud-native. Une architecture de cluster GPU Kubernetes de production inclut généralement :

Des images de nœuds et l’automatisation du bootstrap.
GPU Operator ou la gestion des pilotes/pilotes de périphérique spécifiques au fournisseur.
Device plugin ou Dynamic Resource Allocation pour l’exposition des GPU.
Espaces de noms, RBAC, secrets, politique de pull des images et politique réseau.
Jobs, Deployments, RayJob, opérateurs d’entraînement ou services d’inférence.
Kueue ou une autre couche de file d’attente lorsque l’équité des traitements par lots est importante.
Quotas par équipe, projet, environnement ou client.
DCGM, Prometheus, journaux, traces et étiquettes de facturation.
Contrôles d’admission pour les images, les charges de travail privilégiées, les montages de l’hôte et le partage des GPU.

Les device plugins Kubernetes exposent les GPU comme ressources étendues. Kubernetes Dynamic Resource Allocation ajoute un modèle de ressources plus riche, basé sur des claims, pour les périphériques et d’autres ressources spécialisées. Kueue ajoute des concepts de file d’attente des jobs tels que workloads, queues, cohorts et resource flavors pour la planification batch et IA/ML. Ensemble, ces outils peuvent transformer un pool de GPU en plateforme gouvernée plutôt qu’en ensemble de machines accessibles en SSH.

Architecture de cluster GPU Slurm

Slurm convient à de nombreux environnements de type HPC et de recherche parce qu’il est construit autour des files d’attente, partitions, accounting, réservations et jobs batch. La documentation GRES de Slurm couvre les ressources GPU et la manière dont les jobs les demandent.

Slurm est souvent un bon choix lorsque :

Les utilisateurs soumettent des jobs batch d’entraînement.
La politique de file d’attente est centrale.
Les équipes disposent déjà d’une expérience d’exploitation HPC.
La charge de travail est moins orientée services.
MPI, les tests NCCL et l’accounting batch sont des primitives opérationnelles familières.

Certaines organisations utilisent les deux : Slurm pour la recherche et les grandes files d’attente d’entraînement, Kubernetes pour les services d’inférence et les API de plateforme. Cela peut fonctionner, mais seulement si l’identité, l’accès aux données, l’observabilité et l’allocation des coûts sont conçus à travers les deux systèmes.

L’observabilité et les contrôles de coûts doivent faire partie de la conception initiale

N’ajoutez pas la télémétrie après la mise en production du cluster. Les questions qui comptent pour l’ingénierie et la finance sont prévisibles :

Quels jobs ont utilisé quels GPU ?
Quel espace de noms, équipe, client, modèle ou expérience a généré la dépense ?
Quelle était l’utilisation utile, et pas seulement le temps GPU alloué ?
Combien de temps a été passé en attente dans la file ?
Quels échecs ont consommé le plus d’heures GPU ?
Quel goulot d’étranglement de stockage ou de réseau a provoqué l’inactivité des GPU ?
Quel était le coût par exécution terminée ou par sortie acceptée ?

La télémétrie minimale devrait inclure :

L’utilisation GPU, l’utilisation mémoire, la puissance, la température et les événements ECC.
Le temps d’exécution par job, le temps d’attente en file, le nombre de reprises, la raison de sortie et le propriétaire.
L’état de santé du fabric réseau et l’historique des benchmarks.
Le débit de stockage, la latence, le temps de checkpoint et le temps de restauration.
Les événements d’allocation du scheduler et les refus de quota.
Les étiquettes de facturation ou les exports d’utilisation liés aux unités métiers.

Le socle modèle/API de Flatkey est important ici. Si une API de modèle managé produit la même sortie acceptée avec un coût unitaire plus clair et moins de charge opérationnelle, le cluster doit surpasser ce socle une fois le temps d’inactivité, les reprises, le stockage et la main-d’œuvre pris en compte.

La sécurité, l’isolation et la conception des accès font partie du design

Les clusters GPU commencent souvent comme projets d’ingénierie et deviennent des infrastructures partagées. Traitez la conception des accès comme faisant partie de l’architecture.

Définissez :

L’authentification et la source d’identité.
L’isolation par espace de noms, projet ou compte.
La politique SSH, le cas échéant.
Le registre d’images de conteneurs, la signature et l’analyse.
La gestion des secrets.
La politique d’egress réseau.
La suppression des données et le nettoyage après les jobs.
La rétention des journaux d’audit.
L’accès d’urgence.
L’accès au support du fournisseur et le workflow d’intervention à distance.

Pour les clusters multi-locataires, décidez si le partage des GPU est autorisé. L’allocation d’un GPU complet est plus simple. MIG, vGPU ou le time-slicing peuvent améliorer l’utilisation, mais ils modifient aussi l’isolation, la télémétrie, la planification et les attentes de performance.

Dimensionnement du cluster : transformer l’architecture en chiffres

Le dimensionnement doit être piloté par l’unité utile :

required_gpu_capacity =
  target_work_completed_per_month
  / useful_work_per_gpu_month_after_failures_idle_and_retries

Puis le tester sous contrainte :

Question de dimensionnement	Pourquoi c’est important
Quel taux d’utilisation est utile, et pas seulement alloué ?	Les réservations inactives et les exécutions échouées n’aident pas la production.
Quel est le temps d’attente maximal acceptable dans la file ?	Un cluster bon marché peut tout de même manquer les fenêtres de lancement ou d’entraînement.
Que se passe-t-il lorsqu’un nœud tombe en panne en cours d’exécution ?	Le temps de redémarrage modifie le débit effectif.
Le modèle peut-il migrer vers une autre classe de GPU ?	Les engagements matériels peuvent survivre à l’architecture du modèle.
Quel est le délai de montée en capacité ?	La demande en GPU peut évoluer plus vite que les achats.
Quelle est la voie de sortie ?	La revente, la résiliation du contrat, le nettoyage des données et le coût de migration doivent entrer dans la décision.

Pour un modèle de coût, reliez cet article à votre feuille de calcul TCO de cluster GPU :

effective_cluster_unit_cost =
  (compute + network + storage + support + operations + idle + retries)
  / accepted workload units

Le dénominateur doit correspondre au produit : exécutions d’entraînement terminées, jetons d’inférence acceptés, tâches de génération média, mises à jour d’index de recherche ou demandes clients.

Liste de verification de l'architecture

Utilisez cette checklist avant d’approuver un schéma d’architecture de cluster GPU multi-nœuds ou un devis de fournisseur.

Zone	Condition de réussite
Résumé de la charge de travail	L’équipe a défini le modèle, le framework, la forme d’échelle, le chemin des données, la cible d’utilisation et le dénominateur métier.
Calcul	La forme du nœud inclut la topologie GPU, le CPU/la RAM, le NVMe local, les NIC, le cycle de vie du pilote/CUDA et la politique de remplacement.
Réseau	Le type de fabric, le placement, la sursouscription, les domaines de défaillance et le benchmark NCCL ou de service sont documentés.
Stockage	La préparation du jeu de données, le cache des poids, l’écriture/restauration des checkpoints, le stockage objet, les snapshots et le nettoyage sont testés.
Planificateur	Kubernetes, Slurm ou une architecture mixte ont une responsabilité claire pour les files d’attente, les quotas, les tentatives et l’accès utilisateur.
Observabilité	Les jobs, les GPU, le fabric, le stockage et les coûts sont visibles par équipe et par charge de travail.
Sécurité	L’identité, les secrets, la politique d’image, la politique réseau, les journaux d’audit et le nettoyage des données sont définis.
Test d’acceptation	Le fournisseur ou l’équipe interne peut exécuter le conteneur de production, benchmarker le réseau, écrire et restaurer des checkpoints, et exporter les journaux.
Économie unitaire	Le cluster est comparé à la location cloud, à la colocation, à l’on-premises et aux bases de référence modèle/API en utilisant le même dénominateur.

Références officielles à garder ouvertes

Utilisez les documents officiels comme vérifications de source pendant la revue d’architecture :

Source	À utiliser pour
Kubernetes device plugins	Comment du matériel spécialisé comme les GPU est exposé à l’ordonnancement Kubernetes.
Kubernetes Dynamic Resource Allocation	Modèle d’allocation fondé sur des claims pour les ressources spécialisées.
NVIDIA GPU Operator	Gestion du pilote, du runtime de conteneur, du device plugin, de MIG et de la télémétrie GPU pour Kubernetes.
NVIDIA NCCL documentation et NCCL tests	Communication distribuée et validation pratique de all-reduce.
NVIDIA GPUDirect Storage	Considérations sur le chemin des données du stockage vers le GPU pour les grands volumes de données et les flux de checkpoints.
Kueue concepts	Concepts de mise en file d’attente natifs Kubernetes pour les charges de travail batch et IA/ML.
Slurm GRES	Ressources GPU, comptabilisation et demandes de jobs dans Slurm.

Considérez-les comme des références d’architecture, et non comme un substitut aux tests d’acceptation sur le cluster exact que vous allez utiliser.

Quand un cluster GPU n’est pas la bonne architecture

Ne construisez pas ou ne réservez pas un cluster uniquement parce que le prix à l’heure GPU semble attractif. Un cluster GPU direct peut être la mauvaise architecture lorsque :

Le produit n’a besoin que des sorties du modèle.
Le mix de modèles change chaque semaine.
L’équipe ne peut pas gérer les pilotes, les ordonnanceurs, le stockage, le réseau et les incidents.
La charge de travail est irrégulière et peu utilisée.
Les mouvements de données dominent le calcul.
L’approvisionnement veut un engagement de trois ans avant l’existence de preuves de benchmark.
La finance ne peut pas relier les dépenses du cluster aux sorties acceptées.

Dans ces cas, comparez d’abord les prix de location GPU cloud, le GPU serverless ou une API de modèle. La bonne architecture est celle qui fournit une sortie acceptée fiable au coût opérationnel total le plus bas, et non celle qui possède le plus grand parc d’accélérateurs. Pour une analyse du marché au niveau des fournisseurs, utilisez la comparaison des clouds GPU avant de demander des devis.

Conclusion finale

Une architecture de cluster GPU solide est une conception système : des nœuds de calcul adaptés à la charge de travail, une infrastructure réseau validée par des benchmarks, un stockage qui ne limite pas les GPU, et un plan de contrôle capable de planifier, sécuriser, observer et refacturer l’utilisation.

Pour de petites expérimentations, commencez par la location ou par des API managées. Pour un entraînement multi-nœuds sérieux ou une inférence privée, utilisez le schéma et la liste de vérification ci-dessus avant de vous engager auprès d’un fournisseur, d’un rack ou d’une réservation. L’erreur coûteuse n’est pas de choisir Kubernetes plutôt que Slurm, ni un H100 plutôt qu’un H200. L’erreur coûteuse consiste à acheter de la capacité GPU avant que l’architecture ait prouvé qu’elle peut transformer cette capacité en travail utile.