d1-2B: Liquid AI lançou um modelo de decisão de 1,9B sem um post para anunciá-lo

O repositório do Hugging Face para LiquidAI/d1-2B foi criado às 19:30 UTC de 24 de outubro de 2026. Seu irmão, d1-Omni-2B, surgiu vinte e quatro segundos depois. Ao fim daquela noite, ambos os repositórios estavam completos — 3.84GB de safetensors BF16, quarenta e poucos arquivos de código personalizado de Transformers, uma tabela de calibração, uma API de perguntas tipadas — e nada do que a Liquid AI publicou dizia que qualquer um dos dois modelos existia. A primeira frase do fornecedor que nomeia d1-2B chegou em 27 de outubro, dentro do lançamento da família LFM3 — o mesmo post publicado em liquid.ai e no blog do próprio Hugging Face — como uma oração em um parágrafo sobre dois modelos de decisão. Não houve nenhum post dedicado desde então. Portanto, esta não é uma história de lançamento, e tratá-la como tal inventaria um momento de marketing que nunca aconteceu. É uma história sobre um artefato de modelo completo com um anúncio incompleto, e sobre as duas coisas que um leitor ainda pode fazer com isso: ler o repositório e manter os números do fornecedor à distância até que alguém fora do laboratório os execute.

Os cinco dias entre os pesos e a sentença

A família d1 foi lançada duas vezes, e nenhum dos lançamentos se parecia com este. Em 7 de outubro, a Liquid AI publicou "Open d1: modelos de decisão de borda para texto, visão e áudio", que apresentou o d1-3B com 3,12B de parâmetros e o d1-omni-600M com 587M, com uma alegação de destaque, uma tabela de benchmark, números de latência e um post de blog que permanece no ar desde então. Esse post não contém nenhum modelo 2B.

A linha 2B seguiu um cronograma diferente. O checkpoint base LFM3-Omni-2B surgiu em 21 de outubro. Em 24 de outubro, às 19:30 e 19:30:24 UTC, a Liquid AI criou os repositórios d1-2B e d1-Omni-2B. Depois, em 27 de outubro, o post de lançamento do LFM3 nomeou o par como “modelos de decisão especializados a partir dos modelos de visão e omni” — uma descrição, não um anúncio. No mesmo dia, subiram quatro repositórios derivados do d1-2B: builds MLX em fp16, 8 bits e 4 bits, além de uma exportação ONNX. Ninguém publicou um post sobre esses também.

Isso importa por uma razão prática. Um anúncio é onde um fornecedor assume um posicionamento: para que serve o modelo, quanto custa, qual runtime ele visa, o que ele não faz. O card faz parte desse trabalho e o faz excepcionalmente bem. Mas as lacunas deixadas pela publicação ausente são reais e específicas, e estão listadas no final deste texto, em vez de serem mascaradas.

O que o repositório realmente lhe dirá

Deixando de lado o enquadramento, o checkpoint é um classificador multimodal pequeno e densamente especificado que se recusa a gerar texto. Cada chamada retorna respostas tipadas com probabilidades associadas e output_tokens: 0. O card diz isso abertamente: d1-2B "não é um modelo de chat."

• Parâmetros — 1,92B, fornecido como um único arquivo safetensors BF16 de 3,84GB.

• Base — LFM3-VL-2B, no backbone LFM3: 24 camadas, das quais 13 são convoluções curtas com gating, 5 são atenção de janela deslizante e 6 são atenção global.

• Contexto — 128K tokens e um vocabulário de 128.000 tokens, quatro vezes a janela de 32.768 do d1-3B.

• Entrada — um estado que pode ser texto ou qualquer valor JSON, imagens ou um vídeo, e qualquer quantidade de perguntas nomeadas, tudo em uma única lista de mídia. Vídeo é o recurso que o d1-3B não lista.

• Saída — sim/não, uma escolha entre opções nomeadas, uma pontuação ordenada, um valor ou data lido de um documento com seu trecho, um número com um intervalo p10–p90, uma caixa delimitadora, ou cada instância de um objeto com uma contagem. Cada um carrega uma probabilidade.

• Idiomas — dezesseis: inglês, árabe, chinês, francês, alemão, italiano, japonês, coreano, português, espanhol, vietnamita, tailandês, indonésio, hindi, russo, polonês.

• Licença — LFM Open License v1.0. O uso comercial é concedido abaixo de US$ 10.000.000 de receita anual; o texto da licença define esse valor como um limite, e os direitos para uso comercial acima dele estão condicionados a não excedê-lo.

• Velocidade — 5,7 ms para uma única decisão em uma H100 PCIe e 3,8 ms em uma AMD MI325X, com 1.132 e 1.699 decisões por segundo, respectivamente, quando 64 estados são agrupados em uma única chamada. Em um Apple M5 Pro, o valor para uma única pergunta é 18,6 ms.

A afirmação que vale a pena debater: ele supera o modelo que substituiu.

A ficha da Liquid AI faz uma afirmação comparativa sem ressalvas: o d1-2B "lidera os modelos d1 abertos em média e no nosso painel de mais de cem benchmarks de decisão, à frente do d1-3B com menos de dois terços do seu tamanho." Trata-se de uma afirmação forte de um modelo de 1,92B sobre um de 3,12B, e é verificável, porque a ficha apresenta todos os quatro modelos d1 abertos em uma única tabela, pontuados nos mesmos itens com o mesmo sistema de pontuação.

O número principal é 51,1 contra 49,0 na suíte pública do Decision Index, versão 0.3 — uma vantagem de 2,1 pontos. Antes que alguém interprete isso como uma vitória limpa, duas ressalvas devem ser colocadas ao lado desse número. Primeiro, o próprio cartão do d1-3B reporta 48,57 no Decision Index 0.2.1, e a diferença entre 48,57 e 49,0 é a versão do índice, não uma melhoria no modelo; o cartão do d1-2B afirma que todos os quatro modelos foram reavaliados nos mesmos itens e que, portanto, alguns dos números do d1-3B diferem do seu próprio cartão. Segundo, a suíte pública é uma fração do que determina a ordem do ranking público: o avaliador independente que a reconstruiu descreve 37 benchmarks públicos ponderados em 20% da pontuação, com o restante vindo de testes privados executados apenas pelos mantenedores.

O que torna o 49,0 crível como número — mesmo que o próprio d1-2B não tenha nenhuma verificação externa — é que alguém já reproduziu o 3B nesta versão exata. Efraín Garay executou o d1-3B em uma amostra estratificada de 6.000 requisições do Decision Index 0.3 em meados de outubro e obteve 49,11, contra 49,04 do próprio Liquid nas mesmas linhas e 48,99 na suíte completa. Trata-se de uma reprodução dentro de um décimo de ponto. Isso não valida o 51,1 do d1-2B, que nenhum terceiro executou, mas valida o método de pontuação por trás da tabela na qual o 51,1 está.

Onde o modelo menor não está à frente

“Lidera na maioria dos benchmarks individuais” está fazendo um trabalho discreto nessa frase. Na tabela da mesma execução, o d1-3B ainda vence em três das vinte e poucas linhas que importam para uma decisão de implantação:

• Decisões Rápidas — 59,3 para o 3B contra 58,8, o único benchmark de decisão orientado à velocidade em que o modelo maior leva vantagem.

• Decisões Tipadas — 65,0 contra 61,3, uma diferença de 3,7 pontos e o argumento único mais claro a favor do modelo mais antigo quando a saída precisa ser um valor tipado em vez de um rótulo.

• AI2D — 79,9 contra 76,7, o benchmark de leitura de diagramas, em que uma torre de visão maior ainda rende precisão.

Em todos os outros casos, a ordem se inverte, às vezes de forma acentuada. O VisualWebBench é 96,2 para o d1-2B contra 71,4 para o d1-3B. O ImajevBench v2.0-lite é 75,5 contra 64,0. O MMMU-Pro é 26,4 contra 18,5 — ambos baixos o suficiente para que nenhum dos modelos deva ser confiável para raciocínio multimodal difícil, o que vale dizer claramente em vez de apresentar a diferença de 7,9 pontos como uma vitória. As médias de visão são 70,2 e 65,4.

Três ausências que o cartão não consegue suprir

O anúncio ausente se manifesta como artefatos ausentes. Nenhum destes é um defeito no modelo; cada um é uma razão pela qual o modelo é mais difícil de adotar hoje do que sua linha de benchmark sugere.

• Sem GGUF. d1-3B e d1-omni-600M receberam repositórios GGUF em 6 de outubro, um dia após seus pesos serem publicados, e d1-3B veio em seguida com uma build de ativação de pesos de 8 bits e quatro variantes MLX. d1-2B tem builds MLX e ONNX desde 27 de outubro, mas nenhum GGUF — então não há caminho llama.cpp publicado para o head de decisão, embora o modelo base LFM3-VL-2B tenha recebido seu próprio GGUF em 19 de outubro. Se sua stack de edge é llama.cpp, esta é a história completa.

• Sem preço e sem endpoint. O card não lista nenhuma API hospedada, nenhum preço por token e nenhum provedor de inferência. Isso não é incomum para um lançamento de pesos abertos, mas significa que a única forma de usar o d1-2B é executá-lo, e a seção de implantação do card termina em um snippet de Transformers.

• Nenhum benchmark independente. Em 28 de outubro, o repositório mostra 44 downloads e 13 curtidas. A avaliação independente de modelo de decisão existente abrange d1-3B e d1-omni-600M, não este modelo. Todos os números de desempenho acima são da própria Liquid AI.

Há também um limite que o próprio cartão declara sobre si mesmo: as respostas "ficam menos confiáveis depois de cerca de 64K tokens de estado", metade da janela de 128K anunciada, e as estimativas são confiáveis em contagens e pontuações, mas menos em quantidades livres. Um modelo cujo próprio cartão informa onde ele se degrada é mais útil do que um que não o faz, mas o número de destaque de 128K deve ser lido como uma cifra de capacidade, não como um intervalo de trabalho.

Como é realmente um primeiro deploy

O caminho prático é Transformers 5.19 ou superior com trust_remote_code=True, bf16 na GPU, e a chamada de system_one ou system_one_batch. Não há parâmetros de amostragem porque não há amostragem. O único ajuste que importa é set_size, cujo padrão é o tamanho treinado de 16; aumentá-lo traz ganho de velocidade e custa precisão do texto.

A recomendação do próprio cartão é a etapa que a maioria das equipes pula: calibre seu limiar de decisão com dados do seu próprio uso. Uma probabilidade de 0,62 não significa nada isoladamente. Se você estiver encaminhando tickets de suporte ou sinalizando documentos, o limiar que separa "escalar" de "tratar automaticamente" precisa ser ajustado na sua própria amostra rotulada, porque a calibração do fornecedor foi ajustada na amostra dele.

O formato em que isto se encaixa é uma etapa de pipeline, não um assistente: triagem, moderação, classificação de intenção, extração de formulários, reranqueamento, inspeção visual. Esses são exatamente os pontos em que um pipeline já chama vários modelos e em que as etapas generativas em torno da decisão normalmente vêm de uma API hospedada. O OrcaRouter não serve nenhum modelo da Liquid AI hoje — inclusive este —, então executar o d1-2B significa executá-lo por conta própria. O que torna um roteador útil é o restante da cadeia: uma única chave compatível com OpenAI para mais de 200 modelos hospedados, uma DSL de roteamento que compõe etapas em uma única chamada e failover automático quando um provedor cai, para que o nó de decisão na sua GPU não fique refém do nó generativo ao lado.

O que mudaria esta história

Quatro coisas, em ordem decrescente de importância. Um GGUF colocaria o d1-2B no mesmo patamar de runtime que seus irmãos e tornaria o argumento de edge real. Um post dedicado diria aos compradores para que a Liquid AI acha que o modelo serve, além da lista de etapas de pipeline do cartão. Uma execução independente — idealmente a mesma amostra de 6.000 linhas que reproduziu o d1-3B — transformaria o 51,1 de uma alegação do fornecedor em uma medição. E um preço de hospedagem tornaria a pergunta construir-versus-comprar ao menos respondível.

Até lá, o resumo honesto é estreito e útil: existe um modelo de decisão de 1,92B, seu repositório está completo o suficiente para ser avaliado, sua vantagem de benchmark sobre o 3B é real na própria tabela de mesma execução do fornecedor e não verificada em todo o resto, e o anúncio ausente o deixou sem o pacote — runtime, endpoint, preço — de que a maioria das equipes precisa antes de colocar um modelo em um pipeline. Se você já usa Transformers e quer um classificador de janela de 128K com entrada de vídeo, vale uma tarde. Se você precisa de llama.cpp ou de um endpoint gerenciado, espere.