Contexte et motivations

Les organisations orientées IA transforment leurs équipes plateforme en équipes d’inférence pour éviter que les assistants de code n’envoient du code à des tiers et pour maîtriser la facture des modèles de pointe. Hugging Face propose plus de deux millions de modèles ouverts, dont DeepSeek R1, publié en janvier 2025, qui a égalé les performances d’OpenAI o1 sur les benchmarks de mathématiques et de programmation un mois après la sortie d’o1. En auto‑hébergeant ces modèles, les entreprises contrôlent latence, disponibilité et flux de données, tout en réduisant les coûts d’environ 80 % à fort volume.

Architecture de la pile d’inférence

Une pile d’inférence typique comporte quatre couches : les kernels (arithmétique GPU), le moteur d’inférence (ex. vLLM ou SGLang), le plan de contrôle qui déploie et orchestre les moteurs, et la passerelle qui routage les requêtes HTTP. Le moteur agit comme un serveur de base de données état‑ful, charge les poids du modèle en mémoire GPU au démarrage et maintient un état de session par conversation. Le plan de contrôle ne traite aucune requête directe, mais il gère la scalabilité en déployant plusieurs moteurs et en assurant l’observabilité, l’authentification TLS et la gestion des identités, comme l’a démontré Upbound dans son projet Champagne.

Gestion de la mémoire GPU et KV cache

Les poids d’un modèle sont stockés en GPU, non en RAM. La plupart des modèles sont publiés à 2 octets par paramètre (BF16 ou FP16) ; ainsi, un modèle de 8 B paramètres occupe ~16 GB, ce qui, sur une carte L40S de 48 GB, laisse environ deux tiers de la mémoire pour d’autres usages. Le cache KV, qui conserve les clés et valeurs d’attention pour chaque token, constitue le jeu de travail. Sa taille se calcule ainsi :

KV bytes per token = 2 × layers × KV heads × head dimension × bytes per value

Pour Llama 3 70B en FP16 (80 couches, 8 têtes KV, dimension 128), cela représente ~320 KB par token. Une conversation de 128 K tokens nécessite ~40 GB de cache, limitant le nombre d’utilisateurs simultanés sur une même carte. Les modèles MoE (Mixture‑of‑Experts) conservent tous leurs poids : un modèle de 320 B paramètres avec 18 B actifs requiert ~320 GB en FP8, alors que seul le calcul profite des paramètres actifs. Upbound a d’abord estimé la taille d’un tel checkpoint à 315 GB à partir des dtypes, mais la version réelle était de 177,7 GB grâce à un format 4‑bit.

Optimisations de coût et performances

Le prix d’une capacité IA fixe chute d’un facteur ~10 chaque année, principalement grâce aux gains d’efficacité du service plutôt qu’à l’amélioration des GPU. Sur un H100, chaque token génère 1‑2 opérations en virgule flottante par octet lu, et le processeur nécessite ~295 opérations par octet pour rester occupé, révélant un goulet d’étranglement mémoire. Le pic de calcul a progressé d’un facteur 3 tous les deux ans, contre 1,6 pour la bande passante mémoire, d’où l’importance de réduire les déplacements de données. Les benchmarks distinguent le temps jusqu’à la première token (TTFT) et le débit en tokens / seconde, car les deux phases (chargement des poids et génération) sont limitées par des contraintes opposées. Enfin, le coût par million de tokens, qui combine le prix du GPU et le débit, fournit une métrique comparable pour choisir entre hébergement interne et API tierce.