Alibaba vient-il de « faire une DeepSeek » ?

Le groupe chinois est en tout cas parvenu, comme son compatriote en début d’année, à attirer l’attention avec un article scientifique qui touche à la frugalité de l’IA.

La planification de l’autoscaling descendue au niveau des tokens

DeepSeek avait causé un électrochoc en présentant des LLM entraînés avec nettement moins de ressources de calcul que les modèles référents du marché.

Du côté d’Alibaba, la logique est la même, mais sur la phase d’inférence. Elle implique un système de pooling GPU nommé Aegaeon.

En la matière, deux grandes approches sont traditionnellement mises en œuvre : le multiplexage et l’autoscaling.

Le multiplexage place plusieurs instances de modèles sur chaque GPU, avec un partage spatial ou temporel (technologie NVIDIA MPS). Le mécanisme est limité par la quantité de VRAM disponible.

La méthode autoscaling est plus « agressive ». Elle adapte le placement du modèle au fil du temps, en le chargeant depuis la mémoire de l’hôte ou depuis un support externe.

L’efficacité de l’autoscaling est limitée par le ratio de modèles actifs au sein des workloads. Or, la durée d’exécution des requêtes LLM fait qu’à tout moment, un grand nombre de modèles sont actifs, même si les invocations sont sporadiques. Lorsque toutes les instances GPU sont occupées par des modèles actifs, les nouvelles requêtes doivent attendre (on ne peut pas associer en un même lot des opérations de préremplissage et de décodage liées à des modèles différents). Dans ce contexte, réserver moins d’instances qu’il n’y a de modèles accroît le risque de compromettre le respect des SLO.

Pour dépasser cette limite, Alibaba a mis en place un mécanisme planification non au niveau des requêtes, mais des tokens. L’approche avait déjà été expérimentée en configuration monomodèle. En multi, elle est d’autant plus critique que le nombre de batchs augmente (puisqu’on ne peut, donc, pas batcher les requêtes de modèles différents).

Des partitions distinctes pour préremplissage et décodage

Aegaeon planifie en parallèle l’exécution d’une requête et l’autoscaling. Étant donné un ensemble d’instances GPU et des SLO cibles (TTFT, latence du premier token ; TBT, latence entre tokens), il choisit la tâche suivante (prefill ou décodage) pour chaque instance. Et opère éventuellement un autoscaling préemptif si une tâche planifiée utilise un autre modèle que celui actif.

Alibaba a opté pour une désagrégation des phases de préremplissage et de décodage. Il a ainsi divisé le pool GPU en deux partitions. La partie décodage utilise une planification en round-robin pondéré, censée maximiser le respect du TBT. Le prefill exploite un système de planification groupée : on réunit les requêtes qui visent un même modèle, tout en maintenant une approche « premier arrivée, premier servi » pour éviter tout privation de ressources. Les tâches sont ajoutées à un groupe existant si c’est possible. Sinon, Aegaeon en crée un et l’attache à la file d’attente la moins peuplée (chaque instance a sa file). La taille de batch est plafonnée à 1, vu la relative linéarité entre le nombre de tokens et le temps d’exécution – et du fait que de plus petits batchs réduisent les délais d’attente.

Réutiliser pour ne pas (tout) réinitialiser

Les solutions d’autoscaling préemptif tendent à se focaliser sur l’accélération du chargement du modèle. Alibaba Cloud s’est intéressé aux autres étapes de la procédure : réinitialisation du moteur, gestion de la mémoire et transferts du cache clé-valeur.

La réinitialisation du moteur est une séquence qui, à défaut d’optimisation, peut prendre des dizaines de secondes. Elle comprend notamment l’initialisation du cache clé-valeur, le chargement des poids, le profilage et l’optimisation (allocation d’espace pour le cache clé-valeur) et le démarrage d’orchestrateurs comme Ray destinés à distribuer l’exécution.

Alibaba s’est figuré que l’initialisation de ces différents composants pouvait être réutilisée de manière sûre entre modèles. Ainsi, Aegaeon n’initialise le moteur qu’une fois par instance, mettant tous les éléments en cache sauf poids et cache clé-valeur. Pour ce dernier, il exploite un pool préattribué dans la mémoire de l’hôte, évitant de devoir épingler des pages pendant l’autoscaling. L’ensemble réduit la latence de plus de 80 %.

Les événements CUDA mis à profit

La gestion mémoire est quant à elle rendue explicite. À l’appui, entre autres, d’un tampon VRAM autogéré et d’un cache clé-valeur « unifié » (chaque zone, en VRAM ou DRAM, est divisée en fragments de taille fixe qui accueillent différents blocs en fonction de la forme du cache).

Pour ce qui est des transferts du cache clé-valeur entre hôte et GPU, l’enjeu est de permettre leur chevauchement tout en minimisant les conditions de concurrence des données. Les événements CUDA ont été mis à contribution dans ce but, pour suivre individuellement les transferts.

De 1192 à 213 GPU pour le Model Studio d’Alibaba Cloud

Pour évaluer Aegaeon, Alibaba a choisi une config à deux nœuds de 8 GPU H80-80, avec 2 To de DRAM (DDR5) et 192 CPU Xeon Platinum 8469C. Il y a fait tourner des LLM de plusieurs familles (Qwen, Llama, InternLM, Yi, etc., essentiellement de 6 à 14 milliards de paramètres) sur le dataset ShareGPT et deux déclinaisons « augmentées » (inputs et outputs allongés). La comparaison a été faite avec MuxServer et ServerlessLLM, deux solutions qui adoptent respectivement le multiplexage et l’autoscaling.

Illustrant les limites du multiplexage, MuxServer a systématiquement refusé de placer plus de 2 modèles par GPU, en raison du manque de VRAM.

À un débit de 0,1 requête/seconde, Aegaeon soutient un débit utile doublé par rapport à ServerlessLLM. Il gère jusqu’à 70 modèles avec 10 instances de décodage. ServerlessLLM souffre de longs temps d’attente. ServerlessLLM+ (implémentation ad hoc ajoutant une planification Shortest Job First à partir d’un oracle fondé sur les longueurs d’output) atténue l’effet, mais la performance se dégrade inévitablement avec davantage de modèles actifs.

À 0,5 requête/s, l’écart de débit utile est de 2,5 par rapport à ServerlessLLM.

Cet écart se maintient sur les datasets « augmentés ». Et, quoique dans une moindre mesure, avec des SLO plus stricts laissant moins de marge de pooling. Cela se vérifie aussi sur des configs plus restreintes en hardware (par exemple, un nœud de 4 GPU A10). Pour Alibaba, c’est la preuve qu’Aegaeon est potentiellement applicable à un grand éventail de workloads.

Le système alimente, depuis quelques mois, le Model Studio d’Alibaba Cloud. Il fonctionne sur un cluster multirégion de 213 GPU H20 servant 47 modèles de 1,8 à 72 milliards de paramètres. Ces modèles étaient, à l’origine, servis par 1192 GPU H20. Le parc s’est donc réduit de 82 %.

Illustration principale générée par IA

The post « 82 % de GPU en moins » : Alibaba fait du DeepSeek, mais pour l’inférence appeared first on Silicon.fr.