LFM3-Audio-2B no Ollama: fala melhor, os mesmos ouvidos

Da Liquid AI, LFM3-Audio-2B tornou-se um download com um único comando esta manhã. ollama run lfm3-audio baixa 2,1 GB e inicia um modelo de 2 bilhões de parâmetros que aceita texto ou áudio e responde em texto, em fala de 24 kHz, ou em ambos. O modelo em si tem apenas um dia — foi lançado em 27 de outubro de 2026, dentro da família LFM3 de seis modelos. O que é novo em 28 de outubro é a entrega, e a primeira coisa que vale saber está na própria tabela de benchmarks da Liquid: contra o LFM2.5-Audio-1.5B que ele substitui, a qualidade da fala subiu acentuadamente, a compreensão de áudio quase dobrou, e o reconhecimento de fala em inglês não melhorou em nada.

O restante deste texto separa o que é verificável hoje do que não é. O ramo de áudio recebeu um parágrafo de um post de blog da família e um model card — não há um anúncio próprio de "Apresentando o LFM3-Audio" — e não conseguimos encontrar nenhuma execução independente de benchmark deste modelo em lugar algum. Todos os números abaixo são da Liquid, a menos que a frase diga o contrário.

O que foi entregue e quão pouco substancial foi o anúncio

A publicação da Liquid de 27 de outubro, "Apresentando o LFM3: Todas as Modalidades para Inteligência Especializada", anunciou seis modelos da classe 2B treinados a partir do LFM3-1.7B-Base: texto, visão, áudio, omni e dois modelos de decisão especializados a partir dos ramos de visão e omni. O áudio é um dos quatro ramos de modalidade e recebe um único parágrafo — a melhoria do UTMOSv2, o valor de 50 ms para o tempo até o primeiro token, o codec de 87× em tempo real. Não há publicação específica sobre áudio, nem blog de benchmark de áudio, e nenhuma entrada de preços para qualquer modelo LFM3 na página de preços da Liquid.

Três artefactos colocaram o modelo diante de um leitor esta semana:

• Pesos — LiquidAI/LFM3-Audio-2B no Hugging Face, sob a LFM Open License v1.0, com um cartão do modelo que traz a tabela comparativa completa.

• llama.cpp — PR #31257, mesclado em 27 de outubro, adiciona o LFM3-Audio-2B e o LFM3-Omni-2B. Ele mantém as convoluções do codificador de áudio e o codec sem quantização, expõe uma voz masculina ou feminina por meio de uma flag de TTS, e marca o ASR ao vivo como um PR de acompanhamento, em vez de parte da mesclagem.

• Ollama — lfm3-audio, 2,1 GB, tags latest e 2b, exibindo 19 downloads e "atualizado há uma hora" no momento da captura. O cabeçalho da página diz cinco modelos; duas linhas estão publicadas.

A listagem no Ollama é a que mais importa, porque é a única rota que não começa com a leitura de um cartão de modelo. Ela também surgiu sem qualquer tipo de anúncio — nenhuma publicação, nenhum changelog, nada no próprio cartão do modelo apontando para ela.

A ficha técnica, incluindo a figura que quase todo mundo copiou errado.

• Parâmetros — 2B no total, no backbone LFM3 com um codificador de áudio causal interno e o tokenizador LiquidCodec

• Entrada — texto ou áudio amostrado a 16 kHz

• Saída — texto, fala de 24 kHz ou texto e fala intercalados

• Contexto — 32K tokens cobrindo entrada mais saída. Este não é o número de 256K que está sendo repetido na cobertura de lançamento: ele pertence ao LFM3-1.7B, o modelo de texto. A própria página do ramo de áudio diz 32K.

• Idiomas — 18, listados como 19 locales porque o inglês aparece duas vezes, como variantes britânica e americana. O ASR ao vivo é apenas em inglês; a tradução tem melhor desempenho de ou para o inglês.

• Licença — LFM Open License v1.0, gratuita para uso comercial abaixo de US$ 10 milhões de receita anual, com uma licença comercial paga acima desse limite.

• Pegada — 2,1 GB como a build do Ollama.

Duas dessas linhas merecem uma pausa. O número de contexto é aquele que um resumo vai errar durante meses, porque o post da família começa por 256K e a placa de áudio diz discretamente 32K. E a contagem de idiomas é uma contagem de locales disfarçada: dezanove entradas, dezoito idiomas, com as duas variantes do inglês a fazer o trabalho extra. Nenhum dos dois é um escândalo, e ambos mudam o que prometerias a um utilizador.

Um comando, e o campo que contradiz o cartão

ollama run lfm3-audio é genuinamente toda a configuração. A página etiqueta o modelo com tools, audio e 2b, e o readme logo acima da tabela de modelos diz que ele aceita texto ou áudio e responde com texto, fala ou ambos. A tabela de modelos discorda: ambas as tags listam a entrada como "Text" e o contexto como um travessão.

Isso merece ser levado a sério, em vez de ser descartado como uma peculiaridade de renderização. O Ollama oferece suporte a entrada de áudio desde a v0.20, em abril de 2026, quando o Gemma 4 trouxe uma capacidade de áudio, um comando ollama transcribe e partes input_audio ao estilo OpenAI. A infraestrutura existe. O que não está confirmado é se ela está conectada para este checkpoint — a etiqueta de áudio é uma alegação de capacidade, não um resultado de teste. Se o seu plano começa com “canalizar um WAV para o Ollama”, verifique isso com um único arquivo antes de projetar com base nisso.

{{1}}A saída de fala tem o mesmo formato do outro lado.{{/1}} {{2}}O merge do llama.cpp expõe uma flag de voz TTS; a página do Ollama não documenta nada equivalente, e o readme descreve a saída de fala como uma propriedade do modelo, e não como um recurso da CLI.{{/2}} {{3}}Inverta cada frase e a conclusão se mantém: o caminho do terminal hoje é a metade textual de um modelo de fala.{{/3}} {{4}}O chat de voz full-duplex precisa da rota Python ou llama.cpp.{{/4}}

O placar que a Liquid publicou

Seis números, quatro dos quais têm um valor antecessor. Todos eles vêm do model card da Liquid, sem conjunto de teste nomeado, sem harness e sem variância.

• ASR em inglês, taxa de erro de palavras ↓ — 6,23 para LFM3-Audio-2B contra 6,13 para LFM2.5-Audio-1.5B. Sem alteração, e a única linha que não mudou.

• ASR multilíngue, WER/CER ↓ — 6,03. Nenhum valor publicado para o antecessor.

• TTS em inglês, UTMOSv2 ↑ — 3,83 contra 3,22. Um avanço considerável; 4,0 costuma ser tratado como o limiar de quase humano.

• VoiceBench ↑ — 73,13 contra 55,17.

• Compreensão de áudio, MMAR ↑ — 50,60 contra 25,85. Quase o dobro.

• Chamada de ferramentas a partir da fala, avaliação interna ↑ — 58,50. Sem valor de referência anterior.

Em comparação com os demais concorrentes da mesma tabela, ele é um bom modelo pequeno, e não um líder. O Voxtral Mini 3B registra 5,51 de WER e o NVIDIA Audex 2B registra 5,99, ambos melhores que 6,23. O Qwen2.5-Omni 3B alcança 54,41 em compreensão de áudio, contra 50,60. O Gemma 4 E4B alcança 72,40 em chamada de ferramentas, contra 58,50, e a própria linha de parâmetros da Liquid coloca esse Gemma em 8B, contra 2B deste modelo — o nome "E4B" conta parâmetros ativos, não totais. O resumo honesto é: ASR competitivo, um avanço claro na saída de voz e raciocínio de áudio sólido para 2B — não é detentor de recorde em nenhuma coluna.

A diferença de 6,23 contra 6,13 está dentro do que o ruído de amostragem produz e não deve ser interpretada como uma regressão. A diferença de 3,83 contra 3,22 não está — uma variação de 0,6 ponto no UTMOS está muito fora desse intervalo. A leitura defensável é que a Liquid dedicou esta geração à geração: melhor voz, melhor raciocínio de áudio e um front-end de ASR que se manteve firme enquanto os encoders mudavam por baixo dele. Não encontramos nenhuma reprodução por terceiros de qualquer linha, então trate a ordenação como uma hipótese até que alguém publique uma.

Por que o codec sobrevive ao modelo

O LiquidCodec é a parte deste lançamento que vale a pena acompanhar além do checkpoint. Ele compacta 80 ms de fala em 12 tokens discretos, decodifica de volta para 24 kHz com suporte a streaming, e a Liquid mede cerca de 87× o tempo real em uma única thread de CPU de um M4 Max. O encoder causal é o que permite o prefill durante a fala em vez de depois dela, que é de onde vem o número de tempo até o primeiro token de "até 50 ms".

Esses dois números são os itens mais citados e menos reproduzíveis do lançamento. Ambos são medições de fabricante em hardware Apple específico, sem harness, sem conjunto de áudio e sem percentil. Eles descrevem um cenário ideal. Um celular, um Raspberry Pi ou uma VM x86 compartilhada não os alcançará, e nada no comunicado diz o que será alcançado em vez disso.

O suporte de runtime é excepcionalmente amplo para um modelo com um dia de existência: Transformers 5.20.2 ou mais recente com trust_remote_code, vLLM e SGLang para o checkpoint BF16, llama.cpp para GGUF, MLX 4-bit em Apple silicon, ONNX Runtime para portabilidade, e fine-tuning em uma única GPU. O requisito de código personalizado é o ponto que precisa ser fixado. O LFM3-Audio carrega a partir do próprio módulo e lê os pesos do codec de um diretório audio_tokenizer separado, então um ambiente sem versões fixadas é um chamado de suporte esperando para acontecer.

Fala local contra um endpoint hospedado

O motivo pelo qual um modelo de áudio de 2B com 2,1 GB é interessante é que a alternativa cobra de você por cada segundo de áudio. A auto-hospedagem tem um custo fixo — uma máquina que você já possui, um download, sem medição por minuto. Um endpoint hospedado tem um custo marginal por token e nenhuma superfície operacional.

Seja preciso sobre o que cada lado cobre. O TTS hospedado — o tipo que roteamos, como gpt-4o-mini-tts a US$ 0,60 de entrada e US$ 12,00 de saída por milhão de tokens, ou gemini-2.5-flash-preview-tts a US$ 0,50 e US$ 10,00 — converte texto em fala e nada mais. O LFM3-Audio-2B também escuta, transcreve e traduz, e funciona sem conexão de rede. Eles resolvem metades diferentes do mesmo agente de voz.

O LFM3-Audio-2B não está no OrcaRouter. Os modelos de áudio que servimos são endpoints de fala hospedados, então a divisão honesta para um produto de voz neste mês é fala local na entrada e na saída com o modelo Liquid, e tudo do lado de texto por trás de um endpoint para 200+ modelos — 0% de markup sobre o preço de tabela do provedor, failover automático quando um provedor falha, e uma DSL de roteamento se você quiser compor vários modelos em uma única chamada. É isso que torna uma configuração de dois runtimes sobrevivível: um contrato para a metade hospedada, um download para a metade local.

Para a metade local, o custo não é zero: 2,1 GB de pesos, um processo a manter ativo e nenhum SLA. Se o áudio nunca sai do edifício, essa troca é fácil. Se sai, o preço do serviço alojado é suficientemente baixo para que o ónus operacional decida normalmente a questão.

Quem deve executar isso esta semana, e quem deve esperar

Execute-o se você quiser um loop de voz local em um laptop e puder conviver com a saída em texto no terminal por enquanto. Execute-o se você precisar de saída de fala em um idioma em que a voz hospedada que você tem seja fraca ou cara — dezoito idiomas é mais cobertura do que a maioria dos modelos TTS pequenos oferece. Execute-o se você tiver gravações que não podem sair da máquina e quiser transcrição mais um resumo a partir de um único modelo. Execute-o se você estiver prototipando chamadas de ferramentas por voz e quiser o modelo na mesma máquina que a ferramenta.

Atenção se a precisão do ASR for o produto. Uma taxa de erro de palavras de 6,23 é respeitável e fica atrás de três modelos na própria tabela da Liquid. Atenção se você precisa de transcrição em streaming hoje — o ASR ao vivo é um PR subsequente no llama.cpp, e apenas em inglês quando for lançado. Atenção se você precisa que o modelo saiba coisas: o card recomenda recuperação e explicitamente não recomenda codificação agêntica nem raciocínio em múltiplas etapas neste tamanho. E atenção se você precisa de um SLA de fornecedor, porque a página de preços da Liquid lista d1, d1-ultra e LFM2.5-24B-A2B e não lista nenhum endpoint de áudio LFM3.

Três perguntas que o lançamento não responde

O LFM3-Audio-2B é o mesmo modelo que o LFM3-Omni-2B?

Não. Eles compartilham a espinha dorsal LFM3 e ambos apareceram no mesmo pull request do llama.cpp, mas o Omni adiciona visão sobre o áudio e é o maior compromisso dos dois. Se a tarefa for uma chamada telefônica, uma gravação de reunião ou um comando de voz, o Audio é o modelo menor fazendo a tarefa menor. Se a tarefa envolve olhar para algo enquanto se ouve, esse é o ramo omni.

Ele consegue transcrever uma transmissão ao vivo?

Ainda não via llama.cpp. O merge sinaliza o ASR ao vivo como um trabalho futuro, e o card do modelo deixa explícito que o ASR ao vivo é apenas em inglês mesmo quando existir. A transcrição em lote de uma gravação é o caminho suportado hoje, com 32K tokens de contexto — aproximadamente o limite de tamanho a considerar para arquivos longos, já que tokens de áudio e tokens de texto compartilham esse orçamento.

Precisa de uma GPU?

Não, e esse é justamente o ponto da build GGUF. O artefato de 2,1 GB do Ollama roda na CPU. O número de 87× em tempo real mede o codec, não o modelo de linguagem, então não o interprete como velocidade ponta a ponta no seu hardware. O Apple silicon tem o caminho mais tranquilo via MLX ou o suporte integrado do llama.cpp; em x86, espere que a decodificação por CPU seja o gargalo, e meça antes de prometer um número de latência a qualquer pessoa.

O que mudaria este veredito?

Três sinais, em ordem de quão relevantes seriam. Primeiro, a integração do acompanhamento de ASR ao vivo no llama.cpp — isso transforma um transcritor de lote em algo que você poderia colocar atrás de um microfone, que é o caso de uso que a maioria das pessoas realmente quer. Segundo, uma execução independente de WER em um conjunto padrão; até que uma exista, a única coisa que mantém o ASR deste modelo honesto é uma tabela do fornecedor comparando-o ao modelo anterior do próprio fornecedor. Terceiro, um preço de API publicado para o ramo de áudio, que nos diria se a Liquid pretende vender escuta como serviço ou mantê-la como uma aposta em pesos.

Até então, a descrição precisa é estreita e útil: um modelo de fala 2B que você pode baixar em um minuto, que fala melhor do que o modelo que substitui, escuta quase tão bem e ainda não tem testemunhas independentes. Para um protótipo em um laptop, isso é suficiente. Para um pipeline de transcrição em produção, não é — e a lacuna entre essas duas frases é exatamente a distância entre um lançamento e uma avaliação.