Quand vous posez une question à ChatGPT ou à un assistant basé sur Mistral, votre texte voyage jusqu’à une machine distante qui héberge un modèle de langage. Cette machine, avec tout ce qui l’entoure (logiciel de file d’attente, gestion mémoire, API), constitue ce qu’on appelle un serveur LLM. Comprendre son rôle permet de mieux choisir entre cloud et local, et de dimensionner correctement une infrastructure d’inférence.
Serveur LLM : la différence entre inférence et serving
On confond souvent deux opérations. L’inférence, c’est le calcul brut : le modèle de langage reçoit votre prompt et génère une réponse token par token. Le serving, c’est tout le reste.
A lire également : Qu'est-ce qu'un logiciel autonome ?
Le serving ajoute une couche opérationnelle qui gère la file d’attente des requêtes, regroupe dynamiquement plusieurs demandes pour optimiser le GPU, route le trafic entre plusieurs cartes graphiques et diffuse les tokens au fur et à mesure de leur génération. C’est souvent le serving, pas le modèle, qui détermine la latence ressentie par l’utilisateur final.
Prenez l’analogie d’un restaurant. Le chef en cuisine, c’est le modèle. Le serveur LLM, c’est l’ensemble : la cuisine, le système de commandes, la salle, le personnel qui coordonne les plats pour que chaque table soit servie dans un délai raisonnable. Un excellent chef dans une organisation chaotique produit un service médiocre.
A voir aussi : Pourquoi les LLM ont-ils autant de paramètres ?
Prefill et decode : les deux phases d’une requête sur un serveur LLM
Chaque requête envoyée à un serveur LLM traverse deux étapes distinctes, et elles ne sollicitent pas les mêmes ressources.
Le prefill traite le prompt initial
Quand vous envoyez un texte de 500 mots au modèle, la phase de prefill analyse l’ensemble du prompt en parallèle. Cette étape exploite bien la puissance de calcul brute des GPU, car tous les tokens d’entrée sont traités simultanément.
Le decode génère la réponse mot par mot
La phase de decode produit ensuite les tokens de réponse un par un. Chaque nouveau token dépend du précédent. Cette étape séquentielle devient sensible à la mémoire disponible et au nombre d’utilisateurs simultanés plutôt qu’à la seule puissance de calcul.
Vous avez déjà remarqué qu’un assistant IA met parfois une seconde avant de commencer à répondre, puis enchaîne fluidement ? Ce délai initial correspond au prefill. La vitesse d’affichage ensuite reflète le decode.
Mémoire GPU : poids du modèle et cache KV
La mémoire des cartes graphiques est la ressource la plus critique d’un serveur LLM. Elle se partage entre deux postes concurrents.
- Les poids du modèle occupent un espace fixe. Un modèle plus grand (davantage de paramètres) consomme plus de mémoire GPU, quelle que soit la charge.
- Le cache KV (key-value) stocke l’état des tokens déjà traités pour chaque conversation active. Plus le contexte est long et plus il y a d’utilisateurs simultanés, plus ce cache grossit.
- Si la mémoire GPU est saturée par ces deux postes, le serveur ne peut plus accepter de nouvelles requêtes, même si la puissance de calcul reste disponible. Le débit chute.
C’est pour cette raison qu’un serveur avec un GPU très puissant mais doté de peu de mémoire vidéo peut se retrouver bloqué dès que plusieurs utilisateurs envoient des conversations longues. La capacité mémoire compte autant que la puissance de calcul pour dimensionner un serveur d’inférence.
Architecture d’un serveur LLM en production
Un serveur LLM qui dépasse le stade du prototype repose généralement sur trois couches empilées.
La première, c’est l’engine d’inférence. Des outils comme vLLM ou llama.cpp chargent les poids du modèle et génèrent les tokens. C’est le moteur.
La deuxième couche, c’est la couche de serving. Elle expose une API (souvent compatible avec le format OpenAI), gère le batching dynamique des requêtes et distribue la charge entre plusieurs GPU si nécessaire. Sans cette couche, chaque requête attendrait que la précédente soit entièrement terminée.
La troisième, c’est la couche de routage et d’orchestration. Elle intervient quand plusieurs modèles cohabitent sur la même infrastructure, ou quand on veut basculer entre un modèle léger pour les questions simples et un modèle plus lourd pour les tâches complexes.
Serveur LLM cloud ou serveur local : critères de choix concrets
La question revient systématiquement. Faut-il utiliser une API cloud (OpenAI, Anthropic, Mistral) ou héberger son propre serveur LLM ?
Le critère déterminant, c’est le volume de tokens traités. Une API cloud facture chaque token consommé. Un serveur local représente un investissement matériel initial (GPU, mémoire, alimentation), mais le coût par token devient ensuite quasi nul.
- Pour un usage occasionnel ou un prototype, l’API cloud est plus simple et moins coûteuse. Pas de matériel à maintenir, pas de compétence système requise.
- Pour un usage intensif avec des données sensibles (documents internes, données clients, secteur réglementé), un serveur local évite toute sortie de données vers un tiers. Les requêtes ne quittent jamais le réseau de l’entreprise.
- Pour un usage intermédiaire, certaines entreprises combinent les deux : un modèle local pour les tâches courantes et une API cloud pour les requêtes qui nécessitent un modèle de langage plus puissant.
La confidentialité des données est un argument réel, mais c’est rarement lui seul qui justifie l’investissement. C’est la combinaison volume plus confidentialité qui fait basculer la décision vers le local.
Dimensionner un serveur LLM demande de penser au-delà du modèle de langage lui-même. La mémoire GPU, la gestion du cache KV, le batching des requêtes et l’architecture de serving pèsent autant que le choix du modèle sur la qualité de service. Avant de choisir entre cloud et local, estimez d’abord votre volume de tokens mensuel et le niveau de confidentialité requis : ces deux paramètres orientent tout le reste.
