Architecture d'exécution des modèles IA
Projet Innovation & IA

Plateforme IA on-premises

Deux accélérateurs H200 partitionnés en huit instances, pilotés par Kubernetes, pour exécuter plusieurs modèles d'IA en interne — sans qu'aucune donnée ne sorte, et sans rien installer sur l'hôte.

Architecture, intégration et exploitation 2026 2 janvier 2026 13 vues
Plateforme d'exécution de modèles d'IA générative hébergée en interne, construite autour de deux accélérateurs NVIDIA H200 partitionnés en instances MIG et pilotés par Kubernetes. L'objectif : faire tourner plusieurs modèles simultanément — chat, embeddings, OCR, audio — sur une même machine, avec une exploitation déclarative, réversible, et sans qu'aucune donnée ne quitte l'organisation.

Garder les données à l'intérieur

C'est la raison première. Dès qu'un service interne envoie du texte à une API externe, ce texte sort de l'organisation. En interne, la question ne se pose plus — ce qui débloque des projets qui n'auraient jamais passé le stade de l'étude.

Mutualiser un accélérateur entre plusieurs modèles

Une carte de 141 Go découpée en partitions matériellement isolées permet d'héberger un gros modèle de chat, un modèle moyen et plusieurs petits — sans qu'ils se ralentissent mutuellement.

Une exploitation déclarative et réversible

Aucun runtime d'IA installé sur l'hôte : un service correspond à un fichier YAML, un modèle à un dossier. On ajoute sans casser, on retire sans laisser de trace.

Fonctionner en circuit fermé

Les modèles sont téléchargés une fois, lors d'une ouverture réseau temporaire, puis la plateforme bascule en mode hors ligne — ce qui la rend indépendante d'Internet en exploitation.

Contexte & Problématique

Consommer un modèle par API est simple et, à faible volume, imbattable. L'internalisation se justifie quand certaines données ne doivent pas sortir, quand le volume rend la facturation à l'usage pénalisante, ou quand la reproductibilité des traitements devient une exigence.

Des données qui ne peuvent pas sortir

Documents internes, données personnelles, éléments couverts par le secret professionnel : le traitement local n'est pas un confort, c'est parfois la seule voie possible.

Un coût qui cesse d'être proportionnel

Un assistant réellement adopté voit sa facture croître avec son succès. Un serveur est un coût fixe : au-delà d'un certain volume, l'usage marginal devient gratuit — ce qui change les usages.

Un accélérateur qu'il faut partager

Dédier une carte entière à un seul modèle est un gâchis. Sans isolation matérielle, plusieurs modèles sur une même carte se disputent la mémoire et se dégradent mutuellement.

Le risque de la machine fourre-tout

Un serveur d'IA où l'on finit par installer runtimes, environnements Python et dépendances devient rapidement impossible à diagnostiquer et à remettre à neuf.

Réalisation

La plateforme repose sur trois décisions structurantes : partitionner le matériel, laisser l'orchestrateur distribuer les partitions, et n'exécuter les modèles que dans des conteneurs.
  1. 1. Partitionner les accélérateurs

    Chaque carte est découpée en quatre instances MIG — une grande, une moyenne, deux petites — soit huit partitions au total. La découpe est choisie à partir des modèles à héberger, car elle ne se modifie pas à chaud.

  2. 2. Exposer les partitions à Kubernetes

    Le GPU Operator et le device plugin annoncent chaque profil comme une ressource distincte. Point de passage obligé : la stratégie MIG doit être en mode « mixed », faute de quoi rien n'est exposé dès qu'on utilise plusieurs profils.

  3. 3. Organiser le stockage des modèles

    Un dossier par modèle sur le disque de l'hôte, un fichier YAML par service. Les modèles sont téléchargés une seule fois, jamais depuis un pod — sans quoi chaque redémarrage retéléchargerait des dizaines de gigaoctets.

  4. 4. Maîtriser le cycle réseau

    Ouverture temporaire du proxy pour récupérer poids et images, puis fermeture et bascule en mode hors ligne dans les pods. Tout ce qui a été ouvert pour déployer est refermé après.

  5. 5. Déployer les modèles

    Un moteur d'inférence par pod, une partition MIG par pod, les modèles montés en lecture seule, et une API compatible OpenAI exposée par un service Kubernetes aux applications internes.

  6. 6. Exploiter

    Suivi des pods, lecture des journaux au premier démarrage — c'est là qu'apparaissent les erreurs de mémoire —, vérification des services et des points de terminaison, et suppression propre d'un service en une commande.

Stack technique

Matériel

2 × NVIDIA H200 NVL (141 Go HBM3e) MIG : 2×3g.71gb 2×2g.35gb 4×1g.18gb

Orchestration

K3s NVIDIA GPU Operator device plugin stratégie MIG mixed ClusterPolicy

Moteurs d'inférence

vLLM (API compatible OpenAI) architecture ouverte à Ollama et autres runtimes

Modèles et stockage

Stockage local NVMe un dossier par modèle montage en lecture seule cache persistant

Sécurité et réseau

Proxy filtrant ouvertures temporaires mode hors ligne autorités internes injectées par ConfigMap

Résultats & Impact

La plateforme héberge simultanément plusieurs modèles — chat généraliste, embeddings pour la recherche documentaire, OCR, audio — accessibles aux applications internes par une API standard, sans qu'aucune donnée ne quitte l'infrastructure.
8
partitions GPU indépendantes sur deux cartes
141 Go
de mémoire par carte, ce qui décide des modèles hébergés
0
runtime d'IA installé sur le système hôte
1
fichier YAML par service, versionné et supprimable

Plusieurs modèles, sans interférence

L'isolation MIG est matérielle : un modèle qui sature sa partition ne ralentit pas les autres, et un plantage reste confiné.

Un hôte resté diagnosticable

Aucun service d'IA installé sur le système : le serveur reste compréhensible, et l'on distingue un problème de plateforme d'un problème de modèle.

Une exploitation en circuit fermé

Mode hors ligne activé dans les pods : la plateforme fonctionne sans accès Internet, et les résultats restent reproductibles.

Des règles écrites, pas implicites

Un manifeste d'administration fixe les principes non négociables — pas d'installation sur l'hôte, pas de téléchargement dans un pod, une partition par pod, tout service versionné et supprimable.

Galerie

Retour au portfolio