GPU as a Service

Cartes GPU NVIDIA dédiées 
via VM ou Kubernetes

Accédez à des GPU NVIDIA haute performance via GPU Passthrough sur vos VMs, ou via le NVIDIA GPU Operator sur vos clusters Kubernetes. Deux modes, un seul catalogue matériel.

DEMANDER UNE DEMO LIRE LA DOCUMENTATION

 4 GPU 

 L40S · A100 · H100 · RTX PRO 

 2 modes 

 VM Passthrough · Kubernetes 

 96 GB 

 VRAM max (RTX PRO 6000) 

 3700 tops 

 Performance RTX PRO 6000 (FP4) 
CATALOGUE GPU

Quatre familles NVIDIA pour chaque workload 

 L40S pour l'inférence et le développement, A100 pour l'entraînement ML, H100 pour les LLM et le calcul exascale. Commencez par le L40S avant de monter en gamme. 

L40S

NVIDIA Ada Lovelace

image 7
Mémoire 48 GB DDR6
ECC Inclus
Performance INT8 362 TOPS
Performance FP32 91.6 TFLOPs

Inférence, IA générative, rendu temps réel, développement et prototypage.

A100


NVIDIA Ampere

image 6
Mémoire 80 Go HBM2e
ECC Inclus
Performance INT8 312 TOPS
Performance FP32 624 TFLOPs

Entraînement ML, fine-tuning de modèles, calcul haute performance.

H100

NVIDIA Hopper

H100NVIDIA Hopper
Mémoire 80 Go HBM3
ECC Inclus
Performance INT8 1979 TOPS
Performance Tensor 989 TFLOPs

LLM, transformers, entraînement distribué, calcul exascale.

RTX PRO 6000


NVIDIA Blackwell

NVIDIA Blackwell
Mémoire 96 Go GDDR7
ECC Inclus
Performance FP4 3.7 PFLOPS
Performance FP32 117 TFLOPs

Inférence LLM multimodale, fine-tuning de modèles jusqu’à 70B paramètres, IA générative et rendu temps réel.

Conseil de démarrage

Commencez par un L40S pour le développement et le prototypage. Passez à un A100 pour l'entraînement de modèles ML standard, et réservez le H100 pour les workloads exigeants comme l'entraînement de LLM ou le calcul haute performance.
Modes d'accès

GPU sur VM ou GPU sur Kubernetes 

 Hikube propose deux modes d'accès au même matériel. Choisissez selon votre workload et votre niveau d'orchestration. 

GPU sur Machine Virtuelle PCI Passthrough

Le GPU physique est attaché directement à la VM via VFIO-PCI. Accès complet et exclusif à l'accélérateur — performances natives, sans overhead d'orchestration.

  • Applications nécessitant un contrôle complet du GPU
  • Workloads legacy ou spécialisés non conteneurisés
  • Environnements de développement isolés
  • Applications graphiques (rendu, CAO)
  • Prototypage et expérimentation CUDA

GPU sur Kubernetes GPU Operator

Les GPU sont exposés aux pods via le NVIDIA Device Plugin, géré par le GPU Operator. Scheduling orchestré par Kubernetes — partage entre pods, autoscaling, pipelines ML.

  • Workloads containerisés d'IA/ML
  • Scaling automatique des applications GPU
  • Partage de ressources GPU entre pods
  • Jobs parallèles et distribués
  • Pipelines ML/AI complexes
GPU sur VM
GPU sur Kubernetes
Mode d’accès
PCI Passthrough exclusif
Device Plugin partagé
Isolation
1 GPU = 1 VM (dédiée)
Scheduling orchestré par K8s
Performance
Native (passthrough)
Native (device plugin)
Drivers NVIDIA
Manuels via cloud-init
Automatiques (GPU Operator)
Scaling
Vertical uniquement
Horizontal + Vertical
Partage entre workloads
Non
Oui (entre pods)
Temps de setup
~5 minutes
~10 minutes
Complexité
Simple
Modérée
Mise en route

Prêt en quelques lignes de YAML  

Que ce soit sur une VM ou un cluster Kubernetes, la configuration GPU se résume à déclarer le type de GPU souhaité dans votre manifeste. Le reste, drivers, scheduling et allocation sont gérés par Hikube. 

Sur une VM

Ajoutez un champ gpus[] à votre VMInstance. Le GPU est attaché en PCI Passthrough vous garantissant un accès direct et exclusif au matériel. Multi-GPU possible en répétant les entrées.

yaml
kind: VMInstance
spec:
  instanceType: u1.2xlarge
gpus:
  - name: "nvidia.com/AD102GL_L40S"


Les drivers NVIDIA s'installent via cloud-init au premier démarrage.

Voir le guide complet

Sur Kubernetes

Ajoutez un node group GPU à votre cluster, puis demandez le GPU dans vos pods via resources.limits. Le GPU Operator gère les drivers automatiquement. 

yaml
kind: Kubernetes

spec:
 
  nodeGroups: 
    -gpu-workers:
 
      instanceType: u1.xlarge
 
      gpus:
 
        - name: "nvidia.com/AD102GL_L40S" 
 


 

Séparez vos node groups CPU et GPU pour un scaling indépendant.

Voir le guide complet
DImensionnement

Ratio CPU/RAM recommandé par GPU 

Prévoyez 8 à 16 vCPU par GPU. Les instances de la gamme Universal (u1) sont recommandées pour les workloads GPU. 

INSTANCES
VCPU
RAM
USAGE RECOMMANDÉ
u1.xlarge
4
16 GB
1× L40S — développement, prototypage
u1.2xlarge
8
32 GB
1× A100 — fine-tuning, inférence multi-modèles
u1.4xlarge
16
64 GB
1-2× A100 — entraînement ML intensif
u1.8xlarge
32
128 GB
4× H100 — entraînement distribué, LLM
Vérification post-déploiement

Confirmer l'accès GPU 

Sur une VM

bash
# Connexion SSH
virtctl ssh -i ~/.ssh/id_ed25519 ubuntu@gpu-workstation



# Vérifier le GPU

nvidia-smi



# Infos détaillées
nvidia-smi \
 
  --query-gpu=name,memory.total,utilization.gpu \
 
  --format=csv 


 

Sur Kubernetes

yaml
# GPU exposés par node

kubectl get nodes -o custom-columns=\
NAME:.metadata.name,\ 

GPU:.status.allocatable. 'nvidia\.com/gpu'



# Depuis un pod

kubectl exec -it <pod-name> -- nvidia-smi



# Ressources allouées

kubectl describe node <gpu-node> \
| grep -A5 "Allocated resources"


 
Pourquoi le GPU cloud

Le GPU, accélérateur des workloads modernes 

Le CPU est conçu pour exécuter des tâches séquentielles complexes. Le GPU, lui, est architecturé pour le parallélisme massif : des milliers de cœurs simples travaillant simultanément sur le même problème. C'est cette différence fondamentale qui rend le GPU indispensable pour l'entraînement de modèles de machine learning, l'inférence à grande échelle, le rendu 3D ou le calcul scientifique.

Acheter du matériel GPU en propre implique des cycles d'investissement longs, une gestion de capacité difficile à anticiper et une obsolescence rapide : un H100 acheté aujourd'hui sera dépassé dans 3 ans. Le modèle GPU as a Service permet d'accéder à la dernière génération de matériel NVIDIA à la demande, de scaler selon la charge réelle, et de ne payer que ce qui est consommé.

Sur Hikube, les GPU sont hébergés en Suisse et accessibles via des APIs standard, sans lock-in, sans agent propriétaire. Que votre workload tourne sur une VM isolée ou dans un cluster Kubernetes partagé entre équipes, l'accès au matériel reste identique.

svgviewer-output

CPU vs GPU : le bon outil pour chaque tâche


Le CPU excelle sur les traitements séquentiels à faible latence. Le GPU est optimisé pour les opérations matricielles massives : multiplication de tenseurs, convolutions, attention mechanisms qui sont au cœur du deep learning. 

svgviewer-output

Souveraineté des données garantie


Vos modèles, vos datasets, vos checkpoints restent en Suisse. Conformité RGPD native, sans configuration supplémentaire. 

svgviewer-output

Accès à la dernière génération sans capex


L40S, A100, H100 disponibles à la demande. Pas de cycle d'achat, pas d'amortissement, pas de gestion de salle serveur. Vous accédez au matériel le plus récent au moment où vous en avez besoin. 

svgviewer-output

Intégration dans votre stack existante


Kubernetes standard, YAML natif, compatible avec vos outils MLOps existants (Kubeflow, Argo Workflows, MLflow). Pas de réécriture de pipeline. 

FAQ

Questions sur le GPU as a Service

 Les questions que posent les équipes avant de déployer leurs premiers workloads GPU. 

Quel GPU choisir pour mon workload ?

La règle générale : commencez par le L40S pour tout ce qui est inférence, développement ou prototypage. Il couvre la grande majorité des cas à moindre coût. Passez à l'A100 quand vous entraînez des modèles sérieusement (fine-tuning, datasets larges). Réservez le H100 aux workloads vraiment exigeants : LLM multi-milliards de paramètres, entraînement distribué sur plusieurs nœuds.

VM ou Kubernetes, comment choisir ?

Si votre application n'est pas conteneurisée, que vous avez besoin d'un accès complet au GPU, ou que vous prototypez — prenez une VM. C'est plus simple, plus rapide à mettre en place, et le GPU vous est entièrement dédié.

Si vous orchestrez déjà vos workloads avec Kubernetes, que vous avez besoin de scaling automatique ou de partager des ressources GPU entre plusieurs équipes — optez pour le mode Kubernetes. La complexité supplémentaire est compensée par la flexibilité.

Puis-je partager un GPU entre plusieurs jobs ?

Prévoyez 8 à 16 vCPU par GPU. Un u1.2xlarge (8 vCPU, 32 GB RAM) est un bon point de départ pour un seul GPU. Pour 4 GPU H100, montez à u1.8xlarge (32 vCPU, 128 GB RAM). Sous-dimensionner le CPU crée des goulots d'étranglement sur le prétraitement des données qui plafonnent l'utilisation GPU.

Faut-il gérer les drivers NVIDIA soi-même ?

 Sur VM, oui — vous installez les drivers via un script cloud-init au premier démarrage. La doc fournit le script complet, c'est une manipulation unique.

Sur Kubernetes, non — le GPU Operator s'en charge automatiquement sur les nœuds GPU. Vous activez l'addon dans le manifeste du cluster, le reste est transparent.

Est-ce que je peux partager un GPU entre plusieurs jobs ?

En mode VM, non — le GPU est entièrement dédié à la VM. En mode Kubernetes, le GPU Operator permet d'allouer des GPU entiers à différents pods sur le même nœud, mais un pod ne peut pas demander une fraction de GPU. Si vous avez besoin de faire tourner plusieurs petits jobs en parallèle, l'approche Kubernetes avec plusieurs pods sur un nœud multi-GPU est la plus efficace