Les coûts d'inférence baissent, Quail et Magnitude poussent à servir moins cher

Cette annonce tombe le jour même où un projet soutenu par Y Combinator, Magnitude, a livré un moteur d'inférence open source qui ajuste ses propres kernels sur votre matériel. Les deux défendent la même idée : le modèle n'est plus la partie chère. C'est la couche de service qui l'est.

Quail est le fruit d'un travail commun entre des chercheurs en inférence de Modal et des chercheurs en bases de données du Full Stack Data Lab de Carnegie Mellon. Le projet est décrit dans un billet du 30 septembre sur le blog de Modal et dans un texte d'accompagnement du laboratoire. Le problème qu'ils attaquent est le AI-SQL, où les requêtes SQL appellent des modèles de langue ligne par ligne. Un simple filtre demande un appel au modèle par ligne. Une jointure naïve en demande un pour chaque paire de lignes. La requête de référence du laboratoire, BIO-4, filtre 5 000 comptes rendus médicaux contre 4 144 termes d'effets indésirables, puis les joint deux fois. Leur billet estime un temps d'exécution à la vitesse de la lumière de 894,37 secondes, soit 14,91 minutes. Ce calcul part d'un modèle roofline qui suppose un débit GPU maximal, un recouvrement complet CPU et GPU et un espace KV cache illimité.

Faire tourner vLLM 0.26.0 avec Qwen3 4B FP8 sur un H100 à un facteur d'échelle de 1,0 a pris 6,84 heures, selon le laboratoire, soit 27,55 fois l'estimation idéale.

Deux causes expliquent l'écart. D'abord la surcharge de l'hôte : le CPU planifie les requêtes pendant que le GPU tourne à vide. Ensuite ce qu'ils appellent le KV regret, où vLLM jette un état clé-valeur dont il aura de nouveau besoin. Le laboratoire compte 174,6 millions de tokens gaspillés sur cette exécution.

Sur une requête à jointures multiples où la planification compte particulièrement, Quail dépasse le milliard de tokens traités par minute et par GPU H100 (TPM/GPU), soit plus de 10 fois plus vite que notre référence vLLM sur le même matériel.

Le billet de Modal attribue la victoire à la connaissance préalable de la structure de la requête. Le moteur peut ainsi ordonner les requêtes pour mieux mettre en cache et évincer l'état KV. Il a fallu pour cela réviser l'attention en cascade de type Hydragen. Sur l'ensemble du benchmark, Quail est 1,84 fois plus rapide que vLLM, en moyenne géométrique. Ce chiffre inclut deux requêtes que les auteurs ont conçues pour montrer où l'inférence AI-SQL doit encore progresser.

Magnitude mise sur votre propre silicium

Magnitude, présentée comme une société YC S25, a pris la route opposée vers le même problème de coût. Son README GitHub, mis à jour le 30 septembre, décrit un moteur qui compile et ajuste les kernels sur l'appareil de l'utilisateur avant l'exécution d'un modèle, plutôt que de livrer des kernels précompilés pour des classes de matériel. Le projet revendique jusqu'à 2 fois plus rapide que llama.cpp, avec un décodage 92 % plus rapide sur Metal et 19 % sur CUDA, plus 27 % de mémoire en moins par agent. Il tourne sur Apple Silicon, NVIDIA, AMD ou un CPU seul. Il se connecte à des agents dont Pi, OpenCode, Hermes, Codex et Claude Code en un clic, et il est sous licence Apache 2.0. Les prompts, les fichiers et les modèles restent en local, indique le README.

Les deux projets courent après la même économie.

Un indice de prix publié le 30 septembre par AICostBudget couvre 81 enregistrements publics de 11 fournisseurs. Il situe le prix médian d'entrée à 1,32 dollar par million de tokens et le prix médian de sortie à 6 dollars. La sortie coûte environ cinq fois l'entrée à la médiane. Le même instantané relève une remise médiane de 90 % sur l'entrée mise en cache sur 58 enregistrements comparables, et une remise médiane de 50 % sur le traitement par lots sur 44. C'est le détail qui compte pour quiconque fait tourner du AI-SQL. Les charges de travail qui peuvent être traitées par lots et mises en cache paient une fraction du prix catalogue. Celles qui ne le peuvent pas paient le plein tarif.

La facture arrive ailleurs

L'énergie est l'autre chiffre de la pièce.

Un article présenté à SOSP '26 le 28 septembre, signé Prasoon Sinha, Dimitrios Liakopoulos, Nathan Lemma et Neeraja J. Yadwadkar, soutient qu'optimiser les clusters GPU uniquement pour l'utilisation peut faire grimper la consommation d'énergie. Leur système, EnerTune, utilise des modèles analytiques de performance et de puissance par modèle, y compris la consommation des modèles colocalisés sur un même GPU, et un algorithme de bin-packing sensible à l'énergie. Ils rapportent une énergie de 1,4 à 2,3 fois plus faible et une puissance appelée de 1,3 à 2,6 fois plus faible que les références de l'état de l'art, tout en respectant les objectifs de performance.

Les auteurs de Quail ne prétendent pas que leur benchmark tranche quoi que ce soit. Ils indiquent que deux des requêtes ont été conçues pour montrer où l'inférence AI-SQL doit s'améliorer. Ils présentent la moyenne géométrique de 1,84 fois comme un point de départ, pas un plafond. L'idéal de 14,91 minutes du laboratoire reste un idéal : aucune implémentation ne peut satisfaire toutes ses hypothèses.

Un dernier point de données, de l'autre côté du débat sur les prix.

Un billet du 30 septembre de Gagan Kogan, revenant sur un travail chez Pinecone, décrit un test A/B. Retirer un calculateur de prix à l'usage de la page tarifaire a rendu les visiteurs 16 % plus enclins à s'inscrire et 90 % plus enclins à contacter l'entreprise, sans hausse des tickets de support sur les prix. Sept employés sur dix avaient prédit que le calculateur l'emporterait. La transparence des coûts est, elle aussi, une forme de complexité.

Pour les acheteurs, la lecture pratique est plus étroite que les gros titres. Le prix par token baisse pour les charges de travail structurées et mises en cache, et les fournisseurs publient les paliers qui le font baisser. L'infrastructure en dessous, les GPU, l'électricité et l'ordonnancement entre eux, est le terrain où le coût se joue désormais.