Liquid AI d1 vs Liquid AI d1-3B: o que a Biblioteca Ollama chama de um modelo e o fornecedor chama de dois

Há duas maneiras de nomear o mesmo conjunto de pesos, e Liquid AI d1 e Liquid AI d1-3B ilustram a diferença melhor do que qualquer comparação de parâmetros conseguiria. Retire um hífen e um sufixo de tamanho do segundo nome e você obtém o primeiro, então é tentador tratar a string mais curta como um apelido. Os dois catálogos que de fato listam esses modelos não concordam com essa leitura. O próprio índice de documentação da Liquid AI mantém d1 em sua própria linha com as letras "API" onde ficam os links de download, e mantém d1-3B e d1-omni-600M em um par separado de linhas com links funcionais do Hugging Face e GGUF e um "Não" na coluna "treinável". O Ollama, cuja entrada na biblioteca é a razão pela qual vale a pena escrever sobre este par, reduz tudo isso a uma única página chamada d1, descreve-a em uma única linha como "um modelo de decisão de 3B da Liquid AI, construído sobre LFM2.5-VL-3B," e oferece exatamente três tags abaixo. Comparar Liquid AI d1 com Liquid AI d1-3B não é, portanto, uma comparação entre um endpoint hospedado e um checkpoint aberto, e também não é uma comparação entre dois checkpoints. É uma comparação entre um endpoint hospedado e o checkpoint aberto que o ecossistema de runtime local decidiu que é d1 quando você diz a palavra sem qualificação. A maior parte do que segue trata de qual dessas leituras sua implantação realmente depende.

Uma nota sobre como os números abaixo são obtidos, já que a honestidade importa mais do que a formatação disso. Tudo o que é numérico aqui é relato da própria Liquid AI, nos cartões de modelo ou no post de lançamento de 7 de outubro. As linhas do Decision Index foram pontuadas pelo fornecedor com o pontuador oficial, em vez de submetidas para classificação pública, e nenhum terceiro reproduziu independentemente qualquer resultado do d1 que conseguimos encontrar. Quando um número é uma operação aritmética sobre um valor publicado em vez de uma medição, isso é indicado.

De onde vêm os dois nomes

O nome mais curto é mais antigo. A publicação da Liquid AI de 5 de outubro apresentou o modelo como Liquid AI d1 — "nosso primeiro modelo de decisão", multimodal nesse lançamento, respondendo a perguntas digitadas sobre um estado de texto, imagens ou ambos, em uma única passagem direta com zero tokens de saída. Essa publicação indica um preço de serviço hospedado de US$ 0,04 por milhão de tokens de entrada, cobra apenas tokens de entrada e observa que imagens são cobradas como texto, a 1,5 tokens por patch de 32×32, então uma imagem de 1024×1024 custa 1.536 tokens. Ela também informa a latência de decisão de texto como 200–300 ms. Esses são números de serviço hospedado, e a publicação deixa explícito que o runtime por trás deles é o endpoint de decisão do próprio fornecedor em api.liquid.ai/decisions/v1/systemone.

O nome mais longo aparece na publicação de 7 de outubro e no Hugging Face, e é ele que carrega o detalhe reproduzível: 3,12B de parâmetros, um contexto de 32.768 tokens, um vocabulário de 128.000 tokens, dezesseis idiomas documentados, um codificador de visão de 400M otimizado para forma SigLIP2 NaFlex, e a cadeia base LFM2.5-2.6B-Base → LFM2.5-VL-3B → d1-3B. Esse cartão também afirma claramente que o modelo não é um modelo de chat e não escreve texto. Este é o checkpoint sobre o qual todo o ecossistema local é construído: o repositório GGUF carrega Q4_K_M com 1,67 GB, Q8_0 com 2,87 GB, e F16 e BF16 com 5,4 GB cada.

O que nenhum documento do fornecedor declara abertamente é que Liquid AI d1 e Liquid AI d1-3B são os mesmos pesos. O índice da documentação atribui a eles linhas separadas. A publicação de lançamento chama d1 de uma família, não de um checkpoint. Análises de terceiros notaram a lacuna e observaram que o fornecedor não confirmou a identificação. Portanto, a declaração honesta é curta: os números com os quais os dois nomes são publicados não entram em conflito em nenhum lugar que consigamos encontrar, o lançamento da família e o endpoint servido foram anunciados com dois dias de diferença, com uma descrição compatível, e o fornecedor não disse que são o mesmo modelo. Trate a equivalência como uma hipótese de trabalho razoável e não como um fato que o fornecedor endossou.

O que o build local de fato altera

A entrada do Ollama não é um relançamento nem um novo checkpoint. É uma decisão de empacotamento, e o empacotamento impõe três restrições que a documentação do próprio fornecedor não menciona de forma alguma. A primeira é a lista de tags: d1:latest, d1:3b e d1:3b-q8_0, três tags que nomeiam uma única quantização. O repositório GGUF que a Liquid publica traz quatro precisões, e o Q4_K_M de 1,67 GB — aquele que a maioria das pessoas escolheria em um notebook — não está entre as tags do Ollama. O que você consegue baixar é o Q8_0 de 2,87 GB e o que ele ocupa depois de expandido no armazenamento local; a página da biblioteca informa o download como 3,7 GB.

O segundo é o contrato de requisição. O Ollama responde a esses modelos em /v1/systemone, recebe um state mais um objeto questions e retorna respostas tipadas com output_tokens: 0. Esse é o mesmo formato usado pelo endpoint hospedado do fornecedor, e é isso que faz a alternância entre local e hospedado ser uma mudança de configuração, e não uma reescrita. A terceira restrição está na documentação de endpoints da Ollama, e não na página do modelo, e é mais restrita do que a de um modelo generativo: as requisições devem caber em 64 KiB sem imagens e 32 MiB com elas, não há suporte a streaming, modelos hospedados na nuvem são rejeitados, e as imagens devem estar em base64 no formato PNG, JPEG ou WebP no corpo da requisição — URLs remotas são recusadas. As imagens são compartilhadas por todas as perguntas de uma requisição, então uma imagem que você quer que apenas uma resposta considere precisa de uma chamada própria. A entrada nunca é truncada, o que significa que um state grande demais retorna um erro em vez de ser cortado silenciosamente. Esse é o modo de falha preferível, e ainda é um modo de falha que seu cliente precisa tratar.

Dois detalhes da documentação permanecem sem resolução e vale a pena conhecê-los antes de registrar um bug. A referência de endpoint da Ollama descreve o tipo de pergunta de escolha como aceitando de 2 a 255 chaves de opção, enquanto sua página de capacidades de modelos de decisão diz de 2 a 26; um dos dois está desatualizado. E a página de capacidades lista seus modelos suportados como Nimble, Tev1, Clef e Clef Flash, sem qualquer menção a d1 — embora o próprio readme do pacote d1 documente suporte a /v1/systemone e --ask, e o pacote exija Ollama 0.40.4, enquanto o mínimo documentado do próprio endpoint é 0.35.0. Leia o requisito de versão no pacote, não o que está no guia.

Os números, e sob qual nome foram publicados

Esta é a parte do emparelhamento mais fácil de errar, porque ambos os nomes são publicados com números de desempenho e os números não estão organizados da forma que se esperaria.

• Decision Index 0.2.1 — 48,57, publicado sob Liquid AI d1-3B. A Liquid descreve-o como a melhor pontuação para um modelo de decisão com menos de 10B parâmetros e coloca-o à frente de um modelo 35B-A3B com 47,11. • Latência de decisão de texto — 200–300 ms, publicado sob Liquid AI d1 na publicação da API hospedada. Não há um valor equivalente associado ao próprio nome do checkpoint aberto. • Latência de pergunta única em hardware local — 8 ms numa RTX 4090, 16 ms num Jetson AGX Thor, 26 ms num Jetson AGX Orin 64 GB, 50 ms num Orin Nano, 30 ms num Apple M5 Pro. Publicado sob Liquid AI d1-3B. • Vazão — 475 decisões por segundo na RTX 4090 e 1.106 por segundo numa AMD MI325X com perguntas agrupadas em lotes. Publicado sob Liquid AI d1-3B. • Visão — uma média de 74,1 em onze benchmarks públicos de imagens, contra 73,9 para a base LFM2.5-VL-3B a partir da qual foi construído. Publicado sob Liquid AI d1-3B. • Ablação de imagem — o mesmo conjunto de perguntas respondido com as imagens removidas obtém 45,1, que é a medida do próprio fornecedor sobre o que a via de visão contribui. Publicado sob Liquid AI d1-3B.

Dois problemas decorrem dessa lista e nenhum deles é fatal, que é exatamente por isso que passam despercebidos. O valor hospedado e o valor local diferem por um fator de 25 a 37 — 200–300 ms contra 8 ms — e foram medidos em itens que o fornecedor não descreve em termos comparáveis. Interpretar a diferença como "o local é mais rápido" não tem sustentação, porque o número hospedado é ponta a ponta por meio de uma API e os 8 ms são um forward pass numa GPU nomeada. Não são a mesma medição, e o fornecedor nunca afirma que sejam.

O segundo problema é a linha de visão. Uma melhoria de 0,2 ponto sobre o modelo base em onze benchmarks de imagem está dentro do ruído da forma como a maioria dos benchmarks é reportada, de modo que, seja lá o que a decision head proporcione, não se trata de um codificador de imagens materialmente melhor. A linha da ablação parece muito mais impressionante na direção oposta — uma variação de cerca de 29 pontos quando imagens são adicionadas —, mas ela compara dois conjuntos de perguntas diferentes, e não duas versões de um mesmo conjunto, o que a própria Liquid afirma no post. Ambas as linhas são úteis. Nenhuma das duas sustenta uma alegação forte sobre a qualidade da decisão visual, e nenhum terceiro executou qualquer uma delas.

Onde os dois nomes divergem na prática

Para um comprador, a distinção se resume a quatro perguntas, e as respostas não apontam todas na mesma direção.

• Perfil de custo — Liquid AI d1 é cobrado por token de entrada, à tarifa publicada pelo fornecedor, sem tokens de saída a pagar. Liquid AI d1-3B é um download de 2,87 GB no pacote do Ollama ou de 1,67 GB no repositório GGUF do fornecedor, sem nenhuma medição por chamada. • Latência, mensurável — a rota hospedada informa 200–300 ms por decisão de texto. Os 8 ms divulgados da rota local são uma forward pass em uma RTX 4090 com o modelo já aquecido, o que é um número real e não uma ida e volta de requisição. • Caminho dos dados — a rota hospedada envia o estado ao fornecedor. A rota local mantém isso na máquina, o que, para um ticket de suporte, uma nota médica ou uma fotografia, costuma ser o argumento que encerra a discussão. • Fixação de versão — Liquid AI d1 atrás de um endpoint é o que o fornecedor estiver servindo hoje. Liquid AI d1-3B no Ollama é um pacote fixo que você controla, e a contrapartida é que as atualizações ficam por sua conta.

A realidade incômoda subjacente a todas as quatro é que o checkpoint aberto é um irmão do modelo hospedado, e não um substituto para ele, e o fornecedor não disse o contrário. O cartão do modelo do checkpoint aberto recomenda-o para roteamento e triagem, moderação, classificação de intenções, verificações de extração, rerranqueamento, LLM-as-a-judge e mecanismos de proteção, e descreve-o como pós-treinado no LFM2.5-VL-3B para decisões calibradas de passagem única. O post do modelo hospedado descreve o mesmo conjunto de tarefas com palavras diferentes e cita o preço do modelo hospedado. Se esses forem um único modelo, a versão local é uma cópia gratuita de um produto hospedado, o que seria uma coisa incomum para um laboratório lançar sem dizê-lo. Se forem dois ajustes finos de uma base comum, não se deve presumir que os números publicados sejam transferíveis em qualquer direção. A segunda explicação exige menos do fornecedor e ajusta-se às evidências que temos.

Executando ambas as metades da decisão sem executar duas stacks

Qualquer que seja o nome escolhido, o pipeline ao redor dele tende a parecer o mesmo. Uma fila de suporte recebe uma pergunta de escolha sobre uma equipe de destino, uma pergunta booleana sobre se um reembolso está sendo solicitado e uma pergunta de pontuação para urgência — um estado, três respostas, uma passada. Onde os dois nomes realmente divergem é no ponto em que a decisão condiciona uma chamada a um modelo generativo que você aluga em vez de executar. Essa chamada é um problema diferente, com um perfil de falha diferente, e é a parte do pipeline em que d1 estar certo importa menos: uma resposta de roteamento com probabilidade de 0,98 seguida por um 502 do modelo para o qual você roteou é uma requisição malsucedida de qualquer forma.

Não hospedamos nenhum modelo da Liquid AI — verificamos nosso próprio catálogo antes de escrever isto —, então nada aqui é uma alegação sobre chamar esses pesos por meio de nós. O que fazemos é a camada do outro lado da decisão: uma única chave compatível com a OpenAI para os modelos aos quais uma solicitação triada se ramifica, ao preço de tabela de cada provedor repassado com 0% de markup, de modo que um corte de preço do fornecedor chegue até você no dia em que acontece, e não na renovação do contrato, com failover automático entre provedores para que uma solicitação triada sobreviva ao modelo para o qual você a encaminhou sair do ar. Se você está conectando um modelo de decisão a um pipeline pela primeira vez, essa é a metade que vale a pena tornar entediante.

Que nome usar, por situação

Se quiser experimentar o modelo esta semana sem um ambiente Python que valha a pena manter, use o nome que o runtime local utiliza. Baixe Liquid AI d1 da biblioteca, aceite Q8_0 e 3,7 GB, e encare o teto de requisição de 64 KiB e a regra de não-streaming como restrições de projeto, em vez de incômodos. Você obtém um endpoint real, respostas tipadas reais e nenhum medidor por chamada logo no primeiro dia.

Se precisar de uma pegada menor que a do Q8_0, o nome a usar é Liquid AI d1-3B, porque a build Q4_K_M de 1,67 GB está no repositório GGUF do fornecedor e não na entrada da biblioteca. Esse único fato é a diferença mais prática entre os dois nomes hoje, e é a que mais provavelmente passa despercebida a quem lê a página da biblioteca e para por aí.

Se você está colocando isso diante de usuários pagantes e precisa primeiro de evidências de precisão, nenhum dos dois nomes ajuda você ainda. Não há nenhuma avaliação independente de qualquer modelo d1 que tenhamos conseguido encontrar, as linhas do Decision Index foram pontuadas pela própria empresa, e o fornecedor não publicou nenhum benchmark de decisão em áudio. O que você pode fazer é instrumentar o valor de confiança que o modelo já retorna — de 0 a 1, refletindo com que força as probabilidades favorecem uma resposta, e não a probabilidade de essa resposta estar certa — e descobrir, no seu próprio tráfego, onde o modelo está inseguro. Essa medição vale mais do que qualquer um dos slides acima, e leva um dia.

O modelo de decisão é a metade barata do pipeline. O modelo generativo para o qual ele encaminha é a metade que precisa de um contrato — uma chave compatível com OpenAI inclui os modelos para os quais uma solicitação triada é distribuída, cada um pelo preço de tabela do respetivo provedor, repassado com 0% de markup.

Reduzir um checkpoint destilado face à sua própria versão completa é também um bom momento para verificar o registo: os incidentes de IA documentados e as falhas de agentes em torno dos pequenos modelos Liquid estão reunidos em the OrcaRouter AI Incident Archive, onde cada entrada inclui as suas próprias fontes, gravidade, grau de confiança e sinalização de contestação.