Liquid AI d1 vs Liquid AI d1-omni-600M: el modelo de decisión abierto que puede oírte

Busca el nombre Liquid AI d1 y llegarás a un modelo de tres mil millones de parámetros que lee texto e imágenes. El otro checkpoint abierto de la misma familia tiene una quinta parte del tamaño, considera hasta treinta segundos de habla y es el único de los dos que puede decidir algo en absoluto sobre una voz. Se llama Liquid AI d1-omni-600M, y si descubriste la familia a través de una biblioteca de ejecución local en lugar de la propia documentación del proveedor, hay una buena probabilidad de que nunca hayas visto su nombre. Esa es la situación que esta comparación pretende corregir, porque los dos modelos no son respuestas rivales a la misma pregunta. Son respuestas a dos preguntas diferentes, y solo una de ellas implica escuchar.

Cada cifra a continuación proviene del propio material de Liquid AI: la tarjeta del modelo LiquidAI/d1-omni-600M, el repositorio complementario d1-omni-600M-GGUF y la publicación de lanzamiento del 7 de octubre que anunció ambos checkpoints abiertos a la vez. El proveedor puntuó las filas de rendimiento en un índice que mantiene, en lugar de enviarlas a una clasificación pública, y la publicación afirma sin rodeos que los benchmarks dedicados a decisiones de audio son un problema abierto. Nada de esto ha sido reproducido por nadie fuera del laboratorio.

De qué están hechos 587 millones de parámetros

La cifra titular esconde una división inusual. Los parámetros totales ascienden a 587M, y no forman un único bloque: un tronco compartido de 381M con la cabeza de decisión acoplada, un codificador de visión de 94M y un codificador de audio de 112M. Cada modalidad pasa por los mismos pesos del tronco, y esa es la decisión de diseño que mantiene todo pequeño: el modelo no son tres modelos metidos en una gabardina, es un único tronco que decide con dos formas de alimentarlo.

Las piezas provienen de distintos lugares del catálogo de Liquid. El tronco desciende de LFM2.5-Encoder-350M, un codificador bidireccional, en lugar de la línea de solo decodificador de la que provenía su hermano mayor. La torre de visión es un SigLIP2 tomado de LFM2.5-VL-450M con un adaptador y actualizaciones LoRA aplicadas al backbone. La ruta de audio es un codificador FastConformer de 17 capas con su propio adaptador, afinado contra un backbone de texto congelado. La tarjeta informa un contexto de 16.384 tokens compartido entre posiciones de texto, imagen y audio en conjunto, con el texto recortado a 896 tokens cuando hay imágenes presentes, y un vocabulario de 65.536 tokens —la mitad de los 128.000 de su hermano mayor. Esa última cifra merece que le prestes atención si trabajas en un idioma que la familia solo cubre en parte.

La diferencia entre bidireccional y solo decodificador es la razón por la que los dos modelos se sienten diferentes para cualquiera que haya ejecutado ambos. El tronco con forma de codificador lee todo el estado de una vez, en ambas direcciones, antes de producir nada. El de forma de decodificador lee hacia adelante tal como lo hace un modelo de lenguaje. Ambos están entrenados para reportar respuestas a partir de una distribución con cero tokens de salida, así que ninguno escribe texto — pero la maquinaria subyacente es una clase de modelo diferente, y la brecha de precisión que se analiza a continuación es el costo visible del diseño más pequeño, con forma de codificador.

Treinta segundos de discurso, y nada con qué puntuarlo

El audio es la razón por la que existe este checkpoint. Acepta un único clip de audio de hasta 30 segundos, mono a 16 kHz, en la misma pasada hacia adelante que produce la respuesta, y es el único miembro de la familia con pesos abiertos que puede hacerlo. Para el trabajo en el dispositivo, eso no es una característica marginal. Una cámara que señala un defecto en una línea de producción es un problema de visión que el hermano de mayor tamaño ya maneja; una cámara que enruta una solicitud hablada, clasifica un enunciado o decide si quien llama está pidiendo un reembolso es un problema al que solo uno puede apuntar.

Dos restricciones se asientan sobre esa capacidad y ambas están documentadas, lo que significa que no hay excusa para tropezar con ellas en producción. Primero, una solicitud transporta imágenes o audio, nunca ambos —pasar ambos genera un ValueError en lugar de descartar uno silenciosamente, así que el fallo es ruidoso y fácil de encontrar en las pruebas. Segundo, la ruta de audio se entrenó con intercambios entre un hablante de inglés y un asistente, con los clips recortados a 30 segundos. Eso es una única geometría de hablante, una única estructura de turnos y una única distribución de acentos. Apuntarla a grabaciones de centros de llamadas o audio de campo es pedir un comportamiento que la tarjeta no declara, y es exactamente el tipo de brecha que un benchmark sacaría a la luz si existiera.

No existe ninguno. La publicación de lanzamiento califica los benchmarks dedicados a decisiones de audio como «actualmente un problema abierto» e invita a la comunidad a crear uno, lo cual es algo sincero de escribir para un laboratorio y una restricción real para cualquiera que evalúe el modelo. Liquid AI d1-omni-600M se ve obligado a justificarse sobre la base de una capacidad que todavía nadie puede medir. El proveedor también ocultó por completo las cifras de inferencia, aduciendo que el modelo es un lanzamiento de investigación temprano en desarrollo activo. Así que no hay ninguna cifra de latencia para el 600M en absoluto — ni para texto, ni para visión, ni para la ruta de audio, que es el punto central de todo.

Lo que se puede decir sin inventar nada es aritmética sobre el recuento de parámetros publicado: con la precisión float16 que la ficha recomienda para GPU, 587M de parámetros están en el orden de 1,2 GB de pesos antes de las activaciones, frente a aproximadamente 6,2 GB para el modelo hermano de 3,12B con la misma precisión. La ficha también incluye una advertencia sobre la precisión que es fácil pasar por alto y que no debería pasarse por alto: el modelo se entrenó en float32, se recomienda float16 en GPU, y bfloat16 cambió la respuesta principal en algunas filas durante las pruebas. Si tu stack de servicio usa bfloat16 de forma predeterminada, este es un modelo en el que ese valor predeterminado no es seguro.

Por qué es fácil pasar por alto la mitad más pequeña de la familia

La razón por la que un lector llega al 3B y se detiene es estructural, no accidental. El índice de documentación de Liquid AI enumera tres filas bajo modelos de decisión y no se leen igual: d1-3B y d1-omni-600M incluyen enlaces a Hugging Face y GGUF con un "No" en la columna de entrenabilidad, mientras que d1 ocupa su propia fila con las simples letras "API" donde estarían los enlaces de descarga de cualquier otro modelo. La publicación de lanzamiento llama a d1 un nombre de familia y nunca distingue el endpoint servido del checkpoint abierto. Las bibliotecas de ejecución locales entonces toman el 3B, porque es el que coincide en tamaño y número de modalidades con la entrada que quieren publicar, y el 600M no aparece en ese mismo listado en absoluto.

El resultado es una familia cuyo relato de acceso publicado, leído de un vistazo, parece un solo modelo y una sola fila de API. Lo que en realidad se ofrece son dos checkpoints abiertos con troncos distintos, modalidades distintas y una brecha de 32 puntos entre sus puntuaciones en el índice propio del proveedor, además de un endpoint alojado cuya relación con ninguno de los dos checkpoints el proveedor nunca ha confirmado. El 600M no está oculto detrás de nada. Simplemente no tiene un nombre que una búsqueda de d1 saque a la luz, y es el único de los dos que oye.

Las puntuaciones que existen, y la única columna que vale la pena leer

En Decision Index 0.2.1, el proveedor reporta 15,95 para Liquid AI d1-omni-600M frente a 48,57 para su hermano de mayor tamaño —una diferencia lo bastante grande como para que el total sea casi inútil como base para elegir. Las puntuaciones parciales son más informativas que la suma, y una de ellas es realmente sorprendente.

• Conocimiento — 8.3 frente a 23.8

• Idioma — 12.9 frente a 56.4

• Recuperación — 35.0 frente a 52.8

• Herramientas — 15,1 frente a 74,5

• Artes — 6,8 frente a 36,3

La recuperación es donde el modelo pequeño se mantiene firme: pierde menos de un tercio de la puntuación del modelo grande, mientras que en las otras cuatro columnas pierde entre el 60 y el 80 por ciento. Ese patrón coincide con aquello en lo que un codificador entrenado debería ser bueno: emparejar un estado con un contenido se acerca a aquello para lo que se construyó el tronco, y depende mucho menos de la capacidad lingüística por capas que el hermano con forma de decodificador heredó de mucho más preentrenamiento. La columna Herramientas es la historia opuesta, y una brecha de 59 puntos allí es la cifra en la que hay que fijarse si tu carga de trabajo consiste en enrutar una solicitud a la función correcta.

En siete benchmarks públicos de texto, el panorama se suaviza. El proveedor informa una media de 78,4 para el 600M frente a 82,9 para el 3B, con el modelo pequeño perdiendo por un margen estrecho en SQuAD 2.0 (74,0 frente a 85,3), PubMedQA (61,3 frente a 66,0), BoolQ (77,7 frente a 86,7) y XNLI (74,7 frente a 85,0), mientras que gana en la detección de toxicidad de Civil Comments (95,8 frente a 93,0) y en la identificación de paráfrasis de PAWS-X (79,5 frente a 76,9). El propio planteamiento de Liquid es que el 600M supera la media de 77,1 de un modelo de decisión de 2B con la cuarta parte de los parámetros. Dos suites de benchmarks ofrecen dos veredictos aparentes distintos, ambos autodeclarados, y la lectura honesta es que ninguno de los dos zanja nada sobre la ruta de audio, porque la ruta de audio no está en ninguna de las dos suites.

Donde los dos realmente se encuentran

A pesar de todas las divergencias, el modelo de programación es idéntico, y eso es lo que los hace intercambiables en un sentido concreto. Ambos responden preguntas de noul, de elección y de puntuación sobre un estado, ambos devuelven la respuesta elegida con un mapa de probabilidades y un valor de confianza entre 0 y 1, y ambos informan output_tokens: 0. El campo confidence es el que la gente malinterpreta: mide con cuánta fuerza las probabilidades favorecen una respuesta, no la probabilidad de que la respuesta sea correcta. Un 0,96 en una pregunta mal planteada es una respuesta incorrecta dada con confianza, y el campo no te avisará.

Donde se encuentran en la práctica es en una cascada. Filtra con Liquid AI d1-omni-600M —de forma económica, local y abarcando los casos de audio que ningún evaluador solo de texto puede tocar—, luego escala los elementos que coloca cerca de la mitad de su escala al checkpoint más grande para una decisión más precisa. Las reglas de escalado son la confianza y la distribución que el 600M ya devuelve, así que la lógica de enrutamiento no necesita un modelo adicional y, en una carga de trabajo con una amplia mayoría de elementos fáciles, la mayor parte del tráfico nunca llega a la segunda etapa. Esa composición funciona porque ambos modelos devuelven el mismo tipo de objeto. Dos modelos arbitrarios no lo harían.

Si esa cascada alguna vez condiciona una llamada a un modelo generativo que alquilas en lugar de ejecutar, la capa subyacente es donde la fontanería se vuelve interesante, y también es donde entramos nosotros. Enrutar una decisión a través de una cadena de modelos es exactamente la forma de problema para la que sirve una regla de enrutamiento: OrcaRouter compone varios modelos detrás de un único endpoint compatible con OpenAI, cada uno al precio de lista de su proveedor trasladado con 0 % de margen, con conmutación por error automática entre proveedores de modo que un escalado que falla en la capa del proveedor se reintenta en un respaldo en lugar de fallar la solicitud. No alojamos ningún modelo de Liquid AI —lo comprobamos antes de escribir esto—, así que nada de lo anterior es una afirmación sobre llamar a estos pesos a través de nosotros. El punto es que el modelo de decisión es la parte barata del pipeline y el modelo prestado al otro lado es la parte que se cae.

De dónde viene el archivo, si quieres ejecutarlo hoy

Para el despliegue local, el propio repositorio GGUF del proveedor para el 600M incluye Q8_0 a 407 MB y F16 y BF16 a 764 MB cada uno, sin ninguna compilación de 4 bits listada, por lo que la descarga oficial más pequeña es aproximadamente siete veces más pequeña que la compilación correspondiente del modelo más grande y aproximadamente del mismo tamaño que una fotografía de resolución media. El propio ejemplo de la tarjeta del modelo inicia un servidor de llama.cpp con flags de lote de 4096 y sugiere aumentarlos a 16384 para estados más largos, y luego consulta el mismo endpoint /v1/systemone que usa el modelo hermano más grande.

Lo único que la ruta local no te da son las cifras del recorrido de audio, porque no existen. Si piensas pasar voz por esto delante de usuarios reales, la evaluación te toca construirla: un conjunto etiquetado de clips, los mismos tres tipos de preguntas y una tasa de respuesta medida por clase. Eso no es una desestimación del modelo — un checkpoint de 587M que decide sobre un clip de voz en una sola pasada es una herramienta genuinamente distinta de un clasificador de texto acoplado a un paso de transcripción, y merece una prueba real en lugar de una basada en intuiciones.

Si esa cascada llega a condicionar una llamada a un modelo generativo que alquilas en lugar de ejecutar, OrcaRouter combina varios modelos detrás de un único endpoint compatible con OpenAI, cada uno al precio de lista de su proveedor, traspasado con un 0 % de margen.

Elegir un checkpoint omni en lugar del de solo texto también es un buen momento para observar qué ha salido ya mal en esta clase: los incidentes documentados de IA y los fallos de agentes que involucran modelos multimodales pequeños están recopilados en el OrcaRouter AI Incident Archive, donde cada entrada incluye sus propias fuentes, gravedad, grado de confianza y marca de disputa.