Liquid AI d1-omni-600M agora está disponível para pull no Ollama: um modelo de decisão de 600M que consegue ouvir você

Liquid AI d1-omni-600M tornou-se um pacote do Ollama às 22:32 UTC de 17 de outubro de 2026. Esse carimbo de tempo não é um palpite: o registro do Ollama fornece um cabeçalho ollama-push-time em todo manifesto, e as quatro tags por trás do nome d1-omni foram aceitas entre 22:31:25 e 22:32:13 naquela noite, cerca de quatro horas antes de isto ser escrito. O modelo em si não é novo — Liquid AI disponibilizou com pesos abertos o Liquid AI d1-omni-600M ao lado do Liquid AI d1-3B em 5 de outubro de 2026 e anunciou ambos em seu post "Open d1" em 7 de outubro — mas até a noite passada as únicas maneiras de executar o modelo com capacidade de áudio no seu próprio hardware eram um ambiente transformers com trust_remote_code=True ou uma build do llama.cpp que você mesmo compilou. Agora é ollama pull d1-omni. Ninguém anunciou isso: nem o blog da Liquid AI, nem o da Ollama.

O empacotamento é a história, e vale a pena ser preciso sobre quais partes dele estão documentadas. Os posts mais recentes do blog da Liquid AI são d1-ultra, em 15 de outubro, e LFM2.5-24B-A2B, em 13 de outubro, e nenhum deles menciona o Ollama; a própria página de implantação do Ollama do laboratório ainda ensina a executar seus repositórios GGUF diretamente do Hugging Face com ollama run hf.co/LiquidAI/... e nunca cita um modelo d1. O blog do Ollama está igualmente silencioso — suas entradas mais recentes são Reflection's Beam, em 16 de outubro, e uma integração com o Fly.io, em 13 de outubro. O que existe, em vez disso, é uma entrada de registro, quatro tags, um digest verificável e uma página de biblioteca que ainda estava sendo escrita enquanto este artigo era redigido: uma captura inicial dessa página retornou "No readme", e uma captura quarenta minutos depois retornou uma descrição completa escrita pela Liquid AI, com uma tabela de benchmark e uma seção de licença. Se você quer um evento datado e verificável dos últimos sete dias, é esse cabeçalho.

O que o registro realmente aceitou

Quatro tags resolvem para duas imagens, que é a primeira coisa a entender antes de fazer o pull. d1-omni:latest, d1-omni:600m e d1-omni:600m-q8_0 são o mesmo manifesto — digest 1ba59f63e836 — enquanto d1-omni:600m-bf16 é um segundo, digest c1e95fce6627. Não há tag F16, embora o repositório GGUF do próprio fornecedor publique um tronco F16.

• Camadas de pesos (build Q8_0) — um tronco de 407 MB de d1-omni-600M-Q8_0.gguf mais um projetor de 442 MB de mmproj-d1-omni-600M-BF16.gguf, com um blob de licença de 10,5 KB e um blob de parâmetros de 18 bytes, totalizando 849.659.968 bytes.

• Tamanho informado — 850 MB para a tag padrão e 1,2 GB para 600m-bf16, ambos conforme impresso na página da biblioteca.

• Requisito mínimo de runtime — requer: 0.40.4 no blob de configuração, que também informa model_family: lfm2, model_type: 380.73M e tipo de arquivo Q8_0.

• Contexto — o blob de parâmetros fixa num_ctx em 16.384.

• Licença — o texto incorporado é a LFM Open License v1.0, que nomeia a Liquid AI, Inc. como licenciante, correspondendo ao identificador lfm1.0 no cartão do modelo.

Esse projetor merece uma segunda olhada, porque é maior que o modelo ao qual está anexado. A leitura direta dos metadados GGUF no blob do registro mostra clip.has_vision_encoder = True e clip.has_audio_encoder = True no mesmo arquivo: 197 tensores de visão em 12 blocos, com embeddings de 768 dimensões e entradas de 256 pixels, e 641 tensores de áudio em 17 blocos, com embeddings de 512 dimensões e 128 bins mel. Trata-se da torre SigLIP2 e do codificador FastConformer viajando juntos no pacote multimodal, e é por isso que um tronco de 381M parâmetros vem atrás de um anexo de 442 MB. A capacidade de áudio está fisicamente no pacote que você baixa; a questão de saber se o endpoint consegue alcançá-la vem depois.

O modelo tem 587M de parâmetros e o selo de 125K é maior do que a verdade.

A página do Ollama anuncia uma “janela de contexto de 125K” em todas as tags. O próprio num_ctx do pacote é 16.384, e a ficha do modelo da Liquid AI diz o mesmo em palavras: 16.384 tokens abrangendo posições de texto, imagem e áudio em conjunto, com o estado e o texto da pergunta cortados para 896 tokens sempre que há imagens presentes. O número de 125K é rastreável — o GGUF do tronco carrega lfm2.context_length = 128000 —, mas é o teto da arquitetura, não a janela que você obtém, e é o número com maior probabilidade de induzir alguém a erro ao dimensionar um substituto para um classificador de contexto longo. Considere 16.384 como o valor prático e 896 tokens de texto como o valor prático quando houver uma imagem no estado.

O restante dos metadados corrobora o cartão do modelo, e não o texto de marketing. O tronco tem 18 blocos, embeddings de 1.024 de largura e um vocabulário de 65.536, e não é um decodificador: lfm2.attention.causal é False. As contagens de cabeças KV por camada são 0, 0, 8, 0, 0, 8, …, o que significa que a maioria desses blocos não são blocos de atenção de modo algum, é a ancestralidade de codificador bidirecional transparecendo. A cabeça de decisão tem dois blocos (lfm2.decision.block_count = 2), e as constantes de calibração que o fornecedor mantém em config.json também estão neste GGUF — perguntas de escolha trazem uma temperatura de 1,7465 com duas opções, 1,3999 com três a cinco, 1,1751 com seis a dez e 1,3725 acima de onze; sim/não é 1,6663; perguntas pontuadas são 1,7301 em três a cinco níveis e 1,0 em seis a dez. Esse é o design inteiro em um só lugar: um conjunto fixo de respostas nomeadas, pontuadas em uma única passagem, calibradas por formato de pergunta, com output_tokens: 0 no final.

Não é um modelo de chat e não escreve texto. A Liquid AI lista quinze idiomas, coloca os dados de treinamento de áudio apenas em inglês — solicitações entre um locutor e um assistente — e limita os clipes a 30 segundos. O cartão também alerta contra bfloat16 em GPUs: nas próprias verificações do fornecedor, ele alterou a resposta principal em 0,8% das linhas de texto e 1,7% das linhas de áudio, enquanto float16 correspondia a float32 em todos os casos.

O áudio está nos pesos e está ausente da API documentada.

Esta é a discrepância que vale a pena conhecer antes de registrar um bug. O README da página da biblioteca, escrito pela Liquid AI, documenta áudio inserindo um WAV em base64 dentro do array images de uma requisição /v1/systemone. O README GGUF no Hugging Face do fornecedor para o mesmo checkpoint documenta isso de forma diferente, com um array files carregando data:audio/wav;base64,… para o servidor llama.cpp. E a referência de endpoint publicada pela Ollama não documenta nenhum dos dois: seu esquema de requisição tem state, images, questions e keep_alive, descreve images como "Requer um modelo com visão, como o Clef", e não contém nenhum campo de áudio e nenhum campo files. Enquanto isso, o próprio guia de modelos de decisão da Ollama nomeia Nimble, Tev1, Clef e Clef Flash como os modelos de decisão e diz apenas que os modelos Clef também podem julgar imagens.

A posição honesta sobre áudio no Ollama hoje é: o codificador foi verificado como presente no blob, o readme do fornecedor diz que ele funciona por meio de imagens, e o esquema publicado não o admite. A entrada de imagem no mesmo modelo está em terreno mais firme — a visão é uma capacidade documentada do System One e o d1-omni aparece na listagem da categoria de visão do Ollama. Duas lacunas menores de documentação acompanham essa: a referência do endpoint permite até 255 chaves de opção em uma pergunta de escolha, enquanto o guia de decisão diz de 2 a 26, e o piso de runtime do pacote, 0.40.4, é superior ao 0.35.0 citado pela documentação do endpoint.

Arquivado em visão, não em decisão

A busca de modelos do Ollama filtra os modelos de decisão para uma categoria própria. Ela contém nove entradas — nimble-v3, pplx-decider, kev, tev1, nimble, clef-flash, clef, laya e strands-decider — e nem d1 nem d1-omni está entre elas. A página do d1-omni está marcada com as tags vision e 600m e de fato aparece na listagem de vision, então um leitor que procura por "modelo de decisão" não encontrará o mais novo. Isso é um problema de descoberta, não de capacidade, mas importa se você estava planejando comparar as famílias de decisão no próprio catálogo do Ollama e concluiu que este não existia.

O que isso também significa é que o d1-omni é o primeiro modelo de decisão na biblioteca do Ollama que consegue receber fala — o codificador de áudio está no pacote e nenhum outro item daquela lista de nove modelos possui um. Se o endpoint vai ou não entregar seu WAV a ele é a questão em aberto da seção acima, e é a única coisa mais provável de ter mudado até o momento em que você ler isto.

Os números, e quem produziu cada um deles

Toda métrica de acurácia atribuída ao Liquid AI d1-omni-600M é da própria Liquid AI, e não existe nenhuma avaliação independente de qualquer modelo d1 até onde conseguimos encontrar — nenhuma linha em leaderboard, nenhuma execução por terceiros, nenhuma rejeição publicada da pontuação do fornecedor. O fornecedor pontuou ambos os checkpoints d1 por conta própria com o scorer oficial do Decision Index, em vez de submetê-los ao leaderboard público, e afirma isso no card; cada linha concorrente em sua tabela vem do leaderboard v0.2.1, o que significa que a comparação é um número autoavaliado colocado ao lado de números avaliados externamente.

• Decision Index 0.2.1 — 15,95 para d1-omni-600M (conhecimento 8,3, linguagem 12,9, recuperação 35,0, ferramentas 15,1, artes 6,8) contra 48,57 para d1-3B.

• Benchmarks como decisões, média de sete — 78,4 para o d1-omni-600M contra 82,9 para o d1-3B, com o modelo 600M à frente em Civil Comments (95,8 vs 93,0) e PAWS-X (79,5 vs 76,9) e atrás em BoolQ (77,7 vs 86,7) e SQuAD 2.0 (74,0 vs 85,3).

• Fast Decisions, divisão de dev — 76,9, informado pelo fornecedor, nenhuma linha de comparação publicada.

• Velocidade — nada. O card declara claramente que os números de inferência não são reportados porque este é um lançamento de pesquisa inicial em desenvolvimento ativo, então qualquer alegação de latência que você veja para ele em outro lugar é medição própria de alguém.

• Números de fixture na página do Ollama — o exemplo prático do readme mostra urgent respondido em 0,998 e technical em 0,995. Esses são resultados ilustrativos de uma única requisição, publicados pelo runtime, e não constituem um benchmark.

A diferença entre 15,95 e 48,57 é a coisa mais útil no cartão, porque resolve a questão da compra nas próprias palavras do fornecedor: o readme diz para usar o d1 quando a precisão em texto e imagens é o que importa e para recorrer ao d1-omni quando o tamanho importa ou você precisa de áudio. Um modelo de 587M que pontua 78,4 em sete benchmarks públicos, reinterpretado como decisões, é um classificador de borda plausível. Ele não é uma versão menor do 3B.

Onde o OrcaRouter se encaixa, e onde não

Não disponibilizamos este modelo. Uma verificação do nosso catálogo em 18 de outubro retornou 208 IDs de modelos e nenhum deles é da Liquid AI, portanto nada aqui constitui uma alegação de disponibilidade e não há nenhum caminho do nosso lado para obtê-lo. Se você quiser Liquid AI d1-omni-600M, o caminho local é o descrito acima, e o caminho hospedado é a própria API do fornecedor e quaisquer plataformas de terceiros que o adotem.

O que o empacotamento muda é a forma do sistema ao seu redor, e é aí que somos úteis. Um modelo de decisão quase nunca é todo o pipeline: o ticket que ele rotula, o frame que ele sinaliza e a transcrição que ele encaminha ainda precisam ser respondidos, resumidos ou escalados por algo que escreve texto. Essas chamadas generativas ficam por trás de uma única chave compatível com OpenAI para mais de 200 modelos hospedados pelo preço de tabela do provedor, repassado com 0% de margem, para que uma mudança de preço do fornecedor chegue até você no mesmo dia, e não em um novo contrato. E, como o d1-omni-600M é lançado sem evidência independente de precisão e sem latência publicada, a maneira certa de colocá-lo diante de tráfego real é por trás de failover automático entre provedores — deixe-o lidar com as chamadas sobre as quais tem confiança e mantenha uma rota de saída quando não tiver, em vez de transformar 587M de parâmetros em um ponto único de falha para sua etapa de triagem. A decisão permanece local; o fallback não precisa ser.

O que mudaria essa leitura?

Quatro coisas, qualquer uma das quais transformaria uma nota de embalagem em um artigo diferente. A Ollama documentar áudio no esquema de requisição do System One, o que converteria o truque de WAV em imagens do readme em uma entrada suportada e faria deste o primeiro modelo de decisão capaz de fala que você pode executar com um único comando. Qualquer uma das empresas reconhecendo o porte — a Liquid AI adicionando o d1-omni à página da Ollama em sua documentação de implantação, ou a Ollama listando-o em modelos de decisão em vez de visão. Um número de velocidade de qualquer pessoa, fornecedor ou não, já que nenhum existe hoje. E uma linha independente do Decision Index para qualquer modelo d1, que continua sendo a única peça faltante em toda a família.

Até lá, a decisão é simples. Se você já executa o Ollama na versão 0.40.4 ou posterior, o pull é um único comando, o download é de 850 MB, e o que você obtém é um classificador de 587M que responde a perguntas digitadas em uma única passagem direta sobre texto e imagens — e, se o readme estiver certo, sobre mais de 30 segundos de fala em inglês. Se o seu estado for longo, tenha em mente a janela de 16.384 tokens e o orçamento de texto de 896 tokens, em vez do selo de 125K. E, se você precisa de evidências de que ele é preciso antes de rotular qualquer coisa que um cliente veja, essas evidências ainda não existem, para este modelo ou qualquer um de seus irmãos.

As falhas documentadas de IA e os incidentes com agentes por trás de lançamentos como este estão reunidos em o OrcaRouter AI Incident Archive, onde cada entrada traz suas próprias fontes, gravidade, grau de confiança e sinalização de contestação.