La taille d’un modèle ne suffit pas à prévoir son comportement sous forte charge. Dans un benchmark publié le 5 septembre 2026, Google Cloud compare Gemma 3 12B et Gemma 3 27B sur un TPU v6e et observe des profils nettement différents selon la tâche exécutée : classification de texte ou génération.
Deux charges qui ne sollicitent pas l’infrastructure de la même manière
Les tests ont été réalisés sur Google Kubernetes Engine Autopilot, avec un pool de nœuds TPU v6e à hôte unique configuré selon une topologie de 2 × 2 puces. Le service s’appuyait sur vLLM via le plugin vllm-project/tpu-inference. Les deux modèles ont été évalués avec 16, 32, 64 et 128 utilisateurs simultanés.
La classification utilisait environ 4 000 tokens en entrée et près de 10 tokens en sortie, dans le cadre d’un contrôle de conformité pour le commerce en ligne. La génération partait d’un prompt de 500 tokens, mais produisait environ 1 000 tokens pour une note consacrée à l’avenir de l’IA sur le marché du travail.
La première charge correspond donc à une lecture longue suivie d’une réponse très courte. La seconde demande au système de produire une sortie beaucoup plus importante pour chaque requête. Cette différence pèse directement sur la capacité observée lorsque le nombre d’utilisateurs augmente : un même modèle et un même accélérateur peuvent présenter une courbe différente selon la quantité de texte à traiter et à générer.
Google Cloud a conservé plusieurs paramètres de service identiques, dont max-model-len=128000, max-num-batched-tokens=8192 et max-num-seqs=512. Les résultats décrivent donc ce cadre de fonctionnement précis. Ils ne permettent pas de classer universellement Gemma 3 12B et Gemma 3 27B dans tous les scénarios.
La génération accentue l’écart entre les deux modèles
À 128 utilisateurs simultanés, Gemma 3 12B a atteint un multiplicateur de débit normalisé de 8,19× lors du test de génération. La référence utilisée était le débit de Gemma 3 12B avec 16 utilisateurs. Gemma 3 27B a atteint 4,12× dans la même comparaison.
Sur cette charge, le multiplicateur relatif du modèle 27B représente ainsi environ la moitié de celui du 12B. Ce résultat ne mesure pas seulement une différence de taille : il montre surtout que la production d’une sortie d’environ 1 000 tokens modifie fortement la façon dont la capacité évolue avec la concurrence.
La classification présente un écart beaucoup plus limité. Gemma 3 12B atteint 6,37×, contre 6,04× pour Gemma 3 27B au même niveau de concurrence. Le benchmark ne dit donc pas que le modèle 12B est toujours plus rapide. Il montre que le profil de la tâche peut réduire ou accentuer l’écart apparent entre les deux modèles.
Le débit doit être lu avec la latence
La montée en charge fait aussi apparaître une contrainte distincte : le temps de réponse. Pour la classification avec Gemma 3 12B, la latence normalisée de bout en bout passe de 0,99× à 32 utilisateurs à 1,79× à 64 utilisateurs, puis à 2,90× à 128 utilisateurs.
Google Cloud avertit qu’une saturation du matériel peut provoquer une forte hausse de la latence et entraîner l’abandon silencieux de requêtes. Un système capable de traiter davantage de demandes n’est donc pas automatiquement plus exploitable si les réponses arrivent trop tard ou si certaines requêtes disparaissent sans signal clair.
Pour une équipe qui dimensionne un service LLM, le choix se joue entre capacité et prévisibilité. Le débit normalisé aide à comprendre comment l’infrastructure absorbe la concurrence, tandis que la courbe de latence indique à partir de quel niveau cette capacité devient difficile à utiliser.
La portée du benchmark reste limitée aux deux modèles Gemma, à la configuration TPU v6e, au service vLLM et aux profils de charge décrits. D’autres prompts, modèles, topologies matérielles ou schémas de trafic nécessiteraient des mesures séparées.
La conclusion opérationnelle est claire : classification et génération doivent être évaluées séparément avant un déploiement. Le modèle qui évolue le mieux sur une tâche courte n’a pas nécessairement le même comportement lorsqu’il doit produire une réponse longue, et le débit seul ne suffit pas à garantir un service stable sous forte concurrence.