Liquid AI d1 vs Liquid AI d1-omni-600M: O Modelo de Decisão Aberto Que Consegue Ouvir Você

Pesquise pelo nome Liquid AI d1 e você chegará a um modelo de três bilhões de parâmetros que lê texto e imagens. O outro checkpoint aberto da mesma família tem um quinto do tamanho, considera até trinta segundos de fala e é o único dos dois que consegue decidir qualquer coisa sobre uma voz. Ele se chama Liquid AI d1-omni-600M, e se você encontrou a família por meio de uma biblioteca de runtime local em vez da documentação do próprio fornecedor, há uma boa chance de você nunca ter visto o nome dele. É essa a situação que esta comparação existe para corrigir, porque os dois modelos não são respostas concorrentes para a mesma pergunta. Eles são respostas para duas perguntas diferentes, e só uma delas envolve escutar.

Todo número abaixo vem do próprio material da Liquid AI: o model card do LiquidAI/d1-omni-600M, o repositório complementar d1-omni-600M-GGUF e o post de lançamento de 7 de outubro que anunciou ambos os checkpoints abertos de uma só vez. As linhas de desempenho foram pontuadas pelo fornecedor em um índice que ele mesmo mantém, em vez de submetidas a classificação pública, e o post afirma explicitamente que benchmarks dedicados de decisão em áudio são um problema em aberto. Nada aqui foi reproduzido por ninguém fora do laboratório.

Do que são feitos 587 milhões de parâmetros

O número de destaque esconde uma divisão incomum. O total de parâmetros chega a 587M, e eles não formam uma única pilha: um tronco compartilhado de 381M com a cabeça de decisão acoplada, um codificador de visão de 94M e um codificador de áudio de 112M. Cada modalidade passa pelos mesmos pesos do tronco, que é a decisão de design que mantém o todo pequeno — o modelo não são três modelos vestindo um sobretudo, é um tronco decisor com duas formas de alimentá-lo.

As peças vêm de lugares diferentes no catálogo da Liquid. O tronco descende do LFM2.5-Encoder-350M, um encoder bidirecional, e não da linha apenas decodificadora de onde veio o irmão maior. A torre de visão é um SigLIP2 extraído do LFM2.5-VL-450M com um adaptador e atualizações LoRA aplicadas ao backbone. O caminho de áudio é um encoder FastConformer de 17 camadas com seu próprio adaptador, ajustado com fine-tuning em relação a um backbone de texto congelado. O card informa um contexto de 16.384 tokens compartilhado entre posições de texto, imagem e áudio em conjunto, com o texto reduzido a 896 tokens quando há imagens, e um vocabulário de 65.536 tokens — metade dos 128.000 do seu irmão maior. Vale a pena notar esse último número se você trabalha com um idioma que a família cobre apenas parcialmente.

Bidirecional versus somente decodificador é a razão pela qual os dois modelos parecem diferentes para qualquer pessoa que já tenha executado ambos. O tronco em formato de codificador lê todo o estado de uma vez, em ambas as direções, antes de produzir qualquer coisa. O em formato de decodificador lê para frente do modo como um modelo de linguagem faz. Ambos são treinados para relatar respostas a partir de uma distribuição com zero tokens de saída, então nenhum dos dois escreve texto — mas a maquinaria por baixo é uma classe diferente de modelo, e a lacuna de precisão discutida abaixo é o custo visível do design menor, em formato de codificador.

Trinta segundos de fala, e nada com que pontuá-la.

O áudio é a razão pela qual este checkpoint existe. Ele aceita um único clipe de até 30 segundos, mono de 16 kHz, na mesma passagem direta que produz a resposta, e é o único membro de pesos abertos da família capaz de fazê-lo. Para trabalho em dispositivo, isso não é uma característica marginal. Uma câmera que sinaliza um defeito numa linha de produção é um problema de visão que o irmão maior já resolve; um dispositivo que encaminha um pedido falado, classifica uma fala ou decide se um interlocutor está pedindo um reembolso é um problema para o qual só este pode ser apontado.

Duas restrições recaem sobre essa capacidade e ambas estão documentadas, o que significa que não há desculpa para tropeçar nelas em produção. Primeiro, uma requisição carrega imagens ou áudio, nunca ambos — passar ambos gera um ValueError em vez de descartar um silenciosamente, então a falha é ruidosa e barata de encontrar em testes. Segundo, o caminho de áudio foi treinado em trocas entre um falante de inglês e um assistente, com os clipes cortados em 30 segundos. Essa é uma única geometria de falante, uma única estrutura de turnos e uma única distribuição de sotaques. Apontá-lo para gravações de central de atendimento ou áudio de campo é esperar um comportamento que o card não afirma, e é exatamente o tipo de lacuna que um benchmark evidenciaria se existisse.

Nenhum existe. O post de lançamento chama os benchmarks dedicados de decisão de áudio de "um problema em aberto no momento" e convida a comunidade a criar um, o que é uma coisa franca para um laboratório escrever e uma restrição real para quem avalia o modelo. Liquid AI d1-omni-600M está sendo solicitado a justificar-se com base na força de uma capacidade que ninguém consegue medir ainda. O fornecedor também omitiu completamente os números de inferência, sob a alegação declarada de que o modelo é um lançamento de pesquisa inicial em desenvolvimento ativo. Portanto, não há nenhum número de latência para o 600M — nem para texto, nem para visão, e nem para o caminho de áudio, que é o ponto central.

O que pode ser dito sem inventar nada é aritmética sobre a contagem de parâmetros publicada: na precisão float16 que o card recomenda para GPUs, 587M de parâmetros está na ordem de 1,2 GB de pesos antes das ativações, contra aproximadamente 6,2 GB para o modelo irmão de 3,12B na mesma precisão. O card também traz um aviso de precisão que é fácil de passar batido e que não deveria ser: o modelo foi treinado em float32, float16 é recomendado em GPUs, e bfloat16 mudou a principal resposta em algumas linhas durante os testes. Se sua stack de serving usa bfloat16 por padrão, este é um modelo em que esse padrão não é seguro.

Por que é fácil não notar a metade menor da família

O motivo pelo qual um leitor chega ao 3B e para é estrutural, e não acidental. O índice de documentação da Liquid AI lista três linhas sob modelos de decisão e elas não se leem da mesma forma: d1-3B e d1-omni-600M trazem links do Hugging Face e GGUF com um "Não" na coluna treinável, enquanto d1 fica em sua própria linha com apenas as letras "API" onde estariam os links de download de todos os outros modelos. A postagem de lançamento chama d1 de nome de família e nunca distingue o endpoint servido do checkpoint aberto. As bibliotecas de runtime locais então adotam o 3B, porque é aquele cujo tamanho e número de modalidades correspondem à entrada que desejam publicar, e o 600M não aparece na mesma listagem de forma alguma.

O resultado é uma família cuja narrativa de acesso publicada, lida rapidamente, parece um modelo e uma linha de API. O que está realmente sendo oferecido são dois checkpoints abertos com trunks diferentes, modalidades diferentes e uma diferença de 32 pontos entre suas pontuações no índice do próprio fornecedor, além de um endpoint hospedado cuja relação com qualquer um dos checkpoints o fornecedor nunca confirmou. O 600M não está escondido atrás de nada. Ele simplesmente não tem um nome que uma busca por d1 encontre, e é o único dos dois que ouve.

As partituras que existem, e a única coluna que vale a pena ler

No Decision Index 0.2.1, o fornecedor reporta 15,95 para o Liquid AI d1-omni-600M contra 48,57 para o seu irmão maior — uma diferença suficientemente grande para que o total seja praticamente inútil como base de escolha. As subpontuações são mais informativas do que a soma, e uma delas é genuinamente surpreendente.

• Conhecimento — 8,3 contra 23,8

• Idioma — 12,9 contra 56,4

• Recuperação — 35,0 contra 52,8

• Ferramentas — 15,1 contra 74,5

• Artes — 6,8 contra 36,3

A recuperação é onde o modelo pequeno se mantém firme, perdendo menos de um terço da pontuação do modelo maior, ao passo que nas outras quatro colunas ele perde de 60 a 80 por cento. Esse padrão corresponde ao que um encoder treinado deveria fazer bem: fazer corresponder um estado a um conteúdo é próximo daquilo para o que o trunk foi construído, e depende muito menos da capacidade de linguagem em camadas que o irmão em formato de decoder herdou de muito mais pré-treinamento. A coluna Ferramentas é a história oposta, e uma diferença de 59 pontos ali é o número a encarar se a sua carga de trabalho for rotear uma requisição para a função correta.

Em sete benchmarks públicos de texto, o quadro se suaviza. O fornecedor relata uma média de 78,4 para o 600M contra 82,9 para o 3B, com o modelo pequeno perdendo por pouco no SQuAD 2.0 (74,0 contra 85,3), no PubMedQA (61,3 contra 66,0), no BoolQ (77,7 contra 86,7) e no XNLI (74,7 contra 85,0), enquanto vence na detecção de toxicidade do Civil Comments (95,8 contra 93,0) e na identificação de paráfrases do PAWS-X (79,5 contra 76,9). A própria Liquid enquadra a questão afirmando que o 600M supera a média de 77,1 de um modelo de decisão 2B com um quarto dos parâmetros. Duas suítes de benchmarks apresentam dois veredictos aparentes diferentes, ambos autorrelatados, e a leitura honesta é que nenhum dos dois resolve nada sobre o caminho de áudio, porque o caminho de áudio não está em nenhuma das duas suítes.

Onde os dois realmente se encontram

Apesar de toda a divergência, o modelo de programação é idêntico, e é isso que os torna intercambiáveis num sentido específico. Ambos respondem a perguntas noul, de escolha e de pontuação sobre um estado, ambos devolvem a resposta escolhida com um mapa de probabilidades e um valor de confiança entre 0 e 1, e ambos reportam output_tokens: 0. O campo de confiança é o que as pessoas interpretam mal: mede quão fortemente as probabilidades favorecem uma resposta, não a probabilidade de a resposta estar correta. Um 0,96 numa pergunta mal formulada é uma resposta errada com confiança, e o campo não o avisará.

Onde eles se encontram na prática é uma cascata. Faça a triagem com Liquid AI d1-omni-600M — de forma barata, localmente e incluindo os casos de áudio que nenhum avaliador apenas de texto consegue alcançar — e depois encaminhe os itens que ele coloca perto do meio de sua escala para o checkpoint maior, em busca de uma decisão mais precisa. As regras de escalonamento são a confiança e a distribuição que o 600M já retorna, então a lógica de roteamento não precisa de nenhum modelo extra e, numa carga de trabalho com uma forte maioria de itens fáceis, a maior parte do tráfego nunca chega ao segundo estágio. Essa composição funciona porque ambos os modelos retornam o mesmo tipo de objeto. Dois modelos arbitrários não o fariam.

Se essa cascata chegar a condicionar uma chamada a um modelo generativo que você aluga em vez de rodar, a camada por baixo é onde o encanamento fica interessante, e é também onde nós entramos. Encaminhar uma decisão por uma cadeia de modelos é exatamente o tipo de problema para o qual uma regra de roteamento serve: o OrcaRouter compõe vários modelos por trás de um único endpoint compatível com OpenAI, cada um ao preço de tabela do respectivo provedor, repassado com 0% de markup, com failover automático entre provedores para que um escalonamento que falha na camada do provedor tente novamente em um fallback em vez de fazer a requisição falhar. Não hospedamos nenhum modelo da Liquid AI — verificamos antes de escrever isto —, então nada acima é uma afirmação sobre chamar esses pesos por meio de nós. O ponto é que o modelo de decisão é a parte barata do pipeline e o modelo emprestado do outro lado é a parte que cai.

De onde vem o arquivo, se você quiser executá-lo hoje

Para implantação local, o próprio repositório GGUF do fornecedor para o 600M traz Q8_0 com 407 MB e F16 e BF16 com 764 MB cada, sem nenhuma build de 4 bits listada — portanto, o menor download oficial é cerca de sete vezes menor que a build correspondente do modelo maior e aproximadamente do mesmo tamanho que uma fotografia de média resolução. O próprio exemplo do card inicia um servidor llama.cpp com flags de batch de 4096 e sugere aumentá-las para 16384 para estados mais longos, depois consulta o mesmo endpoint /v1/systemone que o irmão maior usa.

A única coisa que a rota local não lhe dá são os números do caminho de áudio, porque eles não existem. Se você pretende passar fala por isto na frente de usuários reais, cabe a você construir a avaliação: um conjunto rotulado de clipes, os mesmos três tipos de perguntas e uma taxa de resposta medida por classe. Isso não é uma desqualificação do modelo — um checkpoint de 587M que decide sobre um clipe de voz em uma única passagem é uma ferramenta genuinamente diferente de um classificador de texto acoplado a uma etapa de transcrição, e merece um teste de verdade em vez de um baseado em vibes.

Se essa cascata algum dia condicionar uma chamada a um modelo generativo que você aluga em vez de executar, o OrcaRouter compõe vários modelos por trás de um único endpoint compatível com OpenAI , cada um pelo preço de tabela do seu provedor, repassado com 0% de acréscimo.

Escolher um checkpoint omni em vez do somente texto também é um bom momento para analisar o que já deu errado nesta classe: os incidentes de IA documentados e as falhas de agentes envolvendo pequenos modelos multimodais estão reunidos em o OrcaRouter AI Incident Archive, onde cada entrada traz suas próprias fontes, gravidade, grau de confiança e flag de disputa.