Cloud ou Métal : Où Héberger vos Modèles IA de Pointe en 2026 ?
Votre équipe vient de livrer une fonctionnalité IA. Les utilisateurs adorent. Le trafic monte. La facture OpenAI dévore votre trésorerie. Quelqu’un pose la question que toute équipe IA finit par affronter : “Ne devrions-nous pas faire tourner ça nous-mêmes ?”
C’est le guide qui y répond --- pas avec de la théorie, mais avec de vrais chiffres, du vrai matériel, et un cadre de décision utilisable dès aujourd’hui.
TL;DR
- Le cloud gagne pour la plupart des équipes. Si votre utilisation GPU se situe en dessous de 70 % (et c’est probablement le cas), la location est plus économique et plus simple.
- Les clouds GPU spécialisés sont 40 à 85 % moins chers qu’AWS, GCP ou Azure. Utilisez CoreWeave, Lambda Labs, RunPod ou Spheron plutôt que les hyperscalers, sauf si vous avez des exigences de conformité spécifiques.
- Commencez avec vLLM. C’est le moteur qui offre le plus large support de modèles, sans étape de compilation, et avec un débit compétitif. Passez à TensorRT-LLM uniquement quand votre modèle est stabilisé et que vous avez besoin de performances maximales.
- Le H100 SXM5 reste le GPU par défaut en 2026. Le B200 est plus rapide, mais son approvisionnement reste limité.
- L’on-premise devient rentable à 80 %+ d’utilisation soutenue sur un horizon de 3 ans --- ou en moins de 4 mois pour les charges de travail à forte utilisation.
Le Scénario
Imaginez une startup IA de dix personnes à la mi-2026. Ils font tourner Qwen3.5-35B derrière une API de chatbot, en payant au token à un fournisseur de modèle en tant que service. Leur facture d’inférence mensuelle vient de dépasser 8 000 $. Le directeur financier veut réduire les coûts. Le directeur technique veut posséder l’infrastructure. L’équipe ingénierie veut arrêter de s’inquiéter des limites de débit et des données qui quittent leur VPC.
Ils doivent décider : louer des GPU auprès d’un fournisseur cloud, ou acheter leur propre matériel ?
C’est cette décision que nous allons parcourir. En chemin, nous couvrirons quel GPU choisir, quel moteur d’inférence utiliser, quel fournisseur cloud offre le meilleur rapport qualité-prix, et quels modèles open-weight valent réellement la peine d’être auto-hébergés aujourd’hui.
La Règle de l’Utilisation
Avant de comparer les prix ou le matériel, il y a un chiffre qui compte plus que tout autre : votre taux d’utilisation GPU.
La recherche est claire :
| Utilisation | Gagnant | Pourquoi |
|---|---|---|
| Moins de 70 % | Cloud | Vous ne payez que ce que vous utilisez. Du matériel inactif, c’est de l’argent gaspillé. |
| 70—80 % | Égalité | Dépend de l’horizon temporel, des besoins de conformité et de l’expertise de l’équipe. |
| 80 %+ soutenu | On-premise | Le matériel s’amortit. Jusqu’à 18x d’avantage en coût par million de tokens par rapport aux APIs MaaS sur 5 ans. |
La plupart des équipes en production opèrent entre 40 et 65 % d’utilisation en raison de la variabilité du trafic. Cela signifie que le cloud gagne pour la majorité des cas d’usage. Mais si vous exécutez des tâches d’inférence par lots 24h/24 ou si vous servez une API à fort trafic avec une charge prévisible, posséder du matériel devient pertinent.
Le calcul du point mort est étonnamment favorable pour les charges à forte utilisation : l’infrastructure on-premise peut atteindre son seuil de rentabilité en moins de 4 mois comparé aux prix des hyperscalers, selon le livre blanc TCO 2026 de Lenovo.
Sources : Spheron — On-Premise vs Cloud, avril 2026 | Lenovo Press — Livre blanc TCO, 2026
Quel GPU en 2026 ?
Le marché des GPU en 2026 est dominé par les architectures Hopper et Blackwell de NVIDIA. Voici le paysage :
| GPU | VRAM | Bande passante | Avantage clé | Statut |
|---|---|---|---|---|
| NVIDIA B200 | 192 Go HBM3e | 8 To/s | ~4x le débit d’inférence du H100 | Approvisionnement limité, listes d’attente |
| NVIDIA H200 | 141 Go HBM3e | 4,8 To/s | Évolution du H100, bonne disponibilité | Délai de 4 à 8 semaines |
| NVIDIA H100 SXM5 | 80 Go HBM3 | 3,35 To/s | Cheval de trait de production, meilleure disponibilité | Choix standard en 2026 |
| NVIDIA A100 | 80 Go HBM2e | 2 To/s | Milieu de gamme solide, prix en baisse | Moins de 1 $/h en spot chez certains fournisseurs |
| RTX 4090 (grand public) | 24 Go GDDR6X | 1 To/s | Meilleur rapport FLOPS/$ pour les petits modèles | Usage local/amateur uniquement |
Recommandations pratiques :
- Choix par défaut : H100 SXM5. Meilleure disponibilité, éprouvé en production, supporté par tous les moteurs d’inférence.
- Anticipation : B200, si vous pouvez en obtenir un. Il offre environ 4 fois le débit d’inférence d’un H100, mais l’approvisionnement reste limité jusqu’à la mi-2026.
- Option économique : Instances spot A100. Les performances sont solides et les prix chutent sous 1 $/h chez certains fournisseurs.
- Développement local : RTX 4090. Rapport FLOPS/euro incroyable pour les modèles de moins de 24 Go, mais non adapté au service en production.
Le calcul achat vs location pour un H100 : L’achat d’un H100 coûte environ 30 000 $. La location à 5 $/h signifie un seuil de rentabilité à environ 6 000 heures --- soit 3,4 ans à 5 heures par jour --- avant de compter l’électricité, le refroidissement et les installations. C’est pourquoi l’utilisation est si déterminante.
Sources : Inworld AI — Comparatif GPU Cloud, avril 2026 | WhiteFiber — Guide GPU
Fournisseurs Cloud : Qui a les Meilleurs Prix GPU ?
C’est ici que le marché devient intéressant. Les fournisseurs de cloud GPU spécialisés sont 40 à 85 % moins chers que les hyperscalers pour des charges GPU équivalentes. AWS, GCP et Azure ajoutent des frais de sortie, des primes de stockage et des charges réseau qui gonflent considérablement le coût réel.
| Fournisseur | GPU disponibles | Idéal pour | Notes |
|---|---|---|---|
| CoreWeave | H100, B200, A100 | Entraînement lourds, entreprise | Natif Kubernetes, HIPAA/SOC2/ISO27001 |
| Lambda Labs | H100, B200 | Chercheurs, inférence flexible | Tarification transparente, images DL solides |
| RunPod | H100, A100, RTX | Équipes soucieuses des coûts | Prix spot, large gamme de GPU |
| Spheron | H100 SXM5 | Prix spot les plus bas | H100 spot à partir de 1,03 $/h (mai 2026) |
| AWS (p5) | H100 | Organismes régulés, empreinte cloud existante | 4,10 à 6,88 $/h/GPU à la demande |
| GCP (A3 High) | H100 | Intégration GKE/Vertex AI | 11 à 16 $/h/GPU --- le plus cher |
| Azure | H100, B200 | Gouvernance entreprise, BYOK | InfiniBand Quantum-2, 3,2 Tbps |
Instantané de Prix (Mai—Juin 2026)
| GPU | Fournisseur | À la demande (/h) | Spot (/h) | Coût estimé /M tokens |
|---|---|---|---|---|
| H100 SXM5 | Spheron | ~2,90 $ | 1,03 $ | 0,47 $ |
| H100 SXM5 | AWS (p5) | 4,10 à 6,88 $ | Variable | --- |
| B200 | Divers | ~4 à 5 $ | 2,12 $ | 0,42 $ |
| A100 | Divers | ~1,50 à 2,00 $ | Moins de 1,00 $ | 0,57 $ |
La conclusion : Si vous payez les prix d’AWS ou de GCP pour l’inférence GPU, vous surpayez. Passez à un fournisseur spécialisé et vos coûts baissent de la moitié ou plus. Utilisez les hyperscalers uniquement lorsque vous avez des exigences de conformité spécifiques (HIPAA, FedRAMP) ou une intégration profonde avec leur écosystème (GKE, SageMaker).
Sources : Spheron — Prix GPU, mai 2026 | Inworld AI — Comparatif GPU Cloud, avril 2026
La Stack d’Inférence : vLLM vs SGLang vs TensorRT-LLM
Choisir le bon GPU n’est que la moitié de la bataille. La stack logicielle qui sert votre modèle détermine votre débit réel, votre latence et votre complexité opérationnelle. En 2026, le paysage des moteurs d’inférence s’est consolidé autour de trois concurrents sérieux.
La Hiérarchie de Recommandation 2026
- Commencez avec vLLM --- le plus large support de modèles, pas d’étape de compilation, un débit compétitif, la meilleure documentation. C’est le choix sûr par défaut pour toute équipe.
- Passez à TensorRT-LLM --- quand votre modèle est stabilisé depuis des mois et que vous avez besoin du débit maximum. Attendez-vous à un gain de 20 à 30 % sur vLLM, mais avec une étape de compilation de 28 minutes à relancer à chaque changement de modèle.
- Utilisez SGLang --- quand la latence individuelle des requêtes compte le plus (chat en temps réel, génération structurée, charges de travail avec préfixes partagés). Il excelle dans la minimisation du temps jusqu’au premier token.
- Évitez TGI (HuggingFace) --- officiellement en mode maintenance. HuggingFace recommande elle-même de migrer vers vLLM ou SGLang.
Comparaison des Benchmarks
| Moteur | Débit | Latence (TTFT) | Support modèles | Compilation | Idéal pour |
|---|---|---|---|---|---|
| vLLM | 4/5 | 3/5 | 5/5 | Aucune | Production générale, large couverture de modèles |
| SGLang | 3/5 | 5/5 | 4/5 | Aucune | Chat temps réel, génération structurée |
| TensorRT-LLM | 5/5 | 4/5 | 3/5 | ~28 min | Débit maximum, modèles stabilisés |
| llama.cpp | 2/5 | 3/5 | 5/5 | Aucune | CPU, local, edge, GPU grand public |
| Ollama | 2/5 | 3/5 | 4/5 | Aucune | Développement local uniquement --- pas pour la production |
| TGI | 3/5 | 3/5 | 4/5 | Aucune | Mode maintenance --- migrer |
Note sur les benchmarks : Sur H100 SXM5, TensorRT-LLM offre le meilleur débit et la meilleure latence mais nécessite une compilation. Sur le Blackwell B200, TensorRT-LLM atteint 1 000 tokens par seconde par utilisateur sur Llama 4 Maverick --- un chiffre impressionnant qui en fait le choix évident pour les charges de production à haut volume sur matériel de nouvelle génération.
Sources : Spheron — Benchmarks d’inférence, mars 2026 | The AI Engineer — Comparatif d’inférence, mars 2026
Les Modèles qui Valent la Peine d’Être Auto-Hébergés en 2026
Tous les modèles ne justifient pas un investissement en infrastructure. Voici les modèles open-weight qui rendent l’auto-hébergement pertinent en 2026 :
| Modèle | Paramètres (Total / Actifs) | Fenêtre de contexte | Pourquoi l’auto-héberger ? |
|---|---|---|---|
| Qwen3-Coder-30B-A3B | 30B / 3B MoE | 256K | Meilleur MoE de code pour du matériel 32—64 Go |
| Qwen3.5-35B-A3B | 35B / 3B MoE | 262K | Meilleur MoE généraliste à cette taille |
| Qwen3.5-122B-A10B | 122B / 10B MoE | 128K | Performances quasi-frontière, nécessite 64—96 Go |
| Nemotron-30B (Omni) | 30B / 3B MoE | 1M | Meilleur multimodal + vitesse ; hybride Mamba2 |
| DeepSeek V4 Pro | MoE large | --- | Score élevé à l’Intelligence Index |
| Kimi K2.6 | MoE | --- | Intelligence Index open-weight le plus élevé (54) |
Pourquoi ces modèles en particulier ? Ce sont des architectures Mixture-of-Experts (MoE), ce qui signifie qu’elles n’activent qu’une fraction de leurs paramètres totaux lors de l’inférence. Un modèle MoE de 35B avec 3B de paramètres actifs fonctionne presque aussi vite qu’un modèle dense de 3B tout en offrant une qualité proche d’un modèle dense de 30B+. Cela les rend incroyablement efficaces à auto-héberger --- vous obtenez une qualité de niveau frontière à une fraction du coût de calcul.
Le Nemotron-30B Omni mérite une mention spéciale : son architecture hybride Mamba2 et sa fenêtre de contexte de 1M le rendent unique pour les charges multimodales (texte, image, audio) sur un seul GPU.
La Matrice de Décision
Voici le cadre de décision consolidé en fonction de votre scénario spécifique :
| Scénario | Recommandation |
|---|---|
| Phase amorce / charge variable | Cloud spot (RunPod, Spheron) + vLLM |
| Production, trafic en croissance | CoreWeave ou Lambda H100/B200 + vLLM |
| Performance max, modèle stable | TensorRT-LLM ou conteneur NVIDIA NIM |
| Forte utilisation + résidence des données | Serveurs H100/B200 en propre + vLLM |
| Besoins multimodaux / omni | Nemotron-30B Omni sur cloud H100 |
| Apple Silicon / on-device | MLX + Qwen3-Coder-30B (pas de cloud nécessaire) |
| Régulé (HIPAA, ISO27001) | CoreWeave ou Azure + BYOK |
Retour à Notre Startup
Revenons au scénario de départ. Cette startup de dix personnes avec sa facture d’inférence de 8 000 $/mois ?
Voici ce qu’elle ferait :
-
Passer du MaaS à l’inférence auto-hébergée. Louer un H100 SXM5 sur Spheron à 1,03 $/h en spot (ou 2,90 $ à la demande). Exécuter Qwen3.5-35B-A3B via vLLM. Le coût par token passe de la tarification premium de l’API à environ 0,47 $ par million de tokens.
-
Utiliser un cloud GPU spécialisé, pas un hyperscaler. Spheron, RunPod ou Lambda Labs leur feront économiser 40 à 85 % par rapport à AWS ou GCP pour le même GPU.
-
Commencer avec vLLM, sans optimisation pour l’instant. À leur niveau de trafic, le débit de vLLM sur un seul H100 est largement suffisant. Ils pourront migrer vers TensorRT-LLM plus tard si le débit devient un goulot d’étranglement.
-
Surveiller l’utilisation. S’ils atteignent régulièrement 80 %+ d’utilisation, ils devraient planifier un achat on-premise. S’ils se situent à 40—60 %, rester sur des instances spot cloud est le bon choix.
Le résultat : leur facture d’inférence mensuelle passe de 8 000 $ à environ 800—1 500 $, selon les schémas de trafic. Soit une réduction de 5 à 10x avec une meilleure latence, un contrôle total des données et aucune limite de débit.
Pourquoi Cette Stack ?
Quelques mots sur le raisonnement derrière ces recommandations, au cas où vous pesez des alternatives :
Pourquoi les clouds spécialisés plutôt que les hyperscalers ? AWS, GCP et Azure facturent des prix premium pour les instances GPU parce qu’ils incluent le réseau, le stockage, la conformité et l’enfermement dans l’écosystème. Si vous n’avez pas besoin de ces extras, vous subventionnez des fonctionnalités que vous n’utilisez pas. Les fournisseurs spécialisés vous donnent le même GPU à une fraction du prix.
Pourquoi vLLM comme choix par défaut ? Il fonctionne avec pratiquement toutes les architectures de modèles dès la sortie de la boîte. Pas de compilation signifie que vous pouvez changer de modèle en quelques minutes. La documentation est excellente, la communauté est active et les performances sont compétitives. Vous n’avez besoin du gain de 20 à 30 % de TensorRT-LLM que lorsque vous poussez les limites de votre matériel --- et à ce moment-là, l’étape de compilation de 28 minutes en vaut la peine.
Pourquoi les modèles MoE ? Les architectures Mixture-of-Experts vous donnent la qualité d’un grand modèle au coût d’inférence d’un petit. Qwen3.5-35B-A3B n’active que 3 milliards de ses 35 milliards de paramètres par token. Cela signifie des performances quasi-frontière sur du matériel qui aurait du mal avec un modèle dense de 35B.
Pourquoi ne pas simplement utiliser Ollama pour tout ? Ollama est fantastique pour le développement local et l’expérimentation. Il n’est pas conçu pour le service en production à grande échelle. Il lui manque les optimisations de batching, de scheduling et de débit que vLLM, SGLang et TensorRT-LLM fournissent. Utilisez Ollama sur votre laptop ; utilisez vLLM en production.
Sources
Le marché des GPU évolue vite. La stack d’inférence encore plus vite. Mais le compromis fondamental --- louer ou posséder, cloud ou métal, flexibilité ou contrôle --- est la même décision que toute équipe IA affronte en s’agrandissant. Choisissez le bon outil pour votre utilisation, votre calendrier et vos contraintes. Tout le reste en découle.