Decision 3.0 ya está en Hugging Face: seis modelos de decisión multimodales abiertos, anunciados solo en X

Decision 3.0 exists in a form you can download right now, and almost nobody has written it down. Six checkpoints — d3, d3-flash, d3-mini, d3-nano, d3-lite and d3-edge — landed in the vllm-sr organisation on Hugging Face on 10 October 2026, newest-first starting at 09:38 UTC and finishing with d3-edge at 23:49 UTC. They are Apache-2.0, they are built on Qwen3.5 and Qwen3.8 backbones, they answer choice, yes/no and score questions with a probability per option instead of generating a token, and five of the six now read images and video. Every model card describes itself as "the 27B multimodal foundation decision model of Decision 3.0, the decision models of vLLM Semantic Router," which is the vLLM project's open decision layer.

Lo que falta es el anuncio. La cuenta de X del proyecto vLLM felicitó al equipo de vLLM-SR por el lanzamiento el 11 de octubre, citando el propio hilo introductorio del mantenedor: ese es todo el registro público. El índice del blog del proyecto todavía termina el 10 de octubre con una entrada sobre modelos de decisión de enrutamiento, no sobre estos.vllm-project/semantic-router La página de versiones de GitHub sigue llegando como máximo hasta la v0.4.0 del 27 de septiembre. Los pesos ya se publicaron; la nota de lanzamiento, no.

Esa distinción importa para cómo interpretas todo lo que sigue. Cada cifra de rendimiento de este artículo proviene de las propias tarjetas de modelo de vLLM-SR, medidas con su propio banco de pruebas en su propio hardware. Nada de esto ha sido reproducido por una parte externa, y el tablero en el que publican es uno que ellos mismos mantienen. Esta es una lectura temprana y honesta de un artefacto que es real y de una afirmación que aún no ha sido auditada.

¿Qué hay realmente en Hugging Face?

Los seis repositorios son simples, completos y coherentes entre sí. Cada uno incluye pesos safetensors, una plantilla de chat, un decision_config.json que fija la revisión del modelo base, código de modelado personalizado (modeling_d3.py, d3_engine.py, d3_server.py), una cabeza de lectura en su propio readout.safetensors, y un MODEL_MANIFEST.json con un SHA-256 por archivo. Un séptimo repositorio, la página de la colección, enumera los seis.

La familia, en el orden en que aparecen las tallas:

• d3 — 26,09B de parámetros, incluido un codificador de visión de 0,46B, construido sobre Qwen/Qwen3.8-27B. Subido el 10 de octubre, 09:38 UTC.

• d3-flash — 8.39B, incluido un codificador de visión de 0.46B, construido sobre Qwen/Qwen3.5-9B.

• d3-mini — 4,54B, incluyendo un codificador de visión de 0,33B, construido sobre Qwen/Qwen3.5-4B.

• d3-nano — 2,21B, incluyendo un codificador de visión de 0,33B, construido sobre Qwen/Qwen3.5-2B.

• d3-lite — 0,85B, incluido un codificador de visión de 0,10B, construido sobre Qwen/Qwen3.5-0.8B.

• d3-edge — 0,59B, que incluye un codificador de visión de 0,10B, también construido sobre Qwen/Qwen3.5-0.8B. Subido en último lugar, 23:49 UTC.

Los seis comparten el mismo contrato de solicitud: un estado (texto o JSON, opcionalmente con imágenes y videos) más un diccionario de preguntas con nombre, y una respuesta de distribuciones de probabilidad tipadas. Existen tres tipos de preguntas — Choice, Noul (sí/no), Score — y el modelo responde a todas en una sola llamada ejecutando una pasada hacia adelante por pregunta sobre la misma entrada, sin ningún bucle de decodificación en ningún lugar.

Los números, y de quién son

vLLM-SR publica una tabla de clasificación que llama Jev Decision Index 0.3.1 y sitúa a d3 en lo más alto. Las filas destacadas, todas reportadas por el proveedor:

• d3 — Índice 64,7, conjunto público 65,5, pruebas de la misma habilidad 62,8, tareas de nuevo dominio 56,6.

• Perplexity Decider v1.1 (27B) — 62,8; 62,3; 61,1; 55,6.

• Fastino GLiDE sin razonamiento (28B) — 60.2, 59.1, 59.5, 52.9.

• Jev — 60,1, 58,0, 58,0, 55,0.

• Torchcast Decision 27B — 59.9, 65.1, 58.1, 50.8.

• Decision 2.0 (27B), la generación anterior: 55,9, 57,0, 55,7, 47,9.

Una nota al pie en la tarjeta de d3 declara sin ambages que la fila de d3 es una evaluación interna, mientras que las filas de comparación son datos en vivo de un tablero leídos el 10 de octubre. Esa es la divulgación correcta y vale la pena leerla dos veces: los números de los competidores se extrajeron de un tablero, y el número del sujeto lo produjo el equipo que construyó el modelo. La tarjeta también afirma que las 140.178 solicitudes públicas fueron respondidas y ninguna quedó sin respaldo — una afirmación de cobertura, no de precisión, y una inusual de publicar.

Los checkpoints más pequeños se reportan marchando al mismo paso. Cada tarjeta da una cifra de la suite pública y un delta frente al tamaño equivalente en Decision 2.0: d3-flash 57,79, 11,0 más que el 9B anterior; d3-mini 54,90, 10,7 más; d3-nano 42,22, 12,2 más; d3-lite 36,93, 16,4 más; d3-edge 28,82, 12,1 más. Las ganancias relativas son mayores en la parte baja del rango, que es lo que cabría esperar si la receta de preentrenamiento multimodal está haciendo más trabajo para los modelos pequeños que para los grandes, y también lo que producirías al ajustar con más intensidad los modelos pequeños. No hay forma de saber cuál de las dos cosas desde fuera.

La parte multimodal es el verdadero cambio

Los modelos de Decision 2.0 leen texto. Los de Decision 3.0 leen texto, imágenes y vídeo, y esa es la diferencia sustancial entre las generaciones, no el movimiento del índice. Cada tarjeta enumera la entrada de imágenes como PNG, JPEG o WebP, suministradas como rutas, URL, imágenes PIL o URL de datos base64, con varias por solicitud de hasta 1,6 megapíxeles cada una; y la entrada de vídeo como MP4, WebM, MOV o MKV, o como matrices de fotogramas, leída a 2 fotogramas por segundo con como máximo 32 fotogramas repartidos a lo largo de todo el clip y cada fotograma de hasta 0,2 megapíxeles. Cada pregunta en una solicitud ve cada imagen y cada vídeo adjuntos a ella.

La evidencia de respaldo para vídeo es un resultado de Perception Test en las 19.140 preguntas de validación: d3 con 77,4, d3-flash 73,3, d3-mini 70,3, d3-nano 63,5, d3-lite 59,3, d3-edge 46,6, frente a un suelo de azar documentado de 33,3 en preguntas con tres opciones. vLLM-SR lo califica como una evaluación interna. d3 también presenta un vision board que lo sitúa en 71,6 en general, por delante de Perplexity Decider v1.1 con 70,6 y de JEV-27B-VL con 69,6, con las filas de comparación, una vez más, tomadas de los datos del board y no ejecutadas por los autores.

Las cifras de rendimiento son de una sola solicitud y una sola GPU, y así se indican: d3 responde a una solicitud de texto en una mediana de 55 ms, a una solicitud que incluye una imagen en 273 ms, y a una solicitud que incluye un vídeo de diez segundos en 553 ms, en una AMD Instinct MI325X. d3-edge hace lo mismo en 6,7 ms, 41,9 ms y 308,3 ms. Esas son medianas por pregunta en un modelo diseñado para ser invocado muchas veces dentro de un flujo de trabajo, que es la cifra que importa para la arquitectura para la que están hechos estos modelos — veinte decisiones secuenciales con 100 ms adicionales cada una cuestan dos segundos, como Microsoft señaló este mes con el mismo argumento sobre su propio modelo de decisión.

Lo que los repositorios no dicen

Vale la pena nombrar tres brechas antes de que alguien planifique en torno a esto.

El primero es el presupuesto de entrada. decision_config.json para el modelo más grande establece max_length en null, y ninguna tarjeta indica un límite de tokens para el estado más las preguntas más las descripciones de las opciones. Las tarjetas de Decision 1.0 publicaron presupuestos explícitos —1,024 tokens para la rama del codificador, 16,384 para la rama del decodificador—, y esos números son una restricción de planificación real. Su ausencia aquí es llamativa, y es lo más útil que un commit de seguimiento podría añadir.

Lo segundo es la calibración. El número más importante de un modelo de decisión no es la precisión, sino si un 0.9 devuelto significa nueve de cada diez veces. Los índices de visión y texto no dicen nada al respecto. No hay puntuación de Brier, ni cifra de error de calibración esperado, ni temperatura en ninguna de las seis tarjetas. InternLM publicó ambos en su propio modelo de decisión en septiembre; vLLM-SR no lo ha hecho, para ningún miembro de esta familia.

El tercero es la independencia. Los modelos de Decision 2.0 han tenido dos semanas de uso externo; los de Decision 3.0, horas. Los recuentos de descargas del 11 de octubre —130 para d3, 83 para d3-lite, 82 para d3-nano— son la huella de una subida, no de una adopción. Trata cada cifra de índice anterior como una hipótesis con un repositorio adjunto.

Dónde encaja esto en un stack que puedes invocar hoy

La cuestión práctica respecto a un modelo de decisión es si encaja en un pipeline que ya existe, y aquí el ecosistema está más avanzado que los modelos. El formato de solicitud de System One que usan estos modelos no es propiedad exclusiva de vLLM-SR: es el mismo contrato de estado y preguntas con nombre con el que se invoca a los modelos Jev alojados, y por eso "Jev" aparece tanto como el nombre del índice en la ficha del modelo de d3 como en una fila de su tabla de clasificación.

OrcaRouter cubre ese lado de la familia. typesafe/jev-1.13 está en nuestro catálogo y se sirve mediante POST /v1/systemone — el mismo contrato, a $0.042 por millón de tokens de entrada, sin cargo por finalización porque no hay finalización, hasta aproximadamente 64K tokens de entrada, texto de entrada y JSON estructurado de salida, sin streaming. Es el tipo de modelo que una capa de decisión invoca hoy. Hay dos cosas que no afirmamos: d3 y el resto de Decision 3.0 no están en nuestro catálogo, y la ruta de inferencia local de Decision 3.0 es una clase de Python en un repositorio de Hugging Face, no un endpoint que pudiéramos enrutar aunque quisiéramos. Lo que un enrutador sí te aporta aquí está en el otro lado del bucle: el modelo generativo que actúa sobre una decisión, enrutado a través de una sola clave entre más de 200 modelos con conmutación automática por error cuando un proveedor falla, de modo que añadir un paso de puntuación delante de un flujo de trabajo no implique también añadir una segunda relación con proveedores.

¿Qué cambiaría esta imagen?

Cuatro cosas, en orden aproximado de cuánto te dirían. Una entrada de blog del proyecto que indique el presupuesto de entrada y la forma de despliegue prevista, lo que confirmaría que se trata de un lanzamiento y no de un simple push. Una puntuación de Brier o una cifra de ECE sobre cualquiera de los checkpoints. Que un tercero ejecute la suite pública sobre los pesos publicados, en lugar de limitarse a leer el índice. Y un runtime: el repositorio semantic-router recibió dos commits el 11 de octubre que integran d3 y d3-edge en su runtime de modelos, incluida la entrada de vídeo, lo que sugiere que la parte de servicio se está construyendo ahora y será lo que haga que probar estos modelos salga barato.

Hasta que al menos el primero de esos llegue, el resumen honesto es este: hay una familia completa de modelos de decisión, con licencia Apache-2.0, genuinamente multimodal, alojada en Hugging Face desde 0.6B hasta 27B, publicada con una procedencia inusualmente buena —hashes de archivos, revisiones base fijadas, un objetivo de hardware declarado— y con una cantidad inusualmente escasa de la documentación circundante que te permitiría decidir si usarla. Descargarla no cuesta nada. Creer que el índice debería esperar.