vLLM Semantic Router lanza d3-ultra: un modelo decisor multimodal de 27B que responde todas las preguntas en una sola lectura
Según MarkTechPost, el 26 de octubre de 2026, el equipo de vLLM Semantic Router publicó d3-ultra, un modelo decisor multimodal de 27B bajo licencia Apache-2.0 que no genera texto: en una sola lectura de la entrada devuelve probabilidades para cada pregunta, abarcando enrutamiento, clasificación, selección de cajas visuales e inspección de vídeo.
Qué ha cambiado
Según MarkTechPost, el 26 de octubre de 2026, el equipo de vLLM Semantic Router publicó d3-ultra, un modelo decisor multimodal denso de 26.09B parámetros (con un codificador visual de 0.46B), cuyos pesos se abren bajo licencia Apache-2.0 y que pertenece a su familia Decision 3.0 (de 0.6B a 27B). A diferencia de los modelos generativos, d3-ultra no emite texto: quien lo invoca envía un estado (texto o JSON, más imagen o vídeo) y un conjunto de preguntas tipadas —Choice, Yes/No, Score, Box, Track—; el modelo lee la entrada una sola vez y devuelve probabilidades para cada respuesta candidata de cada pregunta. Según el reportaje, la configuración muestra que su backbone es la arquitectura Qwen3.5, con 64 capas (48 de atención lineal más 16 de atención completa); la tarjeta del modelo no nombra el checkpoint base, mientras que la receta de vLLM afirma que d3, de la misma familia, se entrenó sobre Qwen3.8-27B, por lo que el origen del propio d3-ultra sigue sin estar claro. Cada pregunta tiene un contexto de 131.072 tokens, y las solicitudes demasiado largas fallan directamente con max_length_exceeded en lugar de truncarse en silencio; el tipo Box devuelve siempre una caja y una confianza, y una confianza cercana a 0 se interpreta como ausencia del objetivo. Las vías de despliegue mencionadas incluyen Transformers (requiere transformers==5.17.0) con kernel opcional flash-linear-attention, el comando vllm-sr serve incorporado mediante el PR #5449 el 25 de octubre de 2026, una interfaz gestionada que, según la tarjeta del modelo, ofrece una key gratuita, y una demo oficial en Hugging Face Space. En cuanto al rendimiento, el equipo lo comparó con GLiDE V1.2, d1-ultra, d3-turbo, d3 y Jev 1.14 sobre dos conjuntos de prueba privados propios: SR-Text, con 10.411 solicitudes y 73.495 preguntas (exactitud corregida por oportunidad), situó a d3-ultra en cabeza con 87,2, por encima del 85,1 de GLiDE V1.2 y del 83,1 de d3-turbo de la misma familia; solo en el ámbito de «arte y gusto humano» d3-ultra obtuvo 89,6 frente al 90,8 de d1-ultra, y el reportaje señala que esa diferencia está dentro del margen de error. SR-Box abarca 5.678 preguntas de selección de cajas sobre 4.984 imágenes, con IoU 0,5 como criterio de acierto; d3-ultra logró 58,2% en 10 ámbitos y 54,6% en 9 ámbitos, por debajo del 60,0% y 59,6% de d3-turbo, y el equipo afirma que d3-turbo es más fuerte en imágenes naturales mientras que d3-ultra lidera en gráficos. En latencia, el reportaje indica que, probado en una sola AMD Instinct MI325X con AutoModel y pesos BF16, una sola foto con una pregunta tardó 304 ms y con 255 preguntas 2,16 s, es decir, unos 7,3 ms por pregunta adicional de media; aún no hay versiones cuantizadas oficiales. Todas las cifras de benchmark son resultados autodeclarados por el equipo en conjuntos privados, y el índice público muestra «enviado, aún no listado».
Impacto para desarrolladores
La forma de este modelo influye más en cómo se integra que en una capacidad concreta. Las interfaces generativas habituales cobran por token de salida y dimensionan la capacidad por concurrencia, mientras que la estructura de coste y latencia de d3-ultra es «una pasada hacia delante por entrada, con un incremento más plano cuanto más preguntas hay»: los 7,3 ms por pregunta mencionados indican que, al agrupar varios juicios en una misma llamada, el coste principal se concentra en esa única lectura. Para los equipos que ya usan un enrutador semántico para derivar solicitudes, esto ofrece una vía alternativa: pasar de pedir a un LLM genérico que emita JSON y luego analizarlo a obtener probabilidades sobre preguntas tipadas y controladas para decisiones como «qué modelo debe atender esta solicitud», «a qué cola pertenece este ticket» o «este contenido infringe normas»; la salida es de forma natural un valor de probabilidad estructurado, con una capa menos de riesgo de fallo de análisis. El precio es la flexibilidad: el modelo no genera libremente, los tipos de pregunta y las opciones deben diseñarse de antemano, y las tareas fuera de esos tipos no pueden resolverse con él. En cuanto a la licencia conviene distinguir: el reportaje afirma que los pesos se abren bajo Apache-2.0, lo que es una condición de licencia y no solo la posibilidad de descargar los pesos; en principio favorece el uso comercial y la redistribución, pero en la práctica debe verificarse la tarjeta del modelo y el archivo de licencia del repositorio, y no debe inferirse ningún derecho de licencia a partir de que «los pesos sean descargables». En el despliegue, 26.09B parámetros densos en BF16 exigen una cantidad notable de memoria de vídeo; la prueba reportada se hizo solo en una AMD MI325X y no hay versiones cuantizadas oficiales, por lo que los equipos que quieran autohospedarlo en dispositivos con menos memoria carecen por ahora de una vía oficial. Los datos de las dos capacidades clave apuntan en direcciones opuestas —lidera con claridad los juicios textuales dentro de su familia, pero queda por detrás de d3-turbo en selección de cajas visuales—, lo que indica que la elección no puede hacerse con el criterio único de «más grande y más nuevo es mejor», sino según la carga de trabajo. El origen del backbone sigue siendo un hueco informativo: la configuración muestra la arquitectura Qwen3.5, la receta solo indica que d3, de la misma familia, se basa en Qwen3.8-27B, y la tarjeta del modelo no nombra el checkpoint base de d3-ultra, lo que afecta a las decisiones sobre procedencia de los datos de entrenamiento, herencia de licencia y margen para ajustes posteriores. Todos los benchmarks son autodeclarados por el equipo en conjuntos privados y el índice público aún no lo lista, por lo que, hasta que haya replicación de terceros, el 87,2 y el 58,2% deben tratarse como cifras del fabricante.
Integración y evaluación
Lo siguiente es análisis condicional y recomendaciones basadas en el reportaje, no hechos verificados. Primero, si el equipo usa un LLM generativo para enrutar o clasificar solicitudes, conviene empezar con una «comparación sobre la misma entrada»: tomar un lote de solicitudes reales de los registros de enrutamiento actuales, ejecutarlas con el esquema de prompts actual y con el formato de preguntas Choice o Yes/No de d3-ultra, y comparar exactitud y latencia de extremo a extremo tomando como referencia el mismo conjunto de respuestas anotadas manualmente. La condición para que tenga sentido es que las categorías de decisión sean limitadas y enumerables y que la respuesta pueda formularse como opciones fijas; si los juicios suelen requerir explicación libre o razonamiento en varios pasos, la sustitución no es adecuada. Las métricas medibles son la exactitud sobre el mismo conjunto anotado y la latencia de extremo a extremo P95; solo debería considerarse el cambio si d3-ultra no es inferior al esquema actual y la latencia total es menor. Segundo, si la carga se centra en localización visual, no hay que adoptar d3-ultra por defecto solo porque lidere en SR-Text. El reportaje afirma que d3-turbo es más fuerte en selección de cajas sobre imágenes naturales y que d3-ultra lidera en gráficos, por lo que se recomienda estratificar según sus propios tipos de imagen (fotos naturales y gráficos por separado), medir la exactitud de ambos modelos con el criterio IoU 0,5 y contar aparte la proporción de falsos negativos en los que «la confianza devuelta es cercana a 0 pero el objetivo existe realmente», y luego decidir cuál usar según el peso de cada tipo de imagen; solo si los gráficos representan una proporción alta podría materializarse la ventaja de localización de d3-ultra. Tercero, antes de autohospedar conviene calcular memoria y rendimiento: estimar la memoria de vídeo necesaria para 26.09B densos en BF16 junto con el codificador visual y la caché KV, medir en el hardware objetivo si una sola solicitud que responde 255 preguntas se acerca al orden de 2,16 s reportado, y usar «304 ms por pregunta» como coste de la primera lectura para establecer una línea base de capacidad; si la memoria es insuficiente y sigue sin haber versión cuantizada oficial, esa vía debería marcarse como no viable por ahora, en lugar de cuantizar por cuenta propia y suponer que la calidad no cambia. Cuarto, al diseñar las preguntas hay que tratar el límite duro de 131.072 tokens como restricción: los documentos largos o los vídeos con muchos fotogramas deben dividirse en bloques, y conviene instrumentar por separado los errores max_length_exceeded para no contabilizar por error un fallo de solicitud como baja confianza. Quinto, la tarjeta del modelo menciona una interfaz gestionada con key gratuita, pero el reportaje no detalla cuotas, estabilidad ni condiciones sobre los datos, por lo que antes de usarla en producción deben verificarse por cuenta propia los términos del servicio.
Límites y cuestiones pendientes
Las exactitudes del reportaje son resultados autodeclarados por el equipo en conjuntos de prueba privados, sin replicación de terceros, y el índice público figura como «enviado, aún no listado». Los datos de latencia son de otra naturaleza: el reportaje indica que se midieron en una sola AMD Instinct MI325X con AutoModel y pesos BF16, no son un benchmark privado, se desconoce el comportamiento en otro hardware y pila de inferencia, y tampoco se publican latencias comparativas con otros modelos en el mismo hardware. El reportaje no aclara si la construcción de muestras de los dos conjuntos privados está sesgada hacia los tipos de tarea en los que esta familia destaca. Existe un hueco informativo sobre el origen del backbone: la configuración muestra la arquitectura Qwen3.5, la receta solo afirma que d3, de la misma familia, se basa en Qwen3.8-27B, y la tarjeta del modelo no nombra el checkpoint base de d3-ultra, por lo que la afirmación de un backbone de la familia Qwen no debe tomarse como hecho confirmado. Las pruebas de despliegue se limitan a una sola AMD Instinct MI325X y pesos BF16, y aún no hay versión cuantizada oficial. El reportaje no aborda las condiciones de la key gratuita de la interfaz gestionada, sus límites ni su disponibilidad, y este tipo de arreglos puede cambiar en cualquier momento. A fecha de esta comprobación del catálogo (27 de octubre de 2026), d3-ultra no aparece en el catálogo de modelos disponibles de KimiSeek; la disponibilidad de API descrita se refiere a la interfaz propia del fabricante y no guarda relación con este sitio; si al lector le interesan los modelos disponibles y la facturación, debe consultar la página de precios del sitio.