Demandez à une équipe pourquoi elle a renoncé à héberger elle-même son modèle : la réponse est rarement que le modèle était insuffisant. C'est la mémoire qui manque. Pendant qu'un modèle écrit, il doit tenir un cache des clés et des valeurs pour chaque requête dans la mémoire graphique, et les moteurs classiques réservent cette place d'un seul bloc, dimensionné sur la plus longue sortie qu'une requête pourrait produire. Ce qu'une requête courte n'utilise pas reste vide, et la fragmentation fait le reste. Le projet ouvert vLLM, sorti en 2023 d'un groupe de recherche universitaire, a pris une autre voie : il a transporté sur la carte graphique la gestion par pages dont les systèmes se servent pour la mémoire ordinaire. La technique, nommée PagedAttention, est devenue depuis l'une des idées les plus citées du domaine, le projet a dépassé les 91 000 marques d'intérêt, et la version stable actuelle est parue en septembre 2026.

Le mécanisme se suit aisément. Le cache n'est plus réservé par requête mais découpé en blocs de taille fixe, et une table de blocs note où se trouvent ceux de chaque requête ; on distribue au fur et à mesure de l'usage. La fragmentation disparaît presque ; selon les chiffres du projet, l'occupation de la mémoire passe des trois ou quatre dixièmes de l'ancienne méthode à plus de neuf, et la même carte sert deux à quatre fois plus de requêtes en même temps. Par-dessus vient le traitement par lots continu : une requête n'attend plus qu'un lot se remplisse, elle entre quand elle arrive et sort dès qu'elle a fini, ce qui creuse encore l'écart lorsque travaux longs et courts partagent la machine. Dans plusieurs mesures indépendantes, le débit total sur une carte a atteint deux à cinq fois celui de la solution comparée, et une simultanéité qui exigeait plusieurs cartes tient désormais sur une seule.

Pour les équipes d'ingénierie, l'autre choix décisif est l'interface. Un service parlant le format de requête des grands hébergeurs est intégré : du code déjà écrit dans ce style bascule vers un modèle auto-hébergé en changeant une adresse, sans qu'une ligne de logique métier ne bouge. Le reste de ce qu'il faut en production vient le plus souvent avec : le calcul réparti sur plusieurs cartes distribue un grand modèle ; un service peut porter plusieurs adaptateurs LoRA et passer de l'un à l'autre selon la requête, si bien qu'un seul déploiement couvre plusieurs domaines étroits ; un cache de préfixe laisse les requêtes partageant une même consigne réutiliser des blocs déjà calculés, ce qui raccourcit l'attente avant le premier mot dans une application de conversation ; la quantification couvre AWQ, GPTQ et FP8 ; et les chiffres sortent dans un format que la surveillance existante comprend déjà.

Sa place mérite la même netteté. vLLM est un cadre de service pour cartes de classe serveur, sans interface graphique, et son terrain est de transformer des modèles ouverts de sept à soixante-dix milliards de paramètres en service en ligne qui tient sous la charge. La conversation légère sur un ordinateur personnel n'est pas son affaire ; les outils de bureau y conviennent mieux. La licence est permissive, l'usage commercial et la reprise ne rencontrent aucun obstacle, et les grandes maisons de l'infrastructure le font couramment tourner comme moteur en dessous. Si les outils plus commodes ont abaissé la barre pour faire tourner un modèle, vLLM répond à l'autre question : est-ce que cela tient. Dès que l'auto-hébergement quitte l'essai pour la production, cette couche est difficile à contourner.

Deux sortes de gens échouent ici : l'ingénieur de plateforme à qui l'on a remis un modèle et une facture de cartes, et l'équipe qui doit garder l'ensemble derrière ses propres murs. Ni l'un ni l'autre ne veut une fenêtre de conversation. Ils veulent un service qui ne tombe pas, et ils acceptent de lire un fichier de réglages pour l'obtenir.

Pas de fenêtre de conversation ni d'historique : un point d'accès et le calcul derrière - c'est précisément pourquoi, caché derrière un produit à soi, il laisse libre la forme de la façade.

Séparer le fait de tourner de celui de tenir laisse cette couche sans remplaçant.

Recevoir plus de requêtes sans ajouter de carte suffit déjà à changer un devis : si la même machine en sert deux à quatre fois plus, le nombre d'utilisateurs tenus pour un même budget suit. L'écart pèse d'autant plus que la charge mêle requêtes longues et courtes.