IA : coût réel ou ressources mal gérées ?

Pourquoi a-t-on l’impression que l’IA “coûte” surtout parce qu’il manque quelque chose, plutôt que parce qu’elle calcule trop ? Dans beaucoup d’organisations, la sensation de pénurie ne vient pas uniquement du nombre de GPU disponibles, mais du fait qu’une partie de leur capacité reste inutilisée, sans que ce soit visible à l’œil nu.

Le nœud du problème, c’est une tension très concrète : l’inférence doit répondre vite et de façon prévisible, alors que les GPU sont des ressources chères, rares, et parfois bloquées par des contraintes de composants. Quand on cherche à éviter les incidents (latence, plantage mémoire), on sur-réserve. Quand on cherche à “remplir” les GPU, on prend le risque inverse. La promesse des outils d’orchestration récents, c’est de rendre ce compromis moins brutal.

Imaginez un parking de livraison devant un entrepôt. Certains camions sont des fourgonnettes (petits modèles d’embeddings), d’autres des semi-remorques (LLM très grands). Si chaque véhicule se voit attribuer une place XXL “au cas où”, le parking paraît plein alors qu’il reste des mètres carrés perdus partout. À l’inverse, si on serre trop, tout le monde se bloque au premier imprévu. Dans l’IA, le parking, c’est la mémoire GPU et le temps de calcul.

Quand la capacité “dort” sans qu’on le voie

Servir des modèles (l’inférence) n’a rien d’un flux homogène. Un petit modèle de recherche sémantique peut consommer seulement quelques gigaoctets de mémoire GPU, tandis qu’un grand modèle avec des dizaines de milliards de paramètres peut réclamer plusieurs GPU. Cette diversité crée un piège : l’allocation la plus simple, “un modèle = un GPU”, évite les surprises… mais laisse une capacité considérable inexploitée.

Ce n’est pas seulement une question de “mettre plus de charges” sur une carte. Le cœur, c’est la planification : comprendre des profils très différents (petites requêtes fréquentes, gros prompts ponctuels, pics de concurrence) et attribuer la bonne part de GPU au bon moment. C’est précisément ce que détaille l’utilisation GPU avec Run:ai, utile parce que le texte met des mots sur ce que beaucoup vivent : soit on sur-provisionne pour tenir les SLA, soit on sous-provisionne et la latence devient imprévisible.

Dans un contexte de coûts élevés et de tension sur les composants, ce gaspillage devient vite un sujet “finance” autant qu’un sujet “machine learning”. Si un cluster semble saturé, le réflexe est d’ajouter des GPU. Mais si la saturation vient d’une allocation prudente et rigide, la première source d’économies n’est pas l’optimisation du modèle : c’est l’organisation du trafic et de la mémoire.

Cette réalité est frustrante parce qu’elle est contre-intuitive. Beaucoup d’équipes se disent : “Si la facture est trop lourde, on va optimiser le modèle.” C’est parfois vrai. Pourtant, avant même de parler quantification ou distillation, un problème plus basique apparaît : des GPU sont réservés, mais pas utilisés en continu. La facture, elle, tourne quand même.

Le chef d’orchestre et les instruments

Deux briques se répondent ici : la standardisation de la mise en production, et l’orchestration fine. D’un côté, NVIDIA NIM emballe des moteurs d’inférence sous forme de microservices en conteneurs : API compatibles OpenAI pour s’intégrer plus facilement, choix automatique de techniques comme la quantification et le batching, conteneurs prêts pour la production avec dépendances et tests, et un volet sécurité/conformité avec signature de conteneurs et contrôles “enterprise”. L’idée est simple : éviter que chaque déploiement réinvente son propre runtime.

De l’autre côté, NVIDIA Run:ai se comporte comme un planificateur qui sait que l’inférence n’est pas l’entraînement. Il priorise les workloads exposés aux utilisateurs, pour que des jobs de training ne viennent pas “préempter” des requêtes en production. La logique est pragmatique : l’entraînement peut s’interrompre, checkpoint puis reprendre ; une requête utilisateur ne “reviendra” pas gentiment après une pause.

Dans les environnements mixtes, ce point change la dynamique : quand la demande d’inférence baisse, les GPU peuvent partir au training ; quand la demande remonte, les ressources reviennent automatiquement vers l’inférence. Ça réduit la tentation d’acheter une marge “juste au cas où”, marge qui, en période de pénurie de composants, devient parfois introuvable de toute façon.

Le mécanisme le plus “visible” est celui des fractions de GPU, avec isolation mémoire. Là où un partage naïf se termine en “out-of-memory” dès qu’un modèle se met à consommer plus que prévu, l’idée est de garantir une enveloppe mémoire à chaque service. Ensuite, un placement intelligent (“bin packing”) remplit d’abord les GPU déjà partiellement occupés, avant d’en ouvrir de nouveaux.

Concrètement, des workloads typiques de production – embeddings, rerankers, petits LLM – n’utilisent pas une carte entière en permanence. Les faire cohabiter proprement peut augmenter l’utilisation moyenne d’un cluster et réduire la part “immobile” de la dépense. Dans un test décrit dans le contexte, trois microservices NIM (un LLM 7B, un VLM 12B, et un MoE 30B) passent d’un schéma “trois GPU H100 dédiés” à un schéma “≈ 1,5 H100” avec des fractions, tout en conservant environ 91 – 100% du débit de référence selon les cas. La capacité “libérée” n’est pas un concept abstrait : elle redevient disponible pour d’autres modèles, ou pour absorber un pic, sans nouvelle commande de matériel.

Attention, ce n’est pas “faire tourner plus de choses sur une même carte” comme on empilerait des processus sans règles. La différence, c’est la combinaison entre isolation mémoire, placement guidé par la charge, et priorités adaptées à l’inférence. Sans ces garde-fous, la cohabitation ressemble vite à une loterie : la latence explose, et on retombe sur la stratégie la plus chère, celle du GPU dédié pour chaque modèle.

La mémoire qui gonfle quand le trafic monte

Un détail technique explique pourquoi les performances se dégradent d’un coup quand la concurrence augmente : le KV-cache. Sans entrer dans les équations, il faut juste garder l’image suivante en tête. À chaque requête, le modèle doit conserver en mémoire un “historique” interne pour générer la suite des tokens. Plus il y a de requêtes actives, plus ce cache grossit. Donc la mémoire nécessaire n’est pas seulement fonction de la taille du modèle ; elle dépend aussi du nombre de conversations simultanées et de la longueur de contexte.

C’est ici que les fractions statiques montrent leur limite. Elles isolent très bien, mais imposent un plafond rigide : au-delà d’un certain niveau de concurrence, le cache voudrait grandir, mais ne peut plus. Le débit plafonne, la latence grimpe, et l’inférence peut commencer à refuser de nouvelles séquences faute de marge.

Les fractions dynamiques cherchent à résoudre ce point avec une logique “request/limit”, inspirée de la sémantique Kubernetes : une part minimale est garantie (request), et une limite supérieure autorise un “burst” quand de la mémoire est disponible. Quand la pression retombe, la mémoire est rendue. L’intérêt économique est immédiat : au lieu de sur-réserver la fraction maximale en permanence (et donc de laisser du vide), on réserve le minimum utile et on accepte des montées temporaires.

Dans les résultats évoqués, ce modèle dynamique permet, sous forte concurrence, d’aller jusqu’à 1,4x plus de débit et jusqu’à 1,7x de latence en moins, tout en restant sur un même “empreinte” matérielle d’environ 1,5 H100 pour les trois services. L’image à garder : la même flotte de GPU sert plus de requêtes, au moment où la demande monte, sans obliger à “pré-allouer” le pire cas toute la journée.

Cette approche est aussi une réponse “anti-pénurie”. Quand les GPU sont difficiles à obtenir, le meilleur GPU est parfois celui qu’on possède déjà, mais qu’on utilise mieux. Les fractions dynamiques transforment des micro-inefficacités (un modèle “calme” qui garde une marge inutile) en marge réellement disponible pour un autre modèle, ou pour un pic de trafic.

Ça implique toutefois un changement de mentalité : on ne cherche plus la stabilité par sur-capacité permanente, mais par adaptation contrôlée. La stabilité vient du fait que le planificateur sait quand un service peut emprunter de la mémoire, et quand il doit la rendre, tout en respectant des garanties minimales. Sans garanties, on obtient une compétition brutale ; avec des garanties rigides, on obtient du gaspillage. L’entre-deux est le terrain où l’orchestration fait une différence.

On peut lire ces chiffres comme une promesse de performance, mais ils racontent surtout un mécanisme de coût. Si un service atteint plus vite sa limite de latence acceptable, il faut répliquer, ajouter des GPU, ou dégrader l’expérience. Si, à matériel constant, la courbe reste “douce” et prévisible quand la concurrence monte, on achète moins de marge matérielle. Et quand une organisation fait face à une pénurie de composants, “acheter moins” peut aussi vouloir dire “déployer quand même”.

Les modèles qu’on n’allume presque jamais

Un autre poste de gaspillage est plus discret : les modèles rarement appelés. Beaucoup d’équipes gardent des réplicas “always-on” pour éviter le démarrage à froid. Le raisonnement est simple : si un utilisateur tombe sur un démarrage à froid qui dure des dizaines de secondes, c’est mort pour le produit. Donc on laisse des GPU réservés, même quand ces modèles n’ont pas de trafic.

Le pattern “scale-to-zero” (couper complètement quand c’est inactif, relancer à la demande) économise les ressources, mais il réintroduit ce démarrage à froid : initialisation du conteneur, chargement des poids depuis le disque, allocation mémoire GPU. Dans le contexte fourni, cette pénalité est décrite comme pouvant prendre de dizaines de secondes à des minutes, ce qui suffit à rendre le modèle inutilisable pour des applications sensibles à la latence.

La “GPU memory swap” propose une troisième voie : le modèle ne disparaît pas, il change de place. Les poids restent en mémoire CPU, et basculent vers la mémoire GPU quand une requête arrive. Si un autre modèle devient actif, l’actuel peut être renvoyé vers le CPU, puis rappelé plus tard. On évite ainsi la cascade qui coûte cher en temps : redémarrer, relire sur disque, reconstruire un état complet.

Dans les mesures mentionnées, l’indicateur clé est le TTFT (time to first token), c’est-à-dire le temps avant d’obtenir le premier token en réponse. Pour des prompts courts (128 tokens), le démarrage à froid va de 75,3 s à 92,7 s selon le modèle, tandis que la memory swap ramène ce TTFT à environ 1,23 – 1,61 s, soit une amélioration de 55 – 61x. Pour des prompts plus longs (2 048 tokens), le TTFT de 158,3 – 180,2 s descend à 3,52 – 4,02 s, soit environ 44x plus rapide.

Ce passage est crucial pour la réduction des coûts, parce qu’il touche un angle souvent négligé : l’argent dépensé pour “ne pas attendre”. Si une organisation peut offrir une latence acceptable sans laisser un modèle sur GPU en permanence, elle peut libérer des cartes pour d’autres usages, ou réduire la taille du cluster. Dans un contexte de pénurie, cette élasticité se traduit aussi en résilience : on peut servir un catalogue plus large de modèles sans immobiliser un parc entier.

À ce stade, il devient possible de raisonner comme un exploitant de services plutôt que comme un simple “déployeur de modèles”. Les questions changent : quels modèles doivent être chauds en continu ? lesquels peuvent être “tièdes” via swap ? quels workloads peuvent partager un GPU sans se nuire ? Répondre avec des règles et des outils d’orchestration peut coûter moins cher que de “gagner” quelques pourcents sur un modèle isolé.

Le coût, la pénurie, et ce qui reste à maîtriser

Optimiser l’utilisation GPU ne règle pas tout. Mieux remplir une ressource rare la rend plus accessible, mais augmente aussi la complexité opérationnelle : priorités, isolation, placement, montée en charge, et sécurité du déploiement deviennent des sujets quotidiens. Cette complexité n’est pas gratuite, elle se gère. Et elle se gère d’autant mieux qu’on comprend ce que l’on automatise.

Ce point rejoint une idée plus large : à mesure que les systèmes IA prennent de l’ampleur, le risque n’est pas seulement “un modèle se trompe”, mais “un système mal contrôlé fait des choses imprévues”, qu’il s’agisse de coûts qui dérivent, de latence qui s’effondre, ou de décisions automatisées qui dépassent l’intention. Une discussion plus générale sur ces enjeux, entre sécurité, méthodes actuelles (comme le RLHF) et conception plus sûre, se trouve dans les risques et sécurité de l’IA, utile pour garder en tête que l’industrialisation est aussi une affaire de garde-fous.

Reste que, sur le terrain, le bénéfice le plus immédiat est tangible : réduire le gaspillage de GPU revient à réduire la facture, et, souvent, à contourner la pénurie de composants en repoussant le moment où il faut acheter. Les chiffres cités (consolidation de trois services sur ≈ 1,5 GPU H100 avec 91 – 100% du débit, montée en charge plus stable avec des fractions dynamiques, TTFT drastiquement réduit via memory swap) donnent une grammaire pour penser “capacité” autrement que par l’achat de nouvelles cartes.

La meilleure synthèse tient en une image simple : au lieu d’une flotte de GPU stationnés avec un moteur qui tourne, l’objectif devient une flotte en mouvement, qui se regroupe quand c’est calme et se redéploie quand ça s’accélère, sans casser l’expérience utilisateur.

Cette façon de voir ne promet pas une magie universelle. Chaque modèle a son profil, chaque produit a ses pics, et chaque organisation a ses contraintes de sécurité et d’exploitation. Mais elle donne une méthode : avant de déclarer “on manque de GPU”, il vaut la peine de vérifier si l’on manque surtout d’orchestration.

Est-ce que cette lecture aide à clarifier où se cache la dépense principale, et quel compromis vous paraît le plus difficile à tenir : la latence, la stabilité, ou la capacité disponible quand les composants manquent ?