Comment la taille du lot affecte-t-elle la latence du premier jeton et celle par jeton ?

Les lots plus importants améliorent souvent le débit total de jetons, mais peuvent augmenter le délai avant le premier jeton et la latence par jeton en raison de la mise en file d’attente, d’itérations plus lourdes et de la pression sur la mémoire.

Un modèle local avec une taille de lot de un peut sous-exploiter son accélérateur, car chaque étape de décodage déplace les poids du modèle pour une quantité de travail très limitée. La combinaison des requêtes amortit ce déplacement et augmente le débit. Cependant, les requêtes peuvent attendre leur admission, les préremplissages longs peuvent bloquer les décodages, et chaque séquence active ajoute du cache KV et du travail de traitement des jetons. Le meilleur lot dépend donc de l’objectif visé : débit, réactivité ou bonput dans le respect d’une contrainte de latence.

Le traitement par lots amortit le travail du modèle entre les requêtes

Une opération matricielle par lots traite simultanément les jetons de plusieurs séquences, ce qui améliore l’utilisation du matériel et répartit les coûts fixes de lancement ou de transfert des poids sur une quantité plus importante de travail utile. Les gains sont les plus importants avant que le calcul, la bande passante mémoire, la capacité du cache ou la surcharge de planification n’atteignent leur saturation.

La planification au niveau de l’itération d’Orca permet aux séquences terminées de quitter le lot et aux nouvelles tâches de le rejoindre entre deux itérations de décodage. Cela évite de contraindre chaque requête à attendre le membre le plus long d’un lot statique.

La taille du lot peut désigner le maximum configuré, le nombre de séquences admises ou le nombre de jetons traités en une itération. Ces valeurs diffèrent avec le traitement continu par lots ; les rapports de performances doivent donc préciser quelle quantité a été contrôlée et observée. Cette distinction reste visible lors des tests ultérieurs en environnement domestique.

La latence avant le premier jeton inclut la mise en file et le préremplissage

Le délai avant le premier jeton commence à l’arrivée d’une requête et inclut l’attente dans le planificateur, le préremplissage de l’invite et la première étape de décodage. Une politique qui attend de constituer un lot peut augmenter le temps d’attente, tandis que l’admission d’une invite volumineuse peut occuper une itération et retarder les requêtes interactives existantes.

Une comparaison actuelle du traitement continu par lots explique comment celui-ci admet et retire dynamiquement les requêtes, ainsi que la manière dont une planification agressive arbitre le débit et le TTFT. Elle montre clairement pourquoi la taille du lot seule ne permet pas de prédire la réactivité avant le premier jeton. Le résultat intermédiaire doit rester vérifiable avant toute automatisation.

Le préremplissage segmenté peut entrelacer les invites longues avec le travail de décodage, mais la taille des segments introduit un compromis supplémentaire. Les petits segments protègent les jetons interactifs, mais ajoutent une surcharge de planification ; les grands segments améliorent l’efficacité du préremplissage tout en créant des intervalles de blocage plus longs. Cette limite doit être mesurée séparément dans des conditions d’utilisation réalistes.

La latence par jeton dépend de l’itération active

Pendant le décodage, une étape produit généralement un jeton par séquence active. Un plus grand nombre de séquences augmente la taille du lot et peut allonger la durée de chaque itération, même si le nombre total de jetons par seconde augmente. Les contextes de longueur inégale, la pression sur le cache, la préemption et la synchronisation distribuée ajoutent de la variabilité.

La dissociation du préremplissage et du décodage de DistServe sépare ces deux opérations, car elles ont des caractéristiques de calcul et des objectifs de service différents. Cette architecture illustre pourquoi l’optimisation du débit global peut entrer en conflit avec le TTFT et le temps par jeton produit. La conséquence pratique apparaît lorsque plusieurs sources se disputent un contexte limité.

La limite à ne pas franchir consiste à choisir le plus grand lot à partir d’un graphique de débit hors ligne pour un assistant domestique interactif. Si la mise en file d’attente ou les intervalles entre les jetons ne respectent pas l’objectif côté utilisateur, le débit nominal ne constitue pas un bonput exploitable, quelle que soit l’utilisation de l’accélérateur.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

$799.00 - $2,499.00

Buy Now

Cartographiez la frontière du bonput des lots

Rejouez de courtes conversations, de longues invites RAG et des tâches en arrière-plan à des taux d’arrivée contrôlés. Faites varier le nombre maximal de séquences et les limites de jetons traités par lots, tout en mesurant les percentiles du TTFT, la latence interjetons, la latence de bout en bout, le débit des invites et des sorties, la profondeur de la file d’attente, l’utilisation du cache, la préemption et les requêtes rejetées.

Appuyez-vous sur le comportement du traitement continu par lots pour distinguer les limites configurées du lot actif observé à chaque itération. Conservez des distributions fixes pour les invites et les sorties, et indiquez le pourcentage de requêtes respectant à la fois les objectifs liés au premier jeton et aux intervalles entre les jetons.

Choisissez le réglage qui maximise le travail terminé dans le respect de ces objectifs, plutôt que le nombre brut de jetons par seconde. Isolez les lots en arrière-plan ou réduisez leur priorité lorsqu’ils diminuent le bonput interactif, puis effectuez de nouveaux tests après toute modification du modèle, de la quantification, du mélange de contextes ou du planificateur.