Inference engineering LLM : optimiser latence et coûts

Un LLM qui répond en 800 ms coûte dix fois moins cher à opérer qu'un LLM qui répond en 4 secondes, à volume équivalent. Pourtant, la grande majorité des équipes qui intègrent des modèles de langage traitent l'inférence comme une boîte noire : on appelle l'API, on attend, on affiche le résultat.

Réponse directe : l'inférence LLM se décompose en deux phases aux contraintes physiques opposées : le prefill (limité par la puissance de calcul brute) et le decode (limité par la bande passante mémoire). Comprendre cette distinction permet de choisir les bonnes optimisations, d'estimer les coûts réels et de décider quand l'auto-hébergement devient rentable, notamment pour les organisations soumises au RGPD.

Pourquoi l'inference engineering change les équations

Pendant des années, faire de l'IA en production signifiait appeler une API d'un grand provider américain. Cette situation évolue pour trois raisons convergentes.

Les modèles open source ont rattrapé les modèles propriétaires. Hugging Face héberge aujourd'hui plus de deux millions de modèles ouverts, contre 80 000 il y a cinq ans. Des modèles comme DeepSeek V3, Mistral Large ou Qwen 2.5 offrent des performances proches des modèles fermés sur la plupart des tâches d'entreprise. L'auto-hébergement n'est plus un compromis sur la qualité.

Le RGPD crée une contrainte réelle. L'Article 44 du RGPD interdit les transferts de données personnelles hors UE sans garanties adéquates. Le CLOUD Act américain de 2018 permet aux autorités américaines d'accéder aux données hébergées par des entreprises US, y compris sur leurs infrastructures européennes. Envoyer des documents clients, des emails ou des données contractuelles à une API hébergée en dehors de l'UE expose l'organisation à un risque réel, difficile à couvrir avec un simple DPA.

L'auto-hébergement est devenu économiquement viable. À volume suffisant, les coûts chutent d'environ 80% par rapport aux APIs publiques. Cursor a construit Composer 2.0 sur un modèle open source avec une latence d'autocomplétion inférieure à celle des APIs cloud, précisément parce que l'infrastructure dédiée permet d'optimiser pour un profil de trafic spécifique.

Comment l'inférence LLM fonctionne : prefill vs decode

Quand une requête arrive sur un LLM, deux opérations s'enchaînent sur le même GPU avec des contraintes physiques radicalement différentes.

La phase prefill traite l'intégralité du prompt d'entrée en parallèle. Le GPU fait tourner tous les tokens d'entrée simultanément à travers toutes les couches du modèle. Le résultat : le premier token de réponse, et un objet appelé KV cache (cache des valeurs d'attention intermédiaires). Cette phase est limitée par la puissance de calcul : plus il y a de flops disponibles, plus elle est rapide. La métrique principale est le TTFT (Time To First Token).

La phase decode génère chaque token suivant un par un, en séquence. Chaque token nécessite un passage complet du modèle, en lisant les poids depuis la mémoire. Cette phase est limitée par la bande passante mémoire : le GPU passe l'essentiel du temps à déplacer des données, pas à calculer. La métrique principale est le TPS (Tokens Per Second).

Cette asymétrie est la clé de l'inference engineering : une technique qui accélère le prefill n'impacte pas nécessairement le decode, et inversement.

Les 6 techniques d'optimisation principales

Batching

Le batching consiste à traiter plusieurs requêtes simultanément sur le même GPU, token par token. Le throughput augmente significativement car le GPU est utilisé à pleine capacité. Le coût : une latence par utilisateur plus élevée. Les APIs publiques maximisent le batching pour leur économie d'échelle ; un déploiement dédié peut optimiser le ratio selon le besoin spécifique (latence vs débit).

Prefix caching

Quand deux requêtes partagent un préfixe commun (un long system prompt identique pour des milliers d'utilisateurs, par exemple), le moteur d'inférence calcule ce préfixe une seule fois et réutilise le KV cache. C'est pourquoi les providers facturent moins les tokens mis en cache. Pratiquement : placer le contenu partagé en début de prompt, les variables utilisateur en fin, maximise l'efficacité du cache.

Quantisation

La quantisation réduit la précision numérique des poids du modèle : de fp16 vers int8 ou int4. Les poids occupent moins de mémoire, se chargent plus vite, et les opérations mathématiques sont plus rapides. Gain typique : 30 à 50% de meilleures performances. Le compromis : une légère dégradation de qualité sur certaines couches. En pratique, les couches d'attention sont laissées en pleine précision (les erreurs s'y accumulent), le reste est quantisé.

Speculative decoding

La génération d'un token depuis zéro est coûteuse. La vérification d'un token candidat est beaucoup plus rapide. La decoding spéculative exploite cette asymétrie : un petit modèle "draft" prédit plusieurs tokens en avance, le modèle principal vérifie tous ces tokens en un seul passage. Résultat : plusieurs tokens émis par passage au lieu d'un. Le gain porte sur le TPS, pas sur le TTFT. Cette technique est désactivée dynamiquement à fort taux de batching car le GPU est déjà saturé.

Parallélisme

Pour les grands modèles qui ne tiennent pas dans un seul GPU, deux stratégies dominent : le tensor parallelism (chaque couche répartie sur plusieurs GPUs, adapté aux modèles denses, requiert une interconnexion rapide) et l'expert parallelism (pour les modèles MoE, chaque expert sur un GPU différent). La plupart des déploiements en production combinent les deux.

Disaggregation

La disaggregation pousse la logique prefill/decode jusqu'au bout : exécuter les deux phases sur des machines séparées. Le moteur de prefill traite les prompts et envoie le KV cache via le réseau au moteur de decode. Chaque ensemble peut être dimensionné et optimisé indépendamment. C'est l'étape la plus architecturalement complexe, réservée aux déploiements à forte échelle.

Quand investir dans l'auto-hébergement ?

La question n'est pas "est-ce que l'inference engineering est mieux ?" mais "à quel stade du produit l'investissement est-il justifié ?"

Trois signaux indiquent que l'équation a basculé :

Signal	Description
Coût API	La facture API est devenue une ligne significative du P&L
Latence	Les APIs publiques ne permettent pas d'atteindre le SLA cible
Fiabilité	Les SLA du provider ne suffisent plus pour les engagements clients

Pour les organisations soumises au RGPD, un quatrième signal s'ajoute : la nature des données traitées. Si les requêtes LLM incluent des données personnelles (noms, emails, données contractuelles), l'auto-hébergement sur infrastructure EU est l'architecture la plus solide pour éviter les transferts hors UE et la portée du CLOUD Act.

Les options concrètes :

• Mistral AI (La Plateforme) : API cloud, société française, infrastructure hébergée en UE, hors portée du CLOUD Act. Solution intermédiaire avant l'auto-hébergement complet.
• Modèle open source + OVHcloud/Scaleway : Llama 3, Mistral 7B, Qwen 2.5 sur GPU loué en France ou en Allemagne. Contrôle total, coût proportionnel au volume.
• Modèle local : pour les équipes de développement ou les déploiements edge, Ollama + Gemma 4 tourne sur un bon laptop sans aucune donnée quittant la machine.

TL;DR

L'inference LLM se décompose en prefill (limité par le calcul) et decode (limité par la mémoire). Cette asymétrie explique pourquoi chaque technique d'optimisation cible une phase spécifique. En début de produit, les APIs cloud sont le bon choix. Quand les coûts, la latence ou les exigences RGPD le justifient, l'auto-hébergement sur infrastructure EU (OVHcloud, Scaleway) avec un modèle open source est l'étape suivante : contrôle total sur les données, tarif prévisible, et hors portée du CLOUD Act américain.

Vous évaluez une architecture d'inférence pour vos cas d'usage ? Discutons des contraintes de votre projet.