Liquid AI d1-omni-600M ya está disponible como Ollama Pull: un modelo de decisión de 600M que puede oírte

Liquid AI d1-omni-600M se convirtió en un paquete de Ollama a las 22:32 UTC del 17 de octubre de 2026. Esa marca de tiempo no es una suposición: el registro de Ollama entrega una cabecera ollama-push-time en cada manifiesto, y las cuatro etiquetas que hay detrás del nombre d1-omni se aceptaron entre las 22:31:25 y las 22:32:13 de esa noche, aproximadamente cuatro horas antes de que se escribiera esto. El modelo en sí no es nuevo — Liquid AI publicó con pesos abiertos Liquid AI d1-omni-600M junto con Liquid AI d1-3B el 5 de octubre de 2026 y anunció ambos en su publicación "Open d1" del 7 de octubre —pero hasta anoche las únicas formas de ejecutar el que admite audio en tu propio hardware eran un entorno de transformers con trust_remote_code=True o una compilación de llama.cpp que compilaras tú mismo. Ahora es ollama pull d1-omni. Nadie lo anunció: ni el blog de Liquid AI, ni el de Ollama.

El empaquetado es la historia, y merece la pena ser preciso sobre qué partes de él están documentadas. Las publicaciones más recientes del blog de Liquid AI son d1-ultra, del 15 de octubre, y LFM2.5-24B-A2B, del 13 de octubre, y ninguna menciona a Ollama; la propia página de despliegue con Ollama del laboratorio sigue enseñando a ejecutar sus repositorios GGUF directamente desde Hugging Face con ollama run hf.co/LiquidAI/... y nunca nombra un modelo d1. El blog de Ollama guarda el mismo silencio: sus entradas más recientes son Reflection's Beam, del 16 de octubre, y una integración con Fly.io, del 13 de octubre. Lo que existe en su lugar es una entrada en el registro, cuatro etiquetas, un digest verificable y una página de biblioteca que todavía se estaba redactando mientras se escribía este artículo: una captura temprana de esa página devolvió "No readme", y una captura cuarenta minutos después devolvió una descripción completa escrita por Liquid AI con una tabla de benchmarks y una sección de licencia. Si quieres un acontecimiento fechado y comprobable de los últimos siete días, esa cabecera es la que hay.

Lo que el registro aceptó realmente

Cuatro etiquetas resuelven a dos imágenes, que es lo primero que hay que entender antes de hacer pull. d1-omni:latest, d1-omni:600m y d1-omni:600m-q8_0 son el mismo manifiesto —digest 1ba59f63e836—, mientras que d1-omni:600m-bf16 es un segundo manifiesto, digest c1e95fce6627. No hay una etiqueta F16, aunque el repositorio GGUF del propio proveedor publica un tronco F16.

• Capas de pesos (compilación Q8_0) — un tronco de 407 MB de d1-omni-600M-Q8_0.gguf más un proyector de 442 MB de mmproj-d1-omni-600M-BF16.gguf, con un blob de licencia de 10,5 KB y un blob de parámetros de 18 bytes, que totalizan 849.659.968 bytes.

• Tamaño indicado: 850 MB para la etiqueta predeterminada y 1.2 GB para 600m-bf16, ambos tal como se muestran en la página de la biblioteca.

• Mínimo de runtime — requiere: 0.40.4 en el blob de configuración, que además informa model_family: lfm2, model_type: 380.73M y tipo de archivo Q8_0.

• Contexto — el blob de parámetros fija num_ctx en 16.384.

• Licencia — el texto integrado es la LFM Open License v1.0, que nombra a Liquid AI, Inc. como licenciante y coincide con el identificador lfm1.0 de la tarjeta del modelo.

Ese proyector merece una segunda mirada, porque es más grande que el modelo al que está adjunto. Leer los metadatos GGUF directamente del blob del registro muestra clip.has_vision_encoder = True y clip.has_audio_encoder = True en el mismo archivo: 197 tensores de visión repartidos en 12 bloques con embeddings de 768 de ancho y entradas de 256 píxeles, y 641 tensores de audio repartidos en 17 bloques con embeddings de 512 de ancho y 128 bins mel. Eso es la torre SigLIP2 y el codificador FastConformer viajando ambos en el paquete multimodal, por lo que un tronco de 381M parámetros se envía detrás de un adjunto de 442 MB. La capacidad de audio está físicamente en el paquete que descargas; la cuestión de si el endpoint puede alcanzarla llega después.

El modelo tiene 587M de parámetros y la insignia de 125K es más grande que la verdad.

La página de Ollama anuncia «ventana de contexto de 125K» en cada etiqueta. El num_ctx del propio paquete es 16,384, y la model card de Liquid AI dice lo mismo con palabras: 16,384 tokens que abarcan en conjunto posiciones de texto, imagen y audio, con el texto de estado y de pregunta recortado a 896 tokens siempre que haya imágenes. La cifra de 125K es rastreable —el GGUF principal lleva lfm2.context_length = 128000—, pero es el techo de la arquitectura, no la ventana que se obtiene, y es el número con más probabilidades de inducir a error a quien esté dimensionando un reemplazo para un clasificador de contexto largo. Toma 16,384 como la cifra operativa y 896 tokens de texto como la cifra operativa cuando haya una imagen en el estado.

El resto de los metadatos corrobora la ficha del modelo más que el texto de marketing. El tronco consta de 18 bloques, embeddings de 1.024 dimensiones y un vocabulario de 65.536, y no es un decodificador: lfm2.attention.causal es False. Sus recuentos de cabezas KV por capa son 0, 0, 8, 0, 0, 8, …, lo que significa que la mayoría de esos bloques no son bloques de atención en absoluto, lo que deja entrever una ascendencia de codificador bidireccional. La cabeza de decisión consta de dos bloques (lfm2.decision.block_count = 2), y las constantes de calibración que el proveedor guarda en config.json también están en este GGUF: las preguntas de elección llevan una temperatura de 1,7465 con dos opciones, 1,3999 con tres a cinco, 1,1751 con seis a diez y 1,3725 con más de once; sí/no es 1,6663; las preguntas puntuadas son 1,7301 con tres a cinco niveles y 1,0 con seis a diez. Ese es todo el diseño en un solo lugar: un conjunto fijo de respuestas con nombre, puntuadas en una sola pasada, calibradas según la forma de la pregunta, con output_tokens: 0 al final.

No es un modelo de chat y no escribe texto. Liquid AI enumera quince idiomas, restringe los datos de entrenamiento de audio al inglés —peticiones entre un hablante y un asistente— y limita los clips a 30 segundos. La ficha también advierte contra bfloat16 en GPUs: en las propias comprobaciones del proveedor, cambió la respuesta principal en el 0.8% de las filas de texto y el 1.7% de las filas de audio, mientras que float16 coincidió con float32 en todas partes.

El audio está en los pesos y ausente de la API documentada.

Esta es la discrepancia que conviene conocer antes de reportar un error. El readme de la página de la biblioteca, escrito por Liquid AI, documenta el audio colocando un WAV en base64 dentro del arreglo images de una solicitud a /v1/systemone. El readme GGUF de Hugging Face del proveedor para el mismo checkpoint lo documenta de otra manera, con un arreglo files que lleva data:audio/wav;base64,… al servidor llama.cpp. Y la referencia del endpoint que publica Ollama no documenta ninguna de las dos: su esquema de solicitud tiene state, images, questions y keep_alive, describe images como «Requiere un modelo con visión, como Clef» y no contiene ningún campo de audio ni ningún campo files. Mientras tanto, la propia guía de modelos de decisión de Ollama nombra Nimble, Tev1, Clef y Clef Flash como los modelos de decisión y solo dice que los modelos Clef también pueden juzgar imágenes.

La postura honesta sobre el audio en Ollama hoy es: el codificador está verificado como presente en el blob, el README del proveedor dice que funciona mediante imágenes y el esquema publicado no lo admite. La entrada de imágenes en el mismo modelo tiene una base más sólida: la visión es una capacidad documentada de System One y d1-omni aparece en el listado de la categoría de visión de Ollama. Junto a esa brecha hay otras dos lagunas de documentación más pequeñas: la referencia del endpoint permite hasta 255 claves de opción en una pregunta de elección, mientras que la guía de decisión indica de 2 a 26, y el mínimo de runtime del paquete, 0.40.4, es superior al 0.35.0 que cita la documentación del endpoint.

Archivado en visión, no en decisión

El buscador de modelos de Ollama filtra los modelos de decisión en su propia categoría. Contiene nueve entradas —nimble-v3, pplx-decider, kev, tev1, nimble, clef-flash, clef, laya y strands-decider— y ni d1 ni d1-omni están entre ellas. La página de d1-omni está etiquetada con vision y 600m, y sí aparece en el listado de vision, así que un lector que busque "decision model" no encontrará el más reciente. Es un problema de descubrimiento más que de capacidad, pero importa si pensabas comparar las familias de decisión en el propio catálogo de Ollama y llegaste a la conclusión de que este no existía.

Lo que también significa es que d1-omni es el primer modelo de decisión de la biblioteca de Ollama que puede procesar voz en absoluto: el codificador de audio está incluido en el paquete y ningún otro de esa lista de nueve modelos lleva uno. Si el endpoint te entregará tu WAV es la pregunta abierta de la sección anterior, y es lo único que con mayor probabilidad haya cambiado para cuando leas esto.

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

Todas las cifras de precisión asociadas a Liquid AI d1-omni-600M son de Liquid AI, y no existe ninguna evaluación independiente de ningún modelo d1 hasta donde hemos podido encontrar —ninguna fila en una tabla de clasificación, ninguna ejecución de terceros, ningún rechazo publicado de la puntuación del proveedor. El propio proveedor puntuó ambos checkpoints d1 con el evaluador oficial Decision Index en lugar de enviarlos a la tabla de clasificación pública, y así lo indica en la ficha; cada fila de la competencia en su tabla proviene de leaderboard v0.2.1, lo que significa que la comparación es una cifra autoevaluada situada junto a otras evaluadas externamente.

• Índice de decisión 0.2.1 — 15,95 para d1-omni-600M (conocimiento 8,3, lenguaje 12,9, recuperación 35,0, herramientas 15,1, artes 6,8) frente a 48,57 para d1-3B.

Benchmarks como decisiones, media de siete — 78,4 para d1-omni-600M frente a 82,9 para d1-3B, con el modelo 600M por delante en Civil Comments (95,8 vs 93,0) y PAWS-X (79,5 vs 76,9), y por detrás en BoolQ (77,7 vs 86,7) y SQuAD 2.0 (74,0 vs 85,3).

• Fast Decisions, división de desarrolladores — 76.9, según el proveedor, no se publicó ninguna fila de comparación.

• Velocidad — nada. La ficha lo dice claramente: no se publican cifras de inferencia porque se trata de una versión de investigación temprana en desarrollo activo, así que cualquier dato de latencia que veas sobre ella en otro sitio es una medición que alguien ha hecho por su cuenta.

• Los números de fixture en la página de Ollama: el ejemplo desarrollado del readme muestra urgent respondido en 0.998 y technical en 0.995. Esos son resultados ilustrativos de una solicitud, publicados por el runtime, y no constituyen un benchmark.

La diferencia entre 15.95 y 48.57 es lo más útil de la ficha, porque resuelve la pregunta de compra en las propias palabras del proveedor: el readme te dice que uses d1 cuando lo que importa es la precisión en texto e imágenes, y que recurras a d1-omni cuando importa el tamaño o necesitas audio. Un modelo de 587M que obtiene 78.4 en siete benchmarks públicos, reinterpretado como decisiones, es un clasificador de borde plausible. No es una versión más pequeña del 3B.

Dónde encaja OrcaRouter y dónde no

No servimos este modelo. Una consulta de nuestro catálogo el 18 de octubre devolvió 208 identificadores de modelo y ninguno de ellos es de Liquid AI, así que nada de esto constituye una afirmación de disponibilidad y no hay ninguna vía por nuestra parte para obtenerlo. Si quieres Liquid AI d1-omni-600M, la ruta local es la que se describe arriba, y la ruta alojada es la API propia del proveedor y las plataformas de terceros que lo adopten.

Lo que cambia el empaquetado es la forma del sistema que lo rodea, y ahí es donde somos útiles. Un modelo de decisión casi nunca es todo el pipeline: el ticket que etiqueta, el fotograma que señala y la transcripción que enruta todavía tienen que ser respondidos, resumidos o escalados por algo que escriba texto. Esas llamadas generativas se realizan a través de una única clave compatible con OpenAI para más de 200 modelos alojados al precio de lista del proveedor, repercutido con un 0 % de margen, así que un cambio de precio del proveedor te llega el mismo día en lugar de con un nuevo contrato. Y como d1-omni-600M se entrega sin evidencia independiente de precisión y sin latencia publicada, la forma correcta de ponerlo delante de tráfico real es mediante conmutación automática por error entre proveedores — deja que gestione las llamadas sobre las que tiene confianza y mantén una vía de salida cuando no la tenga, en lugar de convertir 587M de parámetros en un punto único de fallo para tu paso de triaje. La decisión sigue siendo local; el respaldo no tiene por qué serlo.

¿Qué cambiaría esta lectura?

Cuatro cosas, cualquiera de las cuales convertiría una nota de empaquetado en un artículo distinto. Que Ollama documente el audio en el esquema de solicitud de System One, lo que convertiría el truco de WAV dentro de imágenes del readme en una entrada admitida y haría de este el primer modelo de decisión con capacidad de voz que se puede ejecutar con un solo comando. Que cualquiera de las dos empresas reconozca el port —que Liquid AI añada d1-omni a la página de Ollama de su documentación de despliegue, o que Ollama lo incluya bajo modelos de decisión en lugar de visión—. Una cifra de velocidad de cualquiera, sea proveedor o no, ya que hoy no existe ninguna. Y una fila independiente en Decision Index para cualquier modelo d1, que sigue siendo la única pieza que falta en toda la familia.

Hasta entonces, la decisión es sencilla. Si ya ejecutas Ollama en 0.40.4 o una versión posterior, el pull es un solo comando, la descarga es de 850 MB y lo que obtienes es un clasificador de 587M que responde preguntas escritas en una sola pasada hacia delante sobre texto e imágenes —y, si el readme está en lo cierto, sobre más de 30 segundos de habla en inglés. Si tu estado es extenso, ten en cuenta la ventana de 16,384 tokens y el presupuesto de 896 tokens para texto, en lugar de la insignia de 125K. Y si necesitas pruebas de que es preciso antes de que etiquete algo que vea un cliente, esas pruebas aún no existen, ni para este modelo ni para ninguno de sus hermanos.

Los fallos de IA documentados y los incidentes de agentes que hay detrás de lanzamientos como este se recopilan en el Archivo de Incidentes de IA de OrcaRouter, donde cada entrada incluye sus propias fuentes, gravedad, grado de confianza e indicador de disputa.