Qu’est-ce que la désagrégation du préremplissage et du décodage, et pourquoi cela change-t-il le déploiement des LLM ?
La désagrégation du prefill et du décodage sépare le traitement du prompt de la génération des tokens, afin que chaque phase d’un LLM puisse utiliser des workers, des calendriers et des plans de capacité différents.
Un long prompt RAG exige un important pic de calcul avant l’apparition de son premier token, tandis que le décodage effectue ensuite de nombreuses itérations plus modestes, sensibles à la bande passante mémoire. Exécuter les deux phases sur un seul GPU est simple, mais permet aux longs prefills d’interrompre les conversations en cours. La désagrégation déplace la requête et son état KV entre des pools, au prix d’une coordination et de transferts supplémentaires, afin de contrôler indépendamment la latence du premier token et celle de chaque token.
Le prefill et le décodage ont des profils de ressources différents
Le prefill traite tous les tokens du prompt en parallèle et construit le cache KV, produisant un pic de calcul intensif dont la durée augmente avec la longueur du prompt. Le décodage relit continuellement les poids du modèle et l’état KV accumulé pour générer un ou quelques nouveaux tokens.
DistServe identifie les interférences entre le prefill et le décodage lorsque les deux phases partagent des GPU, et associe le prefill au délai avant le premier token, tandis que le décodage détermine le temps par token généré. Les séparer permet au planificateur de protéger chaque objectif indépendamment. Cette distinction reste visible lors des tests ultérieurs à domicile.
La désagrégation n’est pas un parallélisme de modèle classique. Le même modèle peut exister dans les deux pools, tandis que les requêtes passent d’une phase fonctionnelle à l’autre plutôt qu’entre les couches d’un même passage avant. Le résultat intermédiaire doit rester inspectable avant toute automatisation.
Le transfert KV relie les deux pools de workers
Après le prefill, le système doit rendre le cache KV de la requête disponible pour un worker de décodage. Il peut transférer les tenseurs via PCIe ou un fabric réseau, utiliser de la mémoire partagée ou placer les workers de manière à réduire le coût des déplacements.
Splitwise étudie le service spécifique à chaque phase avec des machines et une planification propres à chaque phase, montrant pourquoi l’allocation matérielle peut correspondre aux différentes caractéristiques computationnelles du traitement des prompts et des tokens. La mise en file d’attente et le déplacement de l’état deviennent partie intégrante du chemin de service. Cette frontière doit être mesurée séparément dans des conditions d’utilisation réalistes.
Le pool de décodage ne peut démarrer tant qu’il ne dispose pas d’un état KV et de métadonnées de requête cohérents. Les contextes volumineux augmentent le nombre d’octets à transférer ; une séparation des phases théoriquement plus rapide peut donc être moins performante qu’une exécution colocalisée sur un petit réseau domestique.
La mise à l’échelle indépendante modifie la planification de la capacité
Des pools séparés peuvent ajouter de la capacité de prefill pour les pics de longs documents sans augmenter proportionnellement la capacité de décodage, ou protéger le décodage vocal pendant que la synthèse en arrière-plan utilise les workers de prompt. Le contrôle d’admission peut cibler deux files d’attente et deux budgets de latence. La conséquence pratique apparaît lorsque plusieurs sources se disputent un contexte limité.
Mooncake décrit une coordination du cache KV qui traite le déplacement et le stockage du cache KV comme des préoccupations de premier ordre pour le service. L’architecture montre que la désagrégation déplace le goulot d’étranglement de la planification pure des GPU vers le transfert de l’état et la coordination du cache.
La limite de défaillance est une échelle ou une bande passante insuffisante. Un ou deux GPU domestiques peuvent ne disposer d’aucun appareil supplémentaire pour la spécialisation, et la duplication des poids du modèle ainsi que le transfert KV peuvent consommer davantage de mémoire et de latence que les interférences supprimées.
Comparez les budgets des phases colocalisées et désagrégées
Mesurez le nombre de tokens de prompt par seconde, le délai avant le premier token, le temps par token généré, le nombre d’octets KV transférés, la durée du transfert, l’attente en file, la duplication de la mémoire du modèle, l’énergie et la récupération après défaillance pour des prompts courts, longs et mixtes. Cette dépendance doit rester explicite dans l’interface finale.
Utilisez le prefill par morceaux comme alternative colocalisée. Testez le prefill par morceaux avant d’ajouter un second pool, puis comparez des séquences d’arrivée identiques avec les deux architectures. Le résultat doit donc être confronté aux éléments de preuve d’origine.
N’adoptez la désagrégation que lorsque les interférences entre les phases sont mesurées et que le chemin de transfert préserve les deux objectifs de latence. Sur un petit serveur, une planification colocalisée avec des morceaux de prefill limités peut offrir le même résultat pour l’utilisateur, avec moins de déplacements d’état.
Produits recommandés
Centre Tech & IA
Plus à lire
Qu’est-ce que la dérive des représentations vectorielles, et quand faut-il reconstruire un index de recherche privé ?
Décoder la dérive du modèle, du prétraitement, du corpus et des requêtes ; distinguer la surveillance de l’incompatibilité ; et déterminer quand un index...
Qu’est-ce que la compatibilité des tokeniseurs et pourquoi peut-elle perturber le changement de modèle ?
Décodez l’identité du vocabulaire, la sémantique des tokens spéciaux, les modèles de chat, les tokens mis en cache, les adaptateurs et les vérifications de...
Qu’est-ce que la résidence d’un modèle et quand un service d’IA local doit-il conserver les poids chargés ?
Comprendre la persistance des poids, les niveaux de cache, les démarrages à froid, l’éviction, le multiplexage, la pression mémoire et les situations où un...
