Mobilité verticale : De l'inférence MVP aux charges de travail à plusieurs milliers de milliards de paramètres — Sitanshu Gupta, CoreWeave

FrançaisالعربيةDeutschEnglishEspañolहिन्दी日本語한국어PortuguêsРусский中文
AAI Engineer
컴퓨터/소프트웨어AI/미래기술

스크립트

00:00:00Bonjour à tous. Je m'appelle Sitan Shu et je viens de chez Corvi. Je vais vous parler de mobilité
00:00:19verticale. C'est un sujet assez élégant, un titre qu'on a imaginé, mais en gros,
00:00:26je vais vous parler de la plateforme d'inférence que nous construisons chez Corvi pour exécuter
00:00:30des modèles de toutes tailles et divers types de charges de travail. Pour me présenter rapidement, j'ai rejoint
00:00:38Corvi il y a tout juste quatre mois pour y diriger toute l'inférence. Et avant cela,
00:00:44je gérais tout ce qui touchait à l'entraînement chez AWS Annapurna Labs, et encore avant, l'inférence
00:00:49et l'entraînement chez Sambanova. J'ai donc pas mal d'expérience dans ce domaine. Ce que
00:00:56je vais faire, c'est vous expliquer nos modèles de consommation
00:01:00et comment nous en avons déduit l'architecture de notre plateforme pour
00:01:04éviter de devoir constamment la changer, tout en continuant à l'améliorer
00:01:09pour l'inférence, et pourquoi la performance y joue un rôle si crucial.
00:01:14Je pense qu'une partie de cela rejoint le sujet abordé juste avant ici.
00:01:20Les modèles de consommation. Dans l'ensemble, nous en avons deux principaux. Le premier est le serverless,
00:01:29où les clients et utilisateurs peuvent venir sans avoir à se soucier de gérer le matériel
00:01:35eux-mêmes, ni de gérer les clusters, l'orchestration, ou quoi que ce soit d'autre.
00:01:40Il y a une API et une interface web : vous venez, payez au jeton et votre modèle est exécuté.
00:01:47Le point clé ici réside dans la variété des modèles que nous proposons au catalogue,
00:01:54c'est-à-dire l'éventail de choix offert au client. Je vais parler du dédié avant de revenir au serverless,
00:02:01car le serverless présente une particularité unique. Le service d'inférence dédiée que nous fournissons
00:02:05s'adresse plutôt aux clients qui veulent savoir exactement quel matériel ils vont utiliser,
00:02:11mais le déploiement du modèle dépend aussi d'eux. Ils utilisent notre service et nos couches d'orchestration,
00:02:18mais le déploiement du modèle reste leur responsabilité. Sa performance dépend d'eux aussi, tant que nous fournissons
00:02:25les capacités et réglages nécessaires sur la plateforme. Pour en revenir au serverless,
00:02:30l'un des aspects intéressants est que les modèles en serverless souffrent souvent du problème de « voisin bruyant »,
00:02:38où si tout le monde sollicite exactement le même modèle, vous risquez de subir pas mal de délais d'attente,
00:02:43selon la capacité allouée en arrière-plan. Une autre fonctionnalité que nous proposons en serverless
00:02:48est ce que nous appelons le débit réservé. Ainsi, en tant que client, si vous connaissez votre profil de trafic
00:02:55et que vous nous le communiquez, nous pouvons vous réserver des ressources dédiées
00:03:00en coulisses. Vous n'avez toujours pas à vous soucier du matériel exact utilisé,
00:03:04du moment que votre débit et vos SLA sont respectés.
00:03:07C'est une autre option en serverless, toujours facturée au jeton,
00:03:12mais avec la garantie d'éviter le problème de voisin bruyant.
00:03:19Examinons rapidement les différents types et profils de charges de travail
00:03:27que nous observons. La proportion entre elles évolue constamment, même si le domaine des agents
00:03:32est très en vogue. L'agentique et le chat sont assez similaires : des séquences d'entrée très longues
00:03:39et des séquences de sortie généralement très courtes. La majeure différence entre agentique et
00:03:43chat réside dans le fait que les échanges multiples en agentique exigent une très faible latence, contrairement au chat,
00:03:50où l'utilisateur doit lire la réponse avant d'y répondre. Il y a donc
00:03:56des différences à ce niveau. Et cette grande différence se traduit finalement par quelque chose
00:04:01lié à la gestion du KVCache. Mais ces deux types sont en temps réel, tout comme
00:04:09la voix et la vidéo, qui sont en flux continu et extrêmement sensibles à la latence. Pour les agents
00:04:16et le chat, les exigences portent surtout sur le débit plutôt que la latence, mais la voix et la vidéo
00:04:23en temps réel sont absolument critiques sur ce point. Concernant le traitement par lots (batch),
00:04:32les SLA sont très souples. Ils se comptent en secondes ou minutes, et parfois même en heures chez certains clients.
00:04:37Ils nous disent : « Donnez-moi une capacité de traitement sur 10 à 12 heures et j'enverrai tout ce que je peux,
00:04:44traitez-le quand vous le pourrez. » L'impact de ces charges par lots réside
00:04:52dans le fait qu'elles dictent certains choix de conception dans notre infrastructure. Imaginez
00:04:59ces quatre profils de charge différents. Sur le plan temporel, vous devez constamment
00:05:04jongler avec leurs caractéristiques afin d'optimiser au maximum l'utilisation du matériel sous-jacent.
00:05:12Voici une vue d'ensemble de la structure actuelle de notre infrastructure. Je vais vous décrire
00:05:19le flux d'une requête. Que ce soit en serverless ou en dédié, si vous regardez le côté droit
00:05:24de l'écran, vous verrez que côté plateforme, vous passez par le plan de contrôle pour gérer
00:05:31autorisations, votre limitation de débit et le suivi de votre utilisation, afin d'être facturé en conséquence.
00:05:37Et l'observabilité, pour s'assurer qu'on ne viole pas les SLA signés,
00:05:45n'est-ce pas ? Sous la plateforme, j'ai montré à très haut niveau qu'on a ces différents
00:05:52moteurs d'inférence, vLLM, SGLang, et TensorRT-LLM, mais il y a pas mal de détails ici sur lesquels je vais revenir.
00:06:00Et en dessous, ce que j'essaie de montrer en vert, ce sont différents composants matériels.
00:06:09Donc la plateforme doit être capable de partager, de répartir la charge de travail
00:06:15sur différentes générations de ces GPU, plus particulièrement les GPU NVIDIA
00:06:21qu'on utilise, n'est-ce pas ? Prenons quelques exemples. Disons que la requête provient
00:06:31du côté client via des applications ou des notebooks, peu importe, ou via les agents, d'accord ? Elle arrive à la passerelle.
00:06:36Une fois à la passerelle, comme je l'ai mentionné pour le plan de contrôle, elle passe par l'authentification,
00:06:42etc., etc., puis vient le cas du serverless ou du dédié. Pour le serverless,
00:06:48c'est de la facturation au jeton, donc l'utilisation des jetons est surveillée ici, pas les jetons exacts,
00:06:53mais simplement l'utilisation des jetons, car nous appliquons des politiques de rétention de données zéro (ZDR).
00:06:59Ensuite, selon le multi-tenant ou le provisionné, si c'est provisionné, on sait
00:07:05qu'en dessous, le routeur doit cibler les déploiements explicites pour les clients
00:07:12à débit provisionné. Pour les clients multi-tenant, il y a des déploiements distincts.
00:07:17Ici, le routeur est particulièrement important, car il a la responsabilité de
00:07:26faire un routage conscient de la cache KV. Pourquoi est-ce important ? Parce que, comme je l'ai dit
00:07:31lorsqu'on discutait des profils de charge, les cas d'usage agentiques ont généralement des longueurs de séquence d'entrée
00:07:39très lourdes, et la majeure partie de cette longueur, environ 80 à 90 %, selon l'entreprise
00:07:44et selon les clients, 80 à 90 % est identique d'une requête à l'autre.
00:07:51Ça ne sert donc à rien d'aller recalculer le pré-remplissage ou de le refaire à chaque fois.
00:07:57Le pré-remplissage exige énormément de calcul et coûte très cher, c'est pourquoi plus vous touchez la cache,
00:08:04plus vous économisez. Si vous regardez la tarification des jetons n'importe où, il y a un prix spécifique pour
00:08:11les jetons d'entrée et un prix bien plus bas pour les jetons d'entrée mis en cache. La mise en cache est donc cruciale
00:08:18ici. La façon dont vous voulez découper le matériel dépend entièrement du choix au niveau de la
00:08:26plateforme, et nous offrons la possibilité de faire les deux. Soit désagréger le pré-remplissage et le décodage si
00:08:31le cas d'usage le demande, soit ne pas le faire, car cette désagrégation n'est pas rentable pour tous les cas d'usage.
00:08:41Prenons un autre flux de requête. Voyons ce qui se passe quand il s'agit d'un client dédié.
00:08:48Un client dédié passera aussi par les passerelles configurées pour lui avec une isolation appropriée.
00:08:55La facturation ne se fait pas aux jetons, mais selon l'utilisation par GPU et par heure.
00:09:03C'est une passerelle privée, il n'y a donc pas de problème de « voisin bruyant », personne d'autre ne peut y accéder.
00:09:09On retrouve la même logique de routage ici pour maximiser les accès à la cache sur les requêtes très similaires.
00:09:18Et selon le déploiement que le client effectue sur ses GPU dédiés,
00:09:24il peut décider de désagréger ou non le pré-remplissage et le décodage. Il peut choisir quel
00:09:29moteur utiliser : vLLM, SGLang ou TensorRT-LLM. Et vu le volume de capacité réservé par
00:09:35le client, il peut décider de n'avoir qu'un seul déploiement capable de passer à l'échelle
00:09:42sur tout le cluster, ou d'avoir plusieurs modèles différents avec plusieurs déploiements.
00:09:47Une chose que je tiens à mentionner concernant le routeur ici, c'est que
00:09:54la capacité hétérogène entre différentes zones et régions
00:09:59est prise en charge. Équilibrer la charge là-dessus est un problème assez complexe.
00:10:04L'ordre de priorité qu'on applique est donc d'abord la localité de la cache KV, puis le basculement vers la moins chargée.
00:10:16Voilà pour ça. Un autre flux de requête que je veux aborder ici, qui
00:10:21est peut-être un peu dur à voir sur le schéma, c'est le traitement par lots (batch).
00:10:25Pour le flux en batch, ce qu'on fait en réalité, c'est d'utiliser la capacité sous-jacente du client :
00:10:31prenons le même client d'inférence dédiée. La journée aux États-Unis, il exécute ses charges en temps réel,
00:10:37et du soir au matin, il veut lancer des traitements par lots. La même capacité peut être planifiée
00:10:43après coup pour exécuter ces tâches en batch. Nous fournissons donc dans l'API de quoi définir quand réduire ou augmenter
00:10:51l'échelle. Selon le planning, s'ils nous indiquent qu'il faut réduire la voilure,
00:10:56on réduit la voilure pour libérer de la ressource pour le traitement par lots pendant la nuit.
00:11:05Je crois que j'ai beaucoup parlé d'optimisations côté cache KV, mais je veux insister un peu
00:11:10dessus, car c'est l'un des aspects les plus intéressants. Plus on touche la cache, plus
00:11:19vous éviterez le coût du pré-remplissage, qui est l'élément le plus coûteux ici.
00:11:26Réutiliser le cache KV sur plusieurs tours de vos tâches agentiques, car entre les tours,
00:11:31il y a aussi beaucoup de pré-remplissage similaire dans la longueur de la séquence d'entrée.
00:11:38Pensez aux conversations de type chat, où le déchargement du cache KV devient aussi très important,
00:11:43car avec les charges de travail de chat, il y a beaucoup de latence entre les différents tours
00:11:49que nous, utilisateurs, saisissons. Mais si nous effaçons totalement le contenu d'une conversation,
00:11:57la prochaine fois qu'on posera une question dans ce même chat, cela prendra un peu plus de temps.
00:12:02Ainsi, au lieu de tout effacer et de refaire le pré-remplissage à zéro, les techniques
00:12:08utilisées—nous avons les nôtres, mais à l'externe on connaît LM cache et Mooncake—
00:12:17consistent à décharger le cache KV vers un stockage à haut débit
00:12:21afin de stocker une grande partie de ces pré-remplissages. Ainsi, dès que la requête associée arrive
00:12:28pour cette conversation spécifique, elle peut être chargée immédiatement dans la HBM.
00:12:37Côté leviers de performance, je voudrais juste mentionner quelques points.
00:12:41Nous avons abordé la désagrégation PD, mais la quantification et le décodage spéculatif en sont d'autres,
00:12:48tout comme le choix minutieux des degrés et stratégies de parallélisation, ce qui est crucial.
00:12:54Deux des plus grands leviers sur lesquels nous avons travaillé sont la quantification en NVFP4 et le décodage spéculatif.
00:13:01Nous offrons la possibilité, si le client a son propre jeu de données, d'entraîner des modèles spéculatifs
00:13:07adaptés à ses données pour améliorer la longueur d'acceptation, ce qui augmente considérablement
00:13:12le débit de sortie. Nous proposons cela aussi. Mais cela se fait de manière asynchrone : nous recevons les données,
00:13:20nous entraînons les modèles spéculatifs et nous les déployons dans l'environnement du client,
00:13:26si c'est ce qu'il souhaite. Vous voyez trois captures d'écran ici, tirées
00:13:32du travail accompli par une partie de mon équipe ce dernier mois. Vous pouvez voir que nous sommes rapidement arrivés
00:13:39en tête du classement sur Kimi 2.6 et 2.7, selon les données d'Artificial Analysis.
00:13:46Pour en revenir à la session précédente : peut-on s'y fier ? C'est pourquoi, pour GLM, j'ai les résultats
00:13:52d'OpenRouter. Quand Artificial Analysis lance des benchmarks, ils testent des charges très spécifiques.
00:13:58OpenRouter, c'est du vrai trafic utilisateur, et vous pouvez voir du côté d'OpenRouter, Weights & Biases.
00:14:05Le nom de marque est différent, mais Weights & Biases, c'est fondamentalement Cirrascale. Nous l'avons racheté
00:14:09il y a environ un an. La vitesse affichée ici pour notre déploiement est très proche
00:14:16de ce que propose Fireworks avec leur offre rapide. Mais ce sont les techniques sous-jacentes
00:14:21sur lesquelles je veux insister le plus pour l'optimisation des performances. C'est essentiel, car
00:14:27au final, ce que l'on veut offrir au client, c'est le meilleur rapport prix/performance.
00:14:36En résumé, une plateforme unique : c'est ce que j'ai essayé de mettre en avant et de vous montrer.
00:14:44Deux modèles de consommation distincts, serverless et dédié. Et au sein du serverless,
00:14:49j'ai aussi décrit deux options : le paiement à l'usage et le débit réservé, selon vos besoins,
00:14:53pour au final cumuler les gains grâce aux optimisations de performance sur toute la pile.
00:15:01Voilà tout. Merci à tous.

핵심 요약

La plateforme d'inférence de CoreWeave combine les modèles serverless et dédiés tout en optimisant le rapport prix-performance grâce au routage conscient de la cache KV, la désagrégation du pré-remplissage et la quantification NVFP4.

하이라이트

  • La réutilisation de la cache KV évite la phase de pré-remplissage gourmande en calcul, permettant de proposer un tarif réduit pour les jetons d'entrée mis en cache.

  • Pour les charges de travail agentiques, 80 % à 90 % de la longueur de la séquence d'entrée reste identique d'une requête à l'autre.

  • La plateforme CoreWeave prend en charge la désagrégation du pré-remplissage et du décodage, tout comme le déchargement de la cache KV vers un stockage à haut débit comme LM cache ou Mooncake.

  • La quantification NVFP4 et l'entraînement asynchrone de modèles spéculatifs personnalisés augmentent considérablement le débit de sortie des jetons.

  • L'équilibrage de charge sur des clusters hétérogènes accorde la priorité absolue à la localité de la cache KV avant de basculer vers le GPU le moins chargé.

타임라인

Modèles de consommation serverless et dédié

  • Le modèle serverless applique un paiement au jeton sans gestion d'infrastructure par l'utilisateur.
  • Le service dédié laisse la gestion du déploiement et des performances sous la responsabilité du client.
  • L'option de débit réservé en serverless élimine les problèmes de voisins bruyants en garantissant des ressources d'arrière-plan.

Deux modes d'accès structurent la plateforme d'inférence. Le modèle serverless masque la complexité matérielle et propose un catalogue étendu de modèles pré-déployés. Pour les clients connaissant leur profil de charge exact, le débit réservé bloque de la capacité dédiée tout en conservant une facturation au jeton. À l'inverse, l'offre dédiée garantit une isolation totale sur des GPU spécifiques, laissant le choix des configurations d'orchestration à l'utilisateur.

Exigences techniques des différents profils de charge

  • Les charges agentiques et le chat partagent des entrées très longues et des sorties courtes, mais l'agentique exige une latence plus faible.
  • La voix et la vidéo en temps réel imposent des contraintes de latence strictes sur des flux continus.
  • Les traitements par lots tolèrent des délais de plusieurs heures pour maximiser le taux d'utilisation du matériel.

L'infrastructure adapte son exécution selon la nature des requêtes. L'agentique impose une gestion très fine de la cache KV en raison d'échanges multiples à faible latence. Les flux vocaux ou vidéo nécessitent une diffusion sans interruption. À l'opposé, le traitement en batch fonctionne selon des SLA souples s'étalant sur des plages de 10 à 12 heures, permettant de combler les creux d'activité de l'infrastructure.

Architecture de la plateforme et routage de requêtes

  • Le plan de contrôle applique des politiques de rétention de données zéro tout en mesurant l'usage des jetons.
  • Le routeur priorise la localité de la cache KV avant de réorienter vers le nœud le moins chargé.
  • Les GPU sous-jacents exécutent des moteurs d'inférence variés comme vLLM, SGLang et TensorRT-LLM.

Les requêtes passent par une passerelle gérant l'authentification et les quotas sans conserver les données textuelles. Le routeur identifie les pré-remplissages déjà effectués pour réutiliser la mémoire GPU existante, évitant des calculs d'entrée très coûteux. En mode dédié, la facturation bascule sur un tarif horodaté par GPU. Les tâches de nuit en batch réutilisent directement la capacité inutilisée des déploiements dédiés.

Optimisations de performance et résultats de vitesse

  • Le déchargement de la cache KV vers un stockage externe permet de réinjecter rapidement le contexte en mémoire HBM lors des reprises de session.
  • L'entraînement asynchrone de modèles spéculatifs améliore la longueur d'acceptation et le débit final.
  • La quantification NVFP4 et les optimisations logicielles placent l'infrastructure parmi les plus rapides sur les benchmarks publics et le trafic réel.

Le coût d'inférence dépend majoritairement de la phase de pré-remplissage. Pour éviter de recalculer ce contexte lors de requêtes espacées, le cache KV est déchargé vers une couche de stockage à haut débit. En parallèle, des techniques de parallélisation, la quantification en NVFP4 et l'usage de modèles spéculatifs entraînés sur les jeux de données clients maximisent le nombre de jetons générés par seconde. Ces ajustements atteignent des vitesses de traitement comparables aux architectures spécialisées les plus rapides du marché.

커뮤니티 글

아직 글이 없습니다. 이 영상에 대한 첫 번째 글을 작성해 보세요!

이 영상에 대해 글쓰기