Faire tourner un modèle d'IA de grande envergure est devenu moins une prouesse scientifique qu'un problème mathématique brutal lié aux factures d'électricité et au loyer des centres de données. Chaque token généré par Gemini coûte réellement quelque chose à Google : des cycles de silicium, de la bande passante mémoire et des watts prélevés sur le réseau. À mesure que le volume de requêtes augmente, des fractions de centime s'accumulent pour former des sommes capables d'engloutir entièrement les marges. Cette urgence silencieuse est à l'origine de Frozen v2, un projet interne de puce pour serveurs qui prend désormais forme au sein de Google. Plutôt que de perfectionner ses Tensor Processing Units à usage général pour une nouvelle génération, l'entreprise tente quelque chose de bien plus radical : mouler le squelette du modèle Gemini directement dans le silicium lui-même.

Des accélérateurs flexibles au silicium spécifique aux modèles

Les TPU de Google sont les piliers de son infrastructure depuis près d'une décennie. Ils entraînent des modèles, alimentent les algorithmes de classement de recherche et sont même loués à l'heure à des clients cloud, dont Meta et d'autres cherchant une alternative aux GPU de Nvidia. Cette polyvalence est précisément ce qui fait d'un TPU un TPU. Il utilise un vocabulaire général de multiplication de matrices et de mouvement de mémoire, utilisable par presque n'importe quel réseau neuronal que l'on peut décrire par logiciel.

Frozen v2 sacrifie délibérément cette flexibilité. La puce est conçue comme un accélérateur spécifique à un domaine dont les circuits reflètent physiquement des parties de l'architecture même de Gemini. Là où un TPU récupère des instructions et les interprète comme des opérations logicielles, Frozen v2 graverait le plan structurel du modèle — l'agencement de ses couches et de ses chemins de données — directement dans la configuration de la puce. Google s'attend à ce que ce mariage étroit entre le modèle et le métal rende la puce six à dix fois plus efficace que les TPU actuels pour fournir des réponses d'IA. Moins d'étapes de calcul par requête signifie moins de temps d'attente pour l'apparition d'un token, et beaucoup moins d'énergie dépensée pour le générer.

Il ne s'agit pas simplement d'une version plus rapide de la même idée. C'est une catégorie de puce différente, qui troque la généralité contre un dévouement total à une seule famille de modèles.

Pourquoi le premier « Frozen » a fondu

Cette approche puise ses racines dans un concept antérieur attribué à Jeff Dean, Chief Scientist chez Google DeepMind. La proposition originale de « Frozen » suggérait d'aller encore plus loin dans la spécialisation en codant en dur non seulement l'architecture, mais aussi les poids réels du modèle — les milliards de paramètres ajustés qui constituent le comportement appris de Gemini — directement dans la puce elle-même.

La logique était solide. Si vous savez exactement quels nombres le modèle utilisera, pourquoi s'embêter à les récupérer dans une mémoire externe ? On pourrait les graver dans les transistors et éliminer des catégories entières de latence.

Le problème était la permanence. Les modèles d'IA ne sont pas statiques. Google met à jour Gemini en continu, en le réentraînant sur de nouvelles données, en ajustant les paramètres et en publiant des versions améliorées. Une puce dont les poids seraient figés dans le silicium deviendrait un presse-papier dès qu'une nouvelle révision du modèle serait déployée. Ce manque de flexibilité a tué le concept original.

Une architecture sans l'ancre

Frozen v2 résout le piège de l'obsolescence en codant l'architecture en dur tout en laissant les poids libres de changer. Voyez cela comme la construction d'une piste de course sur mesure plutôt que de souder la voiture à la route. La forme du circuit reste fixe, optimisée pour les schémas de calcul spécifiques de Gemini, mais le contenu circulant dans ces circuits peut être renouvelé en chargeant de nouveaux poids depuis la mémoire.

Cette distinction est cruciale en pratique. Lorsque les ingénieurs entraînent un nouveau checkpoint Gemini, ils peuvent le déployer sur le matériel Frozen v2 sans fabriquer une nouvelle puce. Le degré exact de codage en dur reste une question ouverte chez Google ; les équipes doivent décider précisément quels éléments structurels méritent l'immortalité du silicium et lesquels doivent rester configurables. Mais le principe est établi. En figeant la forme et en échangeant les paramètres de manière fluide, Google conserve l'avantage de l'efficacité sans sacrifier la capacité d'itération.

L'économie du maintien en interne

Il existe une autre raison pour laquelle vous ne verrez pas Frozen v2 sur la grille tarifaire de Google Cloud. Comme la puce est si étroitement façonnée autour de l'architecture interne de Gemini, elle n'aurait que peu d'intérêt pour des développeurs externes utilisant PyTorch ou des variantes personnalisées de Transformer. Google n'a pas l'intention de la vendre comme un produit à usage général. Elle restera un outil interne, ciblant directement la demande écrasante de capacité d'inférence au sein des propres centres de données de Google.

Ce choix reflète une réalité économique brutale. Sur le marché actuel de l'IA générative, les capacités des modèles convergent rapidement. L'écart entre les concurrents se résume souvent à savoir qui peut se permettre d'exécuter le plus grand modèle au coût par token le plus bas. L'inférence n'est plus une simple réflexion après coup par rapport à l'entraînement ; pour un produit largement utilisé comme Gemini, c'est la dépense dominante. Si Frozen v2 réduit cette dépense d'un facteur six ou plus, Google gagne une marge de manœuvre que les concurrents ne peuvent pas facilement égaler. Elle peut soit empocher les économies sous forme de marge, soit les répercuter par des prix plus bas pour les consommateurs d'API et les intégrations de produits, serrant ainsi la vis à OpenAI, Anthropic et aux autres.

Ce que cela signifie pour l'industrie

La décision de Google laisse également entrevoir la direction que prend la stratégie matérielle globale. Pendant des années, la stratégie standard consistait à construire l'accélérateur le plus flexible possible et à laisser le logiciel gérer la spécialisation. Les GPU de Nvidia dominent car ils font tourner tout, de la dynamique moléculaire aux jeux vidéo en passant par les grands modèles de langage. Les propres TPU de Google ont été conçus dans ce même esprit d'utilité généraliste.

Frozen v2 rompt avec cette tradition. C'est l'aveu que lorsqu'une seule famille de modèles génère un volume de requêtes suffisant, un silicium personnalisé adapté à ce modèle peut être rentabilisé de nombreuses fois. D'autres hyperscalers ont suivi une logique similaire — les puces Trainium et Inferentia d'Amazon, par exemple — mais l'approche de Google va plus loin en co-concevant le matériel autour d'une architecture de modèle spécifique plutôt que d'une classe générale de réseaux.

Le risque, bien sûr, est la rigidité. Si l'architecture de Gemini évolue dans une direction que les circuits codés en dur ne peuvent pas prendre en charge, Google pourrait se retrouver avec un silicium coûteux incapable d'exécuter ses dernières idées. C'est précisément pourquoi le compromis axé uniquement sur l'architecture est important. Il offre une voie médiane : suffisamment de spécialisation pour réaliser des gains d'efficacité spectaculaires, et suffisamment de flexibilité pour éviter de mettre l'entreprise dans une impasse.

La véritable conclusion

Frozen v2 doit être compris non pas comme l'annonce d'une puce, mais comme un pari stratégique sur la forme future de la compétition dans l'IA. Google parie que les gagnants ne se contenteront pas de construire les meilleurs modèles, mais qu'ils posséderont l'intégralité de la stack — du schéma du modèle jusqu'aux électrons circulant dans le transistor. Si le projet réussit, le bénéfice ne se traduira pas par des scores de benchmark. Il apparaîtra dans la colonne des coûts d'un rapport de résultats trimestriels, où quelques centimes économisés par million de tokens peuvent redéfinir les limites de ce qui est commercialement possible dans l'IA générative.