d1-2B vs Liquid AI d1-3B: O modelo menor vence o ranking e perde na implantação

Quatro perguntas decidem esta comparação, e nenhuma delas é "qual modelo é melhor". O estado inclui vídeo? Excede 32K tokens? Você precisa executá-lo no llama.cpp? Você pode se dar ao luxo de ser a primeira pessoa a testá-lo? d1-2B é o modelo de decisão de 1,92B da Liquid AI, construído sobre o LFM3-VL-2B e com pontuação 51,1 na tabela Decision Index do fornecedor. Liquid AI d1-3B é o modelo de 3,12B lançado em 7 de outubro, construído sobre o LFM2.5-VL-3B e com pontuação 49,0 na mesma tabela. O modelo mais novo e menor lidera em média. Ainda assim, perde em três das linhas que uma implantação de fato ativa, e é o único dos dois que não tem caminho para llama.cpp nem resultado de teste independente. Esta página está organizada em torno dessas quatro perguntas, e não do ranking, porque o ranking não responde a nenhuma delas.

A resposta curta, por carga de trabalho

• Triagem apenas de texto em volume — d1-2B, com base em 1.132 decisões por segundo para 64 estados em lote e 3,84 GB de pesos. A vantagem do 3B em Typed Decisions é irrelevante quando a saída é um rótulo.

• Leitura de diagramas e gráficos — Liquid AI d1-3B. Ele vence o AI2D por 79,9 a 76,7, e é o modelo com uma execução independente por trás.

• Documentos longos, formulários longos, transcrições longas de chamadas — d1-2B. Sua janela é de 128K tokens contra 32.768, e o card é honesto ao dizer que a confiabilidade cai após cerca de 64K, o que ainda deixa o dobro da capacidade total do 3B.

• Dispositivos de borda executando llama.cpp — Liquid AI d1-3B, por padrão e não por mérito. Ele tem um repositório GGUF e uma build quantizada de pesos e ativações; o d1-2B não tem nenhum dos dois.

• Qualquer coisa em que uma decisão errada seja custosa e não testada — nenhum dos dois, até você executar os dois nos seus próprios dados. Apenas um deles foi sequer executado por um terceiro.

Mesma família, uma geração de diferença

Os dois modelos não são irmãos da forma que os nomes sugerem. O Liquid AI d1-3B descende do LFM2.5-VL-3B, que deriva do LFM2.5-2.6B-Base, e carrega um codificador de visão SigLIP2 NaFlex de 400M. O d1-2B descende do LFM3-VL-2B, a próxima família, sobre um backbone de 24 camadas divididas entre 13 convoluções curtas com gating, 5 camadas de atenção com janela deslizante e 6 camadas de atenção global. É dessa lacuna geracional que vem a inversão de benchmark: a arquitetura mais nova faz mais por parâmetro, então o checkpoint menor pode superar o maior na maioria das linhas.

• Parâmetros — 1,92B para d1-2B vs 3,12B para Liquid AI d1-3B.

• Baixar — 3,84 GB vs 6,25 GB de safetensors BF16, ambos em arquivo único.

• Contexto — 128K tokens vs 32.768.

• Vocabulário — 128.000 tokens vs o vocabulário do LFM2.5.

• Entradas — texto ou JSON, imagens ou vídeo, além de perguntas nomeadas, para o d1-2B; texto ou JSON mais imagens para o 3B. O vídeo é a diferença de capacidade mais clara entre eles.

• Idiomas — dezesseis cada, o mesmo conjunto.

• Licença — LFM Open License v1.0 para ambos, com uso comercial condicionado a permanecer abaixo de US$ 10.000.000 de receita anual. Não há motivo de licenciamento para preferir nenhum dos dois.

• Lançamento — os pesos do d1-3B foram publicados em 5 de outubro e anunciados em 7 de outubro. O repositório do d1-2B foi criado em 24 de outubro e nunca teve uma publicação própria; a única frase do fornecedor que o nomeia está no lançamento do LFM3 de 27 de outubro.

Um detalhe de documentação vale ser lido como um sinal, e não como um fato: a página de documentação dos modelos de decisão da Liquid AI agora lista d1-2B, d1-omni-2B, d1-omni-600M, d1.1 e d1-ultra. Ela não lista mais o d1-3B. O 3B não foi descontinuado — seu repositório e as builds GGUF e MLX continuam ativos —, mas o índice do próprio fornecedor transferiu a vaga de pesos abertos para o 2B.

O placar, lido linha por linha

Todos os números abaixo vêm da tabela de benchmark no card do modelo d1-2B, que pontua quatro modelos d1 abertos nos mesmos itens com o mesmo avaliador. Isso importa porque o próprio card do d1-3B da Liquid AI reporta 48,57 no Decision Index 0.2.1, enquanto esta tabela reporta 49,0 na versão 0.3; a diferença é da edição do índice, não uma mudança de modelo, e o card diz isso em uma nota. Comparar os dois cards diretamente — 48,57 contra 51,1 — seria subtrair entre dois testes diferentes. Comparar dentro desta tabela é legítimo, e é o que o restante desta seção faz.

• Decision Index public suite v0.3 — 51,1 vs 49,0.

• DecisionBench (Hanno Labs) v1 — 77,1 vs. 73,1.

• Decision Bench (decisionbench.ai) v4 — 85,2 vs 83,6.

• JevBench v1.4.1 — 77,9 vs 76,2.

• ImajevBench v2.0-lite — 75,5 vs 64,0, a maior diferença no lado da decisão.

• WorkflowEvals — 81,6 vs 74,4.

• O conselho interno da Liquid AI — 63,2 vs 58,8.

• Média de visão — 70,2 vs 65,4 em dezoito benchmarks.

Toda suíte de decisão nomeada naquela tabela fica com o 2B, que é o que o post de lançamento do LFM3 quer dizer ao chamar o d1-2B de substituto do d1-3B "com um terço a menos de parâmetros" e pontuações mais altas "em todas as quatro suítes de decisão". A afirmação é precisa como está escrita — e mais restrita do que "supera o 3B"; é por isso que o próximo parágrafo existe. Depois, as três linhas que vão no sentido contrário. Fast Decisions é 58,8 para o d1-2B contra 59,3 para o 3B. Typed Decisions é 61,3 contra 65,0. AI2D é 76,7 contra 79,9. Nenhuma dessas diferenças é grande, e duas das três ficam dentro de um ponto, mas são as linhas em que os 1,2 bilhão de parâmetros extras ainda entregam algo mensurável: decisões voltadas à velocidade, extração tipada e leitura de diagramas. Se os trabalhos do seu pipeline forem extração tipada de formulários, o 3B não é a opção obsoleta que a página de documentação dá a entender.

Latência: os dois números principais não são comparáveis

A Liquid AI cita 5,7 ms por decisão para o d1-2B e 8 ms para o Liquid AI d1-3B, e essas não são a mesma medição. O número do 2B é em uma H100 PCIe; o do 3B é em uma RTX 4090. Uma diferença de 2,3 ms entre duas GPUs diferentes não diz nada sobre qual modelo é mais rápido no seu hardware, e repeti-la como comparação seria exatamente o tipo de lavagem de números que este blog existe para evitar.

Há uma máquina que ambas as fichas reportam. Em um Apple M5 Pro, o d1-2B leva 18,6 ms por pergunta e o 3B leva 30 ms — uma redução de 38% no mesmo silício. Essa é a comparação de velocidade honesta, e ela aponta na mesma direção que a diferença de tamanho sugere. No processamento em lote, o d1-2B processa 1.132 decisões por segundo em uma H100 PCIe e 1.699 por segundo em uma MI325X com 64 estados em uma única chamada; a ficha do 3B reporta 475 por segundo em uma RTX 4090 e 1.106 por segundo em uma MI325X. A linha da MI325X é a que ambas as fichas compartilham, e ali o 2B está à frente em cerca de 54%.

O único teste independente que existe executou o 3B

Em meados de outubro, Efraín Garay executou oito modelos de decisão frente ao Decision Index 0.3 e a três tarefas com dados reais, e publicou os resultados com o código. Dois achados são relevantes para esta comparação.

O primeiro é tranquilizador para o placar. Ele reconstruiu a suíte pública a partir do kit, verificou que os arquivos baixados correspondiam aos oficiais, amostrou 6.000 solicitações e pontuou o Liquid AI d1-3B em 49,11 — contra 49,04 do próprio Liquid nas mesmas linhas e 48,99 na suíte completa. Essa é a evidência mais forte disponível de que os números da v0.3 na tabela acima estão sendo calculados corretamente. É evidência sobre o 3B, não sobre o d1-2B, que ele não testou.

O segundo é um alerta sobre o que um índice mede. Em um banco sintético de fraude de cartão com 10.000 pagamentos, o Liquid AI d1-3B obteve uma AUC de 0,314 — abaixo do acaso, classificando anomalias como menos suspeitas do que pagamentos normais, porque rajadas de pagamentos consecutivos atingiram uma probabilidade mediana de 0,41 contra 0,56 para um pagamento normal. O modelo ficou em segundo lugar no índice público e em último naquela tarefa. A lição se aplica diretamente: o 51,1 do d1-2B é uma pontuação em uma suíte genérica de decisão, e ninguém demonstrou que ela prevê o desempenho na sua decisão específica. O fornecedor afirma isso na própria ficha do modelo, na instrução de calibrar os limites com seus próprios dados.

O que você pode realmente executar hoje

É aqui que o confronto deixa de ser equilibrado. O Liquid AI d1-3B tem um repositório GGUF desde 6 de outubro, uma build de ativação de pesos de 8 bits desde 7 de outubro e quatro variantes MLX desde 12 de outubro. O d1-2B recebeu três builds MLX e uma exportação ONNX em 27 de outubro, e nada mais. Não há GGUF para o d1-2B, nenhuma quantização além das 4 e 8 bits do MLX e, portanto, nenhum caminho llama.cpp publicado para a cabeça de decisão — embora o modelo base, LFM3-VL-2B, tenha seu próprio GGUF desde 19 de outubro.

Para uma implantação em Transformers, a diferença desaparece: ambos carregam com trust_remote_code=True e expõem as mesmas system_one e system_one_batch chamadas. Para uma implantação em edge, isso não acontece. Se sua stack é llama.cpp em um Jetson ou em um telefone, o 3B é o único dos dois que você pode executar sem escrever uma integração de runtime, e seus números publicados para edge — 16 ms no Jetson AGX Thor, 26 ms no AGX Orin 64GB, 50 ms no Orin Nano — são aqueles com os quais você pode planejar.

Nenhum dos dois modelos é servido pelo OrcaRouter, então escolher entre eles é, de qualquer forma, uma decisão de auto-hospedagem. Onde um roteador justifica seu lugar é uma camada acima: modelos de decisão raramente rodam sozinhos, e a etapa generativa que age sobre um rótulo de roteamento normalmente vem de um modelo hospedado. Uma chave compatível com OpenAI para mais de 200 modelos, um DSL de roteamento que permite compor essas etapas em uma única chamada e o failover automático impedem que essa metade do pipeline se torne um segundo projeto de integração, enquanto o nó de decisão permanece no seu próprio hardware.

Se você está migrando, três coisas mudam

A superfície da API é suficientemente próxima para que portar pareça trivial e não é. Primeiro, o contrato de entrada: o d1-3B recebe imagens; o d1-2B recebe uma lista de mídia que pode incluir vídeo, e seu card descreve a mídia como codificada uma vez para todas as perguntas em uma chamada. Código que passa uma única imagem será executado, mas não usará aquilo para o que o modelo foi construído.

Segundo, o limiar. Ambos os modelos retornam probabilidades, e ambos precisam de um limiar de decisão ajustado aos seus dados. Um limiar ajustado na calibração do d1-3B não é transferível — as tabelas de calibração vêm dentro de cada repositório, ajustadas separadamente —, então uma migração que mantém o corte antigo produzirá um ponto de operação diferente e, em um fluxo de moderação ou fraude, um perfil de erro diferente.

Terceiro, o penhasco de confiabilidade. A janela de 128K é o destaque; a ficha diz que as respostas ficam menos confiáveis depois de cerca de 64K tokens de estado. No 3B, o teto é 32.768, então uma migração para o d1-2B geralmente será um ganho direto de capacidade — mas um pipeline que começa a alimentar estados de 100K tokens porque agora pode está testando a parte da faixa que o fornecedor sinalizou como mais fraca.

O veredito é menos simétrico do que o placar. Para uma nova implementação em Transformers, em texto, imagens ou vídeo, com estados que podem se prolongar, o d1-2B é a melhor opção padrão e a mais barata de executar. Para uma implantação de edge com llama.cpp, para extração tipada ou para visão com muitos diagramas, o Liquid AI d1-3B continua sendo o modelo a escolher — e é o único dos dois com alguma evidência externa que o sustente. A única coisa a não fazer é escolher apenas com base na linha de 51,1 contra 49,0. Dois pontos no índice de um fornecedor, entre dois modelos que ninguém executou na sua tarefa, não são uma decisão; são um critério de desempate.