pplx-decider en Ollama: el silencioso modelo de decisión 27B de Perplexity ya se puede ejecutar

Perplexity publicó los pesos de pplx-decider-v1.1-27b el 5 de octubre de 2026, y el primer checkpoint al que reemplazó, pplx-decider (nombre del repositorio: pplx-decider-v1-27b), el 1 de octubre de 2026. Ambos son ajustes finos de Qwen3.8-27B que responden en probabilidades en lugar de frases, y ambos se sitúan en el mismo linaje System One que el de TypeSafe Jev 1.13. Lo nuevo no es el modelo: a partir de hoy, pplx-decider es una entrada en la propia biblioteca de modelos de Ollama, instalable con un solo comando. Antes de que apareciera esa entrada, ejecutar este checkpoint requería una GPU CUDA con espacio para aproximadamente 49 GiB de pesos bf16. Ahora es una descarga cuantizada de 17 GB en un portátil. Ese único cambio es el tema de esta página, y el modelo que permite ejecutar tiene catorce días.

Qué ha cambiado, en términos concretos

La entrada de la biblioteca de Ollama se llama pplx-decider, y la biblioteca ha ido acumulando constantemente modelos de decisión —Laya, Nimble, Kev, Clef y Strands Decider— durante el otoño. Esta es la incorporación más reciente y, en el registro mantenido, expone tres etiquetas (pplx-decider:latest, pplx-decider:27b y pplx-decider:27b-q4_K_M) que apuntan al mismo digest del manifiesto. Un único artefacto, no una escalera de tamaños.

• Formato — GGUF servido por llama.cpp, frente a los fragmentos de safetensors bf16 en Hugging Face

• Tamaño de descarga — unos 17 GB en q4_K_M, frente a aproximadamente 49 GiB de pesos más memoria de trabajo para el checkpoint bf16

• Capa de visión — el manifiesto incluye un proyector separado de ~927 MB junto con la capa del modelo, por lo que la entrada de imágenes se empaqueta con los pesos de texto

• Hardware — una máquina de consumo en lugar de un equipo CUDA

La interfaz es el endpoint /v1/systemone de Ollama, que añadió en la v0.35.0 y amplió para los modelos Clef en la v0.35.1. También acaba de incorporar una interfaz de línea de comandos: la v0.40.4, publicada el 2026-10-12, añadió modelos de decisión a ollama run, así que se puede hacer una pregunta de sí/no, elegir una etiqueta o pedir una puntuación de rúbrica directamente desde una terminal con --ask, --choice y --level. Esa versión tiene tres días; el modelo que hace cómodo tiene dos semanas.

Lo que el repositorio documenta realmente

El checkpoint no es un modelo de chat con un prompt conciso. Su tarjeta describe un diseño de decisión nativo: la columna vertebral Qwen3.8-27B con el nombre de clase publicado, más un readout.safetensors separado que contiene un cabezal de decisión bf16 [255, 5120]: una lectura de 255 vías sobre las ranuras de opciones, no un cabezal de lenguaje de vocabulario completo. No hay bucle de decodificación. Cada opción de cada pregunta se puntúa en una sola pasada hacia adelante, y por eso la respuesta informa cero tokens de salida.

Tres detalles en la tarjeta importan más que la tabla de benchmarks, porque son los que rompen una integración ingenua:

• Modo de atención. Las capas de atención completa usan un modo no causal guardado, y la tarjeta dice claramente que la inferencia causal predeterminada no reproduce la configuración evaluada. Si ejecutas el checkpoint con un cargador causal estándar, obtendrás cifras que no son las publicadas.

• Temperatura de calibración. El DecisionModel.predict proporcionado aplica una temperatura guardada. Si lees los logits directamente, aplícala exactamente una vez: aplicarla dos veces, o no aplicarla en absoluto, escala mal cada probabilidad sobre la que luego ramificas.

• Un límite de decisión real. El texto y todas las imágenes para una decisión deben caber dentro de un presupuesto de 8,192 tokens, y las entradas que exceden el límite se rechazan en lugar de truncarse. El entrenamiento y la evaluación reportada limitaron las imágenes a 512×512; ahora se puede aumentar ese límite mediante max_image_pixels, cuyo valor predeterminado es 2048×2048, pero la tarjeta advierte de que las resoluciones más altas quedan fuera de la distribución de entrenamiento.

El repositorio es, por lo demás, inusualmente completo para un modelo que nadie anunció: once fragmentos de safetensors, un decision_config.json, una plantilla de chat y un release-manifest.json que registra sumas de verificación de archivos y procedencia del checkpoint. La licencia es Apache 2.0.

Dos fragmentos de la documentación han divergido. La ficha de la v1.1 sigue diciéndote que te autentiques contra «este repositorio privado»; hoy el repositorio es de lectura pública. Y la ficha más antigua de la v1 lleva un puntero new_version hacia la v1.1, que es la señal honesta de que la v1 ha sido sustituida.

Lo único que debes comprobar antes de planificar en torno a ello

El listado de Ollama anuncia una ventana de contexto de 256K. Ese número parece heredado del modelo base —Qwen3.8-27B sí tiene 262.144 posiciones— y no es el contrato que el checkpoint de decisión documenta para sí mismo. El checkpoint rechaza toda decisión cuyo texto más las imágenes supere los 8.192 tokens. Planifique un pipeline sobre 256K, aliméntelo con un contrato de 40.000 tokens más cuatro imágenes de páginas, y la solicitud falla en lugar de recortarse. La cifra mayor describe la arquitectura; la menor describe la API a la que realmente está llamando.

El soporte de imágenes tiene un límite similar. La tarjeta de modelo de Ollama para pplx-decider muestra una solicitud de imagen contra /v1/systemone, pero la propia página de capacidades de Ollama para ese endpoint indica que las imágenes son «solo para modelos Clef». Uno de esos dos documentos está desactualizado. Considera la entrada multimodal en esta ruta como no verificada hasta que la hayas probado tú mismo: el checkpoint subyacente claramente acepta imágenes, y el manifiesto claramente incluye un proyector, pero la restricción documentada del runtime es más estrecha de lo que implica la tarjeta del modelo.

Un número de proveedor, y un número diferente

La propia evaluación de Perplexity para el checkpoint v1.1 reporta un Decision Index de 61,56 frente a 57,9 de Jev en el mismo conjunto de pruebas y 56,4 del checkpoint al que reemplazó, con las mayores ganancias por categoría en lenguaje (69,45) y recuperación (61,26). Esas cifras las reporta el proveedor y se produjeron del lado de Perplexity; para el checkpoint anterior, la ficha va más allá y dice que los resultados se midieron a través de la API de Perplexity. Eso es algo legítimo de publicar y una base débil en la que apoyarse.

El panorama independiente es más útil. Una tabla de clasificación comunitaria abierta para esta clase de modelo, el Jev Decision Index, ha estado evaluando pplx-decider-v1.1-27b en su propio panel y su publicación de datos del 2026-10-14 informa que el checkpoint completa 110.179 de 110.201 casos puntuados en 42 benchmarks en una sola RTX PRO 6000. En esa tabla, el modelo alcanza una puntuación de habilidad equilibrada de 62,75 y un puesto de sexto, con Jev duodécimo en 60,11. Dos cosas que la tabla del proveedor no muestra se desprenden de los mismos datos:

• Dónde destaca. ARC-Easy 99.3, ARC-Challenge 97.0, decisiones sí/no de llamada a función (BFCL) 97.2, FinEntity 95.4, BPoMP 95.2, CLINC150 91.5. Las tareas clásicas de clasificación y recuperación son donde este checkpoint demuestra su valía.

• Donde no lo es.Humanity's Last Exam 16.2, ChessBench 17.7, SATA-Bench 28.2, ACOS 28.2, el conjunto de diálogos guiados por esquemas 33.2, BRIGHT 50.9, GPQA Diamond 56.1. El razonamiento difícil de varios pasos no es lo que te aporta una lectura de una sola pasada, y una pila que enruta silenciosamente el trabajo de razonamiento a un modelo de decisión producirá ramas incorrectas con confianza.

La calibración merece su propia línea, porque es el punto central de un modelo que devuelve probabilidades en lugar de etiquetas. En 34.829 decisiones puntuadas de forma independiente, el checkpoint promedió un 76,1 por ciento de precisión frente a un 82,9 por ciento de confianza media —un error de calibración esperado de 0,071 y una puntuación de Brier de 0,335, con un 2,0 por ciento de los casos situados por encima de 0,95 de confianza y aun así incorrectos. Esa es una superficie de probabilidad utilizable pero no impecable, y está mediblemente mejor calibrada que el ECE de 0,074 de Jev en el mismo tablero. Si estás estableciendo un umbral de 0,9 y tratándolo como casi certeza, ese 2 por ciento es el número en torno al cual diseñar.

La latencia en el mismo hardware se situó en una mediana de 104 ms y un p95 de 835 ms en 110.000 decisiones, lo que constituye el argumento práctico a favor de un modelo de decisión frente a un modelo de lenguaje pequeño en una posición de filtrado: el p95 es el presupuesto, no la media.

Lo que cuesta una decisión

Perplexity ejecuta su propia API Decisions alojada para estos checkpoints — POST https://api.perplexity.ai/v1/decisions, con pplx-decider-v1.1-27b como ID de modelo predeterminado y el checkpoint anterior aún accesible. Esa página de precios indica $0.02 por millón de tokens de entrada, tokens de salida gratuitos y sin cargo por solicitud, con un límite de 128 preguntas por solicitud, 262,144 tokens de entrada y 10 solicitudes por segundo por organización.

Frente a eso, la ruta local no cuesta nada por decisión una vez que los 17 GB han llegado. Para una cola de triaje que ejecuta un puñado de preguntas tipadas por ticket, esa aritmética se decide por sí sola, y vale la pena notar que el techo de 262.144 tokens de entrada de la versión alojada no es el límite que impondrá tu copia local, porque el presupuesto del propio checkpoint es de 8.192.

Donde la ruta local no es la respuesta es en el resto del stack en torno a la decisión. Este es un modelo de 27B que devuelve una probabilidad por opción; no redactará la respuesta, ni resumirá el ticket ni llamará a la herramienta. Si quieres la decisión y la redacción detrás de una sola clave, para eso está OrcaRouter: una API que abarca más de 200 modelos con el precio de lista del proveedor repercutido sin margen por token, además del DSL de enrutamiento cuando quieres que un modelo de decisión y un modelo de redacción se compongan en una sola llamada. Dos piezas de esta historia en particular ya están en la plataforma: el checkpoint base se sirve como Qwen3.8-27B, así que puedes comparar el ajuste fino con su propia base usando la misma clave, y el modelo de referencia con el que se mide se sirve como Jev 1.13 a través de la misma forma de endpoint systemone. El decisor de Perplexity no es uno que ofrezcamos — está disponible a través de la propia API de Perplexity y varias plataformas de terceros —, así que si lo necesitas específicamente, la descarga local de arriba y el endpoint de Perplexity son tus rutas.

Tres preguntas que el repositorio no responde

¿Qué checkpoint hay en el artefacto cuantizado? La entrada de la biblioteca de Ollama lleva el nombre de la familia, no de una versión, y su bloque de benchmarks enlaza con el v1 repositorio — la tabla de 11 benchmarks marca 85,7 por ciento, que es la cifra global de la ficha de v1 y no la suite Decision Index de v1.1. v1.1 es el checkpoint más fuerte según los propios cálculos de Perplexity, y no es obviamente el que estás descargando. Comprueba el digest antes de basarte en esa suposición.

¿Tenía Perplexity la intención de que algo de esto fuera público? No ha aparecido ningún anuncio, publicación de blog, entrada de registro de cambios ni aviso de disponibilidad de API para estos pesos. Los checkpoints han sido leídos por miles —2740 descargas en la v1 y 3154 en la v1.1 en el momento de escribir esto—, pero la atención en una tarjeta de modelo no es lo mismo que un proveedor que diga que le da soporte. Considera el repositorio público como el artefacto autoritativo y todo lo demás como inferencia.

¿Habrá una versión alojada por el proveedor y anunciada oficialmente? Se desconoce. La existencia de una Decisions API documentada y con precio por parte de Perplexity sugiere que la vía alojada es el producto previsto y que los pesos son anteriores a esta. Pero eso es una conjetura sobre la intención, no un hecho extraído de un documento, y así se etiqueta.

Quién debería moverse, y quién no

Si tu pipeline ya se ramifica según decisiones tipadas del proveedor —enrutamiento de tickets, detección de reembolsos, habilitación condicional de pasos del agente—, esto es un checkpoint de hace dos semanas con puntuaciones reproducidas de forma independiente, una licencia Apache 2.0 y, a partir de hoy, una ruta de 17 GB hacia hardware que posees. La evaluación sugiere que está mejor calibrado que el modelo de referencia y aproximadamente dos puestos mejor en una tabla de clasificación pública, y la copia local elimina por completo el coste por decisión. Descárgalo, ejecútalo contra tus propios ejemplos etiquetados y compáralo con lo que uses ahora. El presupuesto de decisión de 8.192 tokens es la restricción que hay que probar primero, no los 256K que anuncia la ficha.

Si necesitas razonamiento en lugar de clasificación, espera. El panel independiente sitúa este checkpoint en los trece o catorce puntos en benchmarks de conocimiento difíciles, y una superficie de probabilidad que se muestra segura sobre una pregunta que en realidad no puede responder es peor en producción que un modelo lento que piensa primero. El argumento a favor de un modelo de decisión es la mediana de 104 ms y el hecho de que sesenta preguntas cuesten una sola pasada, y nada de eso ayuda cuando las respuestas son incorrectas.

Ejecutar el paso de decisión en tu propio hardware también es un buen momento para examinar lo que ya ha salido mal en esta clase: los incidentes de IA documentados y los fallos de agentes relacionados con modelos de decisión se recopilan en the OrcaRouter AI Incident Archive, donde cada entrada incluye sus propias fuentes, gravedad, grado de confianza e indicador de disputa.