Quel modèle open-weight déployer en auto-hébergé ?
L'auto-hébergement d'un modèle de langage est l'option que les équipes écartent trop tôt et adoptent trop tard. On l'écarte en disant qu'il est "en retard sur la frontier hébergée" — alors qu'il serait possible de faire tourner aujourd'hui une qualité qui était l'état de l'art il y a douze mois, pour une fraction du coût récurrent. L'adoption finit par arriver, souvent en urgence après qu'une revue de conformité a trouvé un point bloquant dans les conditions d'utilisation d'un tiers. Ce guide sélectionne les cinq modèles open-weight sur lesquels nous construirions aujourd'hui un stack auto-hébergé, et les dimensions qui déterminent lequel correspond à votre infrastructure.
Pourquoi l'auto-hébergement mérite un second regard
L'argument contre les modèles open-weight était autrefois simple : la frontier hébergée est tellement en avance que tout le reste est un faux choix économique. Cet argument a perdu de sa force à chaque trimestre de 2024 et 2025. Les modèles ouverts les plus performants atteignent aujourd'hui le niveau qui était celui des modèles phares hébergés il y a un an — une qualité suffisante pour presque toutes les workloads de production qui ne sont pas du chat orienté client. L'écart avec la pointe existe encore ; l'écart avec "assez bon" a disparu.
La raison d'opter pour le local est rarement la qualité. Il s'agit de résidence des données, de coût récurrent, de latence dans des régions que les grands fournisseurs desservent peu, et de la capacité à faire tourner un modèle qui ne change pas sous vos pieds quand le fournisseur déprécie une génération. Une équipe qui traite dix millions de documents internes par mois pour les classifier peut économiser six chiffres par an sur une infrastructure auto-hébergée par rapport au pay-per-token. Une équipe avec des données régulées évite un cauchemar procurement complet. Une équipe dans une région à haute latence vers les datacenters américains sert ses utilisateurs un ordre de grandeur plus vite.
L'équation de coût n'est pas aussi simple que "les poids du modèle sont gratuits". Vous payez les GPU — achetés ou loués — et les heures d'ingénierie pour les opérer. Le seuil de rentabilité dépend du volume de tokens : en dessous d'environ cent millions de tokens par mois, les API hébergées l'emportent presque toujours sur le coût total ; au-delà d'un milliard, l'auto-hébergement gagne presque toujours. Dans la plage intermédiaire, ce sont les détails propres à la workload qui tranchent.
Cinq contraintes définissent le choix : la quantité de VRAM que le modèle exige à une qualité acceptable, les conditions de licence pour votre cas d'usage, la maturité de l'écosystème environnant et la latence que le modèle peut réellement offrir sur votre matériel. Le bon modèle est celui qui remplit les cinq — pas celui qui affiche le meilleur score de benchmark sur papier.
Les cinq dimensions qui déterminent quel modèle convient
Ce sont les axes selon lesquels notre scorecard évalue un modèle open-weight pour l'auto-hébergement en production. La pondération relative varie selon le budget matériel, la juridiction et la tolérance aux aspérités de l'écosystème — mais tout candidat sérieux doit atteindre un minimum sur les cinq.
- 01 — Adéquation matérielle
Tourne-t-il sur les cartes que vous avez réellement ?
Un modèle qui nécessite un nœud multi-GPU est une proposition bien différente d'un modèle qui tourne sur une seule carte grand public. Calculez toujours les besoins en VRAM à la quantisation prévue, et ajoutez une marge confortable pour le cache KV à la longueur de contexte cible. L'erreur la moins chère est d'acheter trop de matériel ; la plus coûteuse est d'en acheter trop peu.
- 02 — Qualité à la quantisation
Combien perd-il au niveau de quant qui rentre ?
La quantisation échange la qualité contre la mémoire et la vitesse. Certains modèles résistent bien aux quants à quatre bits ; d'autres se dégradent sensiblement en dessous de huit. Les benchmarks full-precision publiés ne vous apprennent pas grand-chose — mesurez au niveau de quant que votre matériel autorise réellement, et acceptez que la réponse puisse inverser le classement.
- 03 — Conditions de licence
Pouvez-vous l'utiliser comme vous le souhaitez ?
Des poids ouverts ne signifient pas forcément une licence ouverte. Certains autorisent un usage commercial large sans conditions ; d'autres comportent des seuils d'utilisation, des clauses d'attribution ou des restrictions de redistribution. Lisez la licence avant de construire, pas après. Une licence permissive avec une qualité légèrement inférieure l'emporte généralement sur une licence restrictive que votre service juridique finira par bloquer.
- 04 — Soutien de l'écosystème
Le stack de serving est-il brut ou rodé ?
Un modèle avec un support de premier plan dans vLLM, Ollama et llama.cpp sera des ordres de grandeur moins coûteux à opérer qu'un modèle livré avec un seul script de référence et un README optimiste. La maturité des outils est le coût caché que la plupart des équipes sous-estiment ; il apparaît dans les heures d'ingénierie consacrées aux incidents.
- 05 — Latence sur votre matériel
Génère-t-il suffisamment vite pour le cas d'usage ?
Un modèle auto-hébergé qui produit dix tokens par seconde sur le GPU que vous pouvez vous offrir est un modèle que vous ne pouvez pas utiliser pour du chat. Mesurez les tokens-par-seconde sous une concurrence réaliste sur exactement la carte que vous comptez déployer ; les chiffres obtenus sur le H100 d'un autre ne se transfèrent pas sur votre L40S.
Les 5 meilleurs choix Tokonomix pour l'auto-hébergement aujourd'hui
Ce qui suit est la sélection que nous déploierions réellement sur du métal la semaine prochaine. L'auto-hébergement récompense une sélection différente de celle du monde des API hébergées — le bon modèle principal est généralement le plus grand qui laisse encore de la marge sur le GPU au niveau de quant que vous pouvez tolérer. Ajoutez un modèle secondaire plus petit derrière un routeur pour les requêtes qui ne nécessitent pas le grand, et l'économie commence à jouer en votre faveur.
Meta-Llama-3_3-70B-Instruct
via OVH AI Endpoints (GRA)
Le point de départ de facto de toute discussion sur les modèles open-weight. Fort suivi d'instructions, large couverture linguistique et un écosystème communautaire (Ollama, vLLM, llama.cpp) plus profond que toute alternative. Nécessite un matériel sérieux — deux GPU grand public ou une carte datacenter — mais la qualité à cette taille se justifie.
- Entrée / 1M tokens
- $0.6700
- Sortie / 1M tokens
- $0.6700
- Contexte
- —
Qwen3-32B
via OVH AI Endpoints (GRA)
S'intègre confortablement sur un seul GPU haut de gamme grand public à une quantisation raisonnable, avec une qualité proche du Llama plus grand pour la plupart des workloads. Le bon choix quand le budget correspond à une carte, pas un cluster, et que l'anglais n'est pas la seule langue que le modèle doit bien maîtriser.
- Entrée / 1M tokens
- $0.0800
- Sortie / 1M tokens
- $0.2300
- Contexte
- —
Mistral-Small-3.2-24B-Instruct-2506
via OVH AI Endpoints (GRA)
Poids ouverts sous licence permissive d'un éditeur européen, hébergés sur une infrastructure résidente en UE et calibrés pour des langues que les modèles d'origine américaine couvrent souvent superficiellement. Un choix naturel pour les équipes dont les règles d'achat favorisent les modèles d'origine européenne ou dont les utilisateurs parlent autre chose que le trio de tête. Relisez toujours la note de licence sur la fiche du modèle avant tout usage commercial.
- Entrée / 1M tokens
- $0.0900
- Sortie / 1M tokens
- $0.2800
- Contexte
- —
gpt-oss-120b
via OVH AI Endpoints (GRA)
Modèle d'instruction généraliste performant avec une licence permissive et un bon support multimodal dans les variantes vision. Plus petit que les flagships Llama et Qwen mais très au-dessus de son gabarit ; un choix par défaut raisonnable quand la maturité de l'écosystème compte plus que la course au sommet absolu du classement.
- Entrée / 1M tokens
- $0.0800
- Sortie / 1M tokens
- $0.4000
- Contexte
- —
Référence de prix hébergé (quand vous ne vous auto-hébergez pas)
L'auto-hébergement est une option ; l'autre consiste à acheter de l'inference auprès d'un fournisseur qui fait tourner les mêmes modèles open-weight pour vous. Le graphique montre le prix hébergé en direct par million de tokens de sortie pour les choix qui en publient un — utile comme contrôle de cohérence pour vos propres calculs d'économie en auto-hébergé.
Guide pratique : quel modèle pour quelle infrastructure
La correspondance ci-dessous est celle que nous utiliserions pour conseiller une équipe dans le choix de son premier modèle auto-hébergé. Traitez-la comme un point de départ, pas comme un verdict — mesurer les tokens-par-seconde sur votre propre GPU vaut plus que toute recommandation générale.
GPU grand public unique (24-32 Go VRAM)
Station de travail ou laptop développeur avec une seule carte performante. Mistral Small 3.2 ou Qwen3-32B en quant quatre bits offrent le meilleur ratio qualité/carte dans cette plage. Serving via Ollama pour la facilité d'utilisation ou vLLM pour un débit plus élevé.
Nœud d'inference datacenter
Un L40S, A100 ou H100 dédié à l'inference. Llama 3.3 70B est le choix par défaut sûr ; passez à gpt-oss-120b si l'écart de qualité compte et que le matériel le supporte. vLLM avec attention paginée pour le serving.
CPU uniquement ou appareil edge
Appareil embarqué, mode confidentialité sur laptop ou serveur sans GPU. Restez sur de petits modèles — Gemma 3 4B ou Mistral 7B — servis via llama.cpp. Fixez des attentes réalistes : la qualité n'atteindra pas un modèle hébergé de tier A.
Inference open-weight managée
Vous voulez la licence et la traçabilité des modèles ouverts sans opérer vous-même les GPU. Des fournisseurs comme OVH AI Endpoints servent Llama, Mistral, Qwen et Gemma sur une infrastructure résidente en UE avec une tarification au token — un juste milieu entre l'auto-hébergement complet et la frontier hébergée.
Testez sur votre propre matériel avant de vous engager
Empruntez le GPU sur lequel vous comptez déployer. Chargez deux candidats à la quantisation que vous comptez réellement livrer — pas la version full-precision sur un H100 emprunté — et faites passer les mêmes cent prompts dans les deux, à une concurrence réaliste. Vous en apprendrez davantage en une après-midi sur lequel vous convient que n'importe quelle page de benchmark ne peut vous en dire en un trimestre.
Lisez ensuite ce qui en sort. A-t-il supporté la quantisation ? Le débit a-t-il tenu sous charge simultanée ? La licence a-t-elle survécu à la première lecture de votre service juridique ? Votre stack de serving le traite-t-il en citoyen de première classe ou en accessoire ? Le modèle qui gagne sur votre matériel est celui qui va en production — même si aucun classement ne le place en tête.
Ouvrir l'outil de test en direct →