Kev 1.0

Kev 1.0 est la première publication versionnée de toute la famille Kev : quatre modèles de décision qui lisent un document et un ensemble de questions typées et renvoient des probabilités calibrées sur les options, en une seule passe avant, derrière l’API System One de TypeSafe. Rien n’y est nouvellement entraîné. Elle épingle les checkpoints, les fiches de modèle, les suites d’évaluation et le code de service contre lesquels la prochaine génération de Kev est mesurée, avec la même étiquette (v1.0) sur chaque dépôt Hub.

Ce que contient la 1.0

Chiffres phares (chemin d’évaluation fp32, chaque modèle à sa température livrée ; le test transfer-v4 est verrouillé et a été lu une fois par modèle) :

hard-v1, devtools-v1 et documents-v1 ont des partitions d’entraînement sur lesquelles tous les Kev se sont entraînés : ces lignes mesurent des éléments tenus à l’écart de familles entraînées, pas du transfert. Les lignes breadth-v1 et transfer-v4 portent sur des jeux de données sur lesquels aucun Kev ne s’est entraîné. Jev a été lu sur les partitions de développement et sur le test breadth-v1 seulement. Chaque chiffre remonte à un rapport commité via docs/claims.json ; les fiches de modèle (docs/model-cards/) contiennent le reste, avec les intervalles.

Ce qui a changé depuis la dernière publication de famille

Mesuré depuis la publication GitHub kev-family telle qu’assemblée pour la première fois pour la famille actuelle le 2026-09-24 (Kev-27B v1, Kev-9B v1, et les mêmes Kev-4B et Kev-0.8B qu’ici). Ses mises à jour du 2026-09-30 (Kev-27B v2, Kev-9B v2) sont aussi listées ici, puisque c’est dans la 1.0 qu’elles font partie d’une publication versionnée.

• Kev-27B v2 : poids complets. Chaque poids de Qwen3.8-27B fine-tuné pendant une époque sur un corpus de 145 840 enregistrements, puis moyenné 0.85 / 0.15 avec la v1. Contre la v1 en test : jeux de données tenus à l’écart +1.2 pp [+0.3, +2.2], familles de tâches tenues à l’écart +5.3 [+3.7, +6.8], compétences, outillage et documents +8.9 [+7.5, +10.3] ; test hors domaine verrouillé 0.889 contre 0.896, Brier 0.154 contre 0.160. Pire et trop confiant sur les contrats longs (CUAD ECE 0.053 contre 0.007). La v1 est à jaredpalmer/kev-27b@v1-lora.
• Kev-9B v2. La v1 plus une époque sur les données de documents et de compétences que Kev-4B et Kev-0.8B avaient déjà. Contre la v1 en test : hard-v1 + devtools-v1 +18.7 pp [+16.7, +20.8], documents-v1 +7.1 [+4.7, +9.2] ; au niveau du test hors domaine verrouillé (0.852 pour les deux) avec Brier 0.199 contre 0.224. La v1 est à jaredpalmer/kev-9b@v1.
• Pas de troncature silencieuse. Le serveur coupait auparavant un état plus long que sa limite sans le dire. Il refuse désormais un état de plus de 65 536 jetons par un 422 qui nomme le nombre de jetons et la limite ; KEV_TRUNCATE_STATES=1 réactive la troncature, et chaque réponse d’un tel serveur dit alors truncated. Les compétences de déploiement et de fine-tuning épinglent KEV_REF sur un commit qui contient ce correctif ainsi que les changements de documents longs et de MLX ci-dessous (71d4829), et le Space a été republié après le correctif.
• Documents longs à toutes les tailles. Le chemin d’évaluation gardait une attention fp32 pour les longues lignes sur le noyau mathématique, donc Kev-0.8B, 4B et 9B tombaient à court de mémoire GPU sur des états de 32k–64k jetons. Les longues lignes exécutent désormais le noyau économe en mémoire en fp32 : Kev-4B lit un état de 61k jetons en 17.2 s avec 17.2 GiB au-dessus des poids sur un H100, et les lignes plus courtes conservent leurs logits au bit près. C’est ce qui rend mesurables les longueurs de contexte validées ci-dessus.
• Apple Silicon. Le backend MLX charge les checkpoints à poids complets tels qu’enregistrés, sans fusion, ce qui donne à Kev-27B un chemin Mac (censé avoir besoin d’environ 51 GB plus la mémoire de travail ; pas encore exécuté à cette taille). Les états longs sont préremplis par blocs de 1 024 jetons et le cache est évincé avant une passe, donc Kev-4B sert un état de 65 000 jetons sur un M5 32 GB à un pic de 13.0 GB (84.5 s nouveau, 716 ms en cache).
• Provenance des noyaux. Chaque rapport d’évaluation et chaque essai consigne désormais l’ensemble de noyaux dont dépendent ses logits (versions des paquets, GPU, dtype, implémentations d’attention et de DeltaNet), après qu’un changement de noyau dans l’image d’évaluation a été constaté déplacer les lectures de Kev-27B v1 de 0.03–0.06 en probabilité sans changement du code propre de Kev.
• Audit d’évaluation. Trois suites ont été retirées comme non valables pour sélectionner des modèles : scienthoon (tickets gabarits, une question que le texte ne peut pas résoudre), WANLI-v2 / WANLI-v1 (un quart des étiquettes or est l’un de deux annotateurs en désaccord) et les évaluations publiques de TypeSafe (or issu de deux modèles fermés, trop peu de questions). Les panneaux phares excluent les éléments que l’audit a jugés sans réponse ou non étiquetés. Les chiffres des publications passées sur ces suites sont conservés dans leurs enregistrements, pas sur les fiches de la 1.0.
• Calibration. Kev-4B et Kev-0.8B livrent des températures ajustées sur des éléments tenus à l’écart de leurs données d’entraînement. Un réajustement enregistré sur des jeux de données tenus à l’écart a été évalué pour les deux et adopté pour aucun : il n’a pas amélioré Kev-4B (différence de Brier −0.0001 [−0.0005, +0.0003]), et il a rendu Kev-0.8B moins bien calibré sur ses familles de documents et de compétences, de plus que la tolérance enregistrée. Kev-9B et Kev-27B livrent déjà des températures de jeux de données tenus à l’écart.
• Données d’entraînement publiées. Les partitions d’entraînement de documents-v1 et hard-v1 sont dans le jeu de données jaredpalmer/kev-suites, donc les données d’entraînement des petits modèles peuvent être récupérées et vérifiées par hachage.
• Longueur de contexte validée. Chaque fiche indique désormais l’état le plus long auquel l’exactitude sur les contrats CUAD reste à moins de 3 pp (borne inférieure à 95 %) du même modèle à 8k jetons. Kev-27B tient jusqu’à 65 536 jetons, la limite de service (sa borne inférieure à 64k est −2.4 pp). Kev-0.8B, 4B et 9B ne valident que leurs 8 192 entraînés : chacun manque déjà la tolérance à 16k (bornes inférieures −8.5, −3.4 et −3.7 pp), donc au-delà de 8k jetons leurs réponses sur les documents longs ne sont pas couvertes par la mesure.
• Fiches de modèle formelles. Les quatre fiches suivent une seule structure : résumé, détails, usages prévus et hors périmètre, comment utiliser, données et procédure d’entraînement, évaluation, limites, risques, calcul, provenance.

Limites connues

• Gains en distribution. Les grands gains de l’année écoulée portent sur des suites dont les partitions d’entraînement sont dans les données d’entraînement. Sur les jeux de données sur lesquels aucun Kev ne s’est entraîné, Kev-27B est 1.7 point d’indice sous Jev sur le test breadth-v1, et les tailles plus petites sont 13–31 points en dessous.
• Longueurs non entraînées. Kev-0.8B, 4B et 9B se sont entraînés sur des états d’au plus 7 552 jetons et Kev-27B sur au plus 32 768 ; le serveur accepte 65 536. Utilise la longueur de contexte validée, pas la limite de service.
• Kev-27B sur les contrats longs est moins exact que la v1 et trop confiant (CUAD test ECE 0.053 contre 0.007) ; réajuste la température sur tes propres documents ou utilise @v1-lora pour la revue de contrats.
• Kev-0.8B et le routage d’outils. Son exactitude When2Call est tombée sous le hasard (0.133 en test) après son étape documents et compétences ; ne l’utilise pas pour le routage d’appels d’outils.
• L’arithmétique de dates est la famille la plus faible à chaque taille sous 27B (exactitude de politique deadline 0.35 / 0.65 / 0.725 contre 0.95 pour Jev) ; KEV_DATE_FACTS=1 aide.
• Les connaissances sont fixées par la base (MMLU-Pro 0.230–0.675 contre 0.840 pour Jev).
• Kev-9B sur un Mac n’a pas été mesuré, et Kev-27B sur un Mac est censé tenir dans 96–128 GB mais n’a pas été exécuté.
• Sélection. Kev-27B v2 et Kev-9B v2 ont été resélectionnés sous la règle auditée avec les lectures de développement antérieures connues ; leurs marges de test sont optimistes.
• Une température par modèle ne peut pas réordonner les confiances, donc à un budget d’erreur de 5 % les modèles automatisent moins de décisions que Jev hors domaine.

Comment l’exécuter

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-4b@v1.0 --port 8009    # CUDA, or MLX on Apple Silicon

Depuis une archive de publication :

shasum -a 256 -c SHA256SUMS.txt
tar -xzf kev-4b.tar.gz
uv run --extra serve python -m kev.serve --run kev-4b --port 8009

Le SDK TypeSafe fonctionne sans modification : TypeSafeClient(api_key="local", base_url="http://127.0.0.1:8009", model="kev-latest"). Kev-27B a besoin d’un B200, H200 ou H100 80 GB : --run jaredpalmer/kev-27b@v1.0. Pour déployer un point de terminaison HTTPS sur Modal, voir skills/kev-deploy.

Ressources

Chaque archive contient un checkpoint tel qu’il est sur le Hub à sa révision de poids (adaptateur LoRA, head.pt avec la température, fichiers de tokenizer, le result.json de l’essai d’entraînement, provenance.json, training_config.json, training_metrics.json et journal), la fiche de modèle Kev 1.0 en README.md, et la lecture transfer-v4 verrouillée en locked_test.json. Elles sont construites par scripts/build_release_assets.py à partir de docs/releases/kev-1.0-assets.json, et reconstruire donne les mêmes octets. Chaque fichier qu’elles contiennent est daté du 2026-10-01 00:00 UTC, ce que kev.serve rapporte comme la date de publication d’un checkpoint décompressé. Les archives attachées pour la première fois le 2026-10-01 dataient leurs fichiers du 1970-01-01, donc kev.serve rapportait 1969-12-31 ; elles ont été remplacées le jour même par celles-ci. Les poids et tous les autres fichiers sont identiques au byte près ; seuls les hachages des archives ont changé.

Kev-27B n’est pas attaché, car ses 51 GB de poids dépassent la limite de 2 GB par ressource de GitHub. Télécharge-le depuis le Hub : jaredpalmer/kev-27b@v1.0 (commit des poids 28be62e9, head.pt 7968f17b…).

Sur chaque dépôt Hub, l’étiquette v1.0 pointe vers le commit qui a téléversé la fiche Kev 1.0. Ce commit n’a changé que README.md, donc ses poids sont les mêmes octets que la révision de poids du premier tableau : kev-0.8b bf75a6a8, kev-4b 6cfce5c2, kev-9b db029f08, kev-27b af0e6d55.

Plan de publication (pour le mainteneur ; ne fait pas partie des notes publiées)

Fait le 2026-10-01 (enregistrement runs/release/kev-1.0.json ; PLAN.md « Released: Kev 1.0 »). Étapes 3 et 4 : commits ne portant que sur la fiche, avec v1.0 sur chaque commit de fiche (0.8B bf75a6a8, 4B 6cfce5c2, 9B db029f08, 27B af0e6d55 ; tout autre fichier inchangé). Étapes 5 et 6 : ressources construites deux fois avec des hachages identiques, la publication publiée et marquée Latest. Étape 7 : kev-family conservée, ses ressources retirées, son corps un pointeur vers kev-1.0, ses anciennes notes dans runs/release/kev-family-notes-retired.md. Étape 8 : épingles inchangées. Étape 9 : collection et Space vérifiés ; le Space n’a pas été republié. Le plan tel qu’écrit avant la publication suit. Ordre :

1. Espaces réservés : remplis (2026-10-01) à partir du read-out de contexte enregistré de la ronde 28, runs/r28-readout/context.json (scripts/longdoc_report.py --context-margin -0.03 sur runs/r28-{4b-r10,08b-r15}-longdoc, runs/r29-9b-r18a-longdoc et runs/r23-27b-k-w85-longdoc ; brut runs/r28-context, ECE à la température livrée runs/r28-context-served), avec les chiffres dans docs/claims.json.

2. Fusionner cette PR.

3. Fiches Hub. Téléverse chaque fiche 1.0 en README.md seulement (pas de poids) : kev.publish n’est pas nécessaire pour un commit de fiche seule ; hf upload jaredpalmer/kev-<size> docs/model-cards/kev-<size>.md README.md --commit-message "Kev 1.0 model card (weights unchanged)". Vérifie avec HfApi().model_info(..., files_metadata=True) que adapter_model.safetensors / head.pt (27B : model.safetensors.index.json et chaque shard) ont le hachage ci-dessous.

4. Étiquettes Hub. v1.0 sur les quatre dépôts. Par défaut (comme spécifié) : les révisions de poids exactes ; si l’étape 3 a été exécutée d’abord, étiquette plutôt le commit de fiche pour que @v1.0 montre la fiche 1.0 (les poids sont identiques au byte près ; consigne les deux commits dans PLAN.md).

   Dépôt	Cible v1.0 (poids)	sha256 adaptateur / tête
   jaredpalmer/kev-0.8b	9a45d25eb2ab761841196625383fa1dff0e56c1e	9b908623… / f400bd12…
   jaredpalmer/kev-4b	139fdd94f1b6a6ad80cc15e08fcb99cac885a101	90e81735… / dd633435…
   jaredpalmer/kev-9b	b5d8c18e44c60888d138b65cb6507ff0a5a448a0	2b2a70cf… / 8e1dab2c…
   jaredpalmer/kev-27b	main (aujourd’hui ef78cc8a34d5f426fb229c52089db189218cfe5c : poids 28be62e9, puis trois commits de fiche seule)	poids d27af6ab… / tête 7968f17b…

   hf repos tag create jaredpalmer/kev-0.8b v1.0 --revision 9a45d25eb2ab761841196625383fa1dff0e56c1e -m "Kev 1.0"
   hf repos tag create jaredpalmer/kev-4b   v1.0 --revision 139fdd94f1b6a6ad80cc15e08fcb99cac885a101 -m "Kev 1.0"
   hf repos tag create jaredpalmer/kev-9b   v1.0 --revision b5d8c18e44c60888d138b65cb6507ff0a5a448a0 -m "Kev 1.0"
   hf repos tag create jaredpalmer/kev-27b  v1.0 --revision <main at release> -m "Kev 1.0"

5. Ressources. uv run python scripts/build_release_assets.py --release docs/releases/kev-1.0-assets.json --out /tmp/kev-1.0-assets construit kev-0.8b.tar.gz, kev-4b.tar.gz, kev-9b.tar.gz (chacun : l’instantané Hub à la révision ci-dessus, c’est-à-dire adaptateur, head.pt avec la température, fichiers de tokenizer, le result.json de l’essai, provenance.json, training_config.json et training_metrics.json ; la fiche 1.0 en README.md ; la lecture verrouillée en locked_test.json), SHA256SUMS.txt et manifest.json (sha256 de chaque membre). Il refuse un téléchargement dont le hachage d’adaptateur ou de tête diffère de la spécification. Kev-27B n’est pas une ressource (51 GB ; GitHub plafonne une ressource à 2 GB) : les notes pointent vers le Hub.

6. Publication GitHub. Étiquette kev-1.0 sur le commit de fusion ; crée la publication en brouillon avec la partie publiée de ces notes comme corps (tout ce qui précède cette section), attache les trois archives et SHA256SUMS.txt, retélécharge-les, shasum -a 256 -c SHA256SUMS.txt, extrais-en une et sers-la, puis publie et marque-la Latest.

7. Une publication par taille. La politique de publication ne garde que la meilleure version de chaque taille dans une publication GitHub. Une fois kev-1.0 publiée, kev-family la duplique : supprime ses trois archives et SHA256SUMS.txt et remplace son corps par un pointeur vers kev-1.0 (ou supprime la publication ; au choix de Jared). Les versions antérieures restent sur les étiquettes Hub listées dans chaque fiche.

8. Épingles de déploiement. skills/kev-deploy et skills/kev-finetune épinglent KEV_REF 71d4829 ; les checkpoints 1.0 n’ont besoin d’aucun code plus récent. Ne déplace l’épingle que si un correctif de service ultérieur doit être livré avec la 1.0.

9. Collection et Space. La collection Kev liste déjà les quatre dépôts. Le Space sert Kev-4B et Kev-0.8B depuis main, qui est constitué des poids 1.0 ; rien à republier sauf si kev/model.py, kev/api.py ou kev/checkpoint.py a changé depuis sa dernière publication.