d1-Omni-2B: qué incluye el modelo de decisión 2B más discreto de Liquid AI — y qué deja fuera

El repositorio de Hugging Face de LiquidAI/d1-Omni-2B se creó a las 19:30 UTC del 24 de octubre de 2026. La primera publicación en el blog de Liquid AI que mencionó el modelo por su nombre se publicó el 27 de octubre. Durante esos tres días, el repositorio fue público y completo —una hoja de especificaciones completa, 4,33 GB de safetensors BF16, código de Transformers funcional— y nada de lo que publicó el proveedor indicaba que existiera. Cuando finalmente llegó la mención, eran dos párrafos y una tabla de cuatro filas dentro del lanzamiento de una familia de seis modelos, no un lanzamiento propio. Esa es la forma de este lanzamiento, y es el marco honesto para todo lo que sigue: los pesos son inspeccionables, las afirmaciones son del proveedor, y las partes que un comprador normalmente obtendría de un anuncio —un precio, un endpoint alojado, un benchmark independiente— aún no están.

La brecha de cinco días entre las pesas y las palabras

La historia de los modelos de decisión de Liquid AI se ha contado dos veces, y d1-Omni-2B no aparece en ninguna de las dos. El 7 de octubre, la empresa publicó «Open d1: Edge decision models for text, vision, and audio», que presentó exactamente dos checkpoints abiertos: d1-3B, un modelo de visión y texto de 3,12B, y d1-omni-600M, un modelo de 587M que aceptaba texto con imágenes o texto con hasta 30 segundos de audio. Esa publicación sigue activa y todavía no contiene ningún modelo de 2B.

La línea 2B llegó con un calendario distinto. El 21 de octubre, el checkpoint base LFM3-Omni-2B apareció en Hugging Face. El 24 de octubre, con veinticuatro segundos de diferencia, Liquid AI creó repositorios para d1-2B y d1-Omni-2B. La publicación de lanzamiento de LFM3 del 27 de octubre nombró entonces a la familia: seis modelos de alrededor de 2B parámetros, cuatro que abarcan texto, visión, audio y omni y, en palabras de la propia publicación, «los dos últimos son modelos de decisión especializados a partir de los modelos de visión y omni». Esa frase es el anuncio. No ha habido una publicación separada de d1-Omni-2B, ni una página de precios, ni una cita de un socio de lanzamiento, ni una actualización del artículo del 7 de octubre.

Así que el modelo no está indocumentado — el repositorio es uno de los checkpoints pequeños mejor documentados que Liquid AI ha publicado, y la página de documentación del proveedor para modelos de decisión lo incluye junto a d1-2B y d1-omni-600M. Está poco anunciado. Esa distinción importa porque te dice qué afirmaciones han pasado por una revisión de lanzamiento y cuáles no.

Leer la tarjeta como una ficha de especificaciones

Si dejamos a un lado el marco, el checkpoint es sencillo. d1-Omni-2B es un modelo de decisión post-entrenado construido sobre LFM3-Omni-2B, y no es un modelo de chat: no escribe texto ni produce voz, y cada llamada devuelve output_tokens: 0.

• Parámetros — 2,17B, distribuido como un único archivo safetensors BF16 de 4,33 GB.

• Arquitectura — el backbone LFM3: 24 capas, de las cuales 13 son convoluciones cortas con compuerta, 5 son atención de ventana deslizante con una ventana de 256 tokens y 6 son atención global. La publicación de la familia describe esta mezcla trihíbrida como el resultado de una búsqueda de arquitectura con hardware en el bucle ejecutada en 14 combinaciones de dispositivos y backends.

• Contexto y vocabulario — 128K tokens y un vocabulario de 128.000 tokens compartido con el resto de LFM3.

• Entrada — un estado que puede ser texto o cualquier valor JSON, además de imágenes, fotogramas de vídeo y clips de audio, además de cualquier número de preguntas con nombre, escritas o habladas. La API de la tarjeta toma todo eso en una lista de medios, lo que supone una diferencia significativa respecto al checkpoint de 587M: d1-omni-600M está documentado como texto con imágenes o texto con audio, no ambos a la vez.

• Salida — respuestas tipadas con probabilidades. Sí/no, una selección entre opciones con nombre, una puntuación ordenada, un valor leído de un documento con su fragmento, un número con un intervalo p10–p90, un cuadro delimitador o cada instancia de un objeto con un recuento.

• Idiomas — dieciséis. La voz cubre el mismo conjunto excepto hindi, tailandés, vietnamita e indonesio, lo cual vale la pena señalar porque el lado del texto sí los incluye.

• Licencia — LFM Open License v1.0. El uso comercial se concede por debajo de los $10,000,000 de ingresos anuales; por encima de esa cifra, el texto de la licencia indica que el uso comercial «no está licenciado en virtud de este Acuerdo».

El audio es la afirmación que vale la pena poner a prueba.

La razón para optar por este checkpoint en lugar de d1-2B es el audio. Liquid AI lo posiciona para «el enrutamiento de llamadas y mensajes de voz, y eventos sonoros», y la tarjeta del modelo incluye la única prueba con la que normalmente habría abierto una publicación de lanzamiento: una comparación entre habla y escritura sobre los mismos elementos.

• Enrutamiento y triaje empresarial (DecisionBench, Hanno Labs v1) — 83.4 escrito, 78.2 hablado.

• Casos de atención al cliente (Decisiones tipificadas) — 50,5 escritos, 48,0 hablados.

• JevBench v1.4.1, las filas que una voz puede pronunciar — 87.6 en escrito, 89.0 en hablado, lo que significa que la ejecución hablada obtuvo una puntuación ligeramente superior, lo que es ruido en lugar de una mejora.

• Eventos sonoros (ESC-50) — 84.5, sin equivalente escrito.

• Identificación de idioma hablado (FLEURS, 43 idiomas) — 92,5.

Esos números respaldan el argumento de venta. El resto de la sección de audio es la parte que te indica dónde no construir, y es inusualmente franca para una ficha de proveedor. Los estados cortos hablados caen de 42,0 escritos a 22,8 escuchados. Los pasajes de Belebele en ocho idiomas caen de 83,6 a 41,8. La ficha afirma sin rodeos que los pasajes hablados largos pierden gran parte de su precisión, «sobre todo fuera de los idiomas con escritura latina», y remite a d1-2B, en su lugar, a cualquiera que no tenga entrada de audio, que según dice es más fuerte en texto y cajas individuales, informa de valores faltantes con más frecuencia y está mejor calibrado.

Leídas en conjunto, esas filas describen un modelo que es bueno con enunciados breves y enrutables en los principales idiomas y mucho más débil en cualquier cosa que requiera mantener un estado hablado prolongado. El triaje de un centro de llamadas encaja. Una reunión grabada de cuarenta minutos, no.

El marcador es del proveedor, y el índice cambió de versión.

Todas las cifras de rendimiento de este modelo son de Liquid AI. La ficha es explícita sobre el método: los cuatro modelos d1 se puntuaron con los mismos ítems y la misma puntuación, por lo que algunas cifras difieren ligeramente de las fichas individuales de las que proceden. No indica que un tercero haya reproducido nada de esto, y en el momento de escribir esto no existe ninguna evaluación independiente de d1-Omni-2B.

• suite pública Decision Index, v0.3 — 49,0 para d1-Omni-2B, frente a 51,1 para d1-2B, 49,0 para d1-3B y 18,3 para d1-omni-600M.

• DecisionBench (Hanno Labs) v1 — 76.4, frente a 77.1, 73.1 y 58.7 respectivamente.

• decisionbench.ai v4 — 84,7, frente a 85,2, 83,6 y 57,9.

• ImajevBench v2.0-lite — 72,3, frente a 75,5, 64,0 y 21,7.

• La propia batería de más de cien benchmarks del fabricante — 61,8, frente a 63,2, 58,8 y sin puntuación para el 600M.

• Promedio de visión en 18 pruebas de referencia de imágenes — 67,7, frente a 70,2, 65,4 y 42,8.

Hay una trampa en medio de esto. La publicación del 7 de octubre reportó d1-omni-600M en 15.95 en Decision Index v0.2.1. La nueva ficha lo reporta en 18.3 en v0.3. Son conjuntos de pruebas diferentes y la diferencia no es una ganancia de capacidad; no restes uno del otro. La única comparación justa es la que la ficha realmente hizo, con los cuatro modelos re-puntuados en los mismos ítems.

El patrón que sobrevive a la reevaluación es que d1-Omni-2B queda justo por debajo de d1-2B en casi todo y por encima de la generación anterior por un margen amplio. Liquid AI lo presenta como superar a d1-3B en su tablero de decisiones y en 16 de 18 benchmarks de imágenes con el 70 % de los parámetros, lo cual es cierto en la tabla tal como está impresa y también es una comparación contra un modelo que la familia ya ha reemplazado.

Lo que el repositorio no responde

Cinco preguntas siguen abiertas, y ninguna de ellas se responde leyendo los pesos.

• Acceso alojado y precio. La publicación de LFM3 dice que los modelos base y post-entrenados están disponibles en Hugging Face, el Playground y la API de Liquid AI. Sin embargo, la tabla de documentación de los modelos de decisión incluye d1-Omni-2B como pesos abiertos y reserva sus filas exclusivas de alojamiento para d1.1 y d1-ultra, y la página del modelo en Hugging Face afirma que «este modelo no está desplegado por ningún proveedor de inferencia». En ninguna parte que este artículo haya podido encontrar se publica un precio por llamada para este checkpoint, así que considera el acceso alojado como plausible pero no confirmado.

• Datos de entrenamiento. La ficha no proporciona ningún corpus, ni composición, ni descripción del conjunto de datos. Menciona pruebas con clips y voces «que ninguna fila de entrenamiento tiene», lo que implica que existe un conjunto de entrenamiento y no dice nada sobre qué contiene.

• Cuantización. El repositorio principal incluye BF16, y Liquid AI publica tres compilaciones hermanas: MLX fp16, MLX de 8 bits y una exportación ONNX. No hay GGUF del proveedor, aunque la biblioteca d1-omni de Ollama incluye una etiqueta 2b con 4.4GB y contexto de 125K, y el tamaño es lo suficientemente cercano al checkpoint BF16 como para que no parezca una cuantización agresiva.

• Evaluación independiente. Ninguna. Todas las cifras anteriores las ejecuta el proveedor con su propio evaluador en su propia tabla.

• Si sustituye a d1-omni-600M. La ficha recomienda d1-2B en lugar de este modelo cuando no hay audio, y recomienda este modelo en lugar de d1-2B cuando lo hay. No dice nada sobre el futuro del checkpoint de 587M, y Liquid AI no lo ha declarado obsoleto.

Ejecutarlo y lo que cuesta en hardware

La ruta de inferencia es Transformers 5.19 o posterior con trust_remote_code, y la llamada es model.system_one(state, questions, media). No hay parámetros de muestreo que configurar, porque no se muestrea nada. La compilación tarda aproximadamente un minuto en las primeras llamadas; después de eso, la tarjeta informa 5,8 ms para una pregunta y 7,7 ms para tres en una H100 PCIe, 3,7 ms y 5,6 ms en una AMD MI325X, y 21,1 ms y 28,9 ms en una Apple M5 Pro. Un estado de 5K tokens cuesta 52 ms en la H100. El batching es donde está el rendimiento: 1.154 estados por segundo en la H100 y 1.697 en la MI325X con 64 estados en una sola llamada.

Para un modelo de esta clase, esos números son el argumento. No compite con un modelo de chat en calidad; compite con el hecho de ejecutar un modelo de chat siquiera. Un pase forward de 5,8 ms que devuelve una probabilidad calibrada es una partida de gasto distinta de una llamada generativa que devuelve un párrafo que luego hay que parsear.

Donde termina la decisión y empieza el resto del pipeline

Un modelo como este hace un solo salto. Convierte un ticket, la grabación de una llamada o un fotograma de cámara en una etiqueta y un nivel de confianza, y luego algo tiene que actuar sobre esa etiqueta: redactar la respuesta, escalar el caso, llamar a la API. Ningún modelo de Liquid AI está en el catálogo de OrcaRouter, así que ese segundo salto es donde reside realmente nuestro producto: los modelos generativos que consumen la decisión pasan por una única clave compatible con OpenAI que cubre más de 200 modelos, al precio de lista de cada proveedor trasladado con un 0 % de margen, con conmutación automática por error cuando una solicitud recae en un proveedor que está teniendo un mal momento. El modelo de decisión es la parte barata, rápida y determinista. Vale la pena conectar la parte cara y no determinista a algo que pueda reintentar.

¿Qué lo resolvería?

Tres cosas harían pasar d1-Omni-2B de «prometedor» a «recomendable», y ninguna de ellas requiere otra entrada de blog. La primera es una ejecución independiente del conjunto de pruebas de audio en hardware que el proveedor no controla: la brecha de 22,8 frente a 42,0 en estados cortos hablados es la cifra más probable de cambiar con el micrófono de otra persona. La segunda es un precio publicado para el acceso alojado, sin el cual no puede completarse el cálculo de construir frente a comprar. La tercera es una comparación directa con d1-2B en las mismas tareas que incluyen audio, porque la recomendación de la propia ficha —usar el 2B omni solo cuando la entrada incluya audio— es la frase más útil que contiene, y también es la que nadie ha probado fuera de Liquid AI.