La plateforme souveraine sous vos modèles d'IA
Faire tourner des modèles open-weights, les affiner sur vos données internes ou donner à vos équipes data une capacité GPU privée pose les mêmes questions que tout cloud souverain : où vivent les données et les poids du modèle, qui y accède, ce que cela coûte en régime établi, et comment vous en sortiriez. OpenStack y répond avec du calcul GPU, du stockage et une isolation qui vous appartiennent. Nous vous aidons à décider si cela en vaut la peine pour vous, et à le concevoir si c'est le cas.
Où nous en sommes, honnêtement
Nous n'avons pas encore exploité de cluster GPU sous OpenStack en production pour un client, et nous ne publions donc aucun retour d'expérience sur ce sujet. Ce que nous apportons aujourd'hui : l'étude d'opportunité, le dimensionnement et la conception, adossés à notre pratique en production d'OpenStack, de Ceph et de Kolla-Ansible et à la documentation officielle. Le premier pilote GPU est cadré comme un pilote, avec des chiffres mesurés, avant tout engagement de programme.
Trois raisons réalistes d'internaliser des workloads IA
Tous les workloads IA n'ont pas leur place sur vos propres GPU. Ces trois-là oui, quand la sensibilité des données ou un usage régulier fait du cloud public le mauvais choix par défaut.
Inférence de modèles open-weights
Servir Llama, Mistral, Qwen ou des modèles métier derrière votre propre API pour des assistants, du traitement documentaire ou de la génération de code. Prompts et réponses ne quittent jamais votre périmètre ; les coûts sont fixes plutôt qu'au token.
Fine-tuning sur données internes
Adapter un modèle de base à votre vocabulaire, vos procédures ou votre historique client. Le jeu d'entraînement est souvent l'actif le plus sensible que vous possédez ; le garder, ainsi que les poids obtenus, sur une infrastructure que vous contrôlez est une décision de gouvernance, pas une préférence technique.
Capacité GPU privée pour les équipes data
Un pool en libre-service d'instances GPU avec projets, quotas et réservations, pour que les équipes recherche et produit cessent de se disputer une station partagée ou de remplir une demande d'achat cloud pour chaque expérimentation.
GPU du cloud public ou les vôtres ? Une grille honnête
L'étude d'opportunité répond à chaque ligne avec vos chiffres. Si la réponse est « restez dans le cloud », nous le disons.
| Critère | Plaide pour vos GPU sous OpenStack | Plaide pour le cloud public |
|---|---|---|
| Profil d'usage | Inférence continue ou fine-tuning récurrent, GPU occupés la plupart du temps | Expérimentations en rafale, quelques gros entraînements par an |
| Sensibilité des données | Données réglementées, classifiées ou contractuellement confinées ; poids du modèle considérés comme un secret d'affaires | Données publiques ou synthétiques, aucune contrainte de résidence |
| Taille des modèles | Modèles tenant sur un à quelques GPU (classe 7B à 70B, quantifiés si besoin) | Pré-entraînement à l'échelle frontière nécessitant des centaines de GPU interconnectés |
| Plateforme existante | Une plateforme OpenStack et Ceph déjà exploitée en interne : les GPU deviennent une classe de calcul de plus | Aucun cloud privé et aucune équipe pour l'exploiter |
| Infrastructure physique | Datacenter ou colocation souveraine disposant de l'alimentation et du refroidissement qu'exigent les serveurs GPU | Aucune salle adaptée, ou un délai d'approvisionnement matériel que vous ne pouvez pas absorber |
| Réversibilité | Vous voulez pouvoir changer de fournisseur matériel, de modèle ou d'hébergement sans réécrire la pile | La dépendance aux services IA managés d'un seul fournisseur est acceptable |
Les GPU deviennent une ressource de plus de la plateforme que vous gouvernez déjà
Les mêmes projets, quotas, identités, réseaux et stockage qui servent vos machines virtuelles servent vos workloads IA. Pas de seconde plateforme, pas de seconde équipe, pas de second périmètre d'audit.
Guide technique : GPU passthrough et vGPU avec Nova →Trois façons d'exposer un GPU
Carte entière à une instance (passthrough), tranches partagées avec les pilotes du constructeur (vGPU ou MIG), ou nœud bare metal quand le framework a besoin du matériel en direct.
Un stockage taillé pour les datasets
Volumes bloc Ceph pour les checkpoints, systèmes de fichiers partagés pour les jeux d'entraînement, stockage objet pour les registres de modèles, tous sous les mêmes quotas et politiques de chiffrement.
Kubernetes là où les outils l'attendent
Des clusters provisionnés sur des instances GPU, avec le GPU Operator pour l'ordonnancement et vLLM, Ray ou Kubeflow au-dessus. Vos équipes data gardent l'outillage qu'elles connaissent.
Isolation et réservations
Un projet par équipe ou par niveau de sensibilité, quotas GPU, réservations bornées dans le temps pour les campagnes d'entraînement, et la même chaîne d'observabilité que le reste de la plateforme.
Les réalités matérielles que l'étude chiffre
Coût et délai des GPU
Les GPU datacenter sont chers et sous contrainte d'approvisionnement. L'étude compare le coût complet sur trois à cinq ans avec votre facture cloud réelle, pas avec des prix catalogue.
Alimentation et refroidissement
Un serveur GPU consomme plusieurs kilowatts. Densité par rack, refroidissement et capacité électrique sont validés avec vos équipes infrastructure avant toute commande matérielle.
Licences des pilotes
Donner un GPU entier à une instance est gratuit ; partager une carte entre instances avec le logiciel vGPU du constructeur est une licence payante. Le choix change à la fois le budget et le modèle d'exploitation.
Réseau pour l'entraînement multi-GPU
Entraîner sur plusieurs nœuds exige des interconnexions à faible latence et haut débit. L'inférence et le fine-tuning mono-nœud, généralement pas. Dimensionner le réseau sur le workload réel évite la surdépense la plus fréquente.
Étude d'opportunité
Inventaire des workloads IA et de leurs données, profil d'usage, dépense cloud actuelle, contraintes réglementaires, vérification des locaux. Livrable : une recommandation go / no-go avec vos chiffres, y compris « restez dans le cloud » quand c'est la réponse honnête.
Conception et dimensionnement
Modèle d'exposition des GPU, flavors et quotas, organisation du stockage pour datasets et checkpoints, réseau, intégration Kubernetes, observabilité, sécurité et plan de réversibilité. Nomenclature matérielle validée avec vos fournisseurs.
Pilote mesuré
Un ou deux nœuds GPU sur votre OpenStack, un workload réel d'inférence ou de fine-tuning, débit, coût et exploitabilité mesurés. C'est seulement ensuite qu'un programme est dimensionné. C'est de ce pilote que viendront nos premiers chiffres terrain sur ce sujet.
Ce que vos équipes reçoivent
Un rapport d'opportunité avec une recommandation claire, une architecture cible, un modèle de dimensionnement et de coût sur plusieurs années, une checklist matériel et licences, un plan de pilote avec critères de recette, et le plan de réversibilité écrit avant la commande du premier GPU.
Questions fréquentes
Construisez-vous ou entraînez-vous les modèles eux-mêmes ?
Non. La data science, le choix des modèles et leur évaluation restent à vos équipes ou à votre partenaire IA. Notre périmètre est la plateforme en dessous : calcul GPU, stockage, isolation, intégration Kubernetes et exploitation sur OpenStack.
Peut-on commencer petit ?
C'est la seule façon que nous recommandons. Un ou deux nœuds GPU ajoutés à un OpenStack existant, un workload réel, des résultats mesurés. La plateforme est conçue pour qu'ajouter des nœuds ensuite soit une décision d'achat, pas une refonte.
Nous n'avons pas OpenStack aujourd'hui. Est-ce que cela s'applique quand même ?
Oui, mais l'étude le pèsera honnêtement : une plateforme GPU est rarement, à elle seule, une bonne raison d'adopter un cloud privé. Si vous quittez aussi VMware ou consolidez votre infrastructure, les deux décisions se renforcent.
Quels GPU et quel constructeur ?
L'étude est neutre vis-à-vis des constructeurs : le choix suit le workload (mémoire par modèle, besoins de partage, support des frameworks) et la disponibilité, pas un partenariat. Le passthrough fonctionne avec tout GPU PCI ; partager une carte exige le logiciel de virtualisation du constructeur et sa licence.