SUN: Shared Use of Next-token Prediction for Efficient Multi-LLM Disaggregated Serving

Le papier propose SUN, une approche novatrice qui permet le partage du module de décodage entre différents grands modèles de langage en désagrégeant les tâches de préremplissage et de décodage, optimisant ainsi l'utilisation des GPU et augmentant le débit jusqu'à deux fois sans sacrifier la précision.

L'essentiel

🌞 SUN : Le Covoiturage Intelligent pour les IA

Imaginez que vous gérez un grand parc de taxis (les serveurs GPU) pour une ville remplie de chauffeurs spécialisés.

• Le Chauffeur Math ne connaît que les équations.
• Le Chauffeur Code ne connaît que la programmation.
• Le Chauffeur Droit ne connaît que les lois.

Dans le système actuel (le "monde avant SUN"), chaque chauffeur a sa propre voiture et son propre passager.

• Si le "Chauffeur Math" a 100 passagers, sa voiture est pleine à craquer.
• Si le "Chauffeur Droit" n'a que 2 passagers, sa voiture roule presque à vide, mais il ne peut pas prendre les passagers du "Chauffeur Math" car ils sont dans une voiture différente.
• Résultat : Beaucoup de voitures sont à moitié vides, ce qui coûte cher en essence (électricité) et en usure, alors que d'autres sont en surcharge.

C'est le problème que résout SUN.

---

🚗 L'Analogie du "Châssis" et du "Siège"

Pour comprendre comment SUN fonctionne, il faut voir une IA comme un processus en deux étapes :

1. L'Analyse (Prefill) : C'est le moment où le chauffeur lit la destination du passager, vérifie la carte et prépare le trajet. C'est une tâche très intense en calcul (comme un moteur qui tourne à fond).
2. La Conduite (Decode) : C'est le moment où le chauffeur conduit la voiture, kilomètre après kilomètre, pour déposer le passager. C'est une tâche qui demande beaucoup de mémoire (garder en tête où on est), mais moins de puissance brute.

Le problème actuel : Chaque modèle d'IA (Math, Code, Droit) a son propre "Châssis" (Analyse) ET sa propre "Voiture" (Conduite). On ne peut pas mélanger les passagers.

La solution SUN : Le "Covoiturage de la Conduite"

L'équipe de SUN a eu une idée géniale : Et si on séparait le châssis de la voiture ?

1. Des Châssis Spécifiques (Prefill) : On garde un "Châssis" spécial pour chaque tâche. Le "Châffeur Math" a un châssis adapté aux maths, le "Chauffeur Code" un châssis adapté au code. C'est là qu'ils font leur travail de préparation.
2. Une Voiture Universelle (Decode) : On crée une seule voiture (un module de conduite) qui est figée, standardisée et très efficace. Tout le monde l'utilise.

Comment ça marche ?

• Le "Chauffeur Math" prépare la route sur son châssis spécial.
• Une fois la route prête, il monte dans la Voiture Universelle pour conduire le passager jusqu'au bout.
• Le "Chauffeur Code" fait pareil : il prépare sur son châssis, puis monte dans la même Voiture Universelle.

Le résultat ?
Au lieu d'avoir 4 voitures (une par chauffeur) qui roulent souvent à vide, vous n'avez plus besoin que de 2 ou 3 voitures pour transporter tout le monde. Les voitures tournent à plein régime, l'essence est économisée, et personne n'attend trop longtemps.

---

🧠 Le Secret : "L'Entraînement de la Préparation"

Vous vous demandez peut-être : "Mais si la voiture est la même pour tout le monde, comment le passager 'Math' ne se retrouve-t-il pas dans le bus 'Code' ?"

C'est là que la magie opère.
Dans le système SUN, on n'entraîne pas la voiture (elle reste la même pour tout le monde). On entraîne uniquement le "Châssis" (la phase de préparation).

• Le "Châssis Math" apprend à préparer la route de manière parfaite pour qu'elle soit comprise par la "Voiture Universelle".
• Le "Châssis Code" apprend aussi à préparer sa route pour la même voiture.

C'est comme si vous appreniez à chaque chauffeur à parler le même langage à la voiture, sans avoir besoin de changer la voiture elle-même. Résultat : la voiture conduit aussi bien que si elle avait été construite spécifiquement pour chaque passager.

---

⚡ L'Accélération "QSUN" : La Voiture Électrique

Les chercheurs sont allés encore plus loin avec QSUN.
Ils ont dit : "Et si on rendait cette Voiture Universelle encore plus légère et rapide ?"

Ils ont appliqué une technique de compression (quantification) sur la voiture pour la rendre plus légère (comme passer d'un camion diesel à une voiture électrique compacte).

• Le problème : Une voiture trop légère peut parfois avoir du mal à conduire sur des routes complexes.
• La solution QSUN : On ré-entraîne légèrement les "Châssis" (la préparation) pour qu'ils s'adaptent parfaitement à cette voiture légère.

Le gain ?

• La voiture est 45 % plus rapide.
• Elle consomme moins d'énergie.
• Et elle conduit aussi bien que la voiture lourde originale !

---

🏆 En Résumé : Pourquoi c'est une révolution ?

1. Moins de gaspillage : Plus besoin d'avoir une voiture (GPU) par modèle. On regroupe les passagers dans un nombre réduit de voitures.
2. Moins cher : Moins de voitures à acheter et à entretenir signifie une facture d'électricité et de matériel bien plus basse pour les entreprises.
3. Plus rapide : Les voitures ne sont plus bloquées dans les embouteillages (les files d'attente) car elles sont toujours pleines et efficaces.
4. Pas de perte de qualité : Grâce à l'astuce du "Châssis spécial", les passagers arrivent à destination avec la même précision que s'ils avaient leur propre voiture de luxe.

SUN, c'est simplement passer d'une logique de "chaque modèle sa voiture" à une logique de "covoiturage intelligent", rendant l'IA plus accessible, moins chère et plus rapide pour tout le monde.

Résumé technique

1. Problématique et Contexte

L'essor des applications d'IA agentiques et des workflows multi-modèles a conduit les fournisseurs de services à déployer simultanément des dizaines, voire des centaines, de modèles de langage (LLM) spécialisés. Cependant, le service de ces modèles (Multi-LLM Serving) fait face à deux défis majeurs :

1. Interférence intra-modèle : Dans les architectures classiques, les phases de prefill (calcul intensif sur le prompt) et de décode (génération token par token, limitée par la mémoire) sont exécutées sur les mêmes GPU. Cela crée des conflits de ressources et augmente la latence. Le disaggregated serving (serving disaggregé) résout ce problème en séparant physiquement ces phases sur des dispositifs distincts.
2. Isolement inter-modèle (Le problème central) : Bien que le serving disaggregé sépare les phases, il conserve une isolation par modèle. Chaque modèle spécialisé dispose de ses propres travailleurs de décode (decode workers).
   • Conséquence : Dans des scénarios réels où la charge est fortement déséquilibrée (distribution de Zipf), les modèles populaires saturent leurs décodeurs tandis que les modèles moins utilisés laissent leurs GPU sous-exploités.
   • Limitation : Le batching (regroupement des requêtes) ne peut pas être effectué entre différents modèles car leurs paramètres de décode sont différents, empêchant une utilisation optimale de la mémoire GPU (HBM).

2. Méthodologie : SUN (Shared Use of Next-token Prediction)

L'article propose SUN, une approche novatrice qui permet le partage d'un module de décode unique entre plusieurs modèles spécialisés, tout en maintenant la précision.

A. Décomposition Préfill-Décode

SUN décompose un Transformer decoder-only en deux modules distincts :

• Module de Préfill ($P_{\theta_p}$) : Traite le prompt d'entrée en parallèle pour générer le cache KV (Key-Value) et la distribution du premier token.
• Module de Décode ($D_{\theta_d}$) : Génère les tokens suivants de manière autoregressive en utilisant le cache KV accumulé.

B. Affinement Uniquement sur le Préfill (Prefill-Only Tuning)

Le cœur de l'innovation réside dans la stratégie d'entraînement :

• Pour chaque tâche spécifique (ex: mathématiques, code), seul le module de préfill est affiné (fine-tuned).
• Le module de décode est gelé (frozen) et partagé par tous les modèles.
• Résultat : Le module de préfill apprend à produire des caches KV adaptés à la tâche, mais qui restent compatibles avec le décodeur gelé. Cela permet de fusionner les requêtes de décode provenant de différents modèles dans un même batch, indépendamment de leur origine.

C. Routage Agnostique au Modèle

• Routage Préfill : Déterministe, basé sur la tâche (ex: une requête de code va au préfill "code").
• Routage Décode : Agnostique. Les requêtes de décode sont réparties de manière équilibrée sur un pool partagé de travailleurs de décode, maximisant ainsi l'utilisation des GPU.

D. QSUN (Quantized SUN)

Pour aller plus loin, les auteurs proposent QSUN, une variante quantifiée :

• Le module de décode partagé est quantifié (poids uniquement, 4 bits).
• Une ré-affinement du préfill (prefill re-tuning) est effectué après la quantification. Cela permet au module de préfill d'ajuster ses sorties pour compenser les erreurs de représentation dues à la quantification du décodeur, récupérant ainsi la précision perdue sans briser le partage du décodeur.

3. Contributions Clés

1. Partage de décode inter-modèle robuste : SUN est la première méthode à éliminer l'isolation inter-modèle dans le serving disaggregé en partageant un décodeur gelé, tout en préservant la précision des modèles entièrement affines.
2. Routage pour une haute utilisation : Grâce au partage, SUN permet d'équilibrer la charge sur un pool réduit de GPU de décode, augmentant considérablement le débit par GPU.
3. Décodage quantifié préservant la précision : QSUN combine la quantification des poids (pour réduire le trafic mémoire) avec un ré-affinement ciblé du préfill, offrant un gain de vitesse significatif sans sacrifier la qualité.

4. Résultats Expérimentaux

Les expériences ont été menées sur des modèles comme LLaMA3.1-8B et Qwen3, avec des tâches de mathématiques, de génération de code et d'appel d'outils.

• Précision : SUN atteint une précision comparable à l'affinement complet (Full Fine-Tuning) sur la plupart des benchmarks (ex: GSM8K, HumanEval, BFCL), validant la compatibilité des caches KV générés par le préfill avec le décodeur gelé.
• Efficacité Système (Throughput) :
  • SUN améliore le débit par GPU de jusqu'à 2,0x par rapport à une base disaggregée classique.
  • Il permet de réduire le nombre de GPU de décode nécessaires de 50% tout en maintenant le débit global du système.
  • La latence par token de sortie (TPOT) reste dans une marge de 5% par rapport à la base.
• Robustesse aux charges déséquilibrées : Contrairement aux bases isolées qui souffrent de goulots d'étranglement lorsque la charge est skewée (Zipf), SUN maintient un débit stable et une interactivité élevée même avec des distributions de trafic très inégales.
• Performance de QSUN :
  • Par rapport à AWQ (quantification standard), QSUN offre une accélération de 45% (réduction du TPOT) tout en récupérant la précision proche du modèle full-precision.
  • QSUN réduit le Time-to-First-Token (TTFT) de 17% par rapport à AWQ, car la phase de préfill (calcul intensif) reste en pleine précision, évitant les surcoûts de déquantification.

5. Signification et Impact

Ce travail représente une avancée majeure pour l'infrastructure de service des LLMs :

• Réduction des Coûts (TCO) : En consolidant les ressources de décode (goulots d'étranglement mémoire) sur un pool partagé et en permettant l'utilisation de GPU moins nombreux ou moins puissants, SUN réduit considérablement le coût total de possession.
• Évolutivité des Agents : Il rend économiquement viable le déploiement de centaines de modèles spécialisés collaborant dans des workflows d'agents complexes, là où l'isolement actuel rendrait l'infrastructure prohibitivement coûteuse.
• Efficacité Énergétique : Une meilleure utilisation des GPU se traduit directement par une réduction de la consommation énergétique par token généré.

En résumé, SUN transforme le paradigme du service Multi-LLM en passant d'une isolation rigide à une architecture de ressources partagées dynamiques, résolvant le problème de fragmentation des ressources mémoire tout en garantissant la qualité des réponses.