Déployer une IA générative “sur vos données” ne se résume pas à “acheter un serveur avec une grosse carte graphique”. Dans une infrastructure IA entreprise, le dimensionnement GPU est un arbitrage entre performance (latence, débit), sécurité/souveraineté, coûts (CAPEX/OPEX), exploitation (monitoring, MCO) et adoption (nombre d’utilisateurs, cas d’usage).
Le problème : on voit souvent deux écueils.
- Sous-dimensionner : l’IA est lente, l’expérience utilisateur se dégrade, les équipes abandonnent.
- Sur-dimensionner : budget immobilisé, GPU sous‑utilisés, ROI qui s’évapore.
L’objectif de cet article : vous donner une méthode claire et praticable pour dimensionner GPU IA en contexte entreprise (ETI inclus), avec des repères concrets (VRAM, concurrence, architecture), et les points de contrôle à valider avant de signer un devis matériel.
Noroit, en tant qu’ESN spécialisée IA & données d’entreprise, intervient précisément sur ce type de sujet : analyse du besoin, dimensionnement infra (serveurs/GPU/architecture), choix du LLM, mise en place RAG et base de connaissance, formation et maintenance.
Ce que “dimensionner GPU” veut vraiment dire en entreprise
En entreprise, “dimensionner son infrastructure GPU” ne signifie pas uniquement “combien de GPU ?”. C’est plutôt :
- Quel modèle (ou quels modèles) allez-vous servir (LLM, embeddings, OCR, vision, etc.) ?
- Quelle expérience utilisateur visez-vous (temps de première réponse, fluidité, débit, heures de pointe) ?
- Quelle isolation et quelle gouvernance sont nécessaires (droits, traçabilité, logs, coûts par équipe) ?
- Quel socle technique vous industrialisez (RAG, connecteurs SI, supervision, pipelines d’ingestion) ?
Autrement dit : le GPU n’est qu’un morceau du puzzle. Mais il devient le goulet d’étranglement… et donc l’endroit où une erreur coûte le plus cher.
Étape 1 — Décrire vos charges IA : les 6 questions qui changent tout
Avant de parler cartes et serveurs, vous devez “figer” une description d’usage. Voici les 6 questions les plus rentables :
1) Vos cas d’usage sont-ils “inférence” ou “entraînement” ?
- Inférence : faire tourner un LLM pour répondre aux utilisateurs (chat, copilote, Q/R, synthèse).
- Entraînement / fine‑tuning : adapter un modèle à votre domaine.
En pratique, beaucoup d’entreprises n’ont pas besoin de “pré‑entraîner” un LLM ; elles ont surtout besoin d’un RAG robuste + éventuellement un fine‑tuning léger (type LoRA) selon le cas.
2) Combien d’utilisateurs actifs en même temps ?
Ne dimensionnez pas sur “nombre de comptes”, mais sur la concurrence :
- une ETI peut avoir 500 comptes, mais 20 utilisateurs simultanés à 10h ;
- ou 80 simultanés lors d’une période de bouclage (finance, juridique, QSE…).
3) Quel SLA de latence ?
Deux indicateurs utiles :
- TTFT (Time To First Token) : délai avant la première réponse visible (ressenti immédiat).
- Tokens/seconde : vitesse de génération (fluidité).
4) Quelle taille de contexte (et quel RAG) ?
Un chatbot “sur documents” injecte du contexte (extraits) dans le prompt. Plus le contexte est long, plus :
- le KV cache explose (VRAM),
- la latence augmente,
- le coût par requête augmente.
5) Quels pics et quelles plages horaires ?
La charge n’est pas linéaire. Pensez “heure de pointe” + “effet démo” + “effet déploiement” :
- POC : 5 utilisateurs enthousiastes → ok.
- Déploiement : 50 utilisateurs le même jour → saturation.
6) Quels “à‑côtés” GPU ?
Selon les choix, le GPU peut aussi servir à :
- générer les embeddings (indexation, recherche sémantique),
- faire de la vision (analyse d’images/PDF),
- faire du batch (synthèse de lots, classification, enrichissement).
Étape 2 — Choisir le mode de déploiement (on‑prem, cloud souverain, hybride)
Le déploiement influence directement votre infrastructure IA entreprise : sécurité, réseau, exploitation, coûts, et vitesse de montée en charge.
Option A — On‑premise (chez vous)
Pertinent si :
- données sensibles / contraintes fortes,
- intégrations SI internes (GED, intranet, tickets, ERP),
- besoin de maîtrise et traçabilité.
C’est un scénario fréquent dès qu’on veut un “ChatGPT privé d’entreprise” sur documents internes.
Option B — Cloud privé / cloud souverain
Pertinent si :
- vous voulez réduire la contrainte datacenter (énergie, refroidissement),
- vous avez besoin d’élasticité,
- vous souhaitez un cadre “cloud de confiance” selon votre contexte.
Option C — Hybride (souvent le plus réaliste)
Exemples :
- LLM sensible on‑prem + tâches génériques via IA externe (traduction/reformulation)
- embeddings et ingestion en batch la nuit + inférence le jour
- environnement pilote isolé + production industrialisée
Noroit positionne justement les projets autour d’une plateforme IA déployée on‑premise ou sur infrastructure souveraine, avec une approche “solution, pas simple outil”.
Étape 3 — Choisir le modèle (LLM) : l’impact direct sur la VRAM et le débit
Deux projets peuvent avoir le même nombre d’utilisateurs… et une facture GPU x10, simplement parce que :
- le modèle est beaucoup plus gros,
- le contexte est plus long,
- la qualité attendue est plus élevée,
- le niveau de quantification diffère.
Les variables qui impactent le dimensionnement :
- Nombre de paramètres (ordre de grandeur : 7B, 13B, 34B, 70B…)
- Quantification (4‑bit / 8‑bit / 16‑bit) : réduit la VRAM, peut impacter qualité/latence
- Longueur de contexte et stratégie RAG (top‑k, chunking, reranking)
- Batching (servir plusieurs requêtes en parallèle sur le GPU)
- Multi‑GPU (sharding, tensor parallel, pipeline parallel)
Étape 4 — Estimer la VRAM : poids du modèle + KV cache + marge
1) La règle simple : la taille des poids
Ordre de grandeur (poids seuls, sans cache ni overhead) :
| Taille modèle | 4 bits | 8 bits | 16 bits |
|---|---|---|---|
| 7B | ~3.3 GiB | ~6.5 GiB | ~13.0 GiB |
| 13B | ~6.1 GiB | ~12.1 GiB | ~24.2 GiB |
| 34B | ~15.8 GiB | ~31.7 GiB | ~63.3 GiB |
| 70B | ~32.6 GiB | ~65.2 GiB | ~130.4 GiB |
Important : en production, vous devez ajouter :
- l’overhead runtime (framework, buffers),
- le KV cache (souvent déterminant),
- une marge (pics, fragmentation mémoire, mises à jour).
2) Le “vrai tueur” : le KV cache
Le KV cache dépend surtout de :
- la longueur de contexte (tokens),
- la concurrence/batch,
- la dimension interne du modèle.
Conséquence :
un modèle “qui tient” en VRAM sur un prompt court peut ne plus tenir dès que vous injectez des extraits RAG + historique de conversation + pièces jointes.
3) La marge de sécurité
En entreprise, une bonne pratique est de viser :
- une configuration qui fonctionne à 60–70% de charge nominale,
- et garde de la marge pour :
- mises à jour de modèle,
- hausse d’adoption,
- nouveaux cas d’usage.
Étape 5 — Estimer la puissance GPU : concurrence, tokens/s, latence
Pour dimensionner, vous avez besoin d’un objectif de service (SLO). Exemple :
- TTFT < 2 s
- génération ~20–40 tokens/s par requête active
- 30 utilisateurs simultanés à l’heure de pointe
Méthode praticable (sans magie)
- Définissez un scénario de charge (réaliste et testable)
- N utilisateurs simultanés
- prompt moyen X tokens (incluant RAG)
- réponse moyenne Y tokens
- Choisissez un moteur d’inférence (selon votre stack)
- Mesurez sur 1 GPU candidat (bench)
- Extrapolez avec prudence (les effets de contention et de mémoire existent)
- Validez par un test de charge instrumenté (étape 8)
En pratique, “dimensionner GPU IA” sans bench revient à dimensionner une base de données sans test de charge : vous aurez une surprise… juste pas au bon moment.
Étape 6 — Concevoir l’architecture cible (mono‑GPU, multi‑GPU, cluster)
Architecture 1 — Serveur mono‑GPU (POC solide / petite prod)
- 1 nœud, 1 GPU, stack LLM + RAG
- idéal pour : 5–30 utilisateurs simultanés (selon modèle/latence)
- avantage : simple, rapide, économique
- limite : pas de haute dispo, montée en charge limitée
Architecture 2 — Serveur multi‑GPU (production ETI classique)
- 1 nœud, 2 à 8 GPU
- possibilités :
- un GPU pour le LLM, un GPU pour embeddings/batch,
- ou sharding du LLM sur plusieurs GPU (si modèle gros),
- ou plusieurs “réplicas” du modèle pour absorber la concurrence
- avantage : bon compromis exploitation/perf/coût
- limite : dépendance à un nœud (même si redondance possible)
Architecture 3 — Cluster (multi‑nœuds)
- plusieurs serveurs GPU, orchestration (souvent Kubernetes) + load balancing
- utile si :
- vous visez des centaines d’utilisateurs,
- vous voulez haute dispo,
- vous avez plusieurs modèles, environnements, équipes
- limite : complexité (réseau, observabilité, sécurité, MCO)
Étape 7 — Ne pas oublier le reste du hardware : CPU, RAM, stockage, réseau
Un piège courant : mettre “tout le budget” dans le GPU… et créer des goulots d’étranglement ailleurs.
CPU
Le CPU sert à :
- ingestion documentaire (parsing, chunking),
- orchestration RAG,
- chiffrement, compression, I/O,
- parfois OCR et pipelines.
RAM
Pour :
- caches (documents, embeddings),
- index temporaires,
- pipelines d’ingestion,
- vector DB selon technos.
Stockage (NVMe recommandé)
Vous en avez besoin pour :
- stocker les modèles,
- stocker l’index vectoriel,
- logs, traces, audit,
- snapshots, sauvegardes.
Réseau
- en mono‑nœud : 10–25 GbE peut suffire selon SI
- en cluster / stockage distant / multi‑GPU distribué : le réseau devient un facteur majeur
Exploitation, sécurité, traçabilité
Dans une plateforme IA d’entreprise, il faut généralement :
- gestion des droits, journaux d’usage, monitoring performance/coûts, etc.
Étape 8 — Valider par un pilote instrumenté (bench + test de charge)
Avant achat massif, faites un pilote qui répond à 3 questions :
- Ça marche fonctionnellement (qualité des réponses, RAG, droits)
- Ça tient la charge (latence, concurrence, pics)
- Ça s’exploite (supervision, incidents, MCO)
Indicateurs à suivre :
- TTFT, tokens/s, latence p95/p99
- taux d’erreurs, timeouts
- VRAM utilisée, fragmentation
- GPU utilization (compute vs memory bound)
- longueur moyenne de contexte
- coût par requête (si refacturation interne)
Exemples “hardware IA générative ETI” (repères de sizing)
Ces repères ne remplacent pas un bench, mais aident à cadrer.
Cas A — POC “sérieux” (objectif : décider, pas juste démo)
- 1 serveur
- 1 GPU avec VRAM 24–48 Go (selon modèle/quantif)
- 128–256 Go RAM
- NVMe rapide (modèles + index)
- cible : copilote documentaire (RAG) pour 1–2 métiers
Cas B — Pilote multi‑équipes (objectif : adoption contrôlée)
- 1 serveur
- 2–4 GPU (réplicas ou séparation LLM/embeddings)
- gouvernance + traçabilité + droits
- cible : 2–5 métiers, montée progressive d’utilisateurs
Cas C — Production ETI (objectif : disponibilité + performance)
- 2 serveurs minimum (redondance)
- 4–16 GPU au total selon :
- taille de modèle,
- concurrence,
- SLA,
- nombre d’apps/copilotes
- supervision, sauvegardes, runbooks, procédures
C’est exactement le type de démarche “socle réutilisable” qu’on retrouve dans l’approche plateforme IA d’entreprise (LLM + RAG + sécurité/gouvernance), plutôt qu’un outil isolé.
Les pièges classiques (et coûteux) du dimensionnement GPU
- Dimensionner sur le nombre de salariés au lieu des utilisateurs simultanés
- Oublier l’impact du contexte long (KV cache)
- Sous-estimer le RAG (qualité dépend du chunking, top‑k, reranking, hygiène documentaire)
- Ne pas instrumenter → impossible de savoir si le problème vient du GPU, du RAG, du réseau ou du SI
- Acheter “le plus gros GPU” sans architecture (réplication vs sharding vs cluster)
- Ignorer l’exploitation (mise à jour modèles, droits, audit, sécurité, formation)
Pourquoi ce sujet crée souvent un besoin d’accompagnement (et comment Noroit intervient)
Dans les faits, les entreprises qui cherchent “infrastructure IA entreprise” ne veulent pas juste un serveur : elles veulent une capacité durable, gouvernée, industrialisable.
Sur votre site, Noroit met en avant une approche bout‑en‑bout :
- analyse du besoin et des cas d’usage,
- dimensionnement de la puissance matérielle (GPU/CPU, stockage, réseau) selon volumes, utilisateurs et performances,
- choix du LLM et de l’architecture, POC/bench,
- mise en place de la base de connaissance,
- formation administrateurs/utilisateurs,
- maintenance et évolution.
C’est typiquement ce qui évite :
- les POC qui “marchent” mais ne passent jamais en prod,
- les plateformes qui saturent dès le déploiement,
- les problèmes de conformité/données,
- l’absence de gouvernance et de traçabilité.
Noroit positionne aussi la plateforme IA sur une logique de souveraineté : déploiement on‑premise ou infrastructure souveraine, contrôle des données, et briques open‑source quand pertinent.
FAQ
Combien de GPU faut-il pour un chatbot interne (RAG) ?
Ça dépend surtout de 4 variables : (1) taille du modèle, (2) longueur de contexte, (3) concurrence, (4) SLA de latence. La bonne réponse opérationnelle : bench + test de charge sur un scénario réaliste.
Faut-il un cluster Kubernetes dès le début ?
Pas forcément. Beaucoup d’ETI démarrent efficacement avec un serveur multi‑GPU bien dimensionné, puis industrialisent en cluster quand :
- la HA devient obligatoire,
- plusieurs modèles/équipes/environnements cohabitent,
- la charge et les pics le justifient.
Peut-on mixer IA interne et IA externe ?
Oui, et c’est souvent pertinent : garder en interne les usages sensibles et utiliser une IA externe pour des tâches génériques (ex. reformulation/traduction) avec des règles strictes. C’est une approche explicitement citée dans la logique “IA externe maîtrisée quand c’est pertinent”.
Pourquoi le RAG change autant le dimensionnement ?
Parce qu’il augmente la taille du prompt (contexte), donc la mémoire (KV cache) et le coût de calcul par requête. Dès que vous voulez que l’IA se base sur des documents internes, le RAG devient le moyen le plus maîtrisable pour contextualiser sans tout réentraîner.
Conclusion
Dimensionner une infrastructure GPU pour un projet IA d’entreprise, c’est :
- clarifier vos cas d’usage et votre charge réelle,
- choisir un modèle et une stratégie RAG cohérents,
- estimer VRAM + débit + latence,
- concevoir une architecture (mono‑GPU, multi‑GPU, cluster),
- valider par bench/test de charge,
- industrialiser (sécurité, gouvernance, traçabilité, exploitation).
Si votre objectif est de passer d’un POC à une plateforme IA d’entreprise (copilotes métiers, base de connaissance, intégration SI, déploiement on‑prem / cloud souverain), l’étape la plus rentable est souvent un cadrage structuré + une architecture cible et un dimensionnement chiffré — exactement le type d’accompagnement décrit par Noroit.