Nouveautés en ingénierie de l'inférence — Philip Kiely, Baseten
AAI Engineer
Computing/SoftwareInternet Technology
Transcript
00:00:00Je suis là pour parler des nouveautés en ingénierie de l'inférence. Bonjour, je m'appelle Philip et
00:00:19j'ai écrit un livre. C'est ma troisième année à l'AI Engineer World's Fair. C'est ma
00:00:24conférence préférée au monde. C'est le moment fort de l'année pour moi. J'ai vraiment
00:00:29débuté comme conférencier et ingénieur ici en 2024. Je suis revenu en 2025 et j'ai fait plein de choses.
00:00:36Je suis encore là, j'adore cet endroit et je remercie les organisateurs de toujours me recevoir. J'ai écrit ce
00:00:44livre sur l'ingénierie de l'inférence. On l'a publié il y a trois ou quatre mois, et j'ai été
00:00:49submergé par les retours. On en a fait... Je l'ai publié le 23 février. À ce jour,
00:00:57on a vendu plus de 11 000 exemplaires papier, on approche les 30 000 numériques, et 24 millions
00:01:04de personnes dans le monde, ou 24 millions de comptes Twitter — on verra combien cela représente
00:01:09de personnes réelles —, ont vu passer du contenu sur l'ingénierie de l'inférence. Et avec ce super accueil,
00:01:17il y a une question qu'on m'a beaucoup posée : pourquoi diable faire ça ? Pourquoi
00:01:23écrire un livre sur un sujet qui évolue si vite ? Eh bien, je pense qu'une grande partie des
00:01:29principes de l'ingénierie de l'inférence sont aujourd'hui bien établis, et qu'il y a beaucoup
00:01:34à apprendre et à reproduire d'une génération de modèles à l'autre. Mais aujourd'hui, je suis là pour parler
00:01:42des nouveautés en ingénierie de l'inférence. C'est la première mise à jour publique depuis la sortie du livre.
00:01:48On va rapidement revoir les principes de base, puis on va aborder
00:01:54tout ce qui s'est passé dans le monde de l'inférence depuis le 23 février 2026. On parlera
00:02:00de ce qui est arrivé à TurboQuant, un peu de la compaction KV, on passera du temps
00:02:05sur dFLASH et d'autres nouveautés passionnantes du décodage spéculatif, puis je me prêterai à
00:02:12un peu de prospective sur ce qui nous attend dans le domaine de
00:02:17l'inférence, et sur ce dont j'espère pouvoir vous parler la prochaine fois
00:02:23qu'on se verra ici. Super, alors commençons. En échangeant
00:02:30avec énormément de monde sur l'inférence, j'ai dégagé quelques grands principes partagés. L'un
00:02:38des plus importants... J'étais dans un podcast l'autre jour avec Sarah, on parlait d'inférence, et
00:02:44deux approches distinctes de l'ingénierie de l'inférence ont émergé. Il y a l'inférence locale,
00:02:48où la stratégie consiste simplement à faire fonctionner le modèle sur le matériel disponible en le compressant
00:02:56par quantification, distillation ou élagage, comme on peut, en le répartissant sur n'importe quelles
00:03:02GPU à disposition. D'abord on le fait tourner, puis on le rend moins bête : on élimine
00:03:09les dégradations majeures causées par toute cette compression, et on essaie
00:03:15de retrouver l'intelligence de référence avec une taille de lot (batch size) de 1. Et puis il y a
00:03:20mon monde, celui du traitement par lots en centre de données. Là, l'objectif est d'abord d'obtenir
00:03:27une version fonctionnelle de vLLM dès le premier jour, puis de la rendre moins lente avec du routage sensible au KV, de la spéculation
00:03:33ou de la désagrégation. Et au sein de ces deux mondes, je pense qu'on a beaucoup à s'apprendre.
00:03:40Dans cette présentation, je vais me concentrer sur l'ingénierie de l'inférence appliquée aux centres de données,
00:03:46car c'est mon domaine, mais il se passe aussi des choses captivantes du côté de l'inférence locale.
00:03:52Dans mon livre, je considère généralement les poids du modèle comme un produit fini, et je pense
00:03:58que la transition entre entraînement et inférence est un aspect essentiel à garder en tête pour bien
00:04:03délimiter le sujet. Cependant, je constate de plus en plus fréquemment que de nombreuses
00:04:10optimisations de l'inférence découlent d'un processus d'entraînement dédié. La frontière entre entraînement
00:04:17et inférence devient donc de plus en plus floue, ce qui est très intéressant à observer.
00:04:22On assiste à un cercle vertueux : une inférence plus rapide génère plus de données, qui permettent d'entraîner
00:04:28un meilleur modèle, offrant une inférence encore plus rapide et plus de données, et ainsi de suite
00:04:33jusqu'à devenir extrêmement riche ! Concernant l'entraînement dédié à l'inférence, nous avons un ensemble
00:04:39de nouvelles techniques à aborder autour de ce que j'aime appeler les “trois grands piliers”. Nous allons
00:04:45parler des nouveautés en quantification, en mise en cache (spécifiquement le mécanisme de cache KV),
00:04:52et en spéculation. Car même s'il existe beaucoup d'autres sujets dans le monde de l'inférence
00:04:57— dont certains que j'aborderai à la fin —, au quotidien, quand il s'agit
00:05:02d'accélérer un modèle donné, ce sont généralement ces trois techniques qui sont privilégiées.
00:05:09Première chose : je publie mon livre en février, je me sens super fier de moi, je me dis : “Waouh,
00:05:16tout ce qu'il faut savoir sur l'inférence est réuni au même endroit !” Et puis, on a eu des nouvelles
00:05:23dans le monde de la quantification. En résumé, la quantification consiste à utiliser un format numérique plus petit et moins précis
00:05:32afin d'économiser de la bande passante et du calcul, d'améliorer le TTFT et le débit de tokens par seconde. C'est
00:05:39souvent spécifique au matériel et permet de réduire les coûts, mais au risque de dégrader légèrement la qualité du modèle.
00:05:45D'ailleurs, si vous voulez entendre toute ma tirade sur la quantification, j'ai donné une conférence à l'AI Engineer
00:05:51Miami le mois dernier, où j'expliquais qu'elle n'est pas forcément aussi mauvaise qu'on le croit et qu'il
00:05:57existe plein de façons de préserver la qualité tout au long du processus. J'étais donc satisfait de ma partie sur
00:06:04la quantification, et là, 20 millions de personnes ont découvert TurboQuant. Ça a même fait baisser temporairement
00:06:12les actions de la mémoire sur les marchés, parce que tout le monde se disait : “La mémoire va être tellement plus efficace
00:06:16qu'on aura plus besoin de mémoire flash !” Ce qui était faux, mais bref. C'était une nouvelle
00:06:23approche de quantification popularisée en mars de cette année, qui utilise des coordonnées polaires
00:06:29et permet de quantifier le cache KV sur 4 bits. Ça a fait un énorme buzz et je me suis dit :
00:06:36“Mince, j'ai raté tout un sujet ! À quoi cela va-t-il ressembler en pratique ?”
00:06:43Notre équipe a donc mené des recherches là-dessus. Si vous le connaissez, dédicace à l'intern
00:06:50Waterloo sur Twitter, Ali, de notre équipe de performance des modèles — je ne sais d'ailleurs pas s'il est toujours stagiaire —,
00:06:57mais il vient de Waterloo. Il a écrit un excellent article sur les mathématiques derrière TurboQuant.
00:07:04En gros, l'avantage de TurboQuant est qu'il permet de représenter le cache KV sur 4 bits au lieu
00:07:09de 8 bits. On gagne la moitié de l'espace et de la bande passante, ce qui double virtuellement la vitesse
00:07:14de déplacement du cache KV dans la mémoire système. Mais l'inconvénient est de taille.
00:07:21Avec TurboQuant, il faut effectuer des calculs supplémentaires lors de la passe avant pour compenser cela
00:07:25pendant le décodage, ce qui réduit le débit de tokens de plus de la moitié. C'est un compromis inacceptable
00:07:32pour la plupart des cas d'usage en production. Nous avons donc étudié TurboQuant en profondeur, mais nous ne l'utilisons pas
00:07:38pour ces charges de travail réelles. Nous conservons la quantification classique NVFP4.
00:07:44Cela dit, c'est une excellente technique pour l'inférence locale. Si vous faites tourner
00:07:51un modèle de langage à long contexte sur votre ordinateur local ou sur des GPU dans votre sous-sol,
00:07:58votre quantité de mémoire est très limitée. C'est le goulot d'étranglement numéro un, donc tout ce qui peut libérer
00:08:04de la mémoire du cache KV et vous permettre de traiter des séquences plus longues est extrêmement précieux,
00:08:09et le surcoût de calcul lors de la passe avant devient un inconvénient bien secondaire.
00:08:16TurboQuant reste donc un papier de recherche fantastique et une très bonne technique, qui s'est juste révélée moins
00:08:22adaptée à l'inférence en centre de données qu'il n'y paraissait au premier abord. À la place, nous nous
00:08:28concentrons sur le NVFP4, en privilégiant la quantification des poids plutôt que du cache KV, en faisant
00:08:36de notre mieux pour détecter les erreurs dans les poids quantifiés afin d'éviter d'aplatir les distributions
00:08:41de probabilité. Pour le cache KV lui-même, nous misons plutôt sur le routage sensible au KV, le déchargement, le partage de KV
00:08:49via des outils comme NCCL ou NVIDIA Dynamo, afin de déplacer le cache KV au sein
00:08:55du système et éventuellement le décharger sur la mémoire vive du CPU, plutôt que de chercher à le compresser
00:09:04avec TurboQuant. Nous travaillons aussi sur la quantification multimodale, en cherchant
00:09:11comment appliquer les avantages du NVFP4 non seulement aux modèles de langage, mais aussi aux modèles d'image
00:09:17et de vidéo. Ali a d'ailleurs écrit de très bonnes choses là-dessus sur Twitter, n'hésitez pas à aller voir.
00:09:23Cela dit, le cache KV reste primordial. Parlons-en et abordons la compaction KV.
00:09:29Petit rappel : si vous envoyez la même invite avec le même préfixe, vous pouvez réutiliser
00:09:35les tokens calculés lors du pré-remplissage précédent, ce qui rend tout votre système plus rapide et plus efficace.
00:09:42Dans l'ensemble, le cache KV est une mémoire sans perte. Il y a peu de sources de mémoire sans perte quand
00:09:48on pense à notre système d'inférence. Il y a le contenu de l'invite, le contexte et le cache KV,
00:09:55qui augmente de manière linéaire avec la quantité de données fournies. Et aujourd'hui, si l'on pense
00:09:59à des longueurs de séquence d'un million de tokens, cela devient considérable. Beaucoup de monde cherche donc
00:10:05à compresser la mémoire et le contexte. Les frameworks d'agents réduisent le contexte, la recherche RAG
00:10:11aussi : toutes ces techniques dont on parle depuis des années consistent à compresser un contexte
00:10:17plus large en quelque chose d'exploitable par le modèle ou d'enregistrable dans des fichiers. Toutes ces méthodes
00:10:22évoluent de manière sous-linéaire par rapport au volume de données. Mais s'il existait une voie intermédiaire ?
00:10:28Un moyen d'obtenir une forte compression des données conservées en mémoire tout en maintenant une rétention
00:10:34d'information presque sans perte ? Il existe différentes approches pour déterminer ce qu'il faut garder
00:10:41dans le cache. Les méthodes récentes de compaction montrent qu'on peut remplacer le cache par un bien plus court.
00:10:47beaucoup plus court. On a des papiers comme Attention Matching ou Cartridges qui offrent des résultats très prometteurs
00:10:53avec des taux de compression élevés. Mais ces deux méthodes s'exécutent au moment de l'inférence. Encore une fois, l'une des techniques
00:11:00ou l'un des thèmes dont je veux parler, c'est l'entraînement dédié à l'inférence. Dans ce cas précis,
00:11:05je souhaite présenter “STILL”, développé par l'équipe de recherche de Base Ten, où la synthèse au-dessus
00:11:12du cache — où l'on conserve une représentation apprise de l'information plutôt que l'information
00:11:17directement ou un sous-ensemble déterministe — est amortie par l'entraînement. Charlie et Mudith de
00:11:25notre équipe de post-entraînement ont fait une présentation fantastique lors d'un récent événement CoSA. Elle est disponible sur YouTube,
00:11:31je vous encourage à la regarder si la compaction du cache KV vous intéresse. Je n'ai
00:11:37malheureusement pas le temps ni le génie pour tout expliquer ici, mais le mécanisme de base
00:11:46est que STILL constitue un goulot d'étranglement de type Perceiver qui prend un ensemble fixe de vecteurs requêtes appris, réalise une attention croisée
00:11:53sur l'ensemble du cache KV, et produit un ensemble de clés et valeurs compactes en une seule passe avant.
00:11:59Cela crée une mémoire compressée, rapide et différentiable à laquelle le LLM peut prêter attention comme s'il s'agissait du contexte réel.
00:12:05Si la compaction KV vous intéresse, jetez absolument un œil aux travaux de Charlie et Mudith.
00:12:09C'était vraiment passionnant à étudier. Voilà pour deux des techniques. Nous avons abordé
00:12:16la quantification, nous avons abordé le mise en cache. La dernière est la spéculation, et il y a eu beaucoup d'évolutions
00:12:21à ce sujet. Pour rappel, dans le décodage spéculatif, on utilise des jetons brouillons que l'on vérifie
00:12:29durant la passe avant, afin de générer plus d'un jeton par passe avant.
00:12:34Cela aide énormément pour le nombre de jetons par seconde, et c'est une optimisation sans aucune perte, ce qui est idéal car
00:12:40nous n'avons pas à nous soucier de la qualité. En ce qui concerne l'historique de la spéculation, nous avons commencé
00:12:46par le décodage spéculatif. Tout cela est détaillé dans le livre. Il y a SpecDec, où l'on utilise un petit modèle
00:12:52de la même famille pour générer des jetons brouillons. Il s'avère que les petits modèles ne sont pas de très bons générateurs de jetons brouillons,
00:12:58même si ce sont de très bons petits modèles. Notre secteur a donc inventé une série de nouvelles méthodes comme Medusa, où
00:13:04l'on ajoute des têtes de décodage au modèle, puis finalement Eagle 3, qui s'est demandé : et si
00:13:09au lieu de prendre un minuscule modèle de la même famille, on entraînait un modèle d'un milliard de paramètres sur les
00:13:15états cachés du modèle cible pour générer ces jetons brouillons ? Cela a particulièrement bien fonctionné, et
00:13:21jusqu'à février de l'année dernière ou février de cette année, Eagle 3 était la meilleure méthode de
00:13:27spéculation. Désormais, nous avons dFlash. dFlash est encore meilleur : c'est de la diffusion appliquée à la spéculation. dFlash crée
00:13:36une séquence entière de jetons brouillons au lieu d'un seul jeton. Le modèle est un modèle de langage par diffusion,
00:13:43ce qui signifie qu'il génère toute une séquence de jetons, exactement comme la génération d'images ou de vidéos crée
00:13:49une suite d'images ou de pixels et effectue des itérations dessus, au lieu de faire une génération autorégressive de jetons.
00:13:55Les modèles dFlash peuvent être deux ou quatre fois plus lents à s'exécuter, mais ils vont prédire huit
00:14:01ou 16 jetons d'un coup dans cette fenêtre d'exécution, alors qu'Eagle n'en traite qu'un à la fois. Une seule passe avant
00:14:08de dFlash est plus rapide que toute la phase de brouillon d'Eagle et prédit plus de jetons. Ces jetons peuvent
00:14:14appliquer une attention croisée entre eux et générer globalement un meilleur taux d'acceptation, car dans la spéculation,
00:14:21le taux d'acceptation fait tout. En pratique, nous constatons une amélioration de plus de 3x grâce à dFlash. C'est mesuré
00:14:30sur un seul GPU B200 avec Qwen 3 8B, et par rapport à Eagle, c'est un gain substantiel au niveau des jetons,
00:14:40aussi bien pour le taux d'acceptation que pour les jetons par seconde. Ces modèles dFlash sont entraînés avec un masque d'attention pour
00:14:47le brouillon bidirectionnel. Le modèle cible fournit le contexte, et au sein de chaque bloc,
00:14:54un sous-ensemble de jetons propres est échantillonné, tandis que le masque d'attention garantit
00:14:59la cohérence causale. Mais il permet tout de même une attention bidirectionnelle, alors que dans
00:15:06un modèle autorégressif traditionnel, vous ne regardez les jetons que dans une seule direction. C'est pourquoi nous pouvons
00:15:13tirer parti de cette architecture basée sur la diffusion. Et puis, au moment où je pensais avoir
00:15:19terminé, dSpark est sorti il y a deux jours. Nous exploitons dFlash en production,
00:15:25mais dSpark relève encore de la recherche récente. À son sujet, je peux juste dire que ça existe, que c'est très intéressant et qu'on
00:15:31étudie la question. La différence par rapport à dFlash, c'est qu'il conserve ce modèle de diffusion mais le couple à
00:15:38un modèle séquentiel. L'idée est d'améliorer les taux d'acceptation en faisant travailler ces deux
00:15:45modèles ensemble, plutôt que d'avoir seulement un spéculateur itératif,
00:15:51un spéculateur par diffusion ou un spéculateur autorégressif. dSpark est très prometteur, mais nous n'avons
00:15:57pas encore de résultats en production à partager. J'espère qu'on en aura la prochaine fois.
00:16:03En revanche, nous avons des résultats en production concernant réentraînement continu du spéculateur. On revient
00:16:09ici à dFlash. L'idée est que le décodage spéculatif dépend énormément du
00:16:15contenu réel des invites et des réponses que votre système traite. Si vous
00:16:21réentraînez continuellement le modèle sur ces invites et réponses en direct, vous pouvez obtenir une amélioration de 20 % à 2x
00:16:29de vos taux d'acceptation de jetons. C'est extrêmement complexe à mettre en œuvre : cela demande beaucoup de
00:16:36stockage et vous devez vous assurer d'avoir l'autorisation d'utiliser les données que vous traitez de
00:16:40cette façon. Cela nécessite énormément de puissance de calcul et il faut déplacer toutes ces informations. De plus, si
00:16:46vous modifiez le modèle sous-jacent, vous devez aussi adapter le modèle spéculateur. Mais quand je me projette dans
00:16:51l'avenir, je pense sincèrement que la spéculation continue pour les très grands systèmes sera une optimisation
00:16:58incontournable. Quelle est la prochaine étape pour l'inférence ? Ce qui suit relève de l'opinion personnelle, de la spéculation
00:17:06et d'informations publiques. Si j'étais au courant de réelles annonces à venir, je ne pourrais pas en
00:17:11parler. C'est donc simplement ma vision des choses. J'ai connu
00:17:17trois cycles matériels : la sortie d'Ampere, celle de Hopper et celle de Blackwell. Et cela prend toujours
00:17:23du temps entre l'expédition de ces puces, leur installation dans les centres de données, et le moment où
00:17:30toute la suite logicielle devient pleinement capable d'exploiter leurs capacités. Mais parmi les évolutions
00:17:36qui me passionnent, il y a Rubin, dont les performances en NVFP4 s'annoncent fantastiques.
00:17:44Ainsi, plus nous pourrons emprunter des techniques à l'inférence locale et gagner en confiance pour exécuter
00:17:49des modèles dans ce format NVFP4, plus nous serons en mesure de profiter des excellentes
00:17:54performances des futurs systèmes Rubin. Je pense aussi que la désagrégation et la communication
00:18:00à l'échelle du système vont devenir de plus en plus cruciales. Nous voyons d'excellents premiers résultats avec la désagrégation
00:18:05Prefill/Decode, et la capacité à déplacer des informations comme les données du cache KV au sein du système sera
00:18:12de plus en plus déterminante. Enfin, comme je l'ai dit, l'entraînement optimisé pour l'inférence reste
00:18:17un sujet qui aura un impact majeur sur l'industrie à l'avenir. Merci infiniment à tous
00:18:25d'être venus assister à cette présentation. Je suis sur Twitter, sur LinkedIn, et je distribue des livres gratuits.
00:18:32Vous pouvez télécharger le PDF via le QR code ou me rejoindre au stand Base Ten pour obtenir votre exemplaire papier d'”Inference Engineering”.
00:18:37Nous en avons pas mal sur place, peut-être assez pour tout le monde, sinon nous demanderons à un coursier
00:18:43d'en apporter d'autres depuis le bureau. Voilà, je serai en bas au stand Base Ten. Merci encore à tous
00:18:48et passez une excellente journée.
Community Posts
No posts yet. Be the first to write about this video!
Write about this video