LFM3-Omni-2B: el modelo Omni que habla, y la filtración que decía que no podía

LFM3-Omni-2B responde con voz. Esa sola frase es la noticia, porque hace una semana la mejor evidencia pública decía lo contrario. Cuando la familia LFM3 apareció mediante una pull request de SGLang sin fusionar, los checkpoints estaban configurados solo para salida de texto, y nuestro propio artículo sobre esa filtración concluía, correctamente en aquel momento, que «LFM3 habla» no estaba demostrado. El 27 de octubre de 2026, Liquid AI publicó el anuncio de la familia y la ficha del modelo, y la ficha lo zanja: salida de voz a 24 kHz, generada mediante un componente llamado LiquidCodec, transmitida en streaming más rápido que el tiempo real. Un modelo no demostrado no debería ser crítico desde el primer día. conmutación por error automática El tráfico puede moverse por regla, y una ruta que falla conmuta por error sin necesidad de cambiar el código.

Todo lo demás en este lanzamiento es más discreto de lo que sugiere esa corrección. El anuncio de Liquid abarca seis modelos, y LFM3-Omni-2B recibe tres frases —sin tabla de benchmarks, sin longitud de contexto, sin recuento de parámetros. El registro cuantitativo vive por completo en la tarjeta de Hugging Face, de donde proviene cada cifra a continuación. Esa separación merece entenderse antes de planificar en torno al modelo: el posicionamiento es marketing, los números son un repositorio, y nada de ninguno de los dos ha sido probado de forma independiente.

Qué se envió realmente y cuándo

El repositorio se creó el 21 de octubre de 2026 a las 16:58 UTC. La tarjeta se modificó por última vez el 27 de octubre a las 17:25 UTC, el mismo día que la publicación de la familia. En el momento de escribir esto, Hugging Face mostraba 83 descargas y 17 me gusta: cifras modestas que encajan con un checkpoint publicado como una rama de una familia de seis modelos en lugar de como un lanzamiento destacado. Los repositorios hermanos cuentan la misma historia: LFM3-VL-2B se creó el 19 de octubre, LFM3-Audio-2B el 8 de septiembre, y todos ellos se modificaron el 27 de octubre.

Así que no se trata de un modelo no anunciado en el sentido que implica el brief. Liquid anunció la familia, nombró las seis ramas y describió qué hace el modelo omni. Lo que la empresa no hizo fue anunciar LFM3-Omni-2B de forma independiente. No hay una publicación por separado, ni un artículo de evaluación del día del lanzamiento, ni una página de precios porque no hay un endpoint alojado, ni un benchmark independiente. La brecha entre «anunciado» y «documentado» es donde se sitúa este artículo.

La tarjeta completa

El checkpoint es una única compilación BF16 de 2.166.928.384 parámetros, que la ficha redondea a 2,17B. Se asienta sobre el tronco LFM3-1.7B-Base —el mismo backbone tri-híbrido que el resto de la familia, con convoluciones cortas con compuerta que sostienen la mayoría de las capas y la atención global reservada para un puñado. Sobre ese tronco se sitúan un codificador de visión, un codificador de audio causal y el tokenizador LiquidCodec que convierte los tokens generados de nuevo en forma de onda.

• Entradas — texto, imágenes a resolución nativa, vídeo a 2 fotogramas por segundo durante 4 a 384 fotogramas, y audio de 16 kHz. La entrada de vídeo puede incluir su propia banda sonora.

• Salidas — texto, voz de 24 kHz o ambos en la misma respuesta.

• Contexto — 32,768 tokens que cubren la entrada y la salida en conjunto.

• Presupuesto de imagen — un máximo de 2.048 tokens visuales por imagen, sea cual sea la resolución.

• Idiomas — la tarjeta enumera 16 idiomas de texto y 19 idiomas o configuraciones regionales de voz; los metadatos del repositorio afirman 23. Las dos cifras no concuerdan en la página.

• Licencia — LFM Open License v1.0, los términos personalizados que Liquid ha utilizado desde LFM2, no una licencia OSI.

• Razonamiento — ninguno. La tarjeta indica que el modo de pensamiento no es compatible y que no se puede usar enable_thinking=True.

Dos de esas líneas importan más que el resto. La primera es el contexto de 32K, que es pequeño para un modelo multimodal de 2026 y una consecuencia directa del objetivo de ejecución en el dispositivo: cada token de contexto cuesta memoria en un teléfono. La segunda es la licencia. LFM Open License v1.0 no es Apache-2.0, y sus términos incluyen un umbral de ingresos que determina quién puede usar los pesos comercialmente sin un acuerdo aparte. Si evalúas este modelo para un producto, lee la licencia antes de leer los benchmarks.

Las cifras que nadie anunció

La publicación de Liquid hace una afirmación comparativa sobre LFM3-Omni-2B: que supera a modelos de hasta 10,7B parámetros, "como Qwen2.5-Omni-7B", en Daily-Omni, WorldSense y AV-SpeakerBench. Ninguna puntuación acompaña esa frase. La ficha las proporciona, y están medidas por la propia Liquid AI —una evaluación del proveedor, no independiente, y la única evaluación que existe.

En los tres benchmarks que menciona la publicación, la ficha indica Daily-Omni 70.09, WorldSense 47.10 y AV-SpeakerBench 46.79. OmniBench alcanza 46.32 en general, con 48.25 en el subconjunto de voz. Para la respuesta visual a preguntas habladas —el truco estrella del modelo, en el que se pregunta sobre una imagen en voz alta—, la ficha enumera RealWorldQA 64.68, MMStar 51.79, POPE 83.78, ERQA 39.43 y EmbSpatial 67.59. Las filas de audio son ASR en inglés con una tasa de error de palabras de 6.36, ASR multilingüe con 6.72, síntesis de voz en inglés con 3.80 UTMOSv2, VoiceBench 64.73 y MMAR de comprensión de audio 51.40. Sus puntuaciones de visión solo de texto, para completar, son DocVQA 92.47, OCRBench 806 de 1,000, MMMU validación 42.44 y MathVista mini 62.50.

Leídas en conjunto, las puntuaciones describen un modelo competente en todo y excelente en nada. Un 46,79 en AV-SpeakerBench y un 47,10 en WorldSense no son cifras que ganen una tabla de clasificación; son cifras que sugieren que un modelo de 2,2B puede mantenerse firme en razonamiento audiovisual sin venirse abajo. La puntuación de DocVQA es el valor atípico en la dirección opuesta y la cifra individual más interesante de la tabla: 92,47 en un modelo omni de 2,2B es alto, y es la única fila en la que este checkpoint claramente supera al modelo de visión dedicado de la propia Liquid, que reporta 91,1.

En qué acertó la filtración y la única cosa en la que se equivocó

La pull request de SGLang que sacó a la luz pública a esta familia acertaba en casi todos los aspectos estructurales. Nombraba correctamente los cuatro checkpoints, describía correctamente el backbone compartido y acertaba al señalar que la ventana deslizante de 256 tokens es un ajuste de atención y no el límite de contexto. También acertaba al ser cautelosa: la pull request no estaba fusionada, tres comprobaciones de CI fallaban y dos de las veintidós comprobaciones de validación omni seguían fallando en las comparaciones ROUGE frente a los checkpoints de desarrollo.

Donde indujo a error —y donde lo repetimos— fue la modalidad de salida. La ruta del runtime que se implementó devolvía texto. No había ninguna rama de salida de audio en ese código, y la inferencia razonable era que la familia podría haber eliminado la síntesis de voz, o que la primera versión del runtime era solo de texto. El modelo que se lanzó hace ambas cosas. La lección no es que la filtración fuera un descuido; es que una integración de serving describe la ruta que alguien implementó, no la capacidad del checkpoint que hay detrás. Un PR es evidencia sobre un runtime, y lo tratamos como evidencia sobre un modelo.

Lo que aún no está confirmado

Tres cosas, y son las tres que decidirían un despliegue en producción.

En primer lugar, no existe ningún tipo de evaluación independiente. Todas las cifras anteriores las produjo la empresa que construyó el modelo, con su propio entorno de evaluación y sin metodología publicada. No hay ninguna entrada en Artificial Analysis, ningún resultado de LMArena, ninguna reproducción por terceros. Considera la tabla de benchmarks como una declaración de intenciones, no como una medición.

En segundo lugar, el servicio de habla no está documentado fuera de la ruta propia del proveedor. La ficha indica que la compatibilidad con SGLang abarca la salida de texto y no documenta cómo se sirve la rama de habla. Si tu plan es «un solo modelo, respuestas habladas, en nuestro propio hardware», la ficha no te ofrece ninguna referencia para la segunda mitad de esa frase. El repositorio no enumera ningún proveedor de inferencia en el momento de redactar este texto.

Tercero, las cifras de idiomas no coinciden entre sí. Dieciséis idiomas de texto, diecinueve locales de voz, veintitrés en los metadatos. Probablemente sean tres definiciones diferentes de lo mismo, pero nadie ha publicado cuál es la correcta.

Por qué un modelo omni de 2,2B es una apuesta diferente

La forma habitual de construir un asistente de voz en 2026 es una canalización: un modelo ASR convierte el habla en texto, un modelo de lenguaje piensa, un modelo de visión se encarga de la cámara y un modelo TTS pronuncia la respuesta. Cada etapa es un checkpoint separado, un presupuesto de latencia separado y un modo de fallo separado. La propuesta de LFM3-Omni-2B es que las cuatro se fusionen en un único archivo BF16 de 4,3 GB que cabe en un teléfono y nunca sale de él.

Ese es un argumento arquitectónico real, y es la razón por la que las puntuaciones de los benchmarks importan menos que la forma del sistema. Un pipeline de cuatro modelos especialistas pequeños normalmente superará a un único generalista en cada tarea individual. Lo que no puede hacer es compartir representaciones: el modelo omni capta el tono de una pregunta sobre una imagen, y la respuesta se condiciona a ambos a la vez. Que eso produzca mejores respuestas es justo lo que ninguna evaluación independiente ha puesto a prueba.

La forma práctica de usar un checkpoint como este mientras no está probado es mantenerlo fuera de tu ruta crítica. El DSL de enrutamiento de OrcaRouter se creó precisamente para ese patrón — una ruta de especialista y una ruta experimental detrás de un único endpoint, de modo que un modelo nuevo pueda recibir tráfico en proporción a su fiabilidad en lugar de todo de golpe, con conmutación por error automática cuando da errores. LFM3-Omni-2B no está hoy en nuestro catálogo, así que nada de lo aquí dicho afirma que puedas llamarlo a través de nosotros. Cuando un modelo como este llegue de verdad, esa es la forma de despliegue que le encaja: disponible, medido y sin soportar carga crítica hasta que se lo gane.

Qué ver

La siguiente señal no es otra tabla de benchmarks. Es si alguien fuera de Liquid publica una. Un modelo omni de 2.2B que realmente mantiene 70.09 en Daily-Omni es un resultado notable para trabajo en dispositivo, y una reproducción independiente —aunque sea parcial— valdría más que la hoja completa del proveedor. La segunda señal es la fusión con SGLang: cuando la ruta de voz está documentada en un stack de serving, el modelo deja de ser un repositorio y empieza a ser infraestructura.

Hasta entonces, el resumen honesto es limitado. LFM3-Omni-2B existe, es más pequeño que casi todo aquello con lo que compite, recibe cuatro modalidades y devuelve dos, y es el primer modelo de Liquid que puede responder en voz alta. La filtración decía que no podía. La ficha dice que sí puede, y por ahora la ficha es el único testigo.