pplx-decider-flash: el silencioso juez de 4B de Perplexity, leído desde el repositorio

Perplexity subió pplx-decider-flash-v1.2 a Hugging Face a las 16:57 UTC del 15 de octubre de 2026, aproximadamente nueve horas después de que subiera pplx-decider-v1.2, el gran modelo de decisión que el marketing llama 27B y la ficha del modelo llama 26B. No pudimos encontrar ninguna publicación de lanzamiento en el blog de la empresa. Lo que siguió fue un hilo de la cuenta de desarrollador en X, una sección en la documentación de la API de Decisions y una conversión a GGUF tres días después. Ese es todo el registro público, y basta para describir el modelo con precisión, pero no para decirte si es bueno con tus datos.

Lo que sigue separa las tres cosas que la gente suele confundir: lo que el repositorio demuestra, lo que afirma la documentación del proveedor y lo que nadie fuera de Perplexity ha verificado. La última categoría es más grande que las dos primeras.

¿Qué se lanzó realmente y en qué día?

La cronología del repositorio no deja lugar a dudas. Perplexity creó pplx-decider-v1-27b el 1 de octubre de 2026, pplx-decider-v1.1-27b el 5 de octubre, ambos checkpoints de la v1.2 el 15 de octubre, y pplx-decider-flash-gguf-v1.2 el 18 de octubre. El checkpoint Flash fue la segunda subida de ese día, que es la forma habitual de un lanzamiento emparejado: primero el modelo insignia, y detrás el hermano pequeño destilado, de modo que ambos queden bajo el mismo anuncio.

Ese orden importa para el encuadre. No es un modelo filtrado ni un repositorio suelto que se adelantara a su documentación. Es un lanzamiento coordinado con una huella pública deliberadamente ligera: un hilo para desarrolladores en lugar de un ensayo de lanzamiento, documentación en lugar de un centro de benchmarks. La API de Hugging Face informa 4.667 descargas en el checkpoint base y 9.428 en la conversión GGUF a 4 de noviembre, y 63 me gusta. Los recuentos de descargas en Hugging Face son una señal débil: cuentan solicitudes, no usuarios distintos, y el tráfico de los espejos los infla. Son coherentes con una audiencia de pesos abiertos real pero modesta, no con un lanzamiento viral.

Lo que el repositorio te dice

La ficha del modelo es inusualmente técnica para ser una publicación de un proveedor, y la mayor parte de lo que se puede saber proviene de ella.

• Red troncal — Qwen3.5-4B, con una cabeza de lectura BF16 separada de forma [255, 2560] en lugar de una cabeza de modelo de lenguaje de vocabulario completo. Este es un checkpoint de decisión, no un modelo de chat con un envoltorio de clasificación.

• Tamaño — 25 archivos que suman aproximadamente 9 GiB en BF16, que es lo que necesitas para mantener los pesos; la memoria de trabajo se suma a eso.

• Número de parámetros — la documentación de la API dice 4B, el encabezado de la ficha del modelo dice 5B en BF16, y un índice de terceros enumera 4.5B. El backbone es un modelo de 4B. Considera "clase 4B" como la descripción honesta y no cites una única cifra como si se hubiera medido.

• Atención — las capas de atención completa se ejecutan de forma no causal sobre toda la solicitud, mientras que las capas de atención lineal siguen siendo causales. Este es el detalle que te va a morder: una pila de servicio causal estándar producirá números distintos, y los prompts escritos para v1.1 no se conservan.

• Posición de lectura — la cabeza se activa en cada marcador <|fim_suffix|> en lugar de en el token final, y así es como una sola pasada hacia adelante puede puntuar varias preguntas contra un mismo estado.

• Contexto — max_length tiene un valor predeterminado de 262.144 tokens, coincidiendo con el backbone. El entrenamiento utilizó secuencias de hasta aproximadamente 32.000 tokens, y la ficha indica explícitamente que se admiten entradas más largas, aunque están menos validadas.

• Imágenes — limitadas a 1,6 megapíxeles (1.638.400 píxeles), mínimo 65.536 píxeles, y una imagen de 1,6 MP consume aproximadamente 1.600 posiciones.

• Calibración — una temperatura guardada de 1,554. En un conjunto de desarrollo de 1.497 preguntas, la ficha informa una exactitud del 88,8 %, un error de calibración esperado de 0,021 y una puntuación de Brier de 0,163; sin la temperatura, el error asciende a 0,057. Un proveedor que publica sus propias cifras de calibración y el coste de omitirlas te está diciendo algo real sobre el uso previsto.

Una línea de la tarjeta no sobrevive al contacto con la API. Dice que el repositorio es privado y necesita un token con acceso. La API de Hugging Face devuelve gated: false y private: false, y los pesos se descargan sin solicitud de acceso. Una línea desactualizada en una tarjeta es un detalle menor, pero es el tipo de detalle menor que te indica que la tarjeta se escribió antes de publicarse y no se volvió a leer después.

Lo que añade la documentación de la API

El precio es donde comienza el argumento de Flash. En la Decisions API, pplx-decider-flash-v1.2 cuesta $0.01 por millón de tokens de entrada. Los tokens de salida son gratuitos y no hay tarifa por solicitud, porque no hay tokens de salida en el sentido habitual — el modelo devuelve probabilidades y una puntuación esperada, y la documentación cuenta cada pregunta como un token de salida para la contabilidad.

La misma página establece la envolvente operativa:

• Alias — pplx-decider-flash-latest sigue la versión más reciente, así que un umbral que ajustaste la semana pasada puede apuntar silenciosamente a un modelo diferente tras una actualización. Fija el id versionado en todo lo que sea importante.

• Límites de velocidad — 4.000.000 de tokens por minuto y 240.000.000 por hora, con un límite máximo de 10 solicitudes por segundo compartido entre ambos modelos de decisión a nivel de organización.

• Tipos de pregunta — noul devuelve P(sí) de 0 a 1, choice devuelve probabilidades entre hasta 255 opciones, y score devuelve una distribución sobre los niveles de la rúbrica.

• Presupuesto de preguntas — la documentación recomienda una pregunta por solicitud. No es una nota de estilo; es la diferencia entre el precio que le cotizaron y el precio que paga.

La regla de facturación que invierte la recomendación

El modelo 27B responde cada pregunta de una solicitud en una sola pasada agrupada y factura el estado una sola vez. Flash responde cada pregunta de forma independiente, sin ver las demás, y vuelve a facturar el estado por cada pregunta. La documentación proporciona el ejemplo resuelto: tres preguntas contra un estado de 10.000 tokens cuestan unos 30.000 tokens de entrada en Flash.

Hagamos los cálculos. Una pregunta sobre un estado de 10.000 tokens cuesta $0,0001 en Flash y $0,0002 en el 27B. Dos preguntas cuestan $0,0002 en Flash y $0,0002 en el modelo más grande: un empate. Tres preguntas cuestan $0,0003 en Flash y $0,0002 en el 27B. El punto de cruce está en dos preguntas por estado. La propia documentación de Perplexity dice que el modelo más grande «normalmente cuesta menos que Flash» con tres o más preguntas; el punto preciso es una pregunta antes, y se cumple con cualquier precio de lista en el que Flash sea exactamente la mitad de la tarifa del 27B.

Esta es la cosa más útil del lanzamiento, y es fácil pasarla por alto porque el titular es un descuento del 50 %. Un modelo de 4B a mitad de precio solo es más barato mientras le preguntas una cosa a la vez.

El número del que desconfiar

Perplexity informa puntuaciones de Decision Index 0.3 para ambos modelos. Flash obtiene 60.05 con una pregunta por solicitud y 58.88 con solicitudes conjuntas; el 27B obtiene 68.09 en conjuntas y 67.75 una por solicitud. En el Vision Decision Index, Flash obtiene 72.53 frente a 77.43.

El desglose por categoría es más informativo que el titular, porque muestra dónde el 4B cede terreno. En cuanto a las cifras de ejecución conjunta de Flash frente a las cifras de ejecución conjunta del 27B:

• Conocimiento — 42,0 vs 56,3. Esta es la brecha más amplia, de 14,3 puntos, y la que decide si el modelo puede manejar conocimiento general del mundo de forma abierta.

• Idioma — 63,3 vs 72,8.

• Recuperación — 64,8 frente a 68,4. La brecha más estrecha, de 3,6 puntos, que encaja con la tarea prevista: juzgar si un pasaje responde a una pregunta es una tarea más ligera que conocer la respuesta.

• Herramientas — 76,7 vs 84,4.

• Artes — 46,8 vs 56,2.

• General — 58,88 vs 68,09.

Cada una de esas cifras proviene de un benchmark que Perplexity mantiene. La ficha del 27B —el maestro en esta destilación— es inusualmente franca sobre el lado del entrenamiento: parte del trabajo, dice, llevó al modelo “en el dominio” para algunas tareas de Decision Index al incluir los splits de entrenamiento oficiales que varios benchmarks distribuyen, con los splits “descontaminados frente a los conjuntos de prueba” para que la comparación siga siendo justa. Esa es una postura más cuidadosa de lo que implicaba la cobertura en torno al lanzamiento, y aun así deja el marcador en manos del proveedor. Ningún tercero ha auditado la disciplina de los splits, y nadie ha reproducido las cifras.

Hay una rareza menor dentro de las propias cifras del proveedor que va en contra del marketing. Flash puntúa más alto cuando responde una pregunta a la vez: 60,05 frente a 58,88. Agrupar perjudica al 4B en general, aunque ayuda en tareas estrechamente acopladas de tipo «selecciona todas las que correspondan», que es exactamente lo que dice la documentación. El modelo se vende por la velocidad de las solicitudes conjuntas y se mide mejor sin ellas.

Lo que todavía no se puede saber

Las lagunas son concretas, y por eso esto es un artículo sobre lo que sabemos y no una reseña.

• Sin benchmark independiente. Nada fuera de Perplexity ha publicado reproducciones del Decision Index ni una comparación directa en un entorno de pruebas neutral.

• Sin nivel de servicio de latencia. La única cifra de velocidad que publica el proveedor es una prueba de documentación fechada el 19 de octubre en la que aproximadamente 248.000 tokens de entrada tardaron 16 segundos en Flash frente a 53 segundos en el 27B. Se trata de una medición del lado del proveedor que no especifica el hardware ni el percentil.

• Sin evaluación multilingüe. La tarjeta y la documentación describen texto e imágenes; ninguna de las dos informa sobre la precisión fuera del inglés.

• No se ha publicado el volumen de datos de entrenamiento. La ficha indica que Flash se destiló a partir del modelo de 27B usando las solicitudes de entrenamiento del modelo más grande, y que el estudiante aprendió las distribuciones de probabilidad completas del profesor en lugar de solo sus respuestas, además de que varias ejecuciones se combinaron mediante un promedio ponderado de los pesos. No dice cuántos datos involucró eso, de dónde provinieron ni dónde se sitúa el corte.

• No hay ningún análisis de errores publicado. Para un modelo cuya salida es una probabilidad a la que aplicarás un umbral, no hay un desglose de dónde falla —por tipo de pregunta, por cantidad de opciones, por idioma o por contenido de imagen.

Dónde encaja un modelo como este dentro de una pila tecnológica

Vale la pena dejar claro para qué sirve Flash, porque el nombre invita a una expectativa equivocada. No escribe nada. Le entregas un estado —texto, JSON, imágenes— y una o más preguntas tipadas, y te devuelve una probabilidad o una distribución sobre la que tu código aplica un umbral. La arquitectura natural es una puerta barata delante de algo caro: clasificar la solicitud, decidir si recuperar, elegir una herramienta y luego generar.

Esa compuerta no sustituye la capa de generación, y aquí es donde importa el enrutamiento. OrcaRouter expone más de 200 modelos de generación detrás de una única clave de API sin recargo sobre los precios de lista de los proveedores, de modo que una reducción de precio de cualquier proveedor upstream se aplica el mismo día en lugar de esperar la hoja de cálculo de un revendedor. Si la compuerta clasifica mal, la conmutación por error automática evita que la solicitud muera en el siguiente salto. Lo que no hacemos es alojar pplx-decider-flash: no está en nuestro catálogo, y la forma honesta de ejecutarlo hoy es usar la propia API del proveedor o los pesos Apache-2.0 en tu propia GPU.

Los cálculos del autoalojamiento son razonables si ya se dispone del hardware. Unos 9 GiB de pesos en BF16 caben en una tarjeta de consumo de 16 GB, y la cobertura del lanzamiento repitió una afirmación del director ejecutivo de Perplexity de que Flash funciona en un Mac M4 con 16 GB de memoria. No hay cifras de rendimiento publicadas que lo respalden, y la atención no causal implica que no basta con integrarlo en un servidor de inferencia causal estándar y esperar obtener las puntuaciones de esa tarjeta.

¿Qué cambiaría esta evaluación?

Cuatro cosas, en orden de utilidad. Una reproducción neutral del Decision Index 0.3 que confirme el 60.05 o explique la brecha. Una distribución de latencia publicada por la API en lugar de una única prueba de documentación. Evidencia sobre entradas multilingües, ya que un clasificador de 4B es justo el tipo de modelo que los equipos aplicarán al tráfico no inglés sin comprobarlo. Y un artículo técnico de primera fuente que describa los datos de entrenamiento detrás de esa destilación.

Hasta entonces, la postura defendible es limitada y útil: pplx-decider-flash-v1.2 es un modelo de decisión real, descargable, Apache-2.0 y de clase 4B, con un precio publicado, una temperatura de calibración documentada y una regla de facturación que lo hace más caro que su hermano mayor en el momento en que agrupas preguntas por lotes. Todo lo que va más allá es el propio marcador de Perplexity, y deberías tratarlo como una hipótesis que poner a prueba con tus datos etiquetados, en lugar de como un resultado.