Petits modèles dévorant les budgets GPU par préallocation

Les petits modèles devaient réduire les coûts. En pratique, quatre instances vLLM occupent souvent quatre GPU, car chaque moteur réserve la majeure partie de la mémoire à l’avance. Le goulot d’étranglement n’est pas la carte. C’est la pile de serving.

Les points clés en bref

En relation :Le chargement du modèle engloutit l’heure TPU coûteuse  /  Kimi K3 : quand l’IA construit sa propre infrastructure

Quatre modèles, quatre cartes, une erreur de raisonnement

Les rapports FinOps montrent alors une augmentation des coûts GPU malgré des modèles « plus petits ». L’histoire racontée au steering committee semble paradoxale. Dans les métriques des nœuds, elle est banale : quatre processus, quatre allocations, quatre factures. Sans discipline de packing, la spécialisation des modèles devient un facteur de coût plutôt qu’un levier d’économie.

Les équipes décomposent la pile d’agents en spécialistes : embedding, rerank, structured extraction, generation. Chaque élément est petit. Pourtant, chaque instance vLLM ou TEI se comporte comme le propriétaire exclusif du GPU. Celui qui alloue 90 % de la VRAM au démarrage ne laisse aucune place au voisin. Le résultat est une multiplication du matériel malgré des « small models ».

L’inférence serverless ne résout cela qu’en apparence. Des cold starts de plusieurs dizaines de secondes, voire approchant la minute, sont mortels pour un reranker dans le pipeline de recherche. Les warm pools coûtent à nouveau en idle. On-prem ou GPU réservés sans shared serving représentent la version coûteuse de la même faille.

Ce dont l’inférence partagée a vraiment besoin

Un processus serveur qui connaît plusieurs modèles. Chargement à la première utilisation. Éviction LRU lorsque la mémoire devient critique. Pas de dogme un processus par modèle. Les projets open source et les routeurs d’inférence commerciaux visent précisément cela. Le nom du projet est interchangeable. La question architecturale demeure : qui possède le memory scheduler ?

Les équipes platform devraient fixer trois SLO. Premièrement, la latence p95 par type d’outil. Deuxièmement, la marge de VRAM sous charge. Troisièmement, l’euro par million de tokens sur l’ensemble de la pile, et non par modèle individuel dans des conditions idéales. Sans ces trois chiffres, toute commande de GPU reste une question de feeling.

Règles d’exploitation pour économiser de l’argent

Séparez les charges lourdes en pré-remplissage (prefill) et en décodage (decode) si votre matériel le permet. Utilisez des modèles mis en cache pour les chemins critiques, et un chargement paresseux (lazy load) pour les outils secondaires. Évitez les déploiements fantômes silencieux de deux moteurs complets « juste pour tester » sur des GPU de production. Assurez une observabilité sur les événements de chargement des modèles : chaque chargement représente un pic de coûts et de latence.

Face au chemin d’API cloud, le partage sur la même machine (shared on-box) l’emporte si le trafic est stable et que les données restent résiduelles. Face à un serveur dédié à un seul modèle, le partage de service (shared serving) devient avantageux dès que plus de deux modèles sont constamment sollicités. Face à un Kubernetes naïf avec un pod par modèle, un démon d’inférence avec des quotas clairs est plus efficace.

Kubernetes aggrave souvent le problème lorsque chaque variante d’inférence est déployée comme une instance distincte avec une demande de GPU à 1. Le planificateur voit les demandes de ressources, mais pas le chevauchement des modèles. Sans stratégies de plugin de périphérique et un packing ciblé, des îlots de VRAM inactifs apparaissent à côté de pods en attente.

Un compromis pragmatique pour de nombreuses équipes DACH : un pool de nœuds d’inférence avec un serveur partagé fixe par nœud, précédé d’un routeur léger. Mise à l’échelle automatique au niveau du nœud, et non par pod de modèle. Les modèles à haut QPS (requêtes par seconde) peuvent rester dédiés. Tout le reste est partagé.

Documentez le pire scénario. Que se passe-t-il si le modèle générateur évince le réranker ? Le chemin LRU (Least Recently Used) est-il acceptable ou avez-vous besoin d’un épinglage (pinning) pour les deux modèles principaux ? Sans politique de pinning, le premier pic de trafic se transforme en chaos de latence.

Checklist du lundi

Listez tous les processus d’inférence et leurs demandes de VRAM. Recherchez les poids de base en double. Simulez le cas « réranker + générateur simultanément ». Si cela mobilise deux cartes, vous n’avez pas un problème de capacité, mais un problème de packing. Résolvez-le avant de passer la prochaine commande.

Foire aux questions

Source de l’image : générée par IA (juillet 2026)