Liquid AI d1-3B llega a Ollama: un endpoint local discreto para un modelo de decisión

Hay un nuevo d1 en la biblioteca de Ollama, y no es un modelo de chat. La entrada lo describe en una sola línea —"un modelo de decisión de 3B de Liquid AI, construido sobre LFM2.5-VL-3B"— y esa única frase contiene los dos hechos que más importan. Liquid AI d1-3B, el modelo pequeño que Liquid AI construyó sobre Liquid AI LFM2.5-VL-3B y publicó como pesos abiertos el 5 de octubre de 2026, ahora está empaquetado de modo que un solo pull lo pone en tu propia máquina; y sigue devolviendo probabilidades calibradas sobre preguntas tipadas en lugar de texto generado, exactamente igual que el checkpoint subyacente. Si tienes un paso de triaje, enrutamiento, moderación o control en una canalización, esta es la primera vez que esa familia concreta de modelos está a un solo comando de ejecutarse sin clave de API, sin precio por llamada y sin que ningún texto de estado salga de tu hardware.

La palabra "quiet" hace aquí un trabajo real, sin embargo, y merece la pena ser precisos sobre qué mitad de esta historia está documentada y qué mitad no. El propio blog de Liquid AI nunca ha mencionado Ollama: la publicación más reciente del laboratorio, del 13 de octubre de 2026, trata sobre un modelo diferente de la línea LFM2.5, y sus dos publicaciones sobre d1 —el anuncio de visión del 5 de octubre y el lanzamiento "Open d1" del 7 de octubre— describen pesos, una API y una puntuación de referencia, no un entorno de ejecución local. La página de la biblioteca de Ollama para d1 tampoco incluye ningún anuncio, y el índice de documentación del proveedor tampoco, que marca GGUF como disponible para Liquid AI d1-3B y su hermano con capacidad de audio Liquid AI d1-omni-600M mientras nombra a llama.cpp, Ollama y MLX solo como opciones genéricas de despliegue. Lo que existe es un paquete publicado, una entrada de registro con un digest que puedes verificar, un readme funcional y un contador de descargas que marcaba 10.4K cuando se escribió esto el 15 de octubre de 2026. Lo que no existe es una frase del proveedor que diga "nosotros hicimos esto".

Lo que realmente contiene el anuncio

Se enumeran tres etiquetas —d1:latest, d1:3b y d1:3b-q8_0— y las tres resuelven al mismo digest de manifiesto, 8c2d9ddae441. Eso es lo primero que hay que entender de la página: el contador de «3 models» de la biblioteca es un recuento de etiquetas, no de checkpoints. Un artefacto, tres nombres, 3,7 GB, una ventana de contexto de 32K y entrada de texto e imágenes. Si esperabas elegir un tamaño o una cuantización, todavía no hay nada que elegir.

El registro que hay detrás de la página es más informativo que la página. El blob de configuración del paquete informa una familia de modelos lfm2, un tipo de modelo de 2,7B, un tipo de archivo Q8_0 y un runtime mínimo de Ollama 0.40.4. Se distribuye en dos capas de pesos: un modelo generativo de 2,87 GB y un proyector independiente de 856 MB. Esa segunda capa es el codificador de visión, y su presencia indica que la compilación local conserva la ruta multimodal en lugar de reducir d1 a solo texto — el modelo aún puede leer una fotografía junto con un ticket de soporte y responder preguntas sobre ambos. Los dos números de esta página que parecen no coincidir —«3B» en la descripción y «2,7B» en el registro— se interpretan mejor como el tronco y el conjunto: la ficha del modelo de Liquid AI sitúa el checkpoint en 3,12B de parámetros, incluido un codificador de visión de 400M de parámetros, y el tronco de lenguaje es la cifra menor. Esa aritmética es nuestra, no del proveedor, y se ofrece como una explicación en lugar de como una especificación.

No hay ninguna fecha de calendario en ninguna parte de la página de la biblioteca. Muestra sellos relativos —"Actualizado hace 2 horas" en el momento de la captura— y un contador de descargas, lo que significa que el día en que este listado apareció por primera vez no puede conocerse a partir del propio listado. Los anclajes con fecha están todos en Hugging Face y en el proveedor: el repositorio de pesos de Liquid AI d1-3B se creó el 5 de octubre de 2026, un repositorio GGUF complementario el 6 de octubre, y Liquid AI publicó su entrada de lanzamiento el 7 de octubre. Si necesitas poner una fecha a "cuándo se volvió ejecutable localmente", la respuesta honesta hoy es que el paquete existe y se está descargando ahora mismo, y nadie fuera de Ollama puede decir en qué mañana apareció.

Por qué un evento de packaging es un evento real

Ollama abrió una categoría de modelo de decisión el 29 de septiembre de 2026, cuando lanzó el endpoint /v1/systemone y una bandera --ask de CLI para modelos que responden preguntas tipadas en una sola pasada hacia adelante. Nimble y Clef fueron las primeras familias en cruzar esa puerta. Lo que añade el nuevo paquete d1 es algo distinto de una nueva fila de benchmark: toma un modelo que hasta ahora vivía ya sea en un entorno de Python con una clase de modelo vendorizada o detrás de un endpoint alojado, y convierte la inferencia local en un comando.

Vale la pena reformular el contrato porque no es lo que la mayoría de los lectores entiende por «ejecutar un modelo». Le entregas a d1 un estado —una cadena, un objeto JSON, un arreglo, o una cadena más imágenes— y un conjunto de preguntas con nombre, y recibes respuestas sin ningún token generado. noul es una pregunta de sí/no que se responde como una única probabilidad entre 0 y 1. choice devuelve la etiqueta seleccionada, una confianza y un mapa de probabilidad completo sobre tus opciones. score sitúa el estado en una rúbrica ordenada de dos a diez niveles y devuelve el nivel ponderado por probabilidad más la probabilidad de cada nivel. Un estado, hasta 64 preguntas, una pasada sobre la entrada. La propia respuesta de ejemplo de Ollama para un ticket de soporte devuelve usage.output_tokens: 0, que es la declaración más limpia posible del diseño.

Para cualquiera cuyo pipeline ya invoque un modelo de decisión por HTTP, la vía local cambia tres cosas a la vez: la latencia, porque la solicitud deja de salir de la máquina; el costo, porque no hay un medidor por llamada; y el tratamiento de los datos, porque el texto del ticket y la fotografía que estás clasificando nunca cruzan la red. Si tu estado es el mensaje de un cliente o un documento interno, ese último punto suele ser el único argumento que hace falta presentar.

Ejecutarlo, y los límites que la documentación le impone

Hay tres formas de acceso compatibles, y todas están documentadas en la página de la biblioteca. La vía de la CLI es ollama run d1 --ask "Is a refund being requested?" con el estado canalizado desde un archivo, y las opciones --choice y --level para los otros dos tipos de pregunta. La vía HTTP es un POST a http://localhost:11434/v1/systemone con un model, un state, un array images opcional y un objeto questions. La vía del SDK apunta el cliente Python de TypeSafe a localhost, donde la clave de API se ignora y cualquier valor de marcador de posición sirve.

Los límites provienen de la documentación del endpoint de Ollama, no de Liquid AI, y son más estrictos que los de un modelo generativo: las solicitudes deben caber en 64 KiB sin imágenes y 32 MiB con ellas, no se admite streaming, los modelos alojados en la nube se rechazan de plano, y las imágenes deben ser PNG, JPEG o WebP en base64 enviadas en el cuerpo de la solicitud; las URL remotas se rechazan. Las imágenes se comparten entre todas las preguntas de una solicitud, así que una imagen que solo quieras que considere la primera respuesta debe enviarse como una llamada propia. La entrada nunca se trunca, lo que significa que un estado sobredimensionado es un error en lugar de un prompt recortado silenciosamente.

Hay dos detalles de la documentación que vale la pena señalar como no resueltos. La referencia del endpoint de Ollama describe el tipo de elección como si aceptara de 2 a 255 claves de opción, mientras que la página de capacidades de los modelos de decisión dice de 2 a 26: una de las dos está desactualizada, y no está claro cuál. Y la página de capacidades nombra sus modelos compatibles como Nimble, Tev1, Clef y Clef Flash, sin ninguna mención a d1, aunque el propio readme del paquete d1 afirma que funciona a través de /v1/systemone y --ask. El paquete requiere Ollama 0.40.4; el mínimo documentado para el propio endpoint es 0.35.0. Nada de eso es una contradicción que te impida descargar el modelo, pero lee el requisito de versión del paquete en lugar del que figura en la guía de capacidades.

Los números, y quién produjo cada uno de ellos

Ahora bien, la parte que merece la mayor cautela. Todas las cifras de rendimiento asociadas a este modelo son de Liquid AI, y no existe ninguna evaluación independiente de Liquid AI d1-3B que hayamos podido encontrar. Los resultados reportados por el proveedor, repetidos en la página de Ollama y en la ficha del modelo, son estos:

• Índice de decisión 0.2.1 — 48,57 para d1-3B, frente a 47,11 para Decider 35B-A3B, que Liquid describe como la mejor puntuación para un modelo de decisión de menos de 10B parámetros. • Visión — una media de 74,1 en once benchmarks públicos de imágenes, frente a 73,9 para la base LFM2.5-VL-3B a partir de la cual se creó. • Latencia — 8 ms por decisión en una RTX 4090, 9 ms en una AMD MI325X y 30 ms en un Apple M5 Pro. • Rendimiento — 475 decisiones por segundo en la 4090 y 1.106 en la MI325X cuando las preguntas se empaquetan en lotes. • Ablación — el mismo conjunto de preguntas respondido sin imágenes obtiene 45,1, que es la propia medida de Liquid de cuánto contribuye la ruta de visión.

La fila de visión es la que debería moderar las expectativas. Una mejora de 0,2 puntos sobre el modelo base en un conjunto de benchmarks de imágenes está dentro del ruido de la mayoría de los informes de benchmarks; sea lo que sea que te aporte la cabeza de decisión, no es un codificador de imágenes sustancialmente mejor. La fila de ablación es más interesante en la otra dirección —una variación de aproximadamente 29 puntos cuando se añaden imágenes—, pero compara dos conjuntos de preguntas diferentes, no dos versiones del mismo. Y el Decision Index es un instrumento de terceros en el que Liquid puntuó sus propias entradas en lugar de enviarlas para una clasificación pública, así que trata 48,57 como una afirmación de proveedor hecha con la vara de medir de otro. Las cifras de velocidad tampoco están auditadas: 8 ms en una 4090 es un número plausible para un modelo de 3B que hace una sola pasada hacia delante, y sigue ocurriendo que nadie ha publicado una ejecución que no sea suya.

Dónde encaja OrcaRouter y dónde no

OrcaRouter no sirve Liquid AI d1-3B. Revisamos nuestro catálogo antes de escribir esto — 207 modelos, ninguno de ellos de Liquid AI, ninguno de ellos un modelo de decisión — así que si quieres llamar a d1 desde una API en lugar de desde tu propio hardware, la ruta alojada hoy es el propio endpoint de decisiones del proveedor en api.liquid.ai/decisions/v1/systemone, donde un nivel d1 de pago gestiona imágenes y un nivel gratuito d1:free es solo texto, además de las plataformas de terceros que lo adopten. Nada en este artículo debe leerse como una afirmación de que lo alojamos.

Lo que hacemos es adyacente al problema que resuelve este modelo. La razón por la que existe un modelo de decisión es que las canalizaciones necesitan una forma barata y determinista de elegir entre opciones, y el propio ejemplo documentado de d1 es un ticket enrutado a un equipo de destino — que es un problema de enrutamiento un nivel por debajo del nuestro. Cuando esa decisión condiciona una llamada a un modelo generativo que alquilas en lugar de ejecutar, OrcaRouter es una clave compatible con OpenAI para más de 200 modelos alojados al precio de lista del proveedor, trasladado con 0% de recargo, de modo que una rebaja de precio del proveedor te llega el día en que se aplica en lugar de en la próxima renovación del contrato. Y como la mitad local de esta canalización es la mitad que tú posees, el riesgo está en la mitad alojada: la conmutación por error automática entre proveedores mantiene viva una solicitud triada cuando el modelo al que la enrutaste se cae. Ninguna de esas es una razón para usar un modelo de decisión de 3B. Son razones por las que lo que está al otro lado de la decisión no debería ser un único punto de fallo.

¿Qué haría falta para que esto dejara de ser una nota de embalaje y se convirtiera en una historia?

Cinco cosas, cualquiera de las cuales cambiaría la lectura. Que Liquid AI reconozca el port, o que su índice de documentación añada Ollama a la fila de despliegue que actualmente llena con llama.cpp y MLX. Una segunda cuantización: el propio repositorio GGUF de Liquid incluye Q4_K_M, F16 y BF16 junto con Q8_0, así que una compilación local más pequeña está técnicamente disponible, solo que no a través de este paquete. Una ruta local para Liquid AI d1-omni-600M, el hermano de 587M de parámetros que lee hasta treinta segundos de audio y que el proveedor etiqueta como una versión de investigación temprana — ese importaría más que el 3B para el trabajo en dispositivo, y todavía no hay rastro de él en ninguna biblioteca. Una fila independiente en el Decision Index, o una entrada en una tabla de clasificación pública, que es la única pieza que falta en toda esta familia de modelos. Y que Ollama añada d1 a su página de capacidad de decisión, que es un cambio de una línea que te diría que el port está avalado y no es algo incidental.

Hasta entonces, la decisión es lo bastante sencilla como para tomarla en tus propios términos. Si ya ejecutas una versión reciente de Ollama, el pull es un solo comando, la descarga es de 3,7 GB, y lo que reemplaza es o bien una llamada alojada que preferirías no hacer con el texto de un cliente, o bien un entorno de Python que da más trabajo de mantener de lo que vale el modelo. Si necesitas evidencia independiente de precisión antes de que esto quede frente a usuarios reales, esa evidencia todavía no existe para ningún modelo d1, y ninguna cantidad de empaquetado local la crea.

Ejecutar el paso de decisión en tu propio hardware también es un buen momento para examinar lo que ya ha salido mal en esta clase: los incidentes de IA documentados y los fallos de agentes relacionados con modelos de decisión se recopilan en the OrcaRouter AI Incident Archive, donde cada entrada incluye sus propias fuentes, gravedad, grado de confianza e indicador de disputa.