Accueil › Glossaire › TPU

TPU (Tensor Processing Unit)

Un TPU (Tensor Processing Unit) est un circuit intégré spécialisé (ASIC) conçu par Google pour accélérer les calculs de machine learning, en particulier les multiplications matricielles au cœur des réseaux de neurones.

Contrairement aux GPU qui sont des processeurs parallèles polyvalents adaptés à l’IA, les TPU sont construits dès le départ pour une seule mission : exécuter le plus efficacement possible les opérations tensorielle qui constituent l’essentiel du calcul en deep learning. Google les utilise massivement en interne pour entraîner et servir ses modèles Gemini, et les propose aux clients externes via Google Cloud. Des entreprises comme Anthropic (qui entraîne Claude sur des clusters TPU), AI21 Labs, et d’autres utilisent aussi les TPU comme alternative aux GPU NVIDIA.

Comment fonctionne un TPU

Architecture interne

Chaque puce TPU contient un ou plusieurs TensorCores (à ne pas confondre avec les Tensor Cores de NVIDIA, qui sont des unités au sein d’un GPU). Chaque TensorCore embarque des MXU (Matrix Multiply Units), des unités vectorielles, et des unités scalaires. Les MXU sont le cœur du TPU : ce sont des matrices systoliques de grande taille qui effectuent des multiplications matricielles avec une efficacité énergétique supérieure aux GPU pour ce type de calcul.

Le TPU v6e (Trillium) contient 1 TensorCore par puce avec 2 MXU, et supporte les précisions BF16 (bfloat16) et INT8. Il dispose aussi d’un SparseCore de 3ème génération, un accélérateur dédié au traitement des embeddings utilisés dans les systèmes de recommandation et de ranking, un workload critique pour les services Google (Search, Ads, Maps).

Mémoire HBM intégrée

Comme les GPU IA haut de gamme, les TPU utilisent de la mémoire HBM (High Bandwidth Memory) empilée en 3D directement sur le package de la puce. Le TPU v6e dispose d’environ 32 Go de HBM par puce (les configurations précises varient). Le TPU v7 Ironwood monte significativement en capacité avec de la HBM3e.

Cette mémoire à haute bande passante est essentielle pour l’inférence de LLM, où la vitesse de lecture des poids du modèle détermine directement la vitesse de génération de tokens.

Interconnexion ICI et mise à l’échelle

Les TPU se connectent entre eux via l’ICI (Interchip Interconnect), un lien propriétaire à très haut débit. Le TPU v6e double la bande passante ICI par rapport au v5e. Un pod TPU v6e contient 256 puces interconnectées dans un maillage 2D à haute bande passante et faible latence.

Au-delà du pod, la technologie Multislice permet de connecter des centaines de pods via le réseau datacenter Jupiter (13 Pétabits/s de bande passante bisectionnelle). Google a démontré un scaling quasi-linéaire (99% d’efficacité sur 3072 puces, 94% sur 6144 puces) pour l’entraînement de modèles comme GPT-3 175B. Les déploiements Trillium atteignent plus de 100 000 puces par fabric réseau, avec 91 exaFLOPS agrégés dans un seul cluster TPU.

Les générations de TPU

TPU v7 Ironwood : la prochaine frontière

Le TPU v7, nom de code Ironwood, est disponible en preview. D’après les analyses, Ironwood réduit considérablement l’écart de FLOPS théoriques avec le B200 de NVIDIA, tout en maintenant l’avantage coût de l’écosystème TPU. Il utilise de la HBM3e et apporte des améliorations sur le compute, la mémoire et l’interconnexion. C’est la première génération TPU conçue entièrement pour l’ère post-LLM, avec un focus sur l’entraînement à très grande échelle et l’inférence efficace.

TPU vs GPU : quand choisir quoi

Avantages des TPU

Le premier avantage est le coût. Le TPU v6e démarre à environ $0,39 par chip-heure en mode on-demand, contre $3+ pour un H100 sur les principaux clouds. Pour des workloads massifs d’entraînement ou d’inférence, cet avantage de coût est considérable. Midjourney a rapporté une réduction de coût d’environ 65% en migrant vers les TPU.

Le second est le scaling. L’interconnexion ICI propriétaire de Google et la technologie Multislice permettent de scaler quasi-linéairement sur des dizaines de milliers de puces, avec une infrastructure réseau (Jupiter) conçue pour cet usage. Les clusters TPU de Google comptent parmi les plus grands superordinateurs IA au monde.

Le troisième est l’efficacité énergétique. Les TPU, en tant qu’ASIC spécialisés, consomment moins d’énergie par FLOP que les GPU polyvalents. Trillium est 67% plus efficace énergétiquement que le v5e.

Avantages des GPU

Le premier avantage des GPU est l’écosystème logiciel. CUDA bénéficie de 20+ ans de développement, 4 millions de développeurs, et une compatibilité native avec tous les frameworks ML. Les TPU fonctionnent principalement avec JAX (le framework préféré de Google), et le support PyTorch via XLA reste moins mature que le support CUDA natif.

Le second est la disponibilité. Les GPU NVIDIA sont disponibles chez tous les fournisseurs cloud (AWS, Azure, GCP, Oracle, etc.) et en achat direct. Les TPU ne sont accessibles que via Google Cloud.

Le troisième est la flexibilité. Les GPU peuvent exécuter une variété de workloads au-delà du ML (rendu graphique, simulation, HPC). Les TPU sont spécialisés pour le ML et moins performants sur d’autres types de calcul.

Verdict : Les TPU sont le meilleur choix si vous opérez déjà dans l’écosystème Google Cloud, si vous utilisez JAX, et si vos workloads sont du training/serving de LLM à grande échelle où le coût par FLOP est déterminant. Les GPU NVIDIA restent le choix par défaut pour la plupart des équipes grâce à la maturité de CUDA, la disponibilité multi-cloud, et la flexibilité d’usage.

Utiliser les TPU en pratique

Accès via Google Cloud

Les TPU sont accessibles exclusivement via Google Cloud, sous plusieurs modalités de consommation. Le mode on-demand permet de provisionner des TPU à la demande, sans engagement. Le mode reserved offre des tarifs réduits avec un engagement de 1 à 3 ans. Le mode Flex-start, introduit récemment, permet de provisionner dynamiquement des TPU pour des durées allant jusqu’à 7 jours via une API de file d’attente, idéal pour l’expérimentation et le fine-tuning.

Les TPU s’intègrent dans l’écosystème Google Cloud via GKE (Google Kubernetes Engine) pour l’orchestration des workloads. Google fournit aussi des VM hôtes avec de la DRAM massive pour le host-offloading (stocker les données qui ne tiennent pas en HBM sur la mémoire hôte).

Frameworks supportés

JAX est le framework de prédilection pour les TPU. Développé par Google, JAX offre une compilation XLA native qui exploite pleinement l’architecture TPU. La plupart des modèles de Google (Gemini, Gemma, PaLM) sont entraînés en JAX sur TPU.

PyTorch est supporté via PyTorch/XLA, une couche qui compile le code PyTorch pour exécution sur TPU. Le support s’améliore rapidement, mais certains modèles ou opérations peuvent nécessiter des adaptations. Le support vLLM et SGLang pour TPU est en beta, ce qui ouvre la porte à l’inférence de LLM avec les mêmes outils que sur GPU.

TensorFlow reste supporté mais est de moins en moins utilisé pour les nouveaux projets, la communauté ML ayant largement migré vers JAX et PyTorch.

Migrer d’un GPU vers un TPU

La migration d’un workload GPU vers TPU n’est pas triviale. Les principaux points d’attention sont le sharding du modèle (les TPU nécessitent un partitionnement explicite du modèle sur les puces, souvent via jax.sharding), la gestion mémoire (la HBM par puce est plus limitée que sur un H100 80 Go, ce qui nécessite un placement précis des tenseurs), et les différences de précision numérique (les TPU utilisent nativement BF16, pas FP16).

L’effort de migration est significatif mais peut être rentabilisé rapidement sur de gros workloads grâce à l’avantage coût des TPU. Google fournit des guides de migration et des exemples pour les modèles les plus courants.

Qui utilise les TPU

Au-delà de Google lui-même (qui entraîne Gemini, Gemma, et fait tourner Search, Maps, YouTube sur des TPU), plusieurs clients majeurs utilisent les Cloud TPU.

Anthropic est l’un des plus gros clients TPU externes, avec un engagement rapporté de potentiellement jusqu’à 1 million de puces TPU pour l’entraînement de ses modèles Claude. Meta serait en négociations pour un déploiement TPU dans ses data centers à partir de 2027. Midjourney a migré une partie de ses workloads de génération d’images vers les TPU, rapportant une réduction de coût de 65%. AI21 Labs utilise les TPU depuis la v4 pour ses modèles Jamba et Mamba. Essential AI, Deep Genomics, Nuro (robotique autonome), et de nombreuses startups IA utilisent aussi les TPU via Google Cloud.

Edge TPU

Google propose aussi des Edge TPU, des versions miniaturisées conçues pour l’inférence sur des appareils embarqués. Un Edge TPU consomme seulement 2 watts tout en offrant 4 TOPS (trillions d’opérations par seconde). Il supporte uniquement l’inférence TensorFlow Lite, pas l’entraînement.

Les Edge TPU sont utilisés dans des caméras de surveillance intelligentes, des appareils IoT, et des systèmes de robotique nécessitant de l’IA locale à faible consommation. C’est un marché distinct des Cloud TPU, avec un positionnement similaire aux NPU intégrés dans les processeurs mobiles.

L’avenir des TPU

Google accélère le rythme de déploiement des TPU. Historiquement, Google annonçait les TPU après que la génération suivante était déjà en développement interne. Depuis Trillium, les annonces sont plus proches de la mise en production, ce qui réduit l’écart perçu avec les GPU NVIDIA en termes de disponibilité.

Le TPU v7 Ironwood représente un saut significatif qui rapproche les performances théoriques des TPU de celles des GPU NVIDIA Blackwell (B200), tout en maintenant un avantage de coût total de possession (TCO). L’intégration croissante avec vLLM et SGLang pour l’inférence ouverte est un signal que Google veut positionner les TPU au-delà de son propre écosystème JAX.

La tendance est aussi à la vente externe de systèmes TPU, un changement stratégique majeur pour Google. Si les TPU deviennent disponibles en dehors de Google Cloud (via des partenaires OEM ou des systèmes rack-scale), cela pourrait significativement élargir le marché adressable et intensifier la concurrence avec NVIDIA.

Historique : du premier ASIC IA au superordinateur

Google a commencé à travailler sur le premier TPU en 2013, motivé par une projection alarmante : si chaque utilisateur de Google utilisait la recherche vocale (qui repose sur des réseaux de neurones) pendant seulement 3 minutes par jour, Google devrait doubler sa capacité de data centers. Il fallait un matériel bien plus efficace que les CPU pour le deep learning.

Le TPU v1, déployé en interne en 2015, était un accélérateur d’inférence INT8 connecté via PCIe. Il ne faisait pas d’entraînement. Le TPU v2 (2017) a marqué l’ouverture aux clients externes via Google Cloud et a ajouté le support de l’entraînement avec la précision BF16 (bfloat16), un format de nombre à virgule flottante 16 bits inventé par Google spécifiquement pour le machine learning. Le TPU v3 (2018) a introduit le refroidissement liquide et doublé les performances du v2.

Le TPU v4 (2021) a été utilisé pour entraîner PaLM, le prédécesseur de Gemini, et pouvait former des pods de 4096 puces. Les TPU v5e et v5p (2023) ont séparé la gamme en deux lignes : le v5e optimisé pour le rapport coût/performance, et le v5p optimisé pour la performance brute (utilisé pour entraîner Gemini 1.x). Le TPU v6e Trillium (annoncé en mai 2024, GA en janvier 2026) a été utilisé pour entraîner Gemini 2.0 et représente le plus gros saut de performance de la lignée.

Chaque génération a aussi repoussé les limites de l’échelle des clusters. Le v4 permettait des pods de 4096 puces. Le v6e permet des déploiements de plus de 100 000 puces sur un seul fabric réseau Jupiter, avec 91 exaFLOPS agrégés. C’est l’un des plus grands superordinateurs IA au monde.

Limites des TPU

Les TPU ont des limites qu’il faut connaître. La première est le verrouillage fournisseur : vous êtes lié à Google Cloud, sans portabilité vers AWS, Azure, ou votre propre data center. Si Google change ses prix, ses conditions, ou son service, vous n’avez pas d’alternative immédiate.

La seconde est la complexité de programmation. Optimiser un workload pour TPU nécessite de comprendre le sharding des modèles sur les puces, la gestion des topologies 2D des pods, et les spécificités du compilateur XLA. C’est plus complexe que de lancer un entraînement sur GPU avec PyTorch.

La troisième est le support des modèles d’inférence ouverts. L’écosystème d’inférence open source (vLLM, SGLang, llama.cpp) est conçu principalement pour CUDA. Le support TPU dans vLLM et SGLang passe par une couche de traduction PyTorch vers JAX/XLA, avec un nombre limité de modèles supportés. Pour l’inférence de modèles open source, les GPU restent bien plus simples à utiliser.

La quatrième est la mémoire par puce. Le TPU v6e offre environ 32 Go de HBM par puce, nettement moins qu’un H100 (80 Go) ou un H200 (141 Go). Pour les modèles qui nécessitent beaucoup de mémoire par accélérateur (grands KV-cache, gros batch sizes), il faut distribuer sur plus de puces TPU que de GPU, ce qui augmente la complexité.