Una tarjeta de título generada para una comparación de pplx-decider y Kev, etiquetada como ambos descargables desde Ollama hoy, que señala el lanzamiento de pplx-decider el 2026-10-01 y su revisión el 2026-10-05, la llegada de Kev v2 el 2026-09-30 en siete tamaños, la temperatura en tiempo de carga de Kev de 1,32 frente a la temperatura no publicada de pplx-decider, y las ventanas de estado de 65.536 tokens frente a 8.192 tokens.
Engineering & Research

pplx-decider vs Kev: dos sistemas, un modelo que ya puedes descargar

Autor

Elias Hawthorne

Fecha de publicación

Últimos modelos · 20Ver todos los modelos →
Benchmarks: Artificial Analysis · actualizado a diario
Volver a todas las publicaciones

El accidente útil de esta comparativa es que puedes resolverlo en tu propio hardware esta tarde. pplx-decider, el modelo de decisión de 27B de Perplexity, apareció el 2026-10-01 sin anuncio alguno y con una revisión v1.1 el 2026-10-05, y ambos están en la biblioteca de Ollama. Kev, la línea de reproducción de Jared Palmer, ha estado en Ollama desde que v2 llegó el 2026-09-30 y cubre de 0.5B a 27B. Comparten la misma forma de llamada —un estado más una lista de preguntas con nombre, una pasada hacia adelante, una probabilidad de retorno, sin texto generado—, lo que significa que el mismo arnés puede ejecutar ambos. Lo que difiere es todo lo que hay debajo: cómo se produce la salida, qué documentaron los autores y cuánta GPU requiere.

Empieza por lo que hace posible un bake-off en primer lugar. Ninguno de los modelos escribe texto. Entregas un documento y haces preguntas por nombre, y cada pregunta declara su tipo de respuesta: una elección entre 2 y 255 opciones etiquetadas, una lectura de sí/no/desconocido, o una puntuación en 2 a 10 niveles descritos. La respuesta llega como una probabilidad, en el orden en que preguntaste. Un ticket con sesenta preguntas es una sola pasada por el modelo, no sesenta llamadas.

¿Cuánto de cada modelo está realmente tomando la decisión?

La ficha de Kev es explícita sobre su construcción de una manera que es rara fuera de los informes internos, y merece la pena leer el detalle antes de fiarse de cualquier número que provenga de ella. El checkpoint de 27B es un ajuste fino supervisado de pesos completos sobre Qwen/Qwen3.8-27B, y luego un promedio de pesos: 0,85 del nuevo modelo combinado con 0,15 de v1 en fp32. Los tamaños más pequeños, de 0,8B a 9B, se distribuyen como adaptadores LoRA sobre las bases de Qwen3.5 en lugar de checkpoints completos.

La parte que decide cómo se da forma a la salida está separada del backbone del lenguaje. Kev lleva una cabeza de puntero —unos 2,6 M de parámetros en fp32, situada sobre un backbone de 25,6 B para llegar a 26 B— que es lo que convierte un estado oculto en una probabilidad sobre tus opciones con nombre. pplx-decider hace el mismo trabajo con una cabeza de lectura publicada de [255, 5120]: 255 opciones sobre un estado oculto de 5.120 de ancho, en bf16.

Dos arquitecturas, una idea: el modelo de lenguaje lee, una cabeza pequeña decide. Por eso ninguna genera prosa, y también por eso una puntuación de benchmark de una no se transfiere a la otra, incluso cuando ambas se comparan con el mismo modelo de referencia.

El único enfrentamiento directo que consta en el registro, y por qué no puedes restarlo.

Ambos proyectos reportan con respecto a Jev, lo que hace tentador alinearlos. No lo hagas.

La propia tarjeta de Kev incluye una fila de Decision Index 0.2 que sitúa a Kev-27B v2 en 52,3 frente a 50,2 de v1, a Jev en 54,0 y a AutoJev-27B en 50,0. Es una comparación limpia, con la misma suite y la misma versión, y dice que Kev v2 mejoró alrededor de dos puntos y aún sigue por detrás de Jev.

Las tarjetas de pplx-decider reportan un resultado global ponderado por suite de 61,56 para v1.1, frente a 56,4 para v1 y 57,9 para Jev. Según sus propios números, eso supone una ganancia de más de cinco puntos en una sola revisión y una ventaja sobre Jev de más de tres y medio.

Esos dos párrafos no se pueden restar entre sí. Distintas suites, distintas combinaciones de tareas, distinta ponderación —y ninguno de los dos proyectos publica la ponderación—. Lo que se puede decir es más acotado y sigue siendo útil: ambos se movieron en la misma dirección en la misma ventana, ambos lo hicieron cambiando cómo se entrena el readout en lugar de sustituir el backbone, y el margen que pplx-decider afirma tener sobre Jev es mayor que el déficit medido de Kev. Eso es una razón para probar pplx-decider, no una razón para creer en él.

Solo uno de los dos tiene una replicación independiente vinculada a alguno de sus números. Las etiquetas de Ollama de Kev publican recuentos de aprobados de JevBench por etiqueta —205 de 231 para kev:27b-nvfp4, incluidos 86 de 111 en la división difícil, hasta 146 de 231 para kev:0.8b— con una nota explícita de que estos excluyen 303 tareas no disponibles, selladas o calificadas por jueces, y no son una puntuación oficial de la tabla de clasificación. Es una ejecución propia, pero es una ejecución propia que puedes repetir. No existe nada comparable para pplx-decider.

A screenshot of the Kev-27B model card on Hugging Face, showing the Qwen/Qwen3.8-27B foundation with 64 layers split into 48 Gated DeltaNet and 16 full-attention layers at a hidden size of 5,120, a 25.6B backbone plus a 2.6M-parameter pointer head making 26B, bf16 weights at 51.3 GB, a served context of 65,536 tokens plus at least 8,192 per question, T = 1.32, Apache-2.0 licensing, a v2-versus-v1 benchmark panel, and a Decision Index 0.2 row reading Kev-27B v2 52.3, v1 50.2, Jev 54.0 and AutoJev-27B 50.0 with ECE 0.015 on breadth-v1 and 0.053 on CUAD.

Lo que Kev documenta que pplx-decider no documenta

• Temperatura — Kev se distribuye con T = 1.32, un intervalo del 90 % de [1.20, 1.45], aplicado al cargar, por lo que las probabilidades que obtienes ya están escaladas. Las tarjetas de pplx-decider no publican temperatura alguna, lo que significa que cualquier calibración que necesites tendrás que ajustarla tú.

• Registro de entrenamiento — Kev v2 supone 129 horas de GPU en 8× H200, una época sobre 145.840 registros y 337.130 preguntas, con etiquetas producidas por GLM-5.3, DeepSeek-V4-Pro, Inkling, Mistral Large 3, gpt-oss-120b y MiMo-V2.6-Pro sin usar ninguna salida de Jev, y un filtro de contaminación que eliminó 6.388 registros en 102 particiones de evaluación. pplx-decider documenta un pipeline construido sobre Bespoke Nimble, de Bespoke Labs, con subconjuntos de benchmark fijados por ID de registro y suma de comprobación, y atribuye las mejoras de la v1.1 a la eliminación de la máscara causal más los datos de entrenamiento añadidos — pero no publica ningún recuento de registros, ni horas de GPU, ni lista de etiquetadores.

• Informe honesto de regresiones — la ficha de Kev imprime sus propios fallos: transfer-v4 retrocedió 0,8 puntos, CUAD bajó 1,6, el error de calibración esperado en breadth-v1 es de 0,015 frente a 0,053 en CUAD, de dos a cuatro veces peor que la v1, y señala el optimismo de selección en su propia evaluación. La tabla v1.1 de pplx-decider muestra que herramientas cae de 79,3 a 78,88 mientras que todas las demás categorías suben, y nada en la ficha lo menciona.

• Modos de fallo — la ficha de Kev enumera el alcance del cribado de contaminación y las condiciones en las que se generaron sus cifras publicadas. La familia Decider, la línea de Mapika, va más allá y nombra formas de entrada concretas que la rompen; pplx-decider guarda silencio sobre la cuestión.

Nada de esto dice que pplx-decider sea peor. La documentación no equivale a capacidad: un laboratorio con una publicación de lanzamiento en borrador tiene incentivos distintos a los de una persona que publica notas en Hugging Face. Pero cuando dos modelos afirman el mismo tipo de resultado y solo uno de ellos te dice su temperatura, el que te lo dice es el que puedes poner en producción este mes.

A screenshot of the pplx-decider entry on the Ollama library, showing the 27b tag at 17 GB, vision and 27b badges, the CLI and API tabs, a worked example asking whether a refund is being requested, and a vendor-reported accuracy panel reading pplx-decider 85.7% against Jev 84.5% and Qwen3.8-27B 74.8%.

La contabilidad del contexto, que es donde los dos divergen más drásticamente.

• Kev — 65.536 tokens de estado, además de al menos 8.192 tokens por pregunta, con entrenamiento de hasta 32.768. Con un estado de 64k, la huella residente alcanza alrededor de 87,1 GB en su punto máximo, el tiempo del modelo es de 9,4 segundos, 733 ms en un acierto de caché, y 21,1 solicitudes por segundo con un solo cliente frente a 36,4 con sesenta y cuatro.

• pplx-decider — 8.192 tokens para texto e imágenes combinados, con las entradas demasiado grandes rechazadas en lugar de truncadas. La compilación de Ollama enumera una ventana de contexto de 256K, lo cual nada en el repositorio explica y que no concilia con el propio límite de la tarjeta.

Esa brecha es la diferencia más determinante entre ambos para cargas de trabajo reales. Kev está diseñado para estados largos y muchas preguntas sobre ellos. pplx-decider es un modelo denso de 27B con un presupuesto de entrada relativamente pequeño, lo que lo orienta hacia documentos cortos, imágenes y preguntas que caben en unos pocos miles de tokens.

• Idioma — solo inglés en ambos, indicado como una limitación en ambos.

• Visión — pplx-decider acepta texto, JSON e imágenes, con tokens de visión que cuestan aproximadamente ancho × alto / 1024 y una configuración de evaluación limitada a 512×512. Kev no tiene visión en la línea 27B.

• Base de servicio — Kev-27B necesita una GPU de la clase de 80 GB: 51.3 GB de pesos bf16, unos 65.5 GB residentes, 87.1 GB con un estado de 64k, y su servidor se enlaza abiertamente a menos que se defina KEV_API_KEY. Los pesos bf16 de pplx-decider rondan los 49 GiB, así que la base es similar; la compilación cuantizada de Ollama se queda en 17 GB, lo que supone una máquina muy diferente.

• Peldaños — Kev abarca 0.5B, 0.6B, 0.8B, 4B, 8B, 9B y 27B, con los tamaños pequeños como adaptadores LoRA. pplx-decider es un tamaño, revisado dos veces.

Ejecutar la comparativa sin apostar por ella

Ambos modelos son accesibles como pesos locales, que es exactamente la situación en la que una capa de enrutamiento se gana su lugar. OrcaRouter no sirve a pplx-decider y no sirve a Kev — ninguno está en el catálogo, y nada de esto debe interpretarse como una afirmación de que los alojamos. Lo que sí ofrecemos en esta clase es typesafe/jev-1.13, expuesto mediante la misma forma de llamada POST /v1/systemone a $0.042 por millón de tokens de entrada, y es el brazo de control natural: misma interfaz, mismos tipos de pregunta, sin GPU propia.

Eso hace que una comparativa a tres bandas sea barata de preparar. Pon un pplx-decider local y un Kev local en el mismo arnés frente a un typesafe/jev-1.13 enrutado, puntúa los tres con tus propios documentos y deja que el desacuerdo entre ellos te diga dónde se sitúan realmente tus umbrales. La conmutación por error automática importa más de lo habitual en esa configuración, porque un 27B local en una sola tarjeta es el componente menos fiable de la cadena; enrutar el fallback a través de una API para más de 200 modelos — el precio de lista del proveedor transferido tal cual con un 0 % de margen — evita que el experimento se convierta en una caída. Y cuando un modelo como pplx-decider llegue finalmente a un endpoint alojado, la misma clave que ejecuta el brazo de control lo ejecuta, sin un segundo contrato y sin cambios en el código.

A generated two-column scoreboard comparing pplx-decider v1.1 and Kev-27B v2 across six dimensions, contrasting pplx-decider's reported 61.56 against Jev 57.9, 8,192-token state window, vision support and unpublished latency against Kev's measured 52.3 against Jev 54.0, 65,536-token state window, SFT-plus-weight-average readout training, LoRA adapter down to 0.8B and published latency of 9.4 seconds at a 64k state with 733 ms cached, with a footer noting both columns are vendor-reported.

¿Qué cambiaría la respuesta?

Cuatro cosas, y todas ellas son verificables en lugar de una cuestión de gusto.

Si pplx-decider llega a un proveedor de inferencia, su tabla de benchmarks no verificada se convierte en una cuestión de precio frente a latencia, y la brecha de documentación deja de importar —estarías pagando por un resultado alojado, no por mantener uno. Si un tercero independiente reproduce los números de JevBench de cualquiera de los dos modelos en un arnés publicado, toda la comparación se reduce a una sola suite en lugar de a dos incompatibles.

Si la debilidad documentada de Kev en ECE sobre CUAD resulta ser corregible con un reajuste en lugar de un reentrenamiento, el argumento de calibración en su contra desaparece en gran medida, porque Kev ya incluye su temperatura y sus modos de fallo son cantidades conocidas. Y si necesitas un modelo de decisión en una sola tarjeta en lugar de dos, la compilación cuantizada de 17 GB de pplx-decider es la única opción aquí — no porque sea mejor, sino porque cabe donde uno de 27B en bf16 no cabe.

Hasta que ocurra una de esas cosas, la lectura práctica es poco glamorosa. Kev es el que tiene números que puedes reproducir hoy y una calibración de la que puedes tener la certeza de que está documentada; pplx-decider es el que tiene el techo declarado más alto y el rastro documental más débil. Elige el primero si vas a lanzar este mes. Mete el segundo en el mismo arnés si eres el tipo de equipo que preferiría medir un lanzamiento silencioso antes que esperar un post de lanzamiento.

Enrutar el fallback a través de precio de lista del proveedor transferido con 0% de margen evita que una comparación de tres vías se convierta en una caída del servicio cuando el checkpoint local es el componente menos fiable de la cadena.

Una comparativa a tres bandas también es un buen momento para preguntarse qué ha fallado ya en esta clase: los incidentes de IA y los fallos de agentes documentados que involucran modelos de decisión se recopilan en el OrcaRouter AI Incident Archive, donde cada entrada incluye sus propias fuentes, su gravedad, su grado de confianza y su marca de disputa.