Chapitre 4 — Silicium spécialisé et ASIC pour l'IA

Quatrième billet de la tournée chapitre par chapitre de LLM Primer VI : Mettre à l'échelle les systèmes IA. Le chapitre qui affirme que le choix entre un GPU et un ASIC est une question de forme de charge — et qui vous donne la forme.

Pourquoi ce chapitre existe

Le camp GPU soutient que l'inférence LLM est une charge parmi d'autres dans une large classe de problèmes de multiplication matricielle dense, et qu'un accélérateur programmable est le bon substrat. Le camp ASIC soutient que l'inférence est spécifique, régulière et prévisible au point qu'une puce dédiée peut battre une puce généraliste sur les deux métriques qui comptent — latence et coût par token. Les deux camps ont raison sur les charges qu'ils choisissent. Le Chapitre 4 parcourt les alternatives ASIC de qualité production aux GPU de centre de données en 2026 — le LPU de Groq, AWS Inferentia2, les TPU Google v5p et v6, l'Intel Gaudi 3 — et nomme les régimes où chacune gagne et les modes d'échec qui ramènent les ingénieurs aux GPU.

4.1 Groq élimine la HBM pour rendre la latence déterministe

Le LPU de Groq est la puce la plus architecturalement distinctive sur le marché des accélérateurs de production : elle n'a pas de HBM. Le modèle entier vit dans une SRAM embarquée ordonnancée par le compilateur, répartie sur de nombreuses puces reliées par un réseau intra-boîtier déterministe. Pas d'allocation mémoire dynamique, pas de surcoût de lancement de kernel, pas de jitter d'ordonnancement — chaque exécution de la même entrée produit la même sortie en exactement le même nombre de nanosecondes. La métrique qui tombe est une latence de décodage que les GPU n'approchent pas : un modèle 70B à 200–500 tokens par seconde par requête, contre 30–80 sur H100. Le coût architectural est la taille du modèle — la SRAM est bornée à quelques centaines de mégaoctets par puce, donc un modèle 70B exige un rack de 250 puces et plus reliées par l'interconnexion TSP de Groq, et le rack est l'unité de déploiement. Les charges qui paient ce rack sont les assistants vocaux sous un budget conversationnel de 200 ms, la complétion de code interactive, la génération de signal financier — partout où l'utilisateur perçoit chaque milliseconde.

4.2 Inferentia2 et TPU gagnent sur le coût quand le modèle est stable

AWS Inferentia2 et Google TPU v5p/v6 attaquent une autre métrique : dollars par million de tokens de sortie. Les deux sont conçues pour du service batché en régime stable où le portefeuille de modèles est étroit, le budget de latence est lâche et le volume est assez élevé pour qu'une économie de 40–60 pour cent sur les GPU domine le coût de re-plateformage. Inferentia2 expose le SDK Neuron et fait tourner vLLM via le conteneur officiel AWS ; l'étape de compilation est lourde au premier chargement et mise en cache ensuite. TPU expose JAX/XLA et tourne via les endpoints Vertex AI Inference. Les deux plateformes récompensent les charges qui restent semblables jour après jour — traduction, modération, pipelines d'embeddings, RAG sur des corpus stables — et pénalisent celles qui changent souvent d'architecture de modèle, car le chemin compile-puis-cache est une taxe à chaque swap. La discipline est de choisir l'une et de standardiser ; faire tourner les deux à l'échelle de production revient à payer la taxe de re-plateformage en double.

4.3 Gaudi 3 est le pari Ethernet, et le GPU garde la frontière

Intel Gaudi 3 fait un pari structurel différent : plutôt qu'une interconnexion propriétaire (NVLink, ICI, TSP), il utilise de l'Ethernet 200/400 GbE de commodité pour la communication puce à puce, en pariant que la mise à l'échelle native Ethernet abaisse le coût opérationnel des grands déploiements. Le logiciel est SynapseAI de Habana plus les intégrations PyTorch Lightning, avec un support vLLM en amélioration régulière. Gaudi 3 est agressivement tarifé face à H100 et MI300X et se pose comme le « levier de coût avec le moins de friction de migration » pour les équipes qui veulent l'économie ASIC sans une nouvelle couche d'interconnexion. Face à tous ces choix, les GPU gardent un régime gagnant : variété des modèles, échelle frontière et expérimentation. Partout où l'équipe fait tourner un modèle de classe 405B, une architecture frontière fraîchement publiée, une variante spécialement affinée ou un kernel issu de la recherche, la profondeur de l'écosystème CUDA et la position d'entrée sur le marché de NVIDIA remboursent. L'heuristique est la « question du kernel » — si la pile fait tourner FlashAttention standard, un MLP fusionné standard et ne touche jamais à autre chose, un ASIC est candidat ; si elle fait tourner un kernel que quelqu'un de l'équipe a écrit, un GPU est l'achat plus sûr.

Ce que prépare le Chapitre 4

Les Chapitres 3 et 4 ont décrit le substrat matériel tel qu'il est. Chaque carte proposée est soit contrainte par la bande passante HBM (décodage GPU), soit re-conçue autour (Groq), soit à bande passante agressivement tarifée pour des charges stables (Inferentia, TPU, Gaudi). Le Chapitre 5 se tourne vers le mouvement côté logiciel qui rétrécit directement le fardeau de bande passante par token : la quantification de FP16 vers FP8 puis FP4. Le gain d'un passage à Blackwell et le gain de quantifier un modèle existant en FP8 sont, mécaniquement, le même levier tiré à deux couches différentes de la pile — et les deux s'appliquent généralement ensemble.

Prochaine étape — Chapitre 5 : Démystifier la quantification. La chute de précision de BF16 à FP8 puis INT4, pourquoi les grands modèles y survivent, et le flux de calibration qui atterrit vraiment en production.