Kev-9B

Résumé du modèle

Kev-9B 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 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. C’est un adaptateur LoRA et une tête pointeur sur Qwen3.5-9B-Base, et il tient dans un GPU de classe 24 GB. Cette fiche décrit la version 2, publiée le 2026-09-30 et incluse dans Kev 1.0.

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 de quelques milliers de jetons : 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 sur un seul GPU de classe 24 GB, et un point de départ pour un fine-tuning sur les propres étiquettes de l’utilisateur (kev.train --init_from jaredpalmer/kev-9b).

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, et examens très dépendants de connaissances (voir Limites).
• Arithmétique de dates à précision du jour sans le préprocesseur KEV_DATE_FACTS=1, é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 L40S ou une H100 ; environ 22 GB résidents) ; 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-9b --port 8008          # v2, Kev 1.0 (this card)
uv run --extra serve python -m kev.serve --run jaredpalmer/kev-9b@v1 --port 8008       # v1

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. KEV_DATE_FACTS=1 ajoute le nombre de jours entre chaque paire de dates trouvée dans l’état, ce que le modèle a été entraîné à utiliser. 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 10 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 5e-5, schedule one-cycle ; batch effectif 8 (4 × 2 d’accumulation) ; autocast bf16, gradient checkpointing. 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 2e-5 avec 2 000 enregistrements rejoués. C’est la v1.
3. Documents et compétences. Une époque depuis la v1 sur les trois ensembles d’entraînement réunis au taux d’apprentissage 2e-5 avec 10 000 enregistrements rejoués ; batch 2 × 4 d’accumulation ; états d’au plus 7 552 jetons ; graine 1 ; 3 318 pas d’optimiseur.
4. Calibration. Une température unique, T = 2.19, minimisant la log-vraisemblance négative sur 648 questions issues de jeux de données tenus à l’écart : 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). Le pool a été vérifié contre les suites d’entraînement du checkpoint avant l’ajustement.

Évaluation

Méthodologie. Chaque comparaison est faite contre Kev-9B v1 sur des éléments identiques, chaque modèle à sa propre température servie (v1 : 2.30). Les comparaisons et leurs barres ont été enregistrées avant les lectures de confirmation ; les partitions de test ont été lues une fois pour ce checkpoint ; le test transfer-v4 est verrouillé (lu une fois par candidat). 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.
• transfer-v4 : décisions hors domaine issues de six sources publiques jamais entraînées plus des structures de politique et de règles tenues à l’écart.
• transfer-r3 : un panneau à états courts issu des huit mêmes sources tenues à l’écart que le pool de calibration.
• 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 de devtools-v1 excluent deux tâches dont les étiquettes ne sont pas déterminées par l’état (flakeflagger, type de changement de commit) ; les mêmes lignes quittent les deux côtés.

Résultats contre la v1 (confirmation enregistrée).

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

Contre la v1, la différence d’exactitude breadth-v1 est de +0.3 [−0.7, +1.3] en développement et +0.6 [−0.4, +1.6] en test. tasksource-heldout-v1 développement a été lu pour ce checkpoint mais son read-out n’est pas complet ; il n’est pas rapporté ici.

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

Différences en test contre la v1 : hard-v1 +25.0 [+22.0, +28.1], devtools-v1 (toutes sources) +15.4 [+11.0, +19.4], documents-v2 +8.0 [+5.9, +10.2].

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 −3.7 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.19. Δ 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/r29-9b-r18a-longdoc).

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

L’intervalle bootstrap à 90 % de la température est [2.05, 2.41]. Le 2.30 de la v1 a été ajusté sur des lignes de développement de sa propre distribution d’entraînement ; la v2 est le premier 9B servi à une température ajustée sur des jeux de données tenus à l’écart.

Autres résultats.

Service. CUDA, bf16 avec noyaux fusionnés et CUDA graphs ; temps de modèle par requête (médiane sur 20) pour un état nouveau / répété, mesuré sur la v1 (même architecture et même forme d’adaptateur) :

La mémoire GPU résidente est de 21.9 GB. Les probabilités servies restent à moins de 0.017 du chemin d’évaluation fp32 sur 280 questions, sans réponse changée. Sur le chemin d’évaluation fp32 (H100, v2), les états de 16k / 32k / 64k jetons prennent 5.1 / 10.9 / 25.4 s et 4.6 / 9.1 / 18.2 GiB au-dessus des poids.

Apple Silicon (MLX) : les mesures à états longs faites pour Kev-0.8B et Kev-4B n’ont pas été faites à cette taille ; sur le M5 32 GB utilisé pour elles, le backbone bf16 de 19.3 GB et son ensemble de travail ne tenaient pas dans la mémoire disponible.

¹ 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

• Sélection. Ce checkpoint a été entraîné et lu sur des données de développement lors d’une ronde antérieure, puis resélectionné sous une règle ultérieure avec ces chiffres connus. Les partitions de test et la lecture verrouillée, chacune lue une fois pour lui, servent de garde ; traite les marges de développement comme optimistes.
• Ses grands gains sont en distribution. Les partitions d’entraînement de hard-v1, devtools-v1 et documents-v1 sont dans ses données d’entraînement ; ces gains portent sur des éléments et gabarits tenus à l’écart de familles entraînées, pas sur un transfert à de nouvelles tâches.
• Il n’est pas meilleur que la v1 sur du travail nouveau. breadth-v1 test +0.6 pp [−0.4, +1.6], transfer-v4 développement −0.2 pp [−2.4, +1.8], transfer-r3 test +0.0 pp [−1.2, +1.2]. Kev-27B le devance de 11 points sur l’indice breadth-v1, Jev de 13.
• Les connaissances sont fixées par la base. MMLU-Pro est 0.590, contre 0.675 pour Kev-27B et 0.840 pour Jev.
• L’arithmétique de dates est sa famille la plus faible : 0.725 sur les questions de politique deadline contre 0.95 pour Jev ; le préprocesseur KEV_DATE_FACTS=1 aide.
• Calibration. devtools-v1 est sa suite la moins calibrée (test ECE 0.098). L’intervalle de la température est [2.05, 2.41]. La température a été écrite dans head.pt à partir de l’ajustement enregistré du pool, avec la raison consignée, parce que le script de calibration ne peut pas lister les sources du fichier d’entraînement combiné pour revérifier le pool lui-même ; la vérification propre à la ronde l’avait couvert. Cette vérification ne couvre pas les données de dates et de preuves manquantes de la v1, dont le manifeste ne liste aucune source ; ces enregistrements sont quatre familles générées, aucune d’elles dans le pool.
• 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 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, 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. 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 et étape dates (v1) : GPU NVIDIA H100 uniques.
• Étape documents et compétences : 2.6 heures sur un NVIDIA H200 (pic 74.1 GB).
• Vérifications d’évaluation et de service : GPU H100 / H200 / L40S uniques sur Modal.

Provenance et reproductibilité

• Code, suites et rapports d’évaluation : github.com/jaredpalmer/kev. Chiffres de publication : runs/release/kev-9b-r27.json (scripts/release_numbers.py --release kev-9b-r27) ; règle enregistrée et verdicts experiments/rounds/r27.json, runs/r27-readout/, runs/r27-verdict/ ; les lectures de famille du 2026-09-30 runs/fam-9bnew-breadth/, runs/fam-9b-breadth/ et runs/fam-breadth-test-report/ ; ood-v2 runs/r29-9b-r18a-ood/ ; service runs/serve-9b-l40s/, runs/serve-9b-h100/, runs/long-state-9b-h100/.
• Étapes : essai de base q35-9b/01-trial-1 (étiquette v7-base) ; dates night2-9b-du/00-trial-0 (v1, étiquette v1) ; documents et compétences ronde 18 bras (a) r18-9b/00-trial-0 (experiments/round18/joint.json), sélectionné et confirmé comme 9b-r18a de la ronde 27.
• Poids publiés : commit Hub b5d8c18e ; sha256 de l’adaptateur 2b2a70cf4ef4440b6c22899e1f72c2f8ea5c6f65b19aa344539b4b8971d1f13d, sha256 de head.pt 8e1dab2c… (T = 2.1936).
• Vérification : chargé anonymement depuis le Hub, il a reproduit les réponses de l’évaluation d’avant publication sur 252 des 252 lignes SemIf et 764 des 764 lignes de développement transfer-v4 à T = 2.19 (runs/rel9-public/).

Citation

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

Contact

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