Exploitation à grande échelle de systèmes d'inférence distribués — Nishant Gupta & Naman Ahuja, Meta
AAI Engineer
컴퓨터/소프트웨어AI/미래기술
스크립트
00:00:00Bonjour à tous. Bienvenue à cette première conférence Influence de la dernière journée de l'AI Engineering
00:00:17World Fair. Je m'appelle Nishan Gupta et je suis accompagné aujourd'hui de mon co-intervenant Naman Ahuja.
00:00:23Nous travaillons sur l'efficacité, l'entraînement et l'infrastructure d'inférence chez Meta.
00:00:27Aujourd'hui, nous allons parler de la gestion des systèmes d'inférence distribués à grande échelle.
00:00:32Comme nous le savons tous, l'inférence n'est plus un simple artefact de recherche intégré dans un produit.
00:00:37C'est une charge de travail d'infrastructure hyperscale fondamentale qui croît à un rythme phénoménal.
00:00:43Le trafic d'inférence dépasse déjà les plus grands microservices au monde
00:00:47et son taux de croissance est le plus rapide jamais observé.
00:00:54Faisons un retour en arrière vers 2008 et comparons l'ère de l'IA avec celle du cloud.
00:01:00Vers 2008, le cloud a débuté sous forme d'offres de machines virtuelles.
00:01:05L'innovation majeure résidait alors dans la virtualisation.
00:01:07Puis, avec le temps, la valeur s'est déplacée vers le haut de la pile, vers les planificateurs comme Borg, Kubernetes ou Mesos.
00:01:14Puis vers les maillages de services, l'autoscaling et les diverses plateformes construites par-dessus.
00:01:18C'est la couche d'orchestration qui a véritablement capturé la valeur et la complexité.
00:01:24L'IA suit exactement la même trajectoire, mais condensée sur ces dernières années au lieu d'une décennie.
00:01:30Nous avons commencé avec des modèles simples tournant sur des GPU.
00:01:33Puis nous avons vu évoluer des frameworks de déploiement comme vLLM, TorchServe, Triton, et aujourd'hui nous voyons émerger la couche d'orchestration en temps réel, répondant aux défis complexes du routage, de la gestion du cache KV, de la désagrégation prefill/decode et du multiplexage multi-modèle.
00:01:51Dans cette nouvelle phase de l'ère de l'IA, il ne s'agit plus seulement des meilleurs modèles, kernels ou optimisations.
00:01:57C'est une question de tout l'écosystème.
00:01:58Il s'agit du plan de contrôle et de l'orchestration, et c'est ce sur quoi nous allons nous concentrer dans cette présentation.
00:02:06Parlons maintenant un peu de l'explosion de la demande liée aux agents.
00:02:09Dans le web classique, avant l'arrivée des charges d'inférence IA, la capacité évoluait de façon à peu près linéaire avec le nombre d'utilisateurs, selon le type de service.
00:02:17Deux fois plus d'utilisateurs signifiait deux fois plus de QPS et deux fois plus d'infrastructures sans optimisation, et la planification de capacité se résumait à un tableau Excel.
00:02:28Avec les agents, la capacité évolue selon le nombre d'utilisateurs fois le nombre d'appels par utilisateur, fois le nombre de tokens, ce qui varie selon le modèle, les optimisations et le matériel.
00:02:40Un chatbot peut faire un appel modèle par échange, ce qui évolue vers 10 à 20 pour les copilotes, 50 pour les agents de recherche, et jusqu'à des milliers d'appels pour les processus autonomes sans intervention humaine.
00:02:54L'idée clé est qu'on ne peut pas planifier la capacité pour des agents comme on le faisait pour des microservices.
00:03:00Nous devons penser à l'élasticité et mettre en place une planification et un contrôle d'admission adaptés au type de charge.
00:03:08Analysons maintenant plus en détail les différences, avantages et inconvénients entre le déploiement de microservices traditionnels et l'inférence moderne.
00:03:19Le profil de la requête.
00:03:20Les microservices supposent des requêtes courtes et uniformes, alors que les requêtes LLM varient de 50 à 100 000 tokens, avec des profils de calcul très différents entre les phases de prefill et de decode.
00:03:33Pour le regroupement (batching), les architectures classiques le faisaient au niveau du répartiteur de charge, s'il y en avait.
00:03:40En revanche, l'inférence LLM exige un batching continu en cours d'exécution, sous peine de voir le débit s'effondrer d'un ordre de grandeur ou plus.
00:03:48L'état.
00:03:49La plupart des microservices traditionnels étaient sans état, hors couche de stockage.
00:03:54Cependant, l'inférence LLM nécessite un état massif par requête, le cache KV, extrêmement coûteux à construire et encore plus à jeter.
00:04:02Unités de mise à l'échelle.
00:04:03Unités de dimensionnement.
00:04:05Pour les microservices traditionnels, on pouvait utiliser des CPU économiques dans des pods.
00:04:11Mais l'inférence moderne nécessite des GPU, 100 fois plus chers et 10 fois plus longs à obtenir, qu'on ne peut pas surprovisionner à la légère.
00:04:20Sinon, cela entraînerait un gaspillage énorme.
00:04:23Modes de défaillance.
00:04:25Dans les microservices classiques, si un hôte ou un pod plantait, on pouvait simplement le redémarrer.
00:04:34On pouvait reconstruire l'état si nécessaire.
00:04:36Mais pour l'inférence de modèles, passer d'un démarrage à froid à un état opérationnel prend beaucoup de temps.
00:04:42Et si un GPU tombe en plein décodage, cela peut perdre des milliers de tokens en cours de traitement et provoquer un engorgement des files d'attente.
00:04:50Ce qu'il faut retenir, c'est que le goulot d'étranglement n'est pas le modèle seul.
00:04:53C'est l'orchestration elle-même.
00:04:58Comme on le voit avec ces étapes invisibles derrière un prompt, une application basée sur des agents nécessite de nombreuses opérations en coulisses.
00:05:06Il faut s'authentifier.
00:05:07Il faut choisir un modèle selon le type de requête.
00:05:09Il faut sélectionner la région de destination.
00:05:11Il faut effectuer le contrôle d'admission.
00:05:12Il faut vérifier la présence en cache.
00:05:14Il faut exécuter le traitement sur le GPU.
00:05:17Il faut gérer le batching.
00:05:18Et bien d'autres étapes sont impliquées.
00:05:19Et parmi toutes ces étapes, une seule nécessite réellement le modèle : le prefill decode,
00:05:25que l'inférence soit désagrégée ou non.
00:05:29Toutes les autres étapes reposent sur l'infrastructure.
00:05:31L'intelligence réside peut-être dans le modèle, mais la rentabilité, la fiabilité et l'expérience utilisateur dépendent de l'infrastructure.
00:05:38C'est pourquoi les équipes plateforme dans de nombreuses entreprises ont aujourd'hui un impact bien plus déterminant qu'avant sur la qualité et le succès du produit.
00:05:50La plupart d'entre nous ici avons une expertise poussée sur une, deux ou trois couches.
00:05:54Nous gérons peut-être les kernels ou leur optimisation.
00:05:57Ou bien le routage ou le produit lui-même.
00:05:59Ou encore l'infrastructure GPU et le cluster.
00:06:03Mais très peu d'entre nous ont géré l'ensemble de la pile ou l'ont pensée de bout en bout.
00:06:08Comme vous le voyez, ces différentes couches ne sont pas nouvelles.
00:06:11Elles existent depuis au moins 20 ans.
00:06:13Ce qui est nouveau, c'est la façon dont elles se combinent et s'interconnectent.
00:06:18Une décision au niveau du routage peut modifier le taux de succès du cache au niveau du modèle, ce qui modifie la composition du batch, modifie l'utilisation du GPU, et influe enfin sur les décisions d'autoscaling.
00:06:32Tout est donc lié.
00:06:33Lorsqu'une baisse de performance survient sur nos charges d'inférence, il ne suffit pas de regarder ce qui s'est passé au niveau du cache ou de l'admission.
00:06:41Il faut analyser la pile de haut en bas.
00:06:43Et en cas de goulot d'étranglement, il est essentiel d'identifier à quelle couche il se situe pour investir efficacement.
00:06:54Pour comprendre le parcours d'un prompt, qu'il s'agisse de générer une image, d'effectuer une recherche ou d'orchestrer plusieurs agents complexes, le processus passe globalement par ces étapes.
00:07:08Le prompt arrive sur la passerelle (gateway).
00:07:10Puis il va vers le routeur, qui vérifie le cache si la requête a déjà été traitée.
00:07:17Il passe ensuite aux planificateurs, qui décident sur quel cluster GPU et quel matériel l'exécuter.
00:07:22Que ce soit sur NVIDIA, AMD ou vos puces internes, la requête est transmise au runtime approprié, comme vLLM ou SGLang.
00:07:30Puis nous envoyons la réponse en streaming à l'utilisateur, en respectant les SLO de délai du premier token et d'intervalle entre les tokens, tout en maintenant le débit souhaité.
00:07:41Ainsi, cette inférence fonctionne comme une transaction distribuée.
00:07:45Chaque flèche de ce schéma représente un saut réseau.
00:07:47Chacun de ces sauts peut faire l'objet de réessais.
00:07:50Il peut expirer.
00:07:51Il peut basculer sur une solution de repli.
00:07:53Il peut même échouer.
00:07:54Chacun de ces sauts est associé à des SLO et renvoie des données en flux continu à l'utilisateur.
00:08:00En cas de panne, la gestion des pannes partielles est bien plus complexe que pour un simple appel RPC.
00:08:06Imaginez qu'après avoir transmis 200 tokens à l'utilisateur, l'hôte GPU soit interrompu en raison d'une opération de maintenance
00:08:15planifiée ou non.
00:08:16On ne peut pas simplement réessayer.
00:08:17Il faut aborder le problème de manière globale.
00:08:19C'est pourquoi la fiabilité ne peut pas être gérée en périphérie (edge).
00:08:23Elle doit être intégrée au plan de contrôle, car c'est lui qui a la vision globale de l'ensemble du flux.
00:08:31Parlons maintenant des planificateurs et des optimisations possibles.
00:08:37Pour les microservices traditionnels, l'optimisation du placement se basait sur trois ou quatre dimensions.
00:08:43Comme la mémoire CPU, ou quatre domaines selon que vous utilisez AWS ou votre propre cloud interne.
00:08:52Mais pour l'inférence, le planificateur doit prendre en compte au moins sept axes pour placer une requête.
00:08:59Il doit connaître le type de GPU.
00:09:00Un cluster peut héberger divers matériels (H100, E100, B200) avec des topologies réseau différentes.
00:09:09Il doit évaluer la mémoire HBM disponible et l'état du cache KV.
00:09:13Il faut savoir si les poids du modèle sont déjà chargés, ou s'il faut effectuer un démarrage à froid.
00:09:19Il doit prendre en compte la priorité du client.
00:09:21Plusieurs clients peuvent partager ce cluster avec des profils d'exigence (SLO) différents.
00:09:27Il faut aussi prendre en compte le contexte du flux de travail.
00:09:30Sommes-nous à la troisième étape d'un raisonnement ayant déjà coûté X dollars, ou au début, permettant d'interrompre le flux en cas de surprovisionnement ?
00:09:39Il faut également penser au budget de latence selon le type d'application d'agent développée.
00:09:44Cela nous amène à la nécessité de mettre en place une planification adaptée aux agents.
00:09:49Nous devons placer les tâches là où elles s'exécuteront le plus vite et au meilleur coût, au lieu d'utiliser un GPU au hasard.
00:09:58Concrètement, le planificateur doit savoir que la requête R est à l'étape 3 d'un flux qui en compte 5,
00:10:05et que les étapes 1 et 2 ont déjà consommé un certain budget.
00:10:09Si l'étape 3 échoue, tout le flux sera interrompu, entraînant le gaspillage de toutes ces ressources de calcul.
00:10:14C'est pourquoi une orchestration consciente du flux de travail est primordiale,
00:10:18car elle modifie les décisions d'admission, la priorité et la gestion des réessais.
00:10:25Abordons maintenant la question des optimisations.
00:10:27Je ne vais pas m'étendre sur chacune d'entre elles.
00:10:29De nombreuses recherches existent déjà, mais je souhaite partager un cadre de réflexion
00:10:34que j'aime utiliser et qui s'articule autour de quatre axes.
00:10:40Premièrement : peut-on éviter le travail ?
00:10:42C'est-à-dire l'ignorer grâce au cache (prefix caching, response caching, semantic caching) ?
00:10:48Deuxièmement : peut-on mutualiser le travail ?
00:10:51Plusieurs requêtes peuvent-elles partager du calcul via le batching ?
00:10:54Comme le continuous batching, prefill decode, chunk prefill, ou le speculative decoding.
00:10:59Troisièmement : peut-on déporter le travail ?
00:11:01Peut-on la déléguer à un modèle moins cher ou plus proche de l'utilisateur ?
00:11:05Principalement via le routage, peut-on la rediriger vers un modèle plus petit, une région moins chère ou autre ?
00:11:12Et enfin, peut-on différer la charge ?
00:11:13Peut-on attendre un meilleur moment grâce au contrôle d'admission et aux files d'attente, ce qui exige de comprendre les priorités et de planifier selon les échéances ?
00:11:25Ce cadre est très puissant car il s'adapte à diverses architectures.
00:11:29Que vous utilisiez vLLM, SGLang ou TensorRT, chaque technique entre dans l'un de ces quadrants.
00:11:35Ainsi, dès qu'on envisage d'optimiser un modèle, il faut comparer ces approches avec les précédentes
00:11:41et observer comment elles se combinent.
00:11:47Quand on pense au passage à l'échelle, les performances du modèle ne font pas tout.
00:11:51Il faut aussi prendre en compte les coûts et l'aspect économique.
00:11:54C'est pourquoi il est essentiel de savoir quel indicateur on cherche à optimiser.
00:11:58Car le coût dépasse largement le simple prix du GPU ou du modèle.
00:12:02Il intègre les paramètres, reessais, stockage, pannes, réseau et bien sûr le coût opérationnel de développement.
00:12:09L'important est de définir l'indicateur clé de performance qui apportera de la valeur aux utilisateurs.
00:12:17Optimiser seulement le coût par jeton ou par requête ne suffit pas.
00:12:22Il faut optimiser le coût par tâche réussie, car c'est ce qui importe réellement aux utilisateurs.
00:12:26En optimisant ce point, le coût global du produit diminue et les utilisateurs sont bien plus satisfaits.
00:12:36Abordons maintenant la fiabilité, et ce qu'implique la prévention des pannes en cascade.
00:12:43Le vrai problème n'est jamais la simple préemption ou panne d'un GPU.
00:12:46Le plus critique, c'est la boucle de rétroaction qui s'ensuit.
00:12:49Un GPU faiblit, la latence augmente, le client réessaie, la file se remplit, les GPU sains saturent, provoquant d'autres reessais et des pannes régionales.
00:13:02C'est la panne en cascade classique, mais avec une spécificité pour l'IA générative : le cache KV.
00:13:09On ne peut pas simplement redémarrer ou réacheminer vers un autre cluster.
00:13:13Un pool froid doit chauffer avant d'absorber du trafic, pendant que le pool chaud encaisse tout.
00:13:20C'est pourquoi il faut concevoir soigneusement les coupe-circuits.
00:13:24Les disjoncteurs au routage, le contrôle d'admission, et le délestage lié à la taille de la file, pas seulement à l'usage CPU ou mémoire.
00:13:34Il faut aussi définir des quotas de reessais, sinon les coûts risquent d'exploser très rapidement.
00:13:43Je passe maintenant la parole à mon co-intervenant Naman pour la suite.
00:13:50Merci.
00:14:20Je passe la parole à mon co-intervenant Naman.
00:14:22Je passe la parole à mon co-intervenant Naman.
00:14:25Je passe la parole à mon co-intervenant Naman.
00:14:26Je passe la parole à mon co-intervenant Naman.
00:14:27Je passe la parole à mon co-intervenant Naman.
00:14:28Je passe la parole à mon co-intervenant Naman.
00:14:29Je passe la parole à mon co-intervenant Naman.
00:14:30Je passe la parole à mon co-intervenant Naman.
00:14:31Je passe la parole à mon co-intervenant Naman.
00:14:32Je passe la parole à mon co-intervenant Naman.
00:14:33Je passe la parole à mon co-intervenant Naman.
00:14:34Je passe la parole à mon co-intervenant Naman.
00:14:35Je passe la parole à mon co-intervenant Naman.
00:14:36Je passe la parole à mon co-intervenant Naman.
00:14:54C'est bon, ça fonctionne.
00:14:57Désolé pour ça.
00:14:58Quand l'inférence passe à l'échelle de la production,
00:15:00elle ressemble de plus en plus à un système distribué.
00:15:03On ne fait plus seulement appel à un modèle.
00:15:06C'est un problème classique de système distribué.
00:15:09En système distribué, on parle de files d'attente, de planification,
00:15:13d'auto-scaling, d'isolation des pannes.
00:15:14Ce sont quelques-unes des dimensions.
00:15:16L'inférence rencontre tous ces enjeux,
00:15:18mais avec de nouvelles contraintes.
00:15:20Au lieu du duo CPU/mémoire, on a le CPU, le HBM, le cache KV,
00:15:25et le coût par tâche réussie.
00:15:27La question fondamentale devient :
00:15:28comment la plateforme sait-elle quoi faire ensuite ?
00:15:31C'est là que l'observabilité entre en jeu.
00:15:34Il ne s'agit pas juste de tableaux de bord,
00:15:35mais de fournir un signal d'entrée à la boucle de contrôle.
00:15:39La télémétrie alimente l'analyse, l'analyse oriente les décisions,
00:15:43qui ajustent la planification et le routage,
00:15:45et il n'y a plus qu'à recommencer.
00:15:47Voici un aperçu de quelques métriques essentielles.
00:15:50D'abord, le temps jusqu'au premier jeton,
00:15:52qui indique combien de temps il faut vraiment
00:15:56pour obtenir la première réponse.
00:15:58Ensuite, le taux d'utilisation,
00:16:00qui montre si le goulot d'étranglement est la mémoire ou le calcul.
00:16:04Le taux de succès par dollar indique
00:16:06si la plateforme fournit les résultats attendus
00:16:08et fonctionne efficacement.
00:16:10Et enfin, la latence de bout en bout,
00:16:12qui mesure le temps écoulé
00:16:15sur l'ensemble du parcours de la requête.
00:16:19Il existe un arbitrage clé entre latence, coût et débit.
00:16:22Impossible d'avoir les trois à la fois.
00:16:24C'est très similaire au théorème CAP.
00:16:26Si j'augmente la taille des lots,
00:16:28j'améliore le débit et l'efficacité financière,
00:16:31mais au détriment de la latence maximale.
00:16:33Si j'utilise le décodage spéculatif,
00:16:35je peux réduire la latence, mais cela consomme du calcul extra.
00:16:38Au final, cela augmente le coût par jeton.
00:16:41Enfin, si j'utilise un modèle plus simple et plus petit,
00:16:44je peux réduire la latence et les coûts,
00:16:45mais la qualité de la réponse sera inférieure.
00:16:48Il faudra analyser les échecs et réessayer,
00:16:50ce qui fera remonter les coûts.
00:16:52Chaque décision d'exécution déplace
00:16:54le système quelque part dans ce triangle.
00:16:56Notre rôle est d'en trouver le juste équilibre.
00:16:58C'est devenu un pur problème d'optimisation.
00:17:03Voici la direction que prend l'industrie actuellement.
00:17:05L'inférence nécessite son propre plan de contrôle.
00:17:07Tout ce dont nous avons parlé (routage, traitement par lots, mise en cache,
00:17:10planification, fiabilité)
00:17:12ne peut plus être géré de manière isolée.
00:17:15Tout converge vers une couche logique unique,
00:17:17un plan de contrôle de l'inférence.
00:17:19Auparavant, on gérait des machines virtuelles en système distribué.
00:17:21Puis sont arrivés les planificateurs d'auto-scaling,
00:17:23et Kubernetes a unifié le tout sous un plan de contrôle.
00:17:27L'inférence traverse aujourd'hui la même transition.
00:17:30Les modèles deviennent de simples ressources.
00:17:32GPU, cache KV, jetons, latence et coûts sont désormais arbitrés.
00:17:36Le plan de contrôle détermine quel modèle traite quelle requête
00:17:40et comment les regrouper par lots.
00:17:42Que l'on développe cette couche en interne,
00:17:44via l'open source ou auprès d'un fournisseur,
00:17:46l'idée essentielle est de concevoir le système en sachant qu'elle existera.
00:17:50Voyons à présent quelques leçons d'exploitation
00:17:53tirées de notre expérience en infrastructure IA
00:17:55et la manière dont elles s'appliquent ici.
00:17:57La première leçon, c'est que les goulets d'étranglement de l'infra
00:18:00surviennent généralement avant ceux du modèle.
00:18:02En production, de nombreuses pannes peuvent survenir,
00:18:04mais elles découlent souvent du routage, de la planification
00:18:07ou d'un manque de capacité.
00:18:08Elles ne sont donc pas liées à l'inférence en soi,
00:18:10mais à des problèmes d'infrastructure pure.
00:18:12Vient ensuite l'élasticité.
00:18:14Le système doit faire preuve d'élasticité.
00:18:15Ajouter plus de GPU ne résoudra pas réellement le problème,
00:18:18cela ne fera que le masquer.
00:18:20Ensuite, nos décisions de planification
00:18:24surpassent l'efficacité brute.
00:18:26Un même parc de machines aura un rendement optimal
00:18:28selon la manière dont vous planifiez
00:18:30ou regroupez vos requêtes.
00:18:31Enfin, les boucles de contrôle surpassent les processus manuels.
00:18:35La plateforme doit mesurer, détecter,
00:18:37et adapter automatiquement le système.
00:18:39L'enseignement majeur : n'optimisez pas pour les jetons.
00:18:43Optimisez pour les tâches réussies.
00:18:48C'est l'évolution globale sur laquelle je souhaite conclure.
00:18:51La première phase de l'infra IA visait à créer de meilleurs modèles.
00:18:54Nous avons investi énormément de temps pour perfectionner nos modèles,
00:18:56les rendre plus intelligents,
00:18:58et établir de meilleurs benchmarks.
00:19:00La phase actuelle vise une inférence plus rapide,
00:19:03une latence réduite, un meilleur traitement par lots,
00:19:05et une meilleure utilisation des GPU.
00:19:08Mais la prochaine étape repose sur l'orchestration.
00:19:10Ce qui signifie que GPU, mémoire, cache et tout le reste
00:19:13ne sont plus que des ressources,
00:19:14qui doivent être planifiées et contrôlées.
00:19:17Les équipes qui l'auront compris tôt
00:19:19bâtiront l'infrastructure de demain.
00:19:21Pour conclure,
00:19:23l'infrastructure n'est plus un problème de service,
00:19:25c'est un problème d'orchestration.
00:19:27Merci.
00:19:29Merci.
커뮤니티 글
아직 글이 없습니다. 이 영상에 대한 첫 번째 글을 작성해 보세요!
이 영상에 대해 글쓰기