Module 10 — Coûts, latence et choix d'architecture

Neuf modules ont posé les briques ; celui-ci les assemble en une décision. Pour notre assistant de support, l'entreprise doit maintenant trancher : appelle-t-on un modèle par API, ou l'héberge-t-on ? Un modèle ou plusieurs ? Avec quel cache, quel routage ? Ce module donne les chiffres qui permettent d'argumenter, pas seulement d'opiner. Il clôt le fil rouge et prépare la mise en service concrète, développée au cours 20.

Le coût par requête, l'unité qui compte

La bonne unité de comptabilité n'est ni le mois ni la carte : c'est le coût par requête, agrégeant entrée, sortie et temps de calcul.

Pour un modèle appelé par API, la formule est directe :

$$c_{\text{API}} = p_{\text{entrée}} \cdot n_{\text{invite}} + p_{\text{sortie}} \cdot n_{\text{réponse}},$$

où $p_{\text{entrée}}$ et $p_{\text{sortie}}$ sont les prix par million de jetons du fournisseur.

Pour un modèle auto-hébergé, on ramène le coût matériel au débit soutenu :

$$c_{\text{local}} = \frac{c_{\text{machine par heure}}}{r_{\text{req/h}}},$$

où $r_{\text{req/h}}$ est le nombre de requêtes traitées par heure à charge nominale. Cette formule masque un coût fixe humain (opérations, maintenance) qu'il faut ajouter en pratique — souvent l'équivalent de 20 à 40 pour cent d'un temps plein d'ingénieur pour un service stable.

Un exemple chiffré, notre assistant

Prenons un scénario réaliste. Notre assistant de support reçoit 8 000 conversations par jour, chacune de trois tours, avec 400 jetons d'invite et 200 jetons de sortie en moyenne. Cela fait 24 000 appels/jour, soit 720 000 par mois.

Option API haut de gamme (modèle propriétaire) :

• Prix entrée : 3 € par million, prix sortie : 10 € par million.
• Coût par requête : $3 \cdot 0{,}0004 + 10 \cdot 0{,}0002 = 0{,}0032$ €.
• Coût mensuel : environ 2 300 €.

Option API modèle intermédiaire :

• Prix entrée : 0,3 € par million, prix sortie : 1 € par million.
• Coût par requête : environ 0,00032 €.
• Coût mensuel : environ 230 €.

Option auto-hébergée (modèle ouvert 8 milliards en AWQ, GPU A100 en cloud) :

• Coût machine : 1,50 € par heure, 1 100 € par mois en réservation annuelle.
• Débit soutenu : 4 req/s, soit environ 10 M requêtes/mois de capacité.
• Coût par requête à charge nominale : 0,00015 €.
• Coût mensuel utilisé : 1 100 € pour 720 000 requêtes, plus temps humain.

Option	Coût par requête	Coût mensuel	Contrôle des données	Latence médiane
API haut de gamme	3,2 milli-euros	2 300 €	externe	800 ms
API intermédiaire	0,32 milli-euros	230 €	externe	1 500 ms
Auto-hébergé	0,15 milli-euros	1 100 € fixes	interne	500 ms

Ces chiffres n'incluent pas un affinage local ni le cache que nous allons ajouter. Ils suffisent déjà à balayer deux idées reçues : « l'API est toujours moins cher au démarrage » (faux si le trafic dépasse quelques centaines de milliers de requêtes), « l'auto-hébergement est prohibitif » (faux dès qu'on a du volume et un peu de compétence).

Latence perçue, décomposée

L'utilisateur ne mesure pas les coûts. Il mesure la latence, et surtout deux moments : le premier jeton et la fin de la réponse.

$$T_{\text{total}} = T_{\text{réseau}} + T_{\text{préremplissage}}(n_{\text{invite}}) + T_{\text{génération}}(n_{\text{réponse}}).$$

Le premier jeton apparaît après $T_{\text{réseau}} + T_{\text{préremplissage}}$. Sur du streaming, c'est ce délai que l'utilisateur perçoit : dès qu'un jeton s'affiche, il tolère bien mieux les suivants. Un service qui n'utilise pas le streaming est perçu comme deux fois plus lent qu'un service qui l'utilise, à latence totale égale.

Composant	API propriétaire	Auto-hébergé sur A100
Réseau	100-300 ms	5-20 ms
Préremplissage (400 jetons)	200 ms	60 ms
Génération de 200 jetons à 50 j/s	4 s	4 s
Latence perçue au premier jeton	400 ms	80 ms

L'auto-hébergement gagne surtout sur la latence perçue, pas sur la latence totale — la génération domine. Pour un tchat en direct où l'utilisateur regarde s'écrire la réponse, cette différence est très visible.

Le routage petit-grand, économie sans perte perceptible

Toutes les questions ne demandent pas le même modèle. La distribution typique d'un service de support est fortement asymétrique :

• 60 pour cent des messages sont des salutations, des demandes triviales ou des questions déjà en FAQ.
• 30 pour cent sont des questions produit standard.
• 10 pour cent sont des cas complexes, litigieux, ou hors du mandat.

Un routage à deux étages traite chaque catégorie avec le bon modèle.

def routeur(message, classifieur, petit_modele, grand_modele):
    categorie = classifieur.classer(message)      # petit modele ou heuristique
    if categorie in ("salutation", "faq_directe"):
        return petit_modele.repondre(message)
    if categorie == "hors_mandat":
        return "Je transfere votre message a un operateur humain."
    return grand_modele.repondre(message)

Le classifieur est un modèle très léger (100 M paramètres suffisent) ou une simple recherche par embeddings dans un jeu de FAQ. Il classe la question en dessous de 50 ms. Le petit modèle traite les cas courts et bon marché ; le grand modèle est réservé aux cas où sa qualité fait une différence.

Une entreprise que j'ai accompagnée en 2025 a réduit sa facture LLM de 68 pour cent avec ce simple routage, sans dégradation mesurable de la qualité perçue.

Le cache, l'économie qui compte le plus

Beaucoup de requêtes se répètent quasi à l'identique. Deux caches sont possibles.

• Cache d'invite exact : même invite = même sortie. Utile pour les FAQ traduites en réponses préconstruites.
• Cache sémantique : deux invites qui ont la même intention se voient renvoyer la même réponse. On indexe l'invite par embedding et on récupère la plus proche sous un seuil de similarité.

def cache_semantique(question, index_embeddings, cache_reponses, seuil=0.92):
    e = encoder(question)
    plus_proche, similarite = index_embeddings.chercher(e, k=1)
    if similarite >= seuil:
        return cache_reponses[plus_proche]
    reponse = generer(question)
    index_embeddings.ajouter(e)
    cache_reponses[e] = reponse
    return reponse

Sur les services de support à trafic moyen, un cache sémantique traite entre 25 et 45 pour cent des requêtes à latence quasi nulle, avec un coût marginal proche de zéro. Le seuil de similarité doit être choisi conservatif — 0,92 est prudent, 0,85 devient risqué : deux questions superficiellement proches peuvent avoir des réponses très différentes.

API contre auto-hébergement : la grille de décision

Après neuf modules, la décision se ramène à cinq axes. Le tableau condense le fil rouge.

Axe	Favorable à l'API	Favorable à l'auto-hébergement
Trafic	pointes fortes, volume faible ou variable	volume soutenu et prévisible
Données	sortie de l'entreprise autorisée	données personnelles ou sensibles
Compétences	pas d'équipe MLOps	équipe MLOps disponible
Latence perçue	tolérante	temps réel critique
Contrôle	acceptable de subir les mises à jour	besoin de figer une version

Pour l'assistant de support d'une entreprise francophone de taille moyenne, avec 8 000 conversations par jour, des données personnelles clients et une exigence de réponse en français propre, la décision penche nettement vers l'auto-hébergement d'un modèle ouvert de 8 milliards affiné, complété par un cache sémantique et un routage à deux étages. C'est la solution que le cours 20 mettra en production étape par étape.

Le coût caché des changements de fournisseur

Les prix des API baissent en général tous les six mois, mais les modèles changent aussi. Un modèle propriétaire peut être retiré avec un préavis court, et le remplaçant n'a jamais tout à fait le même comportement. Cela impose de refaire l'évaluation métier (module 9) à chaque changement, ce qui coûte plusieurs jours-ingénieur. L'auto-hébergement a un défaut symétrique : l'obsolescence matérielle. Ni l'une ni l'autre n'est réellement « figée ».

Commencer petit, garder l'option

Une architecture prudente commence par un modèle ouvert servi par vLLM sur une seule machine, avec un cache sémantique et un jeu d'évaluation métier. Cette configuration tient 100 000 requêtes par jour sans effort. Si le trafic monte, on ajoute un GPU ; si l'entreprise change d'avis, l'interface compatible OpenAI de vLLM permet de basculer en une variable d'environnement.

En résumé

• Le coût par requête est la bonne unité de comparaison ; il aligne API et auto-hébergement sur la même échelle, à condition d'inclure le coût humain d'opération.
• La latence perçue est dominée par le premier jeton ; le streaming double la tolérance de l'utilisateur, à latence totale égale.
• Le routage petit-grand et le cache sémantique coupent typiquement plus de la moitié de la facture sans dégrader la qualité, et se mettent en place en quelques jours.
• Pour notre fil rouge — assistant francophone à quelques milliers de conversations quotidiennes avec données personnelles — l'auto-hébergement d'un modèle ouvert de 8 milliards, servi avec vLLM, cache et routage, l'emporte sur l'API tant en coût qu'en contrôle.

Module suivant : la récapitulation du cours et l'examen final de 40 questions.