Liquid AI publicó el 7 de octubre de 2026 los pesos de dos modelos de decisión: d1-3B y d1-omni-600M. La novedad acerca este tipo de modelos al procesamiento local de imágenes y audio, aunque cada variante tiene capacidades distintas y la pequeña se presenta como experimental. El anuncio del equipo confirma que ambos están disponibles en Hugging Face.
Un modelo de decisión recibe información y responde a preguntas con opciones definidas: elegir un departamento, puntuar una prioridad o estimar una respuesta de sí o no. En esta familia las respuestas se calculan en una pasada del modelo, sin generar una explicación palabra por palabra. Para ampliar ese contexto tenemos la comparativa de Jev y alternativas de decisión.
Dos variantes, dos puntos de partida
La ficha de d1-3B describe un modelo de aproximadamente 3.120 millones de parámetros, capaz de trabajar con texto e imágenes y con una ventana de contexto de 32.768 tokens. Su ejemplo oficial de integración utiliza Transformers 5.14 o superior y carga código del repositorio con trust_remote_code=True.
La ficha de d1-omni-600M describe una variante de 587 millones de parámetros, con texto e imágenes o texto y audio. Una petición puede llevar imágenes o audio, pero no ambos a la vez. Sus instrucciones requieren Transformers 5.15 o superior.
Aquí importa leer la letra pequeña: el entrenamiento de audio se centró en solicitudes en inglés entre una persona y un asistente, con clips recortados a 30 segundos. En las entradas con imágenes, el texto del estado y de la pregunta se limita a 896 tokens. El equipo no publica cifras de velocidad para esta variante porque sigue en desarrollo.
Un uso concreto: ordenar solicitudes antes de que actúe un agente
Imaginemos un equipo que recibe incidencias con una descripción y, a veces, una captura de pantalla. Este es un ejemplo hipotético, no una prueba realizada por Puntoes.
Podríamos plantear tres decisiones: qué equipo debe atender la solicitud, si bloquea el trabajo y si falta información. Esa clasificación puede alimentar una cola de revisión o ayudar a un agente a escoger su siguiente paso.
Nuestra propuesta sería mantener separados dos procesos: interpretar la solicitud y autorizar una acción. Que el modelo clasifique una petición como «reembolso» no debería bastar para devolver dinero. La aplicación seguiría comprobando permisos y reglas del negocio antes de ejecutar nada.
Tampoco trataríamos la confianza de una respuesta como garantía de acierto. Conviene probar mensajes ambiguos, capturas incompletas y casos que no encajan en ninguna opción; decidir cuándo pedir aclaraciones forma parte del diseño.
Qué comprobar antes de adoptarlos
Empezaríamos con una tarea acotada y ejemplos representativos en español. Mediríamos los errores por categoría: enviar un ticket al equipo equivocado y dejar pasar una incidencia urgente tienen consecuencias distintas. Compararíamos el resultado con las reglas o el sistema que ya utiliza la empresa, sobre su hardware real.
Los pesos descargables permiten estudiar una integración local, pero no demuestran que vaya a funcionar bien en cualquier dispositivo o idioma. El fabricante publica sus propias evaluaciones; no hemos ejecutado estos modelos y no presentamos esas cifras como resultados nuestros ni como prueba de superioridad universal.
Las fichas identifican una licencia LFM 1.0. Antes de integrar o redistribuir, hay que revisar sus condiciones; «pesos abiertos» no equivale a permisos ilimitados. También revisaríamos el código que se autoriza a cargar y fijaríamos una versión concreta para que futuras actualizaciones no cambien la integración sin control.
La oportunidad está en probar si una decisión bien definida necesita un generador de texto completo. Para las tareas con entradas visuales o de voz, este lanzamiento añade opciones que merece la pena evaluar, con especial cautela en la variante experimental.