fGPU OUTSCALE : GPU NVIDIA à la demande pour IA et calcul

Le Flexible GPU (fGPU) est le service OUTSCALE qui permet d’allouer dynamiquement un GPU NVIDIA et de l’attacher à une VM existante, le temps d’une charge IA, ML ou calcul intensif. Contrairement au modèle des familles d’instances GPU intégrées des hyperscalers, le fGPU est une ressource indépendante : vous l’allouez, vous l’attachez à la VM de votre choix, vous le détachez et le libérez quand la charge se termine. Particularité OUTSCALE : les modèles A100 et V100 sont qualifiés SecNumCloud 3.2, ce qui rend possible l’IA souveraine sur des données sensibles. Page tagguée pour les piliers Well-Architected Performance, Cost et Sovereignty.

Ce que vous allez apprendre

Le modèle Flexible GPU d’OUTSCALE — allocation et attachement séparés, contrairement aux familles GPU intégrées des hyperscalers.
Les modèles disponibles (NVIDIA A100, V100, P100, P6, K2) et leurs cas d’usage.
Allouer et attacher un fGPU à une VM via oapi-cli.
Détacher et libérer un fGPU pour limiter le coût.
Comprendre les contraintes : compatibilité avec la génération CPU de la VM, sous-région, redémarrage de la VM nécessaire à l’attachement.
La position SecNumCloud 3.2 des modèles A100 et V100 pour les charges IA souveraines.

Prérequis

Avoir lu Calcul — instances TINA et sizing — un fGPU s’attache à une VM existante.
Connaître le vocabulaire OUTSCALE ↔ AWS — fGPU est un service Outscale-spécifique sans équivalent AWS direct.
oapi-cli configuré avec un compte ayant les permissions EIM nécessaires sur flexiblegpu:*.

Le Flexible GPU en deux phrases

Un fGPU est une ressource GPU NVIDIA que vous allouez dans une sous-région, puis que vous attachez à une VM existante de la même sous-région. Le GPU devient alors visible côté OS comme un périphérique NVIDIA standard (utilisable avec les drivers et CUDA).

Cette séparation entre allocation et attachement est la particularité d’OUTSCALE : vous pouvez détacher un fGPU d’une VM et le réattacher à une autre, ce qui n’est pas possible sur les familles d’instances GPU intégrées (où le GPU fait partie de l’instance). Le fGPU survit indépendamment des VMs auxquelles il est attaché tour à tour — utile pour des workflows par phases (entraînement nocturne sur une VM puissante, inférence diurne sur une VM légère).

Modèles disponibles

OUTSCALE propose plusieurs modèles de GPU NVIDIA, adaptés à différents profils de charge.

Modèle	Génération NVIDIA	Cas d’usage principal	Note
`nvidia-a100`	Ampere	Entraînement de grands modèles IA, LLM, calcul HPC haut de gamme	Qualifié SecNumCloud 3.2
`nvidia-v100`	Volta	Entraînement IA / ML standard, inférence haut débit	Qualifié SecNumCloud 3.2
`nvidia-p100`	Pascal	Calcul scientifique, ML mature, charges variées	Disponibilité variable selon sous-région
`nvidia-p6`	Pascal (workstation)	Rendu graphique, visualisation, postes virtuels	—
`nvidia-k2`	Kepler (ancien)	Charges légères de rendu, postes virtuels d’entrée	Génération ancienne

Pour la liste à jour et les caractéristiques détaillées (VRAM, vCPU max, RAM max compatibles), interroger le catalogue fGPU :

oapi-cli ReadFlexibleGpuCatalog

La réponse contient pour chaque modèle : ModelName, VRam (GB), MaxCpu, MaxRam, Generations (générations CPU compatibles).

Workflow — allocation, attachement, détachement, libération

Le cycle de vie d’un fGPU se déroule en quatre étapes.

1. Allouer le fGPU

L’allocation crée le fGPU dans une sous-région sans qu’il soit attaché à une VM. Il existe alors avec l’état allocated.

oapi-cli CreateFlexibleGpu \
  --ModelName "nvidia-v100" \
  --SubregionName "eu-west-2a" \
  --Generation "v6"
# Réponse : FlexibleGpuId (par exemple "fgpu-12345678")

Paramètres :

ModelName (requis) — modèle de GPU.
SubregionName (requis) — la VM cible doit être dans la même sous-région.
Generation (optionnel) — génération CPU de la VM cible. Si non spécifiée, la plus ancienne compatible est sélectionnée.
DeleteOnVmDeletion (optionnel, défaut false) — si true, le fGPU est supprimé automatiquement quand la VM est terminée. Pratique pour des charges éphémères.

2. Attacher à une VM

L’attachement nécessite que la VM soit dans le même Subregion et arrêtée ou autorise un redémarrage.

oapi-cli LinkFlexibleGpu \
  --FlexibleGpuId "fgpu-12345678" \
  --VmId "i-aabbccdd"

L’état du fGPU passe par attaching puis attached. Côté VM, un redémarrage est généralement nécessaire pour que l’OS détecte le nouveau périphérique GPU (plus de détail dans la doc officielle).

3. Utiliser depuis l’OS

Une fois la VM redémarrée, le GPU apparaît dans lspci :

# Sur la VM, vérifier la présence du GPU
lspci | grep -i nvidia
# Exemple de sortie : 01:00.0 3D controller: NVIDIA Corporation V100 ...

# Installer les drivers NVIDIA et CUDA selon votre distribution
# (procédure standard NVIDIA — pas spécifique OUTSCALE)

À partir de là, tout outil GPU (PyTorch, TensorFlow, CUDA, frameworks d’inférence) fonctionne nativement.

4. Détacher et libérer

Quand la charge se termine, détacher puis supprimer le fGPU pour ne plus payer.

# Détacher
oapi-cli UnlinkFlexibleGpu --FlexibleGpuId "fgpu-12345678"
# L'état passe par detaching puis revient à allocated

# Supprimer définitivement
oapi-cli DeleteFlexibleGpu --FlexibleGpuId "fgpu-12345678"

Important sur la facturation : le fGPU est facturé tant qu’il existe dans votre compte (état allocated même non attaché compte). Pour des charges ponctuelles, libérer immédiatement après usage.

Position SecNumCloud 3.2 — IA souveraine

Les modèles A100 et V100 d’OUTSCALE sont qualifiés SecNumCloud 3.2 sur la région cloudgouv-eu-west-1 — qualification ANSSI étendue par OUTSCALE pour couvrir les charges IA. Cela rend possible :

L’entraînement de modèles IA sur des données sensibles (santé, défense, secret industriel) dans un environnement qualifié SecNumCloud.
L’hébergement de LLM ou modèles fine-tunés sur des données réglementées, sans exposition aux juridictions extra-européennes.
L’inférence sur des données patients ou des cas d’usage sectoriels qui exigent une qualification stricte.

Pour les charges qui n’ont pas d’exigence SecNumCloud forte, les fGPU restent disponibles sur eu-west-2 (région commerciale), avec une disponibilité plus large des modèles.

Allouer plusieurs fGPU sur la même VM

Plusieurs fGPU peuvent être attachés à une même VM (typiquement pour des charges multi-GPU comme l’entraînement distribué local). Les contraintes documentées :

Les fGPU attachés sur une même VM doivent être du même modèle (pas de mélange A100 + V100 sur la même VM).
Le nombre maximum dépend du modèle et de la VM (vérifier MaxCpu / MaxRam du catalogue + capacité de la VM).
L’alignement génération CPU doit être respecté pour tous les fGPU.

Bonnes pratiques (par pilier Well-Architected)

1. Libérer après usage — pilier Cost

Le fGPU est facturé tant qu’il existe dans votre compte, même non attaché. Discipline systématique : à la fin d’une session de travail, détacher puis supprimer le fGPU. Pour des charges éphémères, utiliser DeleteOnVmDeletion: true à la création — la suppression est automatique avec la VM.

Un fGPU oublié allocé sans usage représente plusieurs dizaines à plusieurs centaines d’euros par mois selon le modèle.

2. Choisir le modèle adapté à la charge — pilier Cost + Performance

Pas besoin d’un A100 pour un POC d’inférence sur un petit modèle — un V100 ou P100 est largement suffisant et coûte significativement moins cher. Inversement, sur un entraînement de LLM, le bénéfice de l’A100 (puissance + VRAM) justifie son surcoût.

Les ratios à connaître :

A100 > V100 en performance pure et en VRAM — entraînement de gros modèles, fine-tuning LLM.
V100 = bon défaut « équilibré » pour la majorité des charges IA / ML.
P100 convient pour la production stable d’inférence ou de calcul scientifique.
P6 et K2 sont dédiés au rendu graphique et aux postes de travail virtuels — pas adaptés à l’IA / ML moderne.

3. Utiliser la même sous-région pour fGPU et VM — pilier Performance

Un fGPU est lié à une sous-région. La VM cible doit être dans la même sous-région. Avant d’allouer, vérifier la sous-région où vit la VM cible (champ SubregionName retourné par ReadVms).

4. SecNumCloud 3.2 pour l’IA souveraine — pilier Sovereignty

Pour toute charge IA ou ML traitant des données sensibles (santé, défense, secret industriel, R&D stratégique), utiliser exclusivement la région cloudgouv-eu-west-1 avec les modèles A100 ou V100 qualifiés SecNumCloud 3.2. Détails dans SecNumCloud 3.2 — implications.

5. Tagging discipliné — piliers OpEx + Cost

Comme pour les autres ressources, taguer chaque fGPU dès l’allocation : env, project, owner, cost-center, purpose (par ex. training, inference, prototype). Cela permet le reporting FinOps par projet et la détection des fGPU oubliés.

oapi-cli CreateTags \
  --ResourceIds '["fgpu-12345678"]' \
  --Tags '[
    {"Key": "env", "Value": "prod"},
    {"Key": "project", "Value": "llm-souverain"},
    {"Key": "owner", "Value": "equipe-ia"},
    {"Key": "purpose", "Value": "training"}
  ]'

6. Audit régulier des fGPU alloués — pilier Cost

Audit hebdomadaire ou trimestriel via ReadFlexibleGpus pour repérer les fGPU alloués depuis longtemps sans utilisation active. C’est un poste de gain FinOps régulier.

# Lister tous les fGPU avec leur état et VM attachée
oapi-cli ReadFlexibleGpus | jq '.FlexibleGpus[] | {FlexibleGpuId, ModelName, State, VmId, SubregionName}'

Antipatterns à éviter

Antipattern	Conséquence	Discipline correcte
fGPU oublié alloué	Coût mensuel élevé pour rien	Audit régulier + suppression systématique en fin de charge
A100 par défaut « pour avoir de la marge »	Surcoût significatif sans bénéfice mesuré	Choisir le modèle adapté à la charge réelle
fGPU dans une sous-région différente de la VM	Attachement impossible	Vérifier SubregionName avant l’allocation
IA sur données sensibles en `eu-west-2`	Hors périmètre SecNumCloud, conformité non garantie	`cloudgouv-eu-west-1` pour les données sensibles
Pas de tagging	Impossibilité de FinOps, fGPU « orphelins »	Tags dès la création
Mélange de modèles sur la même VM	Refus d’attachement	Même modèle sur une VM, sinon plusieurs VMs

fGPU sous l’angle Well-Architected

Performance Efficiency — adapter le GPU à la charge

Le pilier Performance se joue principalement sur le choix du modèle : la performance brute d’un A100 dépasse largement celle d’un K2, mais à un coût correspondant. La séparation allocation/attachement permet aussi des patterns flexibles : utiliser un GPU puissant pour l’entraînement nocturne, un moins puissant pour l’inférence diurne, sur la même VM ou sur des VMs différentes.

Les questions clés du pilier Performance adressées par cette page :

Quel modèle de GPU correspond à ma charge ? — A100 pour le très gros, V100 pour le standard, P100 pour la production stable, P6/K2 pour le rendu graphique.
Comment éviter de dimensionner trop gros ? — démarrer sur un V100 ou P100, mesurer, monter si nécessaire.
Comment exploiter plusieurs GPU sur une charge distribuée ? — plusieurs fGPU du même modèle attachés à la même VM (dans les limites de capacité).

Cost Optimization — facturation à l’allocation

Le pilier Cost est structurant sur les fGPU : la facturation porte sur l’allocation (que le fGPU soit attaché ou non). Les leviers principaux :

Libération immédiate après usage — surtout pour les workflows par phases.
DeleteOnVmDeletion: true pour les charges éphémères liées à une VM.
Choix du modèle adapté — pas d’A100 par défaut.
Audit régulier — repérage des fGPU oubliés.

Sovereignty — IA souveraine

Pour les charges IA traitant des données sensibles, le couple cloudgouv-eu-west-1 + A100/V100 SecNumCloud 3.2 est un différenciant fort d’OUTSCALE. Les questions clés du pilier Sovereignty adressées :

Mes données d’entraînement peuvent-elles être traitées sur du cloud souverain ? — oui sur cloudgouv-eu-west-1 avec A100/V100.
Mon LLM fine-tuné sur données réglementées reste-t-il en juridiction française ? — oui, garanti par la qualification SecNumCloud du fournisseur sur cette région.
Quelle position juridique vis-à-vis du Cloud Act / FISA ? — les charges sur cloudgouv-eu-west-1 ne sont pas soumises aux juridictions extra-européennes (cf. SecNumCloud 3.2 — implications).

À retenir

Le fGPU est une ressource GPU allouée indépendamment puis attachée à une VM, contrairement aux familles GPU intégrées des hyperscalers.
Modèles disponibles : nvidia-a100, nvidia-v100, nvidia-p100, nvidia-p6, nvidia-k2. Modèles A100 et V100 qualifiés SecNumCloud 3.2 sur cloudgouv-eu-west-1.
Quatre étapes du cycle de vie : allouer (CreateFlexibleGpu), attacher (LinkFlexibleGpu), détacher (UnlinkFlexibleGpu), libérer (DeleteFlexibleGpu).
Le fGPU est facturé tant qu’il existe dans le compte, même non attaché — discipline de libération systématique après usage.
Compatibilité entre modèle de GPU et génération CPU à vérifier via ReadFlexibleGpuCatalog avant l’allocation.
DeleteOnVmDeletion: true pour les charges éphémères liées à une VM.
IA souveraine = cloudgouv-eu-west-1 + A100/V100 — différenciant fort pour les données sensibles.

Prochaines étapes

Calcul — instances TINA et sizing Choisir la VM à laquelle attacher le fGPU.

SecNumCloud 3.2 — implications Le contexte juridique et opérationnel de l'IA souveraine sur OUTSCALE.

Régions et sous-régions OUTSCALE Allocation par sous-région et choix entre eu-west-2 et cloudgouv-eu-west-1.

EIM patterns multi-comptes Compte dédié pour les charges IA souveraines, séparé du compte commercial.