Peut-on mettre en place un serveur LLM auto-hébergé pour 300 utilisateurs ?

• Synthèse d’une question et des réponses publiées sur le subreddit Reddit /r/ollama
• En tant qu’administrateur système d’un cabinet juridique d’environ 300 personnes, l’auteur souhaite fournir à l’ensemble du personnel un outil de rédaction et de relecture de documents basé sur l’IA, similaire à ChatGPT
• Pour protéger les informations sensibles comme les PII, il envisage d’héberger directement un LLM sur un serveur interne plutôt que d’utiliser un service externe, avec contrôle d’accès via connexion, 2FA, VPN, etc.
• Questions principales
  • Un serveur LLM auto-hébergé peut-il réellement prendre en charge plus de 300 utilisateurs ?
  • Il pensait qu’une poignée de PC + GPU suffirait, mais a-t-il en réalité fortement sous-estimé l’ampleur du projet ?
  • La création et la gestion des utilisateurs peuvent-elles devenir une lourde contrainte ?
  • Y a-t-il des points importants oubliés dans cette réflexion ?
• N’étant pas spécialiste des LLM, il demande des conseils réalistes sur la scalabilité, la charge d’exploitation et la faisabilité

Résumé des principales réponses

1. Limites matérielles, performances et coûts

• Si l’on vise un niveau proche des modèles commerciaux (ex. ChatGPT), il faut un cluster de GPU très coûteux, potentiellement de plusieurs centaines de milliers d’euros (estimation $200,000~$1,000,000+)
• En se rabattant sur des modèles open source (30B à 70B paramètres), il faut accepter une baisse de performance (latence, qualité des réponses). Même 10 à 40 utilisateurs simultanés peuvent déjà représenter une limite
• Recommandation fréquente : partir sur une hypothèse de moins de 10 utilisateurs simultanés, puis étendre progressivement en ajoutant des serveurs
• La location de GPU dans le cloud peut être plus économique et plus flexible qu’un déploiement purement local

2. Recommandation d’un PoC (pilote) et d’une approche progressive

• Il est conseillé de construire un PoC (pilote) avec 1 serveur + 1 GPU, puis d’élargir après avoir mesuré les scénarios réels d’usage et la charge
• En cas de nombreuses requêtes simultanées, un système de file d’attente devient indispensable ; dans la pratique, la simultanéité réelle peut être de 10 à 30 utilisateurs, et non 300
• À court terme, il est possible d’expérimenter avec de petits modèles (3B à 13B paramètres) sur une station de travail

3. Cloud, hybride et options alternatives

• Proposition d’une architecture hybride reliant des LLM cloud (API, VPS, Azure, AWS Bedrock, etc.) à l’infrastructure interne, selon les exigences de sécurité
• L’auto-hébergement entraîne une charge élevée en sécurité, performance et coût ; dans les faits, des solutions commerciales comme ChatGPT Enterprise/Teams ou Microsoft Copilot Studio peuvent être plus efficaces
• Les exigences de sécurité liées aux données juridiques et aux PII doivent être examinées avec soin

4. Autres enjeux d’exploitation, d’administration et techniques

• Gestion des utilisateurs / authentification : peut être simplifiée via intégration AD, OAuth ou authentification maison
• Choix et tuning du modèle : il est recommandé de tester des modèles open source petits à moyens (LLama, Deepseek, Gemma, Qwen, etc.) adaptés à l’usage réel, comme la relecture documentaire
• Il faut aussi envisager l’ajout de solutions comme RAG, caching, répartition de charge, etc.
• Il est nécessaire de définir précisément les scénarios d’usage et de valider le budget/ROI via un PoC

Synthèse des réponses représentatives

ithkuil

• Comparés aux modèles commerciaux, les modèles open source présentent un écart important de performance, et pour 300 personnes, il pourrait falloir un matériel coûtant plusieurs centaines de milliers d’euros
• Il reste toutefois raisonnable d’espérer des progrès du matériel et des modèles open source dans les deux prochaines années

SlimeQ

• Recommande de commencer à petite échelle avec une instance unique + file d’attente, puis d’étendre progressivement selon l’augmentation de l’usage
• Les 300 personnes ne pourront pas toutes l’utiliser en même temps ; il faut mesurer l’usage réel avant de décider d’une montée en charge

Ok-Internal9317

• Le nombre réel d’utilisateurs simultanés pourrait être inférieur à 10, et 4 à 5 GPU pourraient alors suffire
• Sur le long terme, le coût d’une API peut être plus avantageux qu’un matériel en propre

dyoh777

• Une démo simple est possible avec Ollama + WebUI, mais la qualité du modèle reste déterminante

careful-monkey

• Il est possible d’exécuter de petits modèles sur un Mac Studio + grande quantité de RAM, avec une vitesse d’environ 20 tokens/sec

tshawkins

• Recommande des solutions SaaS comme Microsoft Copilot Studio, intégrées à la Power Platform

roman_fyseek, Cergorach, Space__Whiskey

• Limites de VRAM des modèles : 1 session = 1 GPU, donc 300 utilisateurs simultanés = 300 GPU
• En pratique, il faut donc limiter les connexions simultanées et prévoir caching et architecture hybride

Siderox, SandboChang, unrulywind

• Conseillent d’expérimenter d’abord avec un petit serveur en PoC (ex. 1 à 2 utilisateurs / modèle, validation sur de vrais usages), puis d’étendre progressivement
• Le budget et le ROI doivent être validés après définition des scénarios réels et benchmarking

Little_Marzipan_2087, morosis1982, Daemonero

• La location de GPU dans le cloud est moins chère et plus scalable, et constitue une solution fréquemment utilisée
• Compte tenu de la charge d’exploitation et de maintenance, ils recommandent le cloud plutôt qu’un investissement matériel

CtiPath, alew3, faldore, Wheynelau

• Recommandent des frameworks de serveurs LLM open source performants comme vLLM, OpenWebUI, TGI, sglang, etc.
• Préconisent une architecture avec file d’attente + load balancer

Divers

• Enjeux de sécurité / juridiques : même en cas d’usage du cloud, il faut examiner rigoureusement localisation des données, chiffrement, conformité réglementaire, etc.
• Plusieurs options matérielles sont mentionnées, comme Mac Studio, RTX 6000 Pro, 4090, etc.
• Il est possible de réduire la charge via caching, RAG, limites de contexte, offload, etc.

Résumé de la conclusion

• Un serveur LLM auto-hébergé doit de manière réaliste commencer par un petit pilote (PoC), puis valider par étapes les volumes d’usage réels, les exigences, les performances et les coûts
• Gérer 300 utilisateurs simultanés implique une charge matérielle et opérationnelle importante ; selon les usages et le budget, des solutions cloud, hybrides ou commerciales peuvent être plus adaptées
• Au final, il faut prendre en compte de manière globale la sécurité, les coûts, l’expérience utilisateur et la maintenance

[xodnrdl201]

Je pense que vous avez défini de manière trop large le niveau de raisonnement requis pour les tâches traitées par ces 300 utilisateurs. Si l’objectif est vraiment de couvrir de la culture générale très basique jusqu’aux articles de recherche ou à des sujets avancés, alors cette approche se tient. Mais si l’on considère le niveau réel des tâches à traiter en entreprise, la plupart pourraient probablement être gérées avec un modèle d’environ 30B accompagné de RAG. À force de vouloir s’appuyer sur toutes les pondérations d’un socle open source pour obtenir un haut niveau de raisonnement et de fonctionnalités, n’avez-vous pas fini par dimensionner l’ensemble de façon excessive ?? Et je pense aussi qu’il serait plus pertinent de séparer en fonctions distinctes le traitement immédiat d’un côté, et la recherche/exploration documentaire de l’autre.
Pour la plage de tokens visée par le KV cache pour 300 utilisateurs simultanés, si l’on part sur quelque chose comme 20 000 tokens quantifiés par utilisateur, cela devrait déjà laisser une marge confortable ; là aussi, c’est peut-être surestimé... ??
À moins que ces 300 personnes ne soient toutes des doctorants en train de rédiger des articles scientifiques, il me semble qu’en visant un niveau de raisonnement de lycéen avec un modèle de 14 à 30B, puis en configurant l’exploration de divers documents internes via une logique RAG avec un CoT adapté, on pourrait probablement monter un projet pilote à un coût raisonnable.

[tsboard]

Moi aussi, par nécessité, je construis une solution RAG en utilisant 4 GPU H100, ces fameux modèles si difficiles à obtenir. Mais quand on prend en compte non seulement l’investissement matériel direct, mais aussi la facture d’électricité, les coûts d’une solution de refroidissement et le reste, je me suis souvent dit qu’il valait largement mieux simplement appeler une API.

J’ai moi aussi commencé par faire des tests avec Ollama, puis après avoir constaté que cela ne couvrait même pas correctement 3 utilisateurs simultanés, je suis immédiatement passé à vLLM et, tant bien que mal, j’ai mis en place une configuration de solution RAG. Mais rien que pour cela, en partant de l’hypothèse de 10 utilisateurs simultanés, il faut déjà utiliser presque à fond 2 GPU H100. J’ouvre aussi les tâches d’embedding et de recherche avec vLLM, et même avec 4 H100, c’est vraiment très juste. Pourtant, chaque carte dispose d’environ 90 Go de VRAM.

Bien sûr, je ne m’y connais pas vraiment en IA, et comme j’essaie juste de faire quelque chose qui réponde aux besoins de mon service tout en respectant tant bien que mal les règles de sécurité internes, je fonce un peu tête baissée... Mais je me demande si c’est vraiment la bonne approche. C’était ChatGPT Enterprise, non ? Franchement, je trouve que c’est un prix incroyablement avantageux.

[chinnotching]

Il suffirait sans doute d’une sacrée machine à un prix imbattable ? Un gros cabinet d’avocats l’achèterait sans hésiter. Mais bon, ce serait comme faire tourner une machine d’usine 24 h/24, lol.

[neinomu]

Une personne qui ne pense qu’au prix d’une Porsche sans accorder la moindre attention aux frais d’entretien, au carburant, à l’assurance, etc.

[beepp]

Pour un service de type chatbot qui doit proposer une fonctionnalité de streaming, lors du traitement simultané, l’étape de prefill est affectée jusqu’au decode ; ainsi, même si la VRAM est suffisante, du point de vue de l’utilisateur, on a l’impression que les performances se dégradent fortement.

J’ai aussi testé les options liées au chunk prefill ainsi que la fonctionnalité expérimentale de Disaggregated Prefilling proposée par vLLM, mais dès qu’une nouvelle requête arrive, les réponses déjà en cours de génération continuent de se couper par à-coups. En tant que développeur débutant, je me demande donc s’il existe une méthode plus efficace que d’augmenter simplement le nombre de GPU ou de nœuds.

[iolothebard]

Comme toujours… ça dépend !