Kev-0.8B

Résumé du modèle

Kev-0.8B 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 implémente l’API System One publique de TypeSafe (POST /v1/systemone), donc le SDK TypeSafe fonctionne avec lui sans modification. C’est le plus petit Kev : un adaptateur LoRA et une tête pointeur sur Qwen3.5-0.8B-Base, qui tourne sur un ordinateur portable ou un GPU 4 GB. Il est destiné aux cas où la mémoire ou le coût écartent les tailles supérieures et où la tâche ressemble à ce sur quoi il a été entraîné ; hors domaine, il est nettement moins exact que Kev-4B. Cette fiche décrit le checkpoint de Kev 1.0, publié pour la première fois le 2026-09-24.

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 proches de ses familles d’entraînement (classification de documents, routage, contrôles de politique sur des règles énoncées) sur du matériel trop petit pour Kev-4B : un ordinateur portable, une L4 ou un GPU 4 GB.
• Un point de départ pour un fine-tuning sur les propres étiquettes de l’utilisateur là où le coût d’entraînement compte (kev.train --init_from jaredpalmer/kev-0.8b).
• Prototyper contre l’API System One avant de passer à un Kev plus grand.

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.
• Routage d’appels d’outils (s’il faut appeler un outil, demander un paramètre manquant ou refuser) : son exactitude When2Call est sous le hasard (voir Limites).
• 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 très dépendantes de connaissances, arithmétique de dates, états de plus de 65 536 jetons et langues autres que l’anglais.

Comment l’utiliser

Sers-le avec le dépôt Kev. Sur CUDA, il tourne en bf16 avec les noyaux DeltaNet fusionnés et CUDA graphs (une L4 suffit) ; sur Apple Silicon, la même commande le sert via MLX, choisi automatiquement.

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-0.8b --port 8008        # Kev 1.0 (this card)
uv run --extra serve python -m kev.serve --run jaredpalmer/kev-0.8b@v1.0 --port 8008   # the same weights, pinned

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. KEV_DTYPE=fp32 sélectionne le chemin exact utilisé pour l’évaluation. Un état de plus de 65 536 jetons est refusé par un 422 qui donne son nombre de jetons.

Données d’entraînement

Les deux étapes de fine-tuning rejouent 2 000 et 6 000 enregistrements de decision-v7. Aucune sortie de Jev (le modèle de décision hébergé de TypeSafe) n’a été utilisée. CodeReviewer et FlakeFlagger viennent de Zenodo ; les récits CFPB sont des œuvres du gouvernement américain ; les licences et révisions par source sont consignées dans les manifestes des suites. Les suites d’évaluation seule ci-dessous (breadth-v1, tasksource-heldout-v1, transfer-v4, longdoc-v1, et les sources When2Call et injection de prompt de devtools-v1) n’entrent jamais dans l’entraînement.

Procédure d’entraînement

1. Recette de base. Deux époques sur decision-v7 depuis la base : LoRA rang 16, α 32 ; taux d’apprentissage 1e-4, schedule one-cycle ; batch 8 ; autocast bf16 ; graine 2. La perte est l’entropie croisée sur les options de chaque question. L’ordre des options est mélangé, des options « none of the above » et des distracteurs sont insérés au hasard, et un quart des enregistrements choice 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).
2. Dates et preuves manquantes. Une époque depuis l’étape 1 au taux d’apprentissage 4e-5 avec 2 000 enregistrements rejoués.
3. Documents et compétences. Une époque depuis l’étape 2 sur les trois ensembles d’entraînement réunis au taux d’apprentissage 2e-5 avec 6 000 enregistrements rejoués ; batch 4 × 2 d’accumulation ; états d’au plus 7 552 jetons ; gradient checkpointing ; graine 1 ; 2 818 pas d’optimiseur.
4. Calibration. Une température unique, T = 2.35, minimisant la log-vraisemblance négative sur les lignes de développement decision-v7 de l’essai de l’étape 3 (1 264 questions). Ce sont des éléments tenus à l’écart d’un corpus d’entraînement. Un réajustement sur des jeux de données tenus à l’écart a été évalué et non adopté (voir Calibration).

Évaluation

Méthodologie. Chaque chiffre est le chemin d’évaluation fp32 à la température livrée, sauf indication contraire. Les partitions de développement ont servi à la sélection ; 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. Les intervalles appariés sont des bootstraps à 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). Jev (le modèle hébergé de TypeSafe, interrogé via Vercel AI Gateway) est montré là où il a été lu sur les mêmes éléments. 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 d’une collection multi-tâches publique, jamais entraînées (noms des familles privés).
• transfer-v4 : décisions hors domaine issues de six sources publiques jamais entraînées (QNLI, SciQ, TweetEval-offensive, PAWS, MMLU, Emotion) plus des structures de politique et de règles tenues à l’écart.
• hard-v1 : les familles de compétences ci-dessus ; 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 six sources vérifiées quant à leur licence (quatre entraînées, deux en évaluation seule).
• documents-v1 / documents-v2 : récits de plaintes CFPB ; v2 est un ensemble de test privé tenu à l’écart.
• longdoc-v1 : contrats commerciaux CUAD et ensembles d’accords générés, avec des états de 4k à 64k jetons.

Les panneaux phares marqués « audited » excluent les éléments qu’un audit d’étiquettes a jugés non valables¹ ; chaque exclusion retire les mêmes lignes des deux côtés d’une comparaison.

Données tenues à l’écart (jamais entraînées).

Familles entraînées (éléments et gabarits tenus à l’écart).

Le chiffre devtools-v1 de Jev porte sur les 1 074 questions de développement ; les lignes de Kev retirent un id CodeReviewer que le constructeur de la suite a réutilisé pour deux enregistrements (2 questions).

Contre la version précédente (étiquette night2-du-release, à sa propre température 2.41 ; critères enregistrés, chaque test lu une fois) :

Documents longs.

• Longueur de contexte validée : 8 192 jetons, la longueur d’entraînement. Le bucket 16k est hors tolérance : sa borne inférieure est −8.5 pp, sous −3 pp, donc aucune longueur supérieure n’est validée.
• Règle, fixée avant la lecture : 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. Être dans la tolérance signifie que la différence d’exactitude CUAD par rapport au bucket 8k (états de 6 553–7 618 jetons, la longueur d’entraînement), 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, et que chaque enregistrement a reçu une réponse. Si le bucket 16k échoue, la longueur validée est 8 192 jetons.

Exactitude CUAD, ECE et différence appariée par rapport au bucket 8k selon la longueur nominale de l’état (longdoc-v1 développement) :

ECE à la température livrée T = 2.35. Δ est apparié sur les 445–447 questions posées sur les mêmes contrats aux deux longueurs. Le bucket 4k contient d’autres contrats et ne sert pas de référence pour la règle. Source : runs/r28-readout/context.json (le read-out enregistré de la ronde 28, runs/r28-08b-r15-longdoc).

Calibration (erreur de calibration attendue, ECE, à la température livrée T = 2.35 ; plus bas est mieux) :

La température livrée a été ajustée sur des éléments tenus à l’écart d’un corpus d’entraînement, ce que les règles du projet n’autorisent plus pour une nouvelle publication. Un réajustement enregistré sur 648 questions issues de jeux de données tenus à l’écart (la partition de calibration de transfer-r3, huit sources, et 200 questions MMLU-Pro) donne T = 2.52 (intervalle bootstrap à 90 % [2.19, 2.83]). Sur les 4 468 questions de développement breadth-v1 et tasksource-heldout-v1 audited, il est mieux calibré : ECE 0.037 contre 0.048, Brier inférieur de 0.0020 [0.0014, 0.0025]. Il est pire sur les familles entraînées, chacune de plus que la tolérance enregistrée de 0.005 : hard-v1 ECE 0.124 contre 0.112, devtools-v1 (audited) 0.099 contre 0.092, documents-v1 0.078 contre 0.059. Le réajustement n’a donc pas été retenu, et T = 2.35 reste. Les utilisateurs dont la charge de travail ressemble davantage à des jeux de données publics tenus à l’écart qu’aux familles d’entraînement de Kev peuvent le servir à la valeur du réajustement avec KEV_TEMPERATURE=2.52 ; les réponses ne dépendent pas de T.

Autres résultats.

Service. CUDA, bf16 avec noyaux fusionnés et CUDA graphs, sur une L4 ; temps de modèle par requête (médiane sur 20) pour un état nouveau / répété : 22.7 / 16.1 ms pour six questions sur un état court, 108.6 / 32.3 ms pour cinq questions sur un état de 2 200 jetons ; 62.8 requêtes/s à 64 clients. La mémoire GPU résidente est de 3.8 GB. Les probabilités servies restent à moins de 0.017 du chemin d’évaluation fp32 sur 280 questions, avec 1 réponse changée.

Apple Silicon (MLX, bf16, M5 avec 32 GB ; trois questions, une portant sur un fait planté à 60 % de profondeur ; l’état est prérempli par blocs de 1 024 jetons) :

Contre PyTorch fp32 sur CPU sur les mêmes requêtes, les réponses MLX diffèrent d’au plus 0.0076 à 8k et 0.0052 à 16k jetons, sans réponse changée. Sur 100 questions à état court, le chemin MLX reste à moins de 0.020 du chemin d’évaluation fp32, avec 1 réponse changée.

¹ Exclus des panneaux audited : 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) ; deux tâches devtools-v1 dont les étiquettes ne sont pas déterminées par l’état (flakeflagger, type de changement de commit).

² 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. L’indice de Jev vient d’une lecture séparée des mêmes éléments de test.

Limites et compromis

• C’est un modèle de moins de 1B hors domaine. Il est à 21 points derrière Jev sur le développement transfer-v4 et à 31 points sur l’indice breadth-v1 ; les connaissances (MMLU-Pro 0.230) et la paraphrase sont proches de la base non entraînée. Utilise Kev-4B là où l’exactitude compte.
• Ses gains sont en distribution. Les partitions d’entraînement de documents-v1, hard-v1 et devtools-v1 sont dans ses données d’entraînement ; sur le palier difficile public de JevBench, un contrôle hors distribution, l’étape documents et compétences l’a déplacé de +2.7 pp [−1.8, +7.2], non distinguable de zéro.
• Le routage d’appels d’outils s’est dégradé. When2Call, une source en évaluation seule, est passé de 0.260 à 0.167 en développement et de 0.233 à 0.133 en test, sous le taux d’une chance sur quatre de deviner parmi ses quatre options. Ne l’utilise pas pour le routage d’appels d’outils.
• Un résultat devtools-v1 est inexpliqué. FlakeFlagger est passé de 0.500 → 0.520 en développement mais de 0.507 → 0.813 en test, sur 150 questions par partition ; traite-le comme inexpliqué, pas comme une compétence.
• L’arithmétique de dates est sa famille la plus faible : 0.35 sur les questions de politique deadline contre 0.95 pour Jev ; le préprocesseur KEV_DATE_FACTS=1 aide les plus grands modèles plus que celui-ci.
• La composition de règles est faible : les deux jumeaux d’une paire minimale de politique tenue à l’écart sont corrects 0.422 du temps.
• La calibration est une seule température en distribution (voir Calibration). Elle ne peut pas réordonner les confiances : la couverture à ≤ 5 % d’erreur hors domaine est de 0.145 en développement contre 0.70 pour Jev, donc peu de décisions peuvent être automatisées à un budget d’erreur strict.
• Longueurs non entraînées. Les états d’entraînement faisaient au plus 7 552 jetons. Les états plus longs sont servis jusqu’à 65 536 jetons ; jusqu’où l’exactitude tient est la longueur de contexte validée ci-dessus.
• L’ordre des options peut changer une réponse ; l’isolation des questions ne l’empêche pas.

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 lignes de développement de la distribution d’entraînement 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, et réajuste-y la température (python -m kev.calibrate), avant de fixer des seuils.
• L’exactitude et la calibration bougent sous changement de domaine, davantage à cette taille qu’à des tailles supérieures. 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

• Recette de base : environ 20 minutes sur un NVIDIA H100. Étape dates : 9 minutes.
• Étape documents et compétences : 52 minutes sur un NVIDIA H200 (pic 23.9 GB).
• Vérifications d’évaluation et de service : GPU H100 / H200 / L4 uniques sur Modal ; mesures MLX sur un Apple M5.

Provenance et reproductibilité

• Code, suites et rapports d’évaluation : github.com/jaredpalmer/kev. Chiffres de publication : runs/release/kev-08b-r15.json (scripts/release_numbers.py --release kev-08b-r15), la lecture verrouillée runs/locked/kev-08b-r15-ungated/, les lectures de famille du 2026-09-30 runs/fam-08b-breadth/, runs/fam-08b-breadthtest/ et runs/fam-breadth-test-report/, le réajustement de calibration runs/r28-readout/round28.json, le service runs/serve-08b-l4/, runs/mlx-long-states/, runs/mlx-full-0.8b/.
• Étapes : essai de base q35-08b/02-trial-2 (étiquette v7-base) ; dates night2-08b-du2/00-trial-0 (étiquette night2-du-release) ; documents et compétences ronde 15 r15-08b/00-trial-0 (experiments/round15/joint.json, règle experiments/rounds/r15.json). Réajustement de calibration : bras 28 08b-r15 (experiments/rounds/r28.json).
• Poids publiés : révision Hub 9a45d25e ; sha256 de l’adaptateur 9b908623…, sha256 de head.pt f400bd12… (T = 2.3511).
• Historique de publication : publié le 2026-09-24 comme candidat confirmé de la ronde 15 ; inclus sans changement dans Kev 1.0. Le récit de sa sélection, y compris les suites depuis retirées comme non valables (scienthoon, WANLI-v2, TypeSafe), est le README à la révision Hub 9a45d25e et PLAN.md à l’étiquette git research-archive-2026-09-24.

Citation

@misc{palmer2026kev08b,
  title        = {Kev-0.8B: a calibrated decision model on Qwen3.5-0.8B},
  author       = {Palmer, Jared},
  year         = {2026},
  howpublished = {\url{https://huggingface.co/jaredpalmer/kev-0.8b}},
  note         = {Kev 1.0}
}

Contact

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