En bref

Les TPU (Tensor Processing Units) sont des puces conçues par Google spécifiquement pour les calculs de réseaux de neurones. Présentés en 2015, déployés en production en 2016, ils sont aujourd’hui à la septième génération. Leur architecture — le systolic array — diffère fondamentalement des GPU. Cette différence explique à la fois leurs performances exceptionnelles dans les conditions Google et les frictions importantes pour les utilisateurs extérieurs.

Pourquoi Google a construit ses propres puces

En 2013, les ingénieurs de Google ont constaté qu’une adoption massive des réseaux de neurones pour la reconnaissance vocale doublerait les besoins en capacité de calcul de leurs datacenters. Acheter suffisamment de GPU Nvidia pour absorber cette charge représentait un coût prohibitif. La décision est prise : concevoir une puce dédiée, optimisée pour une seule opération — la multiplication matricielle.

Le résultat est le TPU v1, déployé en 2016. Son objectif n’est pas d’être polyvalent : il est fait pour l’inférence, et pour rien d’autre. Cette spécialisation radicale est le fil conducteur de toute la famille TPU.

L’analogie qui explique l’architecture

Un GPU ressemble à un atelier multi-tâches : des centaines de cœurs indépendants, chacun capable d’exécuter des instructions différentes, coordonnés par un ordonnanceur. Flexible, généraliste, adapté à une grande variété de charges.

Un TPU fonctionne comme une chaîne de production industrielle. Au cœur du dispositif : le systolic array, une grille de 256×256 unités de multiplication-accumulation (MACs). Les données y circulent dans un flux synchronisé, de cellule en cellule, sans jamais avoir besoin d’être rechargées depuis la mémoire. Chaque cellule reçoit un résultat partiel, l’enrichit, et le transmet à la suivante.

Cette organisation élimine la quasi-totalité des accès mémoire qui ralentissent les GPU sur les opérations matricielles denses. Quand la charge de travail est prévisible et répétitive — comme l’est une passe forward dans un transformer — la chaîne de production surpasse l’atelier multi-tâches par une large marge.

La contrepartie est symétrique : si la charge s’écarte du schéma prévu, la chaîne se grippe. Les opérations irrégulières, les graphes de calcul dynamiques, les noyaux non optimisés — tout ce qui casse le flux — se traduisent par une sous-utilisation sévère du matériel.

Une ligne de temps en sept générations

TPU v1 (2016) — Inférence uniquement. Précision int8. 92 TOPS à 40 W. Jouppi et al. (2017, ISCA) mesurent des gains de 15 à 30× sur les benchmarks d’inférence par rapport aux CPU et GPU contemporains pour des charges de production Google.

TPU v2 (2017) — Première génération capable d’entraînement. Précision bfloat16, le format numérique que Google popularisera ensuite dans tout le secteur. 45 TFLOPS. Introduction des pods : 64 chips interconnectés.

TPU v3 (2018) — 420 TFLOPS. Refroidissement liquide introduit pour absorber la densité thermique. Pods de 1024 chips.

TPU v4 (2021-2022) — Deux innovations structurantes. L’OCS (Optical Circuit Switch) permet de reconfigurer dynamiquement la topologie du réseau entre chips via des connexions optiques — une première dans l’industrie. Les SparseCores accélèrent les opérations sur embeddings (tables de lookup éparses), avec des gains de 5 à 7× sur ces charges spécifiques. Performances globales : 2,1× vs v3, 1,2 à 1,7× vs A100 selon Jouppi et al. (2023, ISCA). L’entraînement de PaLM mobilise 6144 TPU v4.

TPU v5e / v5p (2023) — Deux profils distincts. Le v5e cible l’efficience à l’inférence. Le v5p cible le scale à l’entraînement : c’est la puce utilisée pour Gemini Ultra.

Trillium v6 (2024) — 4,7× les performances du v5e. Le systolic array reste à 256×256 MACs. L’amélioration vient principalement de la fréquence et de la mémoire.

Ironwood v7 (2025) — Pari sur l’inférence pure. 4614 TOPS. 192 Go de HBM3 par chip. Pods de 9216 chips. L’absence annoncée de capacités d’entraînement continu sur cette génération reflète un choix stratégique : Google anticipe que les workloads de production resteront dominés par l’inférence à grande échelle.

Scale-out : la topologie comme avantage

Un TPU isolé est déjà performant. Mais l’avantage systémique de Google réside dans la mise en réseau. Les chips TPU v4 et suivants communiquent via l’ICI (Inter-Chip Interconnect), organisé en tore 3D. Cette topologie permet une bande passante très élevée entre chips proches, et une latence maîtrisée sur des configurations à plusieurs milliers de chips.

Le multislice, introduit pour les générations récentes, permet de découper un pod en tranches indépendantes pour des jobs de tailles différentes, et de les recomposer dynamiquement. PaLM et Gemini n’auraient pas pu être entraînés sans cette infrastructure.

Nvidia propose des solutions comparables — NVLink, NVSwitch, InfiniBand — mais l’intégration verticale de Google (puces + réseau + datacenter + système d’exploitation) donne un avantage de bout en bout difficile à répliquer hors de ce contexte.

La tension : puissance interne, friction externe

C’est ici que l’image se complique. Les performances publiées par Google sont réelles — mais elles s’obtiennent dans des conditions que la grande majorité des utilisateurs ne reproduiront pas.

L’écosystème JAX/XLA

Les TPU sont conçus pour JAX et son compilateur XLA. JAX est le framework de recherche de Google : performant, élégant pour l’algèbre linéaire, mais avec une courbe d’apprentissage abrupte pour quiconque vient de PyTorch. XLA compile les graphes de calcul et les optimise pour le matériel cible — c’est lui qui tire parti du systolic array.

PyTorch est supporté via torch_xla, mais cette couche d’abstraction introduit des contraintes. Certains opérateurs ne sont pas pris en charge nativement. FlashAttention — l’optimisation d’attention devenue standard dans l’industrie — a mis plusieurs années à être portée efficacement sur TPU, là où elle était disponible sur GPU dès ses premières versions. La dépendance à JAX n’est pas un détail de configuration : c’est un prérequis structurant.

L’asymétrie d’accès

Google utilise les TPU en interne sans passer par Cloud TPU. Les configurations déployées pour PaLM ou Gemini ne sont pas disponibles à l’achat. Ce que Google vend sur Cloud TPU est une version de l’infrastructure interne, avec des limitations de topologie, de durée d’allocation et de surface de configuration.

Pour un laboratoire qui veut entraîner un modèle de 70 milliards de paramètres sur TPU v5p, la disponibilité des pods, la gestion des préemptions et la configuration réseau représentent un investissement opérationnel significatif — là où les GPU H100 sur AWS ou Azure s’inscrivent dans des workflows mieux documentés et plus portables.

CUDA vs XLA comme fossé d’écosystème

CUDA n’est pas seulement un framework : c’est vingt ans d’optimisations accumulées, de bibliothèques tierces, de tutoriels, de profilers. XLA est plus jeune, moins bien outillé pour le débogage, et la communauté qui l’entoure est plus restreinte. La majorité des papiers de recherche publie du code PyTorch/CUDA. Reproduire ces résultats sur TPU demande un effort de portage non trivial.

Ce fossé tend à se réduire — Google investit sur la documentation et l’outillage, et JAX gagne en popularité dans certaines communautés de recherche. Mais en 2026, l’écart reste réel.

Ce qu’il faut retenir

  • Les TPU reposent sur le systolic array : un flux de données synchronisé qui élimine les allers-retours mémoire sur les opérations matricielles denses. Très efficace pour des charges prévisibles, rigide pour les autres.
  • Sept générations en dix ans, des gains mesurés de 15-30× (v1 vs CPU/GPU 2016) à 4614 TOPS (Ironwood v7, 2025). Chaque génération a apporté une innovation structurante : bfloat16 (v2), pods (v2), OCS (v4), SparseCores (v4).
  • L’avantage réel de Google n’est pas une puce isolée — c’est l’intégration verticale : puce + interconnect ICI en tore 3D + datacenter + compilateur XLA.
  • L’écosystème reste centré sur JAX/XLA. PyTorch est supporté mais avec friction. FlashAttention et d’autres optimisations standard ont été longtemps indisponibles ou sous-performantes sur TPU.
  • La majorité des performances publiées s’obtient dans des conditions internes inaccessibles via Cloud TPU. Pour les utilisateurs externes, le ratio performance/effort opérationnel reste inférieur à ce que laissent entendre les benchmarks Google.

Sources