Google Cloud a publié un benchmark comparant des charges de travail de classification et de génération sur TPU v6e le 4 septembre à 15:36 UTC. Son principal résultat : « Pour les tâches de génération lourdes en phase de décodage, le modèle Gemma 3 27B atteint un plafond strict de performance au-delà de 64 utilisateurs simultanés, se stabilisant à un multiplicateur de débit normalisé de 4.12x à 128 utilisateurs. En revanche, le modèle 12B monte jusqu’à un multiplicateur de 8.19x. »

La réserve plus bas dans le texte

« À des niveaux de concurrence extrêmes (par exemple, 128 utilisateurs), vous pouvez remarquer des pics mathématiquement anormaux du débit moyen. … Sous de fortes contraintes de ressources, une mauvaise configuration de --max-num-seqs ou de --max-model-len peut entraîner des abandons silencieux de requêtes, des expirations de connexion côté client ou des erreurs OOM des nœuds de travail GKE. Lorsque ces requêtes échouées se terminent immédiatement, elles raccourcissent faussement la durée de session et gonflent artificiellement les métriques de débit. Les points de données à 128 utilisateurs dans ces benchmarks représentent la limite absolue de stabilité du cluster et doivent être considérés comme un plafond plutôt que comme une métrique de production durable. »

Ce que disent les lignes réellement validées

Le tableau de génération pour 16, 32, 64 et 128 utilisateurs affiche 1.00x / 1.98x / 2.96x / 8.19x pour Gemma 3 12B, et 1.05x / 1.97x / 4.00x / 4.12x pour 27B. À 64 utilisateurs simultanés — la dernière ligne que le billet ne renie pas — le modèle le plus grand est le plus rapide, soit l’inverse du titre. Toute la narration du « plafond de performance » repose sur une comparaison de deux chiffres issus de la ligne désavouée.

Ici, rien n’est une mesure absolue

Chaque case est un multiple de Gemma 3 12B à 16 utilisateurs, dans un tableau dont l’en-tête de colonne indique « Throughput (req/s) ». Il n’y a aucun chiffre absolu de requêtes par seconde nulle part, et aucun chiffre de coût — dans un billet dont la phrase d’ouverture porte sur l’économie à l’unité. La configuration repose sur un pool de nœuds TPU v6e mono-hôte dans une topologie de puces 2x2 sur GKE Autopilot, servi par vLLM via tpu-inference, avec max-model-len=128000, max-num-batched-tokens=8192, max-num-seqs=512.

Ce que le cadrage retenu occulte

Cela sera cité comme « TPU v6e délivre 8x ». Il s’agit d’un multiple normalisé, sur un seul nœud, sur une seule pile d’inférence, à un niveau de concurrence que l’éditeur qualifie d’instable et potentiellement faussé par des requêtes perdues. Le billet est d’une franchise inhabituelle — l’avertissement est là, sans atténuation — et cette franchise se trouve dans le paragraphe que personne ne lit. Le tableau de classification, dont les pics de 6.04x à 6.37x proviennent de la même ligne à 128 utilisateurs, présente le même problème.