Kev-27B

Résumé du modèle

Kev-27B est un modèle de décision. Il lit un document (l’état) et un ensemble de questions typées à son sujet, et renvoie une distribution de probabilité calibrée sur les options fournies avec chaque question, en une seule passe avant et sans générer de texte. Il est destiné aux développeurs qui classent, routent, trient ou vérifient des documents allant jusqu’à 64k jetons et qui ont besoin de probabilités sur lesquelles poser un seuil, par exemple pour envoyer les cas incertains en revue humaine. Il implémente l’API System One publique de TypeSafe (POST /v1/systemone), donc le SDK TypeSafe fonctionne avec lui sans modification. Cette fiche décrit la version 2, publiée le 2026-09-30 : un fine-tuning à poids complets de Qwen3.8-27B moyenné avec la version 1.

Détails du modèle

Entrée. Un état (du texte, ou un objet ou tableau JSON rendu en texte étiqueté) et un nombre quelconque de questions nommées, chacune de l’un des trois types :

Chaque question est traitée comme sa propre ligne qui continue depuis l’état partagé, donc les questions ne peuvent pas s’influencer mutuellement ; l’état est calculé une fois et mis en cache.

Usages prévus

• Décisions typées sur des documents : classification, routage, triage, choix d’extraction, contrôles de politique et d’éligibilité, et jugement d’une réponse proposée contre des critères énoncés.
• Flux de travail qui agissent sur la confiance : automatiser les cas confiants et mettre les autres en file, avec des seuils figés sur un échantillon étiqueté de la propre charge de travail de l’utilisateur.
• Un remplaçant auto-hébergé, sans modification, d’un point de terminaison System One.

Usages hors périmètre

• Génération de texte, chat, résumé ou réponse à des questions ouvertes. Le modèle ne fait qu’évaluer les options qu’on lui donne.
• Décisions entièrement automatisées ayant des conséquences juridiques, médicales, financières, professionnelles ou similaires pour des personnes, sans revue humaine.
• Questions dont la réponse dépend de faits absents de l’état et hors des connaissances générales (le modèle ne peut rien rechercher), et examens très dépendants de connaissances (voir Limites).
• États de plus de 65 536 jetons, langues autres que l’anglais, et matériel plus petit qu’un GPU de classe 80 GB ou un Mac avec environ 96 GB de mémoire (voir Limites).

Comment l’utiliser

Sers-le avec le dépôt Kev sur un seul GPU B200, H200 ou H100 80 GB. Les poids prennent 51 GB et le serveur environ 65.5 GB résidents ; un état de 64k jetons a culminé à 87.1 GB sur un H200 et un état de 32k jetons à 78.7 GB, donc les états les plus longs demandent plus de 80 GB.

git clone https://github.com/jaredpalmer/kev.git && cd kev && uv sync --extra serve
uv run --extra serve python -m kev.serve --run jaredpalmer/kev-27b --port 8008          # v2 (this card)
uv run --extra serve python -m kev.serve --run jaredpalmer/kev-27b@v1-lora --port 8008  # v1

Sur Apple Silicon, la même commande sert via MLX (choisi automatiquement), en chargeant les poids bf16 complets tels qu’enregistrés, sans rien fusionner. Ce chemin est censé fonctionner sur un Mac 96–128 GB mais n’a pas encore été exécuté à cette taille (voir Limites).

from typesafe_sdk import Choice, Noul, TypeSafeClient

client = TypeSafeClient(api_key="local", base_url="http://127.0.0.1:8008", model="kev-latest")
response = client.system_one(
    state="I was charged twice for order 1182. Please refund one of the charges.",
    questions={
        "team": Choice(instructions="Which team should handle this?",
                       criteria={"billing": "Charges and refunds", "shipping": "Deliveries", "returns": "Exchanges"}),
        "urgent": Noul(instructions="Does this need a reply today?"),
    },
)
print(response.choices["team"].choice, response.nouls["urgent"].noul)

La température calibrée est appliquée par défaut ; KEV_TEMPERATURE=1.0 renvoie les probabilités brutes. Le serveur utilise bf16, les noyaux DeltaNet fusionnés et CUDA graphs ; KEV_DTYPE=fp32 sélectionne le chemin exact utilisé pour l’évaluation.

Données d’entraînement

Une époque sur un corpus privé de 145 840 enregistrements (337 130 questions) avec des états d’au plus 32 768 jetons. Seul son manifeste est public (evals/sft-v2-r22/manifest.json dans le dépôt GitHub).

Sources et étiquettes. Les jeux de données publics sont listés dans les métadonnées de cette fiche ; deux sources d’outillage pour développeurs, CodeReviewer et FlakeFlagger, viennent de Zenodo, et les diffs CodeReviewer ne sont conservés que de projets sous licence permissive. Le texte et les étiquettes générés viennent de code ou de modèles à poids ouverts (GLM-5.3, DeepSeek-V4-Pro, Inkling, Mistral Large 3, gpt-oss-120b, MiMo-V2.6-Pro). Les étiquettes de plaintes de consommateurs viennent de modèles à poids ouverts, filtrées par des juges à modèles fermés et une adjudication. Aucune sortie de Jev (le modèle de décision hébergé de TypeSafe) n’a été utilisée.

Licences. Quatre des jeux de données publics plafonnés sont sous partage à l’identique : ARC (CC-BY-SA-4.0), HotpotQA (CC-BY-SA-4.0), Natural Questions (CC-BY-SA-3.0) et SNLI (CC-BY-SA-4.0) ; les autres sont CC-BY-4.0, MIT ou Apache-2.0. Les récits de plaintes CFPB sont des œuvres du gouvernement américain. La licence de GLM-5.3 est de type MIT avec une condition sur les très grands opérateurs de modèle-as-a-service. Les licences, révisions et attributions par source sont consignées dans les manifestes des composants.

Filtrage de contamination. Avant l’entraînement, chaque enregistrement a été filtré contre 102 partitions d’évaluation (76 549 éléments de référence) : toutes les suites Kev gelées, l’ensemble d’évaluation privé, les éléments publics de JevBench et les suites d’évaluation seule ci-dessous. Un enregistrement était retiré sur une correspondance exacte de chaîne normalisée, une similarité de Jaccard en 8-grammes de mots supérieure à 0.2, ou une containment d’au moins 0.5 ; 6 388 enregistrements d’entraînement ont été retirés.

Procédure d’entraînement

1. Fine-tuning à poids complets. Une époque depuis Qwen/Qwen3.8-27B sur 8 GPU NVIDIA H200 (FSDP2). AdamW (β 0.9 / 0.999, weight decay 0.01) avec poids maîtres et moments fp32 sur un backbone bf16 ; taux d’apprentissage 2e-6 pour le backbone et 1e-4 pour la tête, schedule one-cycle avec 10 % d’échauffement ; norme de gradient écrêtée à 1.0 ; 128 enregistrements par pas d’optimiseur (8 par GPU, 2 pas d’accumulation), 1 140 pas ; graine 0. La perte est l’entropie croisée sur les options de chaque question (cibles souples là où les données en ont). L’ordre des options est mélangé et des options « none of the above » et des distracteurs sont insérés au hasard. Un quart des enregistrements choice avec des états d’au plus 8 192 jetons produisent aussi une paire minimale : la question avec une option « none of the above », une fois avec l’option correcte présente et une fois retirée. Chaque état est exécuté une fois et ses questions en dérivent.
2. Moyennage des poids. Chaque tenseur du backbone vaut 0.85 × le poids fine-tuné + 0.15 × le poids de la v1 (l’adaptateur LoRA de la v1 fusionné dans la base en fp32), calculé en fp32 et arrondi une fois en bf16. La tête pointeur du modèle fine-tuné est conservée. Le ratio a été choisi parmi six mélanges (0.85 / 0.70 / 0.50, avec l’une ou l’autre tête) sur des données de développement.
3. Calibration. Une température unique, T = 1.32, minimisant la log-vraisemblance négative sur 648 questions issues de jeux de données tenus à l’écart sur lesquels aucun parent n’a été entraîné : 448 issues de la partition de calibration de transfer-r3 (six jeux de données publics, QNLI, SciQ, TweetEval-offensive, PAWS, MMLU et Emotion, plus deux familles tenues à l’écart d’enregistrements de politique générés) et 200 questions MMLU-Pro (transfer-v9 développement). Aucune partition d’un corpus d’entraînement n’a été utilisée, et un contrôle a constaté l’absence de recouvrement avec les données d’entraînement.

Évaluation

Méthodologie. Chaque comparaison est faite contre Kev-27B v1 sur des éléments identiques, chaque modèle à sa propre température servie. Les partitions de test ont été lues une fois pour ce checkpoint ; le test transfer-v4 est verrouillé (lu une fois par candidat) et a été jugé contre une barre fixée à l’avance (exactitude ≥ 0.886, Brier ≤ 0.165). Les intervalles sont des bootstraps appariés à 95 % qui rééchantillonnent des enregistrements entiers (2 000 rééchantillonnages), donc les questions qui partagent un état bougent ensemble. Les différences sont en points de pourcentage (pp). Les suites :

• breadth-v1 : 14 jeux de données publics tenus à l’écart dans cinq domaines (connaissances, langue, recherche d’information, outils, arts), jamais entraînés.
• tasksource-heldout-v1 : 24 familles de tâches entières de la même collection multi-tâches que le composant sous licence, tenues à l’écart de l’entraînement.
• hard-v1 : enregistrements de compétences étiquetés par programme (politiques longues, compromis, probabilité, multi-sauts, dates et nombres, jugement, abstention) ; la partition de test met de côté des gabarits de générateurs entraînés.
• devtools-v1 : décisions d’outillage pour développeurs issues de sources publiques vérifiées quant à leur licence (revue de code, messages de commit, sécurité, tests instables).
• documents-v1 / documents-v2 : récits de plaintes de consommateurs américains (CFPB) ; v2 est un ensemble de test privé tenu à l’écart.
• transfer-v4 : décisions hors domaine issues de six sources publiques jamais entraînées plus des structures de politique tenues à l’écart.
• longdoc-v1 : contrats commerciaux CUAD allant jusqu’à 64k jetons, et ensembles d’accords générés.

Les panneaux phares excluent les éléments qu’un audit d’étiquettes, achevé avant que ce checkpoint ne soit construit, a jugés non valables¹ ; chaque exclusion retire les mêmes lignes des deux modèles.

Résultats contre la v1 (partitions de test).

Comparaison avec d’autres modèles de décision sur breadth-v1 test (les 14 jeux de données), notée avec l’indice corrigé du hasard du Decision Index communautaire 0.2 (par jeu de données (score − hasard) / (1 − hasard), moyenné dans chaque domaine, puis 100 × la moyenne des cinq domaines). Jev a été interrogé via Vercel AI Gateway et AutoJev-27B (denis-pplx/autojev-27b, un fine-tuning à poids complets de la même base) via son propre serveur, une fois chacun, sur les mêmes éléments.

Contre la v1, la différence d’indice est de +2.1 [−0.4, +4.6]. Aucun intervalle apparié contre Jev n’a été calculé.

Documents longs (contrats CUAD dans longdoc-v1 test, exactitude / ECE selon la longueur de l’état en jetons) :

Différence d’exactitude sur toutes les longueurs : −1.6 [−3.0, −0.3]. Sur les ensembles d’accords générés (2 400 questions), les deux modèles obtiennent 1.000.

Longueur de contexte. Longueur de contexte validée : 65 536 jetons, la limite de service, d’après longdoc-v1 développement (différence d’exactitude CUAD appariée par rapport au bucket 8k, pp [IC 95 %] : 16k +0.2 [−0.7, +1.2], 32k −0.2 [−1.2, +0.7], 64k −1.1 [−2.4, +0.0] ; 445–447 questions chacune). La règle est celle appliquée à chaque taille de Kev 1.0 : la longueur validée est la taille nominale du plus grand bucket à partir de 16 384 jetons tel que lui-même, et chaque bucket entre lui et 8 192, soit dans la tolérance, c’est-à-dire que la différence d’exactitude CUAD par rapport au bucket 8k, appariée sur le même contrat, la même répétition et la même question, a une borne inférieure à 95 % d’au moins −3 pp, chaque enregistrement ayant reçu une réponse.

Calibration (erreur de calibration attendue, ECE, telle que servie ; plus bas est mieux) :

Sur les 648 questions d’ajustement, une validation croisée à 5 plis avec groupes disjoints abaisse l’ECE de 0.048 (brut) à 0.038 (hors pli) ; les deux intervalles se recouvrent. L’intervalle bootstrap à 90 % de la température est [1.20, 1.45]. À ses extrémités, les panneaux phares bougent en sens opposés : l’ECE breadth-v1 monte à 0.026 à T = 1.20 et l’ECE tasksource-heldout-v1 à 0.067 à T = 1.45.

Autres résultats.

transfer-r3 test est un panneau à états courts issu des huit mêmes sources tenues à l’écart que le pool de calibration ; decision-v7 est la distribution d’entraînement de la v1 ; transfer-v9 contient MMLU-Pro et des éléments dont la preuve décisive a été retirée. SemIf (décisions rédigées à la main issues du projet SemIf), WANLI-v2 (paires d’inférence en langage naturel de la partition de test WANLI) et TypeSafe (la sélection de cas de flux de travail TypeSafe par SemIf) sont rapportés seulement : l’audit d’étiquettes les a jugés trop petits, saturés ou bruités pour classer des modèles. WANLI-v2 et TypeSafe ont été retirés comme évaluations le 2026-09-30 (environ un quart des paires WANLI ont été étiquetées différemment par ses deux annotateurs, avec l’or fixé à l’une des deux étiquettes ; l’or de TypeSafe est la réponse moyennée de deux modèles frontière fermés, sur trop peu de questions pour distinguer les checkpoints) ; leurs chiffres sont conservés comme enregistrement.

Parité de service (H200, bf16 avec noyaux fusionnés et CUDA graphs, 200 enregistrements de développement decision-v7 / 280 questions) :

¹ Exclus des panneaux phares : quatre jeux de données breadth-v1 (routerbench, dont les états n’ont pas l’information demandée ; cfcolor et humicroedit, au hasard pour tout système ; chessbench, au plancher pour tout système) ; sept familles tasksource-heldout-v1 avec des étiquettes invalides ou irrécupérables (noms privés) ; et deux tâches devtools-v1 dont les étiquettes ne sont pas déterminées par l’état (flakeflagger, type de changement de commit). La source transfer-r3 emotion (étiquettes par mots-clés lointains) est exclue du panneau à états courts dans Limites.

Limites et compromis

• Sélection. Le checkpoint publié a été choisi après que les résultats de test d’un candidat antérieur furent connus et confirmé sur les mêmes ensembles de test. Traite les marges de test comme optimistes.
• Aucun gain sur les états courts. Il n’est pas meilleur que la v1 sur des entrées courtes : −0.8 pp [−2.0, +0.5] sur le test transfer-v4 verrouillé, −0.9 pp [−2.0, +0.1] sur le panneau de développement à états courts (transfer-v4 développement et transfer-r3 test sans emotion), et −2.1 pp [−3.5, −0.8] sur tout le test transfer-r3.
• Pire et trop confiant sur les contrats longs. Sur CUAD, il est 1.6 pp moins exact que la v1 et son ECE vaut 2 à 4 fois celui de la v1 à chaque longueur (0.053 contre 0.007 au total). Les questions CUAD incluent quelques étiquettes or erronées ou contestées, mais l’écart est cohérent sur toutes les longueurs. Pour la revue de contrats, réajuste la température sur des documents étiquetés qui sont à toi (python -m kev.calibrate) ou utilise la v1.
• Gains en distribution. Les partitions d’entraînement de hard-v1, devtools-v1 et documents-v1 sont dans les données d’entraînement, et les suites ood-v2, agents-ood-v1 et guardrails-ood-v1 sont des domaines tenus à l’écart de générateurs qui ont aussi produit des données d’entraînement. Les gains y mesurent des éléments tenus à l’écart de familles entraînées, pas un transfert à de nouvelles tâches.
• Entraînement de la base inconnu. La base est la publication post-entraînée de Qwen ; ses données d’entraînement ne sont pas connues, donc un recouvrement entre elle et une évaluation ne peut pas être exclu.
• Connaissances. Les connaissances sont fixées par la base : MMLU-Pro est 0.675, contre 0.840 pour Jev sur les mêmes éléments.
• Longueurs non entraînées. Des états de 32k–64k jetons ont été évalués (longdoc-v1) mais pas utilisés à l’entraînement.
• Suite retirée. Une suite de tickets de support utilisée pour sélectionner la v1 (scienthoon) a été retirée comme non valable avant la construction de la v2, donc la v2 n’a aucun résultat dessus. Le parent fine-tuné non moyenné de la v2 y a obtenu 5.5 pp [−7.8, −3.2] de moins que la v1.
• Incertitude de la température. L’intervalle de la température ([1.20, 1.45]) déplace l’ECE de test d’au plus environ 0.02.
• Matériel. Il a besoin d’un GPU de centre de données de classe 80 GB (plus de 80 GB pour les états les plus longs). Apple Silicon via MLX : les poids bf16 complets de la v2 ont besoin d’environ 51 GB plus la mémoire de travail, donc un Mac 64 GB est limite et un Mac 96–128 GB devrait convenir. Cela est attendu d’après des mesures sur des modèles plus petits, pas encore mesuré sur un grand Mac : charger un Kev-4B à poids complets par le même chemin a culminé à la taille de ses poids (8.4 GB), et ses réponses restaient à moins de 0.015 du chemin d’évaluation fp32 (runs/mlx-full-4b). La v1 (l’adaptateur LoRA, étiquette v1-lora) a été servie via MLX sur un M5 Max 128 GB par un contributeur externe (PR #175) : 0.849 d’exactitude sur transfer-v4 développement contre 0.848 publié, 52 GB en régime stable et 97 GB au pic pendant la fusion de l’adaptateur.

Biais, risques et considérations éthiques

• Des probabilités calibrées peuvent créer une confiance injustifiée. La température a été ajustée sur des jeux de données publics tenus à l’écart et ne se transfère pas à chaque charge de travail ; mesure l’exactitude et la calibration sur un échantillon étiqueté de tes propres données avant de fixer des seuils.
• L’exactitude et la calibration bougent sous changement de domaine (par exemple sur les contrats longs). Surveille les taux d’erreur en production plutôt que de te fier aux chiffres ci-dessus.
• Ne l’utilise pas pour des décisions automatisées lourdes de conséquences sur des personnes sans revue humaine. Les biais du modèle de base et des données d’entraînement (y compris les étiquettes produites par d’autres modèles) ne sont pas mesurés.
• Les états peuvent contenir des données personnelles ou confidentielles. L’auto-hébergement garde les entrées sur ton propre matériel ; le serveur est ouvert sauf si KEV_API_KEY est défini, donc applique ta propre politique de contrôle d’accès et de traitement des données.

Calcul

• Fine-tuning : 8 × NVIDIA H200 pendant 16.2 h de temps d’entraînement (129 heures-GPU), hors redémarrages et évaluation.
• Moyennage des poids : environ 6 minutes sur CPU.
• Vérifications d’évaluation et de service : GPU H200 uniques sur Modal.

Provenance et reproductibilité

• Code, suites et rapports d’évaluation : github.com/jaredpalmer/kev. Chiffres de publication : runs/release/kev-27b-r23.json (scripts/release_numbers.py --release kev-27b-r23).
• Fine-tuning : essai de la ronde 22 r22-27b-lr2e6/00-trial-0 (experiments/round22/lr2e6.json), sha256 des poids 3fa0182a…. Mélange : bras de la ronde 23 27b-k-w85 (scripts/interpolate_checkpoint.py --toward ; interpolation.json dans le dépôt Hub), règle de sélection et étapes de confirmation dans experiments/rounds/r23.json ; résultats dans runs/r23-readout/, runs/r23-verdict/, runs/r23-breadth-report/, runs/serving-27b-r23*/.
• Source du mélange : v1 à jaredpalmer/kev-27b@01b81998 (essai r6-27b-v2/01-trial-1), désormais étiquette v1-lora.
• Poids publiés sha256 d27af6ab2be16824166ac639907b4dba40979ff338599c2872721aa6c5072022 ; sha256 de head.pt 7968f17b03479c1ef9d1c0f3ab8a15e31ecb441cf40691b07ee945ab554d45ad (T = 1.3195). Poids publiés dans le commit Hub 28be62e9.
• Vérification : chargé anonymement depuis le Hub sur un H200, il a reproduit exactement les logits de l’évaluation d’avant publication sur 252 des 252 lignes SemIf et 764 des 764 lignes de développement transfer-v4 (runs/release/kev-27b-r23-published.json, runs/release/kev-27b-r23-staging.json).

Citation

@misc{palmer2026kev27b,
  title        = {Kev-27B: a calibrated decision model on Qwen3.8-27B},
  author       = {Palmer, Jared},
  year         = {2026},
  howpublished = {\url{https://huggingface.co/jaredpalmer/kev-27b}},
  note         = {Version 2, released 2026-09-30}
}

Contact

Questions et problèmes : github.com/jaredpalmer/kev/issues.