Nous avons dépensé 18 $ pour comparer des LLM auto-hébergés. Les API les moins chères ont quand même gagné — sauf quand ce n’était pas le cas.

La même heure de GPU, le même modèle, la même tâche : 122 733 requêtes un après-midi, 56 987 le lendemain. Rien n’a changé dans l’infrastructure. Seul le trafic a changé.

La question que tout le monde évalue mal

Toute équipe qui construit sur des modèles ouverts finit par affronter la même bifurcation : payer un fournisseur au token, ou louer un GPU à l’heure et servir le modèle soi-même. Le débat tourne d’habitude sur les mauvaises variables — qualité du modèle, fonctionnalités de la plateforme, préférence pour un fournisseur. Nous avons donc arrêté de débattre et avons mesuré.

Notre dispositif était délibérément simple. Les nouveaux « Auto Endpoints » de Modal déploient un modèle ouvert derrière une API compatible OpenAI en une seule commande, facturée à la seconde d’utilisation du GPU, avec mise à zéro à l’inactivité. Nous avons déployé deux modèles aux extrémités opposées de l’échelle — Gemma 4 E2B (un modèle de classe 2B sur un A100, ~2,50 $/heure) et GPT-OSS-120B d’OpenAI (117 milliards de paramètres, sur un B200 à 9 $/heure) — et fait tourner chacun sur un protocole identique d’une heure : cinq minutes à concurrence 1 pour mesurer ce que ressent un utilisateur unique, quinze minutes à concurrence 16 pour simuler un pipeline réaliste, quarante minutes à concurrence 48 pour trouver le plafond. La tâche était une classification de sentiment avec sortie JSON strictement typée — intentionnellement facile, car nous testions l’infrastructure et son économie, pas l’intelligence du modèle. Une variable à la fois.

Cinq expériences. Environ 345 000 requêtes. Dépense totale : environ 18 $.

Ce que nous avons trouvé : savoir si l’auto-hébergement bat l’API n’est ni une question de modèle, ni une question de plateforme. C’est une question de trafic — à quel point vos prompts se répètent, à quel point votre volume est lourd, et à quel point il est régulier.

Le facteur 2,2 que personne ne met sur une page tarifaire

Notre premier run a fait tourner en boucle un ensemble fixe de 48 textes pendant une heure et a complété 122 733 requêtes. Nous avons ensuite refait la même heure à l’identique, avec un seul changement : chaque requête portait un document unique. Le débit est tombé à 56 987 — une chute de 2,2x, sur le même GPU, le même modèle, la même configuration.

Le mécanisme est la mise en cache de préfixe. Les moteurs d’inférence modernes mettent en cache le calcul des préfixes de prompt répétés ; les métriques du moteur lui-même montraient un taux de succès de cache de 92 % lors du premier run, et de 8 à 11 % lors du second (juste le prompt système partagé). Quand votre trafic se répète — instructions partagées, extraction sur modèle fixe, RAG sur un corpus stable — la plupart de vos « tokens d’entrée » ne coûtent presque rien au GPU.

Voici pourquoi cela compte commercialement : les API au token vous facturent la même chose pour un token en cache et un token calculé. Quand vous louez le GPU, le dividende de mise en cache est le vôtre ; quand vous payez au token, c’est la marge de votre fournisseur. Une équipe dont le trafic est répétitif à 90 % et une équipe qui traite des documents uniques achètent des quantités de calcul complètement différentes — et seul un des deux modèles de tarification le leur permet de voir.

La surprise de l’échelle

L’intuition dit qu’un modèle 50 fois plus gros coûte bien plus cher à exécuter. Nos factures disent le contraire. Le modèle à 120 milliards de paramètres sur le B200 a délivré 3,7 fois le débit du modèle à 2 milliards sur l’A100 — 33 000 contre 8 900 tokens par seconde sur des documents uniques — pour 3,6 fois le prix horaire. Le coût par million de tokens ressort quasiment identique : 0,076 $ contre 0,078 $. Le coût pour mille requêtes chute d’un facteur trois, à environ quatre centimes et demi.

Deux facteurs ont absorbé tout le saut d’échelle : la conception en mélange d’experts du modèle n’active que 5,1 milliards de ses 117 milliards de paramètres par token, et la génération de GPU plus récente apporte bien plus de bande passante mémoire par dollar. Nous présentons ceci comme un résultat mesuré pour cette paire précise, pas comme une loi générale — un modèle dense de 70 milliards raconterait une histoire différente. Mais cela brise un réflexe qui mérite de l’être : ne tarifez pas un modèle par son nombre de paramètres.

Où nous avons perdu, et où l’équation bascule

Voici maintenant le résultat qu’un benchmark sponsorisé par un fournisseur enterrerait. À notre meilleur débit mesuré, le coût effectif du modèle à 120B auto-hébergé était de 0,076 $ par million de tokens. Les tarifs API les moins chers des hyperscalers pour ce même modèle se situent autour de 0,04 $ en entrée et 0,14–0,18 $ en sortie — ce qui signifie que, pour un trafic de documents uniques, ces fournisseurs battent notre GPU unique même si nous le maintenions saturé à 100 % du temps. Le seuil de rentabilité n’arrive jamais. La raison est structurelle : un fournisseur qui regroupe les requêtes de milliers de clients atteint une utilisation qu’aucun locataire unique ne peut égaler, et un seul GPU ne peut pas surpasser une flotte en mutualisation.

Mais « l’API » n’est pas un prix unique. Les tarifs pour ce même modèle s’étalent sur une fourchette d’environ 8x entre les fournisseurs hyperscale en batch et les paliers premium à faible latence. Face au palier rapide (0,15 $ en entrée / 0,75 $ en sortie par million), notre B200 atteignait le seuil de rentabilité à 31–45 % d’utilisation et l’emportait nettement au-delà. Et sur du trafic répétitif — le régime de mise en cache — l’option auto-hébergée battait la majorité du marché, sans conteste.

La carte honnête comporte donc trois régions. Documents uniques à volume modéré : achetez des tokens auprès d’un fournisseur hyperscale. Trafic répétitif à haut volume, ou charges de travail actuellement facturées aux paliers API premium : le GPU horaire l’emporte. Tout le reste : cela dépend d’un chiffre que vous pouvez calculer à l’avance — l’utilisation au seuil de rentabilité : le prix horaire de votre GPU divisé par ce que coûterait votre volume horaire de tokens à l’API. Le nôtre allait de 0,31 (l’auto-hébergement gagne facilement) à 1,86 (il ne peut pas gagner).

Une précision sur le périmètre : notre charge de travail était composée à 98 % de tokens d’entrée — de la classification sur documents. Les charges de travail orientées sortie, comme le chat ou la rédaction, modifient le calcul des deux côtés, ce qui est exactement pourquoi vous devriez faire tourner ce calcul sur votre propre mix de trafic. Les prix de cet article vieilliront ; cette division, non.

À quelle vitesse peut aller un seul GPU

Le coût n’est que la moitié de la bifurcation ; l’autre moitié est la vitesse. Nous avons donc fait tourner une dernière comparaison côte à côte : 300 requêtes identiques à concurrence 1, depuis la même machine, contre notre B200 auto-hébergé et contre le même modèle sur le marché des API via OpenRouter — une fois en laissant le routeur choisir le fournisseur, une fois épinglé sur le palier le moins cher (DeepInfra), une fois épinglé sur le plus rapide (Groq).

Trois éléments de ce tableau méritent une relecture de contrat. Premièrement, le palier premium a battu notre médiane de 44 millisecondes — et a perdu partout ailleurs : notre p95 était presque deux fois meilleur, notre p99 était 2,3 fois meilleur, notre gigue quatre fois plus serrée, et nous n’avons jamais été limités en débit. La tenance dédiée ne vous achète pas la médiane la plus rapide ; elle vous achète une queue de distribution qui existe à peine, et la latence de queue est ce que les utilisateurs ressentent réellement. Deuxièmement, « l’API » telle que la plupart des utilisateurs la consomment — la route par défaut — est une loterie : nos requêtes ont été servies par treize fournisseurs différents dont les médianes individuelles s’étalaient de 0,29 à 5,08 secondes, une fourchette de 17x derrière un seul point d’entrée.

Troisièmement, une découverte fortuite que nous considérons comme le risque le plus sous-estimé de ce marché : chacun des sept échecs sur la route par défaut était une réponse de sortie structurée malformée, et les sept provenaient d’un seul fournisseur — un taux d’échec de schéma de 32 % sur les requêtes qu’il a servies, contre zéro réponse malformée sur nos 345 000 requêtes auto-hébergées. La fiabilité de la sortie structurée est une propriété du fournisseur, et aucune page tarifaire ne le mentionne.

Notez la symétrie avec l’économie : le seul palier API qui égale la vitesse d’un GPU dédié est le palier premium — précisément celui que notre seuil de rentabilité indique comme battu par l’auto-hébergement dès 45 % d’utilisation. Plus votre produit dépend de la latence, moins vous êtes en concurrence avec le plancher du marché des API, et meilleur le GPU horaire paraît.

Ce que la page tarifaire ne vous dit pas

Trois faits opérationnels tirés de nos journaux, parce qu’un rapport de terrain vous doit la friction. Les démarrages à froid allaient de quatre à neuf minutes sur quatre démarrages — une variance de 2x — l’essentiel provenant de l’initialisation du moteur et de la capture de graphes CUDA, pas du chargement des poids — ce qui rend la mise à zéro impropre aux charges de travail interactives sans stratégies de préchauffage. Sous surcharge soutenue avec des documents uniques, la recette de service du petit modèle a planté et s’est auto-réparée, coûtant huit minutes de disponibilité en cours de run ; la configuration à 120B a traité 164 641 requêtes avec une seule erreur. Et sur l’ensemble des 344 000 requêtes, la sortie JSON strictement typée n’a jamais produit une seule réponse malformée — la sortie structurée au niveau du moteur est, dans notre expérience, prête pour la production.

Rien de tout cela n’apparaît dans la tarification au token, et tout cela est apparu dans nos trois premières heures de GPU. Cette asymétrie est l’argument le plus profond en faveur du test : le modèle horaire vous montre le comportement réel de votre système — ses caches, ses plafonds, ses modes de défaillance — parce que vous possédez la pile de service qui le produit.

Quatre questions avant votre prochaine décision d’inférence

1. Quelle fraction des tokens de votre prompt se répète d’une requête à l’autre — et quelqu’un l’a-t-il mesurée ?
2. Que coûterait une heure de votre volume de tokens réel aux tarifs de votre fournisseur actuel ?
3. Quelle est votre utilisation au seuil de rentabilité face au palier API le moins cher et le plus rapide servant votre modèle ?
4. Votre budget de latence est-il défini à la médiane ou au 99e centile — et quel palier du marché des API l’atteint réellement ?

Notre protocole complet — sondage, charge par phases, comptage des tokens, calcul du seuil de rentabilité — est une paire de scripts Python que nous avons publiés en open source. L’exécuter sur votre propre point de terminaison coûte à peu près le prix d’un déjeuner.

L’API vous vend des tokens. Le GPU vous vend une heure. Lequel est le moins cher est écrit dans votre trafic, pas sur leur page tarifaire.

Benchmarks : Modal Auto Endpoints, juillet 2026 — Gemma 4 E2B-it (1×A100-40GB, 2,50 $/h) et GPT-OSS-120B (1×B200, 9 $/h), recettes SGLang, us-west, un seul conteneur, protocole identique en 3 phases. Prix API de référence issus des tarifs publics des fournisseurs, juillet 2026. Comparaison de latence : 300 requêtes par cible à concurrence 1 via OpenRouter (auto, épinglé DeepInfra, épinglé Groq), même client et même charge utile ; le nombre de tokens de complétion variait selon le fournisseur (19-35 tokens), les contrôles de raisonnement étant honorés différemment. Données complètes par requête et scripts disponibles dans le dépôt référencé.