Inférence LLM — Passé, présent et avenir : où va la valeur ?
Depuis deux ans, l'inférence LLM est l'une des couches les plus disputées de l'infrastructure IA. Des dizaines de fournisseurs d'inférence, de clouds GPU, de projets open source et de fabricants de puces poursuivent tous le même objectif : servir un modèle entraîné plus rapidement et à moindre coût que le concurrent.
L'attrait reposait sur une idée plausible. L'inférence ressemblait à un problème logiciel avec un fossé défensif logiciel. De meilleurs noyaux, un ordonnanceur plus malin ou un décodage spéculatif plus performant pouvaient justifier des prix premium ou de meilleures marges à prix égal. Pendant un temps, un moteur maison était une véritable arme concurrentielle, et les benchmarks remportaient des contrats.
Cette période touche à sa fin. L'inférence compte plus que jamais et le marché continue de croître, mais la valeur défendable s'est éloignée du moteur. La couche moteur se banalise rapidement. La valeur se déplace d'abord vers les opérations et les plateformes de serving, puis vers le capital, la capacité GPU et, à terme, les centres de données eux-mêmes.
La performance logicielle compte toujours. Un moteur lent ou peu fiable peut disqualifier un fournisseur. Mais une bonne performance est devenue largement accessible, ce qui rend difficile pour une entreprise de la facturer en tant que telle. La question n'est plus de savoir si le moteur crée de la valeur, mais qui capture cette valeur une fois que le moteur devient une infrastructure commune.
Trois générations matérielles rendent ce changement visible. Le même schéma explique la compétition actuelle entre fournisseurs d'inférence et sa trajectoire probable.
Partie I : Le passé — quand le moteur était le fossé
Trois générations, trois listes de contrôle
Chaque génération matérielle NVIDIA était accompagnée d'une liste de contrôle pour un moteur maison. Ce qui changeait, c'était la vitesse à laquelle cette liste devenait un savoir public, et le peu d'avantage qui subsistait une fois que tout le monde l'avait complétée.
L'ère Ampere (A100). Le niveau initial était concret. Un moteur prenant en charge CUDA Graphs pour éliminer la surcharge de lancement, implémentant le décodage spéculatif tel que EAGLE-1 ou Medusa, et proposant une quantification INT8 W8A8 solide, devançait la majeure partie du marché. L'ingénierie était difficile mais circonscrite, et compléter cette courte liste plaçait un fournisseur dans le haut du classement. Ces fonctionnalités remportaient des contrats.
L'ère Hopper (H100/H200). La liste s'est allongée et s'est scindée en deux. Pour un déploiement unique — qu'il s'agisse d'une réplique, d'un nœud ou de quelques-uns — les facteurs de différenciation étaient FlashAttention-3, l'attention FP8, le décodage spéculatif EAGLE-3 et la quantification FP8 W8A8. Des implémentations solides produisaient des résultats mono-nœud remarquables.
Hopper a également ouvert un second front dans le déploiement désagrégé. La prise en charge de la désagrégation prefill-decode (PD), du parallélisme expert (EP) pour les architectures MoE de plus en plus dominantes, et du déchargement du cache KV à travers la hiérarchie mémoire comptait à l'échelle du cluster, là où se trouvaient les plus gros contrats. Ce niveau exigeait de l'ingénierie système autant que du travail sur les noyaux. Pendant un temps, il a séparé les fournisseurs les plus solides de tous les autres.
Les deux niveaux récompensaient des capacités différentes. Les équipes de noyaux pouvaient encore gagner un benchmark sur un déploiement contenu, tandis que les plus gros workloads de production exigeaient une coordination entre machines, pools mémoire et domaines de défaillance. Ce second niveau a mis plus de temps à être copié et a donné aux fournisseurs une fenêtre plus large pour transformer le travail d'ingénierie en revenus.
L'ère Blackwell (B200/B300/GB200/GB300). Ici, la liste s'est réduite à un seul élément principal : l'optimisation NVFP4. La voie dominante n'est plus une implémentation indépendante. Les équipes intègrent les cubins trtllm-gen fournis par NVIDIA ou s'appuient directement sur TensorRT-LLM. Le décodage spéculatif, les chemins FP8 et FP4, la prise en charge de la désagrégation et le parallélisme MoE sont déjà dans la pile de référence.
Blackwell modifie la décision « faire ou acheter ». Construire la pile une fois témoignait d'une profondeur technique ; désormais, cela revient à recréer le travail du fournisseur pendant que les concurrents emploient leurs ingénieurs ailleurs. Une implémentation propriétaire peut encore convenir à un modèle ou un déploiement inhabituel, mais ce n'est plus le chemin par défaut vers la performance de pointe.
L'inférence n'a pas de secrets. Chaque technique importante a un article, une implémentation open source ou un binaire du fournisseur. Les connaissances qui circulaient autrefois dans une poignée d'équipes de performance sont désormais packagées dans du code que tout groupe compétent peut inspecter ou intégrer. La liste de contrôle qualifie toujours un moteur, mais ne le distingue plus.
Pourquoi TRT-LLM est devenu la référence de l'ère Blackwell
La position de TensorRT-LLM dans l'ère Blackwell découle des incitations des deux côtés du marché.
NVIDIA a besoin que TRT-LLM soit performant. Le logiciel sous-tend ses benchmarks sur le nouveau matériel, y compris les soumissions InferenceX, les annonces du jour de lancement et les résultats des keynotes. Les optimisations pour une nouvelle puce arrivent donc dans TRT-LLM dès le premier jour, portées par une grande organisation d'ingénierie de noyaux et un runtime performant.
Les moteurs indépendants ne peuvent pas reproduire cet avantage par le seul effort. NVIDIA voit la feuille de route matérielle, contrôle les couches logicielles les plus basses et a une raison commerciale directe de rendre chaque génération impressionnante au lancement. TRT-LLM est le point de rencontre de ces incitations.
Dans le même temps, une poignée de familles de modèles open-weight de pointe représente désormais l'écrasante majorité du trafic de production sérieux. Les fournisseurs ont moins besoin de prendre en charge des centaines d'architectures. Avec cet ensemble de modèles plus restreint et le matériel Blackwell, TRT-LLM offre le plafond de performance le plus élevé disponible. La largeur de prise en charge des modèles, l'argument traditionnel d'un moteur polyvalent, importe moins lorsque la demande elle-même s'est resserrée.
La production récompense désormais la spécialisation. Un moteur qui gère bien une longue traîne est utile, mais un fournisseur tire l'essentiel de ses revenus des modèles que les clients demandent réellement. Sur une petite matrice de modèles populaires et de matériel NVIDIA actuel, la performance de pointe pèse plus lourd que la largeur architecturale.
Depuis mi-2025, davantage d'équipes d'inférence ont cessé de maintenir des moteurs totalement indépendants pour passer au développement secondaire sur TRT-LLM. Sa faiblesse persistante est l'ergonomie. L'expérience développeur est rude, mais une équipe payée pour extraire les derniers 20 % d'un parc GPU tolérera une chaîne d'outils difficile. L'ergonomie départage ; TRT-LLM sur Blackwell n'a pas d'égal pour départager.
Ces équipes n'ont pas cessé de faire de l'ingénierie. Elles continuent d'ajuster les modèles, de corriger le comportement du runtime et de construire les systèmes de production autour du moteur. Ce qui a changé, c'est la couche à partir de laquelle elles commencent. Partir de la ligne de base de NVIDIA oriente davantage d'efforts vers leur workload et moins vers la reproduction d'une machinerie générale.
L'accélérateur : les agents de codage
La convergence open source et la poussée verticale de NVIDIA raccourcissaient déjà la durée de vie des avantages propriétaires. Au cours des six derniers mois, les agents de codage l'ont encore raccourcie en réduisant le coût de l'ingénierie d'inférence.
Le travail sur les noyaux, les modifications du runtime et l'infrastructure de serving peuvent tous être menés plus rapidement avec l'assistance de l'IA. Intent Lab a mis environ une semaine, en travaillant avec des agents sur TRT-LLM, pour livrer des optimisations qui ont produit de très importants gains de bout en bout. Auparavant, un travail de cette ampleur aurait pu occuper un ingénieur dédié pendant un trimestre.
L'économie du travail sur un moteur propriétaire change avec cette vitesse. Une technique qui exigeait six mois-ingénieur et achetait neuf mois d'exclusivité pouvait justifier l'investissement. S'il faut deux semaines pour la construire et que les concurrents la reproduisent en trois, le résultat n'est pas un fossé ; c'est un tapis roulant. Le travail reste techniquement difficile, mais la durée de vie utile de l'avantage approche de zéro.
Ce qui compte économiquement, c'est la durée de l'avance. Une optimisation difficile peut être commercialement faible si elle se diffuse avant que l'entreprise n'ait récupéré son coût de construction. Les agents de codage ne rendent pas l'ingénierie triviale ; ils font expirer l'exclusivité plus vite.
Ce qui reste pour les moteurs ouverts : communauté, ergonomie et très peu de loyauté
vLLM, SGLang et les autres moteurs open source servent le marché laissé vacant par l'expérience développeur rude de TRT-LLM. De nombreux utilisateurs en dehors des fournisseurs disposant d'équipes d'inférence dédiées sont des chercheurs ou exécutent de la génération hors ligne : des workloads par lots orientés débit plutôt que du serving en ligne sensible à la latence. Dans ces contextes, l'écart de performance avec TRT-LLM est modeste, souvent négligeable.
Ces utilisateurs optimisent un flux de travail différent. Ils doivent déployer un modèle rapidement, changer d'architecture sans réécrire la pile et trouver des réponses quand quelque chose casse. Quelques points de pourcentage de débit justifient rarement des jours passés à se battre avec un runtime, surtout lorsque le workload n'a pas d'objectif de latence interactif.
L'adoption dépend alors de la facilité d'utilisation, de la documentation et de la communauté. Installer le paquet, le pointer vers un dépôt Hugging Face et exposer un endpoint compatible OpenAI. Pour un chercheur ou un pipeline de génération par lots, c'est toute la décision d'achat.
L'adoption n'est pas la loyauté. La standardisation sur l'API compatible OpenAI réduit un changement de moteur, dans le cas le plus simple, à une modification de base_url. Une équipe peut faire tourner vLLM aujourd'hui, essayer SGLang demain et benchmarker les deux plus tard dans la semaine. Les moteurs ouverts doivent continuer à conquérir des workloads qu'ils ont déjà gagnés.
Les utilisateurs bénéficient de cette portabilité ; les projets en quête de contrôle durable, non. La taille de la communauté peut attirer un workload, et la documentation peut le retenir un temps, mais ni l'une ni l'autre n'empêche une équipe de relancer la comparaison lorsqu'un concurrent publie une version plus rapide.
Les vrais coûts de changement apparaissent dans la production en ligne. Ils viennent de la supervision et des alertes, des pipelines de déploiement, de la reprise après sinistre, de la récupération automatique des pannes, des corrections de bugs accumulées et de la longue traîne des cas limites de production. Le parsing des appels d'outils fournit à lui seul de nombreux exemples. Cette couche opérationnelle crée un verrouillage, mais c'est une friction de migration plutôt qu'un fossé de capacité. Une équipe compétente peut la reproduire autour d'un autre moteur en quelques semaines. Plus important encore, cette connaissance appartient à l'organisation SRE de l'utilisateur, donc le projet de moteur n'en capture rien.
Commercialement, la connaissance opérationnelle rend un déploiement difficile à abandonner sans donner au vendeur de moteur le pouvoir de fixer ses prix. L'utilisateur supporte le coût de migration et possède l'essentiel des systèmes environnants. Même lorsque le remplacement est pénible, le moteur lui-même n'a pas verrouillé le compte.
L'open source comme bien public
Les principaux moteurs open source ont largement accepté ce rôle. vLLM et SGLang reversent presque tout leur travail à la communauté. Leur objectif stratégique est l'adoption ; le résultat est une base gratuite en amélioration constante en termes de fonctionnalités, de performance et de stabilité. En pratique, l'écosystème subventionne l'inférence de pointe pour tout le monde.
Il y a un coût pour les projets eux-mêmes. Chaque amélioration de la base réduit la marge de différenciation, y compris pour les moteurs maison et les moteurs ouverts qui ont apporté cette amélioration. En élevant le plancher, ces projets compriment aussi la valeur de leur propre couche.
Le signe révélateur : les entreprises de moteurs montent dans la pile
Le comportement des auteurs de moteurs est la preuve la plus claire qu'un moteur seul ne peut pas capturer beaucoup de valeur.
Les entreprises derrière les deux principaux moteurs open source ont commencé à prendre des contrats de serving en production, signant, selon certaines informations, des contrats d'inférence
Un logiciel peut être ajouté à une base d'actifs bien plus rapidement qu'une base d'actifs ne peut être ajoutée à une société de logiciels. La commoditisation des moteurs a aidé les fournisseurs à se développer, mais elle arme aussi leur challenger le plus dangereux.
Le plus grand rival auquel sont confrontés Together AI, Fireworks et Baseten n'est pas un autre fournisseur. C'est Nebius, suivi de tout néocloud prêt à monter dans la pile.
Où vont désormais les heures d'ingénierie
L'ingénierie d'inférence comptera toujours chez les fournisseurs, mais son allocation va changer. Les moteurs open source rendent cette réallocation possible.
À mesure que le niveau de base des moteurs gratuits s'améliore, les fournisseurs peuvent dégager leurs heures d'ingénierie coûteuses des noyaux et des runtimes. Ces heures sont investies dans la fiabilité de l'infrastructure, qui donne de la substance aux SLA ; dans l'expérience de la plateforme, qui favorise les renouvellements ; et de plus en plus dans le RL. Les rollouts d'apprentissage par renforcement sont très gourmands en inférence, de sorte que l'expertise en serving se transfère directement vers l'infrastructure RL du marché croissant du post-entraînement.
Les fournisseurs ne se retirent pas du travail technique. La fiabilité d'un parc hétérogène, la reprise rapide sous charge et des rollouts RL efficaces sont des problèmes système difficiles. Leurs solutions restent plus proches des clients et des opérations du fournisseur, ce qui en fait des sources de différenciation plus utiles.
La valeur de la couche moteur n'a pas disparu. L'open source l'a intégrée dans un socle gratuit, permettant à la valeur de l'ingénierie de migrer vers les systèmes construits au-dessus. La question stratégique pour la plupart des entreprises n'est plus de savoir si elles doivent construire un moteur, mais où investir le temps qu'un moteur gratuit permet d'économiser. Les bénéficiaires du travail open source, qui relève du bien public, apparaissent dans les feuilles de route des autres entreprises.
L'histoire n'est pas terminée
La fin de partie reste indécise. Vera Rubin, MI455, LPU et d'autres matériels conçus en priorité pour l'inférence réinitialiseront la check-list, comme l'a fait chaque transition matérielle précédente. Chaque réinitialisation rouvre brièvement un espace de différenciation des moteurs grâce à de nouveaux formats numériques, de nouvelles hiérarchies mémoire et de nouveaux compromis de parallélisme. Les techniques se diffusent ensuite, et la fenêtre se referme.
De nouvelles architectures de modèles et de nouvelles charges de travail créeront des ouvertures similaires. Les agents dotés de grands contextes réutilisables, ainsi que le RL à l'échelle de la production, imposent de nouvelles contraintes. La commoditisation des moteurs est un cycle récurrent. L'intervalle entre l'invention et la diffusion se réduit, mais il n'a pas disparu.
À chaque ouverture, une équipe rapide peut encore remporter des contrats significatifs. Les avantages temporaires comptent lorsqu'ils surviennent en même temps qu'une transition matérielle ou de modèle majeure, car les revenus et les relations clients peuvent persister une fois que les concurrents ont rattrapé leur retard. Ce qui a changé, c'est le temps disponible pour reconnaître et exploiter l'ouverture.
Les moteurs et les fournisseurs doivent encore passer deux tests. Le premier est la vitesse de réaction : peuvent-ils saisir une transition tant que l'avantage est encore disponible ? Chaque génération a laissé sur le carreau des entreprises bien gérées, arrivées avec un cycle matériel de retard. Les équipes qui se sont positionnées tôt sur la désagrégation ou sur l'économie du NVFP4 de Blackwell ont engrangé des gains temporaires mais cumulatifs.
Le deuxième test est financier : peuvent-ils préserver leur marge pendant que l'ARR augmente ? Un fournisseur peut enregistrer plus de revenus et perdre plus d'argent en achetant sa croissance avec une capacité sous-tarifée. À mesure que la concurrence s'intensifie et que les marges brutes se rapprochent des réalités économiques de l'infrastructure, la discipline opérationnelle devient une condition de survie. Le taux d'utilisation du parc, les coûts de l'énergie, la prévision de la demande, la planification de la capacité et l'équilibre entre revenus engagés et revenus spot désigneront le prochain groupe de gagnants. Lever des milliards n'est que le début ; bien dépenser ces milliards est tout un art.
