Laya vs Nimble : données contrastives versus un encodeur plus rapide

Laya et Nimble sont les deux modèles de décision à poids ouverts dont les auteurs ont le plus fait pour expliquer comment ils ont été construits, et leurs explications divergent sur l'endroit où réside la difficulté. Convai Innovations a publié Laya le 18 septembre 2026 sous Apache 2.0 — un checkpoint anglais ModernBERT-large de 421 M, un checkpoint multilingue mmBERT-base de 322 M couvrant plus de 100 langues, un routeur inférieur à la milliseconde entre eux, et un p50 de 32,8 ms par décision publié sur un Tesla T4. Bespoke Labs a construit Nimble comme un fine-tuning LoRA sur Qwen3.5-9B, sous Apache 2.0, et le décrit comme « le Jev open source » — inspiré du Jev de TypeSafe AI mais n'utilisant ni ses poids, ni son architecture, ni une distillation de ses sorties. La réponse de Convai au problème de précision, c'est la vitesse et une base affinable. La réponse de Bespoke, ce sont les données d'entraînement. Cette différence mérite plus d'attention que l'écart de précision de trois points qui apparaît dans les tableaux principaux.

L'affirmation que chaque projet formule réellement

L’affirmation de Laya est d’ordre architectural. Elle est non autorégressive au sens strict — un encodeur bidirectionnel, aucune boucle de décodage, aucun JSON à analyser, aucun espace où émettre du texte en dehors du type déclaré. Cette garantie structurelle est la même que celle qu’offre Jev, atteinte par une autre voie, et elle est véritablement précieuse pour quiconque a écrit une logique de réessai autour d’un modèle qui oublie parfois de fermer une accolade. Le coût, c’est qu’un encodeur de 421 M avec une fenêtre de 512 jetons et sans préentraînement génératif derrière lui n’en sait pas très long. Convai le dit sur la fiche du modèle : « Laya est une base rapide à spécialiser, pas un moteur de décision zéro-shot. »

L'affirmation de Nimble porte sur les données. La méthode de Bespoke est une curation contrastive, adaptée des travaux antérieurs de l'équipe sur Bespoke-MiniCheck : écrire deux exemples presque identiques qui diffèrent par un « fait focus », de sorte que l'étiquette correcte s'inverse. Le pipeline comporte quatre étapes énoncées — vérifier que les règles de décision pourraient véritablement mener à des réponses différentes, construire la paire en modifiant au plus huit mots, vérifier les deux exemples au moyen d'appels distincts au modèle, plus un contrôle consistant à retirer chaque phrase, et générer les étiquettes dans le code tout en ne conservant que les paires dont les étiquettes diffèrent réellement. L'objectif n'est pas d'obtenir plus d'exemples, mais des exemples plus nets : forcer le modèle à apprendre quelles preuves devraient changer la décision. C'est une théorie différente de la raison pour laquelle les petits modèles de décision échouent, et elle est plus intéressante qu'un point de précision supplémentaire.

Ce que les chiffres publiés étayent réellement

Nimble rapporte une concordance de 90,12 % avec les étiquettes de référence sur 324 échantillons tenus à l'écart, contre 93,21 % pour Jev, 66,36 % pour la base Qwen3.5-9B non ajustée et 84,88 % pour un Qwen3.8 27B non ajusté. Il indique une médiane d'environ 106 ms sur un H100 et de 444 ms sur un M5 Pro avec 64 Go. Ce sont les propres chiffres du banc d'évaluation de Bespoke. L'ensemble d'évaluation de 324 échantillons est l'élément à peser avec prudence, et le projet en donne lui-même la raison : les échantillons couvrent six des dix familles de sources d'entraînement, ils ont été générés et validés par des modèles sans examen humain, et la généralisation à des catégories non vues n'est donc pas démontrée. Lorsqu'un modèle est entraîné avec une méthode de curation de données, puis évalué sur une partition tenue à l'écart de cette même distribution curée, le chiffre d'exactitude est un indicateur de la cohérence interne de la méthode, pas de votre trafic.

Les chiffres de Laya viennent de l'autre bout. Sur le benchmark typed-decisions de TypeSafe, il obtient 0,362 en zero-shot — le hasard est à 0,318, la baseline de la classe majoritaire à 0,461 — et 0,766 lorsqu'il est affiné sur le propre split d'entraînement du benchmark. Sur Banking77, 77 étiquettes, il obtient 0,425 contre 0,870 pour Jev, ce qui est l'illustration la plus frappante de son plafond lorsqu'il y a de nombreuses options. Sur AG News avec quatre étiquettes, il obtient 0,950 contre 0,910 pour Jev ; sur DAIR Emotion avec six étiquettes, 0,595 contre 0,480. Son erreur de calibration au départ est de 0,466 et descend à 0,081 après un réajustement de température par type de question. Un test effectué par un tiers sur 100 messages d'urgence Mars-base a donné Jev à 100/100 et Laya à 53/100. Et dans une évaluation indépendante d'appels d'outils d'agent, Laya a atteint un rappel de refus de 100 % sur les appels dangereux, mais seulement en signalant tout, ce qui est un échec de précision déguisé en victoire de sécurité.

Mettez les deux ensembles de chiffres côte à côte, et la lecture honnête est qu’ils ont été mesurés sur des choses différentes. Les 90,12 % de Nimble correspondent à un accord avec ses propres étiquettes de référence sélectionnées. Le 0,362 de Laya est un benchmark que cette dernière n’a pas construit. Aucun des deux chiffres ne se transpose.

Calibration : le seul endroit où les deux projets font preuve d'une franchise inhabituelle

C'est ici que les deux projets se rapprochent le plus par l'esprit et divergent le plus dans le résultat.

Le README de Bespoke avertit explicitement que les probabilités de Nimble sont des logits normalisés par softmax sur les candidats fournis, et non des taux d’exactitude calibrés — un 0,9 ne signifie pas 90 % de réponses correctes. Il recommande d’ajouter une option « aucune des réponses ci-dessus », car si la bonne réponse ne figure pas parmi les candidats, l’un d’eux l’emporte quand même. Sur une évaluation plus récente de 3 880 enregistrements couvrant 13 sous-ensembles, Jev présentait une erreur de calibration rapportée plus faible dans 11 des 13 sous-ensembles et un score de Brier plus faible dans 10 des 13. Ainsi, une concordance d’étiquettes similaire n’implique pas une qualité de probabilités similaire, et Bespoke le dit.

La divulgation de Convai en est l'image miroir : l'erreur d'étalonnage attendue de 0,466 figure sur la fiche, à côté du 0,081 que produit le réajustement de température par type de question. Aucun des deux projets ne livre un modèle dont on peut exploiter la confiance sans travail. Les deux vous le disent par écrit. Si vous mettez en place un seuil de confiance — libération automatique au-dessus de 0,95, escalade en dessous de 0,7 — la documentation des deux auteurs vous dit la même chose : ajustez d'abord le seuil sur vos propres données annotées.

La comparaison, dimension par dimension

• Backbone — Laya : encodeur ModernBERT-large 421M, bidirectionnel, pas de pré-entraînement génératif. Nimble : Qwen3.5-9B avec un fine-tuning LoRA, base générative conservée.

• Langues — Laya : plus de 100 grâce au checkpoint multilingue 322M. Nimble : anglais.

• Budget de prompt — Laya : 512 jetons en anglais, 1 024 en multilingue. Nimble : 2 048 jetons maximum par prompt, schémas plats uniquement, énumérations limitées à 26 options par champ.

• Vitesse — Laya : 32,8 ms p50 sur une T4, 7,2 ms par question en lots de 10. Nimble : environ 106 ms en médiane sur une H100, 444 ms sur un M5 Pro 64 Go.

• Matériel — Laya : CPU, CUDA et Apple MPS ; moins d’un gigaoctet résident sur le port MLX. Nimble : GPU CUDA BF16 pour les chiffres indiqués, avec prise en charge des chemins MLX et CUDA.

• Précision rapportée — Laya : 0,362 en zéro-shot, 0,766 après affinage, 0,425 sur Banking77. Nimble : 90,12 % sur 324 échantillons retenus et sélectionnés, contre 93,21 % pour Jev.

• Méthode — Laya : l’architecture d’abord, un réglage fin par déploiement. Nimble : une curation de données contrastive, publiée sous forme de recette.

• Licence — Apache 2.0 pour les deux.

Deux contraintes dans cette liste méritent d’être relues deux fois avant de vous engager. La limite de 26 options par énumération de Nimble et son plafond de 2 048 jetons pour le prompt sont des limites de schéma strictes, et non une dégradation des performances — si votre taxonomie comporte quarante libellés ou si votre prompt contient un long document, Nimble n’est pas l’outil adapté, quelle que soit sa précision. Et Nimble évalue chaque champ indépendamment, donc toute règle de cohérence entre champs — « si A est vrai alors B doit être faux » — doit résider dans votre code, et non dans le modèle.

Pourquoi la recette de données est l'artefact le plus portable

Voici l’argument en faveur de Nimble que les tableaux de précision laissent de côté. Bespoke a publié le pipeline de curation, pas seulement les poids. Si votre problème de décision a une taxonomie fixe et que vous pouvez consigner les règles, la méthode contrastive est quelque chose que vous pouvez exécuter sur vos propres données avec vos propres faits ciblés, par-dessus le modèle de base de votre choix. Le 9B LoRA est autant une démonstration de la méthode qu’un produit.

La portabilité de Laya est différente et complémentaire. Parce qu'il est petit, parce qu'il tourne sur CPU et parce que les ports ONNX et MLX existent, Laya est le modèle que vous pouvez placer dans un processus qui n'a ni GPU ni réseau. Dans un benchmark tiers d'agents de navigateur, Laya a accompli 0 des 50 tâches et a déclaré avoir terminé prématurément dans 33 tentatives — mais les auteurs du benchmark notent qu'il a été entraîné pour un travail de jugement comme les tickets d'assistance, les factures et l'examen des traces d'agents, pas pour la navigation. Interprétez ce résultat comme un énoncé de périmètre plutôt qu'un verdict, et il est cohérent avec le cadrage des deux projets : il s'agit de composants pour une classe spécifique de décisions, et non d'agents généraux.

Ni Laya ni Nimble ne sont des modèles hébergés sur OrcaRouter. Les deux sont des poids que vous exécutez vous-même, et rien dans cet article ne doit être interprété comme une affirmation que nous les servons. Si le produit de routage est mentionné, c'est pour la même raison qu'il l'est dans toute architecture à modèle de décision : le modèle de décision répond à un appel, et l'application qui l'entoure a toujours besoin de prose. Un pipeline qui utilise Nimble pour évaluer si un brouillon est conforme et Laya pour router l'exception aura toujours besoin d'un modèle génératif pour rédiger le brouillon. Maintenir cette moitié générative sur un unique point de terminaison compatible OpenAI — plus de 200 modèles, prix catalogue du fournisseur répercuté avec 0 % de marge, de sorte qu'une baisse de prix d'un fournisseur soit effective le jour même, avec basculement automatique entre fournisseurs — signifie que la couche de décision peut être remplacée sans toucher au contrat de la couche générative.

Le verdict, et l’expérience qui le changerait

Choisissez Nimble si votre taxonomie est fixe et étroite, vos entrées sont en anglais et courtes, vous disposez d'un GPU, et vous voulez la recette de données autant que le modèle. Choisissez Laya si vous avez besoin d'entrées multilingues, d'un budget inférieur à 40 ms, ou d'un processus sans GPU du tout — et intégrez le coût du fine-tuning dès le départ, car le checkpoint zero-shot est en dessous de la baseline triviale et la fiche du modèle le dit.

L'expérience qui permettrait de trancher est une évaluation appariée sur du trafic réel : mêmes entrées, mêmes ensembles d'options, mêmes seuils de confiance, évalués par rapport à des étiquettes humaines, avec un diagramme de fiabilité pour chacun. La documentation de Nimble elle-même avertit que ses probabilités ne sont pas des taux d'exactitude, et la fiche de Laya rapporte une erreur de calibration de 0,466 avant réajustement ; ce diagramme est donc l'artefact qui vous dirait réellement quel modèle placer devant la production. Aucun des deux projets n'en a publié, et aucun n'a publié celui de l'autre. Construisez-le sur vos propres données avant de fixer un seuil.