Kev: modelos de decisión open source sobre Qwen3.5

Qué es Kev y por qué importa si no usas TypeSafe

Kev es una familia de modelos de decisión open source publicada por Jared Palmer que replica, sobre pesos abiertos, la idea de “System One” que TypeSafe lanzó como producto cerrado el 15 de septiembre de 2026. En la práctica: Kev te deja correr localmente un modelo pequeño que, en lugar de generar texto, devuelve decisiones tipadas con probabilidades, los mismos tres tipos de pregunta que Jev (choice, noul, score), bajo una API compatible con el SDK de TypeSafe.

El repositorio jaredpalmer/kev en GitHub incluye tres tamaños —Kev-0.8B, Kev-4B y Kev-9B, todos sobre bases Qwen3.5— con código de entrenamiento, datos de evaluación y un playground web. La promesa es concreta: clasificar tickets, puntuar urgencia o detectar frustración sin mandar datos a una API cerrada, en tu propia Mac o GPU.

Qué resuelve un “modelo de decisión” y por qué Jev encendió la conversación

TypeSafe, la startup detrás de Jev, salió del stealth el 15 de septiembre de 2026 con una ronda semilla de US$40 millones liderada por DCVC, según reportó Forkast, a una valoración reportada de unos US$200 millones. Su CEO, Diogo Almeida, es ex-OpenAI y coinventor de RLHF; su CTO es Erik Gafni, y la cofundadora Sasha Sheng.

🤖 La IA no es solo para leer sobre ella

En la comunidad la aplicamos: automatización, agentes IA y herramientas reales para emprender, no solo para informarte.

👥 Aplicarla en la comunidad

La tesis: la mayor parte de lo que hoy hacen los LLMs en pipelines agentic —routing, clasificación, scoring— no requiere generar texto. Jev responde en 70–500 ms con un costo de US$0,042 por millón de tokens de entrada (salida gratis), frente a los segundos y dólares que cobra un modelo generativo para la misma tarea. TypeSafe reportó, en benchmarks internos, hasta 193,6 veces más rápido y 444,6 veces más barato que LLMs frontera en workflows de System One.

El problema es que esos benchmarks los mide TypeSafe contra la media de GPT-6 Astra y Fable 5.1, usando workflows escritos por el propio equipo. Y el modelo es solo hosted, sin pesos abiertos ni opción self-host. Ahí entra Kev.

Qué hay dentro del repositorio

El README de Kev describe una API idéntica a https://api.typesafe.ai/v1/systemone, expuesta en local con python -m kev.serve. Una sola petición acepta múltiples preguntas contra el mismo state:

{
  "state": "Shoes arrived two weeks late and in the wrong size...",
  "model": "kev-latest",
  "questions": {
    "department":  {"type": "choice", "criteria": {...}},
    "escalate":    {"type": "noul"},
    "frustration": {"type": "score", "criteria": ["Calm","Frustrated","Very angry"]}
  }
}

La respuesta devuelve la opción elegida, las probabilidades por opción y un confidence calculado como (p_max − 1/K) / (1 − 1/K) para Choice, y una aproximación de la fórmula de TypeSafe para Score. Los tokens de salida son gratis en costo y baratos en latencia porque el modelo no genera texto.

Kev soporta el SDK Python de TypeSafe (from typesafe_sdk import Choice, Noul, Score, TypeSafeClient), por lo que puedes escribir código hoy contra Jev hosted y mañana apuntar a tu servidor local con un cambio de base_url.

Tamaños, hardware y rendimiento real

Los pesos viven en Hugging Face bajo jaredpalmer/kev-* y en el release de GitHub con SHA-256:

Kev-0.8B sobre Qwen3.5-0.8B-Base — corre en GPUs pequeñas y Macs.
Kev-4B sobre Qwen3.5-4B-Base — cabe en una Mac de 32 GB en bf16.
Kev-9B sobre Qwen3.5-9B-Base — para cuando la calibración y accuracy pesan más que la memoria.

Sobre Mac, los números oficiales en M5 con cinco preguntas de tres opciones en un state de ~230 tokens:

Kev-0.8B: 329 ms (vs. 123 ms de la generación previa sobre Qwen3)
Kev-4B: 779 ms (vs. 174 ms de Kev-4B Qwen3)
Kev-9B: ~2 s (vs. ~300 ms de Kev-8B Qwen3)

La regresión en latencia es real y documentada: Qwen3.5 mezcla capas de atención con capas Gated DeltaNet recurrentes, y Apple Silicon todavía no tiene kernels optimizados para DeltaNet. El propio repo recomienda, si sirves en Mac con latencia crítica, quedarte con los modelos Qwen3 anteriores. El backend MLX para Qwen3.5 está listado como “próximo cambio planificado”.

Sobre CUDA con un H100, una petición de cinco preguntas corre en decenas de milisegundos, según el repo. Para H100 el repo documenta la instalación de flash-linear-attention.

Resultados en evaluación: qué dice y qué no dice

La tabla oficial del repositorio reporta accuracy (dev / test) y Brier (dev / test):

Kev-0.8B: trained sources 0,829 / 0,827; new sources 0,643 / 0,668; Brier new sources 0,513 / 0,473
Kev-4B: trained sources 0,877 / 0,870; new sources 0,794 / 0,832; Brier new sources 0,316 / 0,266
Kev-9B: trained sources 0,876 / 0,873; new sources 0,812 / 0,837; Brier new sources 0,291 / 0,243
Jev hosted: trained sources 0,845 / —; new sources 0,857 / —; Brier new sources 0,211 / —

El propio README aclara: Kev-9B queda unos 4,5 puntos por debajo de Jev en el set de desarrollo de “new sources”, y como no se sabe con qué datos entrenó Jev, no es una comparación controlada. Sobre el set de test bloqueado, Kev-9B supera a su predecesor Kev-8B por 7,3 puntos (IC 95 % +2,8 a +11,7) con Brier 0,08 más bajo; Kev-4B lo supera por 2,9 puntos (−0,9 a +6,4); Kev-0.8B supera a Kev-0.6B por 4,8 puntos (+0,2 a +9,3).

El repo también publica resultados sobre test sets externos convertidos a su formato: SemIf (144 decisiones) — Kev-9B 0,917 vs Jev 0,965 y scienthoon (900 tickets de soporte) — Kev-9B 0,952 en routing y 0,911 en tone, frente a Jev 0,897 y 0,914. Donde Jev gana por poco, Kev-9B también puede ganarle en routing de soporte real.

Cómo entrenar tu propio Kev en minutos

El flujo documentado está pensado para que un founder lo ejecute sin reinventar la arquitectura:

Prepara un train.jsonl con la misma forma que la API, añadiendo label por pregunta (choice → nombre de opción, noul → true/false, score → índice desde 0). Separa 10–20 % para evaluación.
Lanza el fine-tune partiendo del checkpoint público con --init_from jaredpalmer/kev-4b:

   uv run python -m kev.train --data train.jsonl \
     --base Qwen/Qwen3.5-4B-Base \
     --init_from jaredpalmer/kev-4b \
     --epochs 2 --lr 2e-5 --batch 1 --accum 8 \
     --dtype bf16 --checkpointing 1 --device cuda --out runs/mine

Evalúa y sirve localmente:

   uv run python -m kev.benchmark --run runs/mine --data heldout.jsonl --out runs/mine-eval
   KEV_DTYPE=bf16 uv run --extra serve python -m kev.serve --run runs/mine --port 8009

El --init_from es la pieza clave: el propio repo cuenta que un usuario, entrenando desde la base Qwen3.5-4B, pasó de 0,33 a 0,84 en el eval interno de Kev solo por partir del checkpoint en lugar del modelo base, y llegó a 0,88 en su dominio nuevo conservando 0,83 en el eval de Kev. La moraleja que el repo repite: fine-tunear desde la base suele empeorar lo que Kev ya sabe; partir del checkpoint público lo preserva.

Con --batch 1 --accum 8 en bf16 el modelo 0.8B cabe en una GPU de 4 GB. El trainer chequea que la base, revisión, rank LoRA y tamaño del head coincidan antes de cargar nada.

Qué significa esto para tu startup

Si hoy ruteas tickets con un LLM generativo, Kev es una alternativa local que cuesta cero por llamada una vez entrenado y corre en una Mac. Útil cuando el volumen sube y el costo por clasificación empieza a doler.
El switch desde Jev es de una línea de código: la API y el SDK de TypeSafe funcionan contra http://127.0.0.1:8009. Empieza hosted para validar, migra a local cuando privacidad o costo lo justifiquen.
El playground web (localhost:3001) incluye presets útiles para founders: “Packed vs separate” mide si empaquetar preguntas en una sola llamada cambia probabilidades; “Permute” mide sensibilidad al orden de las opciones; hay un demo de ajedrez donde las jugadas legales son opciones choice y un score evalúa la posición.
Tres acciones concretas:
Audita tu pipeline de soporte: ¿qué decisiones repetitivas paga hoy un LLM frontera? Lista 3–5 candidatos a choice (routing, categoría, idioma) o score (urgencia, frustración).
Etiqueta 200–500 ejemplos reales de tu dominio en el formato JSONL del repo y lanza un fine-tune de 1 hora en H100 partiendo de jaredpalmer/kev-4b.
Define umbrales de confidence por pregunta: alto → automatiza; medio → muestra sugerencia al humano; bajo → escalar. El README insiste en que probabilidades sin calibrar en tu dominio son la fuente #1 de errores.