Comment sont fabriqués des termes marketing comme near-lossless ou deployment unlock ?

near-lossless ajoute un préfixe pour emprunter le poids de « sans perte » sans en assumer la charge de preuve — après une ternarisation, les poids d'origine sont irrécupérables, personne n'ose parler de sans perte ; deployment unlock ne donne pas de chiffres mais un récit : reformuler « le modèle est compressé » en « le déploiement est déverrouillé » déplace la question dans l'esprit de l'auditeur de « quelle taille fait le modèle ? » à « combien de GPU puis-je économiser ? ». Faisons la liste des bénéficiaires : le discours marketing de l'éditeur, les créateurs de contenu, et ceux qui veulent faire avancer un projet ; le seul qui n'y gagne pas, c'est celui qui n'a pas déconstruit les mots avant de signer.

Comment utiliser trois questions pour déconstruire le langage lors d'une évaluation d'achat ?

Premièrement, exigez une formulation reproductible : quel est le dénominateur, la liste des références et les pondérations d'agrégation peuvent-elles être fournies ? Deuxièmement, faites appel à un tiers sans lien d'intérêt pour refaire les tests — ne vous fiez pas uniquement aux chiffres autodéclarés. Troisièmement, inscrivez les arguments marketing dans les critères de recette — une fois le langage transformé en clauses contractuelles, soit l'autre partie définit précisément chaque terme, soit ce terme disparaît de la proposition ; dans les deux cas, le client gagne.

« 9× plus petit, 98,2 % préservés » : comment les responsables techniques doivent lire le langage des fournisseurs

Q: Comment lire « 9× plus petit que la version en pleine précision » ?

D'abord, demandez le dénominateur : la version en pleine précision est-elle en FP16 ou en FP32 ? Le multiple change complètement. L'éditeur indique que Ternary Bonsai 2 27B utilise 1,76 bit effectif par poids, pour un total de 5,9 Go — 27 milliards de paramètres multipliés par 1,76 bit, cela donne bien environ 5,9 Go, c'est vérifiable ; en revanche, pour « 98,2 % des performances de référence agrégées », l'éditeur ne fournit ni la liste complète ni la méthode d'agrégation. Les pertes lissées par la moyenne pourraient précisément se situer sur vos tâches critiques.

Ouverture : une phrase, deux chiffres

Le 17 septembre, le blog officiel de PrismML a publié Ternary Bonsai 2 27B, avec un message officiel en une phrase : 9× plus petit que la version en pleine précision, tout en préservant 98,2 % des performances de référence agrégées. Ce discours est-il faux ? Pas nécessairement. Mais savoir le lire est un autre métier. Le même jour, cette phrase a obtenu 563 votes sur Hacker News. Et en remontant deux mois en arrière, lors du lancement de la première génération de Bonsai 27B, le discours officiel de l’entreprise était déjà passé de « rendre le modèle plus petit » à « la compression devient un déverrouillage du déploiement (deployment unlock) ».

Un mot marketing n’est pas synonyme de mensonge, mais il obéit à sa propre logique de création lexicale et a ses propres bénéficiaires. Le travail d’un responsable technique n’est ni de le critiquer ni d’y croire, mais de le décomposer en éléments vérifiables.

Shiwen : Une phrase, deux chiffres — pourquoi méritent-ils un épisode entier ?

Yongliang : Parce qu’en dix-sept ans de comptes rendus côté prestataire et d’évaluations de propositions, plus de la moitié des désaccords ne portent pas sur la technique, mais sur le langage. Le fournisseur annonce un chiffre, le client en entend un autre, les deux croient parler de la même chose, et ce n’est qu’après la signature qu’ils découvrent que ce n’était pas le cas. Cet épisode démonte précisément cela : comment lire les chiffres, comment les mots sont fabriqués, comment les étoiles montent, et pour finir, trois questions que vous pouvez poser directement en réunion d’achat.

Q1 : Commençons par déconstruire les deux chiffres « 9× plus petit » et « 98,2 % »

Yongliang : Précision préalable : tout ce qui suit repose sur les chiffres autodéclarés du blog officiel de PrismML, et je précise à chaque fois « selon l’éditeur ». Dans ce cadre, ces deux chiffres sont précisément les échantillons les plus dignes d’analyse.

Selon le blog officiel, Ternary Bonsai 2 27B est basé sur Qwen3.8 27B, avec des poids ternarisés — trois valeurs {-1, 0, +1} — complétés par une mise à l’échelle par groupes en FP16. L’éditeur annonce 1,76 bit effectif par poids, une occupation totale de 5,9 Go, un support de 262K de contexte, une entrée multimodale texte-image, sous licence Apache 2.0. Rien que sur ces points, le travail d’ingénierie est solide, il faut le reconnaître.

Ce qui mérite une lecture lente, c’est la seconde partie. L’éditeur annonce « 9× plus petit que la version en pleine précision, tout en préservant 98,2 % des performances de référence agrégées ». En décomposant, il y a trois problèmes de formulation. Premièrement, quel est le dénominateur du « 9× » ? La version en pleine précision est-elle en FP16 ou en FP32 ? Le multiple change complètement selon le dénominateur. Deuxièmement, quelles références sont agrégées dans les « 98,2 % » et avec quelles pondérations ? Le blog officiel ne fournit ni la liste complète des références ni la méthode d’agrégation — ce n’est pas une accusation, c’est une question de niveau de divulgation. Troisièmement, et c’est le plus facile à négliger : un score de référence n’équivaut pas à une expérience sur des tâches réelles. Une référence agrégée est une moyenne sur des dizaines de tâches ; conserver 98,2 % en moyenne signifie que certaines tâches individuelles chutent plus, d’autres moins, et la partie lissée par la moyenne pourrait précisément se situer sur vos tâches métier critiques.

Je le redis : je suis prestataire depuis dix-sept ans, cette technique d’emballage des chiffres, je l’ai vue utilisée par d’autres et je l’ai moi-même utilisée. Un pourcentage avec une décimale, c’est pour paraître précis ; utiliser « agrégé » sans fournir la liste, c’est pour que les pertes ne soient pas visibles. Je ne dis absolument pas que l’éditeur ment — l’absence de liste peut être due à des contraintes de longueur ou à une présentation sélective, les deux sont possibles. Mais la lecture d’un manager est unique : face à tout chiffre emballé du type « X fois » ou « Y % », demandez d’abord le dénominateur et la liste, ensuite seulement croyez-y.

Q2 : Comment sont fabriqués des termes comme « near-lossless » ou « deployment unlock »

Yongliang : Les mots ne sont pas créés au hasard ; derrière chaque terme marketing se cache un bénéficiaire concret.

Il y a deux mois, lors du lancement de la première génération de Bonsai 27B, le discours officiel de PrismML était « la compression devient un déverrouillage du déploiement » (deployment unlock). Pour Bonsai 2, le terme near-lossless (quasi sans perte) est apparu dans les discussions communautaires. En mettant les deux côte à côte, la méthode de création lexicale est claire.

« Sans perte » a une définition technique précise : l’information peut être intégralement reconstituée. Or un modèle quantifié ne le peut pas — après une ternarisation, les poids d’origine sont irrécupérables. Personne n’ose donc parler de sans perte ; on invente alors « near-lossless » : ajouter un préfixe permet d’emprunter le poids du « sans perte » sans en assumer la charge de preuve. Qui y gagne ? À court terme, les diffuseurs de contenu — un terme à consonance technique fait tourner les publications ; à long terme, l’éditeur — une fois le terme répandu, l’impression par défaut est semée.

« Deployment unlock » suit une autre voie : pas de chiffres, un récit. « Compression » est un terme d’ingénieur, seul l’ingénieur s’y intéresse ; « déverrouiller le déploiement » est un terme commercial, destiné aux patrons et aux investisseurs. Dire que 5,9 Go « déverrouille le déploiement » déplace la question dans l’esprit de l’auditeur de « quelle taille fait ce modèle ? » à « combien de GPU cela peut-il m’économiser ? ». Les paramètres techniques n’ont pas changé, mais le public du récit a changé — c’est le virage opéré dès le lancement précédent, il y a deux mois.

Faisons la liste des bénéficiaires : d’abord le récit marketing et de levée de fonds de l’éditeur ; ensuite les créateurs de contenu, qui ont un nouveau terme à exploiter ; et même, indirectement, ceux côté client qui veulent faire avancer un projet, car un terme agréable à entendre réduit la résistance à la validation. Le seul qui n’y gagne pas, c’est celui qui signe le chèque — s’il n’a pas décomposé les mots en chiffres avant de signer.

Q3 : Trois jours, cinq dépôts, plusieurs milliers d’étoiles — comment lire la vague de projets homonymes autour de Jev

Shiwen : Après les mots des fournisseurs, regardons la communauté. Le modèle Jev de TypeSafe a fait émerger cinq projets dans la même direction sur GitHub en trois jours, avec des milliers d’étoiles cumulées. Est-ce la preuve d’un engouement technique ?

Yongliang : D’abord, établissons les faits vérifiables, ensuite seulement interprétons.

Jev est un modèle commercial de TypeSafe. Selon le blog officiel de TypeSafe, il se présente comme un modèle « system one » : au lieu de générer une réponse mot par mot, il produit directement des probabilités pour des options données, utilisé pour des décisions de branchement rapides dans des agents. TypeSafe n’a pas rendu publique la conception du modèle.

La vague de projets homonymes a démarré le 16 septembre, soit il y a trois jours. Selon les données publiques de GitHub : browser-use/jev-ultrafast avec 5487 étoiles, dont le README met en avant une démonstration « réservation d’un vol Zurich-Londres en 7,1 secondes », avec en haut du README un lien d’inscription à la liste d’attente de Browser Use Cloud ; tamaratran/fast-jev-compaction avec 3206 étoiles ; TheoLeeCJ/SemIf avec 1585 étoiles, anciennement OpenJev, dont la page d’accueil précise qu’il n’est pas affilié à TypeSafe ; vinnylarouge/jevlike avec 885 étoiles, qui se décrit comme « Jev est un modèle commercial de TypeSafe dont la conception n’est pas publique ; ce dépôt est un modèle d’apprentissage indépendant avec les mêmes formes d’entrée et de sortie » ; jarrodwatts/jev-trader avec 866 étoiles, un bot de trading on-chain qui prend une décision d’achat/vente toutes les 300 millisecondes. Le fil « OpenJev » sur Hacker News a obtenu 534 votes.

Ces chiffres contiennent deux choses qu’il faut lire séparément. La première est une action marketing : les dépôts les plus rapides placent la démo et l’entonnoir d’inscription sur le même écran, et la croissance des étoiles est elle-même l’entrée de l’entonnoir — ce n’est pas une preuve technique, c’est de l’acquisition d’utilisateurs, plutôt bien exécutée, mais cela ne répond pas à la question « ce modèle est-il bon ? ». La partie des dépôts opportunistes suit la même logique : le nom profite du buzz, les étoiles montent vite, mais les étoiles n’ont jamais égalé l’utilisabilité. Je le dis en tant qu’ancien prestataire : utiliser le nombre d’étoiles GitHub comme preuve technique en réunion d’évaluation, c’est la même erreur méthodologique que d’utiliser la longueur d’une file d’attente de restaurant comme note gustative.

La deuxième chose est précisément un signal sain. SemIf a changé de nom et déclaré n’avoir aucun lien avec TypeSafe ; jevlike précise clairement être « un modèle d’apprentissage indépendant avec les mêmes formes d’entrée et de sortie » — ces deux clauses de non-responsabilité sont la communauté qui comble les manques de divulgation de l’éditeur. Quand un sujet devient chaud, des gens prennent le temps de faire des implémentations indépendantes compatibles en forme, et écrivent en page d’accueil « je ne suis pas l’officiel, la conception m’est inconnue » — cela montre que des gens dans la communauté tiennent à la reproductibilité. Les actions marketing finissent par refluer, les clauses de non-responsabilité restent. Pour lire cette vague, contentez-vous d’observer ces dernières.

Q4 : En achat et en lancement de projet, comment utiliser trois questions pour déconstruire le langage

Yongliang : C’est ce que je veux le plus vous donner dans cet épisode. Trois questions, utilisables directement en réunion d’évaluation.

Première question : donnez une formulation reproductible. Quel est le modèle et la précision du dénominateur du « 9× plus petit » ? La liste des références et les pondérations d’agrégation des « 98,2 % » peuvent-elles être fournies ? L’essentiel de cette question n’est pas dans la réponse, mais dans la manière dont l’autre partie réagit. S’il peut fournir la liste, les chiffres résistent probablement à la vérification ; s’il commence à parler de « conventions du secteur » ou de « non-communicable », vous avez compris — ce qu’il protège, ce n’est pas un secret, c’est un chiffre. Deuxième question : y a-t-il un test tiers ? Pas un article qui relaie les chiffres officiels, mais une équipe sans lien d’intérêt avec l’éditeur, qui produit des résultats comparables dans des conditions proches. La semaine dernière, nous avons démonté une infrastructure dont les chiffres étaient autodéclarés par l’éditeur : la pile technique et les difficultés reposaient entièrement sur une seule source — un chiffre autodéclaré n’est pas forcément faux, mais il ne faut pas s’y fier uniquement. La troisième question est la plus redoutable : inscrivez les arguments marketing dans les critères de recette. « Vous parlez de near-lossless ? Alors le critère de recette sera défini par une borne d’erreur. Vous parlez de 98,2 % ? Alors la recette suivra point par point la liste de références que vous fournissez. » Une fois le langage transformé en clauses contractuelles, soit l’autre partie commence à définir sérieusement chaque terme, soit ce terme disparaît de la proposition — dans les deux cas, le client gagne.

J’utilise ces trois questions depuis une dizaine d’années. Le principe tient en une phrase : un terme marketing a la particularité de pouvoir être présenté vers le haut, mais jamais d’être soumis à une recette vers le bas. Tout terme qui ne peut pas être inscrit dans un critère de recette devrait avoir un poids nul dans une décision d’achat.

Q5 : Pour conclure — quel langage mérite la méfiance, quelle exagération est acceptable

Shiwen : Pour finir, un étalon pour que le public puisse trancher ?

Yongliang : Mon étalon distingue selon la « direction de l’exagération », pas selon le secteur.

Pour les exagérations de vitesse, je suis très tolérant. Une démo comme « billet d’avion réservé en 7,1 secondes », même tournée dans les meilleures conditions, revendique la « rapidité », et le coût de vérification de la rapidité est extrêmement faible — vous la testez vous-même et vous savez si c’est vrai. Pour les revendications de capacité, je suis intolérant. « 98,2 % de performances préservées », « near-lossless » — ces revendications portent sur « l’équivalence », et le coût de vérification de l’« équivalence » est extrêmement élevé : le temps que vous vérifiiez, le contrat est signé et l’argent est parti. Il existe une catégorie encore plus préoccupante que les revendications de capacité : le langage de définition. « Deployment unlock » ne contient en soi rien de vérifiable ; il fait un travail de redéfinition du problème — reformuler « le modèle a été compressé » en « le déploiement a été déverrouillé ». La caractéristique du langage de définition : plus il sonne agréable, plus vous devez revenir en arrière et chercher où est passé le problème d’origine.

Donc mon classement est le suivant : pour une exagération de vitesse, souriez et passez — une reproduction personnelle suffit ; pour une revendication de capacité, demandez d’abord la formulation et un tiers, et que les critères de recette en décident ; pour un langage de définition, posez directement la question du problème d’origine. En dix-sept ans de revue de propositions, les litiges finaux n’ont presque jamais porté sur des chiffres erronés, mais sur des termes jamais définis du début à la fin.

Épilogue

Shiwen : Pour finir, une phrase pour résumer cet épisode ?

Yongliang : Un mot marketing n’est pas un mensonge, c’est une archive compressée. Le travail d’un responsable technique n’est ni de le critiquer ni d’y croire, mais de la décompresser avant de signer — dénominateur, liste, critères de recette. Une fois décompressé, il est souvent moins effrayant et moins avantageux qu’il n’y paraît.

Shiwen : Cette phrase, je vous la laisse. À la prochaine.

【Approfondissement technique】Ce que fait réellement la quantification ternaire, et pourquoi 5,9 Go est le chiffre le plus vérifiable de tout le blog

Le fil principal de cet épisode portait sur la lecture du langage. Certains lecteurs voudront peut-être aller plus loin : qu’est-ce que la quantification ternaire, et pourquoi « 1,76 bit effectif », ce chiffre étrange, est-il en réalité la partie la plus honnête du blog officiel ?

Poids ternaires : {-1, 0, +1}. La quantification classique compresse chaque poids d’un flottant 16 ou 32 bits vers moins de bits, par exemple un entier 4 bits. La ternarisation va plus loin : chaque poids ne peut prendre que trois valeurs — moins un, zéro, plus un — complétées par un ensemble de coefficients de mise à l’échelle par groupes en FP16. L’éditeur annonce que cet ensemble revient à 1,76 bit effectif par poids.

Pourquoi 1,76 est honnête. Trois valeurs peuvent être encodées avec moins de 2 bits ; en ajoutant la mise à l’échelle par groupes et le surcoût d’encodage, on retombe à 1,76 bit par poids. Ce chiffre a une décimale, il n’est pas rond — c’est précisément le signe qu’il s’agit d’une moyenne calculée, pas d’un entier choisi. 27 milliards de paramètres multipliés par 1,76 bit, cela donne bien environ 5,9 Go — ce produit, tout le monde peut le vérifier. Un chiffre vérifiable est crédible ; et c’est précisément parce qu’un chiffre crédible est utilisé pour emballer le « 98,2 % » invérifiable que tout le langage tient là.

Les 1,8 % perdus ne sont pas répartis uniformément. La ternarisation n’affecte pas toutes les tâches de la même manière : pour les tâches dont la distribution des poids est lisse et la tolérance élevée, la perte est proche de zéro ; pour les tâches qui dépendent de différences numériques fines, la perte est nette. La moyenne agrégée masque précisément cette non-uniformité. C’est le fondement de la phrase du Q1 : demandez d’abord la liste, ensuite croyez.

Revenons au fil principal de cet épisode. Un chiffre vérifiable n’effraie jamais ; un chiffre effrayant est souvent invérifiable. C’est le premier principe pour lire tout langage de fournisseur.

Sources de cet épisode

Blog officiel de PrismML, 2026-09-17 : publication de Ternary Bonsai 2 27B (basé sur Qwen3.8 27B ; poids ternaires + mise à l’échelle par groupes en FP16 ; 1,76 bit effectif par poids ; 5,9 Go ; contexte 262K ; Apache 2.0 ; « 9× plus petit, 98,2 % des performances de référence agrégées préservées » sont des chiffres autodéclarés par l’éditeur, la liste complète des références et la méthode d’agrégation n’étant pas divulguées)
Blog officiel de PrismML (il y a deux mois) : lancement de la première génération de Bonsai 27B, avec le discours officiel « la compression devient un déverrouillage du déploiement » (deployment unlock)
Hacker News, 2026-09-17 : fil de discussion Ternary Bonsai 2, 563 ▲
Blog officiel de TypeSafe : Introducing System One Models and Jev (Jev est un modèle commercial, la conception du modèle n’est pas publique — tout ceci relève du discours officiel)
Données publiques GitHub (au matin du 2026-09-19) : browser-use/jev-ultrafast 5487★, tamaratran/fast-jev-compaction 3206★, TheoLeeCJ/SemIf 1585★ (la page d’accueil déclare n’avoir aucun lien avec TypeSafe), vinnylarouge/jevlike 885★ (se présente comme un modèle d’apprentissage indépendant avec les mêmes formes d’entrée et de sortie), jarrodwatts/jev-trader 866★ (les cinq dépôts ont tous été créés le 2026-09-16)
Hacker News : fil de discussion « OpenJev », 534 ▲