Kev-9B

Resumen del modelo

Kev-9B 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. Está pensado para desarrolladores que clasifican, enrutan, triajan o comprueban documentos y que necesitan probabilidades sobre las que se pueda aplicar un umbral, por ejemplo para enviar los casos inciertos a revisión humana. Implementa la API pública System One de TypeSafe (POST /v1/systemone), así que el SDK de TypeSafe funciona contra él sin cambios. Es un adaptador LoRA y una cabeza de puntero sobre Qwen3.5-9B-Base y cabe en una GPU de la clase de 24 GB. Esta tarjeta describe la versión 2, publicada el 2026-09-30 e incluida en Kev 1.0.

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 sobre documentos de unos miles de tokens: clasificación, enrutamiento, triaje, elecciones de extracción, comprobaciones de política y elegibilidad, y juzgar una respuesta propuesta contra criterios enunciados.
• Flujos de trabajo que actúan según la confianza: automatizar los casos con confianza y poner en cola el resto, con umbrales congelados sobre una muestra etiquetada de la propia carga de trabajo del usuario.
• Un sustituto autoalojado y directo de un endpoint System One en una sola GPU de la clase de 24 GB, y un punto de partida para hacer fine-tuning con las propias etiquetas del usuario (kev.train --init_from jaredpalmer/kev-9b).

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.
• Decisiones totalmente automatizadas con consecuencias legales, médicas, financieras, laborales o similares para personas, sin revisión humana.
• Preguntas cuya respuesta depende de hechos que no están en el estado ni son conocimiento general, y exámenes con mucho conocimiento (véase Limitaciones).
• Aritmética de fechas con precisión de día sin el preprocesador KEV_DATE_FACTS=1, 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 L40S o H100; unos 22 GB residentes); 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-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 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. KEV_DATE_FACTS=1 añade el número de días entre cada par de fechas encontradas en el estado, que el modelo se entrenó para usar. 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 10,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 5e-5, esquema one-cycle; lote efectivo 8 (4 × 2 de acumulación); autocast bf16, gradient checkpointing. 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 2e-5 y 2,000 registros repetidos. Esta es v1.
3. Documentos y habilidades. Una época desde v1 sobre los tres conjuntos de entrenamiento juntos con tasa de aprendizaje 2e-5 y 10,000 registros repetidos; lote 2 × 4 de acumulación; estados de como máximo 7,552 tokens; semilla 1; 3,318 pasos de optimizador.
4. Calibración. Una única temperatura, T = 2.19, que minimiza la log-verosimilitud negativa en 648 preguntas de conjuntos de datos reservados: 448 de la partición de calibración de transfer-r3 (seis conjuntos de datos públicos, QNLI, SciQ, TweetEval-offensive, PAWS, MMLU y Emotion, más dos familias reservadas de registros de política generados) y 200 preguntas de MMLU-Pro (desarrollo transfer-v9). El conjunto se comprobó contra las suites de entrenamiento del checkpoint antes del ajuste.

Evaluación

Metodología. Cada comparación es contra Kev-9B v1 con elementos idénticos, cada modelo a su propia temperatura servida (v1: 2.30). Las comparaciones y sus listones se registraron antes de las lecturas de confirmación; las particiones de test se leyeron una vez para este checkpoint; el test transfer-v4 está bloqueado (se lee una vez por candidato). 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.
• transfer-v4: decisiones fuera de dominio de seis fuentes públicas nunca entrenadas más estructuras de política y reglas reservadas.
• transfer-r3: un panel de estado corto de las mismas ocho fuentes reservadas que el conjunto de calibración.
• 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 de devtools-v1 excluyen dos tareas cuyas etiquetas no determina el estado (flakeflagger, tipo de cambio de commit); las mismas filas salen de ambos lados.

Resultados frente a v1 (confirmación registrada).

Datos reservados (nunca entrenados).

Frente a v1, la diferencia de precisión en breadth-v1 es +0.3 [−0.7, +1.3] en desarrollo y +0.6 [−0.4, +1.6] en test. El desarrollo de tasksource-heldout-v1 se ha leído para este checkpoint, pero su lectura no está completa; no se informa aquí.

Familias entrenadas (elementos y plantillas reservados).

Diferencias de test frente a v1: hard-v1 +25.0 [+22.0, +28.1], devtools-v1 (todas las fuentes) +15.4 [+11.0, +19.4], documents-v2 +8.0 [+5.9, +10.2].

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

Calibración (error de calibración esperado, ECE, tal como se sirve; más bajo es mejor):

El intervalo bootstrap del 90 % de la temperatura es [2.05, 2.41]. El 2.30 de v1 se ajustó sobre filas de desarrollo de su propia distribución de entrenamiento; v2 es el primer 9B servido a una temperatura ajustada sobre conjuntos de datos reservados.

Otros resultados.

Servicio. CUDA, bf16 con kernels fusionados y CUDA graphs; tiempo de modelo por solicitud (mediana de 20) para un estado nuevo / repetido, medido en v1 (la misma arquitectura y forma de adaptador):

La memoria de GPU residente es 21.9 GB. Las probabilidades servidas se mantienen dentro de 0.017 de la ruta de evaluación fp32 en 280 preguntas, sin respuestas cambiadas. En la ruta de evaluación fp32 (H100, v2), los estados de 16k / 32k / 64k tokens tardan 5.1 / 10.9 / 25.4 s y 4.6 / 9.1 / 18.2 GiB por encima de los pesos.

Apple Silicon (MLX): las mediciones de estado largo hechas para Kev-0.8B y Kev-4B no se han hecho a este tamaño; en el M5 de 32 GB usado para ellas, el backbone bf16 de 19.3 GB y su conjunto de trabajo no cabían en la memoria disponible.

¹ 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

• Selección. Este checkpoint se entrenó y leyó con datos de desarrollo en una ronda anterior, y se volvió a seleccionar bajo una regla posterior conociendo esos números. Las particiones de test y la lectura bloqueada, cada una leída una vez para él, son la salvaguarda; trata los márgenes de desarrollo como optimistas.
• Sus grandes ganancias son en distribución. Las particiones de entrenamiento de hard-v1, devtools-v1 y documents-v1 están en sus datos de entrenamiento; esas ganancias son elementos y plantillas reservados de familias entrenadas, no transferencia a tareas nuevas.
• No es mejor que v1 en trabajo nuevo. test breadth-v1 +0.6 pp [−0.4, +1.6], desarrollo transfer-v4 −0.2 pp [−2.4, +1.8], test transfer-r3 +0.0 pp [−1.2, +1.2]. Kev-27B le saca 11 puntos en el índice de breadth-v1, y Jev 13.
• El conocimiento lo fija la base. MMLU-Pro es 0.590, frente al 0.675 de Kev-27B y al 0.840 de Jev.
• La aritmética de fechas es su familia más débil: 0.725 en las preguntas de política deadline frente al 0.95 de Jev; el preprocesador KEV_DATE_FACTS=1 ayuda.
• Calibración. devtools-v1 es su suite peor calibrada (ECE de test 0.098). El intervalo de la temperatura es [2.05, 2.41]. La temperatura se escribió en head.pt a partir del ajuste registrado del conjunto, con el motivo registrado, porque el script de calibración no puede listar las fuentes del archivo de entrenamiento combinado para volver a comprobar el propio conjunto; la comprobación propia de la ronda lo había cubierto. Esa comprobación no cubre los datos de fechas y evidencia ausente de v1, cuyo manifiesto no lista fuentes; esos registros son cuatro familias generadas, ninguna de ellas en el conjunto.
• 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 conjuntos de datos públicos reservados 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. 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 y etapa de fechas (v1): GPUs NVIDIA H100 individuales.
• Etapa de documentos y habilidades: 2.6 horas en una NVIDIA H200 (pico 74.1 GB).
• Comprobaciones de evaluación y servicio: GPUs H100 / H200 / L40S individuales en Modal.

Procedencia y reproducibilidad

• Código, suites e informes de evaluación: github.com/jaredpalmer/kev. Números de publicación: runs/release/kev-9b-r27.json (scripts/release_numbers.py --release kev-9b-r27); regla registrada y veredictos experiments/rounds/r27.json, runs/r27-readout/, runs/r27-verdict/; las lecturas familiares del 2026-09-30 runs/fam-9bnew-breadth/, runs/fam-9b-breadth/ y runs/fam-breadth-test-report/; ood-v2 runs/r29-9b-r18a-ood/; servicio runs/serve-9b-l40s/, runs/serve-9b-h100/, runs/long-state-9b-h100/.
• Etapas: ensayo base q35-9b/01-trial-1 (etiqueta v7-base); fechas night2-9b-du/00-trial-0 (v1, etiqueta v1); documentos y habilidades ronda 18, brazo (a) r18-9b/00-trial-0 (experiments/round18/joint.json), seleccionado y confirmado como 9b-r18a de la ronda 27.
• Pesos publicados: commit del Hub b5d8c18e; sha256 del adaptador 2b2a70cf4ef4440b6c22899e1f72c2f8ea5c6f65b19aa344539b4b8971d1f13d, sha256 de head.pt 8e1dab2c… (T = 2.1936).
• Verificación: cargado de forma anónima desde el Hub, reprodujo las respuestas de la evaluación previa a la publicación en 252 de 252 filas de SemIf y 764 de 764 filas de desarrollo de transfer-v4 a T = 2.19 (runs/rel9-public/).

Cita

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

Contacto

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