ELDR : Microsoft et KAIST accélèrent le décodage des MoE

Servir un Mixture-of-Experts en production reste tortueux même quand la charge semble équilibrée: deux workers ayant reçu le même nombre de tokens peuvent afficher des latences très différentes, parce qu'à chaque pas de décodage il faut charger en HBM les poids de chaque expert distinct activé par le batch. Sur Qwen3-30B-A3B, faire passer le nombre d'experts actifs de 16 à 128 à taille de batch constante multiplie par 4,7 la latence de la couche MoE.

C'est le point de départ d'ELDR, un article de chercheurs du KAIST et de Microsoft Research publié sur Hugging Face Papers. L'idée est d'exploiter une régularité empirique: sur les trois modèles testés (Qwen3-30B-A3B, GPT-OSS-120B, Gemma-4-26B-A4B), les experts activés au prefill et au décodage corrèlent entre 0,70 et 0,92. Les auteurs construisent donc, à partir des activations de prefill, une signature par requête, partitionnent hors ligne l'espace des signatures avec un K-means équilibré, puis routent en ligne chaque requête vers le worker de décodage dont le centroïde est le plus proche, en autorisant une bande de tolérance pour équilibrer avec la charge courante.

Les gains rapportés sont modestes mais nets. La réduction médiane du TPOT va de 5,9 à 13,9% selon le couple modèle-workload, avec en moyenne 22,0% d'experts distincts en moins par pas de décodage sur Qwen3-30B-A3B en workload task. Le surcoût runtime est annoncé à 0,86 ms par requête (soit 1,2% du TTFT médian de 69 ms), le cache de signatures pesant 0,24% de la HBM. Les sorties du modèle, elles, restent strictement identiques au top-k standard, puisqu'ELDR ne change que le worker qui sert la requête.

L'honnête caveat, c'est que les mesures viennent d'un banc unique: un cluster à 5 nœuds équipé de GPU AMD MI300X et de vLLM 0.21.0rc1 sur ROCm 7.2, en topologie 8P16D. Ce que le papier ne donne pas, c'est un retour sur du trafic multi-tenant réel, ni sur le coût opérationnel de recalibrer quand le mix de domaines dérive, alors que la capture prend 4 à 15 minutes par couple (modèle, dataset).

Reste que la piste est concrète pour quiconque tente de rentabiliser des MoE de plusieurs centaines de milliards de paramètres: les opérateurs qui déploient déjà en prefill/decode disaggregated peuvent tester une couche de routage par signature sans toucher au modèle et sans trade-off qualitatif. C'est le genre d'optimisation sous le capot qu'on aimerait voir remonter jusqu'aux runtimes d'inférence open source.