Pourquoi la latence du premier jeton d’un LLM local augmente-t-elle après une période d’inactivité du serveur ?
La latence du premier token augmente souvent après une période d'inactivité, car la requête suivante doit reconstituer l'état du modèle, de la mémoire, de l'accélérateur et de l'alimentation que les requêtes à chaud réutilisent.
Un serveur d'IA domestique peut répondre rapidement aux invites répétées, puis sembler lent lorsque la première requête arrive le lendemain matin. Le modèle peut toujours exister sur le disque, mais ses pages, son allocation GPU, ses noyaux et son contexte d'exécution peuvent ne plus être chauds. La vitesse du stockage, la pression sur la mémoire, l'expulsion par le moteur d'exécution, la gestion de l'alimentation des appareils et la longueur de l'invite déterminent l'ampleur du délai qui réapparaît.
Le temps d'inactivité supprime plusieurs types d'états chauds
Une requête à chaud peut réutiliser des poids déjà présents dans la RAM ou la VRAM, des pages du système de fichiers conservées par le système d'exploitation, des bibliothèques d'accélération initialisées, des noyaux compilés, des pools de mémoire et un processus de modèle actif. Le nettoyage lié à l'inactivité peut ne supprimer qu'une seule couche ou démanteler l'ensemble du processus.
le chargement de points de contrôle multiniveau réduit le démarrage des modèles serverless en conservant les points de contrôle à proximité des accélérateurs, en chargeant les données via plusieurs niveaux de stockage et en planifiant les requêtes là où l'état du modèle est déjà local. Sa conception montre que la latence à froid est une chaîne de transferts et d'étapes d'initialisation plutôt qu'une simple valeur de lecture sur disque.
Le délai observable dépend de la couche qui est devenue froide. Un processus resté actif peut n'avoir besoin que de relancer la fréquence de l'appareil, tandis qu'un modèle expulsé doit lire les poids, allouer la mémoire de l'appareil, reconstruire les structures du moteur d'exécution, puis traiter l'invite avant d'émettre un token.
Le chargement du modèle et le préremplissage s'accumulent avant l'apparition du moindre token
Le délai avant le premier token inclut la mise en file d'attente, la disponibilité des poids, l'initialisation du moteur d'exécution, la tokenisation et le préremplissage de l'ensemble de l'entrée. Un débit de décodage élevé ne peut pas masquer ces étapes, car aucun token de sortie n'existe tant que le préremplissage n'a pas produit le premier état de décodage.
La réutilisation de la mémoire GPU conserve les paramètres dans la mémoire GPU inutilisée et utilise une planification tenant compte de l'affinité afin de réduire les transferts répétés. Les améliorations rapportées du démarrage à froid montrent pourquoi la conservation d'une présence partielle peut être importante, même lorsqu'un service ne peut pas garder chaque modèle entièrement chargé.
Une longue invite système peut donc rester lente après le réchauffement des poids, tandis qu'une invite courte peut toujours être bloquée par le chargement à froid du modèle. La séparation du temps de chargement, de l'initialisation, du préremplissage et du premier décodage empêche une seule valeur moyenne de TTFT de masquer le véritable composant froid.
Les économies d'énergie constituent généralement une couche plus réduite, mais mesurable
Les processeurs, les GPU, les appareils NVMe et les liaisons PCIe peuvent passer à des états de consommation réduite pendant les périodes d'inactivité. La première rafale doit augmenter la fréquence et rétablir les chemins actifs, ce qui ajoute une courte phase de montée en régime avant le début des calculs soutenus ; la mise en veille agressive de l'hôte peut ajouter beaucoup plus de délai en suspendant les services ou les disques.
Le chevauchement des étapes du démarrage à froid combine le chargement du modèle, les communications et le calcul pour les démarrages à froid de LLM en périphérie. Ce travail montre que masquer une étape de démarrage nécessite de coordonner les autres, notamment lorsque les poids et le calcul sont répartis entre des appareils aux ressources limitées.
L'erreur consiste à attribuer chaque première réponse lente à l'état d'alimentation. Si le délai se mesure en nombreuses secondes, l'expulsion du modèle, les lectures du stockage, le démarrage du conteneur ou le préremplissage de l'invite dominent généralement une transition d'horloge de l'ordre de la milliseconde. Diagnostiquez la chronologie au lieu de désactiver par défaut toutes les économies d'énergie.
Faites la distinction entre le coût du démarrage à froid et celui de l'invite froide
Envoyez une même invite courte après 0, 1, 10, 60 et 480 minutes d'inactivité. Relevez pour chaque intervalle la durée de vie du processus, la présence du modèle en mémoire, l'utilisation de la RAM et de la VRAM, le volume de données lu, la fréquence des appareils, le temps d'attente en file, la tokenisation, le préremplissage, le premier décodage et le TTFT total.
Comparez la couche de stockage avec le stockage nécessaire au démarrage à froid du modèle, puis répétez l'opération en maintenant le processus de travail actif, en réchauffant uniquement le cache du système de fichiers, en gardant uniquement la RAM de l'hôte chaude et en modifiant la longueur de l'invite. Chaque test doit modifier une seule couche d'état plutôt que de combiner toutes les optimisations.
Ne considérez le serveur comme chaud que lorsque des périodes d'inactivité répétées maintiennent le TTFT requis sans pénaliser les autres services. Si le maintien du modèle en mémoire crée une pression sur la mémoire ou bloque des charges de travail prioritaires, acceptez un démarrage à froid limité et rendez-le visible au lieu de masquer ce compromis.
Produits recommandés
Centre Tech & IA
Plus à lire
Qu’est-ce qui amène un planificateur d’agent IA à répéter des étapes déjà effectuées ?
Suivez les étapes répétées du planificateur à travers la persistance de l’état, les preuves d’achèvement, l’analyse des résultats des outils, la conservation du contexte,...
Qu’est-ce qui provoque des erreurs d’autorisation uniquement dans les sous-processus des agents d’IA ?
Comparez l’identité du processus parent et du processus enfant, la vue du système de fichiers, l’environnement, les capacités, la politique de sécurité et le...
Quelles sont les causes de la saturation du processeur lorsque le transcodage matériel et l’IA vidéo s’exécutent simultanément ?
Suivez la saturation du processeur au niveau du déchargement des codecs, de la conversion des pixels, des copies d’images, du prétraitement de l’IA, de...
