Vous vous demandez si votre budget infrastructure va exploser ou non cette année ? Le choix du matériel pour faire tourner vos grands modèles de langage (LLM) en production est devenu le gouffre financier numéro un des startups IA. En mai 2026, la décision n'est plus binaire entre « avoir » ou « ne pas avoir ». Elle se joue sur chaque centime dépensé par token généré.
Beaucoup pensent encore que le NVIDIA A100 suffit amplement. D'autres sautent immédiatement sur le char du NVIDIA H100, persuadés que c'est la seule voie viable. Et puis il y a ceux qui essaient de contourner le problème avec de l'offload CPU, espérant que leur serveur classique fera l'affaire. La réalité ? C'est plus nuancé. Votre modèle, votre volume de requêtes et votre tolérance à la latence dictent la réponse. Pas le marketing.
Pourquoi l'architecture change tout pour les LLM
Les LLM ne sont pas comme les anciens réseaux de neurones. Ils sont massivement limités par la bande passante mémoire, pas seulement par la puissance de calcul brute. Quand un modèle comme Llama 3.1 70B doit charger ses poids pour répondre à une question, la vitesse à laquelle ces données circulent de la mémoire vers les cœurs de calcul devient le facteur critique.
C'est ici que la différence entre l'A100 et le H100 devient rédemptrice. L'A100, lancé en 2020 avec l'architecture Ampere, utilise de la mémoire HBM2e avec une bande passante de 2,0 To/s. Le H100, basé sur l'architecture Hopper sortie fin 2022, passe à la mémoire HBM3. Cela porte la bande passante à 3,35 To/s. Soit une augmentation de 67,5 %.
Concrètement, cela signifie que le H100 peut alimenter ses cœurs Tensor bien plus vite. Pour l'inférence, où on lit souvent les mêmes poids répétés, cette rapidité de lecture se traduit directement par un débit de tokens supérieur. Si vous servez des utilisateurs en temps réel, chaque milliseconde compte. Avec l'A100, vous atteignez rapidement un plafond où ajouter plus de puissance de calcul ne sert à rien car la mémoire est saturée.
Le duel performance : H100 contre A100
Regardons les chiffres bruts sans filtre. Sur un benchmark standardisé utilisant le moteur d'inférence vLLM avec le modèle Llama 3.1 70B, le H100 SXM5 atteint environ 3 311 tokens par seconde. L'A100 NVLink, lui, plafonne autour de 1 148 tokens par seconde. C'est un gain de débit de 2,8 fois.
Mais attention au piège du prix horaire. Il est vrai qu'une instance H100 coûte cher à l'heure - disons 1,20 $/h sur AWS par exemple - tandis que l'A100 tourne autour de 0,75 $/h. Le H100 est donc 1,7 fois plus cher à louer. Pourtant, quand on divise le coût horaire par le nombre de tokens produits, le H100 s'avère souvent moins cher par unité de travail. Dans cet exemple précis, le H100 serait environ 18 % moins cher par token généré.
| Caractéristique | NVIDIA A100 (80GB) | NVIDIA H100 (80GB) |
|---|---|---|
| Bande passante mémoire | 2,0 To/s (HBM2e) | 3,35 To/s (HBM3) |
| Cœurs CUDA | 6 912 | 14 592 |
| Précision FP8 native | Non | Oui (Transformer Engine) |
| Débit Llama 3.1 70B (tokens/s) | ~1 148 | ~3 311 |
| Coût horaire estimé (Cloud 2025-2026) | ~0,75 $ | ~1,20 $ |
L'avantage du H100 s'accentue avec les modèles optimisés. Grâce à son Transformer Engine, le H100 supporte nativement la précision FP8. Cela permet de compresser dynamiquement les données pendant l'inférence sans perdre significativement en qualité. Un modèle de 30 milliards de paramètres peut voir ses performances augmenter de 3,3 fois sur H100 grâce à cette optimisation, là où l'A100 reste bloqué sur FP16 ou INT8.
L'option CPU Offloading : compromis ou impasse ?
L'offload CPU consiste à garder une partie des poids du modèle dans la RAM du processeur central (CPU) et à les transférer vers le GPU uniquement quand ils sont nécessaires. Des outils comme llama.cpp ou la bibliothèque accelerate de Hugging Face rendent cela possible même sur des machines modestes.
La tentation est forte : pourquoi payer des milliers de dollars pour un GPU si on peut utiliser un serveur AMD EPYC 9654 avec 128 Go de RAM ? Le problème, c'est la physique. La bande passante de la RAM DDR5, même haute fréquence, est dérisoire comparée au HBM3. Transférer des gigaoctets de données depuis la RAM système vers le GPU crée des goulots d'étranglement monstres.
En pratique, l'inférence sur CPU seul ou avec offload lourd augmente la latence d'un facteur 3 à 10. Là où un H100 répond en 200 à 500 millisecondes, un setup CPU-offload peut mettre 2 à 5 secondes par token. Pour une application de chatbot interactif, c'est inacceptable. L'utilisateur sent le délai, perd patience, et quitte. L'étude de Stanford sur le déploiement efficace des LLM (mai 2025) conclut clairement : l'offload CPU reste une solution de développement ou pour des usages batch hors ligne, mais échoue lamentablement pour les applications nécessitant une réponse sub-seconde.
Quand choisir quoi ? Scénarios réels
Il n'y a pas de gagnant absolu, seulement des contextes différents. Voici comment trancher selon votre situation actuelle en 2026.
Choisissez le NVIDIA H100 si :
- Votre modèle dépasse 13 milliards de paramètres (surtout au-delà de 30B).
- Vous servez plus de 100 utilisateurs concurrents.
- La latence est critique (chatbots, assistants vocaux, trading algorithmique).
- Vous voulez tirer parti de la précision FP8 pour réduire les coûts mémoire.
Gardez le NVIDIA A100 si :
- Votre modèle fait moins de 13 milliards de paramètres (ex: Mistral 7B, Llama 3 8B).
- Votre charge de travail est mixte (entraînement léger + inférence modérée).
- Vous avez besoin d'outils matures : 85 % des frameworks populaires ont un support « prêt à l'emploi » pour A100, réduisant le temps d'optimisation à quelques jours.
- Votre budget immédiat est serré et le volume de requêtes est faible.
Envisagez l'Offload CPU si :
- Vous êtes en phase de prototype ou de recherche exploratoire.
- Vous devez exécuter des tâches batch nocturnes (résumé de documents, analyse de rapports) où la latence importe peu.
- Vous manquez cruellement de fonds et ne pouvez pas accéder au cloud GPU.
- Vous acceptez des temps de réponse de plusieurs secondes par token.
Les coûts cachés et la complexité opérationnelle
Acheter ou louer le GPU n'est que la première étape. Le H100 demande un effort d'ingénierie plus important pour exprimer son plein potentiel. Activer le Transformer Engine et configurer correctement la précision FP8 peut prendre 2 à 4 semaines d'optimisation selon NVIDIA. Si votre équipe n'a pas d'experts en systèmes IA, vous risquez de payer pour du matériel que vous utilisez mal.
L'A100, plus âgé, bénéficie d'une écosystème logiciel très rodé. Les bibliothèques comme vLLM, TensorRT-LLM et DeepSpeed offrent des configurations par défaut stables. Vous pouvez être opérationnel en 1 à 3 jours. Cette maturité a une valeur économique réelle : moins de bugs, moins de temps perdu en débogage.
L'offload CPU, quant à lui, semble simple au départ mais cache des complexités terribles. Gérer le swapping mémoire manuellement pour éviter les plantages avec des modèles de 70B+ demande des efforts importants. Les contributeurs de llama.cpp rapportent passer 5 à 7 jours juste pour stabiliser une configuration fonctionnelle. Et même stabilisée, la performance reste médiocre.
Le marché en 2026 : tendances et alternatives
Le paysage a changé radicalement depuis début 2025. Les prix des instances H100 dans le cloud ont chuté de 40 %, rendant cette option accessible à beaucoup plus d'entreprises. Selon Gartner, le H100 représente désormais 62 % des nouveaux déploiements d'inférence LLM en entreprise, loin devant l'A100 (28 %) et les solutions CPU (10 %).
Des alternatives émergent, mais elles peinent à combler le fossé. Le AMD MI300X offre un bon rapport qualité-prix (85 % du coût du H100), mais ses performances restent inférieures pour les workloads transformers purs. Du côté de Google, les TPU v5p lancés en juin 2025 promettent un débit 1,8 fois supérieur au H100 pour certaines architectures, mais le support des frameworks reste limité et propriétaire.
NVIDIA continue de renforcer sa position avec des variantes comme le H100 Turbo, optimisé thermiquement pour les clusters denses, et le H100 NVL qui double la mémoire vive disponible via deux GPUs interconnectés. Pour les modèles géants dépassant 80 Go, cette dernière option devient bientôt indispensable.
Conclusion pragmatique
Ne choisissez pas votre GPU en fonction de ce qui est à la mode. Choisissez-le en fonction de votre goulot d'étranglement actuel. Si votre limite est la bande passante mémoire et la concurrence utilisateur, le H100 est aujourd'hui l'investissement le plus rentable malgré son coût initial élevé. Si vous démarrez petit avec des modèles légers, l'A100 reste un cheval de trait fiable et moins cher à intégrer. Et si vous testez des idées sans pression commerciale, l'offload CPU vous laisse explorer sans risque financier majeur.
La clé est de mesurer. Prenez votre modèle exact, simulez votre charge de trafic attendue, et calculez le coût par token sur chaque plateforme. Les benchmarks publics sont utiles, mais vos données réelles feront la différence entre un succès scalable et une facture insupportable.
Est-ce que le H100 vaut vraiment le supplément par rapport à l'A100 pour l'inférence ?
Oui, surtout pour les modèles supérieurs à 13 milliards de paramètres. Bien que le H100 coûte environ 1,7 fois plus cher à l'heure, son débit de tokens est jusqu'à 2,8 fois supérieur sur les gros modèles. Cela se traduit souvent par un coût par token inférieur de 15 à 20 %. De plus, la prise en charge native de FP8 améliore l'efficacité mémoire, permettant de servir plus d'utilisateurs concurrents sans augmenter la latence.
Puis-je utiliser l'offload CPU pour une application de chatbot en production ?
Généralement non. L'offload CPU introduit des latences de 2 à 5 secondes par token, ce qui est inacceptable pour une expérience utilisateur fluide. Les études montrent que les utilisateurs abandonnent rapidement face à de tels délais. L'offload CPU convient mieux aux tâches batch, au développement ou aux environnements de test où la rapidité de réponse n'est pas critique.
Quelle est la durée de vie restante de l'A100 pour les nouveaux projets LLM ?
Les analyses suggèrent que l'A100 deviendra obsolète pour les nouveaux déploiements majeurs dans 2 à 3 ans. Avec l'arrivée de modèles dépassant le trillion de paramètres, la bande passante mémoire limitée de l'A100 (2,0 To/s) deviendra un frein majeur. Pour des projets à long terme, le H100 offre une pertinence estimée de 3 à 5 ans avant le prochain changement architectural majeur.
Dois-je migrer immédiatement tous mes serveurs A100 vers H100 ?
Pas nécessairement. Si vos modèles actuels font moins de 13 milliards de paramètres et que votre charge de concurrence est faible, l'A100 reste économiquement viable. La migration vers H100 implique aussi un effort d'optimisation logiciel (activation FP8, etc.). Priorisez la migration pour les workloads critiques, à fort volume ou utilisant des modèles lourds (>30B). Gardez l'A100 pour les tâches secondaires ou expérimentales.
Comment comparer le coût réel entre H100 et A100 ?
Ne regardez pas seulement le prix horaire. Calculez le « coût par million de tokens ». Divisez le coût horaire du GPU par le nombre de tokens générés par heure sous charge réelle. Ajoutez-y les coûts d'ingénierie pour l'optimisation (plus élevés pour H100 initialement). Cette métrique révèle souvent que le H100 est plus économique à grande échelle, tandis que l'A100 peut l'emporter sur des volumes faibles grâce à sa simplicité de déploiement.
