Kev-0.8B

Resumen del modelo

Kev-0.8B es un modelo de decisión. Lee un documento (el estado) y un conjunto de preguntas tipadas sobre él, y devuelve una distribución de probabilidad calibrada sobre las opciones facilitadas con cada pregunta, en una sola pasada hacia adelante y sin generar texto. Implementa la API pública System One de TypeSafe (POST /v1/systemone), así que el SDK de TypeSafe funciona contra él sin cambios. Es el Kev más pequeño: un adaptador LoRA y una cabeza de puntero sobre Qwen3.5-0.8B-Base que corre en un portátil o en una GPU de 4 GB. Está pensado para cuando la memoria o el coste descartan los tamaños mayores y la tarea se parece a aquello con lo que se entrenó; fuera de dominio es notablemente menos preciso que Kev-4B. Esta tarjeta describe el checkpoint de Kev 1.0, publicado por primera vez el 2026-09-24.

Detalles del modelo

Entrada. Un estado (texto, o un objeto o array JSON renderizado como texto etiquetado) y cualquier número de preguntas con nombre, cada una de uno de tres tipos:

Cada pregunta se responde como su propia fila que continúa desde el estado compartido, así que las preguntas no pueden influirse entre sí; el estado se calcula una vez y se guarda en caché.

Usos previstos

• Decisiones tipadas cercanas a sus familias de entrenamiento (clasificación de documentos, enrutamiento, comprobaciones de política sobre reglas enunciadas) en hardware demasiado pequeño para Kev-4B: un portátil, una L4 o una GPU de 4 GB.
• Un punto de partida para hacer fine-tuning con las propias etiquetas del usuario cuando importa el coste de entrenamiento (kev.train --init_from jaredpalmer/kev-0.8b).
• Crear prototipos contra la API System One antes de pasar a un Kev mayor.

Usos fuera de alcance

• Generación de texto, chat, resumen o respuesta a preguntas abiertas. El modelo solo puntúa las opciones que se le dan.
• Enrutamiento de llamadas a herramientas (si llamar a una herramienta, pedir un parámetro que falta o rechazar): su precisión en When2Call está por debajo del azar (véase Limitaciones).
• Decisiones totalmente automatizadas con consecuencias legales, médicas, financieras, laborales o similares para personas, sin revisión humana.
• Preguntas con mucho conocimiento, aritmética de fechas, estados de más de 65,536 tokens e idiomas distintos del inglés.

Cómo usarlo

Sírvelo con el repositorio de Kev. En CUDA se ejecuta en bf16 con kernels fusionados de DeltaNet y CUDA graphs (una L4 basta); en Apple Silicon el mismo comando lo sirve mediante MLX, elegido automáticamente.

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 temperatura calibrada se aplica por defecto; KEV_TEMPERATURE=1.0 devuelve las probabilidades sin calibrar. KEV_DTYPE=fp32 selecciona la ruta exacta usada para la evaluación. Un estado de más de 65,536 tokens se rechaza con un 422 que indica su número de tokens.

Datos de entrenamiento

Las dos etapas de fine-tuning repiten 2,000 y 6,000 registros de decision-v7. No se usó ninguna salida de Jev (el modelo de decisión alojado de TypeSafe). CodeReviewer y FlakeFlagger proceden de Zenodo; las narrativas del CFPB son obras del gobierno de EE. UU.; las licencias y revisiones por fuente se registran en los manifiestos de las suites. Las suites solo de evaluación de abajo (breadth-v1, tasksource-heldout-v1, transfer-v4, longdoc-v1 y las fuentes de When2Call e inyección de prompts de devtools-v1) nunca entran en el entrenamiento.

Procedimiento de entrenamiento

1. Receta base. Dos épocas sobre decision-v7 desde la base: rango de LoRA 16, α 32; tasa de aprendizaje 1e-4, esquema one-cycle; lote 8; autocast bf16; semilla 2. La pérdida es entropía cruzada sobre las opciones de cada pregunta. El orden de las opciones se mezcla, se insertan al azar opciones “none of the above” y distractores, y un cuarto de los registros choice también producen un par mínimo (la pregunta con una opción “none of the above”, una vez con la opción correcta presente y otra con ella eliminada).
2. Fechas y evidencia ausente. Una época desde la etapa 1 con tasa de aprendizaje 4e-5 y 2,000 registros repetidos.
3. Documentos y habilidades. Una época desde la etapa 2 sobre los tres conjuntos de entrenamiento juntos con tasa de aprendizaje 2e-5 y 6,000 registros repetidos; lote 4 × 2 de acumulación; estados de como máximo 7,552 tokens; gradient checkpointing; semilla 1; 2,818 pasos de optimizador.
4. Calibración. Una única temperatura, T = 2.35, que minimiza la log-verosimilitud negativa en las filas de desarrollo de decision-v7 del ensayo de la etapa 3 (1,264 preguntas). Son elementos reservados de un corpus de entrenamiento. Se evaluó un reajuste sobre conjuntos de datos reservados y no se adoptó (véase Calibración).

Evaluación

Metodología. Cada número es la ruta de evaluación fp32 a la temperatura distribuida, salvo que se indique otra cosa. Las particiones de desarrollo se usaron para la selección; las particiones de test se leyeron una vez para este checkpoint; el test transfer-v4 está bloqueado (se lee una vez por candidato) y se juzgó contra un listón fijado de antemano. Los intervalos emparejados son bootstraps del 95 % que remuestrean registros completos (2,000 remuestreos), así que las preguntas que comparten un estado se mueven juntas. Las diferencias están en puntos porcentuales (pp). Jev (el modelo alojado de TypeSafe, consultado a través de Vercel AI Gateway) se muestra donde se leyó con los mismos elementos. Las suites:

• breadth-v1: 14 conjuntos de datos públicos reservados en cinco áreas (conocimiento, lenguaje, recuperación, herramientas, artes), nunca entrenados.
• tasksource-heldout-v1: 24 familias de tareas completas de una colección multitarea pública, nunca entrenadas (nombres de familia privados).
• transfer-v4: decisiones fuera de dominio de seis fuentes públicas nunca entrenadas (QNLI, SciQ, TweetEval-offensive, PAWS, MMLU, Emotion) más estructuras de política y reglas reservadas.
• hard-v1: las familias de habilidades de arriba; la partición de test reserva plantillas de generadores entrenados.
• devtools-v1: decisiones de herramientas de desarrollo de seis fuentes con licencia comprobada (cuatro entrenadas, dos solo de evaluación).
• documents-v1 / documents-v2: narrativas de quejas del CFPB; v2 es un conjunto de test reservado privado.
• longdoc-v1: contratos comerciales CUAD y paquetes de acuerdos generados, con estados de 4k a 64k tokens.

Los paneles destacados marcados como “auditados” excluyen los elementos que una auditoría de etiquetas encontró poco sólidos¹; cada exclusión elimina las mismas filas de ambos lados de una comparación.

Datos reservados (nunca entrenados).

Familias entrenadas (elementos y plantillas reservados).

La cifra de devtools-v1 de Jev es sobre las 1,074 preguntas de desarrollo; las filas de Kev descartan un id de CodeReviewer que el constructor de la suite reutilizó para dos registros (2 preguntas).

Frente a la versión anterior (etiqueta night2-du-release, a su propia temperatura 2.41; criterios registrados, cada test leído una vez):

Documentos largos.

• Longitud de contexto validada: 8,192 tokens, la longitud entrenada. El cubo de 16k está fuera de la tolerancia: su límite inferior es −8.5 pp, por debajo de −3 pp, así que no se valida ninguna longitud mayor.
• Regla, fijada antes de la lectura: la longitud validada es el tamaño nominal del cubo más grande desde 16,384 tokens hacia arriba tal que él, y todos los cubos entre él y 8,192, estén dentro de la tolerancia. Dentro de la tolerancia significa que la diferencia de precisión en CUAD respecto al cubo de 8k (estados de 6,553–7,618 tokens, la longitud entrenada), emparejada por el mismo contrato, repetición y pregunta, tiene un límite inferior del 95 % de al menos −3 pp, y que se respondió cada registro. Si el cubo de 16k falla, la longitud validada es 8,192 tokens.

Precisión en CUAD, ECE y la diferencia emparejada respecto al cubo de 8k por longitud nominal del estado (desarrollo longdoc-v1):

ECE a la T distribuida de 2.35. Δ está emparejada sobre las 445–447 preguntas formuladas sobre los mismos contratos en ambas longitudes. El cubo de 4k contiene contratos distintos y no es una referencia para la regla. Fuente: runs/r28-readout/context.json (la lectura registrada de la ronda 28, runs/r28-08b-r15-longdoc).

Calibración (error de calibración esperado, ECE, a la T distribuida de 2.35; más bajo es mejor):

La temperatura distribuida se ajustó sobre elementos reservados de un corpus de entrenamiento, algo que las reglas del proyecto ya no permiten para una nueva versión. Un reajuste registrado sobre 648 preguntas de conjuntos de datos reservados (la partición de calibración de transfer-r3, ocho fuentes, y 200 preguntas de MMLU-Pro) da T = 2.52 (intervalo bootstrap del 90 % [2.19, 2.83]). En las 4,468 preguntas de desarrollo auditadas de breadth-v1 y tasksource-heldout-v1 está mejor calibrado: ECE 0.037 frente a 0.048, Brier menor en 0.0020 [0.0014, 0.0025]. Está peor en las familias entrenadas, cada una por más que la tolerancia registrada de 0.005: ECE de hard-v1 0.124 frente a 0.112, devtools-v1 (auditados) 0.099 frente a 0.092, documents-v1 0.078 frente a 0.059. El reajuste por tanto no calificó, y T = 2.35 se queda. Los usuarios cuyo flujo de trabajo se parece más a los conjuntos de datos públicos reservados que a las familias de entrenamiento de Kev pueden servirlo al valor del reajuste con KEV_TEMPERATURE=2.52; las respuestas no dependen de T.

Otros resultados.

Servicio. CUDA, bf16 con kernels fusionados y CUDA graphs, en una L4; tiempo de modelo por solicitud (mediana de 20) para un estado nuevo / repetido: 22.7 / 16.1 ms para seis preguntas sobre un estado corto, 108.6 / 32.3 ms para cinco preguntas sobre un estado de 2,200 tokens; 62.8 solicitudes/s con 64 clientes. La memoria de GPU residente es 3.8 GB. Las probabilidades servidas se mantienen dentro de 0.017 de la ruta de evaluación fp32 en 280 preguntas, con 1 respuesta cambiada.

Apple Silicon (MLX, bf16, M5 con 32 GB; tres preguntas, una sobre un hecho plantado al 60 % de profundidad; el estado se prellena en fragmentos de undefined tokens):

Frente a PyTorch fp32 en CPU en las mismas solicitudes, las respuestas de MLX difieren como máximo en 0.0076 a 8k y 0.0052 a 16k tokens, sin respuestas cambiadas. En 100 preguntas de estado corto, la ruta de MLX se mantiene dentro de 0.020 de la ruta de evaluación fp32, con 1 respuesta cambiada.

¹ Excluidos de los paneles auditados: cuatro conjuntos de datos de breadth-v1 (routerbench, cuyos estados carecen de la información pedida; cfcolor y humicroedit, en el nivel del azar para todos los sistemas; chessbench, en el suelo para todos los sistemas); siete familias de tasksource-heldout-v1 con etiquetas inválidas o irrecuperables (nombres privados); dos tareas de devtools-v1 cuyas etiquetas no determina el estado (flakeflagger, tipo de cambio de commit).

² El índice corregido por azar del Decision Index 0.2 de la comunidad: por conjunto de datos (puntuación − azar) / (1 − azar), promediado dentro de cada área, y luego 100 × la media de las cinco áreas. El índice de Jev proviene de una lectura separada de los mismos elementos de test.

Limitaciones y compromisos

• Es un modelo sub-1B fuera de dominio. Va 21 puntos por detrás de Jev en el desarrollo de transfer-v4 y 31 puntos en el índice de breadth-v1; el conocimiento (MMLU-Pro 0.230) y la paráfrasis están cerca de la base sin entrenar. Usa Kev-4B donde importe la precisión.
• Sus ganancias son en distribución. Las particiones de entrenamiento de documents-v1, hard-v1 y devtools-v1 están en sus datos de entrenamiento; en el nivel difícil público de JevBench, una comprobación fuera de distribución, la etapa de documentos y habilidades lo movió +2.7 pp [−1.8, +7.2], no distinguible de cero.
• El enrutamiento de llamadas a herramientas empeoró. When2Call, una fuente solo de evaluación, cayó de 0.260 a 0.167 en desarrollo y de 0.233 a 0.133 en test, por debajo de la tasa de uno de cada cuatro al azar entre sus cuatro opciones. No lo uses para enrutamiento de llamadas a herramientas.
• Un resultado de devtools-v1 no se explica. FlakeFlagger pasó de 0.500 → 0.520 en desarrollo pero de 0.507 → 0.813 en test, con 150 preguntas por partición; trátalo como inexplicado, no como una habilidad.
• La aritmética de fechas es su familia más débil: 0.35 en las preguntas de política deadline frente al 0.95 de Jev; el preprocesador KEV_DATE_FACTS=1 ayuda más a los modelos mayores que a este.
• La composición de reglas es débil: ambos hermanos de un par mínimo de política reservado son correctos el 0.422 de las veces.
• La calibración es una temperatura en distribución (véase Calibración). No puede reordenar las confianzas: la cobertura con ≤ 5 % de error fuera de dominio es 0.145 en desarrollo frente al 0.70 de Jev, así que pocas decisiones pueden automatizarse con un presupuesto de error estricto.
• Longitudes no entrenadas. Los estados de entrenamiento eran de como máximo undefined tokens. Los estados más largos se sirven hasta 65,536 tokens; hasta dónde aguanta la precisión es la longitud de contexto validada de arriba.
• El orden de las opciones puede cambiar una respuesta; el aislamiento de preguntas no lo impide.

Sesgo, riesgos y consideraciones éticas

• Las probabilidades calibradas pueden crear una confianza injustificada. La temperatura se ajustó sobre filas de desarrollo de la distribución de entrenamiento y no transfiere a todos los flujos de trabajo; mide la precisión y la calibración con una muestra etiquetada de tus propios datos, y reajusta allí la temperatura (python -m kev.calibrate), antes de fijar umbrales.
• La precisión y la calibración cambian bajo un cambio de dominio, y más a este tamaño que en los mayores. Vigila las tasas de error en producción en lugar de fiarte de los números anteriores.
• No lo uses para decisiones automatizadas trascendentales sobre personas sin revisión humana. Los sesgos del modelo base y de los datos de entrenamiento (incluidas las etiquetas producidas por otros modelos) no se miden.
• Los estados pueden contener datos personales o confidenciales. El autoalojamiento mantiene las entradas en tu propio hardware; el servidor está abierto a menos que se defina KEV_API_KEY, así que aplica tu propia política de control de acceso y tratamiento de datos.

Cómputo

• Receta base: unos 20 minutos en una NVIDIA H100. Etapa de fechas: 9 minutos.
• Etapa de documentos y habilidades: 52 minutos en una NVIDIA H200 (pico 23.9 GB).
• Comprobaciones de evaluación y servicio: GPUs H100 / H200 / L4 individuales en Modal; mediciones de MLX en un Apple M5.

Procedencia y reproducibilidad

• Código, suites e informes de evaluación: github.com/jaredpalmer/kev. Números de publicación: runs/release/kev-08b-r15.json (scripts/release_numbers.py --release kev-08b-r15), la lectura bloqueada runs/locked/kev-08b-r15-ungated/, las lecturas familiares del 2026-09-30 runs/fam-08b-breadth/, runs/fam-08b-breadthtest/ y runs/fam-breadth-test-report/, el reajuste de calibración runs/r28-readout/round28.json, servicio runs/serve-08b-l4/, runs/mlx-long-states/, runs/mlx-full-0.8b/.
• Etapas: ensayo base q35-08b/02-trial-2 (etiqueta v7-base); fechas night2-08b-du2/00-trial-0 (etiqueta night2-du-release); documentos y habilidades ronda 15 r15-08b/00-trial-0 (experiments/round15/joint.json, regla experiments/rounds/r15.json). Reajuste de calibración: ronda 28, brazo 08b-r15 (experiments/rounds/r28.json).
• Pesos publicados: revisión del Hub 9a45d25e; sha256 del adaptador 9b908623…, sha256 de head.pt f400bd12… (T = 2.3511).
• Historial de publicaciones: publicado el 2026-09-24 como candidato confirmado de la ronda 15; incluido sin cambios en Kev 1.0. El registro de cómo se seleccionó, incluidas suites retiradas después por poco sólidas (scienthoon, WANLI-v2, TypeSafe), es el README en la revisión del Hub 9a45d25e y PLAN.md en la etiqueta de git research-archive-2026-09-24.

Cita

@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}
}

Contacto

Preguntas e incidencias: github.com/jaredpalmer/kev/issues.