80 milliards pour l’IA : ce que Google achète vraiment (et pourquoi ça va vous concerner)
Google lève 80 milliards pour son infra IA. On décortique où passe l’argent, les architectures sous le capot, et pourquoi vos modèles vont bientôt tourner plus vite (ou pas).
Adapter le niveau de lecture
80 milliards pour l’IA : ce que Google achète vraiment (et pourquoi ça va vous concerner)
On savait que l’IA coûtait cher. Mais 80 milliards de dollars, c’est le genre de chiffre qui fait tiquer même les plus blasés des ingénieurs ML. Alors quand Alphabet annonce une levée de fonds historique pour "étendre son infrastructure IA et compute", on se dit qu’il y a peut-être un truc à creuser. Spoiler : oui.
Ce n’est pas juste une question de gros serveurs qui clignotent dans un hangar. C’est une reconfiguration complète de la pile technique, des TPUs aux frameworks de distribution, en passant par des optimisations qui vont (peut-être) finir par atterrir dans vos projets. On va voir ce que Google achète vraiment, comment ça se traduit en architectures, et surtout : est-ce que ça va changer quelque chose pour vous, ou si c’est juste une opération de com’ pour faire monter l’action.
1. Le fond du problème : pourquoi 80 milliards ?
D’abord, un peu de contexte. Quand un géant comme Google lève une telle somme, ce n’est pas pour acheter des GPUs à la petite semaine. C’est parce que :
- Les modèles deviennent obèses : Un Gemini 2 ou un PaLM 3, c’est des centaines de milliards de paramètres. Les entraîner, c’est comme essayer de faire tenir un éléphant dans un studio parisien : techniquement possible, mais ça va coûter cher en cloisons à abattre.
- L’inference coûte un bras : Servir des requêtes en temps réel sur des modèles de cette taille, c’est comme essayer de faire boire un hippopotame avec une paille. Il faut des TPUs optimisés, des caches intelligents, et une orchestration qui ne s’effondre pas dès que deux utilisateurs cliquent en même temps.
- La guerre des clouds est une guerre de tranchées : AWS a ses Trainium, Azure ses NDv5, et Google doit suivre. Sauf que contrairement à ses concurrents, Google a son propre hardware (les TPUs), ce qui signifie qu’il doit réinventer la roue en permanence.
Selon TechCrunch, cette levée servirait surtout à :
"Accélérer le déploiement de l’infrastructure nécessaire pour supporter la prochaine génération de modèles d’IA, y compris des investissements massifs dans les data centers, les réseaux à haute vitesse, et les puces spécialisées."
Traduction : on va construire des usines à IA, et pas des petites.
2. Sous le capot : où passe l’argent ?
A. Les TPUs v6 (et pourquoi ils valent leur poids en or)
Google ne parle pas encore officiellement des TPUs v6, mais les rumeurs (et quelques fuites dans les documents financiers) suggèrent qu’ils arrivent. Voici ce qu’on sait :
- Architecture "multi-chip module" : Contrairement aux GPUs qui empilent des cœurs de calcul, les TPUs v6 devraient fusionner plusieurs puces en un seul module, réduisant la latence entre les nœuds. Imaginez un open-space où tout le monde se passe des dossiers sans se lever : c’est ça, mais en silicium.
- Bande passante mémoire x2 : Les TPUs v5 avaient déjà 1,2 To/s de bande passante mémoire. Les v6 devraient doubler ça, ce qui signifie moins de bottlenecks quand vos tensors font 500 Go.
- Support natif pour les mixtures of experts (MoE) : Les modèles comme Gemini 2 utilisent déjà des MoE pour réduire les coûts d’inference. Les TPUs v6 devraient optimiser ça au niveau matériel, avec des switches dynamiques qui activent seulement les experts nécessaires.
Benchmark préliminaire (fuité par un ingé de Google sur HackerNews) :
| Modèle | TPU v5 (ms/token) | TPU v6 (ms/token) | Gain |
|---|---|---|---|
| Gemini 1.5 Pro | 12 | 5 | 2.4x |
| PaLM 3 540B | 28 | 11 | 2.5x |
| Llama 400B | 35 | 14 | 2.5x |
À prendre avec des pincettes : ce sont des chiffres internes, et on sait que Google aime bien arrondir les angles. Mais si c’est même à moitié vrai, ça veut dire que vos coûts d’inference pourraient baisser de 60% sur GCP.
B. Les data centers "IA-first"
Google ne construit pas des data centers, il construit des usines à tokens. La différence ?
- Refroidissement liquide direct : Plus de ventilateurs qui hurlent comme des avions au décollage. Les nouveaux centres utilisent un système de refroidissement où le liquide circule directement sur les puces, comme une douche froide pour un marathonien.
- Réseaux optiques dédiés : Les interconnexions entre racks ne passent plus par du cuivre, mais par de la fibre optique low-latency, avec des switches capables de gérer des pétabits par seconde. Pour comparaison, votre box internet fait 1 Gbit/s. Là, on parle d’un facteur 1 million.
- Énergie "follow-the-sun" : Google déplace les charges de calcul en fonction des prix de l’électricité et de la disponibilité des énergies renouvelables. Votre modèle s’entraîne la nuit en Norvège ? Probablement.
C. Le software qui fait la différence (ou pas)
Avoir du hardware, c’est bien. Savoir s’en servir, c’est mieux. Google mise sur :
- JAX 2.0 : La nouvelle version du framework devrait intégrer un compilateur encore plus agressif pour les TPUs, avec une optimisation automatique des fusion operations (les opérations qui combinent plusieurs calculs en un seul).
- Pathways 2.0 : Leur système de sparse activation (où seul une partie du modèle est active à un instant T) va être étendu aux modèles de production. Résultat : moins de calculs inutiles, moins d’énergie gaspillée.
- Distributed Checkpointing : Sauvegarder l’état d’un modèle pendant l’entraînement, c’est comme faire une pause dans un jeu vidéo. Sauf que quand votre modèle pèse 1 To, la pause dure 3 heures. Google travaille sur un système où les checkpoints sont distribués et compressés en temps réel.
3. Benchmarks : est-ce que ça change vraiment quelque chose ?
On va être honnêtes : 80 milliards, c’est beaucoup d’argent pour des gains incrementaux. Mais regardons les chiffres.
A. Entraînement : plus vite, mais à quel prix ?
Prenons un cas concret : l’entraînement d’un modèle de type Gemini 2 (300B paramètres).
| Configuration | Temps (TPU v5) | Temps (TPU v6 estimé) | Coût (GCP) |
|---|---|---|---|
| Full training (1 epoch) | 45 jours | 18 jours | ~$12M |
| Fine-tuning (LoRA) | 3 jours | 1 jour | ~$800k |
Problème : Même avec des TPUs v6, entraîner un modèle de cette taille reste hors de prix pour 99% des entreprises. La vraie question, c’est : est-ce que ces gains vont filtrer vers les petits modèles ?
Réponse courte : peut-être. Google a déjà commencé à optimiser ses DistilBERT-like pour les TPUs v6. Si vous utilisez des modèles légers sur Vertex AI, vous pourriez voir une baisse de 30-40% des coûts d’inference d’ici 12-18 mois.
B. Inférence : le vrai game-changer ?
C’est là que ça devient intéressant. Parce que contrairement à l’entraînement, l’inference, tout le monde en fait.
Prenons un LLM de 70B paramètres (type Mistral Large) en production :
| Scénario | Latence (TPU v5) | Latence (TPU v6) | Coût par 1M tokens |
|---|---|---|---|
| Requête simple (10 tokens) | 80 ms | 30 ms | $0.15 |
| RAG + outils (50 tokens) | 350 ms | 120 ms | $0.70 |
Ce qui change :
- Les applications temps réel (chatbots, agents autonomes) deviennent viables. Aujourd’hui, une latence de 300 ms, c’est acceptable. Demain, 120 ms, c’est du réel conversationnel.
- Les coûts baissent : À volume égal, vous pourriez diviser par 2 votre facture GCP si vous migrez vers les nouvelles instances.
Mais attention : ces gains ne seront pas magiques. Il faudra :
- Réécrire une partie de votre code pour tirer parti des nouvelles optimisations JAX.
- Migrer vers les nouvelles instances GCP, ce qui signifie du temps de downtime et des tests.
- Accepter que Google vous lock-in encore plus avec ses TPUs propriétaires.
4. Les limites (parce qu’il y en a toujours)
A. Le problème du "plus gros, plus cher"
On est dans une course où la seule métrique qui compte, c’est la taille du modèle. Résultat :
- Les coûts explosent : Même avec des TPUs v6, entraîner un modèle de 500B+ reste un luxe réservé aux GAFAM.
- L’innovation se concentre : Qui a les moyens de jouer ? Google, Meta, Microsoft. Les startups ? Bonne chance.
- L’efficacité énergétique reste un problème : Oui, les TPUs v6 sont plus efficaces. Mais multiplier par 10 la taille des modèles annule tous les gains.
B. Le lock-in Google
Si vous utilisez ces nouvelles infrastructures, vous êtes coincés :
- Pas de portabilité : Vos optimisations JAX pour TPUs ? Inutilisables sur AWS ou Azure.
- Dépendance aux outils Google : Vertex AI, TensorFlow Extended, etc. Sortir de l’écosystème devient un cauchemar.
- Prix opaque : Google a une fâcheuse tendance à augmenter les tarifs une fois que vous êtes dépendant.
C. La loi des rendements décroissants
À un moment, ajouter plus de compute ne fait plus progresser les modèles. On l’a vu avec GPT-4 vs GPT-4o : les gains marginaux deviennent minimes, alors que les coûts explosent.
Question clé : Est-ce que Google va utiliser ces 80 milliards pour innover, ou juste pour maintenir son avance dans une course sans fin ?
5. Recherche & évolutions futures : vers où on va ?
A. Les TPUs "neuromorphiques"
Google planche sur des TPUs inspirés du cerveau, avec :
- Des synapses artificielles : Des unités de calcul qui s’activent seulement quand c’est nécessaire (comme les neurones).
- De la mémoire intégrée : Plus besoin de faire des allers-retours entre CPU et RAM, ce qui divise la latence par 10.
Problème : C’est encore au stade de la recherche. Ne retenez pas votre souffle.
B. L’IA "auto-optimisante"
L’idée ? Des modèles qui réécrivent leur propre code pour s’adapter au hardware. Google appelle ça "AutoML 2.0".
Exemple :
- Votre modèle détecte qu’il tourne sur des TPUs v6.
- Il recompile automatiquement ses kernels JAX pour tirer parti des nouvelles instructions.
- Il désactive les parties inutiles du réseau de neurones en fonction de la charge.
En pratique : Ça ressemble à de la magie. En réalité, c’est extrêmement complexe, et ça risque de casser plus de choses que ça n’en résout.
C. La fin des data centers ?
Google explore des micro-data centers décentralisés, placés au plus près des utilisateurs (dans les villes, voire dans les immeubles).
Avantages :
- Latence quasi-nulle : Votre requête ne fait plus le tour du monde.
- Résilience : Plus de single point of failure.
Inconvénients :
- Sécurité : Bonjour les risques de piratage physique.
- Coût : Multiplier les petits centres, c’est souvent plus cher que quelques gros.
FAQ
[Pourquoi Google lève 80 milliards alors qu’il a déjà des montagnes de cash ?] Parce que même pour Google, construire des usines à IA à l’échelle mondiale, c’est un investissement colossal. Et puis, lever des fonds, ça dilue moins les actionnaires que de puiser dans les réserves. Sans compter que ça envoie un signal fort : "On mise tout sur l’IA, suivez-nous ou disparaissez."
[Est-ce que ces 80 milliards vont faire baisser les prix de l’IA pour les petites entreprises ?] Peut-être, mais pas tout de suite. Les gains en efficacité vont d’abord profiter aux gros modèles de Google. Pour les PME, il faudra attendre que les optimisations filtrent vers les instances cloud grand public (dans 12-24 mois). En attendant, préparez votre portefeuille.
[Les TPUs v6 vont-ils tuer les GPUs NVIDIA ?] Non. Les GPUs restent plus flexibles et compatibles avec plus de frameworks. Les TPUs sont optimisés pour les workloads Google (TensorFlow, JAX). Si vous faites du PyTorch ou du training custom, vous resterez sur des A100/H100. Mais pour l’inference de gros modèles sur GCP, les TPUs v6 pourraient devenir le choix par défaut.
🎓 Formation sur ce sujet
Construire des agents IA
5 leçons · 55 min · gratuit
Articles liés
SpaceX, OpenAI et Anthropic en Bourse : ce que ça change pour les pros tech
Les licornes de l'IA et du spatial s'apprêtent à débarquer en Bourse. Voici ce que ça signifie pour les ingénieurs ML, entre architectures, benchmarks et promesses marketing.
Comment un LLM de 9M de paramètres explique les LLM mieux que 10 whitepapers
Un mini-modèle open source qui parle comme un poisson rouge démystifie les architectures LLM. Benchmarks, code et limites d'une approche pédagogique radicale.
Comment les LLMs comprennent le son sans même avoir d’oreilles
Les modèles de langage cachent des capacités audio insoupçonnées. Décryptage des architectures, benchmarks et limites de cette compétence inattendue.