IA en entreprise : quel modèle open-source et quel GPU pour une PME européenne ?

TL;DR

Nous avons testé 4 modèles LLM open-source sur deux GPU — le Scaleway L40S (48 Go VRAM, ~450 €/mois) et le NVIDIA RTX PRO 6000 Blackwell (96 Go VRAM, ~900 €/mois) — dans les conditions réelles d'Eridia : system prompt métier de ~6 000 tokens, 5 outils déclarés, requêtes réalistes en français.

Le verdict : les modèles Gemma 4 de Google dominent nettement. Sur le L40S, ils répondent en 155 ms avec 16 tokens/s ; sur le RTX PRO 6000, en 61 ms avec 40 tokens/s — soit 2,5 fois plus vite. Les modèles Qwen3.5 d'Alibaba sont disqualifiés pour le chat interactif : leur mode « thinking », impossible à désactiver, impose 2 à 11 secondes d'attente avant le premier mot.

Pourquoi héberger son IA en 2026 ?

Pour une PME européenne qui manipule des documents sensibles — contrats, données RH, santé, finance — envoyer chaque requête à OpenAI ou Anthropic pose trois problèmes :

• Souveraineté des données — vos documents transitent par des serveurs américains, soumis au Cloud Act
• Coût imprévisible — à 20 utilisateurs actifs, la facture API peut dépasser 2 000 €/mois et varie chaque mois
• Dépendance — un changement de tarif, une panne ou une modification des CGU, et votre outil métier s'arrête

L'auto-hébergement répond aux trois points : les données restent dans votre datacenter (ou chez un hébergeur européen comme Scaleway), le coût est fixe, et vous gardez le contrôle total. Reste une question : quel modèle et quel GPU choisir ? C'est tout l'objet de ce benchmark.

Le banc d'essai

Deux GPU représentatifs du marché

Le L40S est le GPU le plus accessible pour de l'inférence LLM sérieuse en Europe : 48 Go de VRAM suffisent pour des modèles jusqu'à ~35B paramètres en FP8. Le RTX PRO 6000 Blackwell, avec le double de VRAM et presque le double de bande passante, représente la nouvelle référence pour une expérience comparable aux API cloud.

Quatre modèles, deux architectures

Dense ou MoE ? Un modèle dense utilise tous ses paramètres pour chaque token. Un MoE (Mixture of Experts) ne route chaque token que vers un sous-ensemble d'experts (~4B sur 26B pour Gemma) : moins de calcul par token, mais tous les poids doivent quand même tenir en VRAM.

La quantification FP8 : faire tenir 31B dans 48 Go

Un modèle de 31 milliards de paramètres en précision complète (FP32) pèserait ~124 Go. La quantification réduit la précision des poids pour compresser le modèle :

Le FP8 est le sweet spot en 2026 : taille divisée par deux par rapport au FP16, dégradation quasi nulle selon les benchmarks académiques, accélération matérielle native sur Ada Lovelace et Blackwell, et support vLLM en un seul flag. Les quatre modèles testés sont distribués avec des checkpoints FP8 natifs sur Hugging Face.

Méthodologie : des conditions réelles, pas un benchmark académique

La plupart des benchmarks LLM mesurent des tâches isolées (MMLU, HumanEval…). Nous avons voulu mesurer ce que l'utilisateur ressent réellement dans Eridia :

• System prompt complet — le vrai prompt Eridia (~6 000 tokens) : instructions métier, contexte utilisateur, règles de sécurité
• 5 outils déclarés — recherche de fichiers, exécution de code, création de documents, recherche de réunions, interaction utilisateur (format OpenAI function calling)
• 7 requêtes types en français — du simple « Bonjour » à l'analyse juridique complexe
• 3 runs par requête, mesure en streaming : TTFT (Time To First Token), tokens/s en génération, fiabilité des tool calls

Le moteur d'inférence principal est vLLM (v0.19+, FP8 natif, contexte 24K). Nous avons aussi testé llama.cpp + TurboQuant sur L40S pour comparer les deux approches — résultats plus bas.

Résultats

Vue d'ensemble

Moyennes sur les 7 requêtes, 3 runs chacune, avec vLLM :

Trois enseignements immédiats :

1. Les Gemma 4 sont seuls dans la course pour le chat interactif : premier token en moins de 300 ms partout, et même en moins de 70 ms sur Blackwell.
2. Le tool calling est fiable à 100 % sur les 8 configurations — ce n'est plus un critère différenciant en 2026.
3. Les Qwen3.5 paient leur mode thinking : la génération elle-même est correcte, mais l'utilisateur attend plusieurs secondes devant un écran vide avant chaque réponse.

Ce que vaut le passage au Blackwell

Le RTX PRO 6000 offre un gain moyen de ×2,6 en débit et divise le TTFT par 3 à 4. L'explication est directe : la bande passante mémoire GDDR7 (~1 600 Go/s contre 864 Go/s) est le facteur limitant de l'inférence LLM, et le Blackwell en a presque le double.

Dans le détail : le profil du champion

Détail par requête pour la meilleure configuration, Gemma 4 26B-A4B sur RTX PRO 6000 :

Deux constantes que l'on retrouve sur toutes les configurations testées : les requêtes avec tool call ont un TTFT environ 3 fois plus élevé (le modèle doit décider d'appeler l'outil avant d'émettre quoi que ce soit), et le débit reste stable même sur les sorties longues de 1 200+ tokens. À l'inverse, les Qwen3.5 montrent des pointes de TTFT jusqu'à 28 secondes sur les requêtes de raisonnement — le mode thinking s'emballe précisément là où l'utilisateur attend une réponse rapide.

vLLM ou llama.cpp ?

Nous avons rejoué les mêmes requêtes sur le même L40S avec llama.cpp (fork TurboQuant, modèles GGUF) pour comparer les deux moteurs d'inférence de référence :

Le tradeoff est fondamental et symétrique :

• vLLM est optimisé pour le prompt processing : kernels CUDA spécialisés, le premier token arrive quasi instantanément même avec 6 000 tokens de system prompt. En contrepartie, la génération plafonne autour de 16 tokens/s sur L40S.
• llama.cpp est optimisé pour la génération séquentielle : C++ pur, overhead minimal, jusqu'à 130 tokens/s — 8 fois plus vite que vLLM sur le même GPU. Mais le prefill est peu optimisé : 3 à 11 secondes avant le premier token.

S'y ajoute l'argument VRAM : en GGUF Q4_K_M avec le KV-cache compressé TurboQuant (~6 % de pénalité en vitesse), le même modèle tient dans 17 Go au lieu de 40 — de quoi viser des contextes de 64K+ tokens sans saturer le GPU.

En pratique : chat interactif et multi-utilisateurs → vLLM ; génération de documents longs, traitements batch, contexte très long ou budget VRAM serré → llama.cpp + TurboQuant.

Analyse : pourquoi de tels écarts ?

Le mode thinking de Qwen3.5, un piège pour le chat

Les Qwen3.5 intègrent un raisonnement interne (similaire aux modèles o1/o3 d'OpenAI) : avant chaque réponse, le modèle génère des tokens de réflexion cachés qui consomment du temps GPU sans rien afficher. Ce mode est activé par défaut et ne peut pas être désactivé via l'API standard. Pour de l'analyse en batch, pourquoi pas ; pour un assistant conversationnel, c'est rédhibitoire.

MoE vs dense : un avantage qui ne se révèle qu'avec de la bande passante

Sur le L40S, le MoE Gemma 4 26B-A4B n'est pas plus rapide que le dense 31B : l'inférence y est limitée par la lecture des poids en mémoire, et un MoE doit lire tous ses poids même si une fraction seulement est active. Sur le RTX PRO 6000, le bottleneck mémoire se desserre et l'avantage compute du MoE apparaît : 39,5 tokens/s contre 34,5 pour le dense, et un avantage qui grandira en multi-utilisateurs grâce à la charge de calcul réduite par requête.

Combien ça coûte ?

Estimation pour ~500 requêtes/utilisateur/mois avec un system prompt comparable.

À 20 utilisateurs, l'auto-hébergement coûte 2 à 4 fois moins cher que les API — avec un coût fixe, prévisible, et des données qui ne quittent jamais l'Europe. C'est exactement le modèle de l'offre de déploiement sur-mesure d'Eridia.

Nos recommandations

Recommandation principale — Gemma 4 26B-A4B (MoE) sur RTX PRO 6000, ~900 €/mois. 40 tokens/s, premier token en 61 ms : une expérience indiscernable des API cloud premium, en souveraineté totale. Les 96 Go de VRAM laissent de la marge pour des contextes longs et le batching multi-utilisateurs. Idéal de 10 à 50 utilisateurs.

Budget serré — Gemma 4 31B-it sur Scaleway L40S, ~450 €/mois. La meilleure qualité de réponse à ce prix : TTFT sous 200 ms, 16 tokens/s, tool calling fiable, excellent français. Parfait pour démarrer à 10–30 utilisateurs (~22 €/utilisateur/mois), hébergé en France.

Qualité maximale — Gemma 4 31B-it sur RTX PRO 6000, ~900 €/mois. Si la richesse du raisonnement prime sur la vitesse pure : 35 tokens/s, TTFT 64 ms, et les réponses les plus structurées du panel.

Usage batch et contextes longs — Gemma 4 26B-A4B en GGUF Q4_K_M + TurboQuant sur L40S, ~450 €/mois. 130 tokens/s avec 17 Go de VRAM seulement : le choix des pipelines d'automatisation (résumés, extraction de données, génération de rapports) où le TTFT n'est pas critique.

Vous voulez cette stack sans avoir à la gérer vous-même ? Eridia installe ces modèles clé en main sur votre infrastructure, avec la sécurité et la conformité RGPD natives — parlons-en.

Et après ?

• Tests multi-utilisateurs — mesurer la dégradation avec 5, 10, 20 requêtes simultanées
• Benchmark contexte long — KV-cache f16 vs turbo4 à 64K et 128K tokens
• Nouveaux modèles — Mistral Small 3.1 et Llama 4 Scout dès leur disponibilité
• Setup hybride — vLLM pour le chat + llama.cpp pour le batch sur le même GPU

Benchmark réalisé avec Eridia v2 — eridia.ai. Moteurs : vLLM 0.19+ (FP8 natif), llama.cpp fork TurboQuant (GGUF Q4_K_M/Q8_0, KV-cache turbo4). GPU : Scaleway L40S (48 Go, 864 Go/s), RunPod RTX PRO 6000 Blackwell (96 Go, ~1 600 Go/s). Contexte 24K, 7 requêtes en français, 3 runs par requête, system prompt complet (~6 000 tokens). Méthodologie détaillée et scripts disponibles sur demande.