d1-2B: Liquid AI lanzó un modelo de decisión de 1.9B sin una publicación para anunciarlo

El repositorio de Hugging Face de LiquidAI/d1-2B se creó a las 19:30 UTC del 24 de octubre de 2026. Su hermano, d1-Omni-2B, apareció veinticuatro segundos después. Al final de esa noche ambos repositorios estaban completos —3,84 GB de safetensors BF16, unos cuarenta archivos de código personalizado de Transformers, una tabla de calibración, una API de preguntas tipadas— y nada de lo que publicó Liquid AI decía que ninguno de los dos modelos existiera. La primera frase del proveedor que nombra d1-2B llegó el 27 de octubre, dentro del lanzamiento de la familia LFM3 —la misma entrada publicada en liquid.ai y en el blog propio de Hugging Face— como una cláusula en un párrafo sobre dos modelos de decisión. Desde entonces no ha habido ninguna publicación dedicada. Así que esta no es una historia de lanzamiento, y tratarla como tal inventaría un momento de marketing que nunca ocurrió. Es una historia sobre un artefacto de modelo completo con un anuncio incompleto, y sobre las dos cosas que un lector todavía puede hacer con eso: leer el repositorio y mantener los números del proveedor a raya hasta que alguien fuera del laboratorio los ponga a prueba.

Los cinco días entre las pesas y la sentencia

La {{1}}familia d1{{/1}} se ha lanzado dos veces, y ninguno de los dos lanzamientos se parecía a este. El 7 de octubre, Liquid AI publicó «{{2}}Open d1: modelos de decisión en el borde para texto, visión y audio{{/2}}», que presentaba {{3}}d1-3B{{/3}} con 3,12 mil millones de parámetros y {{4}}d1-omni-600M{{/4}} con 587 millones, junto con una afirmación destacada, una tabla de referencia, cifras de latencia y una entrada de blog que ha permanecido publicada desde entonces. Esa entrada no contiene ningún modelo de 2B.

La línea 2B avanzó según un calendario distinto. El checkpoint base LFM3-Omni-2B apareció el 21 de octubre. El 24 de octubre, a las 19:30 y 19:30:24 UTC, Liquid AI creó los repositorios d1-2B y d1-Omni-2B. Luego, el 27 de octubre, la publicación de lanzamiento de LFM3 denominó al par como «modelos de decisión especializados a partir de los modelos de visión y omni» —una descripción, no un anuncio. Ese mismo día, aparecieron cuatro repositorios derivados de d1-2B: compilaciones MLX en fp16, 8 bits y 4 bits, además de una exportación ONNX. Tampoco nadie escribió una publicación sobre ellos.

Esto importa por una razón práctica. Un anuncio es donde un proveedor se compromete con su posicionamiento: para qué sirve el modelo, cuánto cuesta, qué entorno de ejecución tiene como objetivo y qué no hace. La ficha hace parte de ese trabajo, y lo hace excepcionalmente bien. Pero los vacíos que deja la publicación que falta son reales y concretos, y se enumeran al final de este artículo en lugar de disimularse.

Lo que el repositorio realmente te dirá

Si se deja de lado el encuadre, el checkpoint es un clasificador multimodal pequeño y densamente especificado que se niega a generar texto. Cada llamada devuelve respuestas tipadas con probabilidades asociadas y output_tokens: 0. La ficha lo dice sin rodeos: d1-2B «no es un modelo de chat».

• Parámetros — 1,92B, distribuido como un único archivo safetensors BF16 de 3,84 GB.

• Base — LFM3-VL-2B, sobre la arquitectura LFM3: 24 capas, de las cuales 13 son convoluciones cortas con compuerta, 5 son atención de ventana deslizante y 6 son atención global.

• Contexto — 128K tokens y un vocabulario de 128.000 tokens, cuatro veces la ventana de 32.768 de d1-3B.

• Entrada — un estado que puede ser texto o cualquier valor JSON, imágenes o un vídeo, y cualquier número de preguntas con nombre, todo en una sola lista de medios. El vídeo es la capacidad que d1-3B no enumera.

• Salida — sí/no, una elección entre opciones con nombre, una puntuación ordenada, un valor o una fecha leídos de un documento con su extensión, un número con un intervalo p10–p90, un cuadro delimitador, o cada instancia de un objeto con un recuento. Cada uno conlleva una probabilidad.

• Idiomas — dieciséis: inglés, árabe, chino, francés, alemán, italiano, japonés, coreano, portugués, español, vietnamita, tailandés, indonesio, hindi, ruso, polaco.

• Licencia — LFM Open License v1.0. El uso comercial se concede por debajo de 10.000.000 USD de ingresos anuales; el texto de la licencia define esa cifra como umbral, y los derechos para el uso comercial por encima de ella están condicionados a no superarlo.

• Velocidad — 5,7 ms para una sola decisión en una H100 PCIe y 3,8 ms en una AMD MI325X, con 1.132 y 1.699 decisiones por segundo respectivamente cuando se agrupan 64 estados en una sola llamada. En un Apple M5 Pro, la cifra para una sola pregunta es de 18,6 ms.

La afirmación que merece debate: supera al modelo al que reemplazó

La ficha de Liquid AI hace una afirmación comparativa sin matices: d1-2B "lidera los modelos d1 abiertos en promedio y en nuestro conjunto de más de cien benchmarks de decisión, por delante de d1-3B con menos de dos tercios de su tamaño". Es una afirmación contundente de un modelo de 1,92B sobre uno de 3,12B, y es verificable, porque la ficha incluye los cuatro modelos d1 abiertos en una sola tabla, puntuados con los mismos ítems y el mismo sistema de puntuación.

El número principal es 51.1 frente a 49.0 en la suite pública Decision Index, versión 0.3 — una ventaja de 2.1 puntos. Antes de que alguien lo interprete como una victoria limpia, hay dos advertencias que deben acompañarlo. Primero, la propia ficha de d1-3B reporta 48.57 en Decision Index 0.2.1, y la diferencia entre 48.57 y 49.0 se debe a la versión del índice, no a una mejora del modelo; la ficha de d1-2B indica que los cuatro modelos se volvieron a puntuar con los mismos ítems y que, por lo tanto, algunas de las cifras de d1-3B difieren de las de su propia ficha. Segundo, la suite pública es solo una fracción de lo que determina la clasificación pública: el evaluador independiente que la reconstruyó describe 37 benchmarks públicos ponderados al 20% de la puntuación, y el resto proviene de pruebas privadas que solo ejecutan los mantenedores.

Lo que hace creíble al 49.0 como cifra —aunque d1-2B en sí no tenga ninguna verificación externa— es que alguien ya ha reproducido el 3B en esta versión exacta. Efraín Garay ejecutó d1-3B sobre una muestra estratificada de 6.000 solicitudes de Decision Index 0.3 a mediados de octubre y obtuvo 49.11, frente al 49.04 del propio Liquid en las mismas filas y 48.99 en el conjunto completo. Es una reproducción dentro de una décima de punto. No valida el 51.1 de d1-2B, que ningún tercero ha ejecutado, pero sí valida el método de puntuación que hay detrás de la tabla en la que se encuentra 51.1.

Donde el modelo más pequeño no lleva ventaja

«Lidera en la mayoría de los benchmarks individuales» está haciendo un trabajo silencioso en esa frase. En la tabla de la misma ejecución, d1-3B sigue ganando en tres de las veinte y pico filas que importan para una decisión de despliegue:

• Decisiones rápidas — 59,3 para el 3B frente a 58,8, la única prueba de decisiones orientada a la velocidad en la que el modelo más grande aventaja ligeramente.

• Decisiones tipadas — 65,0 frente a 61,3, una diferencia de 3,7 puntos y el argumento más claro a favor del modelo anterior cuando la salida tiene que ser un valor tipado en lugar de una etiqueta.

• AI2D — 79.9 frente a 76.7, el benchmark de lectura de diagramas, donde una torre de visión más grande todavía aporta precisión.

En todos los demás casos, el orden se invierte, a veces drásticamente. VisualWebBench es de 96,2 para d1-2B frente a 71,4 para d1-3B. ImajevBench v2.0-lite es de 75,5 frente a 64,0. MMMU-Pro es de 26,4 frente a 18,5; ambos son lo bastante bajos como para que no se deba confiar en ninguno de los dos modelos para razonamiento multimodal difícil, lo cual merece decirse claramente en lugar de presentar la diferencia de 7,9 puntos como una victoria. Los promedios de visión son 70,2 y 65,4.

Tres ausencias que la tarjeta no puede suplir

El anuncio que falta se manifiesta como artefactos faltantes. Ninguno de estos es un defecto del modelo; cada uno es una razón por la que el modelo es más difícil de adoptar hoy de lo que sugiere su línea de referencia.

• Sin GGUF.d1-3B y d1-omni-600M obtuvieron repositorios GGUF el 6 de octubre, un día después de que se publicaran sus pesos, y d1-3B continuó con una compilación de pesos-activaciones de 8 bits y cuatro variantes MLX. d1-2B tiene compilaciones MLX y ONNX desde el 27 de octubre, pero no GGUF, así que no hay ninguna ruta de llama.cpp publicada para la cabeza de decisión, aunque el modelo base LFM3-VL-2B obtuvo su propio GGUF el 19 de octubre. Si tu stack de borde es llama.cpp, esta es toda la historia.

• Sin precio y sin endpoint. La ficha no indica ninguna API alojada, ningún precio por token ni ningún proveedor de inferencia. Eso no es raro en un lanzamiento de pesos abiertos, pero significa que la única forma de usar d1-2B es ejecutarlo, y la sección de despliegue de la ficha termina en un fragmento de Transformers.

• Sin benchmark independiente. Al 28 de octubre, el repositorio muestra 44 descargas y 13 me gusta. La evaluación independiente de modelos de decisión disponible cubre d1-3B y d1-omni-600M, no este modelo. Todas las cifras de rendimiento anteriores son propias de Liquid AI.

También hay un límite que la propia ficha indica sobre sí misma: las respuestas «se vuelven menos fiables pasados unos 64K tokens de estado», la mitad de la ventana anunciada de 128K, y las estimaciones son fiables en recuentos y puntuaciones, pero menos en cantidades libres. Un modelo cuya propia ficha te dice dónde se degrada es más útil que uno que no lo hace, pero el titular de 128K debería leerse como una cifra de capacidad, no como un rango de trabajo.

Así es realmente un primer despliegue

La ruta práctica es Transformers 5.19 o superior con trust_remote_code=True, bf16 en GPU, y la system_one o system_one_batch llamada. No hay parámetros de muestreo porque no hay muestreo. El único parámetro de ajuste que importa es set_size, que por defecto es el tamaño entrenado de 16; aumentarlo gana velocidad y cuesta precisión de texto.

La propia recomendación de la tarjeta es el paso que más equipos se saltan: calibra tu umbral de decisión con datos de tu propio uso. Una probabilidad de 0,62 no significa nada de forma aislada. Si estás enrutando tickets de soporte o marcando documentos, el umbral que separa "escalar" de "gestionar automáticamente" tiene que ajustarse con tu propia muestra etiquetada, porque la calibración del proveedor se ajustó con la suya.

La forma a la que esto se ajusta es un paso de pipeline, no un asistente: triaje, moderación, clasificación de intenciones, extracción de formularios, reranking, inspección visual. Esos son exactamente los lugares donde un pipeline ya llama a varios modelos, y donde los pasos generativos que rodean la decisión suelen venir de una API alojada. OrcaRouter no sirve hoy ningún modelo de Liquid AI —incluido este—, así que ejecutar d1-2B significa ejecutarlo tú mismo. Para lo que sí sirve un router es para el resto de la cadena: una clave compatible con OpenAI para más de 200 modelos alojados, un DSL de enrutamiento que compone pasos en una sola llamada y conmutación por error automática cuando un proveedor se cae, de modo que el nodo de decisión en tu GPU no quede a merced del nodo generativo que tiene al lado.

¿Qué cambiaría esta historia?

Cuatro cosas, en orden descendente según cuánto importarían. Un GGUF pondría a d1-2B en la misma base de ejecución que sus hermanos y haría real la propuesta para el edge. Una publicación dedicada diría a los compradores para qué cree Liquid AI que sirve el modelo, más allá de la lista de pasos del pipeline de la ficha. Una ejecución independiente —idealmente la misma muestra de 6.000 filas que reprodujo d1-3B— convertiría 51.1 de una afirmación del proveedor en una medición. Y un precio de alojamiento permitiría siquiera responder a la cuestión de construir frente a comprar.

Hasta entonces, el resumen honesto es limitado y útil: existe un modelo de decisión de 1.92B, su repositorio es lo suficientemente completo como para evaluarlo, su ventaja en benchmarks sobre el 3B es real en la propia tabla de la misma ejecución del proveedor y no está verificada en ningún otro lado, y la falta de anuncio lo ha dejado sin el empaquetado —entorno de ejecución, endpoint, precio— que la mayoría de los equipos necesita antes de poner un modelo en una canalización. Si ya usas Transformers y quieres un clasificador con ventana de 128K y entrada de video, vale la pena dedicarle una tarde. Si necesitas llama.cpp o un endpoint gestionado, espera.