💻 computer science

DriftSched: Adaptive QoS-Aware Scheduling under Runtime Token Drift for Multi-Tenant GPU Inference

Cet article présente DriftSched, un cadre d'ordonnancement sensible à la QoS pour l'inférence de LLM multi-locataire qui utilise un mécanisme de rétroaction en ligne pour corriger les erreurs d'estimation de jetons au moment de l'exécution, démontrant que si le calibrage adaptatif améliore considérablement la précision de l'estimation, la politique d'ordonnancement Shortest-Job-First (SJF) produit les réductions les plus substantielles de la latence de bout en bout et de la latence de queue.

Auteurs originaux : Kathiravan Palaniappan

Publié 2026-06-03

📖 6 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Kathiravan Palaniappan

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Imaginez que vous dirigez un restaurant très populaire avec une seule cuisine (le GPU) et un seul chef. Vous avez trois types de clients :

Les VIP (Premium) : Ils veulent être servis rapidement et sont prêts à payer plus cher.
Les Habitués (Standard) : Ils veulent juste un repas normal.
Les Acheteurs en Gros (Batch) : Ils commandent d'énormes plateaux de traiteur et ne sont pas pressés.

Le problème ? La cuisine est débordée. Les commandes s'accumulent et certains attendent une éternité tandis que d'autres sont servis rapidement. Le chef doit décider qui cuisiner ensuite. C'est ce qu'on appelle l'« ordonnancement » (scheduling).

Le problème central : Deviner la charge de travail

Pour décider qui servir ensuite, l'ordonnanceur doit savoir quelle est l'ampleur de chaque commande.

Est-ce une simple salade (travail court) ?
Ou est-ce un repas complexe à 5 services (travail long) ?

Si l'ordonnanceur se trompe dans son estimation, c'est le chaos. S'il pense qu'une énorme commande de traiteur est petite, il pourrait la servir avant l'apéritif rapide d'un VIP, ce qui ferait attendre le VIP trop longtemps. C'est ce qu'on appelle la « mauvaise classification de la charge de travail » (Workload Misclassification).

Les deux façons de deviner

L'article, DriftSched, teste deux façons de deviner la taille d'une commande :

Le « Guess de Paresseux » (Proxy par les espaces blancs) : Imaginez compter les mots sur le ticket de commande. S'il y a 10 mots, c'est probablement petit. S'il y en a 100, c'est grand. C'est rapide et facile pour l'hôte, mais c'est imprécis. Une phrase courte peut être complexe à cuisiner, et une phrase longue peut être simple.
Le « Guess d'Expert » (Sensible au Tokenizer) : Imaginez que l'hôte lise réellement la recette et sache exactement combien d'ingrédients et d'étapes sont impliqués. C'est précis, mais cela prend un peu plus de temps et d'effort pour l'hôte à calculer.

La solution : DriftSched

DriftSched est un système intelligent qui gère ce restaurant. Il possède une fonctionnalité spéciale appelée « Calibration Adaptative » (ou EMA).

Voyez les choses ainsi : si l'hôte utilise le « Guess de Paresseux » et réalise qu'il sous-estime systématiquement le temps de préparation d'un repas de type « Rapport Technique », DriftSched apprend de ses erreurs. Il se dit : « Ah, chaque fois que nous estimons qu'un Rapport Technique est petit, il est en réalité 20 % plus long. La prochaine fois, j'ajouterai 20 % à l'estimation. »

Au fil du temps, le « Guess de Paresseux » devient presque aussi bon que le « Guess d'Expert » car le système corrige ses propres erreurs en fonction de ce qui s'est réellement passé en cuisine.

Les cinq stratégies d'ordonnancement

L'article a testé cinq règles pour décider qui mange ensuite :

FIFO (First-In, First-Out) : Comme une file d'attente standard. Premier arrivé, premier servi. C'est équitable, mais si un Acheteur en Gros est devant vous avec une commande énorme, vous attendrez une éternité.
Priorité : Les VIP passent toujours en tête de liste. Les habitués et les acheteurs en gros attendent. Excellent pour les VIP, terrible pour tous les autres.
Pondéré (Weighted) : Un compromis. Les VIP sont servis 50 % du temps, les habitués 30 % et les acheteurs en gros 20 %. Tout le monde a son tour, mais les VIP en profitent davantage.
SJF (Shortest-Job-First) : Le chef choisit toujours la plus petite et la plus rapide commande ensuite, peu importe qui a commandé. Si un Acheteur en Gros a un petit accompagnement, celui-ci sera cuisiné avant le plat principal d'un VIP.
Priorité par Âge (Aging Priority) : Comme la Priorité, mais si un Acheteur en Gros attend trop longtemps, son ticket reçoit un « tampon » qui booste sa priorité afin qu'il ne meure pas de faim.

Qu'ont-ils découvert ?

1. La précision compte, mais la stratégie compte plus
Utiliser le « Guess d'Expert » (Tokenizer) est meilleur que le « Guess de Paresseux » (Espaces blancs). Cependant, la règle que vous utilisez pour choisir le client suivant (la politique d'ordonnancement) a un impact bien plus important sur les temps d'attente que la précision de votre estimation de la taille de la commande.

2. Le SJF est le roi de la vitesse
La règle SJF (Shortest-Job-First) a été la plus rapide. Elle a réduit le temps d'attente moyen d'environ 42 % par rapport à la file standard (FIFO). Pourquoi ? Parce qu'en traitant d'abord toutes les petites commandes rapides, la cuisine reste occupée et efficace, et moins de personnes restent bloquées derrière une seule commande géante.

3. La Priorité est le roi des VIP
Si vous voulez satisfaire les VIP, l'ordonnancement par Priorité est le meilleur. Les VIP n'ont attendu qu'environ 77 secondes, tandis que les Acheteurs en Gros ont attendu environ 427 secondes. Le SJF, en revanche, ne se souciait pas de qui vous étiez ; il s'intéressait seulement à la taille de votre commande. En fait, sous le régime SJF, des Acheteurs en Gros étaient parfois servis plus vite que des VIP parce que leurs commandes se trouvaient être plus petites.

4. Le « Guess de Paresseux » peut être réparé
La fonction d'auto-correction du système (EMA) a bien fonctionné. Lorsque le système utilisait le « Guess de Paresseux » imprécis, il apprenait à ajuster ses estimations au fil du temps, réduisant les erreurs d'environ 40 %. Cependant, si vous utilisez déjà le « Guess d'Expert », l'auto-correction n'aide pas beaucoup car les estimations étaient déjà précises.

L'essentiel à retenir

Si vous voulez le service le plus rapide globalement : Utilisez le SJF (Shortest-Job-First). Cela vide la file d'attente le plus vite.
Si vous voulez protéger vos clients les plus importants : Utilisez l'Ordonnancement par Priorité. Cela garantit que les VIP sont servis en premier, même si cela fait attendre les autres plus longtemps.
Ne vous souciez pas trop d'une estimation parfaite : Même si vous utilisez une estimation approximative du temps de préparation d'une commande, la règle d'ordonnancement que vous choisissez (SJF vs Priorité) compte beaucoup plus pour le temps d'attente final. Mais si vous pouvez estimer avec précision (en utilisant le Tokenizer), le système fonctionne de manière plus fluide.

En résumé : La façon dont vous alignez les clients compte plus que la perfection de votre estimation de la taille de leur commande.

Résumé Technique : DriftSched

Énoncé du Problème
L'adoption rapide des modèles de langage de grande taille (LLM) a intensifié la demande pour une planification efficace des GPU multi-tenants dans les centres de données d'IA. Bien que les runtimes d'inférence modernes comme vLLM aient optimisé le débit grâce au batching continu et à la gestion de la mémoire, l'estimation précise du coût d'exécution des requêtes d'inférence hétérogènes reste un défi majeur. Les approches de planification existantes reposent généralement sur des limites de tokens statiques, des contraintes de sortie spécifiées par l'utilisateur ou des hypothèses de charge de travail prédéfinies. Ces méthodes statiques ne parviennent pas à capturer le comportement dynamique des charges de travail réelles des LLM, où les longueurs de sortie observées s'écartent fréquemment des valeurs attendues en raison de la complexité du prompt, des caractéristiques de la réponse et du comportement du modèle.

Le document identifie ce décalage comme étant la dérive de jetons à l'exécution (runtime token drift). Ce phénomène introduit des erreurs d'estimation qui se propagent dans les décisions de planification, entraînant une mauvaise classification des charges de travail, un déséquilibre des files d'attente, une inflation de la latence de queue et une allocation injuste des ressources entre les tenants, ainsi qu'une dégradation de la qualité de service (QoS) sous contention GPU. Les algorithmes de planification traditionnels (par exemple, FIFO, SJF), conçus pour des systèmes aux coûts d'exécution prévisibles, peinent dans les environnements multi-tenants de LLM où le comportement à l'exécution dépend de facteurs dynamiques tels que la croissance du KV-cache et la dynamique de batching.

Méthodologie et Architecture du Système
Pour relever ces défis, les auteurs proposent DriftSched, un cadre de planification adaptatif sensible à la QoS, conçu pour l'inférence de LLM multi-tenant sur des GPU NVIDIA L4. L'architecture du système intègre la classification de la charge de travail, l'estimation du budget de jetons, la gestion de file d'attente sensible aux tenants et un mécanisme de compensation de la dérive piloté par le feedback à l'exécution.

Estimation Adaptative des Jetons : Contrairement aux approches statiques, DriftSched estime le coût de l'inférence avant l'exécution GPU en combinant la classification de la charge de travail, des facteurs de sécurité liés au tenant et la complexité du prompt. Crucialement, il utilise un facteur de biais adaptatif ( $B_{runtime}$ ) qui est continuellement mis à jour via le feedback d'exécution. Le nombre de jetons de sortie estimé est calculé comme suit :
$T_{estimated\_output} = T_{base} \times B_{runtime} \times S_{tenant} \times F_{input}$
où $B_{runtime}$ est appris à partir du ratio entre les longueurs de sortie observées et les estimations de base.
Classification de la Charge de Travail et Mise en File d'Attente : Les requêtes d'inférence sont classées en catégories sémantiques (short_qa, summary, technical, report) et mappées vers des classes de planification à l'exécution (court, moyen, long) basées sur le budget de jetons estimé. Les requêtes sont assignées à des files d'attente spécifiques aux tenants (Premium, Standard, Batch) gérées via Redis.
Stratégies de Planification : Le cadre évalue cinq politiques de planification : First-Come First-Serve (FIFO), Priorité (Priority Scheduling), Pondérée (Weighted Scheduling), Shortest-Job-First (SJF) et Priorité avec Vieillissement (Aging Priority Scheduling).
Boucle de Feedback : Le système opère en deux phases : une phase de calibration (les 1 000 premières requêtes) pour collecter le feedback d'exécution et faire converger les facteurs de biais, et une phase d'évaluation de stress (les 2 000 requêtes restantes) où le planificateur utilise les valeurs de biais apprises tout en continuant l'adaptation en ligne. La règle de mise à jour adaptative utilise une moyenne mobile exponentielle (EMA) pour affiner les facteurs de biais en fonction de l'écart entre les jetons estimés et les jetons observés.

Contributions Clés

Architecture Adaptative Sensible à la Dérive : Un nouveau cadre de planification qui traite l'estimation de la charge de travail comme un problème de compensation de la dérive de jetons à l'exécution, mettant à jour dynamiquement les facteurs de biais pour aligner les prédictions sur le comportement observé.
Mécanisme de Compensation de la Dérive de Jetons à l'Exécution : Une méthode pilotée par le feedback qui réduit l'erreur d'estimation en comparant continuellement les budgets de jetons estimés aux longueurs de sortie réelles, améliorant ainsi la précision de la planification lors de l'admission.
Cadre de Benchmarking Reproductible : Une configuration d'évaluation complète utilisant vLLM sur des GPU NVIDIA L4, simulant un trafic multi-tenant hétérogène avec des complexités de prompt et des taux d'arrivée variables pour évaluer l'équité, la latence et le débit.

Résultats Expérimentaux
Les expériences ont été menées sur 3 000 requêtes d'inférence à travers trois niveaux de tenants et quatre types de charges de travail sémantiques sur un GPU NVIDIA L4.

Existence de la Dérive de Jetons : L'étude a confirmé une dérive de jetons à l'exécution mesurable à travers les catégories de charge de travail. L'estimation statique du budget de jetons a systématiquement surestimé le comportement de génération réel.
Précision de l'Estimation : Le mécanisme de feedback adaptatif a réduit l'erreur d'estimation de la charge de travail d'une moyenne de 38,8 % (MAE) et de 40,5 % (RMSE) sur toutes les politiques de planification évaluées par rapport aux bases statiques.
Performance de Latence : Parmi les politiques de planification, Shortest-Job-First (SJF) a obtenu la meilleure performance globale. Par rapport à FIFO, SJF a réduit la latence de bout en bout médiane (P50) d'environ 42 % et la latence P99 d'environ 16 %. Cette amélioration est attribuée à la priorité donnée aux charges de travail plus courtes et à la réduction de l'occupation des files d'attente.
Compromis : Bien que SJF ait optimisé la latence globale, les planificateurs sensibles aux tenants (Priority, Weighted, Aging) ont fourni une différenciation de QoS plus forte pour les tenants Premium. Par exemple, la planification par priorité a réduit la latence du tenant Premium à environ 77 secondes mais a augmenté celle du tenant Batch à environ 427 secondes.
Utilisation du GPU : L'analyse a révélé que la latence d'exécution du GPU et l'utilisation de la mémoire sont restées relativement constantes à travers toutes les politiques de planification. Cela indique que les différences de performance provenaient de la gestion des files d'attente et de l'ordonnancement des charges de travail plutôt que de changements dans l'efficacité d'exécution du GPU.

Signification et Revendications
L'article affirme que la dérive de jetons à l'exécution est un phénomène mesurable et pratiquement significatif dans les systèmes de service de LLM multi-tenants. La principale importance de DriftSched réside dans sa démonstration que l'estimation pilotée par le feedback adaptatif peut considérablement améliorer la caractérisation de la charge de travail et l'efficacité de la planification sous contention GPU.

Les auteurs soutiennent que leurs conclusions fournissent des informations pratiques pour les plateformes de service d'IA d'entreprise, soulignant qu'une estimation précise de la charge de travail à l'exécution est critique pour les futurs runtimes d'inférence adaptatifs. Le travail complète les architectures existantes (par exemple, Orca, Sarathi, vLLM) en introduisant l'estimation adaptative de la charge de travail comme un signal de planification supplémentaire. L'étude conclut que bien que la planification sensible à la charge de travail (comme SJF) réduise considérablement la latence de queue, elle implique un compromis avec l'équité entre les tenants, suggérant que les futurs systèmes devront équilibrer l'efficacité globale avec les garanties de niveau de service. Le papier note modestement que son évaluation a été menée sur une plateforme et un modèle GPU uniques, et que les travaux futurs exploreront les scénarios multi-GPU et la planification basée sur l'apprentissage par renforcement.