SLO-Aware Compute Resource Allocation for Prefill-Decode Disaggregated LLM Inference

Each language version is independently generated for its own context, not a direct translation.

Voici une explication simple et imagée de ce papier de recherche, conçue pour être comprise par tous, même sans être expert en informatique.

🚀 Le Dilemme du "Chef de Cuisine" et du "Serveur"

Imaginez un grand restaurant très populaire qui sert des plats complexes (ce sont nos Intelligences Artificielles ou LLM). Dans un restaurant classique, un seul chef doit faire deux choses :

Préparer les ingrédients (c'est l'étape "Prefill" : lire la demande du client).
Cuisiner et servir le plat (c'est l'étape "Decode" : générer la réponse mot par mot).

Le problème ? Ces deux tâches sont très différentes. La préparation demande beaucoup de force brute (calculs), tandis que le service demande de la rapidité et de la précision (mémoire). Si le chef essaie de faire les deux en même temps sur la même table, ça crée des embouteillages : soit le client attend trop longtemps pour voir son premier mot (le plat), soit la livraison des mots suivants est trop lente.

💡 La Solution : Séparer la Cuisine du Service (Disaggregation)

Pour résoudre ce problème, les chercheurs proposent de séparer le restaurant en deux zones distinctes :

Une Cuisine (Prefill) où l'on prépare les ingrédients.
Une Salle de service (Decode) où l'on sert les plats.

C'est ce qu'on appelle la désagrégation Pré-remplissage/Décodage (P/D). C'est une excellente idée, mais cela crée un nouveau problème : Combien de cuisiniers et combien de serveurs faut-il embaucher ?

Trop de cuisiniers et pas assez de serveurs ? La cuisine est pleine, mais les clients attendent leur plat.
Trop de serveurs et pas assez de cuisiniers ? Les serveurs tournent en rond, attendant que la cuisine livre.

C'est là que ce papier intervient. Il propose une recette mathématique pour trouver le nombre parfait de cuisiniers et de serveurs, sans gaspiller d'argent ni mécontenter les clients.

📐 La Recette Magique : Comment calculer le nombre idéal ?

Les auteurs disent : "Ne devinez pas ! Utilisons les maths et un peu d'observation." Voici leur méthode en trois étapes simples :

1. La Théorie de la File d'Attente (Pour la Cuisine)

Pour la partie "Cuisine" (Préparation), ils utilisent une théorie appelée M/M/1 (qui est comme une file d'attente à la banque).

L'idée : Si vous voulez que le client reçoive son premier mot très vite (un objectif appelé TTFT), vous ne pouvez pas faire travailler les cuisiniers à 100 % de leur capacité. Il faut qu'ils aient un peu de temps libre pour réagir immédiatement aux nouvelles commandes.
L'analogie : Imaginez un chef qui cuit des steaks. S'il est occupé à 100 %, il ne peut pas prendre une nouvelle commande tout de suite. Si vous voulez un temps de réponse de 2 secondes, vous devez le laisser travailler à 80 % de sa vitesse maximale. Le papier explique comment calculer cette vitesse "réelle" en fonction de l'attente souhaitée.

2. L'Expérience Pratique (Pour le Service)

Pour la partie "Service" (Décodage), ils font des tests réels.

L'idée : Plus le serveur sert de plats en même temps (gros groupe), plus il est efficace, mais plus il met du temps à finir chaque assiette.
L'analogie : Si un serveur porte 10 plateaux d'un coup, il va vite, mais il risque de renverser quelque chose ou de mettre 10 secondes à poser chaque assiette. S'il porte 1 plateau, il est lent. Les chercheurs ont trouvé le "nombre magique" de plateaux (la taille du lot) qui permet de servir le plus vite possible tout en respectant l'objectif de rapidité par mot (TPOT).

3. L'Équilibre Parfait

Une fois qu'ils savent :

La vitesse réelle de la cuisine (avec la file d'attente).
La vitesse réelle du service (avec les tests).

Ils utilisent une formule simple pour dire : "Pour servir 5 millions de mots par minute, il vous faut exactement 3 cuisines et 4 salles de service."

🧪 Le Résultat : Moins de Gaspillage, Plus de Rapidité

Les chercheurs ont testé leur méthode dans un vrai restaurant (avec de vraies cartes graphiques puissantes).

Sans leur méthode : On risque de mettre 3 cuisines et 3 salles. Résultat : les clients attendent trop pour recevoir leur plat (le service est le goulot d'étranglement).
Avec leur méthode : Ils ont trouvé qu'il fallait 3 cuisines et 4 salles. Résultat : tout le monde est satisfait, les objectifs de rapidité sont respectés, et on n'a pas payé pour une salle de service en trop.

🌟 En Résumé

Ce papier nous donne une boussole pour les entreprises qui veulent faire tourner des intelligences artificielles. Au lieu de deviner combien de machines acheter, elles peuvent maintenant utiliser cette "recette" pour :

Savoir exactement combien de machines de "préparation" et de "réponse" il faut.
Garantir que les utilisateurs ne seront jamais frustrés par la lenteur.
Économiser de l'argent en évitant d'acheter du matériel inutile.

C'est comme passer d'un restaurant où l'on embauche des serveurs au hasard, à un restaurant parfaitement orchestré où chaque membre du personnel travaille au bon moment, au bon endroit, pour le plus grand bonheur des clients !

Each language version is independently generated for its own context, not a direct translation.

Voici un résumé technique détaillé de l'article "SLO-Aware Compute Resource Allocation for Prefill-Decode Disaggregated LLM Inference" (Allocation de ressources de calcul consciente des SLO pour l'inférence LLM décomposée Préremplissage-Décodage), rédigé en français.

1. Problématique

L'inférence des grands modèles de langage (LLM) repose traditionnellement sur une architecture monolithique où les phases de Préremplissage (Prefill) et de Décodage (Decode) s'exécutent sur les mêmes ressources GPU. Cette approche crée des interférences : la phase de préremplissage est limitée par la puissance de calcul (compute-bound), tandis que le décodage est limité par la bande passante mémoire (memory-bandwidth-bound). Ces contraintes opposées rendent difficile l'optimisation simultanée de deux métriques clés :

TTFT (Time-To-First-Token) : Latence jusqu'au premier token.
TPOT (Time-Per-Output-Token) : Latence par token généré.

Bien que la décomposition Préremplissage-Décodage (P/D Disaggregation) permette d'exécuter ces phases sur des instances séparées pour optimiser indépendamment les SLO (Objectifs de Niveau de Service), un défi opérationnel majeur subsiste : comment déterminer le nombre optimal de ressources matérielles (ratio GPU Préremplissage vs GPU Décodage) pour une charge de travail donnée, tout en respectant les contraintes de débit total et de SLO ?

Les méthodes actuelles manquent de rigueur : certaines reposent sur des essais-erreurs, d'autres sur des configurations fixes non divulguées, ou sur des outils de recherche qui ne fournissent pas de méthode complète d'allocation basée sur le débit et les SLO.

2. Méthodologie

Les auteurs proposent une approche hybride combinant modélisation théorique et benchmarks empiriques pour calculer précisément le nombre d'instances nécessaires.

A. Modèle Théorique de Calcul des Ressources

L'objectif est de satisfaire un débit total de tokens ( $TP_{total}$ ) défini par l'utilisateur, en fonction des longueurs moyennes d'entrée ( $L_{in}$ ) et de sortie ( $L_{out}$ ).

Le temps total de calcul est la somme des temps de préremplissage et de décodage. Pour éviter l'inactivité des ressources, le système vise à équilibrer ces temps ( $T_{prefill} = T_{decode}$ ).
À partir de ces équations, les auteurs dérivent le nombre d'instances de préremplissage ( $N_{prefill}$ ) et de décodage ( $N_{decode}$ ) nécessaires, ainsi que le ratio optimal $R_{P/D}$ .
Défi clé : Les formules nécessitent les débits effectifs ( $TP_{prefill}$ et $TP_{decode}$ ) qui varient selon les contraintes de latence (SLO).

B. Estimation du Débit de Préremplissage sous Contrainte TTFT

Pour déterminer le débit réel de préremplissage compatible avec un TTFT cible :

Les auteurs modélisent le processus de préremplissage comme une file d'attente M/M/1.
Ils mesurent d'abord le débit maximal théorique ( $\tilde{TP}_{prefill}$ ) sans temps d'attente.
En utilisant la théorie des files d'attente, ils relient le taux d'arrivée des requêtes ( $\lambda$ ) et le taux de service ( $\mu$ ) au temps de réponse total (TTFT).
Ils déduisent une formule permettant de calculer le débit effectif ( $TP_{prefill}$ ) en fonction du TTFT cible, du temps de surcharge (transmission KV cache, etc.) et de la longueur d'entrée.
Insight : Plus le TTFT cible est strict (faible), plus le débit effectif réalisable diminue.

C. Estimation du Débit de Décodage sous Contrainte TPOT

Pour la phase de décodage, le débit et le TPOT sont corrélés positivement avec la taille du lot (batch size) :

Un lot plus grand augmente le débit mais aussi le TPOT.
Les auteurs effectuent des benchmarks empiriques pour tracer la courbe reliant le TPOT, le débit et la taille du lot.
Ils identifient la taille de lot maximale qui respecte la contrainte TPOT, ce qui permet de déduire le débit de décodage effectif correspondant.

3. Contributions Clés

Modèle théorique unifié : Une formule permettant de calculer le nombre d'instances P/D en fonction du débit total, des SLO, des longueurs de requêtes et des débits effectifs des phases.
Modélisation M/M/1 pour le Préremplissage : Une méthode pour dériver le débit effectif de préremplissage sous contrainte TTFT, en tenant compte de la théorie des files d'attente et des temps de transmission.
Benchmarking Empirique pour le Décodage : Une approche pratique pour déterminer le débit de décodage optimal en fonction des contraintes TPOT via l'analyse des courbes de performance.
Validation en Scénario Réel : Démonstration que cette méthode permet de prédire avec précision l'allocation de ressources pour maximiser l'efficacité tout en respectant les SLO.

4. Résultats Expérimentaux

Les auteurs ont validé leur méthode sur un scénario réel utilisant le modèle DeepSeek-V3.1-Terminus sur des GPU NVIDIA H200, avec l'inférence engine SGLang.

Configuration cible :
- TTFT : 2 secondes.
- TPOT : 20 ms.
- Débit total : 5 millions de tokens par minute (M TPM).
- Longueurs moyennes : 6144 (entrée) / 512 (sortie).
Calculs :
- Le débit effectif de préremplissage calculé (après ajustement TTFT) était d'environ 25 000 tokens/s.
- Le débit de décodage effectif (sous contrainte TPOT) était d'environ 1 700 tokens/s.
- Le ratio optimal calculé était de 0,82:1 (P/D).
- La solution recommandée : 3 instances de Préremplissage et 4 instances de Décodage (3P4D).
Performance :
- La configuration 3P4D a atteint simultanément les seuils TTFT (2s) et TPOT (20ms) à un débit d'environ 4,8 M TPM, très proche de l'objectif de 5 M TPM.
- En comparaison, une configuration déséquilibrée (3P3D) ne pouvait atteindre les SLO qu'à ~3,6 M TPM, limitant l'efficacité globale.
- L'efficacité par nœud était supérieure avec la méthode proposée (0,69 M TPM/nœud contre 0,6 M TPM/nœud).

5. Signification et Impact

Cet article comble un vide critique dans l'industrie de l'inférence LLM. Il fournit une méthodologie systématique et reproductible pour dimensionner les infrastructures de serveurs LLM décomposés.

Optimisation des coûts : Évite le surdimensionnement (gaspillage de ressources) ou le sous-dimensionnement (violation des SLO).
Prédictibilité : Permet aux ingénieurs de planifier les déploiements matériels basés sur des modèles mathématiques et des benchmarks, plutôt que sur des conjectures.
Extensibilité : La méthode est conçue pour être intégrée avec des outils de configuration existants (comme AIConfigurator) et pourrait être étendue à des systèmes de décomposition multimodale (EPD).

En résumé, cette approche transforme la gestion des ressources LLM d'un processus artisanal en une discipline d'ingénierie précise, garantissant à la fois la performance utilisateur et l'efficacité économique.