Presentamos LFM3: seis modelos 2B, un backbone y una ventana de 256 tokens que no es contexto

La familia LFM3 de Liquid AI llegó el 27 de octubre de 2026 como seis checkpoints de clase 2B en lugar de un único modelo insignia: LFM3-1.7B para texto, LFM3-VL-2B para visión, LFM3-Audio-2B para voz, LFM3-Omni-2B para todo a la vez, además de dos modelos de decisión, d1-2B y d1-omni-2B. Los seis derivan de un único modelo troncal preentrenado, LFM3-1.7B-Base, que Liquid también publicó. La empresa lo enmarca como «inteligencia especializada»: una negativa deliberada a lanzar un generalista pequeño y competir en el eje equivocado.

En menos de un día desde el anuncio, ya se estaba malinterpretando una cifra del informe técnico. La arquitectura de LFM3 enumera capas de atención de ventana deslizante con una ventana de 256 tokens. Eso es la geometría de atención por capa, no la longitud de contexto del modelo. El modelo de texto admite 256K tokens de contexto. Los lectores que echaron un vistazo rápido a la tabla de capas y concluyeron que Liquid había lanzado un modelo de 2026 con una memoria de 256 tokens se han formado una idea equivocada del modelo, y vale la pena corregirlo antes de que cualquier otra cosa en este artículo tenga sentido.

Qué es realmente la arquitectura trihíbrida

LFM3 sustituye la mezcla bidireccional de LFM2 por tres tipos de capas apiladas en un cuerpo de 24 capas. Trece capas son convoluciones cortas con compuerta, cinco son atención de ventana deslizante con una ventana de 256 tokens y seis son atención global completa. El kernel de convolución se amplía de 3 a 7. Tres cambios menores acompañan: una compuerta sigmoide que escala la salida de cada cabeza de atención de forma independiente, embeddings rotatorios parciales en las capas globales que rotan solo la mitad de mayor frecuencia de cada cabeza, y una normalización sándwich que condiciona tanto la entrada como la salida de cada bloque.

La apuesta es que las convoluciones cortas capturan la mayor parte de la estructura local a bajo costo, la atención dispersa se encarga de la distancia media y una fina porción de atención global une toda la ventana de 256K. Por eso la caché KV se mantiene lo bastante pequeña como para ser relevante: Liquid informa una caché completa de 128K tokens de 1.6 GB, frente a 4.3 GB de Qwen3.5-4B y 5.6 GB de MiniCPM5-2B en la misma medición. El modelo de texto en sí cabe en aproximadamente 1 GB con precisión de 4 bits.

El entrenamiento se desarrolló en cuatro etapas: 22 billones de tokens de preentrenamiento, una fase de entrenamiento intermedio de 3,5 billones de tokens con abundantes trazas de agentes y llamadas a herramientas que además amplió el contexto hasta 256K, ajuste fino supervisado sobre 1,75 billones de tokens y, después, aprendizaje por refuerzo mixto combinado con destilación on-policy multidominio de seis profesores especialistas. El vocabulario es de 128K tokens, compartido con LFM2.5-8B-A1B y diseñado para tokenizar escrituras no latinas con más eficiencia que su predecesor.

Los seis modelos, y a dónde va su contexto

Liquid deja claro que son hermanos, no niveles. Cada uno parte de la misma arquitectura base y se entrena posteriormente para una forma de salida distinta.

• LFM3-1.7B — modelo denso de texto y agentes, 1,73B parámetros, contexto de 256K, invocación nativa de herramientas y salida estructurada.

• LFM3-VL-2B — visión-lenguaje, 1,9 mil millones de parámetros, con un codificador visual propio que, según Liquid, necesita aproximadamente un tercio del cómputo de SigLIP2.

• LFM3-Audio-2B — ASR, TTS, traducción de voz y comprensión de audio, usando un codificador propio junto con LiquidCodec.

• LFM3-Omni-2B — el primer modelo omni de Liquid: texto, imagen, video y audio como entrada; texto o voz como salida.

• d1-2B — un modelo de decisión construido a partir de la rama de visión que responde preguntas estructuradas en una sola pasada hacia adelante con probabilidades calibradas en lugar de prosa libre.

• d1-omni-2B — la misma interfaz de decisión en la rama omni.

Las ventanas de contexto no son uniformes, y este es el detalle que omitió la mayor parte de la cobertura del lanzamiento. Liquid publica una ventana para el modelo de texto y el modelo base —256K, entrada y salida combinadas— y no para ninguno de los otros cuatro. Ni el anuncio ni la documentación del modelo indican una longitud de contexto para LFM3-VL-2B, LFM3-Audio-2B, LFM3-Omni-2B ni para ninguno de los dos modelos de decisión. Las publicaciones de terceros han difundido 128K para el modelo de visión y 32K para el modelo omni, y bien podrían ser correctas, pero, a 28 de octubre, no figuran en las páginas propias de Liquid. Si tienes previsto crear un agente que lea documentos largos y también mire capturas de pantalla, actualmente no puedes determinar en absoluto el tamaño del contexto del modelo omni a partir de la documentación oficial. Ese es un vacío que merece nombrarse en lugar de rellenarse con un blog que lo rellenó a partir de otra fuente.

La tabla comparativa, leída con honestidad

Todas las cifras de rendimiento que aparecen a continuación son de la propia Liquid, obtenidas con el arnés propio de Liquid, y ninguna de ellas ha sido reproducida de forma independiente. A 28 de octubre de 2026 no hay ninguna entrada de LFM3 en Artificial Analysis: ni un Intelligence Index, ni mediciones de velocidad o latencia por parte de un tercero neutral. Esto importa más de lo habitual en este caso porque la comparación en la que se apoya el lanzamiento es una comparación en el mismo arnés, lo que favorece al modelo para el que se haya ajustado dicho arnés.

LFM3-1.7B obtiene 49,37 en el promedio de 27 benchmarks de Liquid. El propio LFM2.5-2.6B de la empresa obtiene 31,55 en el mismo conjunto, y de ahí proviene la afirmación de «un 35 % menos de parámetros». Las filas interesantes no son el promedio:

• Uso de herramientas — BFCL V4 71.39, ToolSandbox 80.36, τ³-bench 68.01, MCP-Atlas 32.57.

• Web agéntica — WebArena-Verified 38,42; AutomationBench 41,29; BrowseComp-Plus 37,00; LiveClaw 45,60.

• Codificación agéntica — SWE-bench Verified 43.40, SWE-bench Multilingual 23.00, Terminal-Bench 2.1 en 12.92.

• Seguimiento de instrucciones — IFEval 96.66, IFStruct 93.72, IFBench 73.03, Multi-IF 89.10.

• Conocimiento — GPQA Diamond 63.37, HLE 7.17 sin herramientas y 13.90 con ellas.

• Contexto largo: RULER 128K 65,56, AA-LCR 52,83.

Leído como una forma y no como un total, el perfil es coherente: una adherencia a las instrucciones muy sólida, un uso de herramientas de un solo turno respetable y una caída pronunciada cuando una tarea requiere muchos pasos secuenciales. Terminal-Bench 2.1 con 12.92 y SWE-bench Multilingual con 23.00 no son cifras sobre las que construir un agente de programación autónomo. Liquid no lo oculta —la tarjeta del modelo desvía a los usuarios del razonamiento complejo y de la programación de varios pasos, lo que constituye una pieza de posicionamiento inusualmente directa por parte de un proveedor el día del lanzamiento.

Las afirmaciones sobre eficiencia son la otra mitad de la propuesta. Con Q4_0 y un contexto de 32K, Liquid afirma que LFM3-1.7B fue el modelo más rápido en los tres dispositivos de prueba, entre 1,8 y 2,8 veces más rápido que el siguiente competidor, con la menor huella de memoria. En una sola NVIDIA B300 con SGLang en BF16, atendió 3.600 millones de tokens al día con 1.024 solicitudes concurrentes. La empresa también ejecutó en paralelo más de 300.000 agentes LFM3-1.7B sobre el archivo de correos de Enron como demostración de estrés. Son cifras del fabricante, no auditadas, pero son el tipo de cifra que es difícil inflar discretamente.

Licencia y cuánto cuesta ejecutarlo

Los pesos están en Hugging Face en compilaciones BF16, FP8, NVFP4, GGUF, MLX y ONNX, con soporte desde el primer día en vLLM, SGLang, Transformers, llama.cpp, MLX, ONNX Runtime, Ollama y LM Studio. La licencia es la LFM Open License v1.0: uso comercial libre de regalías por debajo de los 10 millones de dólares de ingresos anuales, con un acuerdo aparte por encima de esa cifra. Ese umbral, y no el número de parámetros, es la línea que decide si LFM3 es gratuito para una empresa determinada.

Liquid también gestiona una API alojada, y ahí la información pública disponible es más escasa de lo que sugiere el lanzamiento. La documentación indica el ID del modelo y un límite de 256K de entrada más salida, pero no incluye una tabla de tarifas. Informes de terceros sitúan la tarifa alojada de LFM3-1.7B en aproximadamente $0,08 por millón de tokens de entrada y $0,20 por millón de salida, con las variantes de visión, audio, omni y decisión a un precio superior; Liquid no ha publicado esas cifras en sus propias páginas, así que deben considerarse reportadas y no confirmadas. El autoalojamiento, en cambio, no tiene ningún precio por token: el coste es la máquina y, en 4 bits, esa máquina puede ser un teléfono.

Dónde encaja OrcaRouter — y dónde no

LFM3 no está en el catálogo de OrcaRouter, y no vamos a fingir lo contrario. Es software de pesos abiertos que ejecutas tú mismo o al que llamas mediante la propia API de Liquid. Para lo que sí sirve el router es para la capa que lo rodea. Un especialista de 1,7B rara vez es el único modelo de un pipeline: se encarga de la llamada a herramientas, la clasificación o la extracción, y algo más grande se ocupa del turno que requiere criterio. OrcaRouter pone esos modelos alojados detrás de una sola clave con un 0% de margen —el precio de lista del proveedor se transfiere directamente—, de modo que la ruta de escalado de LFM3 a un modelo de frontera es una regla de enrutamiento en lugar de un segundo contrato. Su conmutación por error automática importa sobre todo para exactamente la carga de trabajo a la que apunta LFM3, donde un único modelo pequeño es lo único que se interpone entre una solicitud y un error.

El DSL de enrutamiento es el encaje más interesante. Componer un especialista con un generalista en una sola llamada —trabajo con forma de LFM3 enrutado a un modelo pequeño, y todo lo demás derivado a uno alojado— es el patrón de despliegue para el que se creó esta familia. El argumento entero de Liquid es que un modelo de 2B supera a un modelo de frontera en una tarea concreta a una fracción del coste. Un enrutador es la forma de capturar ese ahorro sin apostar el pipeline a ello.

Qué ver

La pregunta abierta no es si LFM3 es bueno en lo que afirma. Es si las afirmaciones sobreviven a un arnés que Liquid no escribió. Las cifras agénticas de la familia son las que hay que volver a probar primero, porque WebArena-Verified con 38,42 y AutomationBench con 41,29 están muy por encima de lo que un modelo de 1,7B ha logrado históricamente, y los benchmarks agénticos son los más sensibles al andamiaje de prompts y a la política de reintentos. Una ejecución independiente que quede a pocos puntos de la tabla de Liquid convertiría a LFM3 en la opción predeterminada para el uso de herramientas en el dispositivo. Una ejecución que quede diez puntos por debajo lo convertiría en un buen seguidor de instrucciones con un relato de agentes exagerado.

Hasta que exista esa ejecución, el resumen honesto es este: LFM3 es una familia de modelos pequeños bien diseñada e inusualmente franca, con una mezcla de capas genuinamente novedosa, una ventaja de memoria real, pesos publicados con un umbral de licencia viable y ninguna verificación independiente de ningún benchmark destacado. La ventana de 256 tokens de la tabla de arquitectura no es la longitud de contexto. Todo lo demás del lanzamiento merece tomarse al pie de la letra hasta que alguien demuestre lo contrario —y merece medirse uno mismo antes de ponerlo delante de los usuarios.