Success Stories

Le magasin de modèles engloutit l’heure coûteuse de TPU

Lors de l'inférence d'IA sur GKE avec des TPU, le chargement du modèle est le moment le plus coûteux.

Par Alec Chizhik 11 juillet 2026 6 min de lecture

Le magasin de modèles engloutit l’heure coûteuse de TPU

Sur une VM TPU à quatre puces, chaque minute coûte de l’argent. Lorsque Google a mis plus de dix minutes à rendre un modèle de 449 gigaoctets opérationnel dans un benchmark documenté, le nœud a payé pour une puissance de calcul qui n’effectuait encore aucun calcul. C’est précisément ce moment de démarrage qui détermine la facture cloud réelle pour l’inférence d’IA sur Google Kubernetes Engine.

Les points clés en bref

Le chargement est le principal facteur de coût. Pour un modèle de 480 milliards de paramètres, le temps de chargement sur une TPU est passé de plus de 630 à moins de 280 secondes dès que les poids ont été streamés directement depuis le stockage objet plutôt que via le détour local.
La mémoire hôte est divisée par deux. Le chemin de chargement classique occupait jusqu’à 881 gigaoctets de RAM hôte, tandis que le streaming s’est contenté de 436. La différence représente un budget réservé que le pool de nœuds doit autrement maintenir en permanence.
La cause réside dans l’architecture. Les nœuds TPU n’ont pas de SSD locaux. Le chemin de chargement classique occupe temporairement le double de la taille du modèle en mémoire vive. Ignorer ce point se paie par du surprovisionnement et une mise à l’échelle lente.

En lien :FinOps Kubernetes : les leviers contre 70 % de gaspillage dans les clusters / 4 % dans le data center, 54 % à la centrale électrique

Pourquoi la coûteuse TPU attend avant de calculer

Un accélérateur coûte à l’heure, qu’il génère des tokens ou charge un modèle en mémoire. Pour les petits modèles, cela passe inaperçu. Mais pour un modèle de plusieurs centaines de gigaoctets de poids, le chargement devient la phase la plus longue du cycle de vie d’un pod.

Cela impacte directement l’autoscaling. Lorsqu’un cluster monte en charge lors de pics, chaque nouveau pod doit d’abord charger son modèle avant de répondre à la première requête. Si cela prend plusieurs minutes, un dilemme se pose : soit la mise à l’échelle réagit trop tard et les utilisateurs attendent, soit l’équipe maintient en permanence une capacité de réserve coûteuse. Les deux solutions consument des heures TPU.

Le calcul est sans appel : un nœud qui charge pendant dix minutes puis travaille une heure perd environ un septième de son temps d’exécution payant dans un processus qui ne produit aucun token.

Le supplément mémoire caché au démarrage

Le chemin de chargement classique sur une TPU passe par la mémoire vive de l’hôte. Le modèle est d’abord entièrement lu dans la mémoire CPU, décomposé pour les puces, puis transféré. Pour les modèles PyTorch sans logique de chargement spécialisée, cela signifie un pic de mémoire d’environ le double de la taille du modèle, car le checkpoint et sa copie préparée coexistent temporairement.

Cette double occupation est le véritable poste de coût. Un pool de nœuds doit être dimensionné pour survivre au pic, pas au fonctionnement normal. La réservation est donc faite pour un moment qui n’intervient qu’au démarrage.

// Pic mémoire lors du chargement

881 Go → 436 Go

Besoin en RAM hôte pour un modèle de 449 Go : chemin de chargement classique vs streaming direct depuis le stockage objet.

Les nœuds TPU sans SSD local imposent un arbitrage

Contrairement à de nombreuses instances GPU, les nœuds TPU ne disposent pas d’un support de stockage local rapide depuis lequel un modèle pourrait être chargé. Les poids proviennent du stockage d’objets ou de volumes attachés. Cela accentue le conflit d’objectifs entre temps de chargement, coûts de stockage et risque qu’un nœud déborde de mémoire au démarrage.

La solution documentée par Google pour ce cas est le Run:ai Model Streamer open source. Il contourne le détour local et pousse les poids en parallèle depuis le stockage d’objets directement dans la mémoire de la puce. Pour le cas général, la documentation indique des temps de chargement jusqu’à six fois plus rapides par rapport aux méthodes conventionnelles. Le cas TPU mesuré ci-dessus se situait autour d’un facteur deux. Le chemin TPU est pris en charge par vLLM à partir de la version 0.18.0.

Important pour la mise en perspective : le saut mesuré au facteur deux s’applique au cas décrit de grands modèles PyTorch. Pour les modèles dont la logique de chargement est déjà optimisée, le gain est plus faible. Si vous planifiez le Streamer, vous devriez vérifier votre propre type de modèle, et non reprendre le chiffre du benchmark.

Quels leviers les équipes plateforme ont réellement

La première décision concerne le chemin de chargement lui-même. Le streaming depuis le stockage d’objets abaisse le pic de mémoire et rend possibles des pools de nœuds plus petits et plus économiques. L’effet est double : disponibilité plus rapide des pods pour la montée en charge, moins de mémoire réservée par nœud.

Le deuxième levier est le cache. Un cache de compilation persistant dans le stockage d’objets raccourcit nettement les démarrages suivants, car la préparation coûteuse ne s’exécute pas à nouveau pour chaque pod. Pour une accélération zonale, un cache en lecture peut être placé devant le stockage d’objets.

Le troisième levier est la planification. Le scale-to-zero réel reste cher sur les TPU, car chaque cold start paie le chargement complet. Pour une charge fluctuante, une élasticité sélective avec des pods de réserve préchauffés est souvent plus avantageuse que le simple scale-up et scale-down. Qui prend au sérieux les coûts d’exploitation de l’infrastructure IA, par exemple dans le contexte du Google Cloud Summit DACH 2026, ne peut pas contourner ce calcul.

Foire aux questions

Qu’est-ce que le Run:ai Model Streamer ?

Le Run:ai Model Streamer est un composant open source qui charge les poids de modèle en parallèle depuis un stockage d’objets tel que Cloud Storage directement dans la mémoire d’un accélérateur. Il contourne le support de stockage local et le détour par la mémoire hôte, ce qui permet aux grands modèles d’être prêts plus rapidement et avec un pic de mémoire plus faible.

Pourquoi le cold start en inférence TPU est-il un problème de coûts ?

Un accélérateur coûte à l’heure, y compris pendant le chargement d’un modèle. Si le chargement dure plusieurs minutes pour de grands modèles, cela retarde la montée en charge et force les équipes soit à réagir lentement, soit à maintenir une capacité de réserve coûteuse. Les deux options augmentent le coût par requête effectivement traitée.

À partir de quelle version de vLLM le Streamer fonctionne-t-il sur TPU ?

Pour le chemin TPU, vLLM en version 0.18.0 ou plus récente est nécessaire. Pour les GPU, le Streamer prend en charge la connexion à Cloud Storage dès la version 0.11.1. Il s’active via un flag supplémentaire dans la commande de démarrage.

Le gain d’un facteur deux s’applique-t-il à chaque modèle ?

Non. La réduction de moitié mesurée du temps de chargement et du pic de mémoire concerne de grands modèles PyTorch qui empruntent le chemin de chargement classique via la mémoire hôte. Les modèles disposant déjà d’une logique de chargement incrémentale en profitent moins. Avant la bascule, un test avec votre propre modèle s’impose.

Comment le temps de chargement du modèle est-il lié à l’autoscaling ?

Chaque pod nouvellement démarré doit charger son modèle avant de répondre aux requêtes. Si cette phase est longue, la montée en charge automatique réagit avec lenteur aux pics de trafic. Des temps de chargement plus courts rendent les pods prêts plus vite, réduisent le besoin de réserve préprovisionnée et améliorent l’utilisation des accélérateurs payés.