Chapitre 15 — API serverless vs infrastructure dédiée

Quinzième billet de la tournée chapitre par chapitre de LLM Primer VI : Mettre à l'échelle les systèmes IA. Le chapitre qui pose le calcul du seuil de rentabilité sur la table et nomme ensuite la ligne d'ingénierie plateforme qui, pour la plupart des équipes, décide la réponse.

Pourquoi ce chapitre existe

Le Chapitre 14 a laissé l'équipe avec une image nette de ce dont la facture API est faite, et un soupçon discret qu'elle pourrait être moins chère. La question naturelle qui suit est de savoir si l'équipe devrait payer au token du tout. L'alternative est de rapatrier l'inférence en interne, faire tourner un modèle à poids ouverts sur la pile décrite aux chapitres précédents, et payer par GPU-heure. Le troc a un seuil de rentabilité propre. Ce qui est moins propre, et que la plupart des équipes sous-estiment, c'est tout ce qui figure du côté dédié du grand livre et qui n'est pas sur la facture GPU — l'ingénierie plateforme, les correctifs de sécurité, la chorégraphie de mise à niveau des modèles, l'alerte de 3 h du matin quand un nœud tombe du parc. Le Chapitre 15 prend les deux côtés au sérieux et dérive quand l'auto-hébergement est la bonne réponse.

15.1 La formule du seuil de rentabilité est propre, et surtout un leurre

Le GPU produit débit × utilisation × 3 600 tokens de sortie par heure. Son coût par million de tokens est (taux_horaire_gpu / tokens_par_heure) × 1 000 000. Le seuil de rentabilité contre l'API se situe là où ce chiffre égale le prix API par million. Un modèle 70B en FP8 sur un H100 à 3 $/h, tournant à 800 tokens par seconde agrégés à 60 pour cent d'utilisation, sort à environ 1 $ par million de tokens de sortie. L'API frontière facture 15 $. L'économie apparente est de 14× — un argument pour l'auto-hébergement que la finance adore et qui rate la seconde ligne, bien plus grosse. Le seuil dépend aussi de l'utilisation ; en dessous de 20–30 pour cent d'utilisation, le coût auto-hébergé par million passe au-dessus du tarif API et le GPU devient plus cher que l'alternative qu'il était censé remplacer. L'utilisation, à son tour, est fonction de la forme du trafic, de la qualité de l'autoscaling et de la capacité de l'équipe à empaqueter plus d'une charge sur le même parc.

15.2 L'ingénierie plateforme est la ligne qui décide l'affaire

La facture GPU est la plus petite moitié. La plus grande est l'équipe qui garde le parc en marche : moteurs, pilotes, orchestration, autoscaling, observabilité, sécurité. L'équipe API paie ce coût implicitement au travers du prix par token ; l'équipe auto-hébergeante le paie en effectifs. Une règle utile : un parc GPU de service — un ou deux variants de modèle, autoscaling, observabilité, astreinte, mises à niveau trimestrielles — exige environ un ingénieur plateforme à plein temps plus une fraction d'un SRE. Un parc plus divers — plusieurs moteurs, plusieurs modèles, ordonnancement multi-tenant — exige deux à quatre. À 300 k$ chargés par ingénieur, la facture annuelle de la plateforme est de 300 k$–1,2 M$. Le seuil de trafic mensuel où l'auto-hébergement devient rentable se situe quelque part entre 200 millions et 1 milliard de tokens de sortie par mois. En dessous, le surcoût d'ingénierie excède les économies de tokens et l'équipe devrait rester sur une API. Au-dessus, les économies dominent. L'ingénierie plateforme arrive aussi par marches, non par courbes lisses : le premier recrutement fait démarrer le parc, le second arrive parce que le premier ne peut pas couvrir l'astreinte du week-end, le troisième quand le parc croît en multi-région.

15.3 La posture réaliste est hybride, et le routeur est la pièce porteuse

La décision la plus propre — tout API ou tout dédié — est rarement la bonne pour une équipe qui a plus d'un an de production. Les charges prévisibles et stables (batch nocturne, rapports planifiés, files de classification) se rangent bien dans une capacité dédiée planifiée. Les charges en rafale (pics viraux, floods de tickets, lancements de nouvelle cohorte) ont besoin de l'élasticité d'une API. Les charges à latence stricte (complétion interactive, voix) bénéficient d'un déploiement dédié colocalisé. Les charges sans exigence de latence (enrichissement nocturne, ré-indexation) bénéficient des API batch à moitié prix. L'architecture qui soutient l'hybride est un routeur à la frontière applicative qui classe chaque requête par budget de latence, complexité et utilisation actuelle du backend, et l'envoie au backend le moins cher qui respecte son SLA. Un routeur raffiné fait aussi du routage inter-modèles à l'intérieur de l'API (modèle bon marché pour les requêtes simples, frontière pour les complexes, palier raisonnement pour celles qui en ont besoin). Le bénéfice de second ordre est l'optionalité : les charges peuvent migrer d'un côté à l'autre en changeant la politique du routeur, non le code applicatif. Et le cas dédié ne rentabilise souvent que parce qu'une seconde charge — qui serait sinon partie à l'API — se greffe sur le GPU déjà payé. Une équipe qui évalue le dédié sur une seule charge ne bouge en général jamais ; une équipe qui pense en portefeuille de charges le fait et économise.

Ce que prépare le Chapitre 15

Le Chapitre 15 a nommé une classe de charge que les agents ont introduite et qui n'entre ni dans « appel d'API » ni dans « service de modèle » : l'environnement d'exécution du code généré par le LLM, qui vit sur des fonctions serverless, des microVM (Firecracker, gVisor) ou des bacs à sable WASM selon l'isolation et la flexibilité de paquets dont l'agent a besoin. Le Chapitre 16 clôt le volume avec le catalogue de mouvements de réduction de coût qui s'appliquent des deux côtés de la ligne de posture : routage intelligent, compaction du contexte au niveau applicatif, API batch, cache sémantique — les mouvements qui composent jusqu'à un tiers ou la moitié de la facture du mois dernier.

Prochaine étape — Chapitre 16 : Stratégies de réduction des coûts en production. Les mouvements qui composent et qui transforment la facture du mois dernier en économies du mois prochain.