Quelles sont les causes des pics de latence du premier jeton après qu’un service d’IA local change de modèle ?

La latence du premier token augmente généralement après un changement de modèle, car le modèle nouvellement sélectionné doit reconstruire son état résident avant de pouvoir traiter le prompt.

Un serveur IA domestique peut répondre rapidement avec un modèle déjà en mémoire, passer à un modèle de vision ou de codage, puis marquer une pause avant le premier token. Le délai peut inclure la lecture des poids, la déquantification, le transfert vers le périphérique, la compilation des noyaux, la capture du graphe CUDA, l’allocation du cache et le préremplissage du prompt. L’étape dominante dépend du stockage, de la mémoire disponible de l’accélérateur, de la stratégie d’exécution et du fait que le modèle précédent ait été entièrement évincé ou non.

Le chargement à froid des poids est la première famille de causes

Si le modèle suivant n’est pas présent dans la RAM ou la VRAM, le serveur doit lire un ou plusieurs fragments de checkpoint, les valider ou les mapper, construire les tenseurs et transférer les poids utilisables vers le périphérique d’exécution. Un fichier plus volumineux ou un chemin NAS plus lent prolonge la pause avant le début de l’inférence.

Les mesures de la latence de démarrage à froid des LLM montrent que le démarrage peut dominer le TTFT lorsque l’état du modèle est froid. Ce symptôme se manifeste par d’importantes lectures du stockage et un temps de chargement du modèle avant l’exécution des noyaux de préremplissage du prompt. Cette distinction reste visible lors des tests domestiques ultérieurs.

Si le passage entre deux modèles qui restent tous deux résidents produit le même pic, le chargement des poids n’explique pas tout. L’observation déterminante consiste à vérifier si les octets lus et l’état des modèles résidents changent avec la requête lente.

L’initialisation de l’environnement d’exécution crée un deuxième chemin à froid

Un modèle chargé peut malgré tout être froid sur le plan opérationnel. L’environnement d’exécution peut initialiser un contexte de périphérique, sélectionner des noyaux, compiler des formes, capturer des graphes, allouer des blocs KV ou construire des caches de tokenizer et de modèles de prompt lors de la première requête après l’activation.

Une analyse technique de la diffusion et de la mise en chauffe des modèles sépare la diffusion depuis le stockage de l’initialisation et de la mise en chauffe. La signature de cette étape se caractérise par des entrées-sorties modestes liées au checkpoint, suivies d’une compilation, d’une allocation ou d’une activité de l’accélérateur avant le traitement du prompt. Le résultat intermédiaire doit rester inspectable avant que l’automatisation ne prenne le relais.

La forme du modèle, le backend de quantification, la limite de contexte, les profils de lots et l’état du pilote déterminent quels artefacts peuvent être réutilisés. Un retour rapide peut être rapide si les caches ont été conservés, tandis qu’une éviction due à la pression mémoire rend à nouveau le même chemin froid.

La mise en file d’attente et le préremplissage peuvent se faire passer pour un délai de chargement du modèle

La requête de changement peut attendre l’arrêt du modèle, la récupération de mémoire, un autre utilisateur ou un long prompt. Une fois admis, le préremplissage traite chaque token d’entrée avant le décodage ; des historiques plus longs augmentent donc le TTFT sans modifier le temps de chargement du modèle. Cette limite doit être mesurée séparément dans des conditions d’utilisation réalistes.

La conception de service avec admission du cache KV paginé explique comment les séquences actives consomment des blocs KV paginés et comment l’admission dépend de la capacité de cache disponible. Un changement qui modifie les réservations du cache peut donc changer le temps d’attente indépendamment de la taille du checkpoint.

La limite révélatrice est celle d’un modèle chaud et résident, avec une initialisation stable et un pic de latence qui suit la longueur du prompt ou la concurrence. Dans ce cas, le changement de modèle n’est qu’une corrélation ; le préremplissage ou la planification en est la cause directe.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

$799.00 - $2,499.00

Buy Now

Décomposez le TTFT en chargement, mise en chauffe, attente et préremplissage

Relancez des prompts fixes tout en enregistrant l’éviction du modèle, les octets du checkpoint, le débit du stockage, le transfert de l’hôte vers le périphérique, la création du contexte du périphérique, la compilation des noyaux, la capture du graphe, l’allocation KV, le temps d’attente en file, la durée du préremplissage et la première étape de décodage sur une même horloge monotone. La conséquence pratique apparaît lorsque plusieurs sources se disputent un contexte limité.

Comparez la trace au routage des modèles selon la mémoire, puis testez séparément le changement à froid, le retour immédiat au modèle précédent, le routage avec deux modèles résidents, le prompt court et le prompt long. Conservez l’échantillonnage, le client et la concurrence afin que seul l’état visé change. Cette dépendance doit rester explicite dans l’interface finale.

Attribuez le pic à la première étape qui augmente. Gardez les poids en mémoire lorsque le chargement domine, conservez les artefacts compatibles lorsque l’initialisation domine et modifiez la politique d’admission ou de contexte lorsque l’attente ou le préremplissage - et non le changement lui-même - détermine le TTFT.