Un LLM hébergé à Paris chez Scaleway : carnet de bord, pénurie de GPU comprise

Lundi 9 novembre, vers 8 h 50, heure de Paris. Une requête arrive, notre veilleur demande à Scaleway d’allumer la L40S qui sert notre modèle. Réponse de l’API : out_of_stock. Le catalogue indique shortage pour toutes les L40S, H100 et B300, dans toutes les zones. Il reste des L4, marquées scarce.

Ce matin-là, nous devions présenter le projet à nos associés. Nous l’avons présenté quand même, sur deux L4, à un tarif voisin, après avoir modifié une variable. Ce carnet de bord raconte la mise en place d’un modèle de langage open-weight chez Scaleway, à Paris : le choix du GPU, les réglages de vLLM qui comptent, l’infrastructure, et ce que « éteindre une machine » veut dire dans un cloud sous tension.

Le cahier des charges : un modèle ouvert pour nos agents de code, hébergé en France, sur une machine dont nous maîtrisons la configuration, sans écrire les prompts dans les journaux, et sans payer un GPU qui dort. Le test de non-conservation et le veilleur qui éteint le GPU ont chacun leur article dans cette série.

Scaleway coche les cases qui comptent pour ce pilote :

• une zone de disponibilité à Paris (fr-par-2, région fr-par) avec des L4 et des L40S[1] ;
• un calcul GPU facturé à la minute ; une fois la machine éteinte, il ne reste que ses volumes et son adresse IPv4[2] ;
• une API complète pour allumer, éteindre, et interroger la disponibilité de chaque type de machine[3] ;
• une société française[4], soumise au droit européen.

Nous avons privilégié des machines virtuelles dont nous configurons chaque service, plutôt qu’une offre d’inférence managée ou serverless : nous voulions pouvoir inspecter nous-mêmes les journaux de toute la chaîne. Ce choix ne signifie pas que les offres managées conservent les prompts, ni qu’un hébergeur français exclut tout accès légal ou technique.

Un GPU doit accueillir les poids du modèle, le cache des couches d’attention (le cache KV, qui grossit avec chaque conversation), les états récurrents si le modèle est hybride, et les allocations du moteur d’inférence lui-même.

Le premier ordre de grandeur se calcule : nombre de paramètres × octets par paramètre. Nous servons le checkpoint FP8 de Qwen3.8-27B (licence Apache 2.0)[5] : un octet par paramètre, environ 27 Go pour les poids seuls. L’effet du FP8 sur la qualité, lui, s’évalue sur les tâches visées. Pour le reste, seul le chargement réel, avec les réglages retenus, dit quel budget il reste pour les requêtes.

Sur les L4, les deux mémoires restent distinctes et les cartes échangent en PCIe[7][9] ; la bande passante d’une H100 dépend de sa variante (PCIe ou SXM)[9].

Un piège de lecture : ces 310 000 tokens sont une capacité totale, partagée par toutes les conversations en cours. Notre contexte maximal est de 131 072 tokens ; trois sessions qui le rempliraient demanderaient 393 216 tokens, plus que la L40S n’en offre. Des préfixes identiques peuvent réduire l’occupation ; sinon, trois contextes pleins ne tiennent pas en même temps, et le moteur doit différer ou préempter des requêtes, au prix d’une latence accrue[10]. Le nombre d’utilisateurs seul ne dimensionne donc rien : il faut la taille des contextes et la concurrence réelles.

À faible concurrence, la bande passante mémoire limite fortement la génération d’un modèle dense[11]. Le traitement par lots et le décodage spéculatif changent toutefois la donne : la bande passante seule ne prédit pas le débit.

vLLM est le moteur d’inférence open source qui charge le modèle sur le GPU et expose une API compatible OpenAI[12]. Configuration utilisée avec vLLM 0.33.0 et Qwen/Qwen3.8-27B-FP8 :

vllm_args = [
  "--max-model-len", "131072",       # contexte maximal par requête
  "--max-num-seqs", "16",            # 256 par défaut : le moteur ne démarrait pas
  "--kv-cache-dtype", "fp8",         # valeurs du cache KV sur 8 bits
  "--language-model-only",
  "--enable-auto-tool-choice",       # appels d'outils, pour les agents
  "--tool-call-parser", "qwen3_coder",
  "--reasoning-parser", "qwen3",
  "--enable-prefix-caching",         # réutilise les débuts de conversation identiques
  "--speculative-config", "{\"method\":\"mtp\",\"num_speculative_tokens\":3}",
]
# --disable-log-requests et --disable-log-outputs sont toujours ajoutés en dernier.

Trois réglages méritent qu’on s’y arrête.

Le décodage spéculatif : un rapport de 2,4 entre nos relevés. Sur la L40S, nous avons relevé 25,5 tokens par seconde sans, et environ 61 avec. Le modèle embarque des têtes de prédiction multi-tokens (MTP)[5] qui proposent, avec notre réglage, jusqu’à trois tokens d’avance, ensuite vérifiés par le modèle. Le gain dépend de la part des propositions acceptées[13]. Que le code sorte plus vite que la prose pourrait venir d’une meilleure acceptation ; nous n’avons pas mesuré ce taux pour le confirmer.

Le cache de préfixe, indispensable pour un agent. Dans notre configuration, opencode envoie environ 20 000 tokens d’instructions et de définitions d’outils : 20 à 30 secondes d’attente au premier tour. Le cache évite ensuite de recalculer la partie identique, tant qu’elle reste en mémoire[14]. Il ne supprime ni le traitement des nouveaux tokens, ni l’attente après une éviction ou un redémarrage[14][15].

--max-num-seqs : 256 par défaut[16], et un moteur qui ne démarrait pas. Au premier démarrage, vLLM redémarrait en boucle. Qwen3.8 est un modèle hybride[5] : une partie de ses couches maintient des états récurrents par séquence (le « cache Mamba », dans le vocabulaire de vLLM[17]). Réserver ces états pour 256 séquences simultanées dépassait la mémoire disponible. Limité à 16, le moteur démarre. Ce réglage ne garantit pas seize longues requêtes simultanées ; il a coûté une dizaine de minutes de GPU à comprendre.

Côté système, l’image GPU de Scaleway (ubuntu_noble_gpu_os_13_nvidia) fournit le pilote NVIDIA, Docker et le toolkit conteneur[18] : vLLM tourne dans son image officielle, sans rien compiler. Les poids et le cache de compilation vivent sur un volume séparé de 50 Go : un redémarrage ne retélécharge rien, et le modèle est prêt deux minutes et demie après l’allumage d’une L40S.

Notre économie repose sur l’extinction du GPU après dix minutes d’inactivité. Ce lundi-là, nous avons mesuré ce qu’elle implique : chez Scaleway, une instance éteinte rend sa machine physique[2]. Chaque rallumage doit en trouver une libre, comme une nouvelle réservation.

La seule façon de conserver sa machine est le mode standby, qui facture le calcul comme si elle était allumée[2] : environ 1 070 € par mois pour une L40S[1]. Autant ne jamais éteindre.

L’API de disponibilité donne un état instantané par type de machine (available, scarce, shortage)[3], sans historique, et un site de suivi tiers affichait une L40S « en stock » quelques minutes avant que l’API nous la refuse. Plus tard dans la matinée, en testant la commande « éteindre », nous avons rendu nos deux L4 ; à 10 h 12, notre rallumage a été accepté alors qu’elles étaient encore indiquées en shortage. Nous n’avons pas mesuré la durée des pénuries : le catalogue donne un signal, pas une réservation. Seule une tentative d’allumage tranche.

Ce que nous avons mis en place :

• une erreur explicite. La première version du veilleur répondait un 502 vide quand Scaleway refusait l’allumage. Il répond désormais 503 gpu_unavailable, avec Retry-After: 300 : le client reçoit une erreur explicite et un délai conseillé avant de réessayer ; la reprise automatique dépend du client ;
• un repli en une variable. Le nombre de GPU se lit dans le nom du type (L4-2-24G : deux cartes) et fixe automatiquement le parallélisme du modèle (--tensor-parallel-size 2). Revenir à la L40S : une ligne, un tofu apply, machine éteinte. C’est une adaptation manuelle, pas une bascule automatique ni une garantie de stock. Depuis le 10 novembre, le veilleur fait ce repli seul : si la L40S est refusée, il passe la machine éteinte sur deux L4 et retente, puis repart de la L40S à l’allumage suivant.

Relevés avec un utilisateur, à travers l’API publique :

Le parallélisme tensoriel répartit le modèle sur deux mémoires de 24 Go et impose des échanges entre les cartes, en PCIe sur les L4[7]. En génération de code, nous avons relevé environ 44 tokens par seconde, contre 61 sur L40S : 28 % de débit en moins. Nous n’avons isolé ni le coût des communications, ni comparé les deux configurations en prose. À l’usage, pour un agent de code, c’est surtout le premier tour d’une grosse session qui se fait attendre.

Tout est décrit en OpenTofu, avec un état partagé sur un bucket Object Storage versionné de Scaleway :

• une VM GPU sans port ouvert sur Internet, hormis SSH depuis nos adresses ; le moteur n’écoute que sur son IP privée ;
• un réseau privé qui la relie au veilleur, seul point d’entrée public, en HTTPS ;
• un volume de 50 Go pour les poids, protégé contre la destruction ;
• un enregistrement DNS chez Cloudflare, sans proxy : sinon, Cloudflare déchiffrerait le trafic[19][20] ;
• ni load balancer, ni base managée, ni passerelle publique : environ 24 € HT par mois de coût fixe.

L’intégration continue vérifie le format et la validité du code OpenTofu, les scripts shell et les tests du veilleur, qui tournent contre un faux Scaleway et un faux vLLM. Aucun identifiant cloud n’est fourni au workflow, le backend d’état est désactivé, et aucune commande de déploiement n’est exécutée.

Ce que nous changerions pour un client :

• un test de charge avant de choisir le GPU, avec les longueurs de contexte, la concurrence et la latence attendues. Le nombre d’utilisateurs seul ne départage pas une L40S d’une H100 ;
• une politique de disponibilité explicite : capacité réservée, avec engagement contractuel, si le redémarrage doit être garanti ; éventuellement un petit modèle toujours allumé pour un service dégradé, après validation de sa qualité. Notre pilote n’a pas de redondance ;
• des droits minimaux, en place dans notre pilote depuis le 9 novembre : la clé qui allume et éteint le GPU est limitée aux seules instances du projet, et la commande d’extinction est réservée aux administrateurs ;
• un accord de sous-traitance (DPA) avec l’hébergeur, et l’export de son journal d’audit ;
• un jeu d’évaluation maison, pour vérifier qu’un nouveau modèle fait mieux que l’ancien sur vos tâches à vous.

Ce pilote a permis de servir notre modèle à Paris en quelques jours. Il n’établit pas un engagement de disponibilité : éteindre réduit la facture, mais expose le prochain allumage au stock disponible. C’est une contrainte de conception, pas un incident ; elle se décide avant le premier client.