FluidPD : réaffectation dynamique des ressources pour équilibrer le préfill et le décodage dans le service de LLM

Le déséquilibre entre préfill et décodage

L'architecture de service des modèles de langage (LLM) a évolué vers la séparation des phases de préfill et de décodage. Cette dissociation, connue sous le nom de séparation préfill-décodage, permet d'optimiser chaque phase de manière indépendante, car elles présentent des motifs d'exécution et des objectifs de service (SLO) très distincts.

Cependant, les charges de travail réelles ne sont pas statiques. Les pics courts et les changements soutenus dans le ratio de demande entre préfill et décodage peuvent rapidement déséquilibrer une configuration initialement bien dimensionnée. Ce désajustement provoque des violations de SLO de latence, même lorsque de la capacité inactive existe ailleurs dans le système.

Mécanismes d'élasticité in-place de FluidPD

FluidPD est un système de service P/D séparé qui introduit deux mécanismes complémentaires pour gérer ce déséquilibre. Le premier, FluidToken, traite le déséquilibre transitoire en déchargeant une portion limitée du calcul de préfill vers les travailleurs de décodage lorsque ceux-ci disposent d'une capacité inactive.

Le second mécanisme, FluidRole, gère le déséquilibre soutenu en réaffectant les travailleurs en cours d'exécution entre les rôles de préfill et de décodage. Cette réaffectation est effectuée in-place, ce qui évite le rechargement du modèle et le redémarrage du moteur d'inférence, permettant une adaptation beaucoup plus rapide aux changements de charge.

Métriques et conditions d'évaluation

Les auteurs du préprint rapportent que FluidPD améliore le respect global des SLO de jusqu'à 94,6 points de pourcentage par rapport à SGLang statique. Cette amélioration est évaluée en utilisant des traces de travail de production d'Azure, ce qui suggère une pertinence pratique pour les environnements à grande échelle.

Il est important de noter que ces métriques proviennent du résumé du préprint et n'ont pas été vérifiées de manière indépendante. L'évaluation se concentre sur la capacité du système à maintenir les SLO sans provisionner de travailleurs supplémentaires, un objectif clé pour l'efficacité opérationnelle.

Coûts opérationnels et dépendances

La stratégie de FluidPD dépend de la capacité des travailleurs de décodage à absorber une partie de la charge de préfill (FluidToken) et de la possibilité de réaffecter les rôles sans redémarrer le moteur (FluidRole). Cela implique que l'architecture du système d'inférence doit prendre en charge ces opérations de manière native.

Bien que le système évite le besoin de GPU de réserve, la rapidité de la réaffectation et l'efficacité de la décharge de calcul sont des facteurs critiques. Si la réaffectation n'est pas suffisamment rapide, le déséquilibre pourrait persister et causer des violations de SLO avant que le système ne se stabilise.

Tests externes et déploiement en production

Avant de recommander le déploiement de FluidPD en production, il serait nécessaire d'évaluer ses performances avec des charges de travail réelles et diverses, et non seulement avec des traces d'Azure. Cela inclurait des tests avec différents modèles de langage, tailles de lot et motifs de trafic.

De plus, la disponibilité du code et des configurations pour reproduire les résultats, ainsi que les limites d'élasticité du système, doivent être vérifiées. L'absence d'une révision par les pairs indépendante et la nature de préprint du travail nécessitent une prudence supplémentaire lors de l'interprétation de ses affirmations de performance.

Poursuivre l’exploration

Corrections et transparence

Si vous repérez une information incorrecte ou obsolète, envoyez-nous la page et la source à vérifier.