Servir un modèle IA à toute une équipe, en interne

OUTILS IA — CHOISIR, MESURER, CONTRÔLER · 06 / 10 · SERVIR UN MODÈLE EN INTERNE

Documentations éditeurs, dépôts publics et textes de licence vérifiés au 19 juillet 2026. Aucun banc d'essai n'a été réalisé pour cet article, et aucun comparatif tiers n'a servi de source.

Faire tourner un modèle de poids ouverts sur une machine est aujourd'hui une affaire d'une soirée. Une commande, un téléchargement, une fenêtre de conversation qui répond. La démonstration convainc, la direction technique valide le principe, et la décision suivante tombe naturellement : puisque cela fonctionne, ouvrons-le à l'équipe.

C'est à cet instant que le sujet change de nature. Servir un modèle à dix, cinquante ou trois cents personnes n'est pas la même opération en plus grand. C'est un autre métier : celui de l'exploitation. Il faut arbitrer un débit contre un temps de réponse, décider qui a le droit d'appeler quoi, savoir qui a consommé combien, et accepter qu'une brique technique choisie aujourd'hui puisse être abandonnée par son éditeur. Cet article traite exclusivement de ce saut. L'installation sur un poste et le choix de la taille de modèle relèvent d'autres discussions — notamment de « Quand un petit modèle local suffit » et de « Quantization : faire tourner un LLM sur sa machine ».

Une machine contre une équipe : ce qui change vraiment

Sur un poste unique, la ressource matérielle est monopolisée par un seul utilisateur qui, par construction, attend sa réponse avant de poser la question suivante. Il n'y a jamais de contention. Le pire scénario est une réponse lente, que l'utilisateur attribue à la taille du modèle et accepte sans protester.

Dès qu'un second appelant arrive, quatre problèmes apparaissent d'un coup, et aucun n'est visible sur le poste d'origine.

Le premier est la contention. Deux requêtes qui arrivent en même temps se disputent la même mémoire de carte graphique et le même calcul. Selon la manière dont le serveur est configuré, elles sont traitées ensemble, ou l'une attend l'autre. La différence entre ces deux comportements est un réglage — et c'est le sujet du paragraphe suivant.

Le deuxième est l'identité. Sur un poste, l'utilisateur est le propriétaire de la machine. Sur un service partagé, il faut savoir qui appelle, sous peine de ne pouvoir ni limiter, ni facturer en interne, ni répondre à la question « qui a envoyé ce document au modèle ».

Le troisième est la disponibilité. Un service que dix personnes utilisent quotidiennement devient une dépendance de travail. Son arrêt n'est plus un désagrément personnel mais une interruption d'activité, avec les obligations que cela entraîne : redémarrage automatique, supervision, fenêtre de maintenance annoncée.

Le quatrième est la réversibilité. Le choix du moteur d'inférence engage l'organisation sur plusieurs années. Or ce marché bouge vite, et le meilleur exemple est aussi le plus brutal : le moteur Text Generation Inference de Hugging Face, longtemps la recommandation par défaut de l'un des plus gros acteurs de l'écosystème, est passé en mode maintenance puis a été archivé par son propriétaire le 21 mars 2026, en lecture seule. Ses mainteneurs renvoient explicitement vers d'autres projets. Une équipe qui avait bâti son exploitation dessus a dû migrer, non pour un défaut technique, mais parce que l'éditeur a cessé de le porter.

Débit, concurrence, temps de réponse : les trois grandeurs à arbitrer

Trois grandeurs gouvernent un service d'inférence partagé, et elles ne peuvent pas être maximisées ensemble.

Le débit est le nombre de jetons produits par unité de temps, tous appelants confondus. C'est la grandeur qui mesure la rentabilité du matériel. La concurrence est le nombre de requêtes traitées simultanément. Le temps de réponse est ce que perçoit l'utilisateur : le délai avant le premier mot, puis la vitesse de défilement du texte. Augmenter la concurrence augmente le débit total, jusqu'au point où chaque requête individuelle ralentit assez pour que l'expérience se dégrade. Le mécanisme sous-jacent est détaillé dans « D'où vient la latence : batching, streaming ».

La technique qui permet d'arbitrer entre ces trois grandeurs porte un nom : le batching continu, aussi appelé traitement par lots dynamique. Plutôt que d'attendre qu'une requête soit terminée pour commencer la suivante, le serveur entrelace les générations en cours et insère les nouvelles requêtes dans le lot dès qu'un emplacement se libère. C'est la différence structurelle entre un moteur de service et un moteur de poste de travail.

Et c'est ici que se trouve le fait le plus utile de cet article. La documentation officielle d'Ollama indique que la variable OLLAMA_NUM_PARALLEL, qui définit « le nombre maximal de requêtes parallèles que chaque modèle traitera en même temps », a pour valeur par défaut 1. La même page indique que OLLAMA_MAX_QUEUE, nombre de requêtes mises en file d'attente avant rejet, vaut 512 par défaut. Autrement dit : sorti de la boîte, l'outil le plus répandu pour faire tourner un modèle en local sert une seule requête à la fois par modèle, et empile poliment les cinq cent onze autres.

La file d'attente ne produit aucune erreur. Chaque requête finit par être servie, chaque utilisateur voit sa réponse arriver, et le seul symptôme est une lenteur que chacun attribue à la taille du modèle. C'est un problème de configuration qui se présente comme un problème de matériel.

En face, la documentation de llama-server, le serveur de llama.cpp, annonce « Parallel decoding with multi-user support », expose une option -np, --parallel qui fixe le nombre d'emplacements de service, et surtout documente -cb, --cont-batching — le batching continu — avec la mention « default: enabled ». Un point de terminaison GET /slots permet en outre de consulter l'état d'occupation de chaque emplacement, ce qui donne une observabilité immédiate de la contention.

Deux outils issus du même écosystème de poids ouverts, deux valeurs par défaut opposées. L'écart entre « ça marche sur ma machine » et « ça sert une équipe » tient littéralement en une ligne de documentation.

Le moteur d'inférence n'est pas l'interface — et il y a une troisième couche

La confusion la plus fréquente consiste à traiter « le serveur IA interne » comme un objet unique. Il en faut trois, et les confondre revient à demander à chaque brique un travail qu'elle ne sait pas faire.

Le moteur d'inférence exécute le modèle. Il charge les poids, gère la mémoire de la carte graphique, applique le batching continu et expose une interface programmatique. Il ne connaît ni les comptes utilisateurs, ni les quotas, ni les conversations. Trois projets vivants occupent ce rôle : vLLM, dont la documentation annonce un « state-of-the-art serving throughput », le batching continu et un serveur compatible avec l'interface programmatique la plus répandue ; SGLang, présenté comme un cadriciel de service haute performance et cité nommément par Hugging Face parmi les successeurs recommandés du moteur archivé ; et llama-server, déjà évoqué.

La passerelle se place devant un ou plusieurs moteurs. C'est elle qui porte l'identité, les clés d'accès, les plafonds de consommation, la répartition de charge et la journalisation. LiteLLM occupe ce rôle : décrite comme une passerelle IA open source offrant une interface unifiée vers plus de cent fournisseurs de modèles, elle se déploie en serveur mandataire et documente des clés virtuelles, un suivi de dépense, des garde-fous, de la répartition de charge et de la journalisation.

L'interface est ce que voient les utilisateurs : conversations, historique, partage de gabarits de consigne, téléversement de documents. Open WebUI est la brique la plus installée de cette couche. Elle n'exécute aucun modèle.

Les trois couches se branchent en série et ne se substituent pas. Sauter la passerelle est le raccourci le plus courant : l'interface parle directement au moteur, et l'organisation se retrouve sans plafond de consommation, sans clé révocable et sans journal exploitable.

Le raccourci qui consiste à brancher l'interface directement sur le moteur fonctionne parfaitement en démonstration. Il devient coûteux le jour où il faut couper l'accès d'une personne qui quitte l'organisation, ou répondre à une question d'audit sur ce qui a été envoyé au modèle.

Comptes, quotas, journalisation : la partie qu'on découvre trop tard

Un service interne d'inférence traite, par définition, des données de l'organisation. Les trois obligations qui en découlent ne sont ni exotiques ni négociables, et ce sont celles qu'aucun tutoriel d'installation n'aborde.

L'authentification d'abord : chaque appel doit être rattaché à une identité, idéalement issue de l'annuaire existant plutôt que d'une liste de comptes tenue à part. La bonne nouvelle est que cette couche est plus accessible que sa réputation ne le laisse croire — la section suivante montre où passe exactement la ligne payante.

Les quotas ensuite. Un service sans plafond individuel est un service dont un seul appelant automatisé peut consommer toute la capacité. La forme utile n'est pas un quota d'usage confortable, mais une limite par identité que l'administrateur système peut abaisser sans redéployer quoi que ce soit. C'est précisément ce que fournit une clé virtuelle de passerelle.

La journalisation enfin. Elle sert trois usages distincts qu'il faut décider séparément : la répartition des coûts entre équipes, le diagnostic d'incident, et la réponse à une demande de conformité. Ces trois usages n'exigent pas la même profondeur d'enregistrement — la question de savoir si l'on conserve le contenu des requêtes ou seulement leurs métadonnées est une décision de politique interne, pas un réglage technique, et elle rejoint les arbitrages exposés dans « Garder ses données en Europe ».

Ces trois obligations sont la vraie raison d'être d'un service interne. Une organisation qui héberge un modèle pour « ne pas envoyer ses données dehors » et qui ne journalise rien n'a pas réglé son problème de gouvernance : elle l'a déplacé sur une machine dont personne ne surveille les entrées.

Panorama des briques, et le piège de licence inversé

Le réflexe courant consiste à supposer que, dans un projet à modèle ouvert, les fonctions d'équipe — comptes, rôles, authentification centralisée — sont la partie réservée à l'offre commerciale. Sur les deux briques les plus installées de cette pile, ce réflexe se trompe, et il se trompe dans deux directions opposées.

Chez Open WebUI, la gestion d'équipe est gratuite. La documentation officielle décrit en édition communautaire l'authentification centralisée par OAuth, OIDC ou en-tête de confiance, l'annuaire d'entreprise et les rôles, ainsi que l'approvisionnement automatique des comptes et des groupes par SCIM 2.0. Ce qui est encadré, c'est autre chose : la marque. Le texte de licence du projet interdit d'altérer, retirer ou masquer les marques « Open WebUI », sauf dans trois cas — dont un déploiement de cinquante utilisateurs finaux ou moins sur toute période glissante de trente jours, une autorisation écrite, ou une licence entreprise.

Chez LiteLLM, la ligne de partage est exactement inversée. Les clés virtuelles, le suivi de dépense et la journalisation de base appartiennent au cœur open source ; en revanche, l'authentification centralisée est commerciale, au même titre que le support professionnel et les contrôles d'administration multi-locataires avancés, couverts par une licence commerciale distincte.

Deux briques de la même pile, deux lignes de partage opposées. L'une offre l'authentification d'entreprise et facture l'apparence ; l'autre offre les quotas et facture l'authentification. Aucune règle générale ne permet de deviner : il faut lire chaque licence, brique par brique.

Le calcul de bascule : à partir de quand l'interne coûte plus cher

La justification habituelle d'un service interne est l'économie. Elle est réelle, mais elle se calcule mal, parce que la comparaison spontanée oppose un abonnement mensuel visible à un serveur dont on ne compte que l'amortissement.

Trois postes manquent presque toujours au calcul. Le premier est le temps d'exploitation : mises à jour de moteur, surveillance, gestion des comptes, réponses aux incidents. Ce n'est pas un coût d'installation, c'est une charge récurrente qui pèse sur une compétence rare. Le deuxième est la capacité de pointe : un service interne se dimensionne sur son pic, pas sur sa moyenne, et le matériel inoccupé la nuit coûte le même prix. Un service hébergé, lui, se facture à l'usage réel. Le troisième est le coût de migration, que l'archivage du moteur de Hugging Face rend concret : il faut provisionner le fait qu'une brique changera.

Reste la question du matériel, et c'est ici qu'un constat mérite d'être énoncé franchement.

Ce que les éditeurs documentent en revanche, c'est le levier. La mémoire de la carte se partage entre deux consommateurs : les poids du modèle, qui sont une constante une fois la taille et la précision choisies, et le cache clé-valeur, qui croît avec le nombre de requêtes simultanées multiplié par la longueur de contexte de chacune. C'est ce second terme qui décide de la capacité réelle du service, et c'est celui que la démonstration sur un poste unique ne révèle jamais — un seul utilisateur n'occupe qu'un exemplaire du cache.

Les réglages qui le pilotent sont nommément documentés. Du côté de vLLM : gpu_memory_utilization, dont la valeur par défaut est 0,90, ainsi que max_num_seqs, max_num_batched_tokens et --max-model-len. Du côté d'Ollama, OLLAMA_NUM_PARALLEL, dont la documentation indique explicitement que le besoin mémoire lui est proportionnel. La question à poser n'est donc pas « quelle carte pour ce modèle », mais « combien d'utilisateurs simultanés, sur quelle longueur de contexte » — et la réponse se relève sur votre propre trafic. Réduire la taille du modèle est l'autre levier, exploré dans « Distillation et petits modèles ».

Comment le vérifier vous-même

Rien de ce qui précède ne remplace un relevé sur votre installation. Les documentations décrivent des valeurs par défaut et des licences, pas le comportement de votre service sous la charge de votre équipe. Le protocole ci-dessous ne demande aucun outil de mesure spécialisé et se conduit en une journée.

Servir un modèle en interne est un projet légitime, et souvent le bon choix. Mais c'est un projet d'exploitation, qui se juge sur des grandeurs d'exploitation : combien d'appelants simultanés, dans quel délai, sous quelle identité, avec quelle trace, et à quel coût de reprise si la brique choisie disparaît. La bonne façon d'entrer dans le sujet n'est pas de comparer des cartes graphiques, mais d'ouvrir la documentation de votre moteur à la page des valeurs par défaut, et d'envoyer deux requêtes en même temps.

Une question, un projet IA ?

Vous envisagez d'ouvrir un modèle interne à vos équipes et cherchez à dimensionner l'exploitation — échangeons sur votre contexte et vos contraintes.

Prendre contact →

Pour aller plus loin : côté mécanique, notre article sur l'origine de la latence — batching, streaming détaille ce qui se joue à l'intérieur d'un lot de requêtes, et « Quantization : faire tourner un LLM sur sa machine » traite du levier de réduction des poids. Côté décision, « Quand un petit modèle local suffit » pose la question en amont. L'ensemble de nos décryptages de concepts IA reste consultable en accès libre.