Économie de l'inférence soutenue vs. inférence ponctuelle : quand l'infrastructure sur site l'emporte, quand le cloud vous sauve la mise

Un serveur d'inférence à quatre GPU consomme la même électricité, occupe le même espace rack et s'amortit selon le même calendrier, qu'il traite vingt millions ou vingt mille jetons par jour. Les cartes graphiques ignorent leur inactivité. Seul le comptable la perçoit. Cette simple asymétrie – coût fixe sur site, coût marginal dans le cloud – explique pourquoi la réponse à la question « Faut-il opter pour une infrastructure sur site ? » dépend autant de… forme de votre trafic en fonction du volume.

T01 Nous avons calculé le coût par carte pour un point d'utilisation unique. L'article T02 compare le coût par million de jetons aux API cloud en pleine charge. Cet article (T03) est celui que votre directeur financier devrait lire : il explique l'impact des pics de trafic et du trafic soutenu sur ces chiffres, et comment concevoir un système qui évite les surcoûts.

Le public cible est composé de personnes ayant déjà conclu que la charge de travail pourrait être gérée sur site et qui doivent maintenant prendre une décision. combien sur site, et ce qui sauve le reste.

Le piège des coûts fixes

Le coût de l'inférence dans le cloud est proportionnel à l'utilisation. Un seul appel Llama 70B sur un fournisseur OpenRouter vous coûte environ 0.50 € à 2.00 € par million de jetons (ce tarif varie selon le niveau de service et le fournisseur). Si vous n'envoyez aucun trafic, vous ne payez rien. Si vous envoyez dix fois plus de trafic, vous payez dix fois plus. La relation est linéaire et commence à zéro.

L'inférence sur site est l'inverse. Un boîtier Blackwell 4× RTX Pro 6000 (T01 Le coût total de possession (TCO) sur 3 ans s'élève à environ 58 58 € (tout compris : amortissement des dépenses d'investissement, électricité, part du châssis et maintenance). Ce coût reste inchangé, que le système traite un million ou un billion de jetons. Le coût marginal du 200 millionième jeton traité en un mois est identique à celui du deuxième : le kWh d'électricité nécessaire à son calcul, et rien de plus. Les dépenses d'investissement sont irrécupérables dès l'expédition du boîtier.

Les conséquences comptables sont brutales et rarement prises en compte par les acheteurs :

(Même matériel, même coût total de possession de 14 400 € par carte sur trois ans ; seul le dénominateur change.)

Le tarif cloud pour Llama 70B FP8 en 2026 se situe entre 0.50 € et 1.50 €/Mtok selon le niveau de fournisseur. Veuillez relire le tableau en tenant compte de cette information. Avec un taux d'utilisation soutenu de 5 %, le serveur sur site est plus cher que toutes les options cloud existantes. À 30 %, il égale les fournisseurs les plus chers. À partir de 60 %, il l'emporte haut la main.

Le piège, c'est que les clients comparent leurs dépenses d'investissement à la charge actuelle, puis découvrent six mois plus tard que cette dernière ne représentait que 8 % de la capacité du système. Le matériel n'était pas en cause ; c'est le dimensionnement qui posait problème.

À quoi ressemble l'utilisation réelle de la production ?

Nous disposons de données publiques ainsi que de nos propres données d'analyse sur les installations K-AI que nous exploitons ou visitons, et le constat est cohérent dans l'ensemble du secteur en 2026 :

Principaux chiffres issus des déploiements en production et des enquêtes auprès des opérateurs : la plupart des équipes exécutent leur propre rapport d’inférence Utilisation moyenne du GPU : 20 à 40 %, avec des configurations matures qui se rapprochent progressivement 40-65%Un taux d'utilisation supérieur à 65 % indique soit un traitement par lots pur, soit une charge tellement importante sur le cluster que le prochain pic de trafic entraînera une mise en file d'attente. En dessous de 20 %, le serveur fonctionne principalement pour son propre financement, et non pour répondre aux besoins des utilisateurs.

Le chiffre qui surprend toujours les acheteurs : un Interactif La charge de travail — un chatbot, un assistant de programmation, un bot de support client — dépasse rarement les 30 %. La raison ? La durée du jour. Même un produit global connaît des périodes creuses ; un produit régional, quant à lui, bénéficie de 14 heures de faible activité par jour. Le calcul est sans appel : cela pénalise fortement les utilisateurs.

Charges de travail soutenues — le pain et le beurre

Le modèle économique sur site est parfaitement adapté à toute charge de travail où les GPU peuvent fonctionner la majeure partie de la journée. Voici, par ordre approximatif de fréquence d'utilisation sur les installations K-AI :

• Assistant de codage / backend IDE Pour une équipe de plus de 30 ingénieurs. Charge de travail stable en semaine de 9h à 18h, plus légère en soirée, quasi nulle le week-end. En moyenne 20 à 30 % sur la semaine, avec des pics à 60-80 % pendant la journée de travail.
• chatbot d'assistance client/ventes avec un trafic continu 24h/24 et 7j/7. Le rythme diurne suit la région desservie ; les produits mondiaux représentent 25 à 35 % du trafic continu, les produits régionaux 15 à 25 %.
• RAG / moteur de recherche sémantique Indexation et diffusion d'une base de connaissances interne. Le taux de requêtes est relativement stable ; la réindexation, une tâche nocturne planifiée, maintient le serveur à 95 % d'utilisation. Taux d'utilisation combiné : 30 à 50 %.
• Le traitement par lots — Synthèse nocturne des documents de la veille, étiquetage automatique hebdomadaire, réexécution mensuelle de la classification d'un corpus. Traitement en file d'attente uniquement, taux d'utilisation de 70 à 90 % lorsque la file d'attente n'est pas vide, conçu pour s'exécuter jusqu'à son terme.
• Inférence sur la flotte de robots — plusieurs unités effectuant la même opération VLM pendant les heures de fonctionnement, inactives à l'extérieur (I01, I06).

La tendance est que les charges de travail soutenues s'étendent soit sur suffisamment de fuseaux horaires pour remplir la journée, soit comportent des composants par lots qui comblent intentionnellement les lacunes. La technique du «comblement des lacunes» est le levier le plus important pour réduire le coût total de possession (TCO) à la disposition d'un client, et pourtant le plus négligé. Une machine qui effectue des conversations interactives 12 heures par jour à 30 % et qui exécute l'étiquetage automatique pendant la nuit à 90 % atteint en moyenne environ 60 % — soit deux fois l'utilisation effective et la moitié du coût par jeton.

Charges de travail ponctuelles — là où l'infrastructure sur site présente des inconvénients

Le cas inverse correspond à une charge de travail nécessitant une capacité énorme pendant une courte période et quasiment aucune le reste du temps. Voici quelques exemples courants :

• Campagne marketing / impulsion de création de contenu. Générer des variantes pour une campagne publicitaire sur N marchés en 48 heures, puis plus rien pendant un mois.
• Moments de contenu viral. Une application grand public lance une nouvelle fonctionnalité, est mise en avant dans une newsletter technologique, le trafic est multiplié par 50 pendant six heures, puis revient à la normale le lendemain matin.
• Événements de démonstration/pilotes. Un stand d'exposition professionnelle proposant des démonstrations d'inférence en direct pendant trois jours, puis retour à zéro.
• Tâches par lots périodiques qui doivent se terminer dans un délai imparti. Contrôle mensuel de conformité de l'ensemble des documents devant être finalisés avant une date limite réglementaire.
• Analyses de la soirée électorale ou d'événements en direct — une fenêtre de 12 à 48 heures pendant laquelle le volume est 100 fois supérieur à la normale.

Exemple concret : une charge de travail nécessite la génération de 10 millions de jetons. Répartie sur 24 heures, elle représente environ 116 jetons/s au total, ce qui est suffisant pour un seul processeur L4. Compressée sur une heure, elle atteint 2 778 jetons/s, nécessitant un serveur équipé de 4 GPU Pro 6000 fonctionnant à pleine capacité, soit environ six processeurs L4.

Ainsi, ces mêmes 10 millions de jetons nécessitent soit une carte 24h/24 et 7j/7, soit six cartes pendant une heure. Pour les pics de charge, la capacité sur site reste inactive 23 heures sur 24. Le calcul du coût total de possession (TCO) est catastrophique : ce système à six cartes, utilisé à 4 %, coûte entre 13 et 25 €/Mtok, selon le tableau ci-dessus. Une solution de cloud burst à 1.50 €/Mtok couvre la même charge pour un total de 15 €. Le seuil de rentabilité est loin d'être atteint.

La conclusion inévitable : Le dimensionnement des ressources sur site pour les pics de consommation est l'erreur de surdépense la plus courante que nous constatons. Les clients souhaitent que leur système soit opérationnel même dans le pire des cas, comme un mardi après-midi, et achètent donc quatre fois plus de GPU que nécessaire en temps normal. Le coût se traduit par des investissements irrécupérables et un parc informatique immobilisé à 90 %.

Le modèle hybride

L'architecture optimale pour une charge de travail de production réelle avec les deux configurations est une infrastructure de base sur site plus une capacité de débordement dans le cloud.

Routage hybride : priorité aux ressources sur site, débordement vers le cloud uniquement lorsque la profondeur de la file d’attente dépasse le seuil configuré.

La logique de routage correcte est pas « Envoyer X % vers le cloud, le reste sur site. » C’est Déploiement sur site en premier, puis passage au cloud uniquement lorsque le système sur site atteint sa capacité maximale.. Le signal est la profondeur de la file d'attente ou l'utilisation du cache KV du côté vLLM (K03 (couvre les indicateurs), et non une répartition statique.

Recette concrète avec vLLM :

1. Placez un routeur en façade du cluster sur site qui expose /v1/chat/completionsNGINX, HAProxy, le routeur vLLM ou une petite passerelle personnalisée fonctionnent tous.
2. Exposer vllm:num_requests_waiting comme indicateur de profondeur de file d'attente. Seuil à, par exemple, 8 à 16 en attente par réplique avant le déclenchement du mécanisme de repli.
3. En cas de surcharge, redirigez le trafic vers un point de terminaison cloud portant le même nom de modèle. OpenRouter, Together et Fireworks prennent tous en charge les modèles de type Llama. Désignez-en un comme principal et l'autre comme de secours afin d'éviter toute interruption de service liée à un seul fournisseur.
4. Identifiez les requêtes de débordement dans votre outil d'observation afin de visualiser quotidiennement le pourcentage de dépenses. Si ce pourcentage dépasse 15 % la plupart des jours, votre infrastructure sur site est sous-dimensionnée ; s'il est inférieur à 1 % pendant des semaines, elle est surdimensionnée.

Logique économique : payer les dépenses d’investissement une seule fois pour la charge qui est toujours làVous payez des tarifs cloud variables pour les pics de charge. Bien implémentée, cette solution permet d'atteindre un taux d'utilisation effectif de 50 à 70 % sur l'infrastructure sur site (le seuil de routage étant le paramètre à optimiser), tout en préservant la latence de queue lors des pics d'activité.

Démarrage à froid : la réalité de l'autoscaling

La solution simpliste, typique du cloud, face aux pics de charge consiste à « adapter automatiquement le cluster sur site » : maintenir le nombre de réplicas à zéro en cas d’inactivité et les augmenter à la demande. Cette solution est fortement défaillante pour le déploiement de LLM, notamment à cause du temps de chargement des modèles.

Le chargement de Llama 70B FP8 (~75 Go de poids) depuis un disque NVMe Gen5 prend du temps. 30 à 60 secondes d'E/S pures avec des vitesses de lecture théoriques de 12 à 14 Go/s. Ajoutez la compilation du noyau CUDA, l'initialisation du planificateur vLLM, la préallocation du cache KV, et une nouvelle réplique est prête à recevoir sa première requête. 60 à 120 secondes après le démarrage de la capsuleLes modèles plus petits aident proportionnellement — un modèle de 8 octets tient en 5 à 10 secondes — mais tout ce qui dépasse 30 octets se trouve dans la plage où les utilisateurs dépasseront le délai imparti.

Pour les traitements par lots, cela ne pose pas de problème. Pour les traitements interactifs, c'est catastrophique. Une latence de deux minutes sur la requête ayant déclenché la mise à l'échelle est inacceptable.

Les mesures d'atténuation, par ordre d'effort :

• Gardez toujours les répliques N au chaud. La charge minimale supportée par votre charge moyenne. Balance up à la demande, jamais jusqu'à zéroLe modèle « minimum-chaud » est celui sur lequel les opérateurs expérimentés conçoivent des produits entiers.
• Mode veille vLLM. Les versions plus récentes de vLLM prennent en charge un état de « veille » où les poids restent en mémoire GPU mais le moteur libère des ressources de calcul. Le réveil est 18 à 20 fois plus rapide qu'une charge neuveUtile lorsque vous avez plusieurs modèles qui partagent des GPU, mais qu'un seul fonctionne à la fois.
• Cache de modèle préchauffé sur NVMe / NFS partagé. Les poids sont chargés une seule fois dans un cache local rapide, que toutes les répliques montent. Le premier chargement a lieu au démarrage du cluster ; les répliques suivantes sont opérationnelles en quelques secondes.
• Mise à l'échelle programmée en fonction de l'heure de la journée. Augmenter la capacité à 08h30 en prévision du trafic de 09h00. C'est la solution la plus simple et la plus efficace pour les charges de travail diurnes prévisibles. Paramétrage des tâches planifiées (CronJobs). kubectl scale sont démodées, mais elles fonctionnent.
• Opérateur NVIDIA NIM avec moteurs TRT-LLM pré-intégrés. Moteurs précompilés, mis en cache sur disque, chargés à la demande. Démarrage à froid plus rapide qu'une compilation complète, mais toujours de l'ordre de quelques dizaines de secondes pour 70 octets.

Pour la clientèle de K-AI (petites flottes, usage prévisible), la bonne réponse est presque toujours N répliques chaudes + mise à l'échelle planifiée + débordement en cas d'explosion du cloud. Le scale-to-zero concerne les plateformes sans serveur où quelqu'un d'autre prend en charge le démarrage à froid.

Mise à l'échelle automatique : HPA basé sur quoi ?

Par défaut, Kubernetes HPA utilise les métriques du processeur et de la mémoire. Les deux sont incorrects pour l'inférence GPU. Un pod vLLM peut avoir une utilisation du processeur de 5 % et être surchargé à 100 %, ou une utilisation du processeur de 95 % et fonctionner correctement. La métrique qui vous intéresse réellement est l'une des suivantes :

L'outil approprié pour intégrer cela à Kubernetes est KÉDA (Kubernetes Event-Driven Autoscaling), qui peut traiter directement les requêtes Prometheus et les transmettre à un HPA. La pile de production vLLM intègre KEDA de manière optimale, et le même modèle est compatible avec KServe sur OpenShift AI.

Un objet ScaledObject fonctionnel pour la mise à l'échelle de la profondeur de la file d'attente :

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: vllm-llama70b
spec:
  scaleTargetRef:
    name: vllm-llama70b
  minReplicaCount: 2     # always-warm floor
  maxReplicaCount: 6     # cap before cloud overflow
  pollingInterval: 15
  cooldownPeriod: 300    # don't thrash on noisy queue
  triggers:
  - type: prometheus
    metadata:
      serverAddress: http://prometheus:9090
      query: avg(vllm:num_requests_waiting)
      threshold: '5'     # avg 5 waiting per replica → scale up

Deux leçons de production que nous avons apprises à la dure :

1. cooldownPeriod Cela compte autant que le déclencheur. Une file d'attente bruyante provoque des changements brusques de capacité, et chaque montée en charge entraîne un démarrage à froid. Cinq minutes constituent un minimum raisonnable.
2. minReplicaCount La taille doit être adaptée au niveau du creux, et non à zéro. Les deux modules inactifs à 03h00 sont les deux modules qui gèrent le pic de 09h00 sans délai d'attente.

Échelle horizontale vs échelle verticale

Un choix architectural subtil en matière de dimensionnement : achetez-vous plus de boîtes (horizontal) ou plus de GPU par boîte (verticale)?

Pour les charges de travail d'inférence avec un trafic irrégulier, L'horizontal l'emporte presque toujours. Deux serveurs équipés de 4 GPU peuvent fonctionner comme quatre répliques DP=2, supporter une panne sur l'un d'eux sans interruption de service et permettre une augmentation de capacité par moitié plutôt que par unité entière. L'architecture verticale est idéale pour l'entraînement et l'inférence de modèles uniques de grande taille, où le traitement du texte (TP) nécessite les GPU dans un seul domaine électrique.

Le piège psychologique du « GPU inactif mais je le paie »

Les clients qui découvrent l'installation pour la première fois ouvrent souvent le tableau de bord Grafana, constatent une utilisation du GPU de 18 % à 14h30 un mardi et se demandent pourquoi ils ont payé pour un matériel qui ne sert à rien 80 % du temps.

La réponse honnête est que pour toute charge de travail sensible à la latence, Un certain temps d'inactivité est le prix à payer pour une réponse à faible latence. Un serveur saturé à 95 % de sa capacité génère une file d'attente. Cette file d'attente induit une latence de requête. Le client qui souhaite un délai d'obtention du premier jeton de 300 ms ne bénéficiera pas pour autant d'une utilisation à 95 % du même serveur. Il faut choisir.

Le compromis qui Boite être optimisé déplacer les travaux fixes dans les fenêtres inactives:

• Les tâches par lots (étiquetage automatique, extraction de documents, génération d'intégration pour les nouveaux contenus) sont programmées pendant la nuit, lorsque le chatbot est inactif.
• Les réglages finaux sont effectués le week-end, lorsque personne n'est connecté.
• Réindexation périodique des bases de données vectorielles tôt le matin.

Il s'agit de la discipline consistant à traiter le serveur sur site comme un actif à double usageService interactif sensible à la latence en journée, traitement par lots la nuit. Dans une configuration optimale, le même matériel affichant 25 % d'utilisation sur le tableau de bord interactif atteint 65 % sur le tableau de bord global. C'est ce dernier que le directeur financier consulte.

Qu'est-ce que le pas Solution de contournement : augmenter artificiellement le nombre de requêtes pour simuler une forte activité. Certains clients y ont recours. Cela aggrave la latence de queue, rend la surveillance inutile et n’a aucun impact sur la facture.

La matrice de décision

C’est la forme de la charge de travail, plus que son volume, qui détermine l’architecture appropriée. Associez votre situation à la ligne la plus proche :

Cette matrice réussit sur deux points que la planification ad hoc ne permet pas d'appréhender correctement :

• Les charges de travail à pics de performance ont leur place dans le cloud. Acheter du matériel pour une charge de travail de quatre heures par mois est une erreur de pratique.
• La configuration hybride « soutenue + explosive » requiert presque toujours les deux. Essayer d'en choisir un ou l'autre conduit généralement à faire le mauvais choix.

Le point de vue honnête

La plupart des clients de Kentino doivent prévoir Utilisation soutenue de 30 à 50 % sur site Utilisez le cloud pour tout ce qui dépasse ce seuil. Les clients qui atteignent 60 à 80 % d'utilisation sur site sont ceux qui exécutent des traitements par lots en parallèle d'opérations interactives : étiquetage automatique la nuit, réglages fins le week-end et génération intégrée aux petites heures du matin. Les clients dont l'utilisation se situe entre 10 et 15 % sont ceux qui ont dimensionné leur infrastructure pour les pics de charge.

L'erreur la plus coûteuse est d'acheter en prévision du pire scénario pour un mardi après-midi. La deuxième plus coûteuse est de passer au tout cloud alors qu'une charge soutenue permettrait d'amortir l'investissement en 14 mois. La solution optimale se situe presque toujours entre les deux : une infrastructure sur site plus petite que celle initialement prévue par le client, avec une solution cloud pour gérer les pics de charge.

Vérifions les calculs : avec un tarif cloud de 0.50 €/Mtok et un serveur Pro 6000 à 4 GPU coûtant 58 000 € sur 3 ans, le serveur est rentabilisé à environ 14 milliards de tokens distribués. Répartis uniformément, cela représente environ 150 tok/s de débit soutenu, largement atteignable avec un taux d’utilisation du serveur de 25 à 35 %. En dessous de ce volume, louez ; au-dessus, achetez. C’est le même seuil de rentabilité. T01 et T02 atteindre les angles par carte et par jeton.

Ceci fait partie du Kentino Wiki, une série de référence sur l'intelligence artificielle, la robotique et les systèmes qui les connectent. Commentaires et corrections bienvenus. info@kentino.com.