Nace.AI publica Drex 1.5 como pesos abiertos: un modelo de decisión de 9B puntúa opciones en una sola pasada y alcanza 93,4% en documentos largos de 128K
Según MarkTechPost, el 9 de octubre de 2026, Nace.AI publicó como pesos abiertos Drex 1.5, un modelo de decisión dense de 8,95B que, tras recibir un estado y una pregunta tipada, devuelve probabilidades para las opciones y no genera texto. El reporte indica que obtuvo 58,08 en Decision Index 0.3.1 y que puede ejecutarse localmente en una sola GPU en bf16 o con una versión cuantizada de unos 9,5 GB.
Qué ha cambiado
Según MarkTechPost, el 9 de octubre de 2026, Nace.AI publicó como pesos abiertos Drex 1.5, un modelo de decisión dense de 8,95B orientado a agentes y flujos de trabajo de backend. El modelo no genera texto: el usuario envía un estado (texto o JSON) y una pregunta con nombre, y el modelo devuelve probabilidades para cada opción en una sola pasada de inferencia; admite tres tipos de pregunta: choice, noul (sí/no) y ordinal score. Como no muestrea tokens, temperature y top_p no aplican. La fuente afirma que su tronco es MiMo-V2.6-Distill-Qwen-9B, con 32 capas y atención híbrida (cada capa de atención completa acompañada de 3 capas de atención lineal), más una cabeza de puntero independiente head.pt que puntúa los estados ocultos. La interfaz es POST /v1/systemone, con el mismo formato de solicitud que el modelo cerrado Jev de TypeSafe; la fuente señala que los clientes de Jev existentes pueden migrar cambiando unas pocas variables de entorno. El contexto es de 16384 tokens por defecto y hasta 131072; los pesos ya están publicados en Hugging Face, la versión alojada está disponible en OpenRouter y se afirma que DeepInfra aporta la capacidad de cómputo.
Impacto para desarrolladores
El cambio más directo para los desarrolladores es que las tareas de decisión pasan de “pedir a un modelo de chat que emita texto estructurado y luego analizarlo” a “obtener probabilidades de opciones en una sola pasada”, lo que elimina lógica de análisis y reintentos y hace más predecible la latencia de decisión. Según el reporte, los documentos largos son el punto fuerte de Drex 1.5: entre 32K y 128K tokens alcanza 93,4% de exactitud con una latencia mediana de 2,0 segundos; al truncar el mismo lote de solicitudes a 8K tokens, la exactitud baja a 76,5% y 78%, lo que indica una diferencia clara entre el desempeño en decisiones de contexto largo y de contexto corto, algo que importa mucho en flujos de arbitraje tras RAG o de ordenación de múltiples candidatos. Por otro lado, el reporte señala que es una capa de decisión y no un modelo general: no genera texto, código ni explicaciones; las tareas intensivas en conocimiento son su punto débil, con GPQA Diamond 45,4% frente a 78,6% de Jev, y MMLU-Pro 58,7% frente a 82,7% de Jev; en ACOS, el F1 de análisis de sentimiento por comentario es de solo 7,4%, frente a 29,5% de Jev. El entrenamiento usó el conjunto oficial de entrenamiento de la referencia de índices, lo que le da ventaja en tipos de decisión comunes, pero la fuente también advierte que los resultados en dominios nuevos podrían diferir. En el plano del despliegue, la vía local requiere las bifurcaciones de llama.cpp y Ollama de Nace, no compilaciones de la línea principal upstream; los pesos usan licencia Open RAIL-M y la fuente advierte explícitamente que se confirmen los términos antes de un uso comercial: aquí es donde “pesos abiertos” y “licencia de código abierto” deben considerarse por separado, pues la disponibilidad de los pesos no equivale a una licencia permisiva.
Integración y evaluación
Lo siguiente son recomendaciones y análisis condicionales basados en lo reportado por la fuente, no hechos verificados. Primera decisión: si conviene migrar los puntos de llamada de Jev existentes a Drex 1.5. El reporte afirma que ambos tienen el mismo formato de solicitud y que el costo del cambio está sobre todo en variables de entorno; por ello, cuando la carga de trabajo se centra en puntuar opciones, decidir sí/no y ordenar de forma ordinal, y el equipo quiere sacar el tráfico de decisión de una API cerrada, es más prudente empezar con una comparación de tráfico en sombra; un criterio de aceptación medible es enviar el mismo lote de solicitudes históricas a las dos rutas a la vez y calcular la tasa de coincidencia de opciones y la proporción de casos en que la probabilidad de la opción más alta queda por debajo de un umbral; si la coincidencia es alta y la proporción de muestras de baja confianza no sube de forma clara, se puede ir aumentando el volumen; si la carga incluye generación de explicaciones o si las respuestas necesitan un proceso de razonamiento visible, no conviene migrar, porque según el reporte el modelo no genera texto. Segunda decisión: si en escenarios de documentos largos conviene usar directamente el tramo de 128K en lugar de truncar primero. El reporte muestra 93,4% de exactitud y 2,0 segundos de latencia mediana en el tramo de 32K a 128K, mientras que al truncar a 8K la exactitud cae a 76,5% y 78%; por tanto, cuando la entrada es realmente un documento largo y el presupuesto de latencia admite un costo de segundos, conservar el contexto largo puede ser la opción más rentable; en la evaluación conviene medir exactitud y latencia P95 por tramos de longitud (menos de 8K, de 8K a 32K, de 32K a 128K) y, si la latencia del tramo largo excede el presupuesto, considerar el truncado, aceptando la caída de exactitud. Tercera decisión de despliegue: ejecutar en local o usar el servicio alojado. El reporte afirma que bf16 ocupa unos 18 GB y puede ejecutarse en una sola A10G de 24 GB, que el Q8_0 GGUF ocupa unos 9,5 GB y puede correr en chips Apple y CPU, y la fuente dice que ambas rutas cuantizadas dan respuestas consistentes; por ello, cuando los datos no pueden salir de la red interna o se necesita inferencia sin conexión, el despliegue local es viable, siempre que se acepte usar compilaciones de la bifurcación de Nace y las condiciones de Open RAIL-M. Los criterios de evaluación son comparar la consistencia de respuestas entre local y alojado en el mismo conjunto de evaluación, y si el rendimiento por GPU satisface la demanda de solicitudes por segundo. Los precios cambian; para el costo del servicio alojado, consúltense las páginas de precios actuales de OpenRouter y Nace Console.
Límites y cuestiones pendientes
Cabe aclarar que Drex 1.5 no aparece actualmente entre los modelos de KimiSeek, y la disponibilidad de API mencionada en el reporte apunta al servicio alojado del propio proveedor, sin relación con el catálogo de este sitio. Las puntuaciones de referencia de la fuente (58,08 en Decision Index 0.3.1, 86,2% en JevBench, 122 victorias, 47 empates y 87 derrotas en OpenSpiel, 93,4% en documentos largos, etc.) son resultados reportados por Nace o por quien elabora la tabla, en su mayoría ejecutados por el propio fabricante con el conjunto oficial de evaluación, y este sitio no los ha reproducido de forma independiente. El reporte también señala que el entrenamiento del modelo usó el conjunto oficial de entrenamiento de la referencia de índices, por lo que el desempeño en nuevos dominios de decisión podría diferir de las puntuaciones de la tabla; las debilidades en análisis de sentimiento ACOS y en pruebas de conocimiento ya se indican en el reporte. Además, las rutas de Ollama y llama.cpp dependen de versiones bifurcadas de Nace, y es posible que la línea principal upstream no las soporte de forma sincronizada; aunque los pesos son abiertos, la licencia es RAIL-M con restricciones de uso, y el uso comercial exige verificar los términos por cuenta propia. La recompensa de registro de 25 dólares y los precios del servicio alojado mencionados en el reporte corresponden al momento del lanzamiento, pueden haber cambiado, y conviene consultar las páginas de precios actuales.