LFM3-Audio-2B en Ollama: mejor habla, los mismos oídos

de Liquid AILFM3-Audio-2B se convirtió esta mañana en una descarga con un solo comando. ollama run lfm3-audio descarga 2.1 GB e inicia un modelo de 2B parámetros que acepta texto o audio y responde en texto, en voz de 24 kHz o en ambos. El modelo en sí tiene un día — se lanzó el 27 de octubre de 2026, dentro de la familia LFM3 de seis modelos. Lo nuevo del 28 de octubre es la forma de entrega, y lo primero que vale la pena saber está en la propia tabla de benchmarks de Liquid: frente al LFM2.5-Audio-1.5B al que reemplaza, la calidad de la voz aumentó drásticamente, la comprensión de audio casi se duplicó y el reconocimiento del habla en inglés no mejoró en absoluto.

El resto de este artículo separa lo que se puede verificar hoy de lo que no. La rama de audio recibió un párrafo de una publicación de blog de la familia y una ficha de modelo —no hay un anuncio propio de "Introducing LFM3-Audio"— y no pudimos encontrar ninguna ejecución de benchmark independiente de este modelo en ningún lugar. Cada cifra a continuación es de Liquid a menos que la oración indique lo contrario.

Qué se lanzó y lo escueto que fue el anuncio

La publicación de Liquid del 27 de octubre, «Presentamos LFM3: todas las modalidades para la inteligencia especializada», anunció seis modelos de la clase 2B entrenados a partir de LFM3-1.7B-Base: texto, visión, audio, omni y dos modelos de decisión especializados a partir de las ramas de visión y omni. El audio es una de las cuatro ramas de modalidad y recibe un único párrafo: la mejora de UTMOSv2, la cifra de 50 ms de tiempo hasta el primer token y el códec de 87× en tiempo real. No hay una publicación específica sobre audio, ni un blog de benchmarks de audio, ni una entrada de precios para ningún modelo LFM3 en la página de precios de Liquid.

Tres artefactos pusieron el modelo frente a un lector esta semana:

• Pesos — LiquidAI/LFM3-Audio-2B en Hugging Face, bajo la LFM Open License v1.0, con una ficha del modelo que incluye la tabla comparativa completa.

• llama.cpp — PR #31257, fusionado el 27 de octubre, añade LFM3-Audio-2B y LFM3-Omni-2B. Mantiene sin cuantizar las convoluciones del codificador de audio y el códec, expone una voz masculina o femenina mediante un flag de TTS y marca el ASR en vivo como un PR de seguimiento en lugar de formar parte de la fusión.

• Ollama — lfm3-audio, 2,1 GB, con las etiquetas latest y 2b, mostrando 19 descargas y «actualizado hace una hora» en el momento de la captura. El encabezado de la página indica cinco modelos; hay dos filas publicadas.

La entrada de Ollama es la que más importa, porque es la única ruta que no comienza leyendo una tarjeta de modelo. Además llegó sin ningún tipo de anuncio: ni una publicación, ni un registro de cambios, nada en la propia tarjeta del modelo que lo señale.

La hoja de especificaciones, incluida la cifra que casi todo el mundo copió mal

• Parámetros — 2B en total, sobre la base LFM3 con un codificador de audio causal propio y el tokenizador LiquidCodec

• Entrada — texto o audio muestreado a 16 kHz

• Salida — texto, voz a 24 kHz o texto y voz intercalados

• Contexto — {{1}}32K tokens que abarcan entrada más salida{{/1}}. Esta no es la cifra de {{2}}256K{{/2}} que se repite en la cobertura del lanzamiento: esa pertenece a {{3}}LFM3-1.7B{{/3}}, el modelo de texto. La propia página de la rama de audio dice {{4}}32K{{/4}}.

• Idiomas — 18, enumerados como 19 locales porque el inglés aparece dos veces, como variantes británica y estadounidense. El ASR en vivo solo está disponible en inglés; la traducción es más precisa hacia o desde el inglés.

• Licencia — LFM Open License v1.0, gratuita para uso comercial por debajo de $10M de ingresos anuales, con una licencia comercial de pago por encima de ese umbral.

• Huella — 2,1 GB como la compilación de Ollama.

Dos de esas filas merecen una pausa. El número de contexto es el que un resumen equivocará durante meses, porque la publicación de la familia abre con 256K y la tarjeta de audio dice discretamente 32K. Y el recuento de idiomas es un recuento de configuraciones regionales disfrazado: diecinueve entradas, dieciocho idiomas, con las dos variantes del inglés haciendo el trabajo adicional. Ninguna de las dos es un escándalo, y ambas cambian lo que le prometerías a un usuario.

Un comando, y el campo que contradice la tarjeta

ollama run lfm3-audio es realmente toda la configuración. La página etiqueta el modelo con tools, audio y 2b, y el README justo encima de la tabla del modelo dice que acepta texto o audio y responde con texto, voz o ambos. La tabla del modelo no coincide: ambas etiquetas indican la entrada como "Text" y el contexto como un guion.

Eso merece tomarse en serio en lugar de descartarse como una peculiaridad de renderizado. Ollama admite entrada de audio desde la v0.20, en abril de 2026, cuando Gemma 4 incorporó una capacidad de audio, un comando ollama transcribe y partes input_audio al estilo de OpenAI. La maquinaria existe. Lo que no está confirmado es si está conectada para este checkpoint — la etiqueta de audio es una afirmación de capacidad, no un resultado de prueba. Si tu plan empieza con «pasar un WAV a Ollama mediante pipe», verifícalo con un archivo antes de diseñar en torno a ello.

La salida de voz presenta la misma forma vista desde el otro lado. El merge de llama.cpp expone una bandera de voz TTS; la página de Ollama no documenta ningún equivalente, y el readme describe la salida de voz como una propiedad del modelo más que como una función de la CLI. Dale la vuelta a cada frase y la conclusión sigue en pie: la ruta de terminal hoy es la mitad de texto de un modelo de voz. El chat de voz full-duplex requiere la ruta de Python o de llama.cpp.

El marcador que Liquid publicó

Seis cifras, cuatro de las cuales tienen un valor predecesor. Todas provienen de la model card de Liquid, sin un conjunto de pruebas con nombre, sin arnés y sin varianza.

ASR en inglés, tasa de error de palabras ↓ — 6,23 para LFM3-Audio-2B frente a 6,13 para LFM2.5-Audio-1.5B. Sin cambios, y la única fila que no se movió.

• ASR multilingüe, WER/CER ↓ — 6.03. No se publicó ninguna cifra del predecesor.

• TTS en inglés, UTMOSv2 ↑ — 3,83 frente a 3,22. Un gran salto; por lo general, 4,0 se considera el umbral cercano a lo humano.

• VoiceBench ↑ — 73,13 frente a 55,17.

• Comprensión de audio, MMAR ↑ — 50.60 frente a 25.85. Casi el doble.

• Invocación de herramientas desde el habla, evaluación interna ↑ — 58.50. Sin cifra del predecesor.

Frente al resto de los participantes de esa misma tabla, es un buen modelo pequeño más que un líder. Voxtral Mini 3B registra un WER de 5.51 y NVIDIA Audex 2B registra 5.99, ambos mejores que 6.23. Qwen2.5-Omni 3B obtiene 54.41 en comprensión de audio frente a 50.60. Gemma 4 E4B obtiene 72.40 en llamada a herramientas frente a 58.50, y la propia fila de parámetros de Liquid sitúa a ese Gemma en 8B frente a los 2B de este modelo: el nombre «E4B» cuenta parámetros activos, no los totales. El resumen honesto es: ASR competitivo, un claro salto adelante en salida de voz y un razonamiento de audio sólido para 2B —no un poseedor de récords en ninguna columna.

La diferencia de 6,23 frente a 6,13 está dentro de lo que produce el ruido de muestreo y no debe interpretarse como una regresión. La diferencia de 3,83 frente a 3,22 no lo está: un cambio de 0,6 puntos en UTMOS queda muy fuera de ese rango. La lectura defendible es que Liquid dedicó esta generación a la generación: mejor voz, mejor razonamiento de audio y un front-end de ASR que mantuvo el tipo mientras los codificadores cambiaban por debajo. No encontramos ninguna reproducción por terceros de ninguna de las filas, así que traten el orden como una hipótesis hasta que alguien publique una.

Por qué el códec sobrevive al modelo

LiquidCodec es la parte de esta versión que vale la pena observar más allá del checkpoint. Empaqueta 80 ms de voz en 12 tokens discretos, decodifica de vuelta a 24 kHz con soporte de streaming, y Liquid lo mide en aproximadamente 87× en tiempo real en un solo hilo de CPU de un M4 Max. El codificador causal es lo que permite el prefill durante el habla en lugar de después de ella, y de ahí proviene la cifra de «hasta 50 ms» de tiempo hasta el primer token.

Esos dos números son lo más citado y lo menos reproducible del lanzamiento. Ambos son mediciones del proveedor sobre hardware Apple con nombre y apellidos, sin arnés de pruebas, sin conjunto de audio y sin percentil. Describen un caso óptimo. Un teléfono, una Raspberry Pi o una VM x86 compartida no los alcanzarán, y nada en el comunicado dice qué se alcanzará en su lugar.

El soporte de ejecución es inusualmente amplio para un modelo de un día de vida: Transformers 5.20.2 o posterior con trust_remote_code, vLLM y SGLang para el checkpoint BF16, llama.cpp para GGUF, MLX 4-bit en Apple silicon, ONNX Runtime para portabilidad y ajuste fino en una sola GPU. El requisito de código personalizado es el punto que hay que fijar. LFM3-Audio se carga desde su propio módulo y lee los pesos del códec de un directorio audio_tokenizer separado, así que un entorno sin versiones fijadas es un ticket de soporte esperando a ocurrir.

Voz local frente a un endpoint alojado

La razón por la que un modelo de audio de 2B a 2,1 GB es interesante es que la alternativa te cobra por cada segundo de audio. El alojamiento propio tiene un coste fijo: una máquina que ya tienes, una descarga, sin medición por minuto. Un endpoint alojado tiene un coste marginal por token y ninguna superficie operativa en absoluto.

Sea preciso sobre lo que cubre cada parte. La conversión de texto a voz alojada —del tipo que enrutamos, como gpt-4o-mini-tts a $0.60 de entrada y $12.00 de salida por millón de tokens, o gemini-2.5-flash-preview-tts a $0.50 y $10.00— convierte texto en voz y nada más. LFM3-Audio-2B también escucha, transcribe y traduce, y funciona con la red desconectada. Resuelven mitades distintas del mismo agente de voz.

LFM3-Audio-2B no está en OrcaRouter. Los modelos de audio que servimos son endpoints de voz alojados, así que el reparto honesto para un producto de voz este mes es voz local de entrada y salida con el modelo de Liquid, y todo lo del lado del texto detrás de un único endpoint para más de 200 modelos — 0% de recargo sobre el precio de lista del proveedor, conmutación por error automática cuando un proveedor falla, y un DSL de enrutamiento si quieres combinar varios modelos en una sola llamada. Eso es lo que hace que una configuración de dos runtimes sea viable: un contrato para la mitad alojada, una descarga para la mitad local.

Para la mitad local, el costo no es cero: 2,1 GB de pesos, un proceso que mantener vivo y ningún SLA. Si el audio nunca sale del edificio, esa disyuntiva es fácil. Si sale, el precio del servicio alojado es lo bastante bajo como para que la carga operativa suela decidir la cuestión.

¿Quién debería ejecutarlo esta semana y quién debería esperar?

Ejecútalo si quieres un bucle de voz local en un portátil y por ahora puedes conformarte con la salida de texto en la terminal. Ejecútalo si necesitas salida de voz en un idioma en el que la voz alojada que tienes es floja o cara: dieciocho idiomas son más cobertura de la que ofrecen la mayoría de los modelos TTS pequeños. Ejecútalo si tienes grabaciones que no pueden salir de la máquina y quieres transcripción y un resumen de un solo modelo. Ejecútalo si estás prototipando llamadas a herramientas por voz y quieres el modelo en la misma máquina que la herramienta.

Espera si la precisión de ASR es el producto. Una tasa de error de palabras de 6,23 es respetable y está por detrás de tres modelos en la propia tabla de Liquid. Espera si necesitas transcripción en streaming hoy: el ASR en vivo es un PR posterior de llama.cpp, y solo en inglés cuando llegue. Espera si necesitas que el modelo sepa cosas: la ficha recomienda recuperación y no recomienda explícitamente codificación agéntica ni razonamiento de varios pasos a este tamaño. Y espera si necesitas un SLA de proveedor, porque la página de precios de Liquid incluye d1, d1-ultra y LFM2.5-24B-A2B y ningún endpoint de audio de LFM3 en absoluto.

Tres preguntas que el lanzamiento no responde

¿Es LFM3-Audio-2B el mismo modelo que LFM3-Omni-2B?

No. Comparten la arquitectura base LFM3 y ambos aparecieron en la misma pull request de llama.cpp, pero Omni añade visión sobre audio y es la apuesta más grande de las dos. Si la tarea es una llamada telefónica, la grabación de una reunión o un comando de voz, Audio es el modelo más pequeño haciendo el trabajo más pequeño. Si la tarea implica mirar algo mientras se escucha, esa es la rama omni.

¿Puede transcribir una transmisión en vivo?

Todavía no a través de llama.cpp. La fusión marca la ASR en vivo como trabajo posterior, y la ficha del modelo deja claro que la ASR en vivo será solo en inglés incluso una vez que exista. La transcripción por lotes de una grabación es la vía compatible hoy, con 32K tokens de contexto — aproximadamente el límite de longitud que hay que tener en cuenta para archivos largos, ya que los tokens de audio y los tokens de texto comparten ese presupuesto.

¿Necesita una GPU?

No, y ese es el punto de la compilación GGUF. El artefacto de Ollama de 2,1 GB se ejecuta en CPU. Lo que mide la cifra de 87× en tiempo real es el códec, no el modelo de lenguaje, así que no lo interpretes como velocidad de extremo a extremo en tu hardware. Apple silicon tiene la ruta más fluida a través de MLX o del soporte integrado de llama.cpp; en x86, espera que la decodificación por CPU sea el cuello de botella, y mide antes de prometerle una cifra de latencia a nadie.

¿Qué cambiaría este veredicto?

Tres señales, en orden de cuánto importarían. Primero, la llegada a llama.cpp del seguimiento de ASR en vivo —eso convierte un transcriptor por lotes en algo que podrías poner detrás de un micrófono, que es el caso de uso que la mayoría de la gente realmente quiere. Segundo, una ejecución independiente de WER sobre un conjunto estándar; hasta que exista una, lo único que mantiene honesto el ASR de este modelo es una {{1}}tabla de proveedor que lo compara con el modelo anterior del propio proveedor{{/1}}. Tercero, un precio de API publicado para la rama de audio, que nos diría si {{2}}Liquid{{/2}} pretende vender la escucha como servicio o mantenerla como {{3}}una apuesta de pesos{{/3}}.

Hasta entonces, la descripción precisa es limitada y útil: un modelo de voz 2B que puedes descargar en un minuto, que habla mejor que el modelo al que sustituye, escucha más o menos igual de bien y aún no tiene testigos independientes. Para un prototipo en un portátil, eso basta. Para una canalización de transcripción en producción, no —y la distancia entre esas dos frases es exactamente la distancia entre un lanzamiento y una evaluación.