Liquid AI d1 vs Liquid AI d1-3B: lo que la biblioteca de Ollama llama un modelo y el proveedor llama dos

Hay dos formas de nombrar el mismo conjunto de pesos, y Liquid AI d1 y Liquid AI d1-3B ilustran la diferencia mejor que cualquier comparación de parámetros. Si quitas un guion y un sufijo de tamaño del segundo nombre, obtienes el primero, por lo que resulta tentador tratar la cadena más corta como un apodo. Los dos catálogos que en realidad incluyen estos modelos no coinciden con esa interpretación. El índice de documentación de Liquid AI mantiene d1 en su propia fila con las letras "API" donde van los enlaces de descarga, y mantiene d1-3B y d1-omni-600M en un par de filas separadas con enlaces funcionales de Hugging Face y GGUF y un "No" en la columna de entrenable. Ollama, cuya entrada de biblioteca es la razón por la que vale la pena escribir sobre este par, lo reduce todo a una sola página llamada d1, la describe en una sola línea como "un modelo de decisión de 3B de Liquid AI, construido sobre LFM2.5-VL-3B," y ofrece exactamente tres etiquetas debajo. Comparar Liquid AI d1 con Liquid AI d1-3B no es, por lo tanto, una comparación entre un endpoint alojado y un checkpoint abierto, y tampoco es una comparación entre dos checkpoints. Es una comparación entre un endpoint alojado y el checkpoint abierto que el ecosistema de runtimes locales ha decidido que es d1 cuando pronuncias la palabra sin más. La mayor parte de lo que sigue trata de cuál de esas interpretaciones depende realmente tu despliegue.

Una nota sobre cómo se obtienen las cifras a continuación, ya que la honestidad importa más que su formato. Todo lo numérico que aparece aquí proviene de los propios informes de Liquid AI, en las tarjetas de modelo o en la publicación de lanzamiento del 7 de octubre. Las filas de Decision Index fueron puntuadas por el proveedor con el evaluador oficial en lugar de enviarse para una clasificación pública, y ningún tercero ha reproducido de forma independiente ningún resultado de d1 que hayamos podido encontrar. Cuando un número es el resultado de operaciones aritméticas sobre una cifra publicada en lugar de una medición, así se indica.

De dónde vienen los dos nombres

El nombre más corto es anterior. La publicación del 5 de octubre de Liquid AI presentó el modelo como Liquid AI d1 — "nuestro primer modelo de decisión", multimodal en ese lanzamiento, que responde preguntas escritas sobre un estado de texto, imágenes o ambos, en una sola pasada hacia delante con cero tokens de salida. Esa publicación cita un precio alojado de $0,04 por millón de tokens de entrada, factura solo los tokens de entrada y señala que las imágenes se cobran como texto a 1,5 tokens por parche de 32×32, por lo que una imagen de 1024×1024 cuesta 1.536 tokens. También indica que la latencia de decisión de texto es de 200–300 ms. Esas son cifras de servicio alojado, y la publicación deja claro que el entorno de ejecución detrás de ellas es el propio endpoint de decisiones del proveedor en api.liquid.ai/decisions/v1/systemone.

El nombre más largo aparece en la publicación del 7 de octubre y en Hugging Face, y es el que lleva el detalle reproducible: 3,12 mil millones de parámetros, un contexto de 32.768 tokens, un vocabulario de 128.000 tokens, dieciséis idiomas documentados, un codificador de visión SigLIP2 NaFlex de 400M optimizado para formas, y la cadena base LFM2.5-2.6B-Base → LFM2.5-VL-3B → d1-3B. Esa ficha también declara claramente que el modelo no es un modelo de chat y no escribe texto. Este es el checkpoint sobre el que está construido todo el ecosistema local: el repositorio GGUF incluye Q4_K_M con 1,67 GB, Q8_0 con 2,87 GB, y F16 y BF16 con 5,4 GB cada uno.

Lo que ningún documento del proveedor dice en voz alta es que Liquid AI d1 y Liquid AI d1-3B son los mismos pesos. El índice de documentación les asigna filas separadas. La publicación de lanzamiento llama a d1 una familia, no un checkpoint. Los artículos de terceros han notado la brecha y señalado que el proveedor no ha confirmado la identificación. Así que la afirmación honesta es breve: los números con los que se publican ambos nombres no entran en conflicto en ningún lugar que podamos encontrar, el lanzamiento de la familia y el endpoint servido se anunciaron con dos días de diferencia con una descripción compatible, y el proveedor no ha dicho que sean el mismo modelo. Trata la equivalencia como una suposición de trabajo razonable y no como un hecho que el proveedor haya respaldado con su nombre.

Lo que realmente cambia la compilación local

La entrada de Ollama no es un relanzamiento ni un nuevo checkpoint. Es una decisión de empaquetado, y el empaquetado impone tres restricciones que la propia documentación del proveedor no menciona en absoluto. La primera es la lista de etiquetas: d1:latest, d1:3b y d1:3b-q8_0, tres etiquetas que designan una única cuantización. El repositorio GGUF que publica Liquid contiene cuatro precisiones, y el Q4_K_M de 1,67 GB —el que la mayoría de la gente elegiría para un portátil— no está entre las etiquetas de Ollama. Lo que puedes descargar es el Q8_0 de 2,87 GB y lo que ocupe una vez expandido en el almacén local; la página de la biblioteca indica que la descarga es de 3,7 GB.

El segundo es el contrato de solicitud. Ollama atiende estos modelos en /v1/systemone, recibe un state más un objeto questions y devuelve respuestas tipadas con output_tokens: 0. Esa es la misma estructura que usa el endpoint alojado del proveedor, lo que hace que el cambio entre local y alojado sea un cambio de configuración en lugar de una reescritura. La tercera restricción está en la documentación del endpoint de Ollama, no en la página del modelo, y es más estricta que la de un modelo generativo: las solicitudes deben caber en 64 KiB sin imágenes y 32 MiB con ellas, no se admite el streaming, se rechazan los modelos alojados en la nube, y las imágenes deben ser PNG, JPEG o WebP en base64 en el cuerpo de la solicitud — se rechazan las URL remotas. Las imágenes las comparten todas las preguntas de una solicitud, así que una imagen que quieras que solo una respuesta tenga en cuenta necesita su propia llamada. La entrada nunca se trunca, lo que significa que un state de tamaño excesivo devuelve un error en lugar de recortarse silenciosamente. Ese es el mejor modo de fallo, y sigue siendo un modo de fallo que tu cliente tiene que gestionar.

Quedan dos detalles de documentación sin resolver y vale la pena conocerlos antes de que reportes un error. La referencia del endpoint de Ollama describe el tipo de pregunta de opción como que acepta de 2 a 255 claves de opción, mientras que su página de capacidades de modelos de decisión indica de 2 a 26; uno de los dos está desactualizado. Y la página de capacidades enumera sus modelos compatibles como Nimble, Tev1, Clef y Clef Flash, sin mencionar d1, aunque el propio readme del paquete d1 documenta la compatibilidad con /v1/systemone y --ask, y el paquete requiere Ollama 0.40.4, mientras que el mínimo documentado del propio endpoint es 0.35.0. Lee el requisito de versión en el paquete, no el de la guía.

Los números, y bajo qué nombre se publicaron

Esta es la parte del emparejamiento que es más fácil de equivocar, porque ambos nombres se publican con cifras de rendimiento y las cifras no están organizadas como uno esperaría.

• Índice de decisión 0.2.1 — 48,57, publicado bajo Liquid AI d1-3B. Liquid lo describe como la mejor puntuación para un modelo de decisión con menos de 10B de parámetros y lo sitúa por delante de un modelo 35B-A3B con 47,11. • Latencia de decisión de texto — 200–300 ms, publicada bajo Liquid AI d1 en la publicación de la API alojada. No hay una cifra equivalente asociada al nombre propio del checkpoint abierto. • Latencia de una sola pregunta en hardware local — 8 ms en una RTX 4090, 16 ms en una Jetson AGX Thor, 26 ms en una Jetson AGX Orin de 64 GB, 50 ms en una Orin Nano, 30 ms en un Apple M5 Pro. Publicada bajo Liquid AI d1-3B. • Rendimiento — 475 decisiones por segundo en la RTX 4090 y 1.106 por segundo en una AMD MI325X con las preguntas agrupadas en lotes. Publicado bajo Liquid AI d1-3B. • Visión — una media de 74,1 en once pruebas de referencia públicas de imágenes, frente a 73,9 del modelo base LFM2.5-VL-3B del que se construyó. Publicada bajo Liquid AI d1-3B. • Ablación de imágenes — el mismo conjunto de preguntas respondido con las imágenes eliminadas obtiene 45,1, que es la medida propia del proveedor de lo que aporta la ruta de visión. Publicada bajo Liquid AI d1-3B.

De esa lista se desprenden dos problemas, y ninguno de los dos es fatal, que es exactamente por lo que se pasan por alto. La cifra alojada y la cifra local difieren en un factor de 25 a 37 —200–300 ms frente a 8 ms—, y se midieron sobre elementos que el proveedor no describe en términos comparables. Interpretar la diferencia como «lo local es más rápido» no está respaldado, porque la cifra alojada es de extremo a extremo a través de una API y los 8 ms son una pasada hacia adelante en una GPU con nombre. No son la misma medición, y el proveedor nunca afirma que lo sean.

El segundo problema es la fila de visión. Una mejora de 0,2 puntos sobre el modelo base en once benchmarks de imágenes se sitúa dentro del ruido de la mayoría de los informes de benchmarks, así que, independientemente de lo que aporte la cabeza de decisión, no se traduce en un codificador de imágenes materialmente mejor. La fila de ablación parece mucho más impresionante en la dirección opuesta —una variación de aproximadamente 29 puntos cuando se añaden imágenes—, pero compara dos conjuntos de preguntas diferentes en lugar de dos versiones de uno mismo, algo que Liquid señala en la propia publicación. Ambas filas son útiles. Ninguna respalda una afirmación contundente sobre la calidad de las decisiones visuales, y ningún tercero ha ejecutado ninguna de las dos.

Donde los dos nombres divergen en la práctica

Para un comprador, la distinción se reduce a cuatro preguntas, y las respuestas no apuntan todas en la misma dirección.

• Estructura de costes — Liquid AI d1 se factura por token de entrada, a la tarifa publicada por el proveedor, sin tokens de salida que pagar. Liquid AI d1-3B es una descarga de 2,87 GB en el empaquetado de Ollama, o de 1,67 GB desde el repositorio GGUF del proveedor, sin ningún medidor por llamada. • Latencia, medible — la ruta alojada declara 200–300 ms por decisión de texto. Los 8 ms publicados de la ruta local corresponden a un forward pass en una RTX 4090 con el modelo en caliente, que es un número real y no un ida y vuelta de solicitud. • Ruta de los datos — la ruta alojada envía el estado al proveedor. La ruta local lo mantiene en la máquina, lo que, para un ticket de soporte, una nota médica o una fotografía, suele ser el argumento que zanja la discusión. • Fijación de versión — Liquid AI d1 detrás de un endpoint es lo que el proveedor esté sirviendo hoy. Liquid AI d1-3B en Ollama es un paquete fijo que tú controlas, y la contrapartida es que las actualizaciones corren de tu cuenta.

La incómoda realidad que subyace a los cuatro es que el checkpoint abierto es un hermano del modelo alojado, y no un sustituto de este, y el proveedor no ha dicho lo contrario. La tarjeta del modelo correspondiente al checkpoint abierto lo recomienda para enrutamiento y triaje, moderación, clasificación de intenciones, comprobaciones de extracción, reordenación, LLM como juez y guardarraíles, y lo describe como postentrenado sobre LFM2.5-VL-3B para decisiones calibradas de una sola pasada. La publicación del modelo alojado describe el mismo conjunto de tareas con otras palabras y menciona el precio del modelo alojado. Si ambos son un solo modelo, la versión local es una copia gratuita de un producto alojado, lo cual sería algo inusual que un laboratorio lanzara sin decirlo. Si son dos ajustes finos de una base común, no debería suponerse que las cifras publicadas se transfieran en ninguna de las dos direcciones. La segunda explicación exige menos del proveedor y encaja con la evidencia de la que disponemos.

Ejecutar ambas mitades de la decisión sin ejecutar dos stacks

Sea cual sea el nombre por el que te decidas, el pipeline que lo rodea tiende a verse igual. Una cola de soporte recibe una pregunta de elección sobre un equipo de destino, una pregunta booleana sobre si se está solicitando un reembolso y una pregunta de puntuación para la urgencia: un estado, tres respuestas, una pasada. Donde los dos nombres realmente divergen es en el punto en que la decisión condiciona una llamada a un modelo generativo que alquilas en lugar de ejecutar. Esa llamada es un problema distinto con un perfil de fallo distinto, y es la parte del pipeline en la que d1 acertar importa menos: una respuesta de enrutamiento con una probabilidad de 0,98 seguida de un 502 del modelo al que enrutaste es, de todos modos, una solicitud fallida.

No alojamos ningún modelo de Liquid AI —consultamos nuestro propio catálogo antes de escribir esto—, así que nada de lo que aquí se dice es una afirmación sobre invocar estos pesos a través de nosotros. Lo que hacemos es la capa que está al otro lado de la decisión: una única clave compatible con OpenAI para los modelos a los que se ramifica una solicitud triada, al precio de lista de cada proveedor, trasladado con un 0 % de margen, de modo que una rebaja de precio de un proveedor te llegue el mismo día en que se aplica y no en la renovación del contrato, con conmutación por error automática entre proveedores, para que una solicitud triada sobreviva a que se caiga el modelo al que la dirigiste. Si estás conectando un modelo de decisión a un pipeline por primera vez, esa es la mitad que vale la pena volver aburrida.

Qué nombre usar, según la situación

Si quieres probar el modelo esta semana sin un entorno de Python que merezca la pena mantener, usa el nombre que utiliza el runtime local. Descarga Liquid AI d1 de la biblioteca, acepta Q8_0 y 3,7 GB, y toma el límite de solicitud de 64 KiB y la regla de no streaming como restricciones de diseño en lugar de molestias. Obtienes un endpoint real, respuestas tipadas reales y ningún medidor por llamada desde el primer día.

Si necesitas una huella menor que Q8_0, el nombre que debes usar es Liquid AI d1-3B, porque la compilación Q4_K_M de 1.67 GB está en el repositorio GGUF del proveedor y no en la entrada de la biblioteca. Ese único hecho es la diferencia más práctica entre los dos nombres hoy, y es el que más probablemente pase por alto cualquiera que lea la página de la biblioteca y se detenga ahí.

Si vas a poner esto delante de usuarios que pagan y necesitas primero pruebas de precisión, ninguno de los dos nombres te sirve todavía. No hay ninguna evaluación independiente de ningún modelo d1 que hayamos podido encontrar, las filas del Decision Index las puntuó el propio proveedor, y el proveedor no ha publicado ningún benchmark de decisiones de audio en absoluto. Lo que sí puedes hacer es instrumentar el valor de confianza que el modelo ya devuelve —de 0 a 1, que refleja con cuánta fuerza favorecen las probabilidades una respuesta, no la probabilidad de que esa respuesta sea correcta— y averiguar con tu propio tráfico dónde no está seguro el sistema. Esa medición vale más que cualquiera de las diapositivas anteriores, y lleva un día.

El modelo de decisión es la mitad barata del pipeline. El modelo generativo al que enruta es la mitad que necesita un contrato: una clave compatible con OpenAI porta los modelos a los que se ramifica una solicitud clasificada, cada uno al precio de lista de su proveedor, transferido con un 0% de margen.

Reducir el tamaño de un checkpoint destilado frente a su propia versión completa también es un buen momento para revisar el historial: los incidentes de IA y fallos de agentes documentados en torno a modelos Liquid pequeños están recopilados en el OrcaRouter AI Incident Archive, donde cada entrada incluye sus propias fuentes, gravedad, grado de confianza e indicador de disputa.