pplx-decider vs Decider: el 27B silencioso de Perplexity contra la Open Ladder de Mapika

Hay dos modelos de decisión en Hugging Face ahora mismo que responden a las preguntas de la misma manera y no coinciden en casi nada más. pplx-decider es un checkpoint de 27B de Perplexity que apareció el 2026-10-01 sin anuncio, sin entrada de blog, sin página de precios y sin ningún proveedor de inferencia que lo aloje; una revisión, pplx-decider-v1.1, le siguió el 2026-10-05 sobre el mismo backbone. Decider es la familia de Mapika de la misma clase de modelo —decider-0.8b hasta decider-35b-a3b—, una reproducción abierta en el linaje System One, publicada con notas de entrenamiento completas. Ambos toman un bloque de preguntas con nombre más un documento y devuelven una probabilidad calibrada por respuesta en una sola pasada hacia adelante. Ninguno escribe una sola frase de prosa. Lo que sigue es lo que realmente está registrado para cada uno, y un marcador claro allí donde termina el registro.

Primero, ¿qué está haciendo "modelo de decisión" en esa oración?

Ninguno de estos es un modelo de chat al que se le haya pedido que sea conciso. No son modelos de lenguaje en absoluto en el sentido habitual — no hay bucle de decodificación, ni muestreo, ni nada token por token. Una sola pasada hacia delante sobre tu documento devuelve una probabilidad para cada opción que hayas proporcionado.

La forma de la llamada es lo que hace que merezca la pena escribir la comparación. Entregas un estado (un ticket, un registro JSON, una captura de pantalla, un contrato) y una lista de preguntas con nombre. Cada pregunta indica su tipo de respuesta: elección entre 2 a 255 opciones etiquetadas, una lectura de sí/no/desconocido, o una puntuación en 2 a 10 niveles descritos. Las respuestas vuelven en el orden en que las pediste, como números entre 0 y 1, y el número debe leerse como una probabilidad en lugar de como una etiqueta limpia — 0,62 en "¿se está solicitando un reembolso?" es toda la salida, y quien llama decide el umbral.

Ese diseño elimina la latencia y el costo, porque un documento con sesenta preguntas cuesta una sola pasada, no sesenta. También significa que las formas habituales de juzgar un modelo de lenguaje no se aplican: no hay rastro de razonamiento que leer, no hay cadena de pensamiento con la que discutir, no hay forma de pedirle que se explique. Obtienes masa de probabilidad y nada más. Ambos proyectos dejan claro que este es el intercambio.

Lo que se lanzó, y lo que nadie ha dicho

El repositorio pplx-decider es inusualmente completo para un modelo que no tiene una publicación de lanzamiento detrás. Los pesos son Apache-2.0. La base es Qwen/Qwen3.8-27B, tal como se indica en la tarjeta. Hay una cabeza de lectura publicada en bf16 con [255, 5120], que es exactamente la forma que cabría esperar para 255 opciones seleccionables sobre un estado oculto de 5.120 de ancho. La tarjeta documenta el presupuesto de entrada, el límite de opciones, los tres tipos de preguntas y la forma del endpoint: POST /v1/systemone.

Lo que no está es la frase que llevaría una publicación de lanzamiento. No hay fecha de lanzamiento en la tarjeta, ni anuncio, ni publicación de benchmark de Perplexity, ni precio, ni plataforma de terceros que lo sirva. Los recuentos de descargas son del tamaño que se obtiene de un repositorio que fue encontrado en lugar de promocionado. Si se leen los dos juntos, la descripción honesta es: el artefacto es público, la intención detrás de él no. Todo lo que sigue sobre pplx-decider proviene del repositorio y sus tarjetas. Nada de lo que sigue ha sido reproducido de forma independiente, y nadie fuera del laboratorio ha publicado una ejecución propia.

La entrada de la biblioteca de Ollama hace visible esa brecha de una forma pequeña. Su página enumera la etiqueta como 27b a 17 GB con una ventana de contexto de 256K —una compilación cuantizada, muy por debajo de los aproximadamente 49 GiB que ocupan los pesos bf16—, mientras que el repositorio documenta un presupuesto de entrada de texto e imágenes mucho menor y afirma que las entradas de tamaño excesivo se rechazan en lugar de truncarse. Esas dos afirmaciones no describen evidentemente el mismo límite, y nada publicado las reconcilia. Trata el número del entorno de ejecución como la afirmación del entorno de ejecución.

La parte interesante: dos desconocidos, una interfaz

La familia Decider de Mapika y pplx-decider se desarrollaron de forma independiente, a partir de bases distintas y por motivos distintos, y convergieron en el mismo formato de transmisión. Los modelos Decider también hablan la forma de llamada de System One: preguntas con nombre, elección entre 2 y 255 opciones, sin generación de texto, estados aceptados de hasta aproximadamente 32k. Un cliente escrito para uno es, prácticamente, un cliente para el otro.

Esa convergencia es el hecho útil en esta comparación. Elegir uno u otro no es una reescritura; es una sustitución de una URL base y una cadena de modelo. La pregunta interesante deja de ser «qué API integro» y pasa a ser «en qué lectura de mis documentos confío» —y los dos proyectos responden a esa pregunta de maneras muy diferentes.

Un checkpoint contra una escalera

La diferencia estructural es la más fácil de ver. Perplexity lanzó un único tamaño. Mapika lanzó una gama y publicó la tabla de tallas:

• Catálogo — pplx-decider: un checkpoint de 27B, más una revisión v1.1 sobre el mismo backbone. Decider: siete o más tamaños publicados, desde decider-0.8b con 1,4 GB hasta decider-2b, decider-2b-vision, decider-4b, decider-12b y decider-35b-a3b con 65 GB en bf16 o 19,6 GB en nvfp4.

• Bases — pplx-decider: Qwen/Qwen3.8-27B, un solo linaje. Decider: una mezcla — Qwen3.5-0.8B, Qwen3.5-2B y Qwen3.5-4B para los tamaños pequeños, Qwen3.5-35B-A3B para el grande, y gemma-4-12B-it y gemma-4-31B-it en las variantes de chat.

• Activación — pplx-decider: denso 27B, por lo que cada parámetro se ejecuta en cada llamada. Decider: decider-35b-a3b es una mezcla — 34.7B en total con aproximadamente 3B activos en 256 expertos enrutados, 8 de ellos activos por token.

• Visión — pplx-decider: multimodal, y el repositorio lo dice; texto, JSON e imágenes, incluidas capturas de pantalla, recibos y formularios, con tokens de visión que cuestan aproximadamente ancho × alto / 1024. Decider: un checkpoint decider-2b-vision separado en lugar de una bandera en la línea principal, por lo que el trabajo con imágenes es una elección de modelo distinta, no un argumento distinto.

• Licencia — Apache-2.0 en ambos lados, que es el único punto en el que esta comparación resulta aburrida.

• Divulgación del entrenamiento — pplx-decider: una canalización de datos que se basa en Bespoke Nimble de Bespoke Labs, con subconjuntos de referencia fijados por ID de registro y suma de comprobación, y las mejoras de la v1.1 atribuidas a la eliminación de la máscara causal y a la incorporación de datos, incluyendo tasksource. Decider: notas por versión con recuentos de elementos, hardware y tiempo real — decider-35b-a3b entrenado en 4× B300 durante 394 minutos sobre 1.543.567 elementos — además de modos de fallo con nombre y la proporción de parámetros realmente entrenados, 2,45B de 34,7B.

Ninguna de las dos es una ventaja decisiva. Un único checkpoint es más sencillo de razonar, más fácil de servir e imposible de reducir de tamaño. Una escalera te permite poner decider-0.8b detrás de un prefiltro barato y gastar los 35B solo en los elementos que lo necesitan — pero solo si estás dispuesto a mantener la lógica de enrutamiento que decide cuál es cuál.

Los números, y quién los produjo

Ambos conjuntos de cifras destacadas están reportados por los proveedores, y ninguno cuenta con una replicación independiente adjunta. Eso importa más aquí de lo que suele importar, porque no existe una tabla de clasificación de modelos de decisión de terceros que tenga el prestigio de las arenas de imagen o de lenguaje.

Las propias cifras de Perplexity para pplx-decider lo sitúan en el 85,7 % en 11 benchmarks públicos, frente al 84,5 % de Jev y el 74,8 % de la base Qwen3.8-27B con la que se entrenó. Las filas individuales reportadas incluyen RAGTruth 88,8, FinancialPhraseBank 84,2, TabFact 90,6, JudgeBench 78,3 y WinoGrande 83,3, y el conjunto más completo abarca Circa, Belebele, TruthfulQA binary, BBH, ContractNLI y una división pública difícil de JevBench. La revisión v1.1 reporta un resultado global ponderado por suite de 61,56 frente a 56,4 para v1 y 57,9 para Jev, con la mayor ganancia en una sola categoría en tareas de lenguaje. La comparación con Jev es del proveedor, calculada sobre la propia suite del proveedor, y la ponderación no se ha publicado.

El reporte de Mapika tiene una textura distinta: las cifras llegan acompañadas de salvedades que las socavan. decider-35b-a3b reporta 0.855 en tarea y 0.810 en reserva frente a una base de zero-shot de 0.732, y 0.676 en la partición difícil pública de JevBench — por debajo del 0.730 de Jev 1.13.0. La ficha también afirma que no hay una etapa de refuerzo, por lo que el juego muestreado se sitúa en 86.4% frente al 93.2% de decider-2b v10, y que el modelo es excesivamente confiado en los ítems más difíciles, con un error de calibración esperado de 0.15 en el nivel difícil. decider-2b v11 se reporta con 0.802 en tarea y 0.752 en reserva, con un ECE de 0.156 frente a una directriz de lanzamiento declarada de 0.08 — un incumplimiento, impreso por los autores.

Hay dos modos de fallo documentados que conviene tener presentes en cualquier evaluación que realices. Seleccionar un registro por su posición dentro de un array JSON largo se describe como la forma de entrada menos precisa que maneja la familia, y empaquetar varias preguntas independientes en una sola llamada puede alterar hasta el 12 % de las respuestas cuando el flag independent está desactivado. Ambas son el tipo de cosa que una hoja de especificaciones oculta y una tarjeta menciona una sola vez.

Cuánto cuesta ejecutar cualquiera de los dos

• El Decider viable más pequeño — decider-0.8b es 1.4 GB. pplx-decider no tiene una variante pequeña, así que su mínimo es el 27B completo.

• Decisor más grande — decider-35b-a3b con 65 GB en bf16 o 19,6 GB en nvfp4, con solo alrededor de 3B parámetros activos por token.

• Latencia, lado del Decider — decider-2b tarda 4 ms por solicitud con CUDA graphs en una B300, frente a 18,9 ms en modo eager, y alrededor de 2.700 decisiones por segundo con batch 32. El 35B es otro mundo: unos 47 ms para un ticket de 92 tokens con tres preguntas, 368 ms para 64 tickets.

• Latencia, del lado de pplx-decider — ninguna publicada. Las tarjetas no ofrecen ninguna cifra de throughput ni de latencia, lo cual es normal para un repositorio que no se lanzó.

• Costo por decisión — aquí es donde el diseño da sus frutos en ambos lados. Sesenta preguntas sobre un documento son una sola pasada hacia adelante en cualquier caso, así que el costo por decisión se desploma a medida que haces más preguntas sobre el mismo documento.

Este es el panorama honesto del enrutamiento. OrcaRouter no sirve pplx-decider, y no sirve a la familia Decider de Mapika — ninguno aparece en el catálogo, y nada en este artículo debe leerse como una afirmación de lo contrario. Lo que el catálogo sí incluye en esta clase hoy es typesafe/jev-1.13, un modelo de decisión de la misma forma System One con una ventana de 65,536 tokens expuesta a través del mismo endpoint POST /v1/systemone a $0.042 por millón de tokens de entrada, lo cual es un ancla útil para saber cuánto cuesta un modelo de decisión enrutado. Si estás evaluando un checkpoint no anunciado como pplx-decider, la manera de hacerlo sin poner en riesgo una ruta de producción es ejecutarlo tú mismo junto a un modelo enrutado detrás de una API para más de 200 modelos — el precio de lista del proveedor se traslada con un 0% de margen, así que cuando estos proyectos lleguen a un proveedor de inferencia, el precio de lista es el precio aquí el mismo día. Hasta entonces, un pplx-decider autoalojado junto a un typesafe/jev-1.13 enrutado es la comparación que realmente te dirá algo.

¿Cuál elegir?

Si necesitas un modelo de decisión hoy, en tu propio hardware, del tamaño que elijas, con notas de entrenamiento que puedas auditar y una licencia que no te exija nada, la respuesta es un checkpoint de Decider, y la única pregunta de verdad es qué escalón elegir. Empieza por decider-2b; los números de v11 muestran que la familia mejora frente a su propio v10 precisamente en la partición difícil que te importaría, y la brecha de ECE documentada te indica que reajustes una temperatura antes de confiar en las probabilidades en producción.

Recurre a pplx-decider si quieres la misma interfaz con un modelo denso más grande detrás, si las entradas de imagen importan y prefieres no ejecutar un segundo checkpoint, o si eres el tipo de equipo que preferiría evaluar por sí mismo la cabeza de lectura de un laboratorio de frontera antes que esperar una publicación de lanzamiento que puede que nunca llegue. Sus ventajas son reales, pero no están verificadas: una columna vertebral más grande, una tabla de benchmarks que lo favorece y un pipeline de entrenamiento documentado hasta sumas de verificación a nivel de registro.

Lo que hay que observar no es un benchmark. Es si pplx-decider llega siquiera a un proveedor de inferencia. Un repositorio con pesos y sin anuncio es una señal, no un producto; en el momento en que aparece en un endpoint alojado, la cuestión de precio frente a latencia que las tarjetas de Decider ya responden se convierte en una comparación real en lugar de una aspiración.

Ejecuta un pplx-decider autoalojado junto a un modelo de decisión enrutado detrás de precio de lista del proveedor transferido con 0 % de margen, de modo que cuando cualquiera de los proyectos llegue a un proveedor de inferencia, el precio listado sea el precio de aquí el mismo día.

Un nuevo checkpoint evaluado frente a una escala publicada también es un buen lugar para consultar el historial: los incidentes de IA documentados y los fallos de agentes relacionados con modelos de esta clase se recopilan en el OrcaRouter AI Incident Archive, donde cada entrada incluye sus propias fuentes, gravedad, grado de confianza e indicador de disputa.