Serveur d'inférence

Du modèle au service

Un modèle téléchargé n'est qu'un fichier de poids. Pour répondre à des utilisateurs, il faut un programme qui charge ces poids en mémoire, reçoit les requêtes, découpe le texte en tokens, calcule les sorties et renvoie la réponse. Ce programme expose une interface HTTP, le plus souvent compatible avec le format des grandes API, ce qui permet de changer de moteur sans réécrire l'application. C'est lui, et non le modèle seul, qui détermine le débit et la stabilité du service.

Le serveur d'inférence gère aussi ce que l'on ne voit pas : la file d'attente quand les demandes arrivent plus vite que le matériel ne les traite, la libération de la mémoire entre deux requêtes, la gestion des erreurs et les journaux. En production, ces fonctions banales expliquent la plupart des incidents, bien avant la qualité du modèle lui-même ou la finesse de vos prompts. Un moteur mal réglé peut saturer une carte graphique tout en affichant un temps de réponse correct sur les premières requêtes.

Les moteurs et leur mémoire

Plusieurs moteurs open source occupent ce rôle. vLLM et le serveur d'inférence de Hugging Face visent le débit sur GPU, avec un traitement par lots continu qui remplit la carte au lieu d'attendre la fin de chaque requête. llama.cpp et Ollama ciblent plutôt le poste de travail ou le petit serveur, avec des formats quantifiés qui réduisent l'empreinte mémoire au prix d'une légère perte de qualité. Le choix dépend du volume attendu et du matériel disponible, rarement du seul classement public.

La mémoire est le facteur limitant. Chaque conversation conserve un cache d'attention qui grandit avec la longueur du texte et le nombre d'utilisateurs simultanés. La quantification des poids, sur huit ou quatre bits, permet de loger un modèle plus grand sur une carte donnée. Le choix se fait donc entre taille du modèle, longueur de contexte, nombre d'utilisateurs et coût du matériel, et ces quatre paramètres se déplacent ensemble dès que l'un d'eux change. Allonger le contexte réduit donc directement le nombre d'utilisateurs simultanés que la carte peut servir.

Dimensionner et surveiller

Le dimensionnement part d'un usage réel : nombre de requêtes par heure, longueur moyenne des échanges, tolérance à l'attente. Un assistant interne utilisé par une équipe n'a pas les mêmes contraintes qu'un service client ouvert. Il vaut mieux mesurer le débit sur vos propres textes que de se fier à un chiffre constructeur, car la langue, la longueur et le format des réponses changent la charge réelle, parfois du simple au triple.

La supervision doit suivre la latence, le taux d'erreur, l'occupation mémoire et la qualité des réponses. Un serveur qui répond vite mais renvoie des sorties tronquées ou des coupures de contexte dégrade silencieusement le service sans alerter personne. Les journaux, la limitation de débit et une procédure de redémarrage propre font partie du livrable autant que le matériel et le modèle installé. Une alerte sur la mémoire évite le plantage brutal ; une alerte sur la latence évite la dégradation lente que les utilisateurs finissent par contourner.