Filtración de LFM3: la próxima familia de Liquid AI son cuatro pequeños modelos Omni

Un pull request abierto en GitHub el 27 de octubre de 2026 pretende enseñar a SGLang cómo servir una familia de modelos que no existe en público. Nombra cuatro checkpoints —LFM3-1.7B, LFM3-VL-2B, LFM3-Audio-2B y LFM3-Omni-2B— y se lee frente a los ya publicados LFM2.5-2.6B y LFM2.5-24B-A2B como un plano de lo que Liquid AI construirá a continuación. El PR no está fusionado. Sus tres comprobaciones de CI están fallando. Liquid AI no ha anunciado nada de ello. Ese diff sin fusionar es todo el registro público de LFM3 a día de hoy, y es más informativo que la mayoría de las publicaciones de lanzamiento, siempre que se lea por lo que es.

Así que seamos precisos sobre la evidencia, porque es escasa en una dirección e inusualmente detallada en otra. Aquí no hay una fecha de lanzamiento, un precio, una condición de licencia ni una puntuación de benchmark. No hay una model card de LFM3, ni un repositorio de Hugging Face, ni una entrada de blog, ni un listado de API. Lo que existe es una contribución de tugot17 —Piotr Mazurek, quien en los últimos dos meses ha incorporado el soporte de runtime de LFM en SGLang, llama.cpp y mlx-vlm— además del material publicado por la propia Liquid sobre la generación LFM2.5 a la que está a punto de reemplazar. Todo lo que sigue está etiquetado en consecuencia.

Lo que realmente pone sobre la mesa la pull request

El título del PR es [Feat] lfm3: Añadir compatibilidad con texto, visión, audio y Omni, y lleva dos etiquetas que indican qué tipo de cambio es: jit-kernel y Multi-modal. Añade generación de texto nativa para una familia de cuatro, cada uno con su propia ruta de checkpoint:

• LFM3-1.7B — texto de entrada, texto de salida, el modelo de lenguaje simple en la base de la familia

• LFM3-VL-2B — entrada de texto, imágenes y vídeo, salida de texto

• LFM3-Audio-2B — acepta texto y audio, genera texto, y también está conectado al endpoint /v1/audio/transcriptions

• LFM3-Omni-2B — entrada de texto, imágenes, audio y vídeo, incluida la banda sonora del propio vídeo, salida de texto

Hay un detalle en esa lista que merece una pausa. Todas las variantes generan texto. No hay ninguna ruta de salida de audio en el PR, y la faceta no conversacional del modelo de audio es la transcripción: entrada de voz, salida de texto. Eso es más limitado que la línea de audio actual de Liquid, donde se documenta que LFM2.5-Audio-1.5B maneja ASR, TTS y chat de voz intercalado en un único modelo. O la primera versión de SGLang solo cubre la mitad de LFM3-Audio que genera texto, o la familia omni realmente prescinde de la síntesis de voz. El PR no puede determinar cuál de las dos cosas es, y quien te diga que sí puede está adivinando. Considera que «LFM3 habla» no está demostrado.

El resto del diff es detalle de implementación que, aun así, data el trabajo. Codificadores de visión y audio con sus proyectores, un backbone compartido, integración de caché híbrida, kernels de convolución en CuTe DSL con un respaldo en PyTorch, y una nota de que FlashInfer usa por defecto prefill paginado para que la atención de ventana deslizante se comporte correctamente. La validación se ejecutó en H100s en FP16 usando lo que la descripción llama checkpoints de desarrollo — cuatro palabras que importan más adelante.

La frase de arquitectura, y el número que la gente malinterpretará.

El PR describe LFM3 como una columna vertebral compartida de convoluciones cortas con compuerta y atención completa y de ventana deslizante. Esa es la línea de LFM2 continuada, no sustituida: LFM2.5-24B-A2B está documentado como un híbrido de convoluciones cortas con compuerta y atención de consultas agrupadas a lo largo de 40 capas. Lo que parece nuevo en la filtración es el componente explícito de ventana deslizante que se sitúa junto a la atención completa.

Las notas de validación mencionan un prompt que se extiende más allá de una ventana deslizante de 256 tokens, y esta es la cifra que se citará fuera de contexto durante toda la semana. No es la longitud de contexto de LFM3. En un diseño híbrido, las capas de atención solo necesitan ver de forma local porque las capas de convolución transportan la señal de largo alcance; esa es toda la premisa de la arquitectura, y es la razón por la que la familia puede sostener 131,072 tokens de contexto en LFM2.5-24B-A2B mientras que la mayoría de sus capas no realizan atención cuadrática en absoluto. Una ventana de atención de 256 tokens es una afirmación sobre dónde mira el modelo dentro de una capa, no sobre cuánto texto puede aceptar. El PR no indica el contexto total de LFM3, y nadie fuera de Liquid lo sabe todavía.

Por qué una pull request de runtime es la señal, no el ruido

Es razonable desconfiar de deducir la estrategia de producto a partir de un diff de infraestructura. En este caso concreto, el patrón es demasiado consistente como para ignorarlo, porque Liquid lanza el soporte de motores con los pesos en lugar de después de ellos. LFM2.5-2.6B enumera llama.cpp, MLX, vLLM, SGLang, ONNX y Transformers 5.0+ como objetivos para el primer día. LFM2.5-24B-A2B tenía soporte en llama.cpp, MLX, vLLM, SGLang y ONNX desde el lanzamiento. Una familia que llega con cinco runtimes listos tiene que tener sus kernels escritos antes del anuncio, lo que significa que los PR se fusionan primero y la entrada del blog llega después.

El autor encaja exactamente en esa cronología. El historial público de Mazurek es una sucesión de trabajos de integración de LFM: la decodificación especulativa DSpark para LFM2-VL en SGLang en septiembre, las correcciones del modelo borrador DSpark y de LFM2.5-VL-3B en llama.cpp ese mismo mes, la decodificación especulativa heredada del modelo de texto en mlx-vlm, y una reutilización de configuración de LFM2-MoE en SGLang el 13 de octubre. LFM3 es la siguiente entrada de esa secuencia, registrada el fin de semana en que la familia cambió de nombre.

Dos ausencias son tan reveladoras como la presencia. No hay una pull request correspondiente en Hugging Face Transformers para LFM3 —una búsqueda en ese repositorio no devuelve nada— y la PR de SGLang carga sus checkpoints mediante Transformers 5.19.0 estándar con --trust-remote-code, que es lo que se hace cuando la arquitectura aún no es nativa de la biblioteca. También hay un commit que rechaza explícitamente la decodificación especulativa para LFM3, por lo que el trabajo de DSpark que se lanzó para la generación 2.5 aún no se ha trasladado. Es pronto, y está incompleto por diseño.

La pregunta sobre el tamaño que nadie ha respondido

Aquí la filtración y la ambición declarada tiran en direcciones opuestas, y la tensión es lo más interesante del documento.

Maxime Labonne, responsable de preentrenamiento de Liquid, ha descrito el objetivo de LFM3 como comprobar si el enfoque de convolución corta que funciona a la escala de 350M a 1.2B puede mantenerse más allá de los 10B parámetros — el régimen en el que las arquitecturas de atención históricamente han tenido ventaja. Esa es una cuestión de escalado, e implica un modelo grande.

Los checkpoints filtrados son uno de 1,7B y tres de 2B. Ninguno de ellos supera el umbral al que se refiere esa pregunta.

Sobreviven dos lecturas. La primera es que estos son la primera ola compacta —una familia omni para teléfonos y coches antes de que llegue un hermano grande—, lo que encaja con cómo Liquid siempre ha liderado con modelos pequeños y con cómo el PR los describe como puntos de control de desarrollo en lugar de versiones finales. La segunda es que 1.7B y 2B son simplemente los tamaños que resultaban convenientes para validar kernels, y no nos dicen nada sobre lo que se lanzará. La postura honesta es que la filtración demuestra que la familia existe y demuestra su forma; no demuestra su techo. Si estás esperando un modelo Liquid de >10B, este PR ni promete uno ni lo descarta.

Lo que LFM3 hereda, para bien y para mal

La línea base que debe superar es reciente y está bien documentada. LFM2.5-24B-A2B se lanzó el 13 de octubre de 2026 con 24B de parámetros totales y 2B activos, 40 capas, 64 expertos y enrutamiento top-4, un contexto de 131.072 tokens, un vocabulario de 128K y 33T tokens de preentrenamiento. LFM2.5-2.6B, de principios de agosto, cabe en menos de 2,5 GB con un contexto de 128K. LFM2.5-VL-3B combina la base de 2.6B con un codificador visual SigLIP2.

Vale la pena decirlo claramente: todos los benchmarks que Liquid publica para estos son ejecutados por el proveedor en los propios harnesses de Liquid, sin ninguna evaluación independiente adjunta. Las cifras destacadas del LFM2.5-24B-A2B —AutomationBench 27.69, BFCLv4 65.01, ToolSandbox 80.71, IFEval 96.75— son cifras de Liquid, y la misma tabla muestra que pierde frente a Qwen3.6-35B-A3B en WebArena Verified (26.75 frente a 37.62), GPQA Diamond y SWE-Bench Verified. Las tablas de proveedores que incluyen derrotas son más creíbles que las que no, pero creíble no es lo mismo que verificado. No existe ninguna cifra de LFM3 de ningún tipo, así que todavía no hay nada que comparar.

El licenciamiento también se mantendrá. Los recientes checkpoints LFM de Liquid en Hugging Face están etiquetados, cada uno, como license: other —una licencia LFM a medida, no Apache-2.0 ni MIT. Sea cual sea la licencia con la que se distribuya LFM3, asume los mismos términos personalizados hasta que una tarjeta de modelo indique lo contrario, y léelos antes de crear un producto basado en los pesos.

Cuándo podría llegar realmente

Nadie tiene una fecha, ni siquiera quienes se dedican profesionalmente a adivinar. Una pregunta de Manifold Markets sobre cuándo se lanzará LiquidAI LFM3 sitúa T4 de 2026 en 40%, T1 de 2027 en 21%, T2 de 2027 en 21%, T3 de 2026 en 11% y T2 de 2026 en 7% — sobre un volumen total de aproximadamente Ṁ160, que es lo bastante pequeño como para que los porcentajes reflejen a un puñado de traders y no un consenso. Interprételo como "en algún momento de los próximos dos trimestres, probablemente", y no con más precisión que eso.

La mecánica aboga por cuanto antes mejor. El trabajo de kernel que llega a un runtime principal es ingeniería de etapa tardía, no de etapa temprana: no se escriben kernels de convolución CuTe ni se cablea una caché híbrida para un modelo que está a un año de distancia. El nombre de la familia se ha estabilizado como LFM3 en cuatro variantes y cuatro rutas de checkpoint. Pero el PR sigue sin fusionar, con las tres comprobaciones en rojo, necesita una revisión aprobatoria que no tiene, y 2 de 22 comprobaciones de validación omni y 2 de 16 comprobaciones de visión siguen fallando su comparación ROUGE. Eso es una rama en pleno desarrollo, no un candidato a lanzamiento.

Qué significa esto si vas a elegir un modelo esta semana

Nada sobre LFM3 debería cambiar una decisión que tomes hoy. No está disponible, no tiene precio público, no cuenta con benchmarks y no tiene licencia pública. Si necesitas ahora un modelo multimodal pequeño, la generación LFM2.5 es la respuesta real, y sus limitaciones —puntuaciones declaradas por el proveedor, licencia personalizada y un perfil de programación que tanto las propias tablas de Liquid como la cobertura externa señalan como el punto débil— son los aspectos que hay que sopesar.

Para lo que la filtración es realmente útil es para planificar. Te dice que se acerca una familia omni compacta, que probablemente llegará en varios runtimes a la vez y que puede que su variante de audio no sintetice voz. Si tu hoja de ruta asumía que el siguiente movimiento de Liquid era un modelo de texto más grande, la evidencia hasta ahora no respalda esa suposición.

La fragmentación de los entornos de ejecución es el problema práctico que creará esta familia. El hábito de Liquid de publicar simultáneamente en llama.cpp, MLX, vLLM, SGLang y ONNX es bueno para la portabilidad e incómodo para cualquiera que quiera un único endpoint: cinco motores significan cinco formas de despliegue, cinco conjuntos de peculiaridades de preprocesamiento y cinco fechas distintas en las que llega una corrección. OrcaRouter, cuyo catálogo supera los 200 modelos, no incluye hoy ni un solo checkpoint de LFM, así que no hay forma de llamar a LFM3 a través de él y nada de lo que aquí se dice debe interpretarse como una promesa de que lo habrá. Lo que realmente hace una capa de enrutamiento en esta situación es ser la costura entre un modelo no probado y una ruta de producción —enviar una porción del tráfico a algo nuevo mientras un modelo conocido permanece detrás, con el failover cubriendo el hueco, es como se evalúa el sucesor de una familia no lanzada sin apostar una funcionalidad de cara al cliente a un mercado de predicciones del 40%.

Las preguntas abiertas que vale la pena seguir

Cuatro cosas resolverán esto más rápido que cualquier especulación adicional. Si las cuatro rutas de checkpoint se convierten en repositorios reales y descargables de Hugging Face — ahora mismo, una búsqueda en la organización LiquidAI no devuelve nada bajo LFM3, y los repositorios nombrados en el PR no se pueden resolver públicamente. Si aparece un PR de Transformers, lo que indicaría que la arquitectura se está integrando upstream correctamente en lugar de ejecutarse mediante código remoto. Si se cierran las comprobaciones de validación fallidas, ya que 2 de 22 fallos omni es la diferencia entre una demo y un merge. Y si aparece un miembro de la familia de >10B, que es la pregunta que Labonne dijo que LFM3 existe para responder.

Hasta entonces, la frase más precisa que cualquiera puede escribir sobre LFM3 es la con la que abrió este artículo: existe una pull request, no está fusionada y nombra cuatro pequeños modelos omni que Liquid AI no ha anunciado. Eso es una señal real — solo que temprana, y las señales tempranas merecen leerse exactamente como eso.