Provisionner un GPU Infomaniak pour vLLM : Horizon, OpenStack CLI et OpenTofu

TL;DR

Pour exécuter un modèle avec vLLM, il faut d’abord disposer d’une machine dont la mémoire GPU peut contenir les poids du modèle, le KV cache et les buffers du runtime. Le chapitre 04 du dépôt xavki/tutorials-vllm retient une VM Infomaniak équipée d’une NVIDIA L4 de 24 Go, avec le flavor nvl4-a16-ram32-disk80-perf1.

La même instance peut être créée de trois façons : depuis l’interface Horizon, avec la CLI OpenStack ou avec OpenTofu. Dans les trois cas, il faut une clé SSH, un groupe de sécurité autorisant le port 22, l’image Ubuntu 24.04 LTS et le réseau ext-net1. Une fois connecté, lspci puis nvidia-smi permettent de vérifier la présence du GPU et le bon chargement du pilote NVIDIA.

Ce chapitre ne lance encore aucun modèle. Il prépare uniquement le serveur GPU. L’installation de vLLM et le premier vllm serve appartiennent au chapitre 05.

La vidéo de référence

La vidéo associée à ce chapitre est disponible ici : vLLM – 04. Provisioning GPU chez Infomaniak.

Le dépôt constitue la référence factuelle pour les commandes et les noms de ressources. Les supports du chapitre sont les fichiers slides.md et notes.txt. Ils suivent le même fil : choisir le GPU, comprendre la pile NVIDIA, provisionner la VM, se connecter puis lire nvidia-smi.

Objectif et périmètre du chapitre

Avant d’optimiser PagedAttention, le batching continu ou le KV cache, il faut une machine capable d’exposer un GPU au système Linux. Le but n’est donc pas encore de servir un LLM, mais de répondre à quatre questions très concrètes :

1. Quelle quantité de VRAM faut-il pour le modèle visé ?
2. Quel flavor Infomaniak correspond à ce besoin ?
3. Comment créer la VM de façon manuelle ou reproductible ?
4. Comment vérifier que Linux et le pilote voient réellement le GPU ?

Le résultat attendu est volontairement simple : une instance Ubuntu accessible en SSH, équipée d’une NVIDIA L4 visible dans nvidia-smi. Cette séparation pédagogique est importante. Un problème de provisioning, de réseau ou de pilote doit être résolu avant d’ajouter PyTorch et vLLM.

Choisir un GPU à partir du modèle et de la VRAM

Le bon raisonnement commence par le modèle, pas par le nom commercial du GPU. Les poids occupent une première partie de la VRAM. Il faut ensuite réserver de la mémoire pour le KV cache, la longueur de contexte, les requêtes simultanées, CUDA, les kernels et les buffers temporaires.

Le chapitre fournit les ordres de grandeur suivants pour les poids seuls :

Ces chiffres ne constituent pas un dimensionnement complet. Un modèle 8B en BF16 peut occuper environ 16 Go de poids, mais les 8 Go restant sur une L4 ne sont pas « libres » au sens absolu : ils doivent absorber le KV cache et l’overhead du runtime. La longueur maximale du contexte et la concurrence peuvent modifier fortement le besoin réel.

Pour les premiers essais de la formation, la NVIDIA L4 de 24 Go offre néanmoins une base cohérente pour un modèle 7B ou 8B. Un 13B en FP16 ou BF16 devient trop serré sur 24 Go ; il faut alors envisager la quantification, un GPU plus grand ou plusieurs GPU.

Au-delà de la capacité, la bande passante mémoire influence la vitesse de génération et les Tensor Cores accélèrent les formats de calcul adaptés. Pour une première sélection, la question prioritaire reste cependant : « le modèle et sa charge de travail tiennent-ils confortablement en VRAM ? »

Lire le flavor Infomaniak retenu

Le flavor utilisé dans le dépôt est :

nvl4-a16-ram32-disk80-perf1

Son nom encode plusieurs caractéristiques :

La VRAM ne figure pas directement dans ce nom. Elle vient des caractéristiques de la NVIDIA L4, qui dispose de 24 Go de mémoire GPU.

Les flavors disponibles et leurs tarifs peuvent évoluer. Leur visibilité dépend aussi du projet Public Cloud : l’accès à certaines familles GPU doit parfois être activé par le support Infomaniak. Il faut donc vérifier le catalogue du projet avec openstack flavor list et consulter la page tarifaire officielle au moment du déploiement, plutôt que de figer un prix dans une procédure durable.

Pilote NVIDIA, CUDA, PyTorch et vLLM : le modèle mental

Une VM équipée d’un GPU ne suffit pas à garantir que les applications peuvent l’utiliser. La pile minimale se comprend ainsi :

Noyau Linux
  -> pilote NVIDIA
    -> runtime et bibliothèques CUDA
      -> PyTorch
        -> vLLM
          -> inférence du modèle

Le pilote permet au système d’accéder au matériel. CUDA fournit la plateforme de calcul utilisée par les bibliothèques. PyTorch construit et exécute les opérations tensorielles sur CUDA. vLLM s’appuie ensuite sur cette pile pour charger le modèle et exécuter ses kernels d’inférence.

La commande de contrôle la plus connue est :

nvidia-smi

Si elle fonctionne, le pilote est chargé et la carte est visible. Elle ne prouve pas pour autant que PyTorch est installé, ni que son build CUDA est compatible. Ces vérifications viendront après l’installation de l’environnement Python.

Le support du cours utilise Ubuntu 24.04 LTS Noble Numbat. Ubuntu n’est pas obligatoire, mais c’est un choix pédagogique pratique : images cloud disponibles, documentation NVIDIA abondante et exemples PyTorch/vLLM fréquents.

Préparer la clé SSH et le groupe de sécurité

Les trois méthodes de provisioning partagent les mêmes prérequis. Créons d’abord une clé dédiée sur le poste local :

ssh-keygen -t ed25519 -f ~/.ssh/infomaniak_vllm

La clé publique ~/.ssh/infomaniak_vllm.pub doit être importée dans OpenStack. La clé privée reste sur le poste de travail et ne doit jamais être ajoutée au dépôt.

Pour ce chapitre, le groupe de sécurité vllm-server n’a besoin que d’une règle entrante TCP sur le port 22. Il n’est pas nécessaire d’ouvrir le port 8000 : aucun serveur vLLM n’est démarré ici.

Dans un environnement durable, limitez la source de la règle SSH à votre adresse publique ou au CIDR de votre VPN. Une règle ouverte à tout Internet est pratique pour un laboratoire ponctuel, mais elle augmente inutilement la surface d’exposition.

Provisionner la VM avec Horizon

Horizon est l’interface web d’OpenStack. Cette méthode convient bien à une première découverte, car elle rend visibles les objets du projet : images, flavors, réseaux, paires de clés et groupes de sécurité.

Depuis le dashboard Horizon Infomaniak, préparez ou sélectionnez :

Dans Compute > Key Pairs, importez la clé publique. Dans Network > Security Groups, créez la règle SSH. Lancez ensuite l’instance depuis Compute > Instances > Launch Instance.

Attendez l’état ACTIVE, récupérez l’adresse publique puis connectez-vous :

ssh -i ~/.ssh/infomaniak_vllm ubuntu@<PUBLIC_IP>

Horizon n’utilise pas une infrastructure différente de la CLI ou d’OpenTofu. Il appelle les mêmes API OpenStack ; seule l’interface change.

Provisionner avec OpenStack CLI

La CLI rend l’opération scriptable et facilite le diagnostic. Le fichier notes.txt recommande de l’installer dans un environnement virtuel Python :

python3 -m venv ~/venvs/openstack-cli
source ~/venvs/openstack-cli/bin/activate
pip install --upgrade pip
pip install python-openstackclient

Deux modes d’authentification sont courants. Le premier consiste à télécharger un fichier OpenStack RC depuis Project > API Access, puis à le charger :

source ~/Downloads/<your-project>-openrc.sh
openstack server list

Le second utilise ~/.config/openstack/clouds.yaml et un nom de cloud, par exemple infomaniak. Ce fichier contient des données sensibles : ne le commitez pas, ne l’intégrez pas dans une capture d’écran et ne publiez jamais son mot de passe.

Avant de créer la VM, contrôlez les ressources réellement disponibles :

openstack image list | grep -i ubuntu
openstack flavor list | grep nvl4
openstack network list

Enregistrez ensuite la clé publique et créez le groupe de sécurité :

openstack keypair create \
  --public-key ~/.ssh/infomaniak_vllm.pub \
  infomaniak_vllm

openstack security group create vllm-server
openstack security group rule create \
  --proto tcp \
  --dst-port 22 \
  vllm-server
openstack security group rule create \
  --proto icmp \
  vllm-server

La création de l’instance reprend exactement les valeurs du chapitre :

openstack server create \
  --flavor nvl4-a16-ram32-disk80-perf1 \
  --image "Ubuntu 24.04 LTS Noble Numbat" \
  --key-name infomaniak_vllm \
  --security-group vllm-server \
  --network ext-net1 \
  vllm-dev-01

Vérifiez ensuite son état et ses adresses :

openstack server show vllm-dev-01 -c status -f value
openstack server show vllm-dev-01 -c addresses -f value

Le nom exact de l’image, du flavor ou du réseau peut évoluer. Les commandes de liste doivent donc précéder la commande de création au lieu de supposer que le catalogue est identique sur tous les projets.

Provisionner avec OpenTofu

OpenTofu transforme le provisioning en code déclaratif. Le dossier opentofu/ du dépôt contient quatre fichiers essentiels :

• providers.tf configure le provider OpenStack terraform-provider-openstack/openstack en version ~> 3.0 et le cloud infomaniak ;
• variables.tf définit le nom de l’instance, le flavor, l’image, le réseau, la clé et le groupe de sécurité ;
• main.tf référence la clé et le groupe existants, puis crée openstack_compute_instance_v2.vllm_dev ;
• outputs.tf expose le nom, l’adresse IPv4 et une commande SSH.

Le workflow est court :

cd ../opentofu
tofu init
tofu plan
tofu apply -auto-approve
tofu output ssh_command

Pour exécuter directement la commande générée :

$(tofu output -raw ssh_command)

L’exemple suppose que la paire de clés infomaniak_vllm et le groupe vllm-server existent déjà. Ce sont des data sources, pas des ressources créées par main.tf. Cette nuance évite de croire qu’un tofu apply sur un projet vierge prépare absolument tout.

OpenTofu devient particulièrement utile lorsque le laboratoire doit être recréé plusieurs fois, partagé avec une équipe ou relu comme du code. Le plan montre les changements avant application et l’état relie la configuration aux ressources distantes.

Pour supprimer les ressources gérées par cet exemple :

cd ../opentofu
tofu destroy -auto-approve

Se connecter et vérifier le GPU

Une fois la VM accessible, commencez par vérifier le système et le matériel :

hostname
lsb_release -a
lspci | grep -i nvidia
nvidia-smi

lspci confirme qu’un périphérique NVIDIA est présenté à la VM. nvidia-smi interroge le pilote et affiche notamment le modèle, la version du pilote, la compatibilité CUDA déclarée, la température, la puissance, la mémoire et les processus utilisant le GPU.

Sur une L4 inactive, on s’attend à voir un GPU d’index 0, environ 23 Gio de mémoire affichée, une utilisation proche de 0 % et aucun processus GPU. Les 24 Go commerciaux et la valeur affichée en Mio/Gio ne se comparent pas directement : les unités diffèrent et une petite partie de la mémoire peut être réservée.

La mention CUDA Version dans l’en-tête de nvidia-smi indique la version maximale de CUDA supportée par le pilote. Elle ne signifie pas que PyTorch a été installé avec cette même version. L’exemple des slides montrant un pilote 580.173.02 et CUDA 13.0 est une sortie pédagogique datée, pas un résultat garanti.

Installer le pilote uniquement s’il manque

Certaines images cloud peuvent déjà fournir le pilote. Testez avant d’installer. Si nvidia-smi est absent ou ne communique pas avec le pilote, le dépôt propose pour Ubuntu 24.04 :

wget -q https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2404/x86_64/cuda-keyring_1.1-1_all.deb
sudo dpkg -i cuda-keyring_1.1-1_all.deb
sudo apt update
sudo apt install -y nvidia-driver-580
sudo reboot

Reconnectez-vous après le redémarrage puis relancez :

nvidia-smi

La version 580 correspond à l’état du support au moment où le chapitre a été écrit. Avant une nouvelle installation, consultez le guide officiel NVIDIA et vérifiez les paquets disponibles pour l’image choisie. Remplacer mécaniquement un pilote fonctionnel par une version copiée depuis un tutoriel peut introduire une incompatibilité inutile.

Sécurité, coûts et nettoyage

Un GPU cloud est une ressource coûteuse par rapport à une VM généraliste. La fin du laboratoire fait donc partie du tutoriel.

Avec la CLI OpenStack :

openstack server stop vllm-dev-01
openstack server start vllm-dev-01
openstack server delete vllm-dev-01

Avec OpenTofu :

tofu destroy -auto-approve

Dans Horizon, supprimez l’instance depuis Compute > Instances. Ne supposez pas qu’une instance simplement arrêtée ne génère plus aucun coût : le disque et d’autres ressources attachées peuvent rester facturés, et les règles précises dépendent de l’offre. Vérifiez la documentation et la console de facturation Infomaniak.

Quelques règles simples évitent la plupart des incidents :

• ne stockez jamais les identifiants OpenStack dans le dépôt ;
• limitez le port 22 à une origine connue ;
• n’ouvrez pas les ports applicatifs avant d’en avoir besoin ;
• utilisez une clé SSH dédiée ;
• supprimez les instances de laboratoire après usage ;
• contrôlez le plan OpenTofu avant l’application, même si le cours montre -auto-approve pour accélérer une démo.

Dépannage

Le dépannage doit rester séquentiel. Commencez par le réseau et SSH, puis le matériel PCI, puis le pilote. PyTorch et vLLM ne doivent intervenir qu’après la validation de ces couches.

Liens utiles

• Dépôt de la formation vLLM
• Chapitre 04 : Infomaniak Cloud Setup
• Slides du chapitre 04
• Notes et commandes du chapitre 04
• Exemple OpenTofu du dépôt
• Vidéo vLLM 04
• Infomaniak Public Cloud
• Tarifs du Public Cloud Infomaniak
• Documentation Infomaniak sur les instances
• Documentation des flavors
• Documentation des groupes de sécurité
• Documentation OpenStackClient
• Documentation OpenTofu
• NVIDIA L4
• Guide d’installation des pilotes NVIDIA
• Documentation vLLM

FAQ

Une NVIDIA L4 de 24 Go suffit-elle pour vLLM ?

Elle constitue une bonne base pour apprendre et servir certains modèles 7B ou 8B, selon la précision, la longueur de contexte et la concurrence. Elle ne garantit pas qu’un modèle donné tiendra : les poids, le KV cache et l’overhead doivent être additionnés.

Quelle différence entre Horizon, OpenStack CLI et OpenTofu ?

Les trois méthodes pilotent les mêmes ressources OpenStack. Horizon est graphique, la CLI est impérative et scriptable, OpenTofu décrit un état reproductible dans des fichiers versionnables.

Pourquoi nvidia-smi affiche-t-il environ 23 Gio sur une L4 annoncée à 24 Go ?

Les constructeurs annoncent généralement la capacité en gigaoctets décimaux alors que l’outil affiche une valeur en Mio/Gio. Une petite quantité peut aussi être réservée. Cet écart est normal.

La version CUDA affichée par nvidia-smi est-elle celle de PyTorch ?

Non. Elle représente la compatibilité CUDA maximale annoncée par le pilote. La version utilisée par PyTorch dépend du paquet installé et se vérifie depuis Python après l’installation.

Faut-il ouvrir le port 8000 dès la création de la VM ?

Non. Le chapitre 04 utilise uniquement SSH sur le port 22. Le port applicatif de vLLM n’est pertinent qu’au chapitre suivant et doit être ouvert de manière contrôlée.

OpenTofu crée-t-il la clé SSH et le groupe de sécurité dans cet exemple ?

Non. Le main.tf du dépôt les lit comme ressources existantes. Ils doivent être préparés auparavant dans Horizon ou avec OpenStack CLI.

Arrêter la VM suffit-il pour ne plus payer ?

Ce n’est pas une garantie. Le stockage et d’autres ressources peuvent continuer à être facturés, et le traitement du GPU dépend de l’offre. Pour un laboratoire terminé, la suppression de l’instance et la vérification de la facturation sont les choix prudents.

Où commence réellement l’installation de vLLM ?

Dans le chapitre 05, après la validation du GPU, du pilote et de l’accès SSH. Ce découpage permet de distinguer les problèmes d’infrastructure des problèmes du runtime d’inférence.

Conclusion

Le provisioning d’un serveur GPU n’est pas une simple étape administrative avant vLLM. Il fixe la capacité mémoire disponible, la surface réseau, le système d’exploitation et la reproductibilité du laboratoire.

Le chapitre 04 propose une progression utile : dimensionner à partir du modèle, sélectionner une L4 de 24 Go, préparer SSH, créer la même VM par trois interfaces, puis valider la pile matérielle avec nvidia-smi. Horizon aide à comprendre les objets, OpenStack CLI rend les actions explicites et OpenTofu fournit une base reproductible.

À ce stade, aucun modèle n’est encore chargé et aucun service HTTP n’est exposé. C’est précisément le résultat recherché : une fondation GPU propre et vérifiée. Le chapitre 05 pourra alors se concentrer sur l’installation de vLLM et la première inférence, sans mélanger les erreurs de runtime avec celles du cloud, du réseau ou du pilote.