Chapitre 13 — Autoscaling et atténuation du démarrage à froid

Treizième billet de la tournée chapitre par chapitre de LLM Primer VI : Mettre à l'échelle les systèmes IA. Le chapitre qui explique pourquoi l'autoscaler Kubernetes par défaut provoque des pannes sous trafic LLM, et comment KEDA, Knative et CRIU composent le correctif.

Pourquoi ce chapitre existe

Un assistant de chat oscille d'un facteur 30 entre pic et creux sur une journée. Un outil dev tombe à zéro le week-end. Un produit grand public suit la vague Pacifique-Europe. Provisionner pour le pic gaspille au creux ; provisionner pour le creux fait tomber des requêtes au pic. L'autoscaling garde le déploiement au rythme du trafic ; l'atténuation du démarrage à froid rend l'autoscaling — et particulièrement la mise à l'échelle vers zéro — assez rapide pour que les utilisateurs ne le remarquent pas. Le Chapitre 13 explique pourquoi le HPA Kubernetes standard est le mauvais scaler pour les LLM, sur quels signaux KEDA scale à la place, comment Knative exprime la mise à l'échelle vers zéro, et ce qu'il faut pour comprimer un démarrage à froid de 60–180 secondes en secondes à un chiffre.

13.1 Le HPA échoue au trafic LLM de quatre manières précises

Le HPA par défaut scale sur l'utilisation CPU ou GPU. Il échoue sur les LLM de quatre manières. D'abord, l'utilisation GPU est le mauvais signal — nvidia-smi rapporte la fraction du temps pendant laquelle un kernel tourne, non si le batch est bien empaqueté ou si les requêtes progressent. Un serveur à 95 pour cent d'utilisation avec huit longs préremplissages en file derrière un décodage est surchargé ; un serveur à 60 pour cent d'utilisation avec un batch continu sain va bien. Ensuite, la durée d'une requête LLM (secondes à dizaines de secondes) est longue face à la boucle de contrôle du HPA (15 secondes), donc le scaling est en retard d'une vie de requête sur la charge. Puis, l'unité de capacité n'est pas un pod ; un déploiement désagrégé scale en cliques et le HPA ne comprend pas les cliques. Enfin, le démarrage à froid : un nouveau pod arrive en ligne 60–180 secondes plus tard, longtemps après que le pic qui l'a déclenché a soit surchargé la flotte soit s'est délesté en timeouts. Le mode d'échec typique est une panne de deux minutes lors d'un doublement de trafic, suivie d'un scale-down qui laisse le déploiement sous-provisionné pour le pic suivant.

13.2 KEDA scale sur la profondeur de file, le TTFT et l'occupation KV

KEDA étend le HPA avec un CRD ScaledObject qui lie une charge cible à un ou plusieurs scalers convertissant une métrique externe en un nombre de répliques voulu. Trois signaux comptent pour le service LLM. La profondeur de file est le plus direct : le nombre de requêtes en attente du moteur est l'excédent du travail arrivant sur la capacité de service ; vLLM l'expose comme vllm:num_requests_waiting. Le temps jusqu'au premier token — plus précisément le p95 ou p99 sur une fenêtre glissante — capture la dégradation visible par l'utilisateur et attrape la surcharge asymétrique que la profondeur de file rate (préremplissage saturé mais décodage bien, ou l'inverse). L'occupation du cache KV est prospective ; quand elle franchit 80 pour cent, de nouvelles répliques doivent arriver en ligne avant que les existantes ne commencent à préempter ou rejeter. Un ScaledObject de production compose généralement les trois, le plus agressif l'emportant. Knative Serving se superpose pour la mise à l'échelle vers zéro : sous un petit seuil d'activation, tous les pods sont retirés ; les requêtes entrantes sont retenues par un activateur qui démarre un pod à la demande, ce qui n'est économique que si le démarrage à froid est rapide.

13.3 CRIU compresse un démarrage à froid de 90 s en 3–6 s

Un démarrage à froid 70B se décompose en pull d'image (10–60 s), init Python (2–5 s), chargement des poids (60–120 s), init du contexte CUDA (5–15 s), capture des graphes CUDA (10–30 s), chauffe KV (2–10 s) — total 90–250 s. CRIU (Checkpoint/Restore In Userspace) prend un instantané d'un processus complètement chaud — poids chargés, contexte CUDA en place, graphes capturés, pool KV alloué, health check passé — et le restaure ensuite depuis le disque en secondes. L'utilitaire cuda-checkpoint de NVIDIA (2024) étend CRIU pour gérer l'état GPU : pools de mémoire de périphérique, contexte CUDA, PTX en cache, graphes capturés. Un instantané vLLM chaud restaure en 3–6 secondes depuis un NVMe local. Un DaemonSet préinstalle le checkpoint sur le NVMe de chaque nœud pour que Knative puisse restaurer depuis un fichier local plutôt que par le réseau. Combiné au streaming d'image (démarrer le pull avant sa fin) et au chargement paresseux des poids, des démarrages à froid en moins de cinq secondes sont réalisables en production — le seuil sous lequel la mise à l'échelle vers zéro devient économiquement défendable pour les applications face utilisateur.

Ce que prépare le Chapitre 13

Les Chapitres 1 à 13 ont parcouru la pile physique du service LLM — matériel, moteurs, plateformes, désagrégation, mise à l'échelle. Le reste du livre se tourne vers l'argent. Le Chapitre 14 explique pourquoi le token est l'unité de facturation, pourquoi la sortie est facturée deux à cinq fois plus cher que l'entrée, et comment les tokens de raisonnement invisibles finissent sur la facture. Le Chapitre 15 parcourt le calcul du seuil de rentabilité entre auto-hébergement et fournisseurs d'API, plus la ligne d'ingénierie plateforme que la plupart des équipes sous-estiment. Le Chapitre 16 est le catalogue des mouvements de réduction de coût qui composent.

Prochaine étape — Chapitre 14 : Économie du token et tarification des API. Pourquoi la facture ressemble à ce qu'elle est, et comment le compteur tourne quand personne ne regarde.