Liquid AI a publié LFM2.5 24B-A2B le 13 octobre. Il compte 24 milliards de paramètres et en lit environ 2.4 milliards pour chaque token qu'il écrit.

Liquid le compare à Qwen3.6 35B-A3B, le modèle derrière le point d'accès de programmation de CARouter Cloud, et le dit plus rapide et meilleur pour le travail d'agent. Nous avons mesuré les deux sur des GB10, la puce sur laquelle tourne CARouter Cloud, à 4 bits comme nous servons nos propres modèles, pour vérifier ces deux affirmations.

Le dernier modèle testé de cette façon : Kolibri-1 face à Qwen3.6 35B-A3B.

En bref

• Vitesse, sur le moteur de Liquid. Sur llama.cpp, où Liquid a mesuré ses propres chiffres, LFM2.5 écrit 105 tokens par seconde pour une requête et Qwen 65. L'affirmation de Liquid tient.
• Vitesse, sur le nôtre. Sur vLLM, le moteur avec lequel CARouter Cloud sert ses modèles, Qwen reste devant : 118 contre 96 pour une requête, 486 contre 387 avec seize à la fois.
• Réponses. LFM2.5 écrit environ 40 % de tokens de moins pour les mêmes réponses. Une réponse de programmation typique arrive en 33 secondes, contre 40, pour un utilisateur seul.
• Qualité. À égalité en programmation, 30 problèmes sur 50 chacun. Meilleur pour suivre des consignes, 95 % contre 89 %. Moins bon pour appeler des outils, 70 % contre 81 %, et sur les questions scientifiques, 73 % contre 83 %.
• Mémoire. LFM2.5 à 4 bits occupe 12.9 Gio de poids, contre 22.0 Gio pour Qwen.
• Notre décision. CARouter Cloud garde Qwen3.6 35B-A3B. LFM2.5 lit deux fois moins de contexte, ne prend pas d'images, et appelle plusieurs outils à la fois de façon moins fiable.

Deux moteurs, deux courses différentes

llama.cpp est conçu pour faire tourner un modèle sur un ordinateur, pour une personne. vLLM est conçu pour servir beaucoup de personnes à la fois depuis une machine, et c'est ce que fait tourner CARouter Cloud.

Qwen3.6 est aussi livré avec un petit assistant qui propose les quelques tokens suivants au modèle principal, qui les vérifie, ce qui le rend environ une fois et demie plus rapide sur vLLM. Liquid a annoncé un assistant de ce genre pour LFM2.5, pour un autre moteur, et ne l'a pas encore publié.

Quel LFM2.5 nous avons fait tourner

Liquid publie une version de LFM2.5 à 4 bits pour llama.cpp et une à 8 bits, en FP8, pour vLLM. Pour vLLM à 4 bits, le format dans lequel nous servons Qwen, nous avons pris deux versions produites par la communauté.

Elles nous ont appris quelque chose sur ce modèle. Deux cinquièmes des paramètres que LFM2.5 utilise pour chaque token se trouvent hors de ses experts, les réseaux spécialisés que les versions à 4 bits compressent d'habitude. Une version ne compresse que les experts et écrit 58 tokens par seconde. L'autre compresse presque tout et en écrit 96.

Même modèle, même moteur, 1.65 fois la vitesse. Compresser le reste n'a rien coûté de mesurable sur le code ou les consignes, et un peu de justesse sur les appels d'outils : 349 sur 500 contre 371. Dans la suite, LFM2.5 sur vLLM désigne la version la plus rapide, celle que nous servirions.

Mémoire

À 4 bits, les poids de LFM2.5 pèsent 9 Gio de moins que ceux de Qwen. Avec les mêmes 28 Gio réservés aux conversations, il retient 41.7 Gio en tout, contre 52.6 Gio.

Par token de conversation, les deux coûtent à peu près la même chose. LFM2.5 loge plus de conversations dans cet espace seulement parce que chacune peut être deux fois plus courte : 131 072 tokens contre 262 144.

Vitesse

Sur llama.cpp, LFM2.5 est 1.6 fois plus rapide que Qwen et lit une requête 1.74 fois plus vite. Liquid annonce 114 contre 67 tokens par seconde sur un AMD Ryzen AI Max+ 395, une machine dont la mémoire est à peu près aussi rapide que celle du GB10. Nous avons trouvé le même écart.

Sur vLLM, l'ordre s'inverse. Son assistant place Qwen de 20 % à 28 % devant, quelle que soit la charge. Sans son assistant, Qwen écrit 76 tokens par seconde seul sur cette même machine, moins que les 96 de LFM2.5.

llama.cpp partage mal une machine. Avec seize requêtes à la fois, LFM2.5 y totalise 250 tokens par seconde, contre 387 sur vLLM.

LFM2.5 lit aussi les requêtes plus vite sur vLLM : environ 9 900 tokens par seconde contre 6 500 pour Qwen. La version FP8 de Liquid a été la plus lente de toutes sur cette puce, à 54 tokens par seconde pour une requête seule.

Les tokens par seconde ne disent pas tout, car LFM2.5 écrit moins. Pour les mêmes 50 problèmes de programmation, il a écrit 173 mille tokens et Qwen 291 mille. Une réponse typique a pris 33 secondes pour un utilisateur seul sur vLLM, contre 40 pour Qwen.

Qualité

Nous utilisons les mêmes 50 problèmes BigCodeBench pour chaque modèle que nous évaluons : le modèle écrit une fonction Python, que l'on exécute ensuite contre des tests. Les deux en ont résolu 30, dont 26 identiques.

IFEval propose 541 requêtes dont les consignes peuvent être vérifiées par un programme, comme un nombre de mots ou un format imposé. LFM2.5 a suivi toutes les consignes de 95 % d'entre elles, Qwen de 89 %. L'écart est trop grand pour être dû au hasard, et c'est celui qu'annonce Liquid.

Pour les appels d'outils, c'est l'inverse. Sur 500 requêtes du banc d'essai d'appel de fonctions de Berkeley, LFM2.5 en a réussi 70 % et Qwen 81 %. Avec un appel par requête, LFM2.5 fait aussi bien. Quand une requête demande plusieurs appels à la fois, il n'en fait généralement qu'un, et il appelle plus souvent un outil quand aucun ne convient.

Sur 198 questions scientifiques de niveau universitaire avancé (GPQA Diamond), LFM2.5 a répondu juste à 73 % et Qwen à 83 %. Le tableau de Liquid montre le même écart, et Liquid recommande d'associer le modèle à une recherche sur le web pour les questions de connaissances. C'est aussi le seul test où LFM2.5 a écrit plus que Qwen.

Nous avons aussi caché une phrase, qui nomme le premier groupe à avoir joué sur la Lune, dans des documents de 16 000 à 100 000 tokens, puis nous l'avons redemandée. Qwen l'a retrouvée 12 fois sur 12, LFM2.5 9. Une fois, LFM2.5 a répondu The Beatles. Sa fenêtre s'arrête par ailleurs à 131 072 tokens, contre 262 144 pour Qwen : on ne peut pas du tout l'interroger sur des documents plus longs.

Ce que nous ne pouvons pas vous dire

• Comment LFM2.5 se comporte dans un agent. Liquid l'a entraîné dans OpenClaw, Hermes Agent, Pi et OpenCode, et nous n'avons fait tourner aucun d'eux.
• Sa vitesse avec son assistant. Liquid ne l'a pas publié.
• Ce qu'il donne dans les quinze autres langues pour lesquelles il a été entraîné. Nous n'avons testé que l'anglais.
• Si un écart de quelques points sur nos plus petits tests est réel. Cinquante problèmes de programmation ne suffisent pas à classer deux modèles aussi proches.

Ce que cela change pour CARouter

Le GB10 de CARouter Cloud garde Qwen3.6 35B-A3B. Sur le moteur qui sert nos clients, LFM2.5 écrit moins vite mais écrit moins, programme aussi bien et suit mieux les consignes. Il lit aussi deux fois moins de contexte, ne prend pas d'images, appelle plusieurs outils à la fois de façon moins fiable, et sa licence n'autorise l'usage commercial qu'aux entreprises de moins de 10 millions de dollars américains de chiffre d'affaires annuel.

Liquid l'a conçu pour une personne sur une machine, et là il fait ce que Liquid annonce : 105 tokens par seconde sur un GB10 avec llama.cpp, 1.6 fois Qwen.

CARouter Cloud sert Qwen3.6 35B-A3B sur deux cartes graphiques Intel Arc Pro B60 à Ottawa, à côté de son GB10. Les mêmes cartes écrivent maintenant jusqu'à 79 % de tokens de plus par seconde pour chaque requête.

Le matériel, le modèle et sa forme à 4 bits n'ont pas changé. Le temps se perdait sur le processeur du serveur, pas sur les cartes.

L'article qui a présenté ce serveur : Qwen3.6 35B-A3B sur deux cartes Intel Arc Pro B60.

En bref

• Ce que voit un client. Avec deux requêtes sur une carte, chacune reçoit 64 tokens par seconde au lieu de 36. Avec quatre, 55 au lieu de 35. Avec huit, 44 au lieu de 35. Seule, 72 au lieu de 60.
• Ce que nous avons changé. Le moteur enregistre maintenant le calcul du modèle une fois et le rejoue. Avant, il faisait passer chaque étape par Python.
• Ce qui faisait obstacle. Deux appels de journalisation dans la version de vLLM d'Intel. Nous les retirons quand nous construisons notre propre image.
• Comment nous l'avons testé. 450 prompts dans les deux modes, un appel d'outil, une question de raisonnement, et des prompts de 29 000 et 101 000 tokens.
• Ce que ça coûte. Un premier démarrage plus long, et environ 6 % de place en moins pour les prompts que le moteur garde en mémoire.

Où passe le temps d'une requête

Nos moteurs comptent ce qu'ils font. Écrire la réponse représente environ neuf dixièmes du temps d'une requête, et une carte écrit le plus souvent pour environ deux requêtes à la fois.

C'est là que ce serveur était le plus faible. Une requête seule recevait 60 tokens par seconde. De deux à huit requêtes sur une carte, chacune en recevait environ 35.

La carte attendait Python

Notre premier article sur ce serveur notait qu'un seul fil d'exécution du processeur donne la cadence à chaque moteur. Cette fois, nous avons regardé ce que fait ce fil.

Environ 70 % de chaque étape allaient à l'interpréteur Python et à l'intendance propre à PyTorch, sur ce seul fil. Environ un quart servait à confier le travail à la carte. La carte elle-même avait du temps libre.

Cela explique ce 35 qui ne bougeait pas. L'essentiel du coût d'une étape était fixe, quel que soit le nombre de requêtes.

Enregistrer une fois, puis rejouer

vLLM peut enregistrer le calcul du modèle une fois, sous forme de graphe, et le rejouer à chaque étape. Rejouer évite l'essentiel du travail de Python.

La version de vLLM d'Intel est livrée avec ce mode désactivé, et pour ce modèle il ne démarrait pas. La cause était petite : deux appels de journalisation se trouvent dans du code que le compilateur de PyTorch doit suivre, et le compilateur s'arrête dessus.

Nous retirons ces deux appels quand nous construisons notre propre image. Le problème, tel qu'il a été signalé à Intel.

Ce que nous avons mesuré

Même carte, même jour, dans les deux modes, pendant que l'autre carte servait des clients.

Avec deux requêtes sur une carte, chacune reçoit 64 tokens par seconde au lieu de 36, soit 79 % de plus. Avec quatre, c'est 55 au lieu de 35, et avec huit 44 au lieu de 35. Une requête seule reçoit 72 au lieu de 60.

Au total, une carte écrit 129 tokens par seconde avec deux requêtes au lieu de 72, et 349 avec huit au lieu de 282. La lecture d'un prompt est aussi rapide qu'avant, environ 5 900 tokens par seconde.

L'assistant intégré au modèle, qui n'était pas payant sur ce serveur, l'est maintenant pour une ou deux requêtes : 111 et 88 tokens par seconde chacune. À partir de quatre requêtes, il est plus lent que sans lui, donc il reste désactivé.

Ce que nous avons vérifié avant de le servir

Intel décrit ce mode comme pas encore pris en charge dans cette version. Nous n'avons donc pas cru la vitesse sur parole.

Nous avons envoyé 450 prompts différents aux deux modes et compté les réponses qui contiennent une longue suite d'un même caractère répété, un signe connu de défaut. Il y en avait 3 dans chaque mode, toutes des traits de tableau.

Un appel d'outil, une question de raisonnement, et un fait caché dans des prompts de 29 000 et 101 000 tokens sont revenus justes dans les deux modes. Un échantillon de cette taille montrerait un défaut fréquent, pas un défaut rare.

Nous avons ensuite basculé une carte à la fois, après avoir déplacé son trafic vers l'autre carte.

Ce que ça coûte

Le moteur met environ deux fois plus de temps à démarrer la première fois, parce qu'il prépare les graphes, et il les garde pour le démarrage suivant.

Il laisse aussi environ 6 % de place en moins pour les prompts qu'il garde en mémoire.

Sur une petite carte, la première chose à mesurer est le processeur qui se trouve à côté.

CARouter Cloud sert Qwen3.6 35B-A3B sur son propre matériel, au Canada. Nous le servons à 4 bits, une forme compressée d'environ 20 Gio qui tient sur une carte graphique de 24 Go.

En pleine précision, le même modèle pèse 67 Gio. AirLLM est une bibliothèque libre qui dit faire tourner un tel modèle sur une petite carte, sans le compresser.

Nous l'avons vérifié sur ce modèle. Tourne-t-il dans 24 Go, avec les images, la vidéo et toute la fenêtre du modèle, et à quelle vitesse ?

L'article précédent : ce modèle servi à 4 bits sur deux cartes Intel Arc Pro B60.

En bref

• Le résultat. AirLLM fait tourner le modèle en pleine précision dans moins de 3 Gio d'une carte de 24 Go. Le texte, les images et la vidéo fonctionnent, et les réponses sont celles qu'écrit notre moteur de service.
• Le prix. Un token toutes les 10 secondes sur un GB10 limité à 24 Go, et un toutes les 68 secondes sur une Intel Arc Pro B60. Une réponse de 500 tokens prend 1 heure 25 minutes, ou 9 heures 27 minutes.
• Par rapport au service. Servi à 4 bits, le modèle écrit 74.9 tokens par seconde sur notre GB10 et de 59 à 62 sur une Arc Pro B60. AirLLM est environ 760 et 4 100 fois plus lent.
• La fenêtre. Tel qu'il est livré, AirLLM lit un prompt d'environ 78 000 tokens dans 24 Go, sur les 262 144 que le modèle accepte. Avec une courte boucle de notre cru autour de lui, un prompt qui remplit presque la fenêtre est lu, en 15 minutes sur le GB10 et en 47 sur l'Arc Pro B60.
• Notre lecture. C'est un moyen d'obtenir une réponse de référence du modèle complet sur une petite carte. Ce n'est pas un moyen de servir.

Comment un modèle de 67 Gio passe par une petite carte

Un modèle est un empilement de couches, 40 pour celui-ci, et chaque token se calcule en les traversant dans l'ordre. Un moteur de service comme vLLM garde toutes les couches sur la carte graphique : la carte doit donc être aussi grande que le modèle.

AirLLM garde le modèle sur le disque, un fichier par couche. Pour chaque token, il copie une couche sur la carte, l'exécute, la libère, puis passe à la suivante.

La carte ne contient jamais plus qu'une couche et le travail en cours. En échange, chaque token fait passer tout le modèle, 65 Gio, par la carte.

Ce que nous avons fait tourner

AirLLM 4.0.0 sur les fichiers en pleine précision de Qwen3.6 35B-A3B publiés par Qwen, une requête à la fois, sur deux machines.

La première est un GB10 loué, la puce de notre propre machine, avec 128 Go de mémoire partagée entre le processeur et le graphique. Nous avons limité le logiciel à 24 Gio de mémoire graphique : il se comporte comme une carte de 24 Go dans une machine qui a beaucoup de mémoire.

La seconde est une vraie carte de 24 Go : une Intel Arc Pro B60 dans le serveur de l'article précédent, qui a 32 Go de mémoire. Son autre carte a continué de servir des clients pendant l'essai.

L'exemple en une ligne d'AirLLM n'a pas chargé ce modèle, absent de sa liste. Sa propre classe pour un modèle voisin, Qwen3.8 27B, désignée à la main, l'a chargé. Nous n'avons rien changé dans AirLLM.

Il tient, et il répond comme notre moteur

Un prompt court, une image et un court extrait vidéo ont chacun culminé sous 3 Gio de mémoire graphique. Le pilote de l'Arc Pro B60 a compté de 3.5 à 4 Gio utilisés, sur 24.

Nous avons envoyé les mêmes prompts à vLLM, chargé des mêmes fichiers en pleine précision. Les 24 tokens de texte, la phrase sur l'image et la réponse sur l'extrait étaient identiques, au caractère près.

Un token toutes les 10 secondes, ou toutes les 68

Sur le GB10 limité à 24 Go, AirLLM écrit un token toutes les 10 secondes. Une réponse de 500 tokens, environ une page, prend 1 heure 25 minutes. Notre GB10 sert le modèle à 4 bits à 74.9 tokens par seconde : la même réponse en 7 secondes.

Sur l'Arc Pro B60, un token prend 68 secondes et la réponse 9 heures 27 minutes. La même carte sert le modèle à 4 bits à 59 à 62 tokens par seconde.

Ce n'est pas la pleine précision qui coûte le plus. vLLM, avec les mêmes fichiers en pleine précision sur un GB10 qui utilise toute sa mémoire, écrit 29.6 tokens par seconde : la réponse en 17 secondes.

Presque tout le temps passe à déplacer le modèle. Sur les 10 secondes du GB10, 5.7 amènent la couche suivante sur la carte, 4.1 libèrent la précédente, et 0.3 sert au calcul.

Les deux machines diffèrent par l'endroit où se trouvent les fichiers. La mémoire du GB10 contient leurs 65 Gio : une couche se copie depuis la mémoire. Le serveur de la B60 a 32 Go : chaque token relit tout le modèle sur le disque, à environ 1.1 Go par seconde.

La fenêtre : 78 000 tokens tel que livré, toute la fenêtre par morceaux

Le modèle accepte jusqu'à 262 144 tokens à la fois : c'est sa fenêtre. AirLLM donne tout le prompt au modèle en un seul passage, et la mémoire utilisée grandit avec le prompt, d'environ 0.2 Gio par millier de tokens.

Dans 24 Gio, un prompt de 77 923 tokens est passé, et un de 93 938 non. Un composant optionnel que le code d'AirLLM mentionne, flash-linear-attention, a repoussé la limite : 126 007 tokens sont passés, 198 087 non.

Sur l'Arc Pro B60, un prompt de 30 094 tokens est passé en un seul passage. Un de 61 908 tokens a rempli la carte, et nous avons arrêté cet essai.

Nous avons ensuite écrit une courte boucle autour d'AirLLM. Elle donne le prompt au modèle 8 192 tokens à la fois et conserve, entre deux passages, ce que le modèle retient de ce qu'il a lu.

Avec elle, un prompt de 260 199 tokens, presque toute la fenêtre, a été lu en 15 minutes dans 19.2 Gio sur le GB10, et un fait placé à son début a été retrouvé.

Sur l'Arc Pro B60, le même prompt a été lu en 47 minutes, avec 16.3 Gio de la carte utilisés au maximum, et le fait a été retrouvé là aussi.

Chaque morceau est un passage complet sur le modèle. vLLM lit le même prompt en une minute environ.

Le mode 4 bits d'AirLLM

AirLLM a son propre mode de compression, à 4 bits, annoncé comme jusqu'à trois fois plus rapide.

Tel que livré, il n'a pas démarré sur ce modèle. Sa vérification de l'espace disque libre a demandé 238 Go pour un modèle de 67 Gio, et l'option qui saute cette vérification s'est arrêtée sur son premier fichier.

Une fois cette vérification contournée à la main, il a tourné sur le GB10 à un token toutes les 129 secondes : 13 fois plus lent que sans compression.

Nous ne voyons qu'un seul usage à AirLLM : vérifier ce que répond un modèle en pleine précision à un prompt donné, sur une machine qui ne peut pas le contenir.

CARouter Cloud sert des modèles ouverts sur son propre matériel, au Canada. Sa première machine repose sur un GB10 de NVIDIA, avec 128 Go de mémoire unifiée.

Nous avons mis à l'essai une deuxième sorte de machine, à Ottawa : un serveur équipé de deux cartes graphiques Intel Arc Pro B60 de 24 Go chacune. Nous y avons fait tourner le modèle que sert le GB10, Qwen3.6 35B-A3B, à 4 bits.

L'article précédent : ce modèle et son assistant intégré sur le GB10.

En bref

• Le résultat. Avec 16 requêtes sur chaque carte, les deux cartes écrivent 818 tokens par seconde au total.
• À charge égale. Avec 16 requêtes en tout, elles écrivent 558 tokens par seconde, soit environ 35 par requête. Le GB10 en écrit 342, ou 479 avec l'assistant intégré au modèle.
• Une requête seule. Le GB10 garde l'avantage : 74.9 tokens par seconde, ou 114.9 avec l'assistant, contre 59 à 62 sur une B60.
• Deux cartes en une seule réserve. Le noyau Linux le refuse sur cette génération de processeurs. Une fois cette seule vérification levée pour un test, la réserve commune a fonctionné, plus lentement qu'une seule carte, et elle a demandé une seconde fois la taille du modèle dans la mémoire du serveur.
• Le processeur. Un seul fil d'exécution du processeur donne la cadence à chaque moteur. Des cœurs plus rapides devraient accélérer une requête seule, mais nous ne l'avons pas mesuré.
• Et ensuite. Ce serveur rejoindra nos serveurs chez CARouter Cloud.

Trois moteurs sur une carte

Un moteur est le logiciel qui charge un modèle et répond aux requêtes. Nous en avons essayé trois sur une carte : llama.cpp avec son backend SYCL (son backend Vulkan était 2.8 fois plus lent), la version de vLLM publiée par Intel (llm-scaler) et OpenVINO Model Server.

Une requête seule reçoit de 67 à 70 tokens par seconde avec llama.cpp, de 59 à 62 avec le vLLM d'Intel et 53 avec OpenVINO. Le GB10 en donne 74.9, ou 114.9 avec l'assistant du modèle, qui rédige les prochains tokens pour que le modèle les vérifie.

Ici, cet assistant n'a pas été payant. Avec le vLLM d'Intel, il a fait gagner 6 % à une requête seule et a plafonné le total entre 135 et 180 tokens par seconde.

Quand les requêtes arrivent nombreuses, le classement change. llama.cpp ne les traite pas par lots : deux requêtes dans un même serveur avancent moins vite, au total, qu'une seule. Le vLLM d'Intel écrit 300 tokens par seconde au total avec 8 requêtes et environ 410 à partir de 16, OpenVINO 212 et 256.

llama.cpp accepte une requête allant jusqu'à 262 144 tokens, soit toute la fenêtre du modèle, mais une seule à la fois. Le vLLM d'Intel partage sa fenêtre entre les requêtes en cours, et avec le modèle entier chargé il lui reste de la place pour environ 95 000 tokens. C'est la mémoire qui est comptée : sur les 23.9 Gio de chaque carte, les poids à 4 bits en occupent 19.2.

Nous avons poursuivi avec le vLLM d'Intel : c'est lui qui abat le plus de travail quand les requêtes sont nombreuses.

Deux cartes, un moteur chacune

Nous avons lancé un moteur vLLM sur chaque carte et mesuré les deux au même instant. Chaque carte donne autant que lorsqu'elle travaille seule : 409 tokens par seconde avec 16 requêtes, donc 818 en tout et environ 26 par requête.

Avec 8 requêtes par carte, le total est de 558, soit environ 35 par requête. Le GB10 en écrit 342 au total avec 16 requêtes, ou 479 avec son assistant, c'est-à-dire 21 et 30 par requête.

Cette machine n'est donc pas plus rapide que le GB10 pour une requête seule. Elle ajoute de la capacité : quand les requêtes sont nombreuses, elle abat plus de travail au total, et chaque requête reçoit encore environ 35 tokens par seconde.

Ce que permet cette génération de processeurs

Le serveur repose sur une plateforme de 2018 : un Intel Core i9-9900K, processeur de 9e génération à 8 cœurs et 16 fils d'exécution, sur une carte mère ASUS PRIME Z390-A, avec 32 Go de mémoire. Il fonctionne sous Ubuntu 24.04, avec le noyau Linux 7.0.

Le vLLM d'Intel sait répartir un modèle sur deux cartes, qui doivent pour cela s'échanger de la mémoire directement (DMA pair à pair). Entre deux cartes branchées sur des ports racine distincts, comme ici, le noyau Linux ne l'autorise que si le pont hôte de la plateforme figure sur sa liste de ponts reconnus fiables.

Le pont hôte de cette génération de processeurs n'y figure pas, dans le noyau 7.0 comme dans la branche principale la plus récente que nous avons lue. Les plateformes AMD Zen et les plateformes Xeon y figurent. Avec un noyau standard, deux cartes font donc ici deux moteurs de 24 Go chacun, et non une seule réserve commune de 48 Go.

La B60 est une carte PCIe 5.0 à 8 voies, et sur cette carte mère chaque carte se connecte en PCIe 3.0. Cela n'a pas limité la vitesse de génération dans nos essais. Cela compterait pour le chargement du modèle et pour tout échange entre des cartes mises en commun.

Un seul fil d'exécution du processeur donne la cadence à chaque moteur. De 1 à 16 requêtes simultanées, chaque moteur vLLM a occupé pleinement un fil, et un seul, tandis que les 16 fils n'étaient occupés qu'à 13 % dans l'ensemble. Huit cœurs ont suffi pour deux moteurs.

De 2 à 8 requêtes simultanées, chaque requête garde la même vitesse, environ 35 à 38 tokens par seconde. C'est la signature d'un coût fixe par étape du côté de l'hôte, et non d'un travail de la carte, qui ne sature que vers 16 requêtes.

Réunir quand même les deux cartes, à titre de test

Pour savoir si la carte mère elle-même était l'obstacle, nous avons levé cette seule vérification. Un petit module de noyau, destiné uniquement au test, a fait accepter au noyau le pont hôte de ce serveur. Ce n'est pas un noyau recompilé, il exige de désactiver Secure Boot, et un redémarrage le retire.

La réserve commune a alors fonctionné. Un petit modèle, Qwen3-0.6B, réparti sur les deux cartes a donné 6 réponses sur 6 identiques à celles d'une seule carte et a passé un banc d'essai, sans aucune erreur dans le journal du noyau. Le matériel achemine bien le trafic.

Elle était plus lente qu'une seule carte, avec le même modèle et les mêmes réglages :

• Une requête seule : 36.8 tokens par seconde en réserve commune, contre 44.2 sur une carte.
• Huit requêtes à la fois : 298.8 au total, contre 356.6.
• Lecture d'un prompt de 12 000 tokens : 16 555 tokens par seconde, contre 25 793.

La vraie limite est la mémoire du serveur. Tout ce que les deux cartes partagent, les poids comme le cache, y occupe aussi sa taille, et l'espace d'échange ne l'absorbe pas. Un modèle de 29 Go a épuisé les 32 Go de cette machine pendant son chargement.

Nous n'avons pas réuni les cartes pour Qwen3.6 35B-A3B lui-même.

Ce qu'une plateforme plus récente apporterait probablement

Rien de ce qui suit n'est mesuré. C'est ce que les chiffres ci-dessus nous laissent attendre.

• Un processeur plus récent, aux cœurs plus rapides, devrait augmenter la vitesse d'une requête seule et des petits lots.
• Une plateforme inscrite sur la liste du noyau réunirait les deux cartes sans module de test.
• Davantage de mémoire permettrait à la réserve commune d'accueillir un grand modèle : à peu près autant, en plus, que ce que les deux cartes partagent.
• Des emplacements PCIe 5.0 relieraient les cartes à la vitesse qu'elles acceptent, ce qui devrait aider le chargement et le trafic entre cartes réunies.

Longs prompts et images

Le vLLM d'Intel lit un prompt de 12 000 tokens à environ 5 900 tokens par seconde, contre environ 6 400 pour le GB10 et de 590 à 700 pour llama.cpp.

La lecture ralentit à mesure que le prompt s'allonge. Sur une carte, une requête seule reçoit sa réponse en 2.9 secondes pour un prompt de 11 400 tokens, en 18.6 secondes pour 55 216 tokens, en 39.2 secondes pour 87 923 tokens et en 78.8 secondes pour 132 606 tokens.

Les images fonctionnent avec le vLLM d'Intel : une image de 1024 sur 1024 représente environ 1 050 tokens et prend moins d'une seconde.

Chargés sans la partie du modèle qui lit les images, les poids occupent 18.4 Gio au lieu de 19.2. Cela laisse tout juste la place, sur une carte, pour toute la fenêtre du modèle, soit 262 144 tokens.

Chaleur : testez avec beaucoup de requêtes

La deuxième carte est arrivée avec un ventilateur qui ne tournait pas, et elle a atteint de 93 à 96 °C en charge. Une requête seule gardait sa vitesse : 62.4 tokens par seconde, contre 61.5 une fois le ventilateur réparé. Avec 8 requêtes, le total tombait de 298.8 à 98.2.

Une fois le ventilateur réparé, les cartes culminent entre 68 et 74 °C environ lorsque les deux sont à pleine charge. Un problème thermique ne se voit pas avec une seule requête : testez avec beaucoup.

Et ensuite

Ce serveur rejoindra nos serveurs chez CARouter Cloud.

Le projet vLLM Semantic Router a publié deux familles de modèles de décision ouverts : Decision 2.0, puis Vela 2.0 cette semaine. Comme Jev et Kev, ils répondent à des questions typées sur un texte.

Nous en avons passé trois sur nos deux benchmarks à côté de Kev, sur un GB10 de NVIDIA, la machine qui sert Kev-4B à l'adresse /v1/decisions. Ce sont Decision 2.0 Nox-4B, Vela 2.0 4B et Vela 2.0 0.3B, assez petit pour se passer de GPU.

C'est le cinquième article de la série. Son tableau réunit tous les modèles de décision que nous avons testés jusqu'ici, et ses dernières sections disent à quoi chacun peut servir.

Lire le premier benchmark. Lire le deuxième, paru avec le lancement de Kev. Lire le troisième, sur OpenJev. Lire le quatrième, sur Clef et Strands Decider.

En bref

• Sur nos requêtes. Vela 2.0 4B a reconnu le bon type de tâche sur 96,6 % de nos 328 requêtes, contre 93,0 % pour Decision 2.0 Nox-4B et 92,4 % pour Kev-4B. C'est le plus juste des modèles entraînés que nous avons testés, à une requête du Qwen3.5-4B d'OpenJev, qui n'a reçu aucun entraînement.
• Là où Vela prend l'avantage. Il a reconnu toutes les conversations courantes et 29 des 32 étapes d'agent. Or CARouter reconnaît une étape d'agent à la requête elle-même. Notés de cette façon, Vela 2.0 4B est à 97,6 % et Kev-4B à 97,3 % : une seule requête les sépare.
• Sans GPU. Sur un processeur seul, Vela 2.0 0.3B atteint 85,7 %, devant les 80,2 % de Kev-0.8B sur un GPU. Une décision courte y prend 92 millisecondes.
• Sur les requêtes publiques. Vela 2.0 4B atteint 80 % en anglais et 76 % en français, Nox-4B 79 % et 78 %. Kev-4B est à 76 % et 70 %.
• L'assurance. Sur les requêtes publiques en anglais, Nox-4B ne s'est trompé en étant sûr de lui à 90 % ou plus que sur 0,7 % des requêtes, contre 3 % pour Kev-4B et 7 % pour Vela 2.0 4B.
• Vitesse. Pour une requête courte, une décision à trois questions prend 99 millisecondes avec Kev-4B, 194 avec Nox-4B et 319 avec Vela 2.0 4B.
• Mémoire. Vela 2.0 4B occupe 23 des 121 Go du GB10, Kev-4B 14 et Nox-4B 11. Le 0.3B occupe 1,5 Go sur le GPU.

Qui sont les nouveaux venus

Decision 2.0 est une famille de six modèles, de 0,6 à 27 milliards de paramètres. Nous avons testé son modèle 4B, Nox, publié sous licence Apache 2.0. Il est affiné à partir de Qwen3.5-4B-Base, la base de Kev-4B, et répond aux trois mêmes types de questions que Jev : un choix, un oui ou non, une note. Les poids de Nox-4B.

Les grands modèles de Vela 2.0 partent de Decision 2.0. Ils sont entraînés à ce qu'un routeur doit savoir d'une requête avant de l'envoyer où que ce soit : son sujet, si c'est une attaque, si elle contient des renseignements personnels, si une réponse s'appuie bien sur ses sources. L'annonce. Les poids de Vela 2.0 4B.

Vela 2.0 ajoute deux types de réponses. Une question d'ensemble renvoie toutes les étiquettes qui s'appliquent. Une question de repérage renvoie les mots exacts trouvés, avec leur position dans le texte.

Vela 2.0 0.3B est construit autrement. C'est un encodeur de 0,3 milliard de paramètres, le genre de modèle qui lit un texte sans pouvoir en écrire, et il tourne sur un processeur. Ses poids sont sous licence Apache 2.0, mais son tokenizer reste soumis aux conditions d'utilisation de Gemma, de Google.

Leurs auteurs le disent : cette spécialisation a un prix. Sur le Jev Decision Index, une série publique de tâches de décision générales, les fiches annoncent environ 32 pour Vela 2.0 4B et environ 44 pour le Nox-4B dont il est issu. Nous nous attendions à ce que Vela comprenne nos requêtes moins bien que Nox. C'est le contraire qui s'est produit.

Les deux modèles 4B lisent jusqu'à 16 384 tokens, et le 0.3B 8 192, questions comprises. Decision 2.0 refuse une requête trop longue ; Vela 2.0 la coupe. Aucune de nos requêtes de test n'a atteint ces limites.

Comment nous avons testé

La machine de test est un GB10, le même modèle que celle qui sert Kev, avec 121 Go de mémoire que se partagent le processeur et le GPU. Chaque modèle y a tourné seul, une requête à la fois, avec le code de ses auteurs. Kev a tourné comme notre serveur le fait tourner.

Les deux benchmarks sont ceux des articles précédents. Sur les 1 020 requêtes publiques, chaque modèle répond à une seule question, avec neuf types de tâche. Sur nos 328 requêtes, il répond à trois questions : le type de tâche, sa difficulté, et si la réponse sera longue.

Un seul script a noté tous les modèles : celui de l'article précédent. Avant de noter quoi que ce soit de nouveau, il recalcule les chiffres publiés dans les articles précédents, et s'arrête si un seul diffère.

Les modèles des articles précédents gardent les chiffres que nous avons publiés. Kev-4B a tourné de nouveau sur cette machine de test, comme référence. Il a choisi la même réponse que la dernière fois pour 1 016 des 1 020 requêtes publiques et pour 325 de nos 328 requêtes, et ses temps sont à moins de 2 % de ceux du dernier article.

Sur l'exemple de leur propre fiche, les deux modèles Vela ont donné les réponses qui y sont publiées, à 0,001 près. Decision 2.0 ne publie aucune réponse à laquelle se comparer. Avant de se charger, il vérifie chacun de ses fichiers par rapport à un manifeste, et sa réponse à l'exemple de sa fiche est sensée.

Le 0.3B a tourné de trois façons : sur le GPU, puis sur le processeur seul avec deux moteurs d'inférence. Les trois ont choisi la même réponse pour chaque requête : sa justesse tient donc en une ligne, et sa vitesse en deux.

Jev est un service hébergé payant, que nous n'avons pas rappelé. Ses chiffres sur les requêtes publiques sont ceux du premier benchmark, et il n'a jamais été passé sur nos requêtes.

Ce que nous avons trouvé : la justesse

Vela 2.0 4B obtient 317 bonnes réponses sur nos 328 requêtes. Le Qwen3.5-4B d'OpenJev en obtient 318, Clef 310, Nox-4B 305 et Kev-4B 303.

Nous avons rédigé les questions posées sur nos requêtes avec les réponses de Kev-4B sous les yeux, sur les trois cinquièmes des requêtes. Sur les 137 requêtes mises de côté, Vela 2.0 4B n'en manque qu'une : 99,3 %, contre 98,5 % pour OpenJev, 94,9 % pour Nox-4B et 93,4 % pour Kev-4B.

Sur les requêtes publiques, les nouveaux venus rejoignent les meilleurs des modèles déjà testés. Vela 2.0 4B atteint 80 % en anglais et Nox-4B 79 %, autour des 81 % de Jev, le service hébergé, et devant Kev-4B, à 76 %.

Le français n'y coûte qu'un point à Nox-4B : 78 % au lieu de 79 %. C'est le plus faible recul de tous les modèles entraînés du tableau. Vela 2.0 4B perd cinq points, comme Jev, et Kev-4B six.

Vela 2.0 0.3B obtient 281 bonnes réponses sur nos requêtes, soit 85,7 %. C'est 18 de plus que Kev-0.8B et 5 de moins que Strands Decider, deux modèles qui ont besoin d'un GPU. Sur les requêtes publiques, il fait jeu égal avec Kev-0.8B : 71 % en anglais et 64 % en français.

D'où viennent les écarts

Vela 2.0 4B fait un sans-faute sur sept des neuf types. Il a reconnu les 30 conversations courantes, quand Nox-4B en reconnaît 28 et Kev-4B 26.

C'est sur les étapes d'agent qu'il creuse l'écart. Il en a reconnu 29 sur 32, contre 20 pour Nox-4B et 16 pour Kev-4B. Le dernier message d'une étape d'agent est le résultat d'un outil, qui ressemble à du code ou à une page web.

C'est aussi le seul type que CARouter ne demande pas à un modèle. Une requête qui contient des définitions d'outils est une étape d'agent, et notre plateforme le voit comme elle voit la langue. Notés de cette façon, Vela 2.0 4B reconnaît 97,6 % des requêtes, Kev-4B 97,3 % et Nox-4B 96,6 %.

La recherche est le seul type où Kev-4B devance les nouveaux venus : 23 sur 28, contre 21 pour Nox-4B et 20 pour Vela 2.0 4B. Le 0.3B n'en reconnaît que 6, et range 14 des autres dans la conversation.

Ce que nous avons trouvé : l'assurance

Un modèle qui décide à la place de quelqu'un ne devrait agir que lorsqu'il est sûr de lui. Nous comptons donc les réponses fausses que chacun donne avec au moins 90 % d'assurance.

Sur les requêtes publiques, Nox-4B se trompe avec assurance sur 0,7 % des requêtes en anglais, et sur aucune en français. Vela 2.0 4B est à 7 %, entre Kev-4B, à 3 %, et Clef, à 8 %.

Sur nos requêtes, Vela 2.0 4B a donné 269 réponses à ce niveau d'assurance, dont deux fausses. Le 0.3B en a donné 172, Kev-4B 187 et Nox-4B 59, sans aucune erreur.

Chaque modèle calcule son assurance à sa façon, et celle de Decision 2.0 est la plus sévère : elle baisse dès qu'une deuxième option reçoit un peu de probabilité. Recalculée avec la formule de Kev, l'assurance de Nox-4B atteint ce niveau pour 144 réponses, et ses erreurs assurées sur les requêtes publiques en anglais passent de 0,7 % à 5 %.

Difficulté et réponses longues

Les deux nouveaux modèles 4B évaluent mieux la difficulté que Kev-4B. Nox-4B place une requête à un niveau près du nôtre 94 % du temps et Vela 2.0 4B 92 %, contre 88 % pour Kev-4B et 81 % pour le 0.3B. Clef reste en tête, à 98 %.

Dix de nos 328 requêtes demandent une réponse longue. Nox-4B a repéré les dix, avec cinq fausses alertes. Vela 2.0 4B en a trouvé huit, avec huit fausses alertes. Kev-4B en a trouvé sept, sans fausse alerte.

Le 0.3B ne sait pas répondre à cette question. Il n'a trouvé que quatre des dix, et a signalé 154 requêtes qui ne demandaient pas de réponse longue.

Vitesse et mémoire sur un GB10

Nous avons chronométré la décision à trois questions des articles précédents, chaque fois sur une requête nouvelle, de la requête courte à celle de 4 000 tokens.

Kev-4B reste le plus rapide des modèles 4B : 99 millisecondes pour une requête courte, 631 pour une longue. Vela 2.0 4B prend 319 millisecondes et 1,3 seconde. Nox-4B prend 194 millisecondes et 3,1 secondes.

Nox-4B est lent sur les requêtes longues parce qu'il relit la requête pour chaque question. Une option lui permet de ne la lire qu'une fois : la requête longue descend alors à 1,1 seconde, et aucune de ses réponses n'a changé sur nos deux benchmarks.

Avec une seule question, Nox-4B est le plus rapide des modèles 4B de cet article : 72 millisecondes pour une requête courte, contre 83 pour Kev-4B.

Le 0.3B joue dans une autre catégorie. Sur le GPU, il prend 11 millisecondes pour une requête courte et 243 pour une longue, dans 1,5 Go.

Sur le processeur seul, avec dix de ses vingt cœurs, il prend 92 millisecondes pour une requête courte, 581 pour une requête de 1 000 tokens et 3,9 secondes pour une de 4 000. Dans notre troisième article, le modèle le plus rapide sur le processeur d'un GB10 était Kev-0.8B : 1,3 seconde pour une requête courte, sur des cœurs partagés avec d'autres tâches.

Vela 2.0 4B occupe 23 Go, parce que le code de ses auteurs garde ses poids en nombres de 32 bits. Kev-4B occupe 14 Go et Nox-4B 11. Sur un processeur, le 0.3B occupe 4 Go de mémoire ordinaire.

Ces temps sont le meilleur cas pour chaque modèle : seul sur la machine, sans réseau entre les deux. En production, Kev-4B partage son GB10 avec d'autres modèles et répond à travers une API : la même décision y prend 143 millisecondes et 1 seconde.

À quoi sert chaque modèle

Un modèle de décision répond à une question fermée sur un texte, et dit à quel point il est sûr de lui. Après cinq articles, voici où chaque modèle du tableau trouve sa place.

• Choisir un modèle pour chaque requête. C'est ce que mesurent nos 328 requêtes. Le Qwen3.5-4B d'OpenJev, Vela 2.0 4B et Clef sont ceux qui les comprennent le mieux. Quand les étapes d'agent sont lues dans la requête, Kev-4B n'est qu'à une requête de Vela, et il répond trois fois plus vite.
• Décider dans votre propre application. Il s'agit de trier des demandes de soutien, d'acheminer un message vers la bonne équipe, de vérifier une condition avant d'agir ou d'évaluer une urgence. Kev-4B le fait aujourd'hui à l'adresse /v1/decisions. Nox-4B convient là où le français compte, ou quand l'erreur commise avec assurance est celle qui coûte cher.
• Décider sans GPU. Vela 2.0 0.3B répond sur un processeur pendant qu'un appelant attend, pourvu que la requête soit courte. Il est fiable sur les types bien tranchés, comme le code, la traduction et l'extraction, mais pas sur la recherche ni sur les réponses longues. Laya, dans notre premier article, répondait lui aussi en une fraction de seconde sur un processeur, mais ne reconnaissait le bon type de tâche que sur 58 % des requêtes publiques en anglais, contre 71 % ici.
• Décider à côté d'un grand modèle. Quand la mémoire du GPU est réservée à un modèle de langage, ce sont les petits qui comptent : le 0.3B dans 1,5 Go, Kev-0.8B et Strands Decider dans 4 Go.
• Vérifier une requête avant qu'elle parte. Vela 2.0 a été entraîné à repérer les renseignements personnels, les attaques par injection, les contenus dangereux et les affirmations non étayées, dans la même lecture que ses autres questions. Nous n'avons rien testé de cela ici. Sur CARouter, le filtre de renseignements personnels et le filtre de contenu font ce travail avec deux modèles distincts.
• Les images et la vidéo. Clef est le seul modèle de cet article qui sait les lire, et nous n'avons testé que du texte.
• Ne rien héberger. Jev est un service hébergé : il n'y a aucun modèle à servir, et chaque requête quitte votre infrastructure.

Ce que cela ne prouve pas

• Chaque modèle n'a tourné qu'une fois, sur deux ensembles de requêtes. Un type compte de 20 à 66 de nos requêtes : pour le plus petit, une seule erreur déplace le chiffre de cinq points.
• Nous avons rédigé et étiqueté les 328 requêtes, et réglé leurs questions sur Kev-4B. Les deux benchmarks ne demandent qu'une chose : de quel type de travail relève une requête. Sur des tâches de décision générales, les auteurs de Vela 2.0 le mesurent eux-mêmes sous Decision 2.0.
• Nous n'avons pas testé ce pour quoi Vela 2.0 a été conçu. Rien ici ne dit s'il repère bien les renseignements personnels, les attaques par injection ou les affirmations non étayées, en anglais comme en français.
• Les nouveaux modèles ont tourné avec le code publié par leurs auteurs. Le chemin le plus rapide de Decision 2.0 est écrit pour les GPU d'AMD et ne s'appliquait pas au GPU NVIDIA du GB10, alors que le code qui sert Kev est optimisé pour cette machine. Les écarts de temps en disent autant sur le logiciel que sur les modèles.
• Le 0.3B a été chronométré sur le processeur du GB10, une puce Arm à vingt cœurs. Un autre processeur donnera d'autres temps.
• Nous n'avons pas rappelé Jev. Ses chiffres viennent du premier benchmark, et il n'a jamais été passé sur nos requêtes.

Ce que cela change pour CARouter

Kev-4B reste derrière /v1/decisions pour l'instant. Noté comme notre plateforme lit une requête, Vela 2.0 4B ne le devance que d'une requête, pour trois fois plus d'attente et 8 Go de mémoire de plus, sur une machine qui sert d'autres modèles.

Vela 2.0 4B reste pourtant le résultat à retenir de cet article. C'est le premier modèle entraîné qui comprend nos requêtes à peu près aussi bien que le Qwen3.5-4B que personne n'a entraîné, et il pourrait répondre aux questions de routage et aux questions de sécurité en une seule lecture. Avant d'en tirer quoi que ce soit, nous devons tester nous-mêmes ce second volet, dans les deux langues.

Nox-4B devance Kev-4B de deux requêtes. Il est plus constant en français, et meilleur pour la difficulté et les réponses longues. Il est aussi deux fois plus lent sur nos trois questions, et cela ne suffit pas pour changer de modèle.

Le 0.3B remet en cause une de nos conclusions. Dans notre troisième article, nous écrivions qu'un processeur n'était pas la place de Kev ni d'OpenJev pendant qu'un appelant attend. Le 0.3B y répond en un dixième de seconde pour une requête courte : c'est un candidat partout où un déploiement n'a pas de GPU à lui consacrer.

Toutes les mesures derrière cet article sont conservées, et nous les partagerons avec quiconque le demande.

Mistral a publié Mistral Large 4 le 6 octobre. Nous l'avons comparé à GLM-5.3, le modèle phare du chinois Z.ai, sur 148 problèmes de programmation difficiles, pour voir si le meilleur modèle européen tient encore tête aux meilleurs modèles ouverts venus d'ailleurs.

Publié le même jour : l'allemand Kolibri-1 sur un GB10.

En bref

• Le score. Mistral Large 4 a résolu 56 des 148 problèmes. GLM-5.3 en a résolu 62 et son petit frère GLM-5.3-Flash 64. Un écart aussi faible peut être dû au hasard.
• L'effort. Mistral Large 4 a écrit 0,18 million de tokens pour répondre. GLM-5.3 en a écrit 3,14 millions, soit dix-sept fois plus.
• La facture. Au prix catalogue, les 148 réponses ont coûté 0,41 $ US avec Mistral Large 4, 14,58 $ US avec GLM-5.3 et 1,03 $ US avec GLM-5.3-Flash.
• Le verdict. L'Europe est toujours dans la course. Son modèle phare fait jeu égal avec celui de la Chine sur ce test, et ses réponses coûtent beaucoup moins cher.

Les trois modèles

• Mistral Large 4. Il est français, compte 1 050 milliards de paramètres et en lit 49 milliards par token. Il répond directement, sauf si on lui demande de raisonner d'abord. Nous l'avons testé des deux façons.
• GLM-5.3. C'est le modèle phare de Z.ai, avec environ 750 milliards de paramètres. Par défaut, il raisonne avant chaque réponse.
• GLM-5.3-Flash. C'est le petit frère, avec 320 milliards de paramètres dont 18 milliards lus par token, vendu environ neuf fois moins cher.

Le test

Nous avons utilisé BigCodeBench-Hard, un ensemble de 148 problèmes. Le modèle écrit une fonction Python, puis des tests vérifient cette fonction. Chaque modèle a répondu une fois à chaque problème, avec les réglages par défaut de son éditeur.

Mistral Large 4 était servi par Mistral. Les deux modèles GLM étaient servis par des hébergeurs indépendants.

Ce qui en ressort

Les modèles sont le plus souvent d'accord. Mistral Large 4 et GLM-5.3 ont obtenu le même résultat sur 126 des 148 problèmes. Mistral en a résolu 8 que GLM-5.3 a manqués, et GLM-5.3 en a résolu 14 que Mistral a manqués. Le hasard seul donne une telle répartition environ trois fois sur dix.

C'est sur l'effort qu'ils se distinguent. GLM-5.3 raisonne longuement avant de répondre, et sur certains problèmes il a déroulé les exemples à la main pendant des dizaines de milliers de tokens. Un problème type a pris 15 secondes à Mistral Large 4 et environ une minute et demie à GLM-5.3.

Le raisonnement n'a pas aidé Mistral Large 4. Il a résolu 56 problèmes dans les deux cas, et le raisonnement a coûté quatre fois plus de tokens.

GLM-5.3-Flash a fait aussi bien que GLM-5.3 pour un quatorzième du coût. Sur ce test, la taille supplémentaire du modèle phare n'a rien apporté de mesurable.

Le test est difficile pour tous. 66 des 148 problèmes ont résisté à tous les essais, et 42 ont été résolus à chaque fois.

Ce que nous ne pouvons pas vous dire

• Si un écart de six problèmes est réel. Pour trancher, il faudrait plusieurs fois plus de problèmes.
• Ce que valent ces modèles en dehors de la programmation en anglais. Nous n'avons testé ni le français, ni l'allemand, ni les images, ni les longues tâches d'agent.
• Comment les modèles GLM se comportent sur le service de Z.ai lui-même. Nous n'avons pas vérifié comment chaque hébergeur indépendant fait tourner les poids.
• Où se situerait un modèle américain. Nous n'en avons testé aucun.

L'Europe est-elle toujours dans la course ?

D'après ces résultats, oui. Le modèle phare français fait jeu égal avec celui de la Chine sur des problèmes de programmation difficiles, et il y parvient avec une fraction des tokens.

Cela compte pour nous pour une raison pratique. CARouter achemine les requêtes vers des fournisseurs canadiens, et ce sont les poids ouverts qui permettent à un fournisseur canadien d'héberger un modèle. Mistral présente Mistral Large 4 comme un modèle à poids ouverts, et ses poids n'étaient pas encore publiés au moment de ce test.

Aleph Alpha a publié Kolibri-1 le 3 octobre. C'est un modèle allemand à poids ouverts, sous licence Apache 2.0, conçu pour l'allemand et l'anglais. Il compte 78 milliards de paramètres et n'en lit qu'environ 3,5 milliards pour chaque token qu'il écrit.

C'est ce dernier chiffre qui a retenu notre attention. Qwen3.6 35B-A3B, le modèle qui répond aux requêtes de programmation sur CARouter Cloud, lit environ 3 milliards de paramètres par token sur 35 milliards. Les deux modèles fournissent un travail comparable par token, et l'un est plus de deux fois plus gros que l'autre. Nous les avons fait tourner sur le même GB10 pour voir ce que coûte cette taille et ce qu'elle rapporte.

Un article précédent : pourquoi nous servons Qwen3.6 35B-A3B.

En bref

• Mémoire. À 4 bits, les poids de Kolibri-1 occupent 42,7 Gio, contre 21,9 Gio pour Qwen. Dans la version FP8 que publie Aleph Alpha, ils occupent 73,5 Gio et le modèle retient 103 Gio sur une machine qui en compte 121,6.
• Vitesse. Une requête seule reçoit 53 tokens par seconde de Kolibri-1 et 117 de Qwen. Avec seize requêtes à la fois, les totaux sont de 290 et de 486.
• Programmation. Sur nos 50 problèmes de programmation, Kolibri-1 en a résolu de 29 à 32 selon la version, et Qwen 33. Cinquante problèmes ne suffisent pas à départager ces résultats.
• Longues conversations. Kolibri-1 les retient pour moitié moins cher : les mêmes 28 Gio contiennent 9,9 conversations de 262 144 tokens, contre 4,8 pour Qwen.
• Notre décision. Nous n'ajoutons pas Kolibri-1 à la machine de CARouter Cloud. Il lui faudrait deux fois plus de mémoire pour répondre à peu près aussi bien aux requêtes de programmation, deux fois moins vite.

Deux modèles qui lisent autant l'un que l'autre par token

Les deux modèles sont des mélanges d'experts. Chaque couche contient des centaines de petits réseaux spécialisés, et chaque token n'est confié qu'à quelques-uns. Tous doivent tenir en mémoire, mais seuls ceux qui sont choisis sont lus.

Kolibri-1 garde 384 experts par couche et en sollicite 6 par token. Qwen3.6 35B-A3B en garde 256 et en sollicite 8. Le travail par token est voisin : la vitesse devrait donc l'être aussi, et la mémoire non.

Quel Kolibri-1 nous avons testé

Aleph Alpha publie Kolibri-1 en FP8, soit 8 bits par poids. Nous servons nos propres modèles à 4 bits, et Aleph Alpha ne propose aucune version à 4 bits. Nous en avons donc retenu deux, produites par la communauté dès les premiers jours :

• La plus téléchargée, un fichier Q4_K_M au format GGUF. Elle tourne sur llama.cpp, moyennant un correctif fourni par son auteur, car llama.cpp ne connaît pas encore cette architecture.
• Une version NVFP4. Elle tourne sur vLLM, le logiciel avec lequel nous servons nos modèles, dans le même format à 4 bits que notre Qwen. C'est elle qui permet de comparer à conditions égales.

Nous avons aussi testé la version FP8 d'origine, pour distinguer ce qui tient au modèle de ce qui tient à sa compression. Chaque modèle était seul sur la machine, avec les réglages par défaut de son éditeur et le raisonnement activé.

Mémoire

À 4 bits, Kolibri-1 demande 21 Gio de plus que Qwen, et ce ne sont que des poids. Sur une machine qui sert aussi des embeddings, un modèle de reclassement et notre modèle de décision, c'est exactement la place qu'occupent ces autres modèles.

La version FP8 tient sur la machine, mais elle y tient seule. Il ne restait que 10 Gio de libres.

Sur l'autre versant de la mémoire, l'avantage va à Kolibri-1. Un modèle doit aussi retenir chaque conversation en cours, et la plupart des couches de Kolibri-1 ne regardent que les 512 derniers tokens. Avec les mêmes 28 Gio, il retient 2,59 millions de tokens de conversation, contre 1,25 million pour Qwen.

Vitesse

Qwen est de 1,6 à 2,2 fois plus rapide, quelle que soit la charge. Il le doit en partie à une fonction que Kolibri-1 n'a pas : Qwen est livré avec un petit assistant qui rédige les prochains tokens pour que le modèle principal les vérifie, ce qui lui fait gagner moitié plus de vitesse sur cette machine. Sans cet assistant, Qwen écrivait 75 tokens par seconde pour une requête seule, ce qui reste au-dessus des 53 de Kolibri-1.

Pour un utilisateur seul, une réponse type à l'un de nos problèmes de programmation prenait 37 secondes à Qwen. Le même problème en demandait environ 91 à Kolibri-1.

Pour la lecture du prompt, les deux modèles font jeu égal. Sur vLLM, l'un comme l'autre lit un prompt de 12 000 tokens à un rythme de 6 400 à 6 800 tokens par seconde.

La version GGUF, sur un autre moteur, se comporte tout autrement. Seule, c'est le Kolibri-1 le plus rapide, avec 64 tokens par seconde. Elle partage mal la machine, avec des totaux irréguliers entre deux et huit requêtes, et elle lit un prompt trois fois moins vite. Sur vLLM, passer de 8 à 4 bits a aussi accéléré Kolibri-1, jusqu'à 80 % sous charge.

Qualité

Nous soumettons les mêmes 50 problèmes de BigCodeBench à chaque modèle que nous étudions : le modèle écrit une fonction Python, puis cette fonction est exécutée contre des tests. Qwen en a résolu 33, comme sur notre propre machine en août.

Kolibri-1 en a résolu 32 dans la version Q4_K_M, 29 en NVFP4 et 31 en FP8. Les modèles s'accordent sur la plupart des problèmes : Q4_K_M et Qwen ont donné le même résultat pour 47 des 50. Sur 50 problèmes, aucun de ces écarts n'est statistiquement significatif.

Kolibri-1 réfléchit plus longtemps pour y arriver. Pour les mêmes 50 réponses, il a écrit de 1,3 à 1,7 fois plus de tokens que Qwen. Or ce sont les tokens qu'un client paie, et ce sont eux qu'il attend.

Nous avons aussi caché une phrase dans des documents allant jusqu'à 220 000 tokens, puis demandé au modèle de la retrouver. Chaque modèle y est parvenu chaque fois qu'il est allé au bout de sa réponse. Quatre fois sur quarante-huit, un modèle a épuisé en raisonnement tout le budget alloué à la réponse : Qwen une fois, Kolibri-1 trois fois.

Les résultats publiés par Aleph Alpha vont dans le même sens. Ils placent Kolibri-1 légèrement devant Qwen3.6 35B-A3B dans une épreuve de programmation, et derrière lui dans une autre.

Ce que nous ne pouvons pas vous dire

• Ce que vaut Kolibri-1 en allemand. C'est sa première langue et son principal argument, et nous ne l'avons pas testée. Nous n'avons pas testé le français non plus.
• Si un écart de quelques problèmes est réel. Pour détecter une différence aussi faible, il en faudrait plusieurs centaines.
• Comment se comporterait une version officielle à 4 bits. Les deux que nous avons testées viennent de la communauté, sans le concours d'Aleph Alpha.
• Ce que fait Kolibri-1 au-delà de 262 144 tokens. Aleph Alpha le valide jusqu'à un million.
• Ce qu'il obtient en raisonnant davantage. Nous avons laissé l'effort de raisonnement à sa valeur par défaut, alors que les résultats publiés par Aleph Alpha utilisent le réglage le plus élevé.

Ce que cela change pour CARouter

La machine de CARouter Cloud garde Qwen3.6 35B-A3B. Pour programmer en anglais, Kolibri-1 nous a donné à peu près les mêmes réponses, avec deux fois plus de mémoire et plus de deux fois plus d'attente.

Ce verdict vaut pour une machine et pour un usage. Kolibri-1 est un modèle sous licence Apache 2.0, entraîné de zéro en Europe. Il gère les longues conversations à peu de frais, et son allemand est justement ce que nous n'avons pas mesuré. Un usage en allemand, ou un fournisseur disposant de plus de mémoire par machine, pèserait ces chiffres autrement.

Il y a cinq semaines, nous avons mis un modèle plus rapide derrière le point d'accès de code de CARouter Cloud. Il contenait une fonction d'accélération que nous n'avions pas activée. C'est fait : le même modèle, sur la même machine, au même prix, écrit environ une fois et demie plus vite. Il a suffi d'une ligne de configuration.

L'article précédent : pourquoi nous servons désormais Qwen3.6 35B-A3B plutôt que Qwen3.8 27B.

En bref

• Ce que voit un client. 115 tokens par seconde au lieu de 75. Une longue réponse de code arrive en 41 secondes au lieu de 63.
• Ce que nous avons changé. Une ligne. Elle active un petit assistant déjà présent dans le fichier du modèle, qui rédige les trois prochains tokens pour que le modèle principal les vérifie.
• Quand la machine est occupée. Avec seize requêtes à la fois, 479 tokens par seconde au total au lieu de 342.
• Ce que ça coûte. 2,3 Gio de mémoire sur 121. Aucun nouveau matériel, aucun nouveau téléchargement.
• Comment nous l'avons testé. Sur une machine identique louée, pour 1,03 dollar américain. La production a redémarré une seule fois, pendant six minutes.

Un assistant qui rédige, un modèle qui vérifie

Un modèle de langage écrit un token à la fois, un token étant un mot ou un morceau de mot. Chaque token coûte un passage complet du modèle.

Avec le décodage spéculatif, un petit assistant rédige les quelques tokens suivants et le grand modèle les vérifie tous en un seul passage. Il garde ceux avec lesquels il est d'accord et réécrit le premier qui ne lui convient pas. Le grand modèle a le dernier mot sur chaque token : l'assistant fait gagner du temps sans faire baisser la qualité.

Qwen3.6 35B-A3B est livré avec un tel assistant dans son propre fichier, appelé tête de prédiction multi-tokens. Il nous avait échappé quand nous avons évalué le modèle en août.

Ce que nous avons mesuré

Même machine, même fichier de modèle, même budget de mémoire. Nous avons mesuré, redémarré le point d'accès une fois avec l'assistant activé, puis mesuré de nouveau le même soir.

L'assistant rédige trois tokens à la fois, et environ sept sur dix sont acceptés. Chaque passage produit environ trois tokens au lieu d'un et coûte environ deux fois plus cher : cela donne une fois et demie plus vite.

Le gain est de 1,53 fois pour un utilisateur et de 1,40 fois pour seize. Dans tout ce que nous avons mesuré, il reste entre 1,35 et 1,58 fois.

Ce que cela change pour la personne qui attend

Une réponse courte arrive deux secondes plus tôt, une longue réponse de code vingt-deux secondes plus tôt. Quand huit personnes utilisent le point d'accès, chacune reçoit cette longue réponse en 99 secondes au lieu de 145.

Un agent de programmation appelle le modèle des centaines de fois pour une seule tâche. Un tiers d'attente en moins à chaque appel, cela finit par compter.

Ce que ça coûte

Le point d'accès occupe 2,3 Gio de mémoire de plus, que la machine avait en réserve. La lecture du prompt est 1 % plus lente.

Il retient aussi un peu moins de conversation à la fois : 4,8 conversations de longueur maximale au lieu de 5,5. Notre trafic est bien en dessous, et nous n'avons changé aucune limite.

Comment nous l'avons testé sans rien éteindre

Chaque redémarrage du point d'accès de code représente six minutes pendant lesquelles il ne répond à personne. Essayer chaque réglage en production en aurait demandé quatre.

Nous avons donc loué à l'heure une machine dotée de la même puce, et nous y avons fait tourner notre propre logiciel sans rien changer. Nous avons essayé l'assistant avec un, deux et trois tokens. Trois l'a emporté, et la soirée a coûté 1,03 dollar américain.

Nous avons ensuite changé une ligne en production et redémarré une seule fois. La machine louée avait prédit le résultat à quelques pour cent près.

Ce que nous ne pouvons pas vous dire

Nous n'avons pas refait le banc d'essai de programmation. Le grand modèle décide toujours de chaque token, et nous avons vérifié que la conversation, le raisonnement, les appels d'outils et les images fonctionnent encore.

Nous ne pouvons pas montrer deux réponses identiques. Même en supprimant tout hasard, ce logiciel ne se répète pas toujours, avec l'assistant ou sans lui. Nous n'avons trouvé aucune différence causée par l'assistant, et nous ne pouvons pas prouver qu'il n'y en a aucune.

Il reste une option plus rapide : une routine de calcul écrite pour cette puce. Elle a des défauts ouverts dans le logiciel dont nous dépendons, et nous ne l'utilisons donc pas.

Ce qui tourne maintenant

Qwen3.6 35B-A3B avec son assistant de prédiction, sur le même GB10, sous le même nom, qwen3.6-35b-a3b, au même prix. Le contexte, les images, les outils et le raisonnement sont inchangés.

Cette politique concerne uniquement les modèles que nous hébergeons nous-mêmes dans CARouter Cloud. Pour les modèles servis par d’autres fournisseurs, vous continuez de payer leur tarif publié, converti en dollars canadiens, auquel s’ajoute la majoration de votre forfait. Cette politique ne change pas leur tarification.

Nous voulons une méthode cohérente pour fixer les prix des modèles offerts aujourd’hui et de ceux qui s’ajouteront. Une référence de marché guide le positionnement de chaque offre, les coûts estimés nous aident à en évaluer la viabilité et des décisions explicites encadrent les tarifs de lancement pendant que la demande grandit.

Ce que nous appelons la référence de marché

La référence de marché porte sur l’hébergement des mêmes poids de modèle. Par défaut, nous partons de la moyenne des offres admissibles sur OpenRouter, convertie en dollars canadiens, puis nous ajoutons une majoration de 10 % pour une inférence opérée au Canada par une entreprise canadienne. Cette comparaison concerne l’hébergement des modèles; le routage et les services de notre plateforme sont tarifés séparément.

Pour estimer cette majoration, nous accordons le même poids aux observations tarifaires retenues chez Google Cloud, OUTSCALE, Microsoft Azure et AWS : (5 % + 20 % + 0 % + environ 15 %) / 4 = environ 10 %.

Il s’agit de notre référence fondée sur les offres retenues. Leurs garanties diffèrent, et la moyenne exclut les taxes, les abonnements de soutien distincts et les services de sécurité supplémentaires. Le zéro d’Azure concerne la majoration de base, et non le coût total d’un déploiement souverain. L’estimation pour AWS vient de la comparaison avec Francfort publiée par tecRacer en janvier 2026, après conversion des devises; nous ne l’avons pas actualisée de façon indépendante. Nous retenons 10 % comme hypothèse initiale de positionnement et réexaminons ce choix chaque trimestre.

Ces tarifs d’infrastructure et de contrôles ne supposent ni des certifications équivalentes ni un service de routage canadien équivalent. Le choix des offres change la moyenne : avec un ensemble de contrôles réglementaires de Google à 20 %, elle serait d’environ 13,75 %. Notre hypothèse de départ retient plutôt son offre régionale de résidence des données et de soutien.

Nous comparons le contexte, la performance, le cache, la disponibilité et la résidence des données. Si une offre présente déjà des garanties de souveraineté comparables, nous utilisons son tarif sans ajouter cette majoration une seconde fois.

La majoration de souveraineté fait partie du tarif de base de l’inférence CARouter Cloud. Celle de votre forfait s’ajoute séparément pour le routage, la facturation et l’exploitation de la plateforme.

Quand il n’existe pas d’offre comparable

Nous estimons un tarif de départ à partir de la capacité réservée par le modèle et du travail qu’il effectue : mémoire, débit mesuré, matériel, hébergement et électricité. Nous appliquons un objectif commun de contribution, puis nous comparons le résultat aux autres façons d’accomplir la même tâche.

Le coût par token dépend du taux d’utilisation de la capacité. Notre hypothèse initiale est de 10 %. Nous examinons aussi des scénarios à 5 % et à 20 %, en conservant les mêmes prix de vente. Ce sont des hypothèses de planification; les coûts réels par token dépendent des charges de travail et de l’utilisation mesurée.

Investir pendant que la demande grandit

Comme entreprise en démarrage, nous pouvons choisir un tarif de lancement inférieur au coût estimé d’un service viable. Nous consignons la raison, fixons une date de révision et prévoyons un budget pour la capacité dont les coûts ne sont pas encore couverts. Une machine peu utilisée ne rend pas automatiquement votre prochaine requête plus chère.

Lorsqu’un déploiement coûte trop cher, nous pouvons regrouper davantage de requêtes, réduire la mémoire réservée ou changer de matériel. Nous évaluons ces possibilités en même temps que le prix. Le service doit rester intéressant au tarif payé par les clients.

Ce que cela change sur votre facture

Nous fixons ensemble les tarifs des tokens entrants, des tokens entrants en cache et des tokens sortants. Réutiliser un prompt en cache évite de le traiter à nouveau : les tokens dont la réutilisation est confirmée bénéficient donc d’un rabais. La génération de la réponse continue de mobiliser des ressources de calcul.

L’effet dépend de votre utilisation. Les conversations et les agents qui réemploient le même contexte peuvent profiter du rabais sur le cache. Les tâches qui produisent de longues réponses avec peu de cache peuvent coûter plus cher. Avant de modifier les tarifs, nous vérifions des requêtes représentatives et l’utilisation existante.

Exemple : Qwen3.6 35B A3B

Dans notre relevé du 1er octobre 2026, nous convertissons les tarifs moyens d’OpenRouter en dollars canadiens au taux de 1,4243, puis nous appliquons la majoration de souveraineté de 10 % et arrondissons à quatre décimales. Ces tarifs illustratifs sont en dollars canadiens par million de tokens, avant la majoration du forfait.

Pour un prompt de 12 000 tokens et une réponse de 100 tokens, le coût est de 0,003049 $ CA sans cache, ou d’environ 0,001554 $ CA si 11 000 tokens du prompt sont confirmés en cache, avant la majoration du forfait et l’arrondi de facturation.

Nous vérifions aussi la viabilité : avec une utilisation de 10 % dans notre scénario de colocation, le coût estimé par million de tokens est de 0,0804 $ CA pour l’entrée hors cache, de 0,0031 $ pour l’entrée en cache et de 1,4897 $ pour la sortie. Ces estimations excluent les frais généraux de l’entreprise; lorsque la demande est plus faible, les coûts de capacité non couverts font partie de notre budget de lancement.

Consultez les tarifs en vigueur dans la documentation.

Des révisions trimestrielles et des changements annoncés

Tous les trois mois, nous réexaminons les références de marché, les coûts du service, la performance et la demande. Nous pouvons décider de conserver les prix. Une révision ne modifie pas automatiquement le tarif de vos requêtes.

Nous annonçons les hausses aux clients concernés avant leur entrée en vigueur, avec une date d’application et une estimation fondée sur leur utilisation. Les baisses peuvent s’appliquer immédiatement. La documentation est générée à partir du catalogue utilisé pour la facturation : c’est là que vous trouverez les tarifs applicables.

Deux nouveaux modèles de décision ouverts viennent de sortir. Cloudflare a publié Clef et son petit frère Clef-flash, et Strands Labs a publié Strands Decider. Comme Jev et Kev, tous trois répondent à des questions typées sur un texte.

Nous les avons passés sur nos deux benchmarks à côté de Kev, sur un GB10 de NVIDIA, la machine qui sert Kev-4B à l'adresse /v1/decisions. Nous avons mesuré la justesse de chacun, la fréquence de ses erreurs commises avec assurance, le temps d'une décision et la mémoire qu'il occupe.

Lire le premier benchmark. Lire le deuxième, paru avec le lancement de Kev. Lire le troisième, sur OpenJev.

En bref

• Sur nos requêtes. Clef a reconnu le bon type de tâche sur 94,5 % de nos 328 requêtes, contre 92,4 % pour Kev-4B, 89,6 % pour Clef-flash et 87,2 % pour Strands Decider.
• Là où Clef prend l'avantage. L'écart est de sept requêtes, et il vient des étapes d'agent : Clef en a reconnu 28 sur 32, Kev-4B 16. Or CARouter reconnaît une étape d'agent à la requête elle-même. Notés de cette façon, Kev-4B est à 97,3 % et Clef à 95,7 %.
• Sur les requêtes publiques. Les trois nouveaux venus atteignent de 80 à 82 % en anglais, à égalité avec Jev, le service hébergé, et devant Kev-4B, à 76 %. En français, Clef-flash arrive en tête à 78 % et Strands Decider tombe à 68 %.
• L'assurance. Sur les requêtes publiques, Clef et Clef-flash se sont trompés en étant sûrs d'eux à 90 % ou plus sur 8 % et 9 % des requêtes, contre 12 % pour Jev, 3 % pour Kev-4B et 0,2 % pour Strands Decider.
• Vitesse. Pour une requête courte, une décision à trois questions prend 101 millisecondes avec Kev-4B, 108 avec Strands Decider, 173 avec Clef-flash et 562 avec Clef.
• Mémoire. Clef occupe 52 des 121 Go du GB10, Clef-flash 18, Kev-4B 14 et Strands Decider 4.
• Le modèle que personne n'a entraîné. Le Qwen3.5-4B d'OpenJev, repassé sur la même machine, reste en tête sur nos requêtes : 97,0 %, en 192 millisecondes et 9 Go.

Qui sont les nouveaux venus

Clef est la famille de modèles de décision de Cloudflare, publiée sous licence Apache 2.0, avec ses poids sur Hugging Face. Clef repose sur Qwen3.8-27B, et Clef-flash sur Qwen3.5-9B. L'annonce de Cloudflare. Les poids de Clef.

Cloudflare a ajouté une petite tête au-dessus de chaque modèle de conversation. Elle lit la dernière couche du modèle et note en un seul passage chaque option de chaque question. Clef accepte la même requête que Jev. Il sait aussi lire des images et de la vidéo, ce que nous n'avons pas testé.

Strands Decider vient de Strands Labs, le volet expérimental du projet Strands Agents, lui aussi sous licence Apache 2.0. Il compte 1,9 milliard de paramètres : un adaptateur et une petite tête posés sur Qwen3.5-2B-Base. Kev est construit de la même façon, et cette base se situe entre celles de Kev-0.8B et de Kev-4B. Code source.

Les trois ne lisent pas la même longueur de texte. La fenêtre de Strands Decider est de 4 096 tokens, celle de Kev de 8 192 tel que nous le servons, et celle de Clef de 16 384 tel qu'il est publié. Clef et Strands Decider coupent un texte trop long et n'en gardent que le début ; notre moteur Kev, lui, refuse la requête. Aucune de nos requêtes de test n'a atteint ces limites.

Comment nous avons testé

La machine de test est un GB10, le même modèle que celle qui sert Kev, avec 121 Go de mémoire que se partagent le processeur et le GPU. Chaque modèle y a tourné seul, une requête à la fois, avec le code de ses auteurs. Kev a tourné comme notre serveur le fait tourner.

Les deux benchmarks sont ceux des articles précédents. Sur les 1 020 requêtes publiques, chaque modèle répond à une seule question, avec neuf types de tâche. Sur nos 328 requêtes, il répond à trois questions : le type de tâche, sa difficulté, et si la réponse sera longue.

Un seul script a noté tous les modèles : celui de l'article précédent. Avant de noter quoi que ce soit de nouveau, il recalcule les chiffres publiés dans les articles précédents, et s'arrête si un seul diffère.

Nous avons vérifié notre montage de trois façons. Sur l'exemple de sa propre fiche, Strands Decider a donné les réponses qui y sont publiées, à 0,004 près. OpenJev a donné la réponse publiée par ses auteurs sur ses 144 décisions de test. Enfin, sur la machine de test, Kev-4B a choisi la même réponse qu'en production pour 1 015 des 1 020 requêtes publiques et pour 327 de nos 328 requêtes.

Cloudflare ne publie pas les réponses de Clef une à une : nous n'avons donc pas pu le vérifier de la même façon. Il s'est chargé comme le décrit sa fiche, et ses réponses aux exemples de cette fiche sont sensées.

Jev est un service hébergé payant, que nous n'avons pas rappelé. Ses chiffres sur les requêtes publiques sont ceux du premier benchmark, et il n'a jamais été passé sur nos requêtes.

Une chose a changé depuis l'article sur OpenJev. Nous avons reformulé deux options de la question sur le type de tâche, la conversation et la recherche. Une étape d'agent montre aussi désormais la tâche demandée par l'utilisateur, à côté du résultat de l'outil. Tous les modèles ont répondu ici à cette nouvelle formulation.

Les chiffres de cet article sur nos requêtes répondaient à l'ancienne formulation, et ne se comparent pas à ceux-ci. Avec la nouvelle, Kev-4B est passé de 88,7 % à 92,4 %, et le Qwen3.5-4B d'OpenJev de 95,7 % à 97,0 %.

Ce que nous avons trouvé : la justesse

Sur nos requêtes, Clef est le plus juste des modèles entraînés : 310 bonnes réponses sur 328, contre 303 pour Kev-4B. Clef-flash en obtient 294, et Strands Decider 286.

Sur les requêtes publiques, l'ordre change. Clef-flash, Clef et Strands Decider atteignent 82 %, 82 % et 80 % en anglais, autour des 81 % de Jev, le service hébergé. Kev-4B reste à 76 %.

Le français les départage. Clef-flash garde 78 % et Clef 76 %, comme Jev. Strands Decider recule à 68 %, sous les 70 % de Kev-4B. Sur nos requêtes, il perd moins : 89 % en anglais et 85 % en français.

Nous avons rédigé les questions posées sur nos requêtes avec les réponses de Kev-4B sous les yeux, sur les trois cinquièmes des requêtes. Sur les 137 requêtes mises de côté, l'ordre reste le même : OpenJev 98,5 %, Clef 95,6 %, Kev-4B 93,4 %, Clef-flash 91,2 % et Strands Decider 88,3 %.

D'où viennent les écarts

Tous les modèles font un sans-faute sur le code, les mathématiques, la rédaction d'affaires et la traduction. Les écarts tiennent à trois types de requêtes : les étapes d'agent, la conversation courante et la recherche.

C'est sur les étapes d'agent que Clef prend l'avantage. Il en a reconnu 28 sur 32, quand Strands Decider en reconnaît 19, Kev-4B 16 et Clef-flash 14. Le dernier message d'une étape d'agent est le résultat d'un outil, qui ressemble à du code ou à une page web.

C'est aussi le seul type que CARouter ne demande pas à un modèle. Une requête qui contient des définitions d'outils est une étape d'agent, et notre plateforme le voit comme elle voit la langue. Notés de cette façon, Kev-4B reconnaît 97,3 % des requêtes, Clef 95,7 %, Clef-flash 95,1 % et Strands Decider 91,2 %.

En recherche, Strands Decider et Kev-4B font mieux que les deux modèles Clef : 89 % et 82 %, contre 71 % pour Clef et 50 % pour Clef-flash, qui range une requête de recherche dans l'extraction ou le résumé. Les points faibles de Strands Decider sont la conversation, à 57 %, et l'extraction, à 63 %.

Ce que nous avons trouvé : l'assurance

Un modèle qui décide à la place de quelqu'un ne devrait agir que lorsqu'il est sûr de lui. Nous comptons donc les réponses fausses que chacun donne avec au moins 90 % d'assurance.

Sur les requêtes publiques, Clef et Clef-flash se trompent avec assurance sur 8 % et 9 % des requêtes en anglais. C'est mieux que Jev, à 12 %, et moins bien que Kev-4B, à 3 %. Strands Decider ne s'est trompé avec assurance qu'une fois sur 540 requêtes.

Sur nos requêtes, presque aucun modèle ne se trompe quand il est sûr de lui. Ce qui les distingue, c'est le nombre de fois où ils le sont. Clef-flash a donné 227 réponses à ce niveau d'assurance, dont deux fausses. Clef en a donné 213, Kev-4B 187 et Strands Decider 131, sans aucune erreur.

Chaque modèle calcule son assurance à sa façon. Kev et Strands Decider la corrigent selon le nombre d'options, alors que Clef donne la probabilité de son premier choix. Recalculée avec la formule de Kev, l'assurance de Clef atteint ce niveau pour 197 réponses, et celle de Clef-flash pour 218. L'ordre ne change pas.

Difficulté et réponses longues

Clef et Clef-flash sont les meilleurs pour évaluer la difficulté. Tous deux placent une requête à un niveau près du nôtre 98 % du temps, contre 90 % pour Strands Decider et 88 % pour Kev-4B. Ils tombent sur le niveau exact 46 % du temps, contre 41 % pour Kev-4B.

Dix de nos 328 requêtes demandent une réponse longue. Clef a repéré les dix, et en a signalé deux autres à tort. Kev-4B en a repéré sept, sans fausse alerte. Clef-flash a aussi trouvé les dix, avec 13 fausses alertes. Strands Decider en a trouvé huit, avec 58 fausses alertes.

Vitesse et mémoire sur un GB10

Nous avons chronométré la décision à trois questions des articles précédents, chaque fois sur une requête nouvelle, de la requête courte à celle de 4 000 tokens.

Kev-4B est le plus rapide des grands modèles : 101 millisecondes pour une requête courte, 639 pour une longue. Strands Decider, deux fois plus petit, prend 108 et 820 millisecondes. Le code qui sert Kev prépare ses calculs à l'avance, ce que ne fait pas le code de référence de Strands Decider.

Clef-flash prend 173 millisecondes et 1,4 seconde. Clef prend 562 millisecondes et 4,4 secondes, soit de cinq à sept fois plus que Kev-4B.

Dans ses propres tests, Cloudflare annonce un temps médian de 209 millisecondes pour Clef et de 39 pour Clef-flash. Sur le GB10, une décision à une seule question sur les requêtes publiques a pris 428 et 141 millisecondes en médiane. Un GB10 est une machine de bureau, pas un GPU de centre de données.

Sur cette machine, la mémoire compte davantage, parce que le processeur et le GPU puisent dans la même réserve. Clef en occupe 52 Go, plus des deux cinquièmes, et met environ six minutes à se charger. Clef-flash occupe 18 Go, Kev-4B 14 Go et Strands Decider 4 Go, autant que Kev-0.8B.

Ces temps sont le meilleur cas pour chaque modèle : seul sur la machine, sans réseau entre les deux. En production, Kev-4B partage son GB10 avec d'autres modèles et répond à travers une API : la même décision y prend 143 millisecondes et 1 seconde.

Le modèle que personne n'a entraîné

L'article précédent laissait une question ouverte : la vitesse du Qwen3.5-4B d'OpenJev sur le GPU qui sert Kev. OpenJev n'entraîne rien : il demande à un modèle de conversation ordinaire de choisir la lettre d'une option. Nous l'avons repassé sur la même machine, avec les questions reformulées.

Il reste le modèle le plus juste sur nos requêtes : 97,0 %, en anglais comme en français. Il reconnaît toutes les conversations courantes et 30 des 32 étapes d'agent. Quand les étapes d'agent sont lues dans la requête, il est à 97,6 % et Kev-4B à 97,3 % : une seule requête les sépare.

Il reste aussi le plus sûr de lui. Il a donné 292 réponses avec 90 % de confiance ou plus, dont quatre fausses. Sur les requêtes publiques, il se trompe avec assurance sur 19 % des requêtes, le chiffre le plus élevé du tableau.

Sur le GPU du GB10, sa décision à trois questions prend 192 millisecondes pour une requête courte et 1,1 seconde pour une longue, dans 9 Go. C'est environ le double de Kev-4B pour une requête courte, et plus rapide que Clef.

Ce que cela ne prouve pas

• Chaque modèle n'a tourné qu'une fois, sur deux ensembles de requêtes. Un type compte de 20 à 66 de nos requêtes : pour le plus petit, une seule erreur déplace le chiffre de cinq points.
• Nous avons rédigé et étiqueté les 328 requêtes, et réglé leurs questions sur Kev-4B. Les deux benchmarks ne demandent qu'une chose : de quel type de travail relève une requête. Les tableaux de Cloudflare couvrent une quarantaine d'autres tâches, du choix d'un outil à la lecture de contrats, et placent Clef devant Jev et Kev-9B sur la plupart d'entre elles.
• Clef et Strands Decider ont tourné avec le code publié par leurs auteurs. Le code qui sert Kev est optimisé pour la vitesse, et celui que Cloudflare exploite en production l'est sans doute aussi. Les écarts de temps en disent autant sur le logiciel que sur les modèles.
• Nous n'avons testé que du texte. Clef lit aussi des images et de la vidéo, ce que ne fait aucun autre modèle de cet article.
• Nous n'avons pas rappelé Jev. Ses chiffres viennent du premier benchmark, et il n'a jamais été passé sur nos requêtes.

Ce que cela change pour CARouter

Kev-4B reste derrière /v1/decisions. Clef n'est plus juste sur nos requêtes que là où notre plateforme connaît déjà la réponse. Sur une machine qui sert d'autres modèles, il prendrait 52 Go et cinq fois plus de temps.

Clef-flash est le plus pratique des deux. Il arrive en tête sur les requêtes publiques dans les deux langues et évalue mieux la difficulté que Kev, pour 18 Go et moins de 200 millisecondes sur une requête courte. Mais il prend la moitié de nos requêtes de recherche pour autre chose.

Du côté des petits modèles, Strands Decider est celui à suivre. Dans les 4 Go qu'occupe Kev-0.8B, il gagne sept points de justesse sur nos requêtes et onze sur les requêtes publiques en anglais, sans jamais se tromper avec assurance sur les nôtres. Il est aussi près de cinq fois plus lent que Kev-0.8B, et moins bon en français.

La question ouverte reste celle du dernier article. Un Qwen3.5-4B que personne n'a entraîné est celui qui comprend le mieux nos requêtes, et nous savons maintenant ce qu'il coûte sur le GPU : 192 millisecondes et 9 Go. Son assurance sur d'autres types de requêtes reste à vérifier, et le test de sélection complet reste à passer avec lui.

Toutes les mesures derrière cet article sont conservées, et nous les partagerons avec quiconque le demande.

Kev-4B est le modèle de décision que CARouter sert à l'adresse /v1/decisions. Nous l'avons choisi sur 1 020 requêtes publiques, puis mesuré sur 328 requêtes rédigées à l'image du travail que nous envoient nos clients.

OpenJev prend un autre chemin : il n'entraîne rien. Il demande à un modèle de conversation ordinaire de choisir la lettre d'une option, puis lit la probabilité de chaque lettre. Nous l'avons passé sur les deux benchmarks, noté par le même script que Kev, pour savoir s'il aurait été le meilleur choix.

Lire le premier benchmark. Lire le deuxième, paru avec le lancement de Kev.

En bref

• Sur nos requêtes. Le Qwen3.5-4B d'OpenJev a reconnu le bon type de tâche sur 95,7 % de nos 328 requêtes, contre 88,7 % pour Kev-4B. Il obtient le même score en anglais et en français.
• Les points faibles de Kev. Il a reconnu la conversation courante 97 % du temps, et une étape isolée du travail d'un agent 88 % du temps. Kev-4B n'y voit juste qu'une fois sur trois et une fois sur deux.
• Sur les requêtes publiques. Il y arrive aussi en tête, à 79 % en anglais et 81 % en français, à égalité avec Jev, le service hébergé. Mais il s'y est trompé avec assurance sur 19 % des requêtes, contre 3 % pour Kev-4B.
• L'assurance sur nos requêtes. Il était sûr à 90 % ou plus de 294 réponses, et deux d'entre elles étaient fausses. Kev-4B l'était de 183 réponses, sans jamais se tromper.
• Le fichier du navigateur. Le fichier de 3 Go que télécharge openjev.com fait aussi bien que le modèle complet. Les deux petits modèles que propose le site sont loin derrière, et se trompent souvent avec assurance.
• Vitesse. Sur le GPU de ce portable, le fichier du navigateur rend une décision à trois questions en 267 millisecondes pour une requête courte. Sur le seul processeur d'un serveur, il lui faut de 9 à 12 secondes, plus qu'aux deux modèles Kev, alors que Kev-4B répond en 143 millisecondes sur le GPU qui le sert.

Ce qu'est OpenJev

OpenJev est un projet libre et indépendant, rebaptisé SemIf par son auteur, sans lien avec TypeSafe, l'entreprise derrière Jev. Son code est sous licence MIT, et openjev.com le fait tourner directement dans le navigateur. openjev.com · Code source.

Il place le texte et la question dans une invite, présente les options sous forme de lettres A, B, C, et demande au modèle de répondre par une seule lettre. Le modèle n'écrit jamais rien. OpenJev lit la probabilité que le modèle attribue à chaque lettre : ce sont les probabilités de la réponse.

Son meilleur modèle est Qwen3.5-4B. Kev-4B a été entraîné à partir de la version de base de ce même modèle. Ce test pose donc aussi une question simple : l'entraînement de Kev fait-il mieux que ce que Qwen sait déjà faire après son propre ajustement aux instructions ?

Comment nous avons testé

Nous avons posé à OpenJev exactement les questions posées à Kev. Sur les requêtes publiques, c'est une seule question, avec neuf types de tâche. Sur nos requêtes, ce sont trois questions : le type de tâche, sa difficulté, et si la réponse sera longue.

Un seul script a noté tous les modèles. Avant de noter quoi que ce soit de nouveau, il recalcule les chiffres des deux articles précédents à partir de leurs réponses brutes, et s'arrête si un seul diffère.

OpenJev a tourné avec son propre code, dans une version figée. Pour vérifier notre montage, nous avons d'abord passé ses 144 décisions de test. Nous avons obtenu la réponse publiée par ses auteurs sur les 144, et le même score de 0,813.

Chaque modèle d'OpenJev a tourné deux fois : en pleine précision, d'où viennent ses scores publiés, puis sous la forme du fichier allégé que le site télécharge vraiment. OpenJev prend une question à la fois avec une liste d'options. Une échelle de difficulté est donc devenue cinq options, et une question fermée, Oui et Non.

Nous avons aussi passé Kev-0.8B et les deux modèles Laya sur nos 328 requêtes, que seul Kev-4B avait vues. Jev et Kev-9B n'y figurent pas : Jev est un service hébergé payant que nous n'avons pas rappelé, et Kev-9B ne tient pas sur le portable que nous avons utilisé.

Ce que nous avons trouvé : la justesse

Sur nos requêtes, le Qwen3.5-4B d'OpenJev est le modèle le plus juste que nous ayons mesuré : 95,7 % en pleine précision et 97,3 % avec le fichier du navigateur, contre 88,7 % pour Kev-4B. L'anglais et le français obtiennent le même score.

Sur les requêtes publiques, il égale Jev et dépasse Kev-4B de quatre points en anglais et de onze en français. Dans le premier benchmark, le français coûtait de cinq à huit points à chaque modèle. À OpenJev, il n'a rien coûté.

Les petits modèles du site changent la donne. MiniCPM5-2B, choisi par défaut sur un ordinateur, tient bon sur les requêtes publiques mais tombe à 75 % sur les nôtres. Qwen3-0.6B, proposé pour les téléphones, arrive derrière tous les modèles sauf Laya.

D'où vient l'écart

L'écart tient à deux types de requêtes. OpenJev a reconnu la conversation courante 97 % du temps, et les étapes isolées d'un agent 88 % du temps. Kev-4B, lui, prend une question de culture générale pour de la recherche, et la prochaine étape d'un agent pour du code.

Kev-4B s'en sort mieux avec les documents : 93 % contre 82 % en recherche, et 100 % contre 85 % pour les résumés. OpenJev a tendance à prendre une longue requête de recherche pour de la rédaction d'affaires. Les deux font un sans-faute sur le code, les mathématiques, la rédaction d'affaires et la traduction.

Ce que nous avons trouvé : l'assurance

Un modèle qui décide à la place de quelqu'un ne devrait agir que lorsqu'il est sûr de lui. Le premier article mesurait la part des réponses fausses données avec au moins 90 % d'assurance. Sur ce point, les deux benchmarks ne disent pas la même chose d'OpenJev.

Sur nos requêtes, OpenJev était aussi sûr de lui pour 294 réponses sur 328, et s'est trompé deux fois, en prenant chaque fois une requête de recherche pour de la rédaction d'affaires. Kev-4B l'était pour 183 réponses, sans jamais se tromper. Avec un seuil à 90 %, OpenJev déciderait seul de neuf requêtes sur dix, et Kev-4B d'un peu plus de la moitié.

Sur les requêtes publiques, OpenJev s'est trompé avec assurance sur 19 % des requêtes en anglais, contre 3 % pour Kev-4B et 12 % pour Jev. Beaucoup de ces étiquettes se discutent.

Le jeu de données range « How many U.S. Presidents have served in the military? » parmi les remue-méninges. OpenJev y a vu une question factuelle, sûr à 99,8 %, et nous l'avons comptée fausse, comme pour tous les modèles.

Les étiquettes n'expliquent pas tout. Compté par famille de tâches, là où ces désaccords ne pèsent plus, OpenJev se trompe encore avec assurance sur 15 % des requêtes publiques. Son assurance a tenu sur des requêtes comme les nôtres ; ailleurs, elle reste à vérifier.

Le fichier du navigateur et les petits modèles

Le fichier de 3 Go que télécharge openjev.com est une copie de Qwen3.5-4B en 4 bits. Il obtient 97,3 % sur nos requêtes et 80 % sur les requêtes publiques dans les deux langues, aussi bien que le modèle complet.

Deux choses changent dans le navigateur. La page pose sa question dans ses propres mots, et avec eux, le même fichier obtient 92,7 % sur nos requêtes au lieu de 97,3 %, toujours devant Kev-4B. Elle ne donne aussi au modèle qu'une fenêtre de 2 048 tokens, où 14 de nos 328 requêtes ne tiennent pas.

Les deux petits modèles sont moins justes, et trop sûrs d'eux en plus. MiniCPM5-2B s'est trompé avec assurance sur 14 % de nos requêtes et Qwen3-0.6B sur 24 %, alors que Kev-4B et Kev-0.8B ne l'ont jamais fait.

Difficulté et réponses longues

Sur les deux autres questions, les deux modèles 4B se tiennent. OpenJev place une requête exactement à notre niveau de difficulté 36 % du temps, contre 41 % pour Kev-4B, et à un niveau près, 87 % contre 88 %.

Ni l'un ni l'autre ne prévoit bien une réponse longue. Seules 10 de nos 328 requêtes en demandent une : OpenJev en a repéré 4, et Kev-4B 3.

Vitesse et mémoire

OpenJev pose une question par passage sur le texte. Trois questions demandent donc trois passages, ou un passage sur le texte suivi de trois courts, le mode le plus rapide qu'offre son code. Kev lit le texte une seule fois et répond à toutes les questions à partir de ce passage.

Sur le GPU de ce portable, le fichier du navigateur du Qwen3.5-4B d'OpenJev rend une décision à trois questions en 267 millisecondes pour une requête courte, et en 2,2 secondes pour une requête de 4 000 tokens. Kev-4B ne tient pas sur ce GPU : les deux modèles 4B n'ont donc jamais été chronométrés côte à côte. Sur le GPU de centre de données du premier benchmark, Kev-4B prenait 58 millisecondes et 1 seconde.

Kev-4B tient en revanche sur un MacBook Air équipé de la puce M4 d'Apple et de 24 Go de mémoire, que son GPU partage avec le processeur. Avec MLX, la bibliothèque d'apprentissage automatique d'Apple, que Kev prend en charge, la même décision y a pris 1,3 seconde pour une requête courte et 14 secondes pour une requête de 4 000 tokens.

Avec PyTorch, la bibliothèque qui fait tourner Kev sur notre propre serveur, il a fallu 3,6 secondes pour une requête courte et 20 secondes pour une requête de 1 000 tokens. Sur un Mac, PyTorch n'a pas de version rapide des couches récurrentes de Kev et relit le texte pour chaque question. À 4 000 tokens, il lui fallait plus de mémoire que n'en a le Mac. Sur six requêtes de contrôle, les deux ont donné les mêmes réponses que le GPU de centre de données.

Le Qwen3.5-4B complet demande 8,7 Go pour ses poids, plus que ce que contient le GPU de ce portable. Nous avons donc mesuré sa justesse en gardant une partie du modèle en mémoire système, sans le chronométrer.

Le fichier du navigateur occupe environ 3 Go sur le GPU, tout compris. Kev-4B montait jusqu'à 17 Go sur le GPU du premier benchmark, et tient sous 9 Go sur la machine qui le sert.

Sur le processeur seul

Nous avons chronométré la même décision à trois questions sur deux processeurs de serveur, sans aucun GPU à portée. Le premier est une machine virtuelle avec quatre cœurs AMD EPYC (Milan) et huit fils d'exécution. Le second, ce sont huit des dix cœurs Arm rapides de la machine GB10 qui sert Kev, à la priorité la plus basse, à côté des modèles qu'elle sert. Kev a tourné comme notre serveur le fait tourner : il lit le texte une fois, puis chaque question. OpenJev a utilisé le fichier de son navigateur, dans le plus rapide de ses deux modes. Les pointillés montrent Kev sur le GPU du GB10, pour les mêmes requêtes.

Sur un processeur, le fichier 4B d'OpenJev est le plus lent des trois. Sur les cœurs du GB10, il a pris 8,9 secondes pour une requête courte et 87 secondes pour une requête de 4 000 tokens, contre 6,1 et 53 secondes pour Kev-4B, et 1,3 et 15 secondes pour Kev-0.8B. Sur les cœurs EPYC, OpenJev et Kev-4B se tenaient, à 12 et 10 secondes pour une requête courte, et Kev-0.8B prenait 1,8 seconde.

Rien de tout cela ne convient quand quelqu'un attend la réponse. Sur le GPU de la même machine, Kev-0.8B répond en 52 à 293 millisecondes et Kev-4B en 143 millisecondes à 1 seconde : environ 25 à 50 fois plus vite que le même modèle sur son processeur le plus rapide.

Deux détails comptent sur un processeur. L'EPYC n'a pas d'arithmétique rapide pour les nombres sur 16 bits dans lesquels Kev est stocké : Kev-0.8B y a tourné de sept à huit fois plus lentement que sur 32 bits. Les cœurs Arm du GB10 ont cette arithmétique, et les deux formats y ont tourné à peu près à la même vitesse. Par ailleurs, les huit fils d'exécution de la machine EPYC ne représentent que quatre cœurs : avec quatre fils, Kev n'était qu'environ 20 % plus lent.

Sur le GB10, passer un modèle sur le processeur ne libérerait pas non plus de mémoire : processeur et GPU puisent dans la même réserve, et un modèle y occupe la même place d'un côté comme de l'autre. Kev-4B lit en outre ses poids en nombres sur 32 bits, environ 16 Go, pour y intégrer exactement son adaptateur. Cela ne tient pas à côté des modèles que sert la machine : sur son processeur, nous avons donc chronométré Kev-4B sur 16 bits, avec l'adaptateur à part.

Ce que cela ne prouve pas

• Chaque modèle n'a tourné qu'une fois, sur deux ensembles de requêtes. Pour un type qui compte 20 requêtes, une seule erreur déplace le chiffre de cinq points.
• Nous avons rédigé et étiqueté nous-mêmes les 328 requêtes. Sur les 144 décisions de test d'OpenJev, la fiche du modèle Kev rapporte l'inverse : 0,896 pour Kev-4B contre 0,813 pour le Qwen3.5-4B d'OpenJev. Le gagnant dépend donc des requêtes.
• Le fichier du navigateur a tourné avec llama.cpp sur le GPU du portable, pas dans un navigateur. Sa justesse reste la même, mais pas sa vitesse : les auteurs d'OpenJev ont mesuré 3,3 secondes pour une décision dans Chrome, sur une RTX 3090.
• Les temps sur portable viennent de deux portables, et ceux des processeurs d'une seule machine EPYC et d'un seul GB10, mesurés une fois chacun avec cinq requêtes par longueur. Les cœurs du GB10 servaient en même temps ses autres modèles.

Ce que cela change pour CARouter

Nous avons choisi Kev-4B parce qu'il était le modèle ouvert le plus juste sur les requêtes publiques, et le plus franc sur ses doutes. Sur des requêtes comme celles de nos clients, un Qwen3.5-4B sans entraînement les comprend mieux, y compris les deux types que Kev-4B rate le plus.

Pour l'instant, Kev-4B reste derrière /v1/decisions, sur le GPU : aucun de ces modèles n'a sa place sur un processeur quand quelqu'un attend la réponse. Avant tout changement, nous mesurerons ce Qwen3.5-4B sur le GPU qui sert Kev, à la vitesse que verrait un client, et nous passerons le test de sélection complet dont a besoin le choix automatique du modèle. Toutes les mesures derrière cet article sont conservées, et nous les partagerons avec quiconque le demande.

Kev 4B est maintenant disponible sur CARouter, à l'adresse /v1/decisions. C'est un modèle de décision : il lit un texte et répond à des questions typées à son sujet, avec une probabilité pour chaque réponse, comme le fait Jev, le service hébergé de TypeSafe. Il tourne sur notre propre matériel, au Canada.

Nous l'avons mesuré sur 328 nouvelles requêtes en anglais et en français, puis nous nous sommes servis de ses réponses pour choisir un modèle pour chaque requête parmi les modèles conversationnels que nous servons. Voici ce qu'il réussit, ce qu'il coûte, et ce que vaut un choix de modèle fait de cette façon.

En bref

• Sur les 137 requêtes tenues à l'écart de tous nos choix de conception, Kev a nommé le bon type de tâche 98,5 % du temps : 98,6 % en anglais et 98,4 % en français.
• Kev a donné 76 de ces réponses avec au moins 90 % de confiance, et aucune n'était fausse.
• Choisir un modèle pour chaque requête à partir des réponses de Kev donne un résultat à deux requêtes près du meilleur modèle unique, pour 25 % de coût et 35 % d'attente en moins.
• Une décision à trois questions prend 146 millisecondes sur une requête courte et 1,2 seconde sur une requête de 4 000 mots.
• Il coûte 0,0532 $ CA par million de tokens en entrée, et la sortie est gratuite.

Ce que fait Kev

Un modèle conversationnel répond par des phrases qu'il faut ensuite lire. Kev, lui, n'écrit jamais rien. Vous lui envoyez un état, texte ou objet JSON, avec jusqu'à 32 questions de trois types : un choix parmi des options nommées, une note sur une échelle ordonnée, ou un oui ou non.

Chaque réponse revient avec ses probabilités et un niveau de confiance. Kev lit tout en une seule passe et ne génère rien : il ne peut donc pas inventer une réponse qui ne figure pas parmi vos options.

Voici un courriel adressé au service à la clientèle, soumis à Kev avec trois questions.

curl https://carouter.ai/v1/decisions \
  -H "Authorization: Bearer $CAROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "kev-4b",
    "state": "Hi, I was charged twice for invoice 2026-0417 this month. Can you refund the second charge before Friday? Our accounts close then.",
    "questions": {
      "intent": {"type": "choice", "instructions": "What is the customer asking for?",
                 "criteria": {"refund": "money back for a charge",
                              "invoice_copy": "a copy of an invoice",
                              "cancellation": "ending their subscription"}},
      "urgent": {"type": "noul", "instructions": "Does the customer need an answer within the week?"},
      "tone":   {"type": "score", "instructions": "How upset is the customer?",
                 "criteria": ["calm", "annoyed", "angry"]}
    }
  }'

Kev a répondu que le client veut un remboursement, avec une probabilité de 98 %, que la demande est urgente, à 88 %, et que le client est agacé plutôt que fâché. Il a lu 111 tokens pour y arriver.

{
  "object": "decision",
  "model": "kev-4b",
  "answers": {
    "intent": {"type": "choice", "choice": "refund", "confidence": 0.9752,
               "probabilities": {"refund": 0.9835, "invoice_copy": 0.0077, "cancellation": 0.0088}},
    "urgent": {"type": "noul", "noul": 0.8772},
    "tone":   {"type": "score", "score": 1.1696, "confidence": 0.8253,
               "legend": {"0": "calm", "1": "annoyed", "2": "angry"},
               "probabilities": {"0": 0.0899, "1": 0.6507, "2": 0.2594}}
  },
  "usage": {"prompt_tokens": 111, "total_tokens": 111},
  "served_region": "CA-ON"
}

La requête reprend le format de l'API SystemOne de TypeSafe, avec en plus le champ model que porte toute requête CARouter. L'état peut compter jusqu'à 8 192 tokens. Au-delà, Kev refuse la requête plutôt que de la tronquer, car il garderait le début d'un long texte et en perdrait la fin.

Les mêmes réponses que pendant notre recherche

Avant d'ouvrir Kev à nos clients, nous avons rejoué les 1 020 requêtes de notre benchmark précédent sur la machine qui le sert maintenant. Il a choisi la même réponse que la machine de test pour 1 017 d'entre elles, et sa justesse est identique à la troisième décimale, dans les deux langues.

Les trois écarts étaient des quasi-égalités, sous 45 % de confiance sur l'une comme sur l'autre machine. Le modèle que vous appelez est bien celui que nous avons mesuré.

Un nouveau benchmark, plus proche du vrai travail

Les jeux de données publics ne contiennent pas ce que nos clients envoient : une revue de code, une question de taxes sur une facture québécoise, la prochaine étape d'un agent après le résultat d'un outil, une loi ou un communiqué statistique collé au complet. Nous avons donc rédigé 328 requêtes de ce genre, moitié en anglais, moitié en français.

Le français a été écrit pour un lecteur du Québec ou de l'Ontario, et non traduit de l'anglais. Les longs documents proviennent de sources sous licence ouverte, comme des lois fédérales, des communiqués de Statistique Canada, Wikipédia et des livres du domaine public. Chaque requête indique d'où viennent ses mots.

Nous avons posé à Kev les trois questions dont un sélecteur automatique de modèle a besoin : de quel type de tâche il s'agit, à quel point elle est difficile, et si une bonne réponse sera longue. Il voyait le début des instructions, le nom des outils, ainsi que le début et la fin du dernier message, ou la tâche de l'utilisateur quand ce message est le résultat d'un outil.

Nous avons écrit ces questions et les règles d'aiguillage sur trois cinquièmes des requêtes. Tous les chiffres qui suivent viennent des deux autres cinquièmes : 137 requêtes qu'aucun de ces choix n'avait vues.

Ce que nous avons trouvé

Kev a nommé le bon type de tâche 98,5 % du temps sur ces 137 requêtes. Il a eu juste sur toutes les requêtes dans sept des neuf types, et n'a manqué qu'une requête de recherche et une requête de conversation.

Les étapes d'agent sont lues dans la requête elle-même. Une requête qui porte des définitions d'outils est une étape du travail d'un agent, et le routeur le voit comme il voit la langue et la longueur. Kev seul n'en reconnaissait que la moitié, car le dernier message est le résultat d'un outil qui ressemble à du code ou à une page web.

La frontière entre une question rapide et une question de recherche relève du jugement, et les étiquettes sont les nôtres. Une autre personne aurait pu déplacer ces deux chiffres de quelques points.

Franc sur ses doutes

Pour un modèle qui décide à la place de quelqu'un, le chiffre qui compte le plus est la fréquence à laquelle il se trompe en étant sûr de lui. Kev a donné 76 réponses avec au moins 90 % de confiance, et les 76 étaient justes.

Toutes les réponses que Kev a données avec au moins 60 % de confiance étaient justes, et 86 % de ses réponses ont atteint ce seuil. En dessous, un sélecteur devrait envoyer la requête vers un modèle par défaut plutôt que de se fier à cette lecture.

Difficulté et réponses longues

Kev situe une requête à un niveau près de notre cote de difficulté 85 % du temps. C'est la moins précise des trois lectures, et notre table d'aiguillage ne s'en sert pas encore.

Une requête qui annonce elle-même sa longueur, par exemple au moins 1 000 mots ou un module complet, est lue comme demandant une réponse longue d'après sa formulation. Avec Kev, cela a permis de repérer 3 des 5 requêtes tenues à l'écart qui en demandent une ; les réponses longues demandent encore du travail.

Choisir le modèle de chaque requête

Nous avons ensuite soumis chaque requête aux quatre modèles conversationnels que nous servons depuis le Canada : Qwen3.6 35B A3B et Qwen3 0.6B sur notre propre matériel, ainsi que Tofino 3 et Rosedale 1 d'Augure. Chaque réponse a été notée par un test, un résultat exact ou une grille d'évaluation.

Le code a été exécuté contre ses tests, et les mathématiques et l'extraction comparées à la bonne réponse. La prose a été notée selon une grille par Qwen3.6 35B A3B, réflexion désactivée : ce juge a recalé 2 des 122 bonnes réponses et n'a laissé passer aucune des 122 mauvaises.

À partir des trois cinquièmes servant à la conception, nous avons écrit une table d'aiguillage par type de travail. Tofino 3 prend les étapes d'agent, les mathématiques, la traduction et la conversation, où il égale ou devance les autres en quelques secondes et pour une fraction du prix. Qwen3.6 prend tout le reste, ainsi que toute requête sur laquelle Kev hésite.

Sur les 137 requêtes tenues à l'écart, le choix du modèle avec Kev a donné 81,8 % de réponses réussies, contre 83,2 % pour le meilleur modèle unique, Qwen3.6. C'est deux requêtes d'écart, pour 25 % de coût en moins, et chaque réponse a pris 33 secondes en moyenne au lieu de 51.

Le plafond est plus haut. Choisir après coup le meilleur modèle pour chaque requête donnerait 94,2 % de réponses réussies : une table par type de travail laisse donc de la qualité qu'une politique plus fine pourrait récupérer.

Vitesse et coût

Kev tourne sur un NVIDIA GB10 en Ontario, qui sert aussi nos autres modèles ouverts. Il occupe moins de 9 Go de mémoire et traite une requête à la fois.

Une décision courte prend environ 150 millisecondes, et une requête de 4 000 mots, environ 1,2 seconde. Le GPU de centre de données de notre test précédent était plus rapide sur les requêtes courtes, et proche sur les longues.

Le prix est de 0,0532 $ CA par million de tokens en entrée, et la sortie est gratuite. C'est le prix que TypeSafe publie pour Jev, moins dix pour cent. Une décision à trois questions sur une requête de 500 tokens coûte moins de trois millièmes de cent.

Kev facture chaque token qu'il lit : l'état une fois, puis chaque question avec ses options. TypeSafe ne publie pas la façon dont Jev compte ses tokens : les deux prix sont donc proches, sans qu'on puisse les dire identiques.

Confidentialité

Kev ne conserve rien. Chaque requête est lue une fois, puis oubliée avec sa réponse. Rien n'est partagé entre clients, pas même un cache dont les délais pourraient trahir ce qu'un autre a envoyé.

Les requêtes sont servies au Canada. Avec une clé qui exige notre filtre de renseignements personnels, ceux que contient l'état sont pseudonymisés avant que Kev ne les voie.

Ce que cela ne prouve pas

• Il s'agit d'une seule exécution, sur 328 requêtes que nous avons rédigées et étiquetées nous-mêmes, et les chiffres viennent des 137 tenues à l'écart. Dans un type qui compte 10 requêtes tenues à l'écart, chaque erreur fait bouger le chiffre de dix points.
• Le juge est aussi l'un des quatre modèles qu'il note, ce qui pourrait avantager Qwen3.6 sur la prose. Nous avons vérifié le juge sur des réponses que nous savions justes ou fausses, pas sur des erreurs subtiles.
• La sélection a été simulée à partir des réponses de Kev et de notre table d'aiguillage. Le mode auto de notre plateforme devra réussir le même test avant de choisir quoi que ce soit pour vous.
• Les latences ont été mesurées par un client situé sur la même machine. Une requête qui passe par notre API depuis ailleurs au Canada y ajoute le temps réseau.

Et ensuite

Kev est la première moitié d'auto, le mode où une requête ne nomme aucun modèle et où CARouter en choisit un, au prix ou à la vitesse de votre choix. Avant qu'auto choisisse quoi que ce soit à votre place, nous voulons une politique d'aiguillage plus fine qui comble une plus grande part de l'écart avec 94 %, une meilleure détection des réponses longues, et notre propre mode auto qui réussit ce test.

D'ici là, vous pouvez appeler Kev directement pour trier des demandes de soutien, qualifier des prospects, aiguiller des requêtes, ou pour toute décision que vous préférez ne pas confier à la prose d'un modèle conversationnel. Toutes les mesures derrière cet article sont conservées, et nous les communiquerons à quiconque les demande.

Aujourd'hui, chaque requête adressée à CARouter nomme le modèle qui y répond. Nous voulons en offrir une qui n'en nomme aucun : écrivez auto, et CARouter choisit le modèle qui convient le mieux à la requête, puis la sert selon votre préférence, le moins cher, le plus rapide ou l'équilibre des deux.

Cela demande un modèle de décision, un petit modèle dont le seul travail est de lire une requête et de dire de quel type de tâche il s'agit, en quelques millisecondes. Nous avons testé trois candidats sur 1 020 requêtes réelles, en anglais et en français, pour savoir si l'un d'eux est assez bon pour qu'on lui confie ce choix, et ce qu'il coûterait de le faire tourner.

En bref

• La justesse. Jev, un modèle commercial hébergé, identifie correctement le type de requête 81 % du temps en anglais et 76 % en français. Kev-4B, un modèle ouvert que nous pouvons faire tourner nous-mêmes, atteint 76 % et 70 %. Son petit frère Kev-0.8B atteint 70 % et 64 %. Laya, le troisième candidat, reste sous 60 % tel quel.
• Les erreurs confiantes. Jev se trompe en affirmant être sûr de lui sur une requête sur huit. Kev-4B, sur une sur trente ; Kev-0.8B, jamais. Pour un système qui ne doit agir que lorsqu'il est sûr, cela compte davantage que l'écart de justesse.
• Plus gros n'est pas meilleur. Le plus gros Kev, à 9 milliards de paramètres, ne fait pas mieux que celui à 4 milliards et demande deux fois plus de mémoire. Le 4B est le bon compromis.
• Vitesse. Sur un GPU de centre de données, une décision prend 43 millisecondes sur Kev-0.8B et 58 sur Kev-4B, un délai qu'un client ne remarquera pas. Sans GPU, seul Laya répond assez vite pour être utilisable, et c'est le moins juste.
• Le meilleur candidat. Kev-4B : assez juste, honnête sur ses doutes, ouvert, et rapide sur un GPU. Reste à savoir s'il est assez bon pour choisir des modèles au nom de nos clients, une question que ce test ne peut pas trancher, parce qu'aucun jeu de données public ne contient les types de requêtes qu'ils envoient. C'est le prochain test à construire.

Pourquoi choisir le modèle à votre place

CARouter donne accès à un catalogue de modèles ouverts, tous servis depuis le Canada, par une seule API. La plupart des clients choisissent un modèle au moment de l'intégration et n'y reviennent jamais. Or corriger un bout de code, traduire un paragraphe et résumer un contrat ne demandent pas le même modèle, et le meilleur pour chacun est rarement le plus cher.

Aujourd'hui, un client peut déjà nous dire comment servir un modèle donné : au prix le plus bas, à la vitesse la plus élevée, ou entre les deux. Cette préférence choisit parmi les fournisseurs qui servent le modèle que le client a nommé. Elle ne peut pas choisir le modèle lui-même, et elle ne peut jamais faire sortir une requête du Canada. La sélection automatique ajouterait la première de ces deux choses en conservant la seconde.

Ce qu'est un modèle de décision

Demandez à un modèle conversationnel de classer un billet de soutien : il répond par une phrase, qu'il faut ensuite lire et interpréter. Un modèle de décision n'écrit pas. Il reçoit un texte et une question typée, laquelle de ces catégories, combien sur cette échelle, oui ou non, et renvoie la réponse avec un score de confiance, en une seule passe.

Il n'y a rien à interpréter et rien qu'il puisse inventer, puisqu'il ne génère jamais. C'est ce qui en fait le bon outil à placer devant chaque requête : rapide, prévisible, et honnête sur son degré de certitude.

Jev est la version commerciale de cette idée, vendue par TypeSafe comme service hébergé. Kev en est une reproduction ouverte, en trois tailles, que chacun peut faire tourner sur son propre matériel. Laya est un second modèle ouvert qui répond aux mêmes types de questions avec une conception différente.

Comment nous avons testé

Nous avons posé à chaque modèle une seule question sur 1 020 requêtes : quel type de tâche l'utilisateur demande-t-il, parmi neuf types tels qu'écrire du code, résoudre un problème de mathématiques, résumer un passage ou trouver des idées. Les requêtes et leurs bonnes réponses viennent de trois jeux de données publics, rédigés et étiquetés à la main par des personnes, et non par nous.

Les mêmes requêtes existent en anglais et en français, si bien que les deux langues sont comparées sur un matériel identique. Ni Kev ni Laya n'avaient jamais vu ces jeux de données. Les données d'entraînement de Jev ne sont pas publiques ; il les a peut-être vues.

La vitesse a été mesurée à part, sur trois machines : le seul processeur d'un portable, le petit GPU du même portable, et un GPU de centre de données loué. Chaque requête était inédite, donc aucun raccourci ni cache ne pouvait aider.

Ce que nous avons trouvé : la justesse

Jev mène, Kev suit à cinq ou six points, Laya traîne. Deux choses valent pour tous les modèles. Le code et les mathématiques sont faciles : Jev et Kev-4B ne se trompent sur aucune requête anglaise, et Kev-4B garde un score parfait en mathématiques en français. Et le français coûte cinq à huit points à tout le monde, Jev compris ; c'est donc une propriété de la tâche, pas d'un modèle.

Les scores comptent une réponse comme juste quand elle tombe dans la bonne famille de tâches. Les jeux de données eux-mêmes étiquettent le même type de requête de plusieurs façons, une question sur un passage étant appelée résumé ici et question de lecture là ; le score plus fin à neuf classes est donc plus bas pour tous les modèles, dans le même ordre.

C'est le deuxième graphique qui tranche. Un système qui choisit un modèle au nom d'un client ne doit le faire que lorsqu'il est sûr, et sinon se rabattre sur un choix par défaut raisonnable. Cela suppose un seuil de confiance. Une mauvaise réponse donnée avec une confiance élevée franchit ce seuil sans peine ; ce qui compte, ce n'est donc pas seulement la fréquence des erreurs, mais celle des erreurs commises avec assurance.

Jev est à la fois le plus juste et le plus sûr de lui : 12 % de ses réponses sont des erreurs confiantes. Kev-4B est à 3 % et Kev-0.8B à 0 %. Un seuil de confiance attrape les erreurs de Kev et laisse passer celles de Jev.

Ce que nous avons trouvé : la vitesse, et où chacun peut tourner

Sur un GPU de centre de données, tous les modèles sont assez rapides. Kev-0.8B répond en 45 millisecondes environ, quelle que soit la longueur jusqu'à un millier de mots. Kev-4B demande 58 millisecondes sur une requête courte et environ une seconde sur une très longue. Un GPU de portable donne les mêmes réponses deux à sept fois plus lentement, et ne peut pas charger Kev-4B du tout.

Sans GPU, le tableau change. Kev-0.8B prend plus d'une seconde par décision sur un processeur de portable, et Kev-4B près d'une minute. Seul Laya répond en un quart de seconde, soit environ quatre décisions par seconde et par machine, et c'est le moins juste des six.

La mémoire décide du reste. Kev-0.8B a besoin de 3,4 Go de mémoire GPU, Kev-4B de 17 Go et Kev-9B de 32 Go. Sur une machine qui sert aussi un modèle de langue, cette mémoire est prise sur les requêtes des clients eux-mêmes.

Ce que déployer chacun d'eux impliquerait

• Comme service de décision, sur un GPU qui a de la marge : Kev-4B. Cinq à six points derrière Jev, quatre fois moins souvent sûr de lui à tort, libre d'utilisation sous licence ouverte, et compatible avec l'API de Jev : une équipe qui utilise déjà Jev pourrait changer en modifiant une adresse. Le prix serait de 17 Go de mémoire GPU et 58 millisecondes, et c'est la mémoire qui coûte vraiment sur une machine qui sert aussi des modèles de langue.
• Comme service de décision quand la mémoire est comptée : Kev-0.8B. 3,4 Go, 45 millisecondes, jamais sûr de lui à tort dans notre test. Il céderait six points de justesse au 4B, et c'est tout le compromis.
• Derrière la sélection automatique du modèle : Kev, sous un seuil de confiance, une fois un dernier test réussi. Les 45 millisecondes qu'il ajouterait avant le début d'une réponse sont acceptables, et ses erreurs sont de celles qu'un seuil de confiance attrape. Ce que notre test ne montre pas, c'est la justesse sur les types de requêtes que nos clients envoient réellement, dont le travail d'agents en plusieurs étapes et les très longs documents, parce qu'aucun jeu de données public ne les contient. Ce test doit exister, et être réussi, avant que les requêtes de quiconque soient routées sur la parole de Kev.
• Tourner sans GPU : Laya, une fois entraîné pour la tâche. C'est le seul candidat qui répond vite sur un processeur ordinaire. Tel quel, il identifie la bonne tâche à peine une fois sur deux, et ses auteurs disent que sa justesse vient de l'entraînement sur vos propres exemples, ce que nous n'avons pas fait.
• Jev : la référence, pas un candidat. C'est le modèle le plus juste du test, et un service hébergé par une entreprise de San Francisco qui ne dit rien de l'endroit où les requêtes sont traitées, ce qui règle la question pour un produit dont toute la promesse est que les requêtes restent au Canada. C'est aussi le plus sûr de lui, le seul défaut qu'un seuil de confiance ne peut pas corriger.

Pourquoi le choix doit tenir

Une conversation est une suite de requêtes, chacune portant tout ce qui a été dit avant elle. La plupart des fournisseurs gardent en mémoire, pour un temps, ce début commun, si bien que le tour suivant coûte moins cher et arrive plus vite s'il atteint le même fournisseur. CARouter garde déjà une conversation chez le fournisseur qui détient cette mémoire, tant qu'elle dure.

Si le modèle choisi pour une conversation changeait d'un tour à l'autre, cette économie serait perdue à chaque fois, et le ton des réponses changerait en pleine conversation. La sélection automatique doit donc s'en tenir à son choix : elle retient le modèle retenu pour une conversation et n'en change que lorsque le modèle de décision la contredit avec assurance.

Voilà pourquoi le taux d'erreurs confiantes est le chiffre autour duquel tourne tout ce test. Un seul seuil de confiance décide de deux choses : si un choix est digne de confiance, et si un tour ultérieur peut le changer. Et si le modèle de décision venait à être indisponible, les requêtes partent vers un modèle par défaut plutôt que d'être refusées.

Ce que cela ne prouve pas

Une question, une exécution, un jeu de requêtes. Une question formulée autrement ou un autre jeu pourrait réordonner le milieu du tableau. Cela ne suffirait ni à ramener Laya dans la course ni à déloger Jev du sommet.

Les chiffres sur processeur viennent d'un portable, et un processeur de serveur ferait mieux. Il leur manque aussi le code optimisé pour lequel Kev a été écrit, qui n'existe que pour les GPU. Ils donnent donc un plafond à la lenteur de Kev sans GPU, pas une prédiction pour un serveur donné.

Jev a été chronométré depuis le Canada, par l'internet public, à 185 millisecondes par décision. C'est ce qu'un client d'ici verrait, pas la vitesse propre du modèle.

Où cela nous mène

Kev-4B est le candidat que nous déploierions, et les deux questions encore ouvertes sont pratiques : quelle machine peut lui céder 17 Go, et tient-il sur un test bâti à partir des requêtes que nos clients envoient vraiment. Un service de décision que les clients appellent directement, comme ils appellent aujourd'hui les plongements ou le reclassement, n'a besoin que de la première réponse ; la sélection automatique du modèle a besoin des deux. Chaque mesure derrière cet article est conservée, et nous la partagerons avec qui le demande.

Notre première expérience a généré du texte à travers des opérations linéaires chiffrées, avec un débit très inférieur à notre seuil interactif. Ce nouvel essai examine si les bibliothèques CKKS sur GPU offrent de meilleures bases pour une IA confidentielle.

Lire notre premier benchmark d’inférence homomorphe.

Sur un A100 80 GB SXM, une projection compacte de 512 → 2 048 a pris 23,43 ms avec FIDESlib et 9,89 ms avec Cheddar. Le regroupement des vecteurs a aussi augmenté le débit total. Ces mesures matricielles sont validées : nous n’avons pas généré de réponse LLM complète avec CKKS, et aucun de ces montages n’a démontré la confidentialité face à l’hôte.

Pourquoi tester CKKS?

CKKS désigne le schéma de Cheon, Kim, Kim et Song pour le calcul approché sur des nombres chiffrés. Il peut regrouper des valeurs dans un même texte chiffré et les traiter ensemble. Cette propriété convient aux opérations matricielles des réseaux neuronaux, mais introduit une erreur numérique qu’il faut mesurer. L’article scientifique à l’origine de CKKS.

Nous avons compilé des révisions figées de FIDESlib et de Cheddar. FIDESlib propose des opérations CKKS sur GPU interopérables avec OpenFHE. Cheddar fournit une implémentation GPU avec des transformations linéaires optimisées. Le moteur de calcul diffère donc de celui de notre première expérience; il ne s’agit pas d’une option de chiffrement à activer dans vLLM. FIDESlib. Cheddar.

Ce que nous avons mesuré

Les dimensions du test proviennent de Qwen3.6-35B-A3B. Les vecteurs et les poids étaient synthétiques et publics. Les valeurs d’entrée ont été tirées uniformément entre −1 et 1; les poids utilisaient la même plage, divisée par la racine carrée de la largeur d’entrée. Nous avons mesuré des produits entre vecteurs chiffrés et matrices en clair, en réutilisant les poids préparés d’un essai à l’autre.

Chaque configuration comprenait 1 essai de chauffe, puis 3 essais mesurés. Nous avons synchronisé le GPU avant et après chaque évaluation, puis comparé toutes les sorties à une référence en clair. L’erreur absolue maximale autorisée était fixée à 0,0001. Les résultats ci-dessous présentent les médianes; le graphique et le tableau matriciels affichent aussi les minimums et maximums observés, sans prétendre représenter des intervalles de confiance.

L’évaluation GPU exclut la génération des clés, la préparation des poids, l’encodage, le chiffrement, le déchiffrement et le transport réseau. Les deux clients cryptographiques fonctionnaient sur la VM GPU. Le contrôleur CPU séparé gérait la collecte et la suppression; il ne jouait pas le rôle de client cryptographique de confiance. Ces montages convenaient à des données de test publiques, pas aux requêtes privées des clients.

La configuration matricielle FIDES imposait la vérification HEStd_128_classic d’OpenFHE, avec une dimension d’anneau de 16 384, une profondeur de 2 et des modules de mise à l’échelle de 40 bits. Cheddar utilisait les paramètres bootparam_40 du projet au niveau 2, avec une dimension d’anneau de 65 536 et une arithmétique de 32 bits. Les paramètres et les chemins d’évaluation diffèrent : la comparaison porte sur nos configurations et n’isole pas le seul effet de la bibliothèque.

Le rangement des valeurs compte aussi

Nous avons d’abord complété les matrices rectangulaires pour obtenir des dispositions carrées. Un rangement plus dense des diagonales et la combinaison des sommes partielles ont réduit le calcul inutile. Avec FIDES, la projection 512 → 2 048 est passée de 83,13 ms à 23,43 ms. Le tableau utilise cette disposition plus dense pour les deux bibliothèques. Cheddar emprunte le chemin alternatif qui minimise les changements de clé et qui a réussi nos vérifications numériques.

Nous avons aussi récupéré une seule matrice de projection de porte dans le checkpoint figé, sans télécharger le modèle complet. FIDES a évalué cette projection 2 048 → 512 en 23,74 ms, avec une erreur absolue maximale inférieure à 0,000001 lors des essais mesurés. Les activations restaient synthétiques. Ce test valide une opération avec de vrais poids, pas un bloc de transformeur, du texte généré ou la qualité du modèle.

Le débit par lots n’est pas la vitesse d’une conversation

Pour la projection 2 048 → 1 024 de Cheddar, le regroupement de 16 vecteurs indépendants dans un même texte chiffré a maintenu l’évaluation GPU près de 14,4 ms. Le débit limité à cette évaluation est passé de 69 à 1 111 vecteurs/s. Tous les vecteurs partageaient la même matrice publique et le même contexte de chiffrement; nous n’avons pas testé le regroupement de clients distincts possédant des clés différentes.

En incluant l’encodage, le chiffrement, le déchiffrement et le décodage, le composant mesuré avec un lot de 16 a pris 63,23 ms, pour un débit de 253 vecteurs/s. La préparation des poids réutilisables a pris 52,3 secondes, exclues de ces mesures. Nous n’avons pas démontré que tous les poids préparés du modèle complet peuvent rester en cache, ni mesuré les coûts de transport réseau et d’attente.

Les essais rejetés comptent

Notre première configuration de transformation matricielle fusionnée de Cheddar a produit des résultats incorrects, malgré un chiffrement/déchiffrement précis et une rotation isolée correcte. Une configuration sans BSGS et le chemin alternatif minimisant les changements de clé ont réussi le petit test. Les résultats publiés utilisent ce dernier. Nous n’avons pas établi la cause du problème ni conclu que toutes les configurations du projet échouent.

Nous avons aussi testé le bootstrap de FIDES, qui renouvelle un texte chiffré pour permettre de poursuivre le calcul. Le déchiffrement a échoué avec la configuration de 40 bits. Les configurations de précision supérieure ont produit des erreurs maximales d’environ 0,000207 et 0,000127, toutes deux au-dessus de notre seuil fixe de 0,0001. Ces essais se sont arrêtés pendant la chauffe; leurs durées ne sont donc pas présentées comme des performances de bootstrap validées.

Le client fourni avec Cheddar avertit explicitement qu’il est destiné aux tests et qu’il n’est pas sécurisé. Il conserve les secrets de test sur le GPU. La vérification des paramètres de FIDES est utile, mais notre client installé sur la même VM exposait tout de même sa clé privée au propriétaire de l’hôte. Réussir un test numérique ne valide pas la confidentialité d’un déploiement. L’avertissement du client Cheddar.

Ce que cela signifie pour le seuil de 10 tokens/s

Notre seuil laisse 100 ms par token généré. Pour donner un ordre de grandeur, la somme séquentielle des médianes Cheddar mesurées pour les projections gate, up et down de l’expert partagé, sur les 40 couches du modèle, représente 1,2 secondes de travail GPU. Ce calcul illustratif exclut les experts sélectionnés, l’attention, les opérations non linéaires, l’état de la conversation, la projection du vocabulaire et les coûts client. Ce n’est ni un débit de modèle mesuré ni une limite minimale universelle : la fusion, le traitement par lots et une autre implémentation pourraient le modifier.

Nous avons donc arrêté l’expérience au test des composants, sans prétendre avoir mesuré une inférence CKKS complète. Cette expérience ne fournit aucun résultat CKKS en tokens/s ni en coût par million de tokens. Pour une projection par lots seulement, le coût de l’évaluation GPU par million de vecteurs est de 1 000 000 × P × t / (3 600 × B), où P est le tarif horaire du GPU, t la durée d’évaluation en secondes et B la taille du lot. La préparation, le travail client, le transport et le reste du modèle s’ajoutent.

Souveraineté et GPU disponibles : une piste de recherche, pas encore un service

Pouvoir calculer sans fournir des requêtes lisibles à l’exploitant du GPU pourrait élargir le parc de matériel utilisable à l’échelle mondiale. Cette expérience montre que les bibliothèques CKKS actuelles méritent d’être étudiées davantage dans cette direction. Elle n’établit ni une solution pratique à la pénurie de GPU ni une garantie complète de souveraineté. Le surcroît de calcul cryptographique peut aussi demander davantage de capacité GPU par réponse utile.

Un système utilisable exige encore une frontière de confiance pour le client et ses clés, une attention et un état chiffrés validés, des approximations non linéaires adaptées, une qualité de réponse acceptable et une politique sur les fuites liées au choix des experts et aux caractéristiques du trafic. La confidentialité seule ne peut pas non plus obliger un hôte à renvoyer une réponse correcte, à rester disponible ou à effacer ses copies. Terraform et dstack peuvent gérer les machines; ces propriétés exigent un protocole d’inférence conçu et testé pour les assurer.

La poursuite des travaux homomorphes nécessiterait un bloc chiffré complet et validé avec un client de confiance séparé, puis des essais de qualité du modèle et de latence de bout en bout si cette étape réussit. Nous reportons ces travaux. Les résultats actuels ne justifient pas le lancement d’un service de conversation chiffrée sur GPU communautaires à notre seuil interactif.

Une suite possible : des VM confidentielles avec GPU protégés

Une machine virtuelle chiffrée pourrait-elle rendre l’inférence sur GPU communautaires viable? Tout dépend de ce que le chiffrement protège. Les disques chiffrés protègent les fichiers stockés, tandis qu’une VM classique ou un hyperviseur de type 2 ajouté laisse la mémoire en cours d’utilisation accessible à l’hôte externe. Une VM confidentielle protégée par le matériel peut protéger la mémoire CPU, mais le simple passage direct du GPU à la VM n’étend pas cette protection à sa mémoire et à ses calculs.

L’architecture à évaluer associe une VM CPU confidentielle, un GPU fonctionnant dans un mode de calcul confidentiel pris en charge et une connexion protégée entre les deux. Un vérificateur indépendant contrôlerait des preuves récentes d’attestation du CPU et du GPU, le logiciel invité approuvé et l’identité de sa session avant de libérer des clés ou d’envoyer des requêtes privées. Le passage direct du GPU fait partie de cette configuration; il ne constitue pas à lui seul la garantie de sécurité. Architecture de référence pour VM et GPU confidentiels.

Contrairement à l’évaluation homomorphe, cette approche permettrait à un moteur classique comme vLLM de calculer sur des données en clair à l’intérieur de l’environnement protégé. Elle évite de transformer les opérations du modèle en calculs homomorphes, mais ses performances sur notre charge de travail restent à mesurer. La confiance repose alors sur la protection matérielle, le micrologiciel, le logiciel invité approuvé et les services d’attestation et de remise des clés.

Des hôtes communautaires compatibles pourraient ainsi contribuer sans que leurs outils habituels d’administration donnent accès aux requêtes en clair. Cela ne rend pas n’importe quel matériel admissible : la plateforme doit prendre en charge et exposer l’ensemble du chemin protégé. Le propriétaire peut toujours interrompre le service ou conserver des copies chiffrées, et la garantie ne couvre pas toutes les attaques physiques ni tous les canaux auxiliaires. La confidentialité n’établit pas non plus, à elle seule, la résidence géographique ou la souveraineté. Modèle de menace et limites du calcul confidentiel.

Il s’agit d’une proposition de suivi, reportée pour le moment. Nous n’avons pas réalisé cette expérience sur VM confidentielle et ne présentons aucun résultat de débit ni de validation de sécurité pour cette architecture. Si nous y revenons, nous vérifierons d’abord l’attestation et le refus des configurations non prises en charge, puis comparerons le même modèle et la même charge de travail avec et sans mode confidentiel, en mesurant la latence du premier token, la vitesse de décodage et le coût.

Les crédits de calcul de Denvr ont soutenu ce travail. Les mesures et les conclusions sont les nôtres. Le GPU et le contrôleur ont été supprimés après récupération et vérification des résultats et des archives de sources; la matrice Qwen téléchargée et les bibliothèques compilées n’ont pas été conservées.

Contactez-nous pour obtenir les données du benchmark et les fichiers sources.

CARouter pourrait-elle utiliser des GPU exploités par des personnes auxquelles nous ne faisons pas confiance, tout en protégeant les requêtes de ses clients? Le chiffrement homomorphe rend cette question intéressante. Nous avons commencé avec GPT-2 sur un H100, puis testé Qwen/Qwen3.6-35B-A3B sur un A100 de Denvr doté de 80 Go de mémoire GPU. Ce deuxième essai porte sur un modèle beaucoup plus représentatif d’un service d’IA.

Notre seuil pour une conversation interactive était d’au moins 10 tokens sortants par seconde et par requête. La génération validée de 16 tokens avec calcul linéaire chiffré a atteint 0,00598 tokens/s, après 35,5 minutes d’attente avant le premier token : un débit environ 1 673 fois inférieur au seuil. Un token est un petit fragment de texte, souvent une partie de mot. Nous ne bâtirions pas un service de conversation confidentielle interactive sur cette implémentation.

Merci à Denvr : son programme AI Ascend a accordé à CARouter 1 000 $ en crédits de calcul, qui ont rendu ces expériences possibles. Ces crédits ont financé les essais GPU du modèle moderne et le contrôleur CPU dédié. Nous remercions Denvr pour ce soutien matériel; les mesures et les conclusions sont les nôtres.

Découvrir Denvr AI Ascend.

Le problème de confidentialité commence en mémoire

Le chiffrement protège une connexion ou un disque, mais l’inférence ordinaire manipule toujours les requêtes et l’état de la conversation en clair dans la mémoire de travail. L’administrateur d’un hôte classique peut avoir accès à cette mémoire, y compris au cache KV. Chiffrer un volume au démarrage ne l’en empêche pas, et supprimer une VM ne prouve pas que son propriétaire a effacé toutes les copies.

Le chiffrement homomorphe permet à une machine de calculer sur des valeurs chiffrées et de renvoyer un résultat chiffré. Le chiffrement entièrement homomorphe, ou FHE, étend ce principe au calcul général. Il faut un moteur de calcul compatible : Terraform et dstack peuvent gérer le cycle de vie des VM, mais placer vLLM dans un conteneur chiffré ne rend pas ses calculs homomorphes.

Du petit modèle exploratoire au checkpoint moderne

Le premier essai sur H100 utilisait GPT-2 pour vérifier que nous pouvions générer du texte avec des opérations linéaires chiffrées et contrôler les résultats. La meilleure variante validée pour une requête, avec les poids préparés en cache, a atteint 0,16 tokens/s et environ 33,2 secondes avant le premier token. Ces essais courts, après échauffement, ont permis de tester le mécanisme. GPT-2 ne représente toutefois pas la qualité de modèle attendue aujourd’hui.

Pour l’expérience chez Denvr, nous avons fixé les versions du checkpoint public BF16, du tokenizer et des logiciels. Nous avons utilisé PyTorch 2.9.1+cu128, Transformers 5.17.0 et Concrete ML Extensions 0.1.9 de Zama. La bibliothèque de Zama assurait les opérations linéaires chiffrées; les autres calculs du modèle s’exécutaient côté client. Nous avons d’abord vérifié le chargement du vrai checkpoint, sans paramètres manquants ou incompatibles dans le modèle de texte. Les essais sur un minuscule modèle aléatoire ne validaient que l’intégration; ils n’ont fourni aucun chiffre de performance du modèle cible.

Le modèle repose sur un mélange d’experts : chaque token n’active que certains réseaux experts. Nous avons intercepté les produits linéaires fonctionnels en plus des modules linéaires ordinaires, pour inclure les projections des experts sélectionnés et celle du vocabulaire de sortie. L’attention, les opérations non linéaires, l’état récurrent, les embeddings et la sélection des tokens restaient en clair côté client. Il s’agit d’une inférence linéaire chiffrée assistée par un client, et non d’un transformer entièrement chiffré.

Comment nous avons mesuré les performances

Nous avons établi une référence de service avec vLLM, une référence de génération native dans le même framework, puis une référence quantifiée en clair utilisant les mêmes calculs que l’adaptateur chiffré. Celui-ci quantifie les activations et les poids en valeurs signées sur 8 bits; la mention BF16 du checkpoint ne signifie donc pas que les calculs chiffrés se font en BF16. La référence de service utilisait une génération déterministe, le raisonnement désactivé et une exécution sans graphes CUDA, avec des requêtes courtes et longues répétées ainsi qu’un groupe simultané. Les préfixes pouvaient être réutilisés; nous ne cherchions pas la capacité maximale.

Pour la génération chiffrée, les requêtes synthétiques publiques contenaient 21 tokens après mise en forme conversationnelle. La requête longue demandait pourquoi le chiffrement est important; la courte demandait combien font deux plus deux. Nous avons mesuré séparément l’attente du premier token, le décodage suivant et la durée totale de la requête. Le débit de décodage exclut le premier token. Le chargement du modèle, la création des clés, l’envoi de la clé publique et le démarrage des VM sont exclus de ces durées.

Le premier déploiement plaçait le client et l’évaluateur sur la même VM GPU pour mesurer le calcul. Son propriétaire pouvait lire la clé du client et sa mémoire en clair. Nous avons ensuite séparé l’évaluateur et un client limité à 4 CPU et 12 Gio de mémoire. La clé privée restait dans la mémoire du processus CPU; le GPU recevait une clé publique de compression et des activations chiffrées. L’attention et l’état KV restaient sur la VM CPU.

Résultats mesurés avec le modèle moderne

La génération chiffrée longue s’est terminée et tous les scores de sortie conservés correspondaient exactement à la référence quantifiée. Elle a atteint sa limite de longueur au milieu d’un paragraphe; il ne s’agissait pas d’une évaluation de la qualité d’une réponse complète. Nous avons volontairement arrêté la répétition supplémentaire après validation indépendante de la requête terminée. Elle n’ajoute aucun échantillon de débit.

L’essai avec client séparé a renvoyé « 4 », puis le token de fin de séquence. Tous deux comptent dans sa sortie de deux tokens, ce qui laisse une seule étape de décodage après le traitement de la requête. Cette étape a pris 178,5 secondes. C’est un essai réseau court, pas une estimation du débit sur une longue conversation. Tous ses scores conservés correspondaient eux aussi exactement à la référence.

La référence de service native a atteint environ 17,06 tokens/s par requête courte. Cela montre que le matériel loué peut servir ce checkpoint; les calculs diffèrent toutefois de ceux de l’adaptateur quantifié. Le débit natif simultané et les lots de matrices synthétiques ne constituent pas des mesures du débit chiffré du modèle par lots, que nous n’avons pas mesuré ici.

Les débits natifs sont estimés à partir du contenu diffusé et du nombre de tokens déclaré; la colonne du premier token correspond au premier contenu reçu. Les modes chiffrés chronomètrent chaque passage du modèle et la sélection du token. Nous conservons ces conventions et les échantillons bruts de service dans nos archives de benchmark.

La justesse avant la vitesse

Nos premiers essais de précision ont révélé des réglages qui généraient du texte sans réussir la comparaison numérique. Les essais du modèle moderne ont repris les précisions supérieures validées pour le stockage des chiffrés et le changement de clé. Nous avons contrôlé les produits entiers chiffrés lors de l’audit du modèle complet, puis enregistré et relu indépendamment les tenseurs de scores de chaque requête chiffrée terminée. La tolérance est restée à 0,005; l’écart maximal observé était nul.

Cela établit l’accord avec la référence quantifiée testée. Cela ne prouve pas une qualité de réponse égale à celle du checkpoint original : les suites de texte natives et quantifiées différaient. Nous n’avons mené ni évaluation de qualité sur un ensemble de tâches, ni examen cryptographique indépendant. Les échecs de configuration, l’erreur de sérialisation et les interruptions volontaires restent dans les archives, sans être comptés comme des inférences réussies.

Le réseau n’était pas la principale source d’attente

L’étape de décodage avec client séparé a passé 167,5 secondes dans le traitement chronométré par l’évaluateur. L’écart avec le temps aller-retour mesuré côté client était de 2,2 secondes, regroupant transport, sérialisation et ordonnancement. Ce n’est pas une mesure de latence réseau pure. Le calcul chiffré et le traitement des poids dominaient le délai; changer d’orchestrateur de VM ne supprimerait pas ce travail.

L’essai réseau a transféré 53,3 Mo de données applicatives pendant cette étape de décodage, au fil de 1 031 appels linéaires séquentiels. L’envoi initial de la clé publique de compression a ajouté 536,9 Mo et pris 2,09 secondes, séparément de l’inférence. Ces volumes excluent le surdébit HTTP, SSH et TCP. La comparaison avec l’essai sur une seule VM n’isole pas non plus le réseau : l’exécution côté client et les contrôles de produits entiers différaient aussi.

Nous avons testé séparément la mise en cache des poids préparés sur le GPU. Elle a amélioré certains temps de calcul sur une seule ligne, mais ce microbenchmark ne générait pas de texte avec le modèle complet et ses poids en cache. L’accélération d’un noyau isolé ne peut pas être présentée comme un nouveau débit du modèle.

Ce que coûte une réponse

Au tarif GPU relevé de 1,45 $/heure, la génération longue a consommé environ 1,87 $ de temps d’exécution mesuré. Son débit de décodage correspondrait à environ 67 394 $ par million de tokens sortants, sans traitement initial de la requête ni préparation. En incluant la VM CPU séparée, la requête réseau courte a consommé environ 1,24 $ de temps d’exécution. Il s’agit de calculs selon le tarif, pas de factures ni de tests de capacité sur un million de tokens.

Le calcul estimé pour l’expérience chez Denvr, en incluant les tentatives échouées, le provisionnement et la durée de vie du contrôleur, s’élève à 7,75 $. Cette estimation repose sur les périodes d’allocation et les tarifs horaires; elle exclut le stockage, le réseau, les arrondis de facturation et les taxes. Nous n’avons pas consommé la totalité de la subvention. Les crédits ont permis de répondre à la question technique avant d’investir dans un système plus vaste.

Ce que cela implique pour l’inférence confidentielle de CARouter

Avec le moteur et la configuration testés, le seuil de performance interactive n’a pas été atteint. Ce résultat déconseille de bâtir aujourd’hui l’orchestration de production autour de cette implémentation; il ne prouve pas que tous les schémas homomorphes ou toutes les optimisations futures seront lents. Un autre moteur devra démontrer une vitesse utile, une qualité de réponse acceptable et une protection complète sur la charge de travail visée.

Le client séparé laisse aussi des hypothèses de confiance explicites. L’évaluateur voit les identifiants des experts sélectionnés, les dimensions des tenseurs et les durées. La VM CPU ordinaire suppose que son propre exploitant est digne de confiance. Nos requêtes synthétiques figuraient dans le code public des essais : l’expérience ne démontre donc pas que leur texte était inconnu de l’hôte GPU. Elle ne rend pas n’importe quelle machine communautaire sûre pour des requêtes clients.

Pour l’inférence native, une autre piste est le calcul confidentiel avec protection compatible du CPU et du GPU, attestation et remise des clés liée à la charge de travail vérifiée. Nous n’avons ni déployé ni mesuré cette architecture ici. Le nom d’un modèle de GPU ne suffit pas à établir ces protections. La confidentialité ne certifie pas non plus l’emplacement d’une machine et ne remplace pas les règles de résidence et de consentement aux fournisseurs de CARouter.

Un contrôleur CPU indépendant gérait les échéances des allocations et recueillait les résultats : une déconnexion du portable ne commandait donc pas la facturation GPU. Nous avons récupéré le code et les preuves, vérifié leurs empreintes et confirmé par l’API de Denvr la suppression de toutes les VM de l’expérience, y compris le contrôleur contenant les identifiants du compte. Les tenseurs de sortie sont conservés pour les vérifications futures, mais pas les poids des modèles ni les binaires compilés. Une suppression confirmée par API reste un constat opérationnel, pas une preuve d’effacement physique ni une protection contre un hôte ayant déjà vu des données en clair.

Où en est la technologie aujourd’hui

En septembre 2026, des systèmes de recherche s’attaquent aux caches KV chiffrés et à l’exécution hybride combinant chiffrement homomorphe et calcul confidentiel. Ce sont des pistes concrètes, mais les résultats dépendent de la taille du modèle, des hypothèses de confiance et de la nature des chiffres : génération réellement mesurée ou estimation à partir de composants. Nous n’avons pas reproduit ces systèmes; leurs vitesses annoncées ne valident donc pas notre charge de travail.

Cachemir · Bifrost

Face aux enjeux mondiaux de souveraineté, le chiffrement peut réduire la dépendance à la capacité ou à la volonté d’un exploitant distant de protéger les données en clair. Il n’établit pas à lui seul la souveraineté. La maîtrise des clés et du client de confiance, les lieux de calcul autorisés, l’exposition des métadonnées, l’intégrité du modèle et la continuité du service restent des exigences distinctes. Un calcul confidentiel à l’étranger ne respecte pas automatiquement la politique de résidence d’un client.

Face à la pénurie de GPU, la mesure pertinente est le nombre de réponses utiles par unité de calcul. Le chiffrement pourrait rendre utilisable un plus grand ensemble de machines jusque-là inadaptées, mais son surcoût doit rester inférieur à la capacité ainsi débloquée. Le moteur testé consomme beaucoup plus de temps de calcul par réponse. Ajouter des machines sans modifier cette implémentation séquentielle ne démontrerait pas une conversation individuelle plus rapide.

Notre constat : les briques cryptographiques existent, mais les preuves que nous avons examinées n’établissent pas encore un service généraliste d’inférence chiffrée de LLM modernes, économiquement utile sur des GPU communautaires quelconques. Pour l’immédiat, nous privilégions le calcul de confiance et l’évaluation séparée de déploiements confidentiels attestés. Nous réexaminerons l’inférence homomorphe communautaire lorsqu’un système complet démontrera le débit requis par requête, la qualité des réponses, la protection de l’état et des métadonnées, ainsi qu’un fonctionnement capable de reprendre après incident. Cela répondrait à une partie du problème de souveraineté; son intérêt face à la pénurie de GPU resterait à démontrer.

Obtenir les fichiers du benchmark

Ces conclusions décrivent nos expériences de septembre 2026. Nous conservons les mesures détaillées et les fichiers sources pour les travaux de suivi. L’essai H100 initial utilisait un autre modèle et un autre matériel; ces résultats ne comparent donc pas les générations de GPU.

Contactez-nous pour obtenir les données du benchmark et les fichiers sources.

Pour aller plus loin

• Documentation de l’inférence assistée par un client dans Concrete ML.
• Code source de l’extension CUDA de calcul chiffré.
• Prérequis NVIDIA pour l’attestation en calcul confidentiel.

Un assistant d’IA reçoit souvent les mêmes instructions et l’historique de la conversation à chaque nouvelle question. Traiter à nouveau ce contenu prend du temps et peut alourdir la facture. La mise en cache des prompts permet au fournisseur de réutiliser temporairement le travail déjà effectué, avec un potentiel de réponses plus rapides et de coûts d’entrée réduits.

L’affinité de cache de CARouter vise à préserver cet avantage lorsqu’une requête doit passer à un autre fournisseur. Le fournisseur qui vient de répondre est privilégié pour les requêtes suivantes utilisant la même clé API et le même modèle. L’activation dépend de la vérification de la durée de cache publiée par chaque fournisseur.

Pourquoi un changement de fournisseur compte

Prenons un assistant de service à la clientèle en pleine conversation. Son fournisseur habituel est occupé. CARouter confie donc la requête suivante à un autre fournisseur autorisé qui sert le même modèle. Celui-ci traite la conversation et peut mettre le contenu répété en cache pour le réutiliser.

Sans affinité de cache, la requête suivante peut retourner au fournisseur habituel dès qu’il est disponible. Le travail effectué chez le fournisseur de remplacement ne peut pas y être réutilisé. Confier la suite au fournisseur qui vient de répondre permet de profiter de son cache, s’il est encore disponible.

Vos règles de routage restent prioritaires

• Résidence des données et fiabilité : cette préférence ne place jamais un fournisseur étranger devant un fournisseur souverain. Elle respecte vos autorisations et vos règles de passage à l’étranger, et ne privilégie pas un fournisseur dégradé face à un fournisseur en bon état dans la même catégorie de résidence.
• Maîtrise des coûts : si votre clé API privilégie le coût, le tarif affiché le plus bas reste prioritaire. L’affinité de cache départage seulement les offres au même prix.
• Mémoire de routage limitée : cette fonction retient le fournisseur qui a répondu en dernier pour une clé API et un modèle. Elle ne conserve ni copie ni empreinte de votre prompt. Le fournisseur gère son propre cache.
• Préférence temporaire : chaque requête réussie renouvelle la préférence pour la durée de cache vérifiée du fournisseur. À l’expiration, le routage habituel reprend. Il s’applique aussi si la préférence ne peut pas être consultée.

À quoi vous attendre

Les instructions répétées et les conversations suivies offrent le meilleur potentiel. Les économies et les gains de rapidité ne sont pas garantis : le fournisseur doit prendre en charge le cache, reconnaître du contenu réutilisable et l’avoir encore à disposition. CARouter ne crée pas de cache et n’en transfère pas entre fournisseurs.

Lorsqu’un fournisseur indique la quantité de tokens entrants servis depuis son cache et publie un tarif correspondant, ce tarif est utilisé pour calculer le coût de la requête. La documentation affiche les tarifs des entrées en cache lorsqu’ils sont disponibles, afin que votre équipe puisse en évaluer l’intérêt.

L’affinité de cache s’active uniquement pour les fournisseurs dont la durée de cache a été vérifiée. Sans cette vérification, les requêtes suivent les règles de routage existantes.

Comparer les modèles et les tarifs disponibles. Consulter les règles techniques de routage.

Chaque offre de notre page de documentation porte désormais une petite feuille. À côté, un chiffre : une estimation du carbone émis pour servir un million de tokens avec ce modèle, chez ce fournisseur. Ce billet explique pourquoi nous le publions, comment il est calculé, et ce qu'il laisse de côté.

Pourquoi un chiffre, et pourquoi maintenant

La consommation électrique de l'IA est devenue une question publique, et une question légitime. Ceux qui choisissent CARouter font déjà un choix délibéré sur la destination de leurs données. Ils méritent la même clarté sur ce que leurs requêtes coûtent au réseau électrique, pour que souverain et durable soient une seule décision plutôt que deux.

Le 3 septembre, le gouvernement du Canada a lancé ses Principes pour le développement responsable des centres de données. Deux des cinq demandent aux centres de données de réduire au minimum leurs impacts environnementaux et d'en rendre compte de façon transparente. Nous ne construisons pas de centres de données. Nous y acheminons des requêtes. À notre échelle, la transparence, c'est un chiffre à côté de chaque offre, avec sa méthode et ses sources, pour qu'un client puisse en tenir compte. Les principes, sur canada.ca.

Ce que dit la feuille

• Le chiffre. Des grammes d'équivalent CO₂ par million de tokens, électricité d'exploitation seulement, arrondis à deux chiffres significatifs.
• La couleur. La catégorie du réseau qui alimente le service : vert sous 100 g de CO₂e par kWh, ambre jusqu'à 300, rouge au-delà. Le réseau plutôt que le chiffre, parce que c'est sur le réseau que vous avez prise en choisissant d'où un modèle est servi.
• Par offre, pas par modèle. Pour un même modèle, les émissions peuvent varier de deux ordres de grandeur entre le Québec et l'Alberta. Une moyenne par modèle ne correspondrait à aucun des réseaux réellement utilisés.
• Ou rien. Aucune feuille n'est affichée si le nombre de paramètres du modèle ou l'intensité carbone du réseau ne sont pas documentés. Nous ne remplaçons pas une donnée manquante par celle d'une région voisine.

Comment il est calculé

Deux données vérifiées et une formule publiée.

L'énergie découle du nombre de paramètres actifs du modèle, celui que son concepteur publie sur la fiche du modèle. Une passe avant coûte deux opérations en virgule flottante par paramètre actif et par token, autant pour le préremplissage, le décodage, les plongements que le reclassement. Avec les constantes de service de classe H100 publiées par Epoch AI, cela donne environ 0,006 kWh par milliard de paramètres actifs et par million de tokens, refroidissement et distribution compris.

L'intensité carbone découle du réseau de la région d'où le fournisseur déclare servir : le chiffre de la Régie de l'énergie du Canada pour chaque province, celui de RTE pour la France, celui de l'Energy Information Administration pour les États-Unis. Chaque ligne indique l'année qu'elle décrit et l'adresse où le chiffre a été lu. Un fournisseur qui ne déclare que le Canada, sans province, est compté sur la moyenne nationale.

On multiplie les deux. Pour un modèle de 100 milliards de paramètres actifs, 0,59 kWh par million de tokens devient, selon les chiffres publiés des réseaux :

• 0,7 g au Québec, 8 g en Colombie-Britannique, 21 g en Ontario ;
• 59 g sur la moyenne nationale canadienne ;
• 220 g sur la moyenne américaine, et 280 g en Alberta.

Pour un même modèle et les mêmes tokens, les émissions varient d'un facteur quatre cents entre le réseau le moins polluant et le plus polluant. Cet écart justifie de publier une estimation pour chaque offre.

Ce qu'il ne compte pas

• Les émissions liées à la fabrication du matériel, et le réseau entre les deux. C'est l'électricité de l'inférence, rien d'autre.
• Le matériel réel du fournisseur. Toutes les offres utilisent les mêmes constantes H100 : l'estimation permet de les comparer, sans mesurer la consommation de leurs serveurs. Elle surestime celle des puces plus récentes et sous-estime celle des plus anciennes, d'un facteur constant.
• Les certificats d'énergie renouvelable et les contrats d'approvisionnement. Le chiffre du réseau est géographique : une prise en Alberta tire le mélange albertain quoi que disent les papiers, et un chiffre géographique ne se manipule pas.
• L'actualité des données. Les chiffres des réseaux sont des moyennes annuelles qui évoluent. Chaque ligne indique l'année de référence, et nous nous engageons à consulter régulièrement les sources.

S'en servir pour choisir

Deux habitudes rapportent. Choisir le plus petit modèle qui fait le travail, parce que l'énergie suit le nombre de paramètres actifs et qu'un petit modèle sur un réseau propre est le token le moins cher qui soit. Et quand un modèle est servi depuis plusieurs endroits, préférer l'offre la plus verte. Au Canada, cela entre rarement en conflit avec la souveraineté : les provinces hydroélectriques offrent les deux.

L'estimation figure aussi dans la version lisible par machine de notre documentation, avec la méthode complète, pour qu'un agent qui choisit un modèle à votre place puisse en tenir compte lui aussi. La page de documentation affiche la feuille à côté de chaque offre qui en a une.

CARouter a été admis dans Denvr AI Ascend, le programme de démarrage de Denvr Dataworks.

Denvr est un fournisseur infonuagique souverain de l'Alberta : une entreprise canadienne qui exploite ses propres grappes de GPU à Calgary. C'est exactement ce que nous exigeons de chaque fournisseur présent sur notre plateforme. Le choix allait de soi.

Ce qu'est Denvr

Denvr répond aux deux questions que nous posons à tout fournisseur : qui possède l'entreprise, et où se trouvent les machines.

Denvr nous a dit en août ce qu'il vend : des GPU à l'heure, sans API d'inférence. Les points d'accès hébergés ne sont pas à leur feuille de route cette année, et Denvr ne figure donc pas parmi les fournisseurs listés sur notre page de documentation.

Cette annonce n'y change rien. Aucune requête passant par notre plateforme ne tourne chez Denvr. Un programme de démarrage n'est pas une entente de partenariat. Ce sont des crédits, et des crédits achètent du temps de machine.

À quoi servira ce temps de machine

Jusqu'ici, tout ce que nous avons publié sur ce blog a été mesuré sur une seule machine de bureau, celle de classe DGX Spark qui fait tourner CARouter Cloud. Elle nous apprend beaucoup sur les petits modèles en mémoire unifiée, et rien sur les serveurs de classe H100 qu'exploitent réellement les fournisseurs canadiens.

Les crédits iront donc à la mesure. Trois chantiers :

• Des modèles à poids ouverts sur du matériel canadien. Les mêmes tests de débit, la même évaluation comparative de code et les mêmes essais de contexte long que sur le Spark, cette fois sur des GPU de centre de données à Calgary.
• Des chiffres utiles au routeur. Aujourd'hui, les candidats sont classés par résidence, puis par priorité, puis par prix. Le routeur ne sait rien du comportement d'une offre sous charge. Mesurer la latence et le débit de chaque modèle, c'est ce qui transforme cette règle en décision éclairée.
• Publié ici, erreurs comprises. Chaque campagne de mesures deviendra un article : le protocole, les graphiques tirés des mêmes chiffres, les réserves. Une mesure que personne ne peut reproduire n'est qu'un argument marketing.

Ce que nous ne promettons pas

Il existe une seule façon pour du matériel Denvr de servir un jour le trafic de nos clients : que CARouter Cloud fasse tourner sa propre pile de service sur des GPU loués à Calgary. Du matériel canadien, dans un centre de données canadien, exploité par nous. Chaque engagement de notre plateforme tiendrait.

Notre étude de capacité prévoit d'ailleurs un nœud Denvr réservé comme solution de repli, si le matériel que nous comptons acheter ne tient pas ses promesses. Nous le notons par souci de transparence. Ce n'est pas un projet en cours, et ce programme ne le finance pas. Denvr restera absent de la page de documentation tant que rien de concret n'aura changé.

Merci à l'équipe de Denvr pour son accueil. La documentation présente chaque fournisseur de notre plateforme et ce qu'il garantit aujourd'hui.

Nous annonçons aujourd'hui un partenariat avec Augure, une entreprise d'IA torontoise. Rosedale One et Tofino 3 sont dès maintenant en service sur notre plateforme.

Notre carte de partage porte trois mentions. Chacune s'appuie sur une entente signée. Voici ce qu'elles veulent dire concrètement.

En bref

• Qui. Augure est une entreprise canadienne, établie à Toronto, sans aucune société mère étrangère. Elle post-entraîne ses propres modèles à partir de bases à poids ouverts et les sert sur des GPU situés au Canada.
• Quoi. Rosedale One est le modèle de raisonnement : un million de tokens de contexte et une phase de réflexion. Tofino 3 est le modèle léger : rapide, sans réflexion, 256K de contexte. Les deux prennent en charge les outils, la sortie JSON structurée et les images. Nous l'avons vérifié nous-mêmes.
• Où. Au Canada, par contrat. Une requête est servie sur une infrastructure canadienne ou elle est refusée. Jamais de basculement, de réplication ni de débordement à l'étranger.
• Conservation. Requêtes et réponses sont effacées dès qu'elles ont été traitées. Les métadonnées, qui n'en contiennent rien, sont conservées trente jours au plus. Nous publions ces deux garanties séparément.
• Preuve. Chaque réponse porte l'en-tête X-CARouter-Region. Pour ces deux modèles, sa valeur provient de ce qu'Augure déclare pour la requête elle-même, et non d'une étiquette fixée une fois pour toutes.

Servi au Canada, ou refusé

Augure s'engage à ne traiter les requêtes que CARouter lui achemine, pour ces deux modèles, que sur une infrastructure située au Canada. Quand la capacité canadienne est épuisée, Augure renvoie une erreur plutôt que de servir la requête ailleurs. Il n'est pas acceptable, ni pour Augure ni pour nous, qu'une requête franchisse le territoire canadien, alors même que nous avons assuré au client qu'elle ne le ferait pas.

De notre côté, la même promesse. CARouter ne bascule jamais une requête d'un pays à un autre, sauf si la clé API l'autorise expressément. Quand Augure est saturé, le client reçoit une erreur provider_at_capacity accompagnée d'un en-tête Retry-After. Une plateforme moins rigoureuse servirait discrètement un autre modèle depuis un autre pays. Nous préférons expliquer une erreur plutôt qu'une substitution.

D'où vient l'en-tête de région

L'API d'Augure indique, sur chaque réponse, où le modèle a réellement tourné. Nous lisons cette valeur à chaque requête et la publions dans l'en-tête X-CARouter-Region. Mesurés avec notre propre identifiant, les deux modèles répondent depuis Waterloo, en Ontario.

Le lieu de traitement est donc vérifié à chaque requête. Si nous ne savons pas situer la valeur reçue, nous indiquons UNVERIFIED au lieu de reprendre la région déclarée par le fournisseur.

En diffusion continue, l'en-tête part avant qu'Augure ait répondu. La valeur corrigée est donc envoyée dans une trame carouter.region finale et consignée dans le journal des requêtes.

Zéro conservation, noir sur blanc

La page sécurité d'Augure promettait déjà zéro conservation. L'entente y ajoute un engagement qui ne peut pas changer sans préavis : le contenu des requêtes et des réponses n'est pas conservé une fois la requête traitée, et rien n'en sert à entraîner, à affiner ni à évaluer un modèle. Les métadonnées de requête, qui ne contiennent aucun contenu, sont conservées trente jours au plus, et nous publions cette garantie à part.

Pour l'utiliser

Augure est désactivé par défaut dans chaque espace de travail, et aucun déploiement ne l'activera à votre place. L'activer dans les Paramètres vaut acceptation des conditions d'Augure. Un interrupteur déjà activé serait un consentement que personne n'a donné.

Une fois activé, les deux modèles répondent au point d'accès habituel :

curl https://carouter.ai/v1/chat/completions \
  -H "Authorization: Bearer $CAROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model": "tofino-3", "messages": [{"role": "user", "content": "Bonjour"}]}' \
  -i | grep -i x-carouter-region

Les tarifs sont les tarifs de base majorés selon votre forfait, comme pour toute autre offre. La documentation présente les deux modèles et leurs tarifs en vigueur.

Et ensuite

D'autres modèles suivront à mesure qu'Augure les ancrera au Canada. Chacun ne sera publié qu'une fois qu'Augure aura confirmé par écrit qu'il est servi au Canada, sans basculement à l'étranger. Aucun modèle n'entre sur notre plateforme sans cette garantie. C'est tout l'objet du partenariat.

Qwen a publié Qwen3.8-Flash-Next le 26 août, un premier aperçu de l'architecture sur laquelle reposera la famille Qwen4, et il s'est hissé d'emblée en tête des palmarès de codage : 91,9 sur LiveCodeBench v6 contre 80,4 pour le modèle que fait tourner notre propre point d'accès de codage. Trois jours plus tard, nous le servions sur la machine de bureau qui sert CARouter Cloud, et nous ne l'avons pas gardé. Voici tous les chiffres que nous avons mesurés, et ce qu'ils coûtent.

Le billet précédent : pourquoi le point d'accès de codage fait tourner Qwen3.6 35B-A3B, un modèle plus ancien et moins bien classé, plutôt que Qwen3.8 27B.

En bref

• Il n'entre pas. La plus petite version que nous puissions servir pèse 125,9 Gio. La machine dispose de 121,6 Gio de mémoire au total. C'est le premier modèle que nous examinons qui soit plus gros que l'ordinateur, avant même d'avoir stocké un seul token de conversation.
• 38 % de son poids n'est pas un modèle. C'est une table de correspondance : 20 000 000 de lignes de plongements de n-grammes, 51,2 milliards de paramètres, 47,7 Gio. Un token en touche 16 lignes. Diffusez-les depuis le SSD au lieu de les garder en mémoire et ce qui doit rester résident tombe à 78,2 Gio, ce qui entre.
• Le nombre de paramètres annoncé l'omet. La fiche du modèle annonce 125 milliards. Les poids en contiennent 180 milliards. La différence, c'est cette table, plus la tête de brouillon et la tour de vision, toutes comptées à part.
• Il est environ trois fois plus lent. 21,3 tokens par seconde sur 1 flux contre 62,2, et 129,8 contre 367,2 avec 16 flux simultanés. Le préremplissage est 3,7 fois plus lent. Il tient le quart des conversations simultanées de 262K tokens : 1,7 contre 7,0.
• Il code probablement mieux. Sur les 40 problèmes qu'il a terminés dans un budget de 32 768 tokens, il en a résolu 29, contre 27 pour le modèle que nous servons et 26 pour celui d'avant. Il a dépassé le budget sur les 10 autres. Aucun des deux écarts n'est statistiquement significatif.
• Mais l'attente est dix fois plus longue. Il écrit 16 751 tokens par problème là où le modèle en place en écrit 4 738. À sa propre vitesse de décodage, cela donne une réponse de 13 minutes contre 76 secondes, pour au mieux 1 problème résolu de plus sur 40.

Un modèle plus gros que l'ordinateur

Le point d'accès auto-hébergé de CARouter Cloud tourne sur un seul ASUS Ascent GX10, une machine de bureau de classe DGX Spark : une puce GB10 avec 128 Go de mémoire partagée entre le processeur et la partie graphique, dont 121,6 Gio réellement adressables. Chaque modèle que nous avons mis en service devait y entrer, aux côtés des 2 modèles de plongement et du reclasseur que le produit sert également.

Qwen3.8-Flash-Next n'y entre pas. 9 personnes différentes en avaient publié des versions quantifiées en 72 heures, et nous les avons toutes vérifiées : la plus petite que nous puissions réellement servir pèse 125,9 Gio de poids. C'est 4,3 Gio de plus que ce que contient la machine entière, avant le système d'exploitation, avant le moteur d'inférence, avant d'avoir stocké un seul mot de la conversation de qui que ce soit.

Normalement l'histoire s'arrête là, et notre procédure de présélection est conçue pour y mettre fin en 10 minutes environ, à partir des métadonnées publiques, sans rien télécharger. Ce qui a valu la peine de continuer ici, c'est d'avoir lu la liste réelle des tenseurs du fichier plutôt que la fiche du modèle.

La fiche annonce 125 milliards de paramètres. Les poids en contiennent 180 milliards. L'écart tient dans une énorme table de correspondance - les plongements de n-grammes, exactement 20 000 000 de lignes de 2 560 nombres chacune, 51,2 milliards de paramètres et 47,7 Gio même après que tous les quantificateurs en circulation s'y sont essayés, et pas un seul ne l'a comprimée sous les 8 bits. Elle représente 38 % du fichier. Ajoutez la tête de brouillon et la tour de vision, elles aussi comptées hors du chiffre annoncé, et 125 milliards deviennent 180 milliards.

Une table de correspondance n'est pas une multiplication de matrices. Produire un token touche 16 de ces 20 000 000 de lignes, environ 2,5 Ko. Elle n'a donc pas besoin d'être en mémoire du tout : elle peut rester sur le SSD et être lue au besoin. Quelqu'un l'avait déjà fait - un projet public qui corrige le moteur officiel pour projeter la table en mémoire depuis le disque - et avec lui les poids résidents tombent à 78,2 Gio et le modèle tourne sur une seule machine, seul.

Ce qu'il a fallu pour le faire tourner tout court

6 correctifs par-dessus l'image officielle, aucun de nous : la table projetée en mémoire, deux corrections pour les noyaux d'attention linéaire sur cette puce précise, une protection contre une course à la copie d'état, une correction du cache de préfixes qui restaurait silencieusement un état entièrement nul à chaque succès de cache, et le remplacement d'un noyau d'attention creuse qui renvoie des réponses différentes à la même question. Le moteur lui-même n'est pas une version publiée - c'est une compilation issue d'une branche, parce que l'architecture est trop récente pour figurer dans une version publiée, y compris celle que nous épinglons.

Il ne peut pas non plus partager la machine. Notre point d'accès fait normalement tourner 4 services à la fois : le modèle de codage, 2 modèles de plongement et un reclasseur. Qwen3.8-Flash-Next prend la machine entière. Chaque mesure ci-dessous a été prise avec le reste de l'inférence du produit à l'arrêt.

Le débit

Nous avons lancé le même banc d'essai que sur tout le reste, sans le modifier : la même consigne, les mêmes 20 secondes de mise en train et 40 secondes de fenêtre de mesure, les mêmes compteurs lus depuis le moteur lui-même.

Entre 2,8 et 3,4 fois plus lent à tous les niveaux de simultanéité, 3,7 fois plus lent à lire une consigne, et tenant 1,7 conversation de pleine longueur à la fois là où le modèle que nous servons en tient 7,0. Ce qui rend le résultat pire qu'il n'y paraît, c'est le handicap : Qwen3.8-Flash-Next tournait avec du décodage spéculatif - une tête de brouillon intégrée à ses propres poids, acceptant 51 % de ses suppositions et livrant 2,02 tokens par étape - sur le noyau rapide de cette puce. Le modèle qui l'a battu ne dispose d'aucun modèle brouillon et tourne sur un noyau de repli que nous n'avons jamais réussi à remplacer.

La note de codage

50 problèmes de codage, les mêmes 50 sur lesquels nous notons chaque modèle, exécutés à l'identique : mêmes problèmes, même budget, mêmes réglages, un modèle après l'autre sur la même machine.

La première chose que l'essai mesure n'est pas la qualité, c'est la longueur. Flash-Next est un modèle de raisonnement et il écrit 16 751 tokens sortants par problème, contre 4 738 pour le modèle que nous servons. Notre budget était de 32 768 tokens, et il a dépassé ce plafond sur 10 des 50 problèmes - coupé en pleine réponse, avec zéro à chaque fois. Ce ne sont pas de mauvaises réponses : l'ensemble comparable est donc celui des 40 qu'il a terminés dans le budget.

Sur ces 40, c'est lui qui arrive en tête : 29 résolus, contre 27 pour le modèle que nous servons et 26 pour celui d'avant. C'est le même ordre que les palmarès publics, et aucun des deux écarts n'est statistiquement significatif - détecter l'écart de 11,5 points annoncé par les palmarès demanderait environ 88 problèmes appariés. À lire comme compatible avec l'hypothèse que Flash-Next code mieux, et comme un échantillon trop petit pour la démontrer.

Le taux de dépassement est un résultat à part entière, et sans doute celui qui vous concernera le plus : 20 % des problèmes de codage ordinaires demandent à ce modèle plus de 32 768 tokens. Quel que soit le budget que vous fixez, il l'atteindra plus souvent que les modèles dont vous avez l'habitude, et une réponse tronquée est pire qu'une réponse lente.

Ce que l'on attend vraiment

Le bavardage n'est pourtant pas un artefact de notre banc d'essai. C'est le produit.

3,5x les tokens, au tiers de la vitesse, cela fait 10x l'attente. Soixante-seize secondes deviennent 13 minutes, pour une réponse au mieux meilleure d'1 problème sur 40 et le plus souvent identique. Et un modèle qui dépasse un budget de 32 768 tokens sur un cinquième des problèmes de codage ordinaires le fera aussi à un client payant, pas seulement à notre banc d'essai - une réponse tronquée est pire qu'une réponse lente.

La réserve honnête

40 problèmes ne peuvent pas trancher si un modèle écrit du code 10 % mieux qu'un autre, et nous n'affirmons pas que Qwen3.8-Flash-Next est moins bon. Nous pensons qu'il est probablement meilleur. Ce que nous avons mesuré, c'est que sur ce matériel son avantage est hors d'atteinte : il arrive dix fois plus tard, dans le quart des conversations parallèles, sur un moteur compilé depuis une branche, sans rien d'autre qui tourne sur la machine.

Une autre machine change entièrement cette réponse. 2 de ces machines, ou une avec plus de mémoire, et la table reste en mémoire, le modèle ne partage le matériel avec rien, et la comparaison devient un combat loyal qu'il pourrait fort bien gagner. 3 des modèles que nous avons écartés ce mois-ci l'ont été pour la même raison, ce qui n'est pas vraiment un fait au sujet des modèles.

Ce qui nous ferait changer d'avis

• Une table quantifiée. Personne n'a comprimé les plongements de n-grammes sous les 8 bits, y compris ceux qui ont quantifié tout le reste à 4. À 4 bits, le fichier perd 23,8 Gio et reste en mémoire.
• Un chemin d'attention linéaire quantifié. 43 % de ce que le modèle lit par token, ce sont des projections que toutes les versions publiées laissent en pleine largeur. Les diviser par deux double à peu près le plafond.
• L'architecture dans un moteur publié. L'architecture n'est disponible que sur une branche et nécessite un correctif de noyau que le projet principal n'a pas intégré pour cette puce. Une version officielle permettrait de remplacer notre assemblage de correctifs par une version standard.
• Une deuxième machine. La configuration qu'utilisent tous ceux qui font tourner ce modèle avec succès.

En attendant l'un de ces changements, le point d'accès de codage continue de faire tourner un modèle plus petit, plus ancien et moins bien classé, qui répond en 76 secondes et tient 7 conversations à la fois. Tout ce qui précède est reproductible depuis notre dépôt d'infrastructure : la présélection et son arithmétique, le script de banc d'essai, et la configuration d'évaluation.

Pendant quatre jours, CARouter Cloud a servi Qwen3.8 27B, et les trois billets qui précèdent racontent comment nous l'avons accéléré : un meilleur modèle brouillon, puis de meilleurs réglages pour ce brouillon, qui ensemble l'ont fait passer de 20,8 à 34,8 tokens par seconde et par flux. Cela n'a pas suffi. Un modèle dense de 27B sur une machine offrant 273 Go/s de bande passante mémoire doit lire ses 23,4 Go au complet pour produire un seul token, et aucun réglage ne change cette arithmétique. Depuis aujourd'hui, le point d'accès de codage fait tourner Qwen3.6 35B-A3B à la place - un modèle plus ancien, moins bien classé sur les palmarès publics de codage, et plus gros : 35B contre 27B. Il est aussi une fois et demie à deux fois plus rapide sur tout ce que nous avons mesuré, et nous n'avons pas réussi à trouver la qualité que nous étions censés y perdre.

Le billet précédent : régler le décodage spéculatif sur la même machine, des réponses de codage deux tiers plus rapides.

En bref

• Le problème. Un modèle dense lit chacun de ses paramètres pour chaque token qu'il écrit. Sur les 273 Go/s du GB10, cela imposait à Qwen3.8 27B un plafond d'environ 12 tokens par seconde avant toute spéculation, et la conséquence concrète était l'attente : sur une plateforme agentique automatisée, une compilation de codage ordinaire prenait une heure.
• La solution, qui semble absurde. Un modèle plus gros. Qwen3.6 35B-A3B compte 35B de paramètres mais n'en active que 3B par token : il lit donc 2,0 Go par passe avant plutôt que 23,4. Il occupe les mêmes 21,8 Gio sur disque.
• Le débit. 62,2 tokens par seconde en flux unique contre 34,8, et 367 contre 241 avec seize flux simultanés - de 1,5x à 1,9x à chaque niveau de concurrence mesuré. Le préremplissage est 3,2x plus rapide : environ 6 600 tokens par seconde contre 2 088 sur une invite de 12K. La compilation qui prenait une heure en prend dix minutes.
• Les sessions simultanées. À partir du même budget KV de 36 Gio, il retient 1 837 064 tokens contre 813 427 - 7,0 sessions complètes de 262K tokens à la fois contre 3,1. Seules 10 de ses 40 couches conservent un cache qui grandit avec la conversation ; les 30 autres gardent une taille constante.
• La qualité que nous pensions perdre. Les palmarès publics le placent une dizaine de points derrière sur LiveCodeBench v6. Sur les cinquante problèmes BigCodeBench que nous exécutons nous-mêmes, appariés sur les mêmes problèmes et la même machine, il obtient 33/50 contre 32/50 pour le 27B - un écart d'un seul problème, avec un p exact de McNemar de 1,000. Sur la récupération en contexte long, il fait mieux : 10/10 contre 9/10, et 10/10 contre 8/10 à 220K tokens.
• La réserve honnête. Cinquante problèmes ne peuvent pas détecter un écart de dix points ; il en faudrait environ 218. L'affirmation n'est donc pas que les deux modèles sont aussi intelligents l'un que l'autre - c'est que nous avons cherché la différence sur notre propre charge de travail sans la trouver, alors que l'écart de vitesse était impossible à manquer.

Pourquoi un modèle dense finit par plafonner

Générer un token consiste à lire les poids du modèle en mémoire et à multiplier. Pour un modèle dense, c'est la totalité des poids, à chaque fois. Qwen3.8 27B en NVFP4 en représente 23,4 Go, et le GB10 déplace environ 273 Go/s : au mieux, il peut donc écrire 273 divisé par 23,4 - environ 12 tokens par seconde. Tout ce que les deux billets précédents ont obtenu, c'est du décodage spéculatif qui contourne ce chiffre sans le changer : un modèle brouillon devine plusieurs tokens d'avance, le gros modèle les vérifie en une passe, et ceux qui sont acceptés sortent d'un coup. Cela nous a menés à 34,8 tokens par seconde, soit environ trois tokens acceptés par étape à 12 par seconde.

Un modèle épars à mélange d'experts casse l'arithmétique au lieu de la contourner. Qwen3.6 35B-A3B contient 256 experts et achemine chaque token vers 8 d'entre eux : bien que les 35B de paramètres résident tous en mémoire, seuls 3B environ sont lus par passe avant - 2,0 Go au lieu de 23,4. Le plafond passe de 12 tokens par seconde à environ 140. Le modèle est plus gros et le fichier sur disque fait la même taille ; ce qui change, c'est la quantité qu'il faut toucher pour produire un mot.

Ce que nous avons mesuré

Les deux modèles sur la même machine, le même budget KV de 36 Gio, la même limite de 16 séquences, l'un remplacé par l'autre puisqu'ils ne tiennent pas ensemble. Décodage agrégé selon le nombre de flux simultanés :

Deux détails font que ce graphique sous-estime le résultat. Le 35B-A3B tournait sans aucun décodage spéculatif, alors que le 27B disposait du brouillon DFlash2 à sept tokens livré dans le billet précédent, qui obtient environ 3,9 tokens acceptés par étape. Et ses experts tournaient sur le noyau Marlin de vLLM, qui décompresse les poids 4 bits et les multiplie en 16 bits, là où le 27B bénéficie du chemin CUTLASS de FlashInfer. Ce second point tient au checkpoint et non à la machine : NVIDIA quantifie ce modèle en W4A16, des poids sur quatre bits contre des activations sur seize, et les noyaux CUTLASS veulent aussi les activations en FP4, accompagnées de facteurs de calibration qu'un checkpoint W4A16 ne porte jamais. Ce sont donc des planchers sur les deux plans.

La mémoire est l'autre moitié, et sur une machine à mémoire partagée c'est celle qui détermine combien de personnes vous pouvez servir à la fois :

Le nombre de sessions simultanées provient du journal de démarrage du moteur lui-même : 1 837 064 tokens en cache contre 813 427 à budget identique. La raison est architecturale. Seules 10 des 40 couches du 35B-A3B utilisent le type d'attention dont le cache grandit avec la longueur de la conversation ; les 30 autres sont des couches à attention linéaire qui gardent un état de taille fixe par session, quelle que soit sa durée. Le 27B dense conserve un cache croissant sur 16 de ses 64 couches, et chacune coûte davantage par token. Deux fois plus de sessions, à mémoire égale, n'est pas un gain de réglage - c'est ce que donne la disposition des couches.

La partie qui devait faire mal

Qwen3.6 appartient à une génération antérieure à Qwen3.8, et les évaluations de codage publiées le disent : LiveCodeBench v6 place le modèle épars à 80,4 contre 90,3 pour le modèle dense. Dix points ne sont pas une erreur d'arrondi, et nous ne voulions pas le découvrir en production.

Nous avons donc soumis les deux modèles aux mêmes cinquante problèmes BigCodeBench, sur la même machine, dans le même bac à sable Docker, sans plafond de tokens et avec des réglages identiques. Puis nous avons fait ce que nous aurions dû faire plus tôt : remesurer le 27B au lieu de nous fier à son score d'il y a quatre jours. Cet ancien chiffre avait été obtenu avec un autre brouillon, une autre version de vLLM, et lors d'une exécution que le bogue de délai d'attente de l'outil d'évaluation avait morcelée et relancée. Réexécuté proprement, le modèle dense obtient 32/50 là où il obtenait 33/50 auparavant.

Appariés sur les mêmes cinquante problèmes, les deux modèles s'accordent sur 43 d'entre eux - 29 résolus par les deux, 14 échoués par les deux. Le modèle épars en résout quatre à lui seul, le dense trois, et un test exact de McNemar sur ces sept désaccords donne un p bilatéral de 1,000. C'est le résultat le plus plat qu'un test apparié puisse produire.

La récupération en contexte long est allée exactement dans l'autre sens. Nous cachons un fait dans une botte de foin allant jusqu'à 220 000 tokens et demandons au modèle de le retrouver, à trois profondeurs pour chacune des quatre longueurs. Le modèle dense obtient 9 sur 10 au total et descend à 8 à la longueur maximale. Le modèle épars obtient 10 sur 10, à chaque longueur et à chaque profondeur. C'était le résultat le plus susceptible de le disqualifier - nous vendons un contexte de 262 144 tokens, et un modèle qui répond vite mais perd le fil au fond d'un long fichier serait une régression qu'aucun score de codage ne révélerait - et c'est celui qui est revenu le plus solide.

Il atteint aussi le même score avec beaucoup moins de mots : 236 949 tokens sortants pour les cinquante problèmes contre 558 275, avec un échantillon médian de 4 773 tokens contre 9 142. Le modèle dense a atteint notre plafond de 32 768 tokens sur au moins un problème ; le modèle épars n'a jamais dépassé 12 253. Les deux modèles raisonnaient - l'épars a enregistré 219 951 tokens de raisonnement sur les cinquante échantillons - il s'agit donc de concision et non d'un mode de réflexion resté désactivé. Pour un point d'accès facturé au token et qui conserve un contexte par session, arriver à la même réponse en moins de la moitié des mots vaut autant que les tokens par seconde.

Ce que nous ne pouvons pas vous dire

Cinquante problèmes ne suffisent pas à détecter une différence de dix points. Détecter un effet aussi faible avec une puissance de 80 % exige environ 218 problèmes appariés, et les exécuter coûte une journée de machine pendant laquelle le point d'accès ne sert personne. Notre résultat ne réfute donc pas le palmarès ; il signifie que sur la seule évaluation de codage que nous exécutons nous-mêmes, les deux modèles étant mesurés la même semaine sur le même matériel, nous n'avons pas trouvé l'écart.

Nous n'avons par ailleurs mesuré que le codage et la récupération en contexte long, rien d'autre. Le raisonnement général, le suivi d'instructions et le comportement agentique multitour ne sont pas testés ici, et les écarts publiés sur ces plans sont peut-être bien réels. Ce que nous pouvons dire, c'est que sur une plateforme agentique automatisée qui exécute de longues compilations autonomes, plusieurs tâches de codage simples qui prenaient une heure sur le modèle dense se terminent en une dizaine de minutes sur celui-ci, sans baisse de qualité visible dans le résultat.

La forme honnête de la décision est celle-ci : nous avons échangé une différence que nous ne pouvions pas mesurer contre une différence que nous ne pouvions pas manquer. Une requête qui attend en file, ou qui défile à demi-vitesse, est un moins bon résultat pour la personne qui attend qu'une réponse légèrement plus faible arrivée rapidement - et un modèle trop lent pour répondre à la demande ne vaut rien du tout pour les requêtes qu'il refuse.

Ce qui tourne maintenant

Qwen3.6 35B-A3B en NVFP4, sur le même GB10 derrière le même proxy TLS, au même prix : 0,20 $ par million de tokens entrants et 0,80 $ par million en sortie. Il répond au nom qwen3.6-35b-a3b, conserve le contexte complet de 262 144 tokens, lit les images, appelle les outils et renvoie son raisonnement. Qwen3.8 27B est retiré du catalogue et, comme il n'était servi que depuis notre propre matériel, il disparaît simplement au lieu d'être acheminé ailleurs.

Son fichier de configuration reste dans le dépôt, et revenir en arrière tient en une ligne. Deux chantiers restent ouverts, et nous nous étions trompés sur les deux à la parution de ce billet. Le modèle brouillon n'a besoin d'être publié par personne : ce checkpoint porte déjà une tête de prédiction multi-tokens, une couche d'attention et d'experts entraînée à deviner le token d'après, inutilisée dans des poids que nous avions déjà téléchargés. Et le noyau ne consiste pas à réclamer CUTLASS, qu'aucun checkpoint W4A16 ne peut utiliser ; il faudrait soit une version de ce modèle quantifiée pour des activations FP4, soit le noyau SM12x fusionné de vLLM, écrit précisément pour cette puce et simplement jamais retenu automatiquement. Ce sont des mesures que nous vous devons et non des gains que nous pouvons revendiquer, et tous les chiffres ci-dessus ont été mesurés sans l'un ni l'autre.

Le décodage spéculatif fait deviner à un petit modèle « brouillon » plusieurs tokens d'avance, pour que le gros puisse tous les vérifier en une seule passe et garder ceux avec lesquels il est d'accord. Quelles suppositions le brouillon fait, et comment elles sont vérifiées, se révèlent être deux réglages que nous avions laissés à leur valeur par défaut. Les changer - deux clés dans un fichier de configuration, aucun matériel neuf, aucun changement à ce que le modèle écrit - a fait passer le point d'accès de code de notre machine auto-hébergée de 20,8 à 34,8 tokens par seconde et par flux : deux tiers plus vite que le prédicteur intégré au modèle, et 22 % plus vite que ce que nous avions déployé la semaine dernière. Voici ce que fait chaque réglage, pourquoi chacun est une perte tout seul, et la conclusion de la semaine dernière que les deux ensemble ont renversée.

L'article précédent : MTP contre DFlash2 sur le DGX Spark de CARouter, 35 % de tokens en plus par étape, et non une étape plus rapide.

En bref

• Ce que voit un client. Le point d'accès de code écrit une réponse deux tiers plus vite qu'avant tout ce réglage : un token toutes les 29 ms au lieu de 48, une réponse typique de 460 tokens en 13 secondes environ au lieu de 22. Rien ne change dans les réponses elles-mêmes.
• Le réglage efficace. draft_sample_method: "probabilistic" fait échantillonner le brouillon dans sa propre distribution à la température de la requête, secoué par le même bruit aléatoire que l'échantillonnage du gros modèle, au lieu de toujours prendre sa meilleure supposition. Le test d'acceptation compare alors deux vraies distributions au lieu de lire une probabilité sur une certitude.
• Les deux réglages doivent être combinés. La vérification par bloc, la règle d'acceptation sans perte que nous recommandions à la fin du dernier article, perd toute seule : 22 % de moins à deux flux et 11 % de moins à huit, à la température que les clients obtiennent par défaut. Le brouillon probabiliste seul gagne à partir de deux flux et abandonne un dixième du décodage à flux unique, qui est exactement là où se trouve un agent de code. Ensemble, ils se couvrent l'un l'autre.
• Notre erreur nous a aussi appris quelque chose. La semaine dernière, nous avons mesuré les suppositions les plus profondes du brouillon, constaté qu'elles ne se rentabilisaient pas, et déployé un bloc raccourci. C'était vrai du réglage par défaut, dont nous n'avions pas remarqué qu'il était une prémisse.
• La longueur de bloc optimale a donc changé. Le brouillon échantillonné de façon probabiliste, nous avons relancé le balayage des longueurs de bloc sur quatre, cinq, six et sept. Le bloc natif de sept tokens du brouillon l'a emporté : 34,8 tokens/s à flux unique contre 29,3 pour le bloc de cinq, et 28,6 contre 24,7 à la température que les clients obtiennent par défaut.
• Le coût. Rien de mesurable. La distribution mise en cache du brouillon pèse environ 106 Mio, absorbés ; le chargement des poids est inchangé à 24,92 Gio ; le budget de cache cède 3 % au cache du bloc plus profond ; le traitement du prompt ne bouge pas.

Ce que nous avons dit la semaine dernière, et pourquoi c'était conditionnel

Le balayage de la semaine dernière a trouvé que les positions quatre à sept du bloc natif du brouillon étaient acceptées 28 %, 22 %, 15 % et 12 % du temps. Ces quatre positions ajoutaient 0,77 token accepté par étape, ce qui est gratuit à un ou deux flux et du vrai travail à seize ; raccourcir le bloc à cinq gardait donc le gain à flux unique et rendait le régime par lots positif à toutes les tailles. Nous avons écrit « un cinq statique fait l'affaire sur cette machine » et l'avons déployé.

Relisez cela avec une semaine de recul. Chaque chiffre y est un chiffre d'acceptation, et l'acceptation n'est pas une propriété de la machine, ni du modèle, ni de la charge de travail seule. C'est une propriété de la façon dont le brouillon est produit et vérifié. Nous avons mesuré une seule règle de brouillon - prendre la meilleure supposition, à chaque fois - et tiré une conclusion sur la profondeur du bloc comme si profondeur et brouillon étaient indépendants. Ils ne le sont pas, et c'est la partie de tout l'exercice qui se généralise : chaque fois que la règle de brouillon change, la question de la profondeur doit être reposée.

Le réglage : échantillonner le brouillon comme le modèle échantillonne

La configuration spéculative de vLLM a une clé que nous avions écartée. draft_sample_method vaut "greedy" par défaut : le brouillon propose son unique continuation la plus probable, et le test d'acceptation traite cette proposition comme une certitude - probabilité un sur le token choisi, zéro partout ailleurs. Mettez-la à "probabilistic" et deux choses changent.

La première est dans le brouillon. Le sélecteur de DFlash2 parcourt un faisceau de seize candidats par position ; en mode par défaut il prend celui au meilleur score, et en mode probabiliste il échantillonne parmi eux à la température propre à la requête. Le noyau qui fait cela porte un commentaire qui mérite d'être cité, parce qu'il contient toute l'idée en une ligne : « Les identifiants des candidats indexent le bruit, en accord avec l'échantillonnage du modèle cible. » Le brouillon et le gros modèle sont secoués par le même bruit aléatoire, si bien que lorsque le gros modèle échantillonne de façon stochastique, le brouillon tend à faire le même choix stochastique.

La seconde est dans le vérificateur. Avec une vraie distribution derrière lui, les scores du brouillon sont mis en cache et le test d'acceptation devient le véritable rapport entre la probabilité du gros modèle et celle du brouillon, au lieu d'une probabilité lue sur une certitude. C'est ce qui donne un sens au second réglage - la vérification par bloc.

Nous avions écrit dans nos propres notes que cette option s'appliquait à la tête intégrée de Qwen et non à ce brouillon. C'était faux, et c'est la lecture du code qui l'a corrigé : le spéculateur DFlash2 redéfinit précisément la méthode qui alloue le cache dont ce mode a besoin, justement pour qu'il fonctionne avec lui.

Constat 1 : le réglage sans perte recommandé ralentit le décodage lorsqu'il est utilisé seul

La dernière phrase de la semaine dernière désignait la vérification par bloc comme le levier suivant : une règle d'acceptation sans perte qui vérifie tout le bloc brouillonné d'un coup plutôt qu'un token à la fois. Elle existe bel et bien, elle fonctionne avec ce brouillon, et elle ne coûte pas de mémoire - le démarrage affiche le même chargement de poids et la même taille de cache. Elle perd aussi. À température 0,7 elle tombe partout dans la dispersion existante, ce que la théorie prédit : la vérification par bloc est démontrablement identique à la règle ordinaire quand rien n'est tiré au hasard, et une sonde de code à 0,7 en est proche. À température 1,0, là où le gain était censé se trouver, elle donne 37,8 tokens/s à deux flux contre 48,7 et 120,1 à huit contre 134,7 - et ce chiffre à huit flux est de trois exécutions à moins de 2,2 tokens/s les unes des autres, ce n'est donc pas du bruit. L'acceptation n'a jamais augmenté.

La raison est celle que pose la section précédente. Un brouillon qui prend sa meilleure supposition est une certitude ; la règle conjointe n'a donc presque rien de plus à exploiter que ce que la règle token par token obtenait déjà, tandis que son arithmétique supplémentaire est facturée à chaque étape et mord dès que le lot s'élargit. Une règle sans perte n'est pas automatiquement une règle gratuite.

Constat 2 : le brouillon probabiliste gagne par lots et perd là où se trouve l'agent

Échantillonné de façon probabiliste au bloc de cinq tokens, le décodage est de 25,7, 57,1, 101,2, 163,5 et 246,0 tokens/s à un, deux, quatre, huit et seize flux, contre 28,5, 47,5, 91,4, 137,4 et 216,1 pour le même bloc au réglage par défaut. À partir de deux flux, cela fait +20 %, +11 %, +19 % et +14 %, et l'acceptation monte avec - de 3,0 à 3,9 tokens par étape là où le brouillon au meilleur choix atteignait 2,7 à 3,0. À un flux il abandonne un dixième, et un flux est précisément là où se trouve un agent de code.

À la température que les clients obtiennent par défaut, le tableau s'inverse : le flux unique passe à 26,0 contre 21,0, soit +24 %, parce que coupler le hasard du brouillon à celui du gros modèle compte le plus précisément là où le gros modèle est le plus aléatoire. Un réglage qui vaut +24 % ou -10 % à flux unique selon un paramètre que le client contrôle n'est pas un réglage qu'on déploie seul.

Constat 3 : combiner les réglages change la longueur de bloc optimale

Ajouter la vérification par bloc par-dessus le brouillon probabiliste répare la case à flux unique - 29,3 tokens/s contre 25,7 - parce qu'il existe désormais une vraie distribution de brouillon sur laquelle la règle conjointe peut travailler. Cette combinaison n'a aucune case mesurée sous la règle ordinaire, à l'une ou l'autre température ; son pire cas est -2 %. Nous avons donc relancé le balayage des longueurs de bloc avec elle, pendant la nuit, quatre longueurs à deux températures, les cases bruitées répétées trois fois.

Sept - le bloc que le brouillon a été entraîné à prédire, et celui que nous avions rejeté il y a une semaine - gagne 19 % à flux unique à température 0,7 et 16 % à 1,0, et 9 % et 12 % à deux flux, pour 2 à 5 % rendus à quatre et seize. Comme notre plateforme fait tourner un ou deux agents à la fois, c'est l'arbitrage que nous voulons, et c'est le même que celui de la semaine dernière quand nous avons choisi cinq plutôt que quatre.

La preuve convaincante n'est pas le débit, bruité sur cette machine, mais l'acceptation : de 3,85 à 4,83 tokens par étape à sept contre 3,18 à 3,92 à cinq, six se plaçant entre les deux et quatre sous les deux. Un ordre net dans le sens que le mécanisme prédit vaut plus que n'importe quelle exécution rapide isolée.

Constat 4 : une exécution n'est pas une mesure, et cela a failli nous coûter cher

Le brouillon probabiliste seul a produit 178,5 tokens/s à huit flux - sa meilleure case, et 13 % devant la combinaison que nous allions déployer. Nous l'avons signalée dans la demande de fusion comme une exécution unique, donc non fiable, et l'avons remesurée pendant la nuit : 161,8, 167,8, 160,9, soit une moyenne de 163,5. Le 178,5 était une valeur aberrante, l'écart réel est d'environ 4 %, et la décision qu'elle aurait renversée était la bonne.

Nous le consignons parce que c'est la deuxième fois en deux articles que la variance de cette machine a failli écrire la mauvaise conclusion, et parce que la discipline qui l'a rattrapée est peu coûteuse : indiquer le nombre d'exécutions à côté de chaque chiffre, et remesurer tout ce qui changerait une décision à soi seul.

Ce que cela signifie pour nos clients

• Les réponses s'écrivent deux tiers plus vite qu'avant tout ce réglage. À flux unique et à température 0,7, les tokens arrivent toutes les 29 ms, contre 35 ms après le changement de la semaine dernière et 48 ms avec le prédicteur intégré au modèle. La réponse moyenne sur notre trafic fait environ 460 tokens : à peu près 13 secondes, contre 16 la semaine dernière et 22 auparavant.
• À la température par défaut, le gain est plus grand que celui de la semaine dernière, pas plus petit. Un client qui ne règle rien obtient 28,6 tokens/s là où la configuration de la semaine dernière en donnait 21,0. C'est le cas que ce changement aide le plus, et c'est le plus fréquent.
• Une machine chargée partage désormais le gain correctement. Avec quatre à seize agents qui décodent en même temps, chacun obtient 19 à 31 % de plus que la tête intégrée, là où le bloc de la semaine dernière donnait 7 à 13 %.
• Le premier token arrive toujours au même moment. Le décodage spéculatif ne touche pas au traitement du prompt, et celui-ci n'a pas bougé : environ 2 000 tokens/s tout du long.
• Régler une température rapporte toujours plus que ce que nous pouvons vous donner. Un client qui envoie 0,7 pour du code au lieu de laisser la valeur par défaut de 1,0 obtient environ 22 % de décodage en plus, contre les 10 % que nous annoncions la semaine dernière.
• Le code est inchangé, par construction. Le décodage spéculatif accepte exactement les tokens que le gros modèle aurait produits de toute façon - voyez toutefois la première réserve ci-dessous, qui porte sur la qualité de notre vérification plutôt que sur la véracité du principe.

Ce que cela coûte, et ce que nous avons déployé

La distribution mise en cache du brouillon pèse environ 106 Mio, absorbés sans rien changer d'autre : le même chargement de poids de 24,92 Gio, le même démarrage à froid de sept minutes. Le bloc plus profond taille davantage dans le budget de cache de 36 Gio pour son propre usage, si bien que le budget tient 813 427 tokens au lieu de 838 501 - 3,10 contextes de 262K simultanés au lieu de 3,20, une réduction de 3 %. Le traitement du prompt est inchangé.

Déployé : Qwen3.8-27B NVFP4 avec un brouillon DFlash2 de sept tokens, draft_sample_method "probabilistic" et rejection_sample_method "block", sur la même image vLLM 0.28.0, même proxy, même nom servi, même contexte de 262K. Les deux réglages vont ensemble dans la spécification, avec un commentaire qui le dit, parce que l'un ou l'autre pris seul est une régression quelque part.

Les réserves honnêtes

• Nous n'avons pas vérifié empiriquement l'absence de perte. Le décodage spéculatif accepte exactement les tokens que le gros modèle aurait produits - c'est une propriété de la construction, et c'est pourquoi nous répétons que la qualité est intacte. Mais nous avons changé le chemin d'échantillonnage et n'avons confirmé que le bon fonctionnement du chat, des appels d'outils, de l'entrée image et du raisonnement, pas que la distribution de la sortie soit inchangée. L'exécution de référence qui l'aurait vérifié a échoué sur un bogue de notre propre outil d'évaluation, qui écrasait les réglages par tâche sur toutes les tâches d'une exécution multitâche ; c'est corrigé, et la vérification reste due.
• Les mesures à flux unique varient beaucoup. Les trois exécutions derrière les 34,8 du bloc en service étaient 39,7, 33,1 et 31,5. Chaque chiffre ici est une moyenne accompagnée de son nombre d'exécutions, et les cases par lots comptent deux à trois exécutions là où celles de la semaine dernière n'en avaient souvent qu'une.
• Une machine, une sonde, une nuit. Même GB10, même checkpoint, même sonde de génération de code que dans les deux articles précédents, chaque configuration faisant l'objet d'un redémarrage distinct.
• Le modèle brouillon n'est toujours pas adapté aux poids utilisés. DFlash2 a été entraîné sur les poids bf16 de Qwen ; nous servons une quantification NVFP4 communautaire, et le brouillon lit des états internes que la quantification perturbe. Une partie de la dispersion à flux unique vient probablement de là. Un brouillon entraîné sur la cible quantifiée reste l'expérience que nous n'avons pas faite, et c'est désormais le seul levier restant que nous connaissions.

Ce que nous avons appris et qui survivra aux chiffres

Deux choses, et aucune ne porte sur cette machine.

La première : un résultat de réglage peut porter une prémisse que vous n'avez pas écrite. « Sept, c'est trop profond » était un fait sur un réglage de brouillon déguisé en fait sur le matériel. Il a survécu une semaine parce que rien dans notre façon de le consigner ne rendait la prémisse visible, et le remède n'est pas de mesurer davantage mais de nommer les conditions dont un chiffre dépend au moment où on l'écrit.

La seconde : « sans perte » et « gratuit » sont deux mots différents. La vérification par bloc ne change rien à ce que le modèle produit et nous a tout de même coûté 11 % à huit flux, parce qu'une garantie de correction ne dit rien du coût de calcul de cette garantie. L'estimation que nous avons ratée la semaine dernière chiffrait un brouillon en divisant ses octets par la bande passante ; l'estimation que nous aurions ratée cette semaine chiffrait une règle d'acceptation en lisant sa démonstration.

CARouter Cloud est la partie de CARouter que nous hébergeons nous-mêmes : un ASUS Ascent GX10 (une machine de classe NVIDIA GB10 « DGX Spark », 128 Go de mémoire unifiée, arm64) qui fait tourner vLLM derrière un proxy TLS et sert deux modèles de plongements et, depuis l'article précédent, Qwen3.8-27B comme modèle de codage. Cet article-là se terminait sur un constat de mémoire. Celui-ci parle de vitesse, et il commence par une coïncidence : le 26 août 2026, une infolettre de ByteByteGo intitulée « How to Make LLMs 3X Faster », une bonne explication du décodage spéculatif, arrivait dans la boîte de réception, et le même matin vLLM 0.28.0 était publié avec le seul brouillon que notre modèle ne pouvait pas encore utiliser. Nous avons donc confronté l'article à la machine ligne par ligne, puis mené l'expérience qu'il venait de rendre possible. Voici ce qui s'est amélioré, ce qui ne l'a pas fait, et ce que vaut un titre en « 3× » sur de la mémoire unifiée.

L'article précédent : Laguna S 2.1 contre Qwen3.8-27B sur le DGX Spark de CARouter, la vitesse a perdu contre la mémoire.

En bref

• Déjà en place. Qwen3.8-27B appliquait déjà la technique de l'article : sa tête de prédiction multi-tokens (MTP) intégrée, passée trois fois, plaçait 2,76 tokens par pas sur le trafic de production - 75 %, 57 % et 44 % aux trois positions, lus dans 22 heures de requêtes de notre plateforme elle-même.
• Le levier. La seule chose qui restait, c'était un meilleur brouillon. DFlash2, un brouillon à diffusion par blocs de cinq couches pour Qwen3.8-27B, exige vLLM 0.28.0; nous avons mis l'image à jour et mesuré MTP contre DFlash2 à 1, 2, 4, 8 et 16 flux simultanés, à trois longueurs de brouillon.
• Le résultat. Avec un bloc de cinq tokens, chaque pas du modèle cible rapporte 3,45 tokens acceptés contre 2,55 (+35 %), si bien que le décodage est à 28,5 tokens/s en flux unique contre 20,8 (+37 %), à 91 contre 81 à quatre flux, à 216 contre 203 à seize. Là où notre plateforme tourne réellement, un ou deux agents de codage à la fois, c'est un tiers de plus par flux.
• L'estimation que nous avons ratée. Nous avions prédit 1,6-2,4× parce que le nouveau brouillon lit 3,85 Go par passage. Le pas n'est pas devenu plus rapide du tout : 121 ms avant, 121 ms après. Chaque token gagné vient de plus de tokens acceptés par pas - 3,45 contre 2,55, +35 % - pas d'un pas plus rapide.
• Le coût. 3 Gio de poids, un cinquième du budget KV (3,2 contextes de 262K simultanés au lieu de 3,9), un démarrage à froid de sept minutes, et le nouvel exécuteur de modèle V2 de vLLM.
• En service. Qwen3.8-27B NVFP4 avec un brouillon DFlash2 de cinq tokens sur vLLM 0.28.0, les quatre conteneurs sur la nouvelle image. Le repli sur MTP tient en une ligne dans un fichier.

Ce que dit l'article, confronté à la machine

L'argument de l'article est le classique, et il est juste : générer un token, c'est lire chaque poids une fois pour une poignée d'arithmétique, si bien que le décodage est borné par la bande passante mémoire pendant que les unités de calcul chôment; un petit brouillon peut deviner plusieurs tokens d'avance, et le gros modèle peut tous les vérifier en un seul passage pour à peu près le prix d'un, en gardant les devinettes qui concordent. Le gain, c'est la longueur d'acceptation - combien de tokens du brouillon survivent par pas - et elle dépend de la charge de travail (le code et l'extraction acceptent bien, la prose ouverte non), de la température d'échantillonnage (plus haute, elle aplatit la distribution et abaisse l'acceptation) et de la charge (sous un gros lot, le calcul libre que l'astuce dépense n'est plus libre). L'article énumère quatre sources possibles pour un brouillon : un petit modèle séparé, des têtes de prédiction entraînées dans le gros modèle, une copie moins coûteuse du même modèle, et une recherche dans le texte déjà vu.

Nous avons passé cette liste en revue face à ce qui tournait. Les têtes de prédiction : c'est la tête MTP de Qwen, déjà active, et les compteurs de vLLM disaient ce qu'elle valait sur du vrai trafic - 208 647 tokens proposés, 122 270 acceptés, 2,76 tokens par pas du modèle cible. La recherche dans le texte existant (brouillon par n-grammes ou par suffixes) : vLLM n'exécute qu'un proposeur par moteur, elle remplacerait donc la tête MTP au lieu de s'y ajouter, et à 2,76 tokens par pas la tête est difficile à battre sur du code que le modèle doit écrire, par opposition à du code qu'il recopie. Un petit modèle séparé : un moins bon brouillon qu'une tête qui lit les états cachés du gros modèle lui-même, et il coûte de la mémoire. L'idée de la copie moins coûteuse (QuantSpec) : absente de vLLM. La falaise de charge : l'article dit que vLLM peut désactiver la spéculation au-delà d'une taille de lot, et c'est vrai - la forme moderne est un barème de longueurs de brouillon par taille de lot - mais sur cette machine un pas à notre plafond de 16 séquences porte au plus 64 tokens, et un 27B sur un GB10 est très loin d'être borné par le calcul en dessous d'un millier, si bien que nous n'avions aucune falaise contre laquelle nous protéger.

Ce que la vérification a fait ressortir, c'est la forme de notre trafic : 41 millions de tokens entrants pour 192 mille générés, 96 % des tokens entrants servis depuis le cache de préfixes, ce qui veut dire qu'une requête typique passe environ deux secondes sur les quatre mille tokens qu'elle doit préremplir et vingt-cinq sur les 460 qu'elle génère. Le décodage, c'est neuf dixièmes du temps. La spéculation est exactement le bon levier, et la seule chose qui restait à tirer, c'était le brouillon.

La seule chose qui restait : un meilleur brouillon

DFlash2 (z-lab, ICML 2026) est un brouillon entraîné pour Qwen3.8-27B : cinq petites couches de transformeur qui lisent les états cachés du gros modèle à cinq profondeurs et, au lieu de deviner un token à la fois, prédisent un bloc entier en un passage et laissent un petit sélecteur tracer un chemin parmi les candidats. Ses auteurs rapportent 5,5 tokens acceptés par pas sur GSM8K contre 5,0 pour la tête MTP à la même longueur de brouillon, et 3,4× par rapport au décodage simple. Il est livré comme un checkpoint de 3,85 Go et exige une architecture que vLLM a ajoutée dans la 0.28.0 - publiée, comme par hasard, ce matin-là.

Avant de le lancer, nous avons écrit l'estimation, comme la fois précédente. Notre pas MTP durait ~123 ms, dont les trois passages successifs de l'unique couche MTP comptaient, d'après l'arithmétique du balayage précédent, pour environ 20 ms chacun. DFlash2 les remplace par un passage sur 3,85 Go, soit environ 15 ms aux 273 Go/s de cette machine, et vérifier huit positions au lieu de quatre est presque gratuit sur un pas borné par la bande passante. Donc : un pas de ~100 ms, et si l'acceptation passait de 2,6 à quelque part entre 3,5 et 5, le décodage en flux unique irait de 18-20 tokens/s à 30-45. C'était la prédiction. Gardez-la en tête.

Ce que nous avons mesuré, et comment

Même sonde que dans l'article précédent, le script de mesure de notre dépôt d'infrastructure : N requêtes de génération de code simultanées à travers le proxy de production, le débit de décodage lu dans les compteurs de vLLM sur une fenêtre de 40 secondes, puis un nouveau préremplissage de 12K tokens. Deux ajouts cette fois. La sonde prend maintenant la température d'échantillonnage en paramètre, parce que le point de l'article sur la température méritait un chiffre : 0,7 est ce que tous les balayages ont utilisé jusqu'ici, 1,0 est la valeur par défaut du checkpoint et ce que notre plateforme envoie quand un client ne fixe rien. Et les points en flux unique ont été répétés, parce que les premiers chiffres de DFlash2 se dispersaient plus que prévu, et qu'une fenêtre de 40 secondes d'une seule génération n'est pas une mesure pour un brouillon dont l'acceptation dépend de ce que le modèle est en train d'écrire.

Chaque configuration est un redémarrage du même checkpoint servi (la quantification NVFP4 de Qwen3.8-27B par unsloth, 262K de contexte, 36 Gio de KV) sur la même machine, le même jour, l'une après l'autre.

Constat 1 : la mise à jour de l'image n'a rien changé, et le débit augmente encore à seize flux

vLLM 0.28.0 embarque la même pile CUDA 13.0.2, torch 2.13 et FlashInfer 0.6.16 que la 0.27.1, choisit le même noyau CUTLASS NVFP4 et la même attention FlashInfer sur ce silicium, et avec la tête MTP il décode à 20,8, 39,7, 81,2 et 124,4 tokens/s en agrégé à 1, 2, 4 et 8 flux là où la 0.27.1 faisait 19,8, 40,0, 74,9 et 127,4 - du bruit. Le préremplissage était à 2 007 tokens/s contre 2 083, une sonde chacun. La seule case nouvelle, c'est 16 flux : 202,7 tokens/s en agrégé, 1,63× le chiffre à huit flux. La falaise dont l'article nous prévient, où la spéculation se met à coûter plus qu'elle ne rapporte, n'est pas là à notre lot maximal.

Constat 2 : 35 % de tokens en plus par pas; le pas n'est pas devenu plus rapide

DFlash2 à son bloc natif de sept tokens de brouillon : 26,0, 52,3, 81,0, 135,2 et 192,6 tokens/s en agrégé à 1, 2, 4, 8 et 16 flux, contre 20,8, 39,7, 81,2, 124,4 et 202,7 pour MTP. En hausse de 25 % et 32 % à un et deux flux, à égalité à quatre, en hausse de 9 % à huit, et en baisse de 5 % à seize.

Puis le chiffre qui l'explique. À un flux, DFlash2 a accepté 3,16 tokens par pas et décodé 26,0 par seconde : un pas de 122 ms. MTP a accepté 2,55 et décodé 20,8 : un pas de 123 ms. Le pas est le même. Un passage d'un brouillon de cinq couches plus son sélecteur plus une vérification à huit positions coûte, sur cette machine, exactement ce que coûtent trois passages d'une seule couche MTP. Notre estimation avait tarifé le brouillon à sa bande passante, 3,85 Go en 15 ms, et oublié que le pas fait aussi tourner les couches Gated DeltaNet de Qwen sur huit positions de requête au lieu de quatre, le sélecteur, et une vérification qui n'est gratuite que tant que le lot vaut un. Tout ce que DFlash2 a gagné, il l'a gagné en acceptant plus de tokens par pas; il n'a rien gagné à être plus rapide par pas.

Et l'acceptation dit où le bloc devrait s'arrêter. Sur la sonde, DFlash2 place 75 %, 52 % et 36 % de ses trois premiers tokens, à peu près ce que la tête MTP place sur le trafic de production, puis 28 %, 22 %, 15 % et 12 % aux positions quatre à sept. Ces quatre positions ajoutent 0,77 token accepté par pas. À un ou deux flux, elles sont gratuites, parce que le pas est borné par la bande passante et que vérifier quatre positions de plus ne coûte aucun temps; à seize flux, une vérification de huit positions sur seize séquences, c'est 128 tokens de vrai travail par pas, et c'est ce qui a transformé +9 % à huit flux en −5 % à seize.

Constat 3 : cinq tokens par bloc donnent de meilleurs résultats que sept

Nous avons donc mesuré des blocs plus courts. À cinq tokens de brouillon : 28,5, 47,5, 91,4, 137,4 et 216,1 tokens/s sur les cinq niveaux de simultanéité, les points à un et deux flux moyennés sur deux passes chacun. À quatre : 23,0, 47,8, 94,2, 142,4 et 229,7. Les trois blocs DFlash2 et la tête MTP tournent tous au même pas de ~121 ms; ce qui diffère, c'est le rendement - 2,55 tokens pour MTP, 2,77 à quatre, 3,45 à cinq, 3,16 à sept, en flux unique - et ce que coûte la vérification une fois que le lot grossit. Cinq est le bloc qui gagne là où vit notre plateforme, un et deux agents de codage à la fois : +37 % sur MTP à un flux. Et il garde le gain à chaque taille de lot que nous pouvons atteindre, +13 % à quatre, +10 % à huit, +7 % à seize. Quatre le devance de 3 à 6 % à partir de quatre flux et perd un cinquième à un; sept ne gagne rien que cinq ne gagne pas.

Le bouton « raccourcir le brouillon quand la simultanéité monte » de l'article existe dans vLLM sous la forme d'un barème de longueurs de brouillon par taille de lot, et l'ordonnanceur le respecte; mais le spéculateur DFlash2 de la 0.28.0 produit un bloc de taille fixe, alors nous ne l'avons pas essayé à l'aveugle sur un moteur de production. Un cinq statique fait le travail sur cette machine.

Constat 4 : la température influe sur le débit, et le client la choisit

L'article dit qu'une température d'échantillonnage plus haute abaisse l'acceptation. C'est vrai, et ce n'est pas petit. À la température par défaut du checkpoint, 1,0, la tête MTP accepte 43 % au lieu de 52 % et le décodage en flux unique tombe de 20,8 à 18,5 tokens/s : 11 % pour un paramètre que la plupart des clients ne fixent jamais. DFlash2 à cette température, c'est là que la dispersion est apparue. Quatre passes en flux unique au bloc de sept tokens ont donné 32,5, 26,8, 21,3 et 17,1 tokens/s, une acceptation de 43 % jusqu'à 16 % sur la même famille d'invites, une moyenne de 24,4 et une pire passe sous les 18,5 de MTP; le bloc de cinq tokens a donné 19,8 et 22,1, le bloc de quatre 22,3 et 20,3. MTP, dont la tête est plus stable, se disperse entre 18 et 21 sur trois jours de mesures. L'acceptation d'un brouillon par blocs dépend de ce que le modèle se trouve écrire dans la fenêtre, et c'est pourquoi chaque chiffre de DFlash2 dans cet article est une moyenne avec sa dispersion, et pourquoi la sonde répète désormais ses mesures.

Côté client, un agent de codage qui fixe la température à 0,7 gagne environ un dixième de débit par rapport à la valeur par défaut, sans modification du serveur. Notre plateforme pourrait appliquer cette valeur par défaut.

Ce que cela signifie pour nos clients

Concrètement, pour les utilisateurs du point d'accès de codage :

• Les réponses s'écrivent environ un tiers plus vite. En flux unique, les tokens arrivent désormais toutes les 35 ms au lieu de 48. La réponse moyenne sur notre trafic fait environ 460 tokens, elle se termine donc en à peu près 16 secondes au lieu de 22; la réécriture d'un fichier de 2 000 tokens prend environ 70 secondes au lieu de 96.
• Le premier token arrive au même moment qu'avant. Cette attente, c'est le traitement de l'invite, que le décodage spéculatif ne touche pas : environ deux secondes par requête sur notre trafic, parce que 96 % de l'invite est déjà dans le cache de préfixes depuis le tour précédent.
• Le gain rétrécit quand la machine est occupée, mais il ne disparaît plus. Avec quatre à seize agents qui décodent en même temps, chacun obtient 7 à 13 % de plus qu'avant au lieu de 37 %. Le bloc natif de 7 tokens perdait du terrain à seize flux; celui que nous servons, non.
• Le code est exactement le même. Le décodage spéculatif n'accepte que des tokens que le modèle aurait produits de toute façon, si bien que la qualité, les appels d'outils et l'entrée d'images sont intacts, et l'appariement BigCodeBench de l'article précédent tient toujours.
• Certaines réponses semblent plus rapides que d'autres. Un modèle brouillon prédit bien le code répétitif et les modifications qui reprennent le fichier existant. Il prédit moins bien la prose ou une logique inhabituelle. Le gain de vitesse varie donc selon le contenu et s'équilibre sur une session.
• Une chose est entre les mains du client. Un agent qui envoie une température d'échantillonnage de 0,7 pour du code, au lieu de laisser la valeur par défaut du modèle à 1,0, obtient environ 10 % de plus, parce que le brouillon est accepté plus souvent quand le modèle est moins aléatoire.

Ce que ça coûte

Le brouillon, c'est 2,95 Gio de poids (la ligne de chargement de vLLM est passée de 21,97 à 24,92 Gio). Son propre cache à fenêtre glissante de 2048 tokens est taillé dans le même budget KV de 36 Gio, qui contient désormais 838 501 tokens au lieu de 1 014 892 : 3,2 requêtes simultanées de 262K tokens au lieu de 3,9. Le démarrage à froid prend sept minutes au lieu de six. Et la 0.28.0 impose son exécuteur de modèle V2 pour un brouillon DFlash2, un chemin de code plus récent, qui a servi la conversation, séparé le raisonnement de la réponse, analysé un appel d'outil et lu une image correctement dans les vérifications du jour même, et survécu à seize flux à sept tokens de brouillon là où la version précédente plantait à quatre flux avec quatre tokens MTP.

Ce que nous avons déployé

Qwen3.8-27B NVFP4 avec un brouillon DFlash2 de cinq tokens sur vLLM 0.28.0; les deux serveurs de plongements sur la même image; même proxy, même nom servi, mêmes 262K de contexte et 36 Gio de KV. La tête MTP reste dans le checkpoint et sa configuration reste dans la spécification sur une ligne en commentaire, parce qu'un brouillon dont l'acceptation oscille entre 16 % et 43 % sur la même invite mérite un repli qui oscille moins.

Les réserves honnêtes :

• DFlash2 a été entraîné contre les poids bf16 de Qwen; nous servons une quantification NVFP4 communautaire, et le brouillon lit des états cachés que la quantification perturbe. Une partie de la dispersion vient peut-être de là. Un brouillon entraîné sur la cible quantifiée est l'expérience que nous n'avons pas menée.
• Chaque chiffre, c'est une machine, une sonde, un jour. Les cases à un et deux flux sont des moyennes de deux à quatre passes; les autres sont des passes uniques.
• Notre estimation avait omis tout le coût d'exécution du modèle brouillon. Sur une machine à mémoire unifiée, il faut mesurer la durée d'une étape; diviser la taille des poids par la bande passante ne suffit pas.
• La qualité du code est intacte par construction - le décodage spéculatif accepte exactement les tokens que le gros modèle aurait produits - si bien que l'appariement BigCodeBench de l'article précédent tient toujours.

Ce que la journée nous a rapporté, au-delà du chiffre

Un tiers de plus par flux, c'est le titre, mais l'infrastructure en ressort avec davantage : l'image est sur vLLM 0.28.0 avec la procédure de mise à jour exercée de bout en bout; la sonde prend une température et répète ses mesures; les compteurs de production nous donnent désormais la longueur d'acceptation du vrai trafic, le chiffre à surveiller maintenant que le brouillon rencontre des agents plutôt qu'une invite sur les arbres rouge-noir; et quarante et un bacs à sable d'évaluation restés de la passe BigCodeBench de la semaine précédente ont disparu de la machine. Le prochain levier est documenté plutôt que deviné : la vérification par blocs, une règle d'acceptation sans perte qu'expose l'exécuteur V2, et un brouillon apparié aux poids quantifiés.

CARouter achemine les requêtes d'IA vers des fournisseurs qui servent depuis le Canada, et CARouter Cloud est la partie que nous hébergeons nous-mêmes : un ASUS Ascent GX10 (une machine de classe NVIDIA GB10 « DGX Spark », 128 Go de mémoire unifiée, arm64) qui fait tourner vLLM derrière un proxy TLS, rattaché à notre grappe Kubernetes comme capacité. Il sert deux modèles de plongements et un modèle de codage. Voici l'histoire du choix du modèle de codage, racontée avec les chiffres, parce que le chiffre qui a tranché n'est pas celui que nous attendions.

En bref

• Vitesse. Sur notre sonde de génération de code, Laguna décode à 46,5 tokens/s en flux unique et à 176 en agrégé à huit flux; Qwen, à 18,3 et 122. Laguna mène à chaque niveau de simultanéité que nous avons essayé.
• Traces de raisonnement. Sur le texte qu'un agent de codage produit réellement, les deux sont à égalité par flux : environ 17 tokens/s contre 14.
• Mémoire. Qwen, à 44 Gio résidents, laisse 62 Gio libres; Laguna, à 98 Gio, en laisse 8. Cela fait 3,9 requêtes simultanées de 262K tokens contre 1,2, et c'est le chiffre qui a tranché.
• Qualité. 33 contre 31 sur les 50 premiers problèmes de BigCodeBench, p = 0,73 au test de McNemar. Pas d'écart.
• En service. Qwen3.8-27B dans une quantification NVFP4 communautaire, profondeur MTP 3, 36 Gio de KV. Laguna reste à une variable d'environnement de distance.

Les deux candidats

Poolside Laguna S 2.1 était le tenant du titre : un mélange d'experts de 117B avec 8,5B de paramètres actifs, servi depuis le checkpoint NVFP4 de Poolside avec leur brouillon de décodage spéculatif DFlash. C'est un très bon modèle de codage, et c'est un gouffre à mémoire : ~98 Gio résidents à 262K de contexte, ce qui, sur une machine de 121,6 Gio, laisse la place aux deux modèles de plongements et à rien d'autre.

Qwen3.8-27B était le prétendant : un modèle dense de 27B, 64 couches dont 48 en Gated DeltaNet (attention linéaire) et 16 en attention complète, 262K de contexte natif, une tour de vision, et une tête de prédiction multi-tokens (MTP) entraînée dans le checkpoint. La fiche de Qwen le place près de la frontière en codage agentique (SWE-bench Pro 61,7, Terminal Bench 2.1 73,0).

L'attente naïve, que nous avions notée avant de mesurer : le 27B dense serait beaucoup plus lent. Un GB10 offre environ 273 Go/s de bande passante mémoire, le décodage est borné par la bande passante, et un 27B dense en FP8 lit ~27 Go de poids par token là où le MoE de Laguna en lit ~4 Go. Le modèle de performance roofline disait 10 tokens/s contre 60. Sur une simple invite de code, l'arithmétique a tenu : Laguna est deux fois et demie plus rapide en flux unique et devant à chaque taille de lot que nous avons essayée. Ce que l'arithmétique a manqué, c'est la charge de travail qu'un agent de codage envoie réellement, et la mémoire que le plus petit modèle laisse derrière lui - c'est là que va le reste de cet article, et de là que vient la décision.

Ce que nous avons mesuré, et comment

Chaque chiffre de débit ici vient d'une seule sonde, le script de banc d'essai de notre dépôt d'infrastructure : N requêtes de génération de code simultanées à travers le proxy de production, le taux de décodage lu dans les compteurs de tokens de vLLM lui-même sur une fenêtre de 40 secondes, puis un nouveau préremplissage de 12K tokens. Même sonde, même machine, même jour pour les deux modèles, pour que les colonnes s'alignent. Quand un chiffre vient plutôt de l'évaluation - le taux de décodage sur de longues traces de raisonnement, lu dans les mêmes compteurs pendant que BigCodeBench tournait - c'est indiqué, parce que les deux charges de travail ne donnent pas la même réponse. La qualité du code, c'est BigCodeBench, les 50 premiers problèmes, tokens sortants sans plafond, notés dans un bac à sable - les mêmes 50 problèmes pour les deux, pour que les deux passes s'apparient.

Constat 1 : le décodage spéculatif vaut 5 tokens par pas sur du code facile et 1,5 sur du raisonnement

Le brouillon DFlash de Laguna propose 7 tokens par pas. Sur notre sonde de génération de code, il en place 58 % - 5,1 tokens par pas - et Laguna décode à 46,5 tokens/s en flux unique. Sur les longues traces de raisonnement qu'un agent de codage produit réellement (sa passe BigCodeBench, lue dans les mêmes compteurs), l'acceptation tombe à 21 %, 1,48 token par pas, et le débit par flux à environ 17. L'unique couche MTP de Qwen, rejouée trois fois, en accepte environ la moitié à chaque position sur l'une ou l'autre charge : 2,5 tokens par pas, 18,3 tokens/s en flux unique sur la sonde et environ 14 par flux avec huit requêtes d'évaluation en vol. La spéculation de Laguna est spectaculaire quand le texte est prévisible et ordinaire quand il ne l'est pas; celle de Qwen est stable, et il partait quand même plus lent, parce que son pas de base lit 27 Go.

Le levier pour Qwen, c'était donc le checkpoint. Nous avons remplacé les poids FP8 officiels de Qwen par une quantification NVFP4 communautaire (celle d'unsloth : MLP en 4 bits, projections d'attention en FP8, échelles de KV et tête MTP comprises). vLLM l'a placée sur le noyau CUTLASS NVFP4 de FlashInfer - la même famille de noyaux qui rend Laguna rapide sur ce silicium - et le temps de pas est passé de 185 ms à 130 ms, plus que ne le prédit le seul rapport d'octets.

Douze configurations plus tard, celle qui est en service est NVFP4 à une profondeur MTP de 3. La profondeur 4 égalait la 3 en flux unique, puis a fait planter vLLM sur un accès mémoire illégal à quatre séquences simultanées, le genre de chose qu'on n'apprend qu'en l'exécutant. Des blocs de préremplissage plus gros ont ralenti le préremplissage d'un tiers. La précision du cache KV s'est révélée être une décision de calibration, pas de vitesse.

Constat 2 : Laguna est plus rapide sur les tâches simples, à égalité sur les tâches complexes

Un point d'accès de codage derrière une plateforme de routage ne traite jamais une requête à la fois, alors nous avons mesuré les deux modèles à 1, 2, 4 et 8 flux simultanés, même sonde, même jour.

Laguna mène à chaque compte : 46,5, 52, 96 et 176 tokens/s en agrégé contre 18,3, 40, 73 et 122 pour Qwen. La courbe de Qwen est la plus droite - à 5 % du linéaire jusqu'à huit flux, parce qu'un modèle dense paie sa lecture de poids une fois par pas quel que soit le lot, et que 32 tokens par pas est très loin de saturer le calcul d'un 27B. Celle de Laguna s'aplatit entre un et deux flux, où l'acceptation de son brouillon fléchit, puis grimpe de 3,8x à huit. Le croisement que nous attendions, où le traitement par lots éroderait l'avantage des paramètres actifs du MoE, n'est pas là à huit flux sur cette machine.

Ce qui resserre l'écart, c'est la charge de travail. Sur les traces de raisonnement, lues dans les mêmes compteurs pendant les passes BigCodeBench, Laguna fait environ 17 tokens/s par flux à deux flux et Qwen environ 14 par flux à huit (113 en agrégé); Laguna au-delà de deux flux sur cette charge est la seule case que nous n'avons pas mesurée. Par flux, sur le texte que les agents produisent réellement, les deux sont à égalité; sur du code que Laguna peut prédire, il est loin devant. Le préremplissage appartient à Laguna à toutes les longueurs : 3 550 tokens/s contre 2 088 sur une invite de 12K, 2 836 à 55K et 1 634 à 200K.

Constat 3 : 62 Gio libres, c'est quatre sessions à 262K au lieu d'une

C'est ce chiffre qui a tranché. Nous voulions 262K de contexte et plusieurs clients de codage actifs simultanément. Le contexte occupe le cache KV, qui doit tenir dans la mémoire laissée libre par les poids.

Laguna, à 98 Gio résidents, laisse 8 Gio libres après les modèles de plongements. Son budget KV de 12 Gio tient 1,2 requête à contexte plein, et il n'y a nulle part où l'agrandir. Qwen, à 44 Gio, laisse 62 Gio libres. Son KV par token est en fait plus cher que celui de Laguna (32 Kio contre 24, parce que ses 16 couches d'attention utilisent des têtes de largeur 256), mais il peut se permettre un budget trois fois plus grand, avec de la place pour quatre.

Avec les 36 Gio de KV que nous avons déployés, Qwen tient près de quatre requêtes simultanées de 262K tokens (3,9 : 1 014 892 tokens en cache, mesurés); à 48, il en tiendrait cinq. Laguna en tient une, avec une deuxième en attente. Pour une plateforme dont les cas d'usage en codage sont des agents qui lisent des dépôts entiers, ce n'est pas un détail de débit; c'est le produit.

Constat 4 : une qualité comparable, comme nous l'espérions

Sur les 50 premiers problèmes de BigCodeBench - sortie sans plafond, notée dans le même bac à sable, les mêmes 50 pour les deux - Qwen en résout 33 et Laguna 31. Appariés problème par problème, les deux s'accordent sur 42 d'entre eux : 28 résolus par les deux, 14 ratés par les deux. Qwen seul en résout cinq, Laguna seul trois, et un test de McNemar exact sur ces huit problèmes discordants donne p = 0,73. Ce n'est pas un classement, et ça n'allait jamais en être un à n = 50; c'est l'absence d'écart, qui est le résultat dont le constat sur la mémoire avait besoin pour signifier quelque chose. Ce qui a différé, c'est le temps que Qwen passe à réfléchir. Il a produit 462K tokens sortants pour l'ensemble contre 264K pour Laguna, et dix de ses échantillons ont dépassé 16K tokens là où Laguna n'a jamais franchi 11K - des traces de raisonnement de 20 à 31K tokens sur les problèmes les plus durs, aucune n'atteignant le plafond de 32K. Ces échantillons sont aussi ce qui nous a fait trouver deux délais d'expiration de dix minutes, un dans le proxy et un dans l'outil d'évaluation, qui coupaient silencieusement les longues générations et les relançaient; les deux sont à 7 200 s maintenant, et chaque chiffre de cet article a été mesuré après le correctif.

Le repérage en long contexte a tenu aussi. Sur la même grille d'aiguille dans une botte de foin qui avait validé les 256K de Laguna (quatre longueurs de contexte de 32K à 220K, trois positions d'aiguille), Qwen obtient 9,0/10 au total - parfait à 95K, 9,0 à 157K, et 8,0 à 220K là où Laguna tenait un 10 parfait. C'est au fond de la fenêtre que le tenant du titre garde une petite avance; tout ce qui est en deçà est un match nul.

Ce que nous avons déployé

Qwen3.8-27B, NVFP4, profondeur MTP 3, 262K de contexte, 36 Gio de KV, images activées, derrière le même proxy sous le même nom servi. Laguna reste sur le disque et dans le dépôt, à une variable d'environnement près, parce qu'une décision prise sur n=50 et une fin de semaine doit rester réversible.

Les réserves honnêtes :

• La version NVFP4 est une quantification communautaire, pas celle de Qwen.
• 50 problèmes, c'est un signal, pas un classement.
• Le décodage de Laguna sur des traces de raisonnement n'a été mesuré qu'à deux flux, si bien que son chiffre à huit flux sur cette charge est une inférence, pas une mesure.
• La comparaison de débit s'est inversée sur le tard : tant que Laguna n'était pas passé par la même sonde, nous mettions son taux d'évaluation en face du taux de sonde de Qwen et déclarions Qwen 3,6x plus rapide à huit flux, ce qu'il n'est pas. La décision tient sur les trois autres constats.
• Tout ici est une seule machine, donc les courbes de lot sont une propriété du dense contre le MoE sur mémoire unifiée, pas une loi universelle.

Ce qu'un deuxième DGX Spark changerait

La question évidente après une fin de semaine comme celle-là, c'est si un deuxième GB10 - deux DGX Spark, reliés par leurs ports ConnectX-7 à 200 Gb/s, la configuration que NVIDIA vend pour les modèles de classe 405B - aurait changé la décision. Il aurait changé les options plus que la réponse.

• Les deux modèles, sans choisir. L'usage le plus simple d'une deuxième machine est de servir Laguna sur l'une et Qwen sur l'autre, chacun avec ses modèles de plongements, et de laisser la plateforme acheminer par modèle. Deux points d'accès de codage, deux offres souveraines, et Laguna récupère ses 121 Gio entiers pour un KV qu'il n'a jamais eu. C'est la configuration que nous ferions tourner si un client demandait Laguna précisément.
• Qwen en double, du KV partout. Deux machines Qwen indépendantes doublent la capacité simultanée à 262K pour la porter à dix, ajoutent la reprise sur panne, et gardent la mise à l'échelle linéaire par lot sur chacune. C'est la réponse ennuyeuse et probablement la bonne pour une plateforme : la capacité s'additionne, rien ne traverse l'interconnexion sur le chemin de la requête.
• Qwen en parallélisme de tenseurs sur les deux. vLLM peut répartir le 27B dense sur deux nœuds, ce qui divise par deux les octets de poids que chaque machine lit par pas et, en principe, double presque le décodage en flux unique. Le prix est un all-reduce par couche sur un lien à 25 Go/s; à la taille cachée de Qwen, cela fait quelques kilooctets par token par couche, donc le coût est en latence, pas en bande passante - plausible, non mesuré, et cela dépense la deuxième machine sur la latence en flux unique, la seule colonne où Laguna est déjà loin devant sur du code et où les deux sont à égalité sur du raisonnement.
• Un plus gros modèle à la place. L'option vraiment nouvelle : avec 256 Go, les candidats changent. La révision principale de Laguna (99,7 Go, les huit couches d'experts en BF16 que Poolside a gardées pour la qualité) tient avec de la place pour le contexte; un MoE 122B-A10B en NVFP4 (83,5 Go sur le Hub) aurait l'économie de paramètres actifs de Laguna avec une base plus forte et laisserait encore bien plus de 100 Go de KV sur la paire. C'est l'expérience que nous ferions ensuite, et c'est un autre article.

Ce qu'une deuxième machine ne changerait pas, c'est la forme du constat. Le décodage sur ce silicium est borné par les octets par pas et aidé par les tokens par pas; une plateforme est servie par le débit agrégé et le contexte simultané; et un modèle dense qui tient dans un tiers de la mémoire transforme les deux autres tiers en exactement ce qu'une plateforme vend. Plus de machines multiplient cela. Elles ne le remplacent pas.