Infrastructure et GPU

Dimensionner votre infrastructure GPU

Choisir le bon GPU, la bonne quantité de mémoire et le bon outil d’orchestration est une étape critique du self-hosting. Un modèle mal dimensionné ne se dégrade pas gracieusement : il refuse de démarrer, ou s’écroule sous la première charge réelle. Nous allons voir les exigences matérielles des modèles Mistral, les techniques de quantization qui permettent de réduire les besoins mémoire, et deux outils d’orchestration, SkyPilot et Cerebrium.

Ce que chaque modèle réclame

Le tableau suivant donne les besoins en FP16, sans quantization — le point de départ de tout dimensionnement.

Vous n’avez pas besoin de ce tableau pour estimer un modèle absent de la liste. En FP16, comptez environ 2 Go de VRAM par milliard de paramètres : pour un modèle de 7B, 7 x 2 = 14 Go minimum, auxquels s’ajoutent l’overhead du KV cache et du moteur d’inférence — d’où les 16 Go annoncés. Cette marge explique pourquoi une carte de 16 Go suffit tout juste pour Mistral 7B, et pourquoi elle ne suffira plus dès que vous servirez des contextes longs à plusieurs utilisateurs simultanés.

Quantization : acheter de la mémoire avec un peu de précision

La quantization réduit la précision des poids du modèle pour diminuer la consommation mémoire, souvent avec un impact minimal sur la qualité. En FP8, c’est-à-dire huit bits par poids, la mémoire est divisée par deux par rapport au FP16, et l’activation tient dans un simple argument :

# Servir un modèle en FP8 avec vLLM
vllm serve mistralai/Mistral-Nemo-Instruct-2407 \
    --tokenizer_mode mistral \
    --config_format mistral \
    --load_format mistral \
    --dtype float8_e4m3fn

La conséquence est très concrète : un Mixtral 8x7B qui exigeait deux A100-80GB en FP16 tient sur une seule carte en FP8, et votre facture horaire est divisée par deux. L’INT4, sur quatre bits, va plus loin encore, mais l’impact sur la qualité devient visible ; il s’active côté TGI par un argument dédié :

# AWQ quantization avec TGI
docker run --gpus all --shm-size 1g \
    -p 8080:80 \
    -e HUGGING_FACE_HUB_TOKEN=$HF_TOKEN \
    ghcr.io/huggingface/text-generation-inference:2.0.3 \
    --model-id mistralai/Mistral-7B-Instruct-v0.3 \
    --quantize awq

En pratique, le FP8 est recommandé pour la production — la perte de qualité est négligeable. L’INT4 convient pour le prototypage ou les environnements à mémoire très limitée, typiquement une démonstration sur un poste équipé d’une carte grand public.

SkyPilot : orchestration multi-cloud

SkyPilot est un framework open-source pour déployer des LLM sur n’importe quel cloud — AWS, GCP, Azure, Lambda Labs et d’autres. Il gère automatiquement la sélection du GPU le moins cher et le provisionning, ce qui évite d’aller comparer manuellement les prix spot de trois fournisseurs avant chaque lancement. Mistral fournit des fichiers YAML prêts à l’emploi, dont la structure décrit à la fois la machine, l’installation et la commande de service :

# mistral-7b.yaml
resources:
  accelerators: A10G:1
  cloud: aws

setup: |
  pip install vllm

run: |
  vllm serve mistralai/Mistral-7B-Instruct-v0.3 \
      --tokenizer_mode mistral \
      --config_format mistral \
      --load_format mistral

Le cycle de vie complet d’un cluster tient ensuite en quatre commandes :

# Installer SkyPilot
pip install "skypilot[aws,gcp,azure]"

# Lancer le cluster
sky launch -c mistral-7b mistral-7b.yaml --region us-east-1

# Vérifier le statut
sky status

# Arrêter (pour économiser)
sky stop mistral-7b

# Supprimer
sky down mistral-7b

Ces deux dernières commandes sont celles qu’on oublie. Un cluster A10G laissé allumé un week-end coûte le prix d’un mois d’API pour un usage modéré, d’où l’intérêt de connaître les ordres de grandeur :

Un dernier point mérite votre vigilance : SkyPilot crée des VM avec des ports ouverts par défaut. En production, restreignez le réseau avec des Security Groups ou des Firewall Rules, placez un load balancer assurant l’authentification devant le service, et ne laissez jamais le port 8000 exposé sur Internet. Un serveur vLLM sans authentification atteignable publiquement, c’est un GPU que vous payez pour le compte de quelqu’un d’autre.

Cerebrium : serverless GPU

Cerebrium adopte l’approche inverse de SkyPilot : au lieu de piloter des machines, vous décrivez un service et ne payez que le compute réellement utilisé, avec auto-scaling. La mise en route se fait en trois commandes :

pip install cerebrium
cerebrium login
cerebrium init mistral-vllm

Tout le déploiement est ensuite décrit dans un fichier cerebrium.toml :

[cerebrium.deployment]
name = "mistral-nemo"
python_version = "3.11"

[cerebrium.hardware]
gpu = "AMPERE_A10"
cpu = 4
memory = 16

[cerebrium.scaling]
min_replicas = 0
max_replicas = 5
cooldown = 60

[cerebrium.dependencies.pip]
vllm = "latest"

Le min_replicas = 0 est l’argument décisif de cette approche : quand personne n’appelle le service, il ne coûte rien. En contrepartie, la première requête après une période creuse doit attendre le démarrage d’une instance. La commande cerebrium deploy suffit à publier, la plateforme prenant en charge le provisionning GPU, l’auto-scaling de zéro à N replicas, le load balancing et le monitoring.

Tenir la charge en production

Pour augmenter le débit, on ne cherche pas un GPU plus gros mais on multiplie les instances derrière un load balancer, chacune servant le même modèle sur sa propre carte :

                    ┌─── vLLM instance 1 (GPU A)
Load Balancer ──────┼─── vLLM instance 2 (GPU B)
                    └─── vLLM instance 3 (GPU C)

Cinq indicateurs suffisent à piloter l’ensemble : les tokens par seconde mesurent le débit de génération ; le TTFB (Time To First Byte) donne la latence avant le premier token, celle que perçoit l’utilisateur ; l’utilisation GPU devrait dépasser 80 % en charge, faute de quoi vous payez du matériel inactif ; la mémoire GPU se surveille pour anticiper les OOM ; et la queue depth, le nombre de requêtes en attente, annonce une saturation avant que les utilisateurs ne s’en plaignent. Sur une machine, un simple rafraîchissement en continu donne déjà l’essentiel :

# Surveiller l'utilisation GPU
watch -n 1 nvidia-smi

Points clés à retenir

• Comptez ~2 Go VRAM par milliard de paramètres en FP16
• La quantization FP8 divise la mémoire par deux avec un impact négligeable sur la qualité
• SkyPilot simplifie le déploiement multi-cloud avec des configs YAML prêtes à l’emploi
• Cerebrium offre du serverless GPU avec auto-scaling (pay-per-compute)
• En production, ajoutez un load balancer et surveillez les métriques GPU en continu