Le paysage de la concurrence dans les puces AI évolue profondément. OpenAI lance la puce Jalapeño dédiée à l'inférence LLM, NVIDIA combine les GPU avec le LPU de Groq pour réaliser un calcul hétérogène, tandis que Google sépare l'entraînement et l'inférence en deux puces distinctes : TPU 8t et TPU 8i. Ces trois approches reflètent les besoins différents en ressources matérielles pour l'entraînement et l'inférence : l'entraînement privilégie les calculs matriciels et une interconnexion à grande échelle, tandis que l'inférence exige une bande passante HBM plus élevée, une SRAM plus importante et des chemins réseau plus courts. À mesure que l'écart entre les configurations matérielles pour ces deux types de charges de travail s'élargit, les FLOPS ne sont plus le seul critère de mesure, et le coût par token devient le nouveau repère de la concurrence dans le domaine du matériel AI.

Auteur et source de l'article : Leifengwang

Le coût des jetons devient un nouveau point de référence pour la concurrence matérielle des grands modèles

Intelligence incarnée, pénètre la cuisine encombrée de fumée

La vie d'un robot sous un million de visiteurs

L'ancien vice-président de Covariant AI, Zhoupu Shuzhong, a directement résumé le rôle du LPU comme comblant le déficit de Vera Rubin dans la région de décodage à faible latence.

La conception des puces de Groq est également presque entièrement axée sur cela. Un rack LPX contient 256 LPU, avec un total de seulement 128 Go de SRAM, une capacité qui ne peut pas être comparée à celle du HBM dans les racks GPU, mais dont la bande passante agrégée peut atteindre 40 Po/s.

Ce design met l'accent sur la "proximité". Le HBM peut stocker de nombreux états de modèle, mais il est plus éloigné des unités de calcul ; le SRAM est coûteux et difficile à scaler en capacité, mais les données se trouvent à l'intérieur même du circuit intégré, permettant une bande passante très élevée et une latence d'accès très faible.

Chaque étape de calcul est limitée, et les données sont fréquemment récupérées ; en plaçant les données plus près de l'ALU, les gains se refléteront directement sur le temps d'attente du prochain Token.

Groq a également réduit davantage le contrôle matériel dynamique. LPU est une architecture d'exécution déterministe, où l'ordonnancement des instructions est principalement effectué à l'avance par le logiciel. Chaque puce agit simultanément comme processeur et routeur ; le compilateur planifie ensemble les ressources de calcul et les ressources réseau, éliminant même des mécanismes traditionnels tels que le contrôle de flux matériel et les canaux virtuels.

Le coût est également évident : cette architecture n'est pas aussi universelle qu'une GPU, et la mémoire SRAM intégrée ne peut pas stocker l'état complet des grands modèles. Ainsi, NVIDIA n'a pas fait fonctionner Groq 3 de manière autonome pour exécuter l'ensemble du modèle, mais a plutôt mis en place un système hétérogène plus complexe.

Le préremplissage est effectué sur le GPU, la majeure partie du décodage est déplacée vers le LPU ; l'attention dans le décodage peut à nouveau revenir au GPU. Le GPU et le LPU maintiennent chacun leur propre KV Cache ; ils échangent principalement des tokens de brouillon et superposent calcul et communication grâce à des micro-batchs. Étant donné que le LPU est un domaine synchrone tandis que le GPU et le KV Cache externe appartiennent à un système asynchrone, NVIDIA a même intégré un FPGA comme pont asynchrone entre les deux.

Cette structure illustre bien à quel point la répartition des tâches pour les puces AI a progressé. Elle ne sépare plus seulement les puces d’entraînement et les puces d’inférence, mais même différentes parties d’un seul décodage peuvent être exécutées sur des architectures distinctes.

Cependant, les données présentées par NVIDIA délimitent les frontières de cette approche : lorsque l'activité se concentre uniquement sur le débit total et qu'une latence plus élevée est acceptable, le GPU Rubin reste très efficace ; à mesure que les exigences en vitesse de token par utilisateur augmentent, LPX commence à afficher ses avantages, et l'utilisation de davantage de LPU entraîne une baisse de l'efficacité globale du débit.

Ainsi, l'apparition de Groq 3 ne signifie pas que les GPU sont éliminés pour l'inférence. Elle illustre autre chose : il est difficile pour un même GPU de maîtriser à la fois la haute débit et la très faible latence ; en laissant chaque type de matériel se concentrer sur son domaine d'expertise, le système parvient plus facilement à élargir la courbe de performance.

Google a placé cette ouverture à un niveau plus élevé.

Entraînement et inférence, avec deux recettes de puces différentes

Google a créé à la fois le TPU 8t et le TPU 8i dans cette génération TPU 8,t destiné à l'entraînement,i destiné à l'inférence. Cette distinction repose sur une logique directement intégrée à la configuration mémoire du puce.

En démonstration en direct sur Hot Chips, le TPU 8t utilise 6 groupes de HBM, tandis que le TPU 8i en utilise 8. Google explique que l'inférence nécessite plus de HBM par unité de calcul, ainsi qu'un pourcentage plus élevé de SRAM ; le TPU 8i alloue donc davantage de ressources à la SRAM, à la capacité mémoire et à la bande passante.

Cette différence mérite réflexion. Si les puces AI ne se concentraient que sur la puissance de calcul matriciel, il n’y aurait aucune raison pour la version d’inférence de consacrer autant de surface de puce et de ressources de封装 à la mémoire. La conception du TPU 8i indique que Google a identifié un goulot d’étranglement déplacé vers l’approvisionnement en données.

Lors de l'entraînement, un grand lot répartit le coût de lecture des poids sur de nombreux tokens ; pendant le décodage, chaque token généré est peu nombreux, mais les poids et le cache KV sont toujours fréquemment accédés. Ainsi, la quantité de bande passante HBM requise par unité de FLOPS diffère entre ces deux types de tâches.

Google a même appliqué cette différence à la topologie réseau. L'3D Torus précédemment utilisé pour les TPU est mieux adapté à l'entraînement, en mettant l'accent sur le débit global dans les clusters à grande échelle. Le TPU 8i prend en charge BoardFly, avec des chemins réseau plus courts : la limite de chemins pour BoardFly est de 7 sauts, tandis que l'3D Torus atteint 16 sauts.

Pour l'entraînement, après quelques sauts réseau supplémentaires, il reste généralement une grande partie de calcul matriciel, ce qui permet de répartir le temps de communication. La fenêtre de calcul pour chaque étape de décodage est courte, et les latences réseau de quelques sauts sont plus susceptibles de se produire directement dans les intervalles entre les jetons.

MoE rend ce problème encore plus évident. MoE permet à un Token d'activer uniquement une partie des Experts, ce qui est très rentable en termes de calcul, mais le Router envoie les Tokens vers différents Experts. Dès que ces Experts sont répartis sur des puces différentes, la réduction du calcul s'accompagne d'une augmentation de la communication All-to-All.

Ainsi, le TPU 8i intègre également l'Collective Acceleration Engine, qui effectue certaines opérations collectives sur le die I/O, près de l'interface réseau. Les données n'ont plus besoin d'être déplacées d'abord vers le die de calcul, puis traitées via le HBM ; cela permet d'éliminer une partie des déplacements de données à l'intérieur du puce.

La répartition des ressources pour la version d'entraînement TPU 8t est clairement orientée vers l'autre extrémité. L'entraînement nécessite une grande quantité de FLOPS ainsi qu'un domaine de mise à l'échelle important pour synchroniser les paramètres et les gradients. Le Superpod TPU 8t peut être étendu à 9600 puces, avec environ 2 PB de HBM partagé et 121 EFLOPS FP4 de capacité de calcul agrégée ; Google y a introduit le réseau Virgo pour créer un système dédié reliant des ensembles d'entraînement encore plus vastes.

Google a également mentionné un problème concret de conception de puce : le dark silicon.

La surface du puce et le budget de consommation énergétique sont limités. Si l'on intègre simultanément sur la même puce une grande quantité de ressources de calcul matriciel nécessaires à l'entraînement, ainsi que davantage de SRAM, de HBM et de réseaux à faible latence requis pour l'inférence, une partie des circuits restera longtemps inutilisée lors de l'exécution d'un type de charge de travail donné.

Étant donné que les deux tâches nécessitent des proportions de ressources différentes, il est plus propre de réaliser deux puces distinctes.

De FLOPS à l'économie de jeton

Mettre les trois itinéraires ensemble révèle en fait des différences claires.

OpenAI fait du Jalapeño, en spécialisant les puces au niveau de l'inférence LLM, tout en conservant un planification flexible du Prefill et du Decode sur du matériel homogène ; NVIDIA continue de décomposer en assignant différentes étapes de l'inférence à des GPU et des LPU Groq ; Google coupe vers le haut, en faisant de l'entraînement et de l'inférence deux TPU distincts.

Derrière ces différentes approches, il n’y a pas de nouveau principe de calcul mystérieux ; ce qui change, c’est la répartition des ressources. L’entraînement vise à consacrer davantage de transistors au calcul matriciel et à l’interconnexion à grande échelle, car un batch élevé permet de répartir le coût de transfert des données. L’inférence à faible latence nécessite une bande passante HBM plus élevée, une SRAM plus importante, une meilleure localité du cache KV et des chemins réseau plus courts, car une grande partie du temps est consacrée à l’attente des données.

Lorsque les « recettes de puce » requises par les deux types de charges s'éloignent de plus en plus, utiliser une seule puce universelle pour les prendre en charge entraîne naturellement une perte d'efficacité de plus en plus marquée.

C'est aussi pourquoi les chiffres clés de cette vague de concurrence matérielle évoluent. Les FLOPS restent importants, mais des indicateurs comme Tokens/s/user, TBT, TTFT, Tokens/kW, la bande passante HBM et la latence réseau apparaissent à côté.

Ils décrivent en réalité la même chose : la puissance de calcul est déjà en place ; le système parvient-il à alimenter continuellement les données et à sortir les tokens générés le plus rapidement possible.

OpenAI, NVIDIA et Google n'ont pas encore choisi la même ligne de démarcation ; ce qui va probablement continuer à évoluer, c'est l'endroit où cette ligne devrait être tracée.

L'entraînement et l'inférence peuvent être séparés, le préremplissage et le décodage peuvent être séparés, et l'attention à l'intérieur du décodage ainsi que les autres calculs peuvent également être subdivisés. Plus la subdivision est fine, plus l'efficacité de chaque tâche individuelle est facile à améliorer, mais la planification des ressources, le transfert du KV Cache et la communication inter-hardware deviennent plus complexes.

Ainsi, le défi de la prochaine phase de la concurrence sur les puces AI ne se limite peut-être plus à la fabrication d'une puce plus puissante.

Plus difficile encore : déterminer quelles tâches méritent une puce dédiée, et quelles tâches continueront d’être exécutées sur le même matériel, afin de réduire au minimum le coût total en tokens du système.