Kev 1.0

Kev 1.0 es la primera versión numerada de toda la familia Kev: cuatro modelos de decisión que leen un documento y un conjunto de preguntas tipadas y devuelven probabilidades calibradas sobre las opciones, en una sola pasada hacia adelante, detrás de la API System One de TypeSafe. Nada de lo que contiene se ha entrenado de nuevo. Fija los checkpoints, las tarjetas de modelo, las suites de evaluación y el código de servicio con los que se mide la próxima generación de Kev, con la misma etiqueta (v1.0) en cada repo del Hub.

Qué incluye 1.0

Números destacados (ruta de evaluación fp32, cada modelo a su temperatura distribuida; el test transfer-v4 está bloqueado y se leyó una vez por modelo):

hard-v1, devtools-v1 y documents-v1 tienen particiones de entrenamiento con las que se entrenó cada Kev: esas filas miden elementos reservados de familias entrenadas, no transferencia. Las filas de breadth-v1 y transfer-v4 son conjuntos de datos con los que ningún Kev se entrenó. Jev se leyó en las particiones de desarrollo y solo en el test breadth-v1. Cada número se remonta a un informe comprometido a través de docs/claims.json; las tarjetas de modelo (docs/model-cards/) tienen el resto, con intervalos.

Qué cambió desde la última versión de la familia

Medido desde la release de GitHub kev-family tal como se ensambló por primera vez para la familia actual el 2026-09-24 (Kev-27B v1, Kev-9B v1 y los mismos Kev-4B y Kev-0.8B que aquí). Sus actualizaciones del 2026-09-30 (Kev-27B v2, Kev-9B v2) también se enumeran aquí, ya que 1.0 es donde pasan a formar parte de una versión numerada.

• Kev-27B v2: pesos completos. Cada peso de Qwen3.8-27B ajustado durante una época sobre un corpus de 145,840 registros, y luego promediado 0.85 / 0.15 con v1. Frente a v1 en test: conjuntos de datos reservados +1.2 pp [+0.3, +2.2], familias de tareas reservadas +5.3 [+3.7, +6.8], habilidades, herramientas y documentos +8.9 [+7.5, +10.3]; test bloqueado fuera de dominio 0.889 frente a 0.896, Brier 0.154 frente a 0.160. Peor y demasiado confiado en contratos largos (ECE de CUAD 0.053 frente a 0.007). v1 está en jaredpalmer/kev-27b@v1-lora.
• Kev-9B v2. v1 más una época sobre los datos de documentos y habilidades que Kev-4B y Kev-0.8B ya tenían. Frente a v1 en test: hard-v1 + devtools-v1 +18.7 pp [+16.7, +20.8], documents-v1 +7.1 [+4.7, +9.2]; a la par en el test bloqueado fuera de dominio (0.852 ambos) con Brier 0.199 frente a 0.224. v1 está en jaredpalmer/kev-9b@v1.
• Sin truncamiento silencioso. El servidor solía cortar un estado más largo que su límite sin decirlo. Ahora rechaza un estado de más de 65,536 tokens con un 422 que indica el número de tokens y el límite; KEV_TRUNCATE_STATES=1 vuelve a optar por el truncamiento, y cada respuesta de un servidor así dice entonces truncated. Las skills de deploy y fine-tune fijan KEV_REF a un commit que tiene esta corrección y los cambios de documentos largos y MLX de abajo (71d4829), y el Space se republicó tras la corrección.
• Documentos largos en todos los tamaños. La ruta de evaluación mantenía atención fp32 para las filas largas en el kernel matemático, así que Kev-0.8B, 4B y 9B se quedaban sin memoria de GPU con estados de 32k–64k tokens. Las filas largas ahora ejecutan el kernel eficiente en memoria en fp32: Kev-4B lee un estado de 61k tokens en 17.2 s con 17.2 GiB por encima de los pesos en una H100, y las filas más cortas conservan sus logits bit a bit. Esto es lo que hace medibles las longitudes de contexto validadas de arriba.
• Apple Silicon. El backend de MLX carga los checkpoints de pesos completos tal como se guardaron, sin fusión, lo que da a Kev-27B una ruta en Mac (se espera que necesite unos 51 GB más memoria de trabajo; aún no se ha ejecutado a ese tamaño). Los estados largos se prellenan de 1,024 tokens en 1,024 tokens y la caché se vacía antes de una pasada, así que Kev-4B sirve un estado de 65,000 tokens en un M5 de 32 GB con un pico de 13.0 GB (84.5 s nuevo, 716 ms en caché).
• Procedencia de los kernels. Cada informe de evaluación y ensayo registra ahora el conjunto de kernels del que dependen sus logits (versiones de paquetes, GPU, dtype, implementaciones de atención y DeltaNet), después de que se descubriera que un cambio de kernel en la imagen de evaluación movía las lecturas de Kev-27B v1 en 0.03–0.06 de probabilidad sin ningún cambio en el propio código de Kev.
• Auditoría de evaluación. Se eliminaron tres suites por poco sólidas para seleccionar modelos: scienthoon (tickets con plantilla, una pregunta que el texto no puede responder), WANLI-v2 / WANLI-v1 (un cuarto de las etiquetas gold son de uno de dos anotadores que discrepan) y las evaluaciones públicas de TypeSafe (gold de dos modelos cerrados, demasiado pocas preguntas). Los paneles destacados excluyen los elementos que la auditoría encontró sin respuesta o sin etiquetar. Las cifras de publicaciones anteriores en esas suites se conservan en sus registros, no en las tarjetas de 1.0.
• Calibración. Kev-4B y Kev-0.8B distribuyen temperaturas ajustadas sobre elementos reservados de sus datos de entrenamiento. Se evaluó un reajuste registrado sobre conjuntos de datos reservados para ambos y no se adoptó para ninguno: no mejoró Kev-4B (diferencia de Brier −0.0001 [−0.0005, +0.0003]) y dejó a Kev-0.8B peor calibrado en sus familias de documentos y habilidades por más que la tolerancia registrada. Kev-9B y Kev-27B ya distribuyen temperaturas de conjuntos de datos reservados.
• Datos de entrenamiento publicados. Las particiones de entrenamiento de documents-v1 y hard-v1 están en el conjunto de datos jaredpalmer/kev-suites, así que los datos de entrenamiento de los modelos pequeños se pueden descargar y comprobar con hash.
• Longitud de contexto validada. Cada tarjeta indica ahora el estado más largo en el que la precisión en contratos CUAD se mantiene dentro de 3 pp (límite inferior del 95 %) del mismo modelo a 8k tokens. Kev-27B aguanta hasta 65,536 tokens, el límite de servicio (su límite inferior de 64k es −2.4 pp). Kev-0.8B, 4B y 9B validan solo sus 8,192 entrenados: cada uno ya falla la tolerancia a 16k (límites inferiores −8.5, −3.4 y −3.7 pp), así que más allá de 8k tokens sus respuestas en documentos largos no están cubiertas por la medición.
• Tarjetas de modelo formales. Las cuatro tarjetas siguen una misma estructura: resumen, detalles, usos previstos y fuera de alcance, cómo usar, datos y procedimiento de entrenamiento, evaluación, limitaciones, riesgos, cómputo, procedencia.

Limitaciones conocidas

• Ganancias en distribución. Las grandes ganancias del último año son en suites cuyas particiones de entrenamiento están en los datos de entrenamiento. En conjuntos de datos con los que ningún Kev se entrenó, Kev-27B está 1.7 puntos de índice por debajo de Jev en el test breadth-v1, y los tamaños menores están 13–31 puntos por debajo.
• Longitudes no entrenadas. Kev-0.8B, 4B y 9B se entrenaron con estados de como máximo undefined tokens y Kev-27B con como máximo 32,768; el servidor acepta 65,536. Usa la longitud de contexto validada, no el límite de servicio.
• Kev-27B en contratos largos es menos preciso que v1 y demasiado confiado (ECE de test de CUAD 0.053 frente a 0.007); reajusta la temperatura con tus propios documentos o usa @v1-lora para revisión de contratos.
• Kev-0.8B y el enrutamiento de herramientas. Su precisión en When2Call cayó por debajo del azar (0.133 en test) tras su etapa de documentos y habilidades; no lo uses para enrutamiento de llamadas a herramientas.
• La aritmética de fechas es la familia más débil en todos los tamaños por debajo de 27B (precisión de política deadline 0.35 / 0.65 / 0.725 frente al 0.95 de Jev); KEV_DATE_FACTS=1 ayuda.
• El conocimiento lo fija la base (MMLU-Pro 0.230–0.675 frente al 0.840 de Jev).
• Kev-9B en un Mac no se ha medido, y se espera que Kev-27B en un Mac quepa en 96–128 GB, pero no se ha ejecutado.
• Selección. Kev-27B v2 y Kev-9B v2 se volvieron a seleccionar bajo la regla auditada conociendo lecturas de desarrollo anteriores; sus márgenes de test son optimistas.
• Una temperatura por modelo no puede reordenar las confianzas, así que con un presupuesto de error del 5 % los modelos automatizan menos decisiones que Jev fuera de dominio.

Cómo ejecutarlo

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

Desde un tarball de release:

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

El SDK de TypeSafe funciona sin cambios: TypeSafeClient(api_key="local", base_url="http://127.0.0.1:8009", model="kev-latest"). Kev-27B necesita una B200, H200 o H100 80 GB: --run jaredpalmer/kev-27b@v1.0. Para desplegar un endpoint HTTPS en Modal, véase skills/kev-deploy.

Assets

Cada tarball contiene un checkpoint tal como está en el Hub en su revisión de pesos (adaptador LoRA, head.pt con la temperatura, archivos del tokenizador, result.json del ensayo de entrenamiento, provenance.json, training_config.json, training_metrics.json y el registro), la tarjeta de modelo de Kev 1.0 como README.md y la lectura bloqueada de transfer-v4 como locked_test.json. Los construye scripts/build_release_assets.py a partir de docs/releases/kev-1.0-assets.json, y reconstruirlos da los mismos bytes. Cada archivo que contienen está fechado el 2026-10-01 00:00 UTC, que kev.serve informa como la fecha de publicación de un checkpoint descomprimido. Los tarballs adjuntados por primera vez el 2026-10-01 fechaban sus archivos el 1970-01-01, así que kev.serve informaba 1969-12-31; se reemplazaron el mismo día por estos. Los pesos y todos los demás archivos son idénticos byte a byte; solo cambiaron los hashes de los tarballs.

Kev-27B no se adjunta, porque sus 51 GB de pesos superan el límite de 2 GB por asset de GitHub. Descárgalo del Hub: jaredpalmer/kev-27b@v1.0 (commit de pesos 28be62e9, head.pt 7968f17b…).

En cada repo del Hub, la etiqueta v1.0 apunta al commit que subió la tarjeta de Kev 1.0. Ese commit solo cambió README.md, así que sus pesos son los mismos bytes que la revisión de pesos de la primera tabla: kev-0.8b bf75a6a8, kev-4b 6cfce5c2, kev-9b db029f08, kev-27b af0e6d55.

Plan de publicación (para el mantenedor; no forma parte de las notas publicadas)

Hecho el 2026-10-01 (registro runs/release/kev-1.0.json; PLAN.md “Released: Kev 1.0”). Pasos 3 y 4: commits solo de tarjeta, con v1.0 en cada commit de tarjeta (0.8B bf75a6a8, 4B 6cfce5c2, 9B db029f08, 27B af0e6d55; todos los demás archivos sin cambios). Pasos 5 y 6: assets construidos dos veces con hashes idénticos, la release publicada y marcada como Latest. Paso 7: kev-family conservada, sus assets eliminados, su cuerpo un puntero a kev-1.0, sus notas antiguas en runs/release/kev-family-notes-retired.md. Paso 8: pins sin cambios. Paso 9: colección y Space comprobados; el Space no se republicó. El plan tal como se escribió antes de la publicación sigue a continuación. Orden:

1. Marcadores de posición: completados (2026-10-01) a partir de la lectura de contexto registrada de la ronda 28, runs/r28-readout/context.json (scripts/longdoc_report.py --context-margin -0.03 sobre runs/r28-{4b-r10,08b-r15}-longdoc, runs/r29-9b-r18a-longdoc y runs/r23-27b-k-w85-longdoc; bruto runs/r28-context, ECE a la T distribuida runs/r28-context-served), con los números en docs/claims.json.

2. Fusionar este PR.

3. Tarjetas del Hub. Sube cada tarjeta de 1.0 solo como README.md (sin pesos): kev.publish no es necesario para un commit solo de tarjeta; hf upload jaredpalmer/kev-<size> docs/model-cards/kev-<size>.md README.md --commit-message "Kev 1.0 model card (weights unchanged)". Comprueba con HfApi().model_info(..., files_metadata=True) que adapter_model.safetensors / head.pt (27B: model.safetensors.index.json y cada shard) tienen el hash de abajo.

4. Etiquetas del Hub. v1.0 en los cuatro repos. Predeterminado (según lo especificado): las revisiones de pesos exactas; si el paso 3 se ejecutó antes, etiqueta en su lugar el commit de la tarjeta para que @v1.0 muestre la tarjeta de 1.0 (los pesos son idénticos byte a byte; registra ambos commits en PLAN.md).

   Repo	Objetivo de v1.0 (pesos)	sha256 de adaptador / cabeza
   jaredpalmer/kev-0.8b	9a45d25eb2ab761841196625383fa1dff0e56c1e	9b908623… / f400bd12…
   jaredpalmer/kev-4b	139fdd94f1b6a6ad80cc15e08fcb99cac885a101	90e81735… / dd633435…
   jaredpalmer/kev-9b	b5d8c18e44c60888d138b65cb6507ff0a5a448a0	2b2a70cf… / 8e1dab2c…
   jaredpalmer/kev-27b	main (hoy ef78cc8a34d5f426fb229c52089db189218cfe5c: pesos 28be62e9, y luego tres commits solo de tarjeta)	pesos d27af6ab… / cabeza 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. Assets. uv run python scripts/build_release_assets.py --release docs/releases/kev-1.0-assets.json --out /tmp/kev-1.0-assets construye kev-0.8b.tar.gz, kev-4b.tar.gz, kev-9b.tar.gz (cada uno: la instantánea del Hub en la revisión de arriba, es decir, adaptador, head.pt con la temperatura, archivos del tokenizador, result.json del ensayo, provenance.json, training_config.json y training_metrics.json; la tarjeta de 1.0 como README.md; la lectura bloqueada como locked_test.json), SHA256SUMS.txt y manifest.json (sha256 de cada miembro). Rechaza una descarga cuyo hash de adaptador o cabeza difiera de la especificación. Kev-27B no es un asset (51 GB; GitHub limita un asset a 2 GB): las notas apuntan al Hub.

6. Release de GitHub. Etiqueta kev-1.0 en el commit de fusión; crea la release como borrador con la parte publicada de estas notas como cuerpo (todo lo anterior a esta sección), adjunta los tres tarballs y SHA256SUMS.txt, descárgalos de vuelta, shasum -a 256 -c SHA256SUMS.txt, extrae uno y sírvelo, y luego publícala y márcala como Latest.

7. Una release por tamaño. La política de publicaciones conserva solo la mejor versión de cada tamaño en una release de GitHub. Una vez publicada kev-1.0, kev-family la duplica: elimina sus tres tarballs y SHA256SUMS.txt y reemplaza su cuerpo por un puntero a kev-1.0 (o elimina la release; decisión de Jared). Las versiones anteriores se quedan en las etiquetas del Hub listadas en cada tarjeta.

8. Pins de despliegue. skills/kev-deploy y skills/kev-finetune fijan KEV_REF 71d4829; los checkpoints de 1.0 no necesitan código más nuevo. Mueve el pin solo si una corrección de servicio posterior debe distribuirse con 1.0.

9. Colección y Space. La colección de Kev ya lista los cuatro repos. El Space sirve Kev-4B y Kev-0.8B desde main, que son los pesos de 1.0; nada que republicar a menos que kev/model.py, kev/api.py o kev/checkpoint.py hayan cambiado desde su última publicación.