O Liquid AI d1-3B chega ao Ollama: um endpoint local discreto para um modelo de decisão

Há um novo d1 na biblioteca do Ollama, e ele não é um modelo de chat. A entrada o descreve em uma linha — "um modelo de decisão de 3B da Liquid AI, construído sobre o LFM2.5-VL-3B" — e essa única frase contém os dois fatos que mais importam. Liquid AI d1-3B, o pequeno modelo que a Liquid AI construiu sobre o Liquid AI LFM2.5-VL-3B e lançou como pesos abertos em 5 de outubro de 2026, agora está empacotado de modo que um único pull o coloca na sua própria máquina; e ele ainda retorna probabilidades calibradas sobre perguntas tipadas, em vez de texto gerado, exatamente como o checkpoint subjacente faz. Se você tem uma etapa de triagem, roteamento, moderação ou controle de passagem em um pipeline, esta é a primeira vez que essa família específica de modelos está a um comando de distância de ser executada sem chave de API, sem preço por chamada e sem que nenhum texto de estado saia do seu hardware.

A palavra "quiet" está fazendo um trabalho real aqui, no entanto, e vale a pena ser preciso sobre qual metade desta história está documentada e qual metade não está. O próprio blog da Liquid AI nunca mencionou o Ollama: o post mais recente do laboratório, em 13 de outubro de 2026, aborda um modelo diferente da linha LFM2.5, e seus dois posts sobre o d1 — o anúncio de visão de 5 de outubro e o lançamento do "Open d1" de 7 de outubro — descrevem pesos, uma API e uma pontuação de benchmark, não um runtime local. A página da biblioteca do Ollama para o d1 também não traz anúncio algum, e o índice de documentação do fornecedor também não, que assinala GGUF como disponível para Liquid AI d1-3B e seu irmão compatível com áudio Liquid AI d1-omni-600M enquanto nomeia llama.cpp, Ollama e MLX apenas como opções genéricas de implantação. O que existe é um pacote publicado, uma entrada de registro com um digest que você pode verificar, um readme funcional e um contador de downloads que registrava 10.4K quando isto foi escrito em 15 de outubro de 2026. O que não existe é uma frase do fornecedor dizendo "nós fizemos isto".

O que a listagem realmente contém

Três tags estão listadas — d1:latest, d1:3b e d1:3b-q8_0 — e todas as três apontam para o mesmo digest do manifesto, 8c2d9ddae441. Essa é a primeira coisa que se deve entender sobre a página: o contador de "3 modelos" da biblioteca é uma contagem de tags, não de checkpoints. Um artefato, três nomes, 3,7 GB, uma janela de contexto de 32K e entrada de texto e imagem. Se você esperava escolher um tamanho ou uma quantização, ainda não há nada para escolher.

O registro por trás da página é mais informativo do que a página. O blob de configuração do pacote informa uma família de modelo lfm2, um tipo de modelo 2.7B, um tipo de arquivo Q8_0 e um runtime mínimo do Ollama 0.40.4. Ele é distribuído em duas camadas de pesos: um modelo generativo de 2,87 GB e um projetor separado de 856 MB. Essa segunda camada é o codificador de visão, e sua presença indica que a build local mantém o caminho multimodal em vez de reduzir o d1 a texto — o modelo ainda consegue ler uma fotografia junto com um chamado de suporte e responder a perguntas sobre ambos. Os dois números nesta página que parecem discordar — "3B" na descrição e "2.7B" no registro — são melhor interpretados como o tronco e o todo: a ficha do modelo da Liquid AI define o checkpoint em 3,12B parâmetros, incluindo um codificador de visão de 400M parâmetros, e o tronco de linguagem é o número menor. Essa aritmética é nossa, não do fornecedor, e é oferecida como explicação, não como especificação.

Não há nenhuma data de calendário em lugar nenhum na página da biblioteca. Ela informa marcações relativas — "Atualizado há 2 horas" no momento da captura — e um contador de downloads, o que significa que não dá para saber, a partir da própria listagem, o dia em que esta listagem apareceu pela primeira vez. As âncoras datadas estão todas no Hugging Face e no fornecedor: o repositório de pesos do Liquid AI d1-3B foi criado em 5 de outubro de 2026, um repositório GGUF complementar em 6 de outubro, e a Liquid AI publicou seu post de lançamento em 7 de outubro. Se você precisar atribuir uma data a "quando isto se tornou executável localmente", a resposta honesta hoje é que o pacote existe e está sendo baixado agora, e ninguém de fora da Ollama pode dizer em que manhã ele foi ao ar.

Porque um evento de embalagem é um evento real

A Ollama abriu uma categoria de modelo de decisão em 29 de setembro de 2026, quando lançou o endpoint /v1/systemone e uma flag --ask da CLI para modelos que respondem a perguntas tipadas em um único forward pass. Nimble e Clef foram as primeiras famílias a passar por essa porta. O que o novo pacote d1 acrescenta é algo diferente de uma nova linha de benchmark: ele pega um modelo que até então vivia ou em um ambiente Python com uma classe de modelo vendorizada ou atrás de um endpoint hospedado, e transforma a inferência local em um comando.

O contrato vale a pena ser reafirmado porque não é o que a maioria dos leitores entende por "executar um modelo." Você entrega ao d1 um estado — uma string, um objeto JSON, um array, ou uma string mais imagens — e um conjunto de perguntas nomeadas, e você recebe respostas de volta sem nenhum token gerado. noul é uma pergunta de sim/não respondida como uma única probabilidade entre 0 e 1. choice retorna o rótulo selecionado, uma confiança e um mapa de probabilidade completo sobre suas opções. score coloca o estado em uma rubrica ordenada de dois a dez níveis e retorna o nível ponderado por probabilidade mais a probabilidade de cada nível. Um estado, até 64 perguntas, uma passagem pela entrada. A própria resposta de exemplo da Ollama para um tíquete de suporte retorna usage.output_tokens: 0, que é a declaração mais clara possível do design.

Para quem já tem um pipeline que chama um modelo de decisão via HTTP, a rota local muda três coisas de uma só vez: latência, porque a requisição deixa de sair da máquina; custo, porque não há medidor por chamada; e tratamento de dados, porque o texto do ticket e a fotografia que você está classificando nunca cruzam a rede. Se os seus dados forem a mensagem de um cliente ou um documento interno, esse último ponto costuma ser o único argumento que precisa ser apresentado.

Executá-lo, e os limites que a documentação impõe a ele

Existem três formas de entrada suportadas, e todas estão documentadas na página da biblioteca. O caminho da CLI é ollama run d1 --ask "Is a refund being requested?" com o state canalizado a partir de um ficheiro, e os sinalizadores --choice e --level para os outros dois tipos de pergunta. O caminho HTTP é um POST para http://localhost:11434/v1/systemone com um model, um state, um array images opcional e um objeto questions. O caminho do SDK aponta o cliente Python da TypeSafe para localhost, onde a chave de API é ignorada e qualquer valor provisório funciona.

Os limites vêm da documentação do endpoint do Ollama, e não da Liquid AI, e são mais restritos do que os de um modelo generativo: as requisições devem caber em 64 KiB sem imagens e 32 MiB com elas, o streaming não é suportado, modelos hospedados na nuvem são rejeitados de imediato, e as imagens devem ser PNG, JPEG ou WebP em base64, enviadas no corpo da requisição — URLs remotas são recusadas. As imagens são compartilhadas por todas as perguntas de uma requisição, portanto, uma imagem que você quer que apenas a primeira resposta considere precisa ser enviada como uma chamada própria. A entrada nunca é truncada, o que significa que um estado grande demais é um erro, e não um prompt cortado silenciosamente.

Dois detalhes de documentação merecem ser sinalizados como não resolvidos. A referência do endpoint do Ollama descreve o tipo de escolha como aceitando de 2 a 255 chaves de opção, enquanto a página de capacidades dos modelos de decisão diz de 2 a 26 — uma das duas está desatualizada, e não é óbvio qual. E a página de capacidades nomeia seus modelos compatíveis como Nimble, Tev1, Clef e Clef Flash, sem mencionar d1, embora o próprio readme do pacote d1 declare que ele funciona por meio de /v1/systemone e --ask. O pacote exige Ollama 0.40.4; a versão mínima documentada para o próprio endpoint é 0.35.0. Nada disso é uma contradição que impeça você de puxar o modelo, mas leia o requisito de versão no pacote, e não o que está no guia de capacidades.

Os números, e quem produziu cada um deles

Agora, a parte que merece a maior cautela. Todos os números de desempenho associados a este modelo são da Liquid AI, e não há avaliação independente do Liquid AI d1-3B até onde conseguimos encontrar. Os resultados relatados pelo fornecedor, repetidos na página do Ollama e na ficha do modelo, são estes:

• Índice de Decisão 0.2.1 — 48,57 para o d1-3B, contra 47,11 para o Decider 35B-A3B, que a Liquid descreve como a melhor pontuação para um modelo de decisão com menos de 10B parâmetros. • Visão — uma média de 74,1 em onze benchmarks públicos de imagens, contra 73,9 do modelo base LFM2.5-VL-3B a partir do qual foi construído. • Latência — 8 ms por decisão em uma RTX 4090, 9 ms em uma AMD MI325X e 30 ms em um Apple M5 Pro. • Vazão — 475 decisões por segundo na 4090 e 1.106 na MI325X quando as perguntas são agrupadas em lotes. • Ablação — o mesmo conjunto de perguntas respondido sem imagens pontua 45,1, que é a medida da própria Liquid de quanto o caminho de visão contribui.

A linha de visão é a que deve moderar as expectativas. Uma melhoria de 0,2 ponto sobre o modelo base em um conjunto de benchmarks de imagem está dentro do ruído da maioria dos relatórios de benchmark; seja lá o que a cabeça de decisão proporcione, não é um codificador de imagens materialmente melhor. A linha de ablação é mais interessante na outra direção — uma variação de cerca de 29 pontos quando imagens são adicionadas —, mas compara dois conjuntos de perguntas diferentes, não duas versões do mesmo conjunto. E o Decision Index é um instrumento de terceiros no qual a Liquid avaliou suas próprias entradas em vez de submetê-las a um ranking público, então trate 48,57 como uma alegação de fornecedor feita na régua de outra pessoa. Os números de velocidade também não são auditados: 8 ms em uma 4090 é um número plausível para um modelo 3B fazendo um forward pass, e continua sendo o caso de que ninguém publicou uma execução que não seja sua.

Onde o OrcaRouter se encaixa, e onde não

A OrcaRouter não serve Liquid AI d1-3B. Verificamos nosso catálogo antes de escrever isto — 207 modelos, nenhum deles da Liquid AI, nenhum deles um modelo de decisão — então, se você quiser chamar o d1 a partir de uma API em vez do seu próprio hardware, a rota hospedada hoje é o endpoint de decisão do próprio fornecedor em api.liquid.ai/decisions/v1/systemone, onde um nível pago do d1 lida com imagens e um nível gratuito d1:free é somente texto, além de quaisquer plataformas de terceiros que o adotem. Nada neste texto deve ser lido como uma afirmação de que nós o hospedamos.

O que fazemos é adjacente ao problema que este modelo resolve. A razão pela qual existe um modelo de decisão é que os pipelines precisam de uma forma barata e determinística de escolher entre opções, e o próprio exemplo documentado do d1 é um ticket encaminhado para uma equipe de destino — o que é um problema de roteamento um nível abaixo do nosso. Quando essa decisão condiciona uma chamada a um modelo generativo que você aluga em vez de rodar, o OrcaRouter é uma chave compatível com OpenAI para mais de 200 modelos hospedados pelo preço de tabela do provedor, repassada com 0% de markup, de modo que um corte de preço do fornecedor chega até você no dia em que entra em vigor, e não na próxima renovação do contrato. E, como a metade local deste pipeline é a metade que você possui, o risco está na metade hospedada: o failover automático entre provedores mantém uma solicitação triada ativa quando o modelo para o qual você a encaminhou fica indisponível. Nenhuma dessas é razão para usar um modelo de decisão de 3B. Elas são razões para que aquilo que está do outro lado da decisão não seja um ponto único de falha.

O que transformaria isto de uma nota de embalagem em uma história

Cinco coisas, qualquer uma das quais mudaria a leitura. A Liquid AI reconhecer o port, ou seu índice de documentação adicionar o Ollama à linha de implantação que atualmente preenche com llama.cpp e MLX. Uma segunda quantização: o próprio repositório GGUF da Liquid traz Q4_K_M, F16 e BF16 junto com Q8_0, então uma build local menor está tecnicamente disponível, só que não por meio deste pacote. Um caminho local para Liquid AI d1-omni-600M, o irmão de 587M de parâmetros que lê até trinta segundos de áudio e que o fornecedor classifica como uma versão de pesquisa inicial — esse importaria mais do que o 3B para trabalho no dispositivo, e não há sinal dele em nenhuma biblioteca ainda. Uma linha independente no Decision Index, ou uma entrada em um leaderboard público, que é a única peça que falta em toda esta família de modelos. E o Ollama adicionar o d1 à sua página de capacidade de decisão, que é uma mudança de uma linha que lhe diria que o port é sancionado, e não incidental.

Até então, a decisão é simples o bastante para ser tomada nos seus próprios termos. Se você já executa uma versão recente do Ollama, o pull é um único comando, o download é de 3,7 GB, e aquilo que ele substitui é ou uma chamada hospedada que você preferiria não fazer com o texto de um cliente, ou um ambiente Python que dá mais trabalho de manter do que o modelo vale. Se você precisa de evidência independente de precisão antes que isto fique diante de usuários reais, essa evidência ainda não existe para nenhum modelo d1, e nenhuma quantidade de empacotamento local a cria.

Executar a etapa de decisão no seu próprio hardware também é um bom momento para examinar o que já deu errado nessa classe: os incidentes documentados de IA e as falhas de agentes envolvendo modelos de decisão estão reunidos em o OrcaRouter AI Incident Archive, onde cada entrada traz suas próprias fontes, severidade, grau de confiança e indicador de contestação.