d1-2B vs Liquid AI d1-3B: el modelo más pequeño gana en la tabla y pierde en el despliegue

Cuatro preguntas deciden este enfrentamiento, y ninguna de ellas es «qué modelo es mejor». ¿El estado incluye video? ¿Supera los 32K tokens? ¿Necesitas ejecutarlo con llama.cpp? ¿Puedes permitirte ser la primera persona en probarlo? d1-2B es el modelo de decisión de 1,92B de Liquid AI, construido sobre LFM3-VL-2B y con una puntuación de 51,1 en la tabla Decision Index del proveedor. Liquid AI d1-3B es el modelo de 3,12B lanzado el 7 de octubre, construido sobre LFM2.5-VL-3B y con una puntuación de 49,0 en esa misma tabla. El modelo más nuevo y más pequeño lidera en promedio. Aun así, pierde en tres de las filas que una implementación realmente activa, y es el de los dos que no tiene una vía para llama.cpp ni resultados de pruebas independientes. Esta página está organizada en torno a esas cuatro preguntas y no en torno al ranking, porque el ranking no responde a ninguna de ellas.

La respuesta breve, según la carga de trabajo

• Triaje solo de texto a gran escala — d1-2B, gracias a 1.132 decisiones por segundo para 64 estados por lotes y 3,84 GB de pesos. La ventaja del 3B en Decisiones tipadas es irrelevante cuando la salida es una etiqueta.

• Lectura de diagramas y gráficos — Liquid AI d1-3B. Gana en AI2D por 79,9 a 76,7, y es el modelo que tiene una ejecución independiente que lo respalda.

• Documentos largos, formularios largos, transcripciones de llamadas largas — d1-2B. Su ventana es de 128K tokens frente a 32.768, y la ficha reconoce con honestidad que la fiabilidad decae a partir de unos 64K, lo que aun así deja el doble de la capacidad total del 3B.

• Equipos edge que ejecutan llama.cpp: Liquid AI d1-3B, por defecto más que por mérito. Tiene un repositorio GGUF y una build cuantizada de activación de pesos; d1-2B no tiene ninguna de las dos.

• Cualquier situación en la que una decisión equivocada sea costosa y no se haya probado — ninguno de los dos, hasta que hayas ejecutado ambos con tus propios datos. Solo uno de ellos ha sido ejecutado por un tercero.

Misma familia, una generación de diferencia.

Los dos modelos no son hermanos en el sentido que sugieren los nombres. Liquid AI d1-3B desciende de LFM2.5-VL-3B, que a su vez deriva de LFM2.5-2.6B-Base, y lleva un codificador de visión SigLIP2 NaFlex de 400M. d1-2B desciende de LFM3-VL-2B, la siguiente familia, sobre una columna vertebral de 24 capas repartidas entre 13 convoluciones cortas con compuertas, 5 capas de atención de ventana deslizante y 6 capas de atención global. Esa brecha generacional es el origen de la inversión en los benchmarks: la arquitectura más nueva hace más por parámetro, así que el checkpoint más pequeño puede superar al más grande en la mayoría de las filas.

• Parámetros — 1,92B para d1-2B frente a 3,12B para Liquid AI d1-3B.

• Descargar — 3,84 GB frente a 6,25 GB de safetensors BF16, ambos en un solo archivo.

• Contexto — 128K tokens vs 32,768.

• Vocabulario — 128.000 tokens frente al vocabulario de LFM2.5.

• Entradas — texto o JSON, imágenes o vídeo, además de preguntas con nombre, para el d1-2B; texto o JSON más imágenes para el 3B. El vídeo es la diferencia de capacidades más clara entre ambos.

• Idiomas — dieciséis cada uno, el mismo conjunto.

• Licencia — LFM Open License v1.0 para ambas, con el uso comercial condicionado a mantenerse por debajo de $10,000,000 de ingresos anuales. No hay ninguna razón de licencia para preferir ninguna de las dos.

• Lanzamiento — los pesos de d1-3B se publicaron el 5 de octubre y se anunciaron el 7 de octubre. El repositorio de d1-2B se creó el 24 de octubre y nunca ha tenido una publicación propia; la única frase del proveedor que lo menciona está en el lanzamiento de LFM3 del 27 de octubre.

Un detalle de la documentación merece leerse como una señal más que como un hecho: la página de documentación de modelos de decisión de Liquid AI ahora enumera d1-2B, d1-omni-2B, d1-omni-600M, d1.1 y d1-ultra. Ya no enumera d1-3B. El 3B no ha sido retirado —su repositorio y sus compilaciones GGUF y MLX siguen activos—, pero el índice propio del proveedor ha trasladado el espacio de pesos abiertos al 2B.

El marcador, leído fila por fila

Todas las cifras siguientes proceden de la tabla de benchmark de la ficha del modelo d1-2B, que puntúa cuatro modelos d1 abiertos con los mismos ítems y el mismo evaluador. Eso importa porque la propia ficha de Liquid AI d1-3B informa 48,57 en Decision Index 0.2.1, mientras que esta tabla informa 49,0 en la versión 0.3; la diferencia se debe a la edición del índice, no a un cambio de modelo, y la ficha lo indica en una nota. Comparar directamente las dos fichas —48,57 frente a 51,1— equivaldría a restar entre dos pruebas diferentes. Comparar dentro de esta tabla es legítimo, y eso es lo que hace el resto de esta sección.

• Decision Index public suite v0.3 — 51,1 frente a 49,0.

• DecisionBench (Hanno Labs) v1 — 77,1 frente a 73,1.

• Decision Bench (decisionbench.ai) v4 — 85,2 frente a 83,6.

• JevBench v1.4.1 — 77,9 frente a 76,2.

• ImajevBench v2.0-lite — 75,5 vs 64,0, la mayor brecha del lado de la decisión.

• WorkflowEvals — 81,6 frente a 74,4.

• El tablero interno de Liquid AI — 63,2 frente a 58,8.

• Promedio de visión — 70,2 frente a 65,4 en dieciocho benchmarks.

Todas las suites de decisiones con nombre de esa tabla van al 2B, que es lo que significa la publicación de lanzamiento de LFM3 cuando llama al d1-2B un reemplazo del d1-3B "con un tercio menos de parámetros" y puntuaciones más altas "en las cuatro suites de decisiones". La afirmación es precisa tal como está escrita —y más limitada que "supera al 3B", que es la razón por la que existe el párrafo siguiente. Luego, las tres filas que van en sentido contrario. Fast Decisions es 58,8 para d1-2B frente a 59,3 para el 3B. Typed Decisions es 61,3 frente a 65,0. AI2D es 76,7 frente a 79,9. Ninguna de esas diferencias es grande, y dos de las tres están dentro de un punto, pero son las filas en las que los 1,2B parámetros adicionales todavía aportan algo medible: decisiones orientadas a la velocidad, extracción tipada y lectura de diagramas. Si los trabajos de tu pipeline son extracción tipada de formularios, el 3B no es la opción obsoleta que implica la página de documentación.

Latencia: las dos cifras destacadas no son comparables

Liquid AI declara 5,7 ms por decisión para d1-2B y 8 ms para Liquid AI d1-3B, y no se trata de la misma medición. La cifra del 2B corresponde a una H100 PCIe; la del 3B, a una RTX 4090. Una diferencia de 2,3 ms entre dos GPU distintas no te dice nada sobre qué modelo es más rápido en tu hardware, y repetirla como comparación sería exactamente el tipo de blanqueo de cifras que este blog existe para evitar.

Hay una máquina que ambas tarjetas reportan. En un Apple M5 Pro, d1-2B tarda 18,6 ms por pregunta y el 3B tarda 30 ms — una reducción del 38 % en el mismo silicio. Esa es la comparación de velocidad honesta, y apunta en la misma dirección que sugiere la diferencia de tamaño. En procesamiento por lotes, d1-2B maneja 1.132 decisiones por segundo en una H100 PCIe y 1.699 por segundo en una MI325X con 64 estados en una sola llamada; la tarjeta del 3B reporta 475 por segundo en una RTX 4090 y 1.106 por segundo en una MI325X. La fila de la MI325X es la que ambas tarjetas comparten, y ahí el 2B va por delante por aproximadamente un 54 %.

La única prueba independiente que existe ejecutó el 3B

A mediados de octubre, Efraín Garay ejecutó ocho modelos de decisión contra Decision Index 0.3 y tres tareas con datos reales, y publicó los resultados junto con el código. Dos hallazgos inciden en esta comparación.

El primero es tranquilizador para el marcador. Reconstruyó la suite pública a partir de su kit, comprobó que los archivos descargados coincidían con los oficiales, tomó una muestra de 6.000 solicitudes y puntuó a Liquid AI d1-3B con 49,11 — frente al 49,04 de la propia Liquid en las mismas filas y 48,99 en la suite completa. Es la evidencia más sólida disponible de que los números de la v0.3 de la tabla anterior se están calculando correctamente. Es evidencia sobre el 3B, no sobre el d1-2B, que no probó.

La segunda es una advertencia sobre lo que mide un índice. En un banco sintético de fraudes con tarjeta de 10.000 pagos, Liquid AI d1-3B obtuvo un AUC de 0,314 —por debajo del azar—, clasificando las anomalías como menos sospechosas que los pagos normales, porque las ráfagas de pagos consecutivos quedaron en una probabilidad mediana de 0,41 frente a 0,56 de un pago normal. El modelo quedó segundo en el índice público y último en esa tarea. La lección se traslada directamente: el 51,1 de d1-2B es una puntuación en una suite de decisiones generales, y nadie ha demostrado que prediga el rendimiento en tu decisión específica. El proveedor lo dice en su propia ficha, en la instrucción de calibrar los umbrales con tus propios datos.

Lo que realmente puedes ejecutar hoy

Aquí es donde la comparación deja de estar reñida. Liquid AI d1-3B ha tenido un repositorio GGUF desde el 6 de octubre, una compilación con cuantización de pesos y activaciones de 8 bits desde el 7 de octubre y cuatro variantes MLX desde el 12 de octubre. d1-2B recibió tres compilaciones MLX y una exportación ONNX el 27 de octubre, y nada más. No hay GGUF de d1-2B, ni cuantización más allá de la de 4 y 8 bits de MLX y, por lo tanto, ninguna ruta publicada de llama.cpp para la cabeza de decisión, aunque el modelo base, LFM3-VL-2B, ha tenido su propio GGUF desde el 19 de octubre.

En un despliegue con Transformers la diferencia desaparece: ambos se cargan con trust_remote_code=True y exponen las mismas llamadas system_one y system_one_batch. En un despliegue en el borde no ocurre lo mismo. Si tu stack es llama.cpp en un Jetson o un teléfono, el 3B es el único de los dos que puedes ejecutar sin escribir una integración de runtime, y sus cifras publicadas para el borde —16 ms en Jetson AGX Thor, 26 ms en AGX Orin 64GB, 50 ms en Orin Nano— son las que puedes usar como referencia para planificar.

Ninguno de los dos modelos se sirve a través de OrcaRouter, así que elegir entre ellos es, en cualquier caso, una decisión de autoalojamiento. Donde un enrutador se gana su lugar es una capa más allá: los modelos de decisión rara vez funcionan solos, y el paso generativo que actúa sobre una etiqueta de enrutamiento suele provenir de un modelo alojado. Una sola clave compatible con OpenAI para más de 200 modelos, un DSL de enrutamiento que te permite componer esos pasos en una sola llamada y la conmutación por error automática evitan que esa mitad de la canalización se convierta en un segundo proyecto de integración mientras el nodo de decisión permanece en tu propio hardware.

Si estás migrando, tres cosas cambian

La superficie de la API es lo bastante parecida como para que una portación parezca trivial y no lo sea. Primero, el contrato de entrada: d1-3B toma imágenes; d1-2B toma una lista de medios que puede incluir video, y su tarjeta describe los medios como codificados una vez para todas las preguntas de una llamada. El código que pasa una sola imagen se ejecutará, pero no usará aquello para lo que se construyó el modelo.

En segundo lugar, el umbral. Ambos modelos devuelven probabilidades, y ambos necesitan un umbral de decisión ajustado a tus datos. Un umbral ajustado con la calibración de d1-3B no es transferible —las tablas de calibración se incluyen dentro de cada repositorio, ajustadas por separado—, así que una migración que mantenga el corte anterior producirá un punto de operación distinto y, en una ruta de moderación o de fraude, un perfil de errores distinto.

Tercero, el acantilado de fiabilidad. La ventana de 128K es el titular; la ficha dice que las respuestas se vuelven menos fiables pasados unos 64K tokens de estado. En el 3B el techo es 32.768, así que una migración a d1-2B normalmente será una ganancia directa de capacidad — pero un pipeline que empieza a alimentar estados de 100K tokens porque ahora puede está poniendo a prueba la parte del rango que el proveedor ha señalado como más débil.

El veredicto es menos simétrico que el marcador. Para una nueva implementación en Transformers, sobre texto, imágenes o vídeo, con estados que pueden alargarse, d1-2B es la mejor opción por defecto y la más económica de ejecutar. Para un despliegue en el borde con llama.cpp, para extracción tipada o para visión con muchos diagramas, Liquid AI d1-3B sigue siendo el modelo que hay que elegir, y es el único de los dos con algo de evidencia externa que lo respalde. Lo único que no hay que hacer es elegir solo por la línea 51,1 frente a 49,0. Dos puntos en el índice de un proveedor, entre dos modelos que nadie ha ejecutado en tu tarea, no es una decisión; es un desempate.