Breaking the Ice: Analyzing Cold Start Latency in vLLM

Résumé Technique : Briser la glace : Analyse de la latence de démarrage à froid dans vLLM

Énoncé du problème
À mesure que les modèles de langage de grande taille (LLM) sont déployés à grande échelle, particulièrement dans les paradigmes d'informatique sans serveur (serverless), la latence de « démarrage à froid » (cold start) des moteurs d'inférence est devenue un goulot d'étranglement critique. Dans les environnements serverless, les fournisseurs de cloud déploient de nouvelles instances de conteneurs pour gérer les pics de trafic, introduisant une latence ordres de grandeur supérieure à celle du service de requêtes sur des instances « chaudes ». Cette latence impacte principalement le temps jusqu'au premier jeton (Time-to-First-Token ou TTFT). Bien que vLLM soit devenu l'outil d'inférence de référence pour de nombreuses charges de travail grâce à ses optimisations (ex: PagedAttention, chunked prefill), son comportement de démarrage manque d'une caractérisation systématique de bout en bout. L'évolution rapide de vLLM (ex: l'introduction de l'API V1 et de torch.compile) et la complexité croissante de sa base de code ont rendu difficile la compréhension de l'impact des changements architecturaux sur la performance de démarrage. La littérature existante se concentre souvent sur des composants isolés (ex: chargement de checkpoints ou matérialisation d'état) plutôt que sur le processus de démarrage holistique, entravant la conception de politiques d'autoscaling efficaces pour les services de LLM conteneurisés.

Méthodologie
Les auteurs mènent une caractérisation complète de la performance du processus de démarrage de vLLM, définissant le « temps de démarrage » comme la durée entre l'initialisation du moteur d'inférence et le moment où il est pleinement opérationnel et prêt à servir des requêtes.

• Configuration expérimentale : Les expériences ont été menées avec vLLM v0.10.1.1 sur 22 LLM divers (allant de 0,5B à 32B de paramètres, incluant des architectures MoE) sur des GPU NVIDIA H100 et L40S. L'étude a utilisé quatre nœuds matériels distincts avec des configurations de CPU variées (AMD EPYC, Intel Xeon) et de stockage (cache DRAM vs. SSD PCIe 5.0).
• Décomposition : Le processus de démarrage a été décomposé en six étapes fondamentales :
  1. Amorçage du framework (détection de la plateforme, imports, initialisation des workers).
  2. Initialisation du tokenizer.
  3. Chargement du modèle (initialisation de la structure et chargement des poids).
  4. Compilation Torch (transformation Dynamo et chargement des graphes compilés).
  5. Profilage du cache KV.
  6. Capture des graphes CUDA.
• Analyse : Les auteurs ont mesuré la latence de chaque étape sous diverses conditions, analysant les tendances de mise à l'échelle par rapport aux paramètres du modèle (taille, couches, vocabulaire), aux paramètres système (types de CPU/GPU) et aux drapeaux de configuration. Ils ont également évalué l'impact de différents backends de chargement de poids (Safetensors, Run:ai Streamer, CoreWeave Tensorizer) et de la présence de graphes compilés mis en cache.
• Modélisation prédictive : Sur la base des tendances de mise à l'échelle observées, les auteurs ont développé un prédicteur analytique léger de type « boîte blanche ». Ce modèle utilise une régression linéaire pour chacune des six étapes de manière indépendante, entraînée sur les configurations de modèles et les caractéristiques de l'environnement, afin de prédire la latence totale de démarrage.

Résultats clés

• Nature limitée par le CPU : L'analyse révèle que le processus de démarrage de vLLM est principalement limité par le CPU (CPU-bound). Bien que les deux dernières étapes (profilage du cache KV et capture des graphes CUDA) soient limitées par le GPU, la majeure partie de la latence (incluant l'amorçage du framework, la tokenisation, le chargement du modèle et la compilation) est pilotée par les performances du CPU. Changer de GPU (H100 vs. L40S) n'a produit que des accélérations négligeables pour la plupart des étapes, tandis que le changement de CPU a entraîné des variations de performance significatives.
• Tendances de mise à l'échelle :
  • Initialisation du tokenizer : Évolue linéairement avec la taille du fichier du tokenizer (PCC = 0,99).
  • Chargement du modèle : Le temps de chargement des poids évolue linéairement avec la taille des paramètres du modèle et la précision (PCC = 1,00). Le chargement depuis des SSD ralentit cette étape d'environ 0,5x mais a un impact minimal sur le temps de démarrage total (qui ne s'améliore que d'environ 1,04x) car le chargement des poids constitue une faible fraction de la durée totale.
  • Compilation Torch : Le temps de transformation Dynamo évolue avec le nombre de couches et la complexité des couches (approximée par la taille du fichier du graphe compilé, PCC = 0,96). Le chargement des graphes compilés évolue également linéairement avec la taille du graphe (PCC = 0,95).
  • Profilage du cache KV : Évolue linéairement avec la taille des paramètres du modèle pour les modèles non-MoE (PCC = 0,92). Les modèles MoE divergent en raison du routage dynamique des experts.
  • Capture des graphes CUDA : Évolue linéairement avec la taille du modèle et le nombre de tailles de lots (batch sizes) capturés (PCC = 1,00).
• Impact du cache : Désactiver le cache pour les graphes compilés augmente l'étape de « stockage des graphes compilés » de ~3–6 secondes à ~11–21 secondes, soulignant l'importance du cache pour les exécutions ultérieures.
• Précision du prédicteur : Le prédicteur analytique proposé atteint une haute précision avec une erreur quadratique moyenne (MSE) de 2,42 secondes et une erreur maximale de 2,08 secondes sur les modèles de validation. Le modèle reste précis (MSE 2,62s) lorsqu'il est validé sur vLLM v0.11, démontrant sa robustesse aux mises à jour de version.

Signification et Revendications
L'article affirme fournir la première caractérisation détaillée et systématique du processus de démarrage de vLLM. Ses principales contributions sont :

1. Décomposition : Identification et isolation de six étapes fondamentales qui constituent le processus de démarrage, révélant que le processus est largement limité par le CPU plutôt que par le GPU.
2. Interprétabilité : Établissement de tendances de mise à l'échelle cohérentes et interprétables (principalement linéaires) entre des paramètres spécifiques (ex: taille du modèle, taille du tokenizer, taille du graphe) et la latence pour chaque étape.
3. Capacité prédictive : Développement d'un modèle analytique léger de type « boîte blanche » qui prédit avec précision la latence de démarrage pour des configurations matérielles et de modèles données. Cet outil est conçu pour assister dans la planification des ressources et les décisions d'autoscaling pour les environnements d'inférence serverless.
4. Pérennité : Les auteurs soutiennent que, bien que les valeurs de paramètres spécifiques puissent changer avec les mises à jour de vLLM, la décomposition en six étapes capture des opérations fondamentales inhérentes aux moteurs d'inférence modernes. Par conséquent, la méthodologie reste applicable, nécessitant seulement un réajustement des paramètres pour les versions futures plutôt qu'une réanalyse complète.

L'article positionne ce travail comme une étape fondamentale vers la conception de politiques d'autoscaler percutantes pour les frameworks d'inférence conteneurisés et serverless, allant au-delà du traitement du démarrage comme une boîte noire monolithique.