IA auto-hébergée de niveau entreprise
Dans cet article, nous partageons la manière dont Saphes IT Systems aborde l'IA auto-hébergée de niveau entreprise depuis le départ. Nous avons choisi cette voie pour deux raisons principales : répondre à des exigences strictes de conformité, et garder un contrôle complet au lieu de dépendre d'un fournisseur unique.
Notre travail touche souvent à la propriété intellectuelle et à des données client sensibles. Envoyer des connaissances internes ou des assets propriétaires à un fournisseur d'IA externe sans garanties solides pose une question simple : que se passe-t-il si l'on donne notre IP gratuitement ?
Après plus de deux ans d'expérimentations concrètes en conditions de production, nous avons développé une vraie expertise dans la conception et l'exploitation d'une stack d'IA auto-hébergée compétitive. Aujourd'hui, cette expérience se traduit par une plateforme conforme, contrôlable, mais aussi rapide et souvent beaucoup plus rentable que certaines alternatives.
Dans les sections suivantes, nous passons en revue les briques principales d'une infrastructure d'IA auto-hébergée :
- Matériel et dimensionnement : planification basée sur la capacité et les SLO.
- Stratégie modèles : quels modèles lancer, pour quels usages, et comment gérer leur cycle de vie.
- Stack logicielle : inférence, orchestration, RAG et observabilité.
Matériel et dimensionnement
Le dimensionnement commence par quelques objectifs simples : nombre d'utilisateurs attendus, pic de concurrence, latence acceptable (temps avant le premier token et tokens/sec), et type de charge (chat, RAG, batch, embeddings). À partir de là, on peut choisir :
- Compute : CPU ou GPU, type de GPU (grand public ou datacenter), et quantité de VRAM selon la taille du modèle, le contexte et le batch.
- Mémoire et stockage : assez de RAM pour les services annexes, et du stockage local rapide pour les poids des modèles et les caches.
- Réseau : une faible latence entre l'inférence et les services autour, comme la base vectorielle, le stockage et l'observabilité.
Pour des équipes qui gèrent déjà des serveurs, cela ressemble beaucoup à du capacity planning classique : définir des SLO, mesurer, puis faire évoluer.
Observations
Ces observations ne remplacent pas une vraie analyse de vos besoins. Elles donnent surtout un ordre de grandeur. Nous recommandons de faire étudier votre usage futur avec un expert plutôt que de choisir uniquement à partir d'un tableau.
| Taille d'entreprise | Types d'usage | Options matérielles | Coût initial |
|---|---|---|---|
| Petite équipe (2-20 utilisateurs), faible usage | Chat interne, Q&A ponctuel, faible concurrence | CPU-first (Apple M3 Ultra) ou 1 GPU Pro 48GB VRAM avec 64GB RAM et NVMe rapide | ~2k-5k€ |
| Petite équipe d'ingénieurs (2-10 utilisateurs), usage élevé | Chat interne, Q&A, forte concurrence, RAG, génération et complétion de code | 2 GPU Pro 96GB VRAM ou 4 GPU grand public premium comme les RTX 3090 avec 128GB RAM et NVMe rapide | ~5k-15k€ |
| Entreprise moyenne (50-200 utilisateurs), usage mixte | Assistant interne + RAG par département, concurrence modérée, batch occasionnel | 2 GPU datacenter 80GB (A100 / H100) ou 2 RTX 6000 96GB, 256-512GB RAM, plusieurs NVMe | ~20k€-50k€ |
Questions fréquentes
Combien coûte l'électricité pour faire tourner le système ?
C'est généralement négligeable comparé au coût initial ou au coût des fournisseurs IA au token. Avec 4 GPU grand public utilisés intensivement environ 20% du temps à pleine capacité, la facture peut tourner autour de 100€/mois. Pour le même usage chez des fournisseurs IA, on peut arriver plutôt autour de 3k-6k€ par mois.
Comment choisir la bonne carte mère et que penser du PCIe ?
Cela dépend de vos besoins. Certaines cartes mères professionnelles comme la MZ32-AR0 sont utiles si vous utilisez plusieurs modèles et que vous devez les charger/décharger vite. Si vous gardez un ou deux modèles chargés en permanence, une carte mère grand public comme une B550 Eagle peut suffire. La vitesse PCIe change surtout le temps de chargement des modèles, pas l'inférence elle-même.
Comment alimenter 4 GPU ? Peut-on utiliser plusieurs alimentations ?
Oui. Nous recommandons d'utiliser plusieurs alimentations si une seule ne correspond pas au besoin. Une alimentation peut être activée sans être branchée directement à la workstation.
Quel CPU utiliser avec des GPU haut de gamme ?
Priorisez les lignes PCIe et la bande passante mémoire. Les CPU workstation ou serveur comme Threadripper, EPYC ou Xeon sont souvent plus adaptés que les CPU grand public dès que l'on utilise 2 à 4 GPU ou plus.
Quel stockage pour les poids des modèles et le RAG ?
Utilisez du NVMe rapide pour les poids des modèles et les caches chauds. Séparez idéalement les volumes, ou même les noeuds, pour la base vectorielle et les logs. RAID1/10 aide pour la disponibilité, mais il faut aussi prévoir les sauvegardes.
Le matériel GPU grand public est-il assez fiable pour la production ?
Dans beaucoup de cas, oui. Mais si vous servez des clients et ne pouvez pas accepter le risque opérationnel lié à l'absence d'ECC VRAM ou aux contraintes thermiques, il vaut mieux choisir des GPU datacenter, des chassis validés et du support entreprise.
Comment gérer le refroidissement, le bruit et les limites de puissance ?
Il faut penser l'airflow en premier, dimensionner l'alimentation avec de la marge, et limiter la puissance des GPU pour stabiliser le rendement. En environnement bureau, un rack distant ou une workstation silencieuse est souvent préférable.
Faut-il du réseau 10/25GbE ?
Pas forcément. Le trafic IA est principalement du texte, donc il est léger. Le réseau est rarement le principal bottleneck pour l'inférence.
Peut-on utiliser des GPU AMD ou Intel ?
Techniquement oui, mais en pratique ce n'est pas toujours rentable. L'écosystème ROCm ou Intel oneAPI reste moins confortable que CUDA. Le gain initial peut être perdu en temps d'intégration, compatibilité et limitations.
Sélection des modèles
Une infrastructure d'entreprise gagne à définir une vraie politique de modèles plutôt qu'un modèle unique pour tout. En pratique, nous recommandons un petit portefeuille :
- Modèle assistant principal : le meilleur modèle que vous pouvez faire tourner dans vos contraintes de latence et de coût.
- Modèle économique : pour les tâches en volume comme classification, extraction, routage ou brouillons.
- Modèle d'embeddings : pour le RAG, avec éventuellement un reranker si la qualité de recherche est critique.
Nos critères de sélection :
- Adéquation à la tâche : chat, traduction, extraction structurée, code, etc.
- Efficacité en service : la taille du KV cache augmente avec la fenêtre de contexte, et devient souvent le vrai coût VRAM.
- Licence et gouvernance : vérifier la compatibilité des licences, documenter les modèles autorisés, et consulter les licences Hugging Face avant déploiement.
Nos recommandations de base
Le tableau ci-dessous donne un point de départ. La VRAM réelle dépend du backend, du batch, du contexte, et du nombre de modèles chargés.
| Modèle | Quantification | Contexte | VRAM | Usage |
|---|---|---|---|---|
| Qwen3.6 35b (a3b) | Q5_K_M | 256k | 50GB | Code, agents, tâches générales |
| Qwen3.6 27b | Q5_K_M | 256k | 50GB | Même usage, parfois plus précis mais plus lent |
| GLM 4.7 flash | Q5_K_M | 198k | 50GB | Code, agents, tâches générales |
| TranslateGemma | Q5_K_M | 128k | 35GB | Traductions |
| Qwen2.5 Coder 14b | Q5_K_M | 8k à 32k | 25GB | Complétion de code |
| Nomic Embed 0.3b | FP16 | 2k | 1GB | Embeddings légers et fiables |
| Qwen3 Embedding 4b | Q8_0 | 40k | 20GB | Embeddings précis mais lourds |
| Flux 2 Klein 9b | FP8 | / | 10GB | Images photoréalistes |
| GLM Image | FP8/FP16 | / | 20GB | Images générales, y compris texte |
Questions fréquentes
Quel débit peut-on espérer ?
Nos exemples sont volontairement pratiques. Une machine avec 4 RTX 3090 lançant Qwen 3.6 35B avec un contexte 256k sur llama.cpp peut atteindre environ 120 tokens/sec pour un utilisateur et 70 tokens/sec pour 3 requêtes concurrentes. C'est très compétitif par rapport à certaines API, sans limite d'usage.
Comment choisir la bonne fenêtre de contexte ?
Partez du besoin produit. Pour la majorité des assistants internes, 8k-16k suffisent si le RAG est bon. Augmentez le contexte seulement pour de vrais cas longs : contrats, grosses specs, revues de code multi-fichiers. Plus le contexte est grand, plus la VRAM augmente.
Comment choisir la quantification ?
FP16 est rarement rentable hors petits modèles ou génération d'image. Le 8-bit est bon pour les tâches sensibles à la précision. Le 4-bit est souvent le meilleur compromis en production. Chez Saphes, Q5 est notre recommandation par défaut.
Qu'est-ce qui consomme le plus de VRAM ?
Trois facteurs dominent : les poids du modèle, la fenêtre de contexte via le KV cache, et la concurrence/batching. Beaucoup d'équipes sous-estiment l'impact du KV cache.
Un gros modèle ou plusieurs petits ?
Nous préférons plusieurs modèles quand les tâches sont bien séparées : un assistant puissant pour les demandes complexes, et des modèles plus petits pour le routage, la synthèse, l'extraction ou les brouillons.
Faut-il un reranker pour le RAG ?
Si vos documents sont longs, bruités ou critiques, un reranker améliore souvent plus la qualité qu'une simple augmentation du contexte. Pour un corpus petit et propre, il n'est pas toujours nécessaire.
Pourquoi ne pas utiliser un très gros modèle comme Kimi k2.5 ?
À partir d'un certain niveau, ajouter des paramètres a moins d'impact sur la qualité. Un modèle comme Qwen 3.6 suffit largement pour beaucoup de tâches agentiques complexes, tout en restant plus rapide et plus économique.
Un modèle flagship ou plusieurs modèles ?
Nous recommandons d'avoir un modèle principal toujours chargé sur les GPU, puis de garder un peu de VRAM pour des modèles spécialisés comme la traduction ou la complétion de code.
Stack logicielle / tooling
Une stack auto-hébergée typique est modulaire et peut démarrer simplement.
Inférence
Pour l'inférence, trois solutions ressortent aujourd'hui. Elles exposent toutes une API compatible OpenAI et ont chacune leurs avantages.
| Solution | Avantages | Inconvénients |
|---|---|---|
| Ollama | Très rapide à installer, simple à utiliser. | Plus lent que les autres solutions, charge/décharge souvent les modèles. |
| Llama server (llama.cpp) | Très rapide, solide en concurrence, très personnalisable, large support de modèles. | Charge un modèle à la fois, configuration plus longue qu'Ollama. |
| vLLM | Excellent pour la concurrence, bon choix pour un modèle principal à l'échelle. | Plus lent que llama.cpp sur une requête simple, setup plus long, support de formats plus limité. |
UI / Gateway
Une option se démarque : Open WebUI. Open WebUI agit comme gateway, gère des accès granulaires, et sait proxifier Ollama ou d'autres API compatibles OpenAI.
Open WebUI peut aussi être couplé à ComfyUI pour la génération d'images, ce qui crée une expérience proche d'un produit type GPT avec image.
RAG
Le RAG (Retrieval-Augmented Generation) est crucial pour beaucoup de cas d'usage. Plus une entreprise possède de documents, plus il devient important. Au lieu d'injecter 300 pages dans le contexte à chaque question, le RAG récupère seulement les morceaux pertinents, avec leurs métadonnées : nom du document, page, source, etc.
Pour le développement, le RAG est parfois moins utile, par exemple parce que ré-embedder tout un codebase à chaque branche n'est pas réaliste. En revanche, embedder une documentation structurée de framework ou de langage peut être très utile.
Avant de mettre en place un RAG, le plus important est de décider ce qui doit entrer dans la base et quelles métadonnées seront nécessaires. L'architecture compte beaucoup : elle détermine si le système sera utilisable au quotidien.
Vous pouvez utiliser ChromaDB ou Qdrant sur votre serveur. Les deux sont bons ; nous recommandons Qdrant parce qu'il est rapide et bien conçu.
Éditeurs de code
Pour un développement local-first assisté par IA, nous recommandons :
Zed : notre choix par défaut. Il intègre l'IA nativement, supporte ACP et d'autres outils modernes, tout en restant extrêmement rapide.
VS Code ou JetBrains :
- Continue pour la complétion de code et les réponses rapides.
- Cline pour des workflows plus agentiques, multi-étapes, avec modifications dans le repo.
MCPs
Il existe beaucoup de MCPs. Les bons sont simplement ceux dont vous avez réellement besoin. Le plus important est souvent le mode de déploiement : les MCPs peuvent tourner de plusieurs façons et utiliser différents types de connexion.
Nous recommandons les connexions HTTP streamables pour les MCPs qui doivent communiquer avec un serveur, et l'exécution directe côté serveur quand c'est pertinent.
Un bon ensemble de MCPs, ou des MCPs développés sur mesure, peut vraiment changer la donne. Ils sont surtout limités par l'imagination : on peut créer un MCP pour parler à une plateforme e-commerce, un CMS, créer ou récupérer du contenu, gérer des produits, et beaucoup plus.
Conclusion
Aujourd'hui, intégrer une IA auto-hébergée dans une entreprise n'est plus un projet lunaire : c'est concret et faisable. Les modèles sont assez intelligents et rapides pour gérer des tâches complexes, un RAG bien configuré peut dépasser beaucoup de solutions automatisées, les interfaces sont devenues accessibles, et le ROI est souvent atteint entre 6 et 24 mois selon la complexité.
Il reste néanmoins des points importants. Le setup initial peut être compliqué : drivers, connexion des outils, configuration du RAG, choix des modèles. Pour nous, le coût principal n'est pas le matériel, mais le temps de mise en place. La maintenance, elle, est généralement beaucoup plus simple.
