d1-omni vs Liquid AI D1 Omni 600M: Dois nomes, um checkpoint e um número de contexto cuja fonte ninguém consegue identificar

Liquid AI D1 Omni 600M e d1-omni não são dois modelos, e também não são dois checkpoints do mesmo modelo. São um único conjunto de pesos — o modelo multimodal de decisão de 587 milhões de parâmetros da Liquid AI, construído sobre o Liquid AI LFM2.5-Encoder-350M e publicado no Hugging Face em 5 de outubro de 2026 sob o nome de repositório LiquidAI/d1-omni-600M — carregando dois nomes de arquivo diferentes em dois catálogos diferentes. Um desses catálogos, o do fornecedor, informa o que o modelo é. O outro, o da Ollama, informa em que alguém o empacotou e imprime no cartão três números que a documentação do fornecedor não sustenta. Essa lacuna é o motivo principal pelo qual esta comparação vale a pena ser lida, porque, para um modelo deste tamanho, o empacotamento não é uma nota de rodapé — é a diferença entre um modelo de texto e imagem e o modelo que o cartão diz que você baixou.

O fornecedor não anunciou nada sobre a entrada do Ollama, e não há nota do mantenedor, entrada de changelog nem readme na página do Ollama que explique qualquer parte disso. Portanto, o enquadramento honesto para tudo o que segue é este: os pesos são públicos e inspecionáveis, o empacotamento é público e inspecionável, e a leitura do empacotamento aqui apresentada é nossa, não da Liquid AI. Quando um número não puder ser rastreado até uma fonte, este texto diz isso em vez de repeti-lo.

Quais são, na verdade, os dois nomes

A Liquid AI publicou o modelo no Hugging Face com carimbo temporal de criação em 5 de outubro de 2026, dois dias antes de ele aparecer na postagem no blog do próprio fornecedor "Open d1: modelos de decisão de borda para texto, visão e áudio" em 7 de outubro. Os pesos estão licenciados sob os termos LFM 1.0 da própria Liquid, marcados com d1_omni, system-one, multimodal, vision, audio e decision-model, e atraíram aproximadamente 13.900 downloads e 135 curtidas no momento da redação. As variantes quantizadas seguiram seu próprio cronograma: um repositório GGUF em 6 de outubro, compilações MLX para Apple Silicon em 12 de outubro.

A entrada do Ollama não é nenhum desses repositórios. É uma página da biblioteca do Ollama chamada d1-omni que traz o selo "vision 600m", mostra quatro tags e havia sido atualizada minutos antes de este texto ser escrito — e é por isso que o radar a detectou. Nada nela menciona a Liquid AI, o LFM2.5-Encoder-350M ou o repositório do Hugging Face de onde os bytes vieram.

Então, a diferença prática é um nome de arquivo e um caminho de distribuição, não um modelo. O que difere, e o que importa, são os metadados que envolvem os bytes.

Os três números no cartão Ollama, verificados um de cada vez

A página do Ollama exibe um tamanho, uma janela de contexto e uma lista de entradas para cada tag. Todos os três merecem uma segunda olhada, porque, neste modelo, dois deles não resistem ao contato com a fonte.

• Janela de contexto — 125K no cartão, 16.384 em todas as fontes do fornecedor. O cartão de modelo da Liquid AI declara um teto de 16.384 tokens que abrange conjuntamente posições de texto, imagem e áudio, e a própria página de documentação do fornecedor para o d1-omni-600M diz "16K tokens". A string 125K não aparece em nenhuma delas. Pode ser um artefato da configuração posicional da arquitetura subjacente LFM2.5-Encoder ou de como o Ollama relata um limite de cache, mas não é um número publicado pela Liquid AI e não é um que este artigo possa atribuir a ninguém. O que torna a discrepância mais do que pedante é o próximo número abaixo.

• O estado que você pode realmente passar é limitado a 896 tokens no caminho de imagem. O cartão da Liquid diz que, quando há imagens presentes, "o texto do estado e da pergunta é cortado para 896 tokens, conforme treinado". Assim, uma solicitação de decisão que carrega uma foto tem um orçamento de texto aproximadamente do tamanho desta frase, não importa qual número de contexto esteja impresso em uma página de referência. Se você estivesse dimensionando um prompt de triagem para 125K e esperando pagar por um estado longo, estaria se baseando em um número que não descreve o runtime. O número 16.384 é o teto real; o número 896 é o limite prático real para o caminho multimodal; os 125K são um número sem documentação.

• Tamanho — 850 MB no cartão, dois arquivos no registro. A tag do Ollama d1-omni:latest resolve para um arquivo de pesos quantizados de 407 MB designado Q8_0, mais um arquivo projetor de 442 MB designado BF16, e 407 + 442 = 849, que a página arredonda para 850 MB. Ambos estão listados honestamente; a aritmética é apenas a soma de um emparelhamento de precisão mista, e não de um único arquivo. A tag d1-omni:600m-bf16 é a mais limpa: 764 MB de pesos BF16 mais o mesmo projetor de 442 MB, 1,2 GB em disco, e o projetor é idêntico byte a byte entre as duas tags. Vale a pena observar para a próxima seção, porque um projetor que carrega os próprios pesos pode alterar a contagem efetiva de parâmetros.

Mais um detalhe que vale a pena registrar em vez de explicar: o blob de parâmetros de runtime dentro do pacote d1-omni do Ollama tem exatamente o mesmo comprimento — 18 bytes — que o do pacote d1 separado do Ollama, que traz o Liquid AI d1-3B com 2,87GB de pesos Q8_0 e um projetor de 855MB. Duas arquiteturas, duas contagens de parâmetros, duas décadas de escala de parâmetros entre elas, e a mesma configuração de runtime de 18 bytes. Isso é uma constante de empacotamento, não uma afirmação sobre qualquer um dos modelos.

O que os próprios pesos dizem

Tirando a embalagem, o modelo é excepcionalmente bem documentado. O Liquid AI D1 Omni 600M totaliza 587M de parâmetros divididos em três partes: um tronco compartilhado e cabeça de decisão de 381M, um codificador de visão de 94M e um codificador de áudio de 112M. O tronco é bidirecional — este é um codificador, não um decodificador — e é o mesmo tronco para todas as modalidades, com torres específicas por modalidade acopladas.

• Visão vem de uma torre SigLIP2 herdada do Liquid AI LFM2.5-VL-450M, com um adaptador e atualizações LoRA que estavam ativas apenas para entradas de imagem, enquanto o próprio codificador permaneceu congelado.

• Áudio vem de um FastConformer de 17 camadas com seu próprio adaptador, ajustado em uma etapa em que o backbone de texto estava congelado, depois toda a pilha foi ajustada, o LoRA foi mesclado e os pesos foram calculados pela média em relação ao checkpoint anterior.

• O vocabulário tem 65.536 tokens em 15 idiomas: inglês, alemão, espanhol, francês, italiano, holandês, polonês, português, árabe, hindi, japonês, russo, turco, vietnamita e chinês.

• As modalidades não podem ser misturadas. Uma única solicitação usa texto mais imagens, ou texto mais até 30 segundos de fala — não ambos. O áudio deve estar em 16kHz mono, entre 0,5 e 30 segundos, e foi treinado em trocas entre um falante de inglês e um assistente, o que é uma restrição real para qualquer coisa multilíngue ou ruidosa.

Nada disso aparece na página do Ollama, e a omissão tem uma consequência que você pode ver diretamente nos exemplos de uso. Os trechos do Ollama são chamadas de chat — uma string de modelo, um array de mensagens, a palavra "Hello!" — e o checkpoint subjacente não consegue respondê-las. Ele não é um modelo de chat e não escreve texto. Ele retorna respostas tipadas: uma probabilidade de sim/não, um rótulo com uma probabilidade por rótulo, ou uma posição em uma escala ordenada, todas lidas diretamente da distribuição de saída com zero tokens de saída gerados. As interfaces publicadas refletem isso: system_one e probabilities via Transformers, ou um /v1/systemone endpoint via llama.cpp 0.7.0 e posteriores. Uma chamada em formato de chat contra um modelo de decisão é o erro que essa lacuna de nomenclatura convida.

Duas ressalvas acompanham cada um desses números.

Primeiro, a Liquid pontuou suas próprias linhas com o avaliador oficial em vez de submetê-las ao ranking público, e nenhum terceiro reproduziu qualquer resultado do d1-omni-600M — o fornecedor declara claramente na ficha do modelo que não informa números de inferência para este checkpoint porque se trata de uma versão inicial de pesquisa em desenvolvimento ativo. Segundo, os dois números principais divergem entre si: a diferença de 32 pontos no índice e a diferença de 4.5 pontos na média do benchmark descrevem o mesmo modelo, e é por isso que as pontuações parciais, e não os totais, são a leitura útil. Retrieval em 35.0 e Tools em 15.1 versus Arts em 6.8 mostram para quais tarefas este checkpoint está e não está pronto. Áudio não tem nenhuma coluna de benchmark; a Liquid chama os benchmarks dedicados de decisão em áudio de problema em aberto.

Liquid AI D1 Omni 600M também lidera sua própria família em duas das sete: Civil Comments com 95,8 e PAWS-X com 79,5. Essas são as duas linhas em que um encoder de 587M supera diretamente o decoder de 3B, e ambas têm formato de classificação de texto em vez de raciocínio — o que se ajusta à arquitetura em vez de contradizê-la.

Escolha pelo que você precisa. Se quiser executá-lo localmente no Ollama, d1-omni é o nome que funciona — 850 MB para a versão Q8_0, 1,2 GB para BF16, o mesmo caminho de imagem documentado pela Liquid, e nenhuma das tags traz um projetor de áudio. Se você quer o modelo que o fornecedor descreve, Liquid AI D1 Omni 600M é o nome a buscar, e a rota Transformers pelo repositório do Hugging Face é a que tem comprimento de contexto, lista de modalidades e contagem de parâmetros compatíveis com a documentação.

De qualquer forma, esta é a metade barata de um pipeline. O modelo de decisão classifica; algo mais precisa agir com base na classificação. Essa é a fronteira em que o OrcaRouter se situa e a que vale declarar com precisão: nenhum modelo da Liquid AI está no nosso catálogo, então a própria chamada d1-omni vai para onde você já a executa — seja esses pesos no seu próprio hardware, seja na API do próprio fornecedor e em plataformas de terceiros para as variantes hospedadas. A finalidade dos mais de 200 modelos por trás de uma única chave compatível com OpenAI é tudo o que vem depois, a preço de tabela de cada provedor repassado com 0% de margem, com failover automático entre provedores quando uma solicitação triada se ramifica para um modelo que está tendo um dia ruim.

O que resolveria a questão em aberto

Três coisas encerrariam essa questão, e nenhuma delas exige um anúncio do fornecedor. Alguém comparando a saída da tag de 850 MB do Ollama com o checkpoint do Hugging Face nas mesmas entradas nos diria se o empacotamento mudou as respostas. Um commit do llama.cpp ou uma entrada no changelog do Ollama explicando o número de contexto nos diria se 125K é um erro ou uma capacidade que o model card ainda não acompanhou. E um resultado de áudio publicado — qualquer resultado de áudio — tiraria este checkpoint da categoria em que ele está hoje, que é a de um modelo bem documentado com uma camada de empacotamento não documentada e um placar inteiramente do próprio fornecedor.

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.