Démarrage à froid des LLM dans Kubernetes : 200 des 294 secondes ne servent pas à charger les poids

L’idée est séduisante : les requêtes adressées au modèle n’arrivent que quelques fois par jour, alors que le nœud GPU est facturé 24 heures sur 24, 7 jours sur 7. La solution logique consiste à supprimer les pods entre les requêtes et à les relancer lorsque la charge apparaît. Pour un service web classique, cela fonctionne : un délai de quelques secondes ne gênera personne. Avec un LLM, la situation est différente.

Pourquoi le démarrage d’un LLM prend-il autant de temps ?

Après le lancement du pod, il faut télécharger l’image, charger les poids dans le GPU, compiler les graphes et préchauffer le moteur. En juillet, l’équipe de H Company écrivait qu’une nouvelle réplique de ses plus grands modèles pouvait mettre jusqu’à 27 minutes avant d’être prête. Elle utilise vLLM sur des nœuds GPU Kubernetes et ajoute des répliques à mesure que la charge générée par les agents augmente. L’autoscaler accroît rapidement le nombre de pods, mais aucun réglage de mise à l’échelle ne peut accélérer toutes ces étapes.

L’auteur de l’analyse pensait que le chargement des poids absorberait l’essentiel du temps. Les mesures publiques ont montré le contraire. Chez Tensorfuse, le démarrage de Llama 3.1 8B sur une L40S a pris 294 secondes. Le téléchargement du modèle et le transfert des poids vers le GPU n’en ont demandé que 94. Les 200 secondes restantes ont été consacrées à la compilation, à la capture des CUDA graphs, à l’initialisation du moteur et aux imports.

Ce qui peut être mis en cache

Un détail est essentiel : une grande partie de ce travail est répétée à chaque démarrage d’un pod, alors que ses résultats peuvent être conservés sur le nœud. C’est là que réside le principal potentiel d’accélération. En stockant les artefacts de compilation sur le nœud et en préchargeant les poids, le nouveau pod ne repart pas de zéro.

Dans l’article complet, l’auteur promet d’aborder les aspects pratiques :

• la source du signal de charge utilisé par KEDA lorsqu’aucun pod n’existe ;
• les éléments qu’il convient de mettre en cache à l’avance ;
• les délais d’expiration qui permettent à la première requête d’attendre que le modèle soit prêt ;
• les manifestes de KEDA HTTP Add-on, le DaemonSet de préchargement et la configuration de vLLM.

Le signal de charge mérite une attention particulière. Lorsqu’il n’y a aucun pod, il est impossible d’en extraire des métriques ; un composant doit donc être placé en amont du service. KEDA HTTP Add-on intercepte précisément la requête, lance le pod et maintient la connexion jusqu’à ce que le modèle soit prêt. Les délais d’expiration sont ici critiques : le client, la passerelle et l’ingress ne doivent pas interrompre la connexion avant la fin du préchauffage du modèle.

Limites et conclusion

Même après toutes les optimisations, le démarrage à froid ne se fera pas en quelques secondes. Pour un chat interactif dont les utilisateurs ne sont pas disposés à attendre une minute, le scale-to-zero constitue un mauvais choix. En revanche, cette approche peut générer des économies substantielles pour les tâches en arrière-plan, les outils internes, les traitements par lots et les agents capables de tolérer ce délai.

La conclusion pratique pour les ingénieurs plateforme est la suivante : avant d’optimiser le téléchargement des poids, examinez où le temps est réellement dépensé. D’après les mesures publiques, plus des deux tiers du démarrage sont consacrés à la compilation et à l’initialisation, et non au réseau. Mettre ces étapes en cache sur le nœud apporte davantage qu’un disque rapide.

Enfin, évaluez honnêtement votre profil de charge. Si les requêtes sont rares et prévisibles, une configuration sans aucune réplique active est rentable. Si les utilisateurs attendent une réponse immédiate, mieux vaut conserver une réplique préchauffée et payer son fonctionnement plutôt que de payer la perte de clients.