Comment choisir le bon modèle open source et le bon matériel

Déployer un LLM privé commence par deux décisions profondément liées : quel modèle faire tourner, et sur quel matériel. Si l’association est mauvaise, vous dépensez trop pour une capacité que vous n’utilisez pas, ou vous sous-approvisionnez le calcul dont votre cas d’usage a réellement besoin. La bonne nouvelle est que l’écosystème open source a mûri au point qu’il existe un modèle éprouvé pour presque tous les budgets et toutes les tâches — à condition de savoir comment les associer.

Partir du cas d’usage, pas du benchmark

L’erreur la plus courante dans la sélection de modèles est de commencer par les scores de benchmark plutôt que par les exigences de la tâche. Un modèle qui atteint des résultats de pointe sur un benchmark de codage peut être excessif pour résumer des tickets de support, et peut introduire une latence qui le rend inadapté à une utilisation en temps réel. Avant de choisir une taille de modèle, définissez précisément votre cas d’usage : quelle est la longueur d’entrée moyenne en tokens ? La tâche nécessite-t-elle un raisonnement en plusieurs étapes, ou s’agit-il principalement de classification et d’extraction ? Combien d’utilisateurs simultanés le système doit-il servir ? Quelle est la latence de réponse acceptable ? Quelles langues le modèle doit-il maîtriser ? Ces questions contraignent votre espace de recherche bien plus utilement que tout classement.

Paliers de taille de modèle : 7–8 Md, 32–70 Md et 405 Md+

Le paysage des modèles open source s’est consolidé autour de trois paliers de taille pratiques. Les modèles dans la plage de 7 à 8 milliards de paramètres — comme Mistral 7B, Llama 3.1 8B et Qwen2.5 7B — sont remarquablement capables pour des tâches ciblées : classification de documents, extraction, résumé et questions-réponses de type FAQ sur un corpus de récupération. Ils fonctionnent confortablement sur un seul GPU grand public ou prosumer et offrent une faible latence même sans optimisation intensive. Le palier 32–70 Md — Llama 3.3 70B, Qwen2.5 32B, Mixtral 8x7B — est là où la qualité du raisonnement général, la fluidité multilingue et le suivi des instructions s’améliorent substantiellement. Ces modèles peuvent gérer des tâches analytiques complexes, des contextes plus longs et une génération plus nuancée. Ils nécessitent des GPU de qualité professionnelle mais restent réalisables pour un déploiement sur un seul serveur. Au-delà de 70 Md, des modèles comme Llama 3.1 405B offrent une capacité de niveau frontier mais exigent des configurations multi-GPU et une planification infrastructure soigneuse ; ils sont mieux réservés aux cas d’usage où la qualité est la contrainte principale et le budget n’est pas un obstacle.

• Modèles 7–8 Md : idéaux pour les tâches ciblées à haut débit — classification, extraction, RAG sur des données structurées. GPU unique, coût le plus bas.
• Modèles 32–70 Md : raisonnement général solide, support multilingue, contextes plus longs. GPU haut de gamme unique ou petit nœud multi-GPU.
• Modèles 405 Md+ : qualité frontier pour les tâches les plus exigeantes. Multi-GPU requis ; planifier l’infrastructure avec soin.
• Les architectures mixture-of-experts (MoE) (ex. Mixtral) peuvent offrir une qualité de classe 70 Md à un coût proche d’un modèle de 13 Md de paramètres actifs — à évaluer si le débit est important.

Associer les modèles aux GPU : la VRAM est la contrainte principale

La VRAM du GPU est la contrainte principale qui détermine quels modèles vous pouvez exécuter et à quelle vitesse. Un modèle doit tenir en VRAM pour l’inférence — avec une marge supplémentaire pour le cache KV, qui croît avec la longueur du contexte et la taille du batch. En règle générale : un modèle de 7 à 8 Md en précision 16 bits nécessite environ 14 à 16 Go de VRAM ; un modèle de 32 Md en nécessite environ 64 Go ; un modèle de 70 Md en nécessite environ 140 Go. C’est pourquoi un seul GPU de 24 Go (comme le NVIDIA RTX 3090 ou 4090) est le foyer naturel des modèles 7–8 Md, une carte de 48 Go (RTX 6000 Ada) ou 80 Go A100/H100 couvre la plage 32–70 Md sur une seule carte, et tout ce qui est plus grand nécessite des configurations multi-GPU avec des interconnexions NVLink ou InfiniBand.

Quantization : dépasser votre budget VRAM

La quantization réduit la précision des poids du modèle — des flottants 16 bits aux entiers 8 bits (INT8) ou 4 bits (GPTQ, AWQ, GGUF Q4) — réduisant considérablement les besoins en VRAM. Un modèle de 70 Md quantifié en 4 bits peut tenir dans environ 35 à 40 Go de VRAM, le rendant accessible sur une configuration double GPU de 24 Go. Le compromis en termes de qualité dépend de la méthode de quantization et de la tâche : pour la plupart des cas d’usage en production, INT8 est quasi sans perte, et une quantization 4 bits bien implémentée préserve la majorité de la qualité du modèle pour les tâches qui ne sont pas très sensibles aux erreurs de raisonnement subtiles. La quantization n’est pas un contournement — c’est une stratégie de déploiement de premier plan que Privonis utilise régulièrement pour maximiser les capacités par euro de budget matériel.

La bonne question n’est pas « quel modèle est le meilleur ? » mais « quel modèle est suffisant pour cette tâche, dans le budget matériel dont nous disposons ? » La quantization comble l’écart entre les deux réponses plus que la plupart des équipes ne le pensent.

Évaluer avant d’acheter : l’approche évaluation d’abord

Aucun benchmark ne se substitue à l’évaluation d’un modèle sur vos données et tâches réelles. Avant de vous engager sur du matériel, Privonis recommande de mener une évaluation structurée : définir un ensemble représentatif d’entrées issues de votre cas d’usage en production, établir des critères de qualité (précision, conformité du format, latence à votre taille de batch cible), et tester deux ou trois modèles candidats sur des instances GPU cloud louées. Cela coûte quelques centaines d’euros et prend généralement un à deux jours. Le résultat est une spécification matérielle basée sur des preuves plutôt qu’une supposition — et cela révèle souvent qu’un modèle plus petit et plus rapide répond à vos besoins, économisant des dépenses en capital significatives.

• Définissez des entrées d’évaluation à partir de données de production réelles avant de choisir un modèle.
• Testez d’abord sur une capacité GPU louée — instances cloud pour l’évaluation, on-premise pour la production.
• Mesurez ce qui compte : précision de la tâche, latence p95, tokens par seconde à votre taille de batch attendue.
• Envisagez le fine-tuning d’un modèle plus petit avant de passer à un modèle plus grand — un 7 Md affiné surpasse souvent un 70 Md générique sur des tâches étroites.
• Planifiez pour le cache KV : les contextes plus longs consomment la VRAM rapidement ; testez à la longueur de contexte maximale attendue.

Comment Privonis guide le processus de sélection

Choisir la bonne combinaison modèle-matériel est l’une des décisions à plus fort effet de levier dans un déploiement IA privé. Une pile bien assortie offre la qualité dont vous avez besoin à un coût qui clarifie le cas d’affaires ; une pile mal assortie dépense soit trop en calcul inactif, soit sous-performe sur des tâches importantes. Privonis apporte une expérience concrète dans la sélection, la quantization, le fine-tuning et le benchmarking de LLM open source pour un large éventail de cas d’usage d’entreprises européennes. Nous vous aidons à éviter le cycle coûteux d’essais et d’erreurs et à arriver à une configuration de déploiement correctement dimensionnée dès le départ — et qui reste maintenable à mesure que les modèles et vos cas d’usage évoluent.