LFM2.5-VL-3B-DSpark vs LFM2.5-VL-3B: Você não escolhe um, você acopla um

A pesquisa que traz as pessoas aqui é uma comparação, mas a resposta real é que LFM2.5-VL-3B-DSpark e LFM2.5-VL-3B não são duas coisas entre as quais se escolher. O segundo é um modelo de visão e linguagem de 3,1B que você pode baixar e servir. O primeiro é um modelo de rascunho de 279,5M de parâmetros que existe apenas para ficar na frente do segundo e torná-lo mais rápido. Tire o modelo de rascunho da pilha e ele não produz nada; você não pode calibrá-lo sozinho, porque “sozinho” não é uma configuração que ele suporta. A comparação real é o LFM2.5-VL-3B executando sozinho versus o mesmo modelo executando com o modelo de rascunho acoplado.

Leia dessa forma e a decisão se resume a uma única pergunta: a memória extra e a complexidade extra de runtime proporcionam latência suficiente para fazer diferença na sua carga de trabalho? Os próprios números da Liquid AI dizem que sim para trabalhos intensivos em decodificação e dizem explicitamente que não quando o prefill domina. Nenhum dos dois lados disso foi reproduzido fora da empresa.

Os dois checkpoints, lado a lado

O que difere entre eles é a história completa, então vale a pena colocar os dois repositórios lado a lado antes que a discussão sobre velocidade comece.

• Função — LFM2.5-VL-3B gera texto e responde sobre imagens; LFM2.5-VL-3B-DSpark propõe tokens para ele verificar e não gera nada utilizável por si só

• Parâmetros — 3,1B para o modelo-alvo, 279,5M em BF16 para o modelo de rascunho, o que a Liquid avalia como um aumento de 8,9% no número de parâmetros implantados

• Arquitetura — o alvo é um modelo híbrido construído sobre um backbone LFM2.5-2.6B com um codificador de visão SigLIP2 NaFlex; o drafter consiste em 4 camadas de atenção completa com tamanho oculto de 2.048, com atenção de consultas agrupadas, além de uma cabeça de Markov e uma cabeça de confiança

• Janela de contexto — 32.768 tokens para o alvo; o rascunhador não carrega contexto próprio e herda o do alvo

• Codificador de visão — SigLIP2 NaFlex 400M no modelo alvo; o modelo de rascunho não tem nenhum e nunca vê a imagem diretamente

• Vocabulário — 128.000, e o embedding e a cabeça LM do modelo de rascunho estão atrelados ao alvo em vez de serem duplicados, e é por isso que o custo de memória é menor do que 279,5M parâmetros sugeririam

• Licença — ambos são distribuídos sob a licença LFM1.0 da Liquid, que consta como "other" no Hugging Face em vez de uma licença OSI, então leia os termos antes de uma implantação comercial

Formatos — o modelo alvo é distribuído como quantizações safetensors, GGUF, ONNX e MLX; o drafter é distribuído como safetensors e um único GGUF F16 de aproximadamente 567 MB

Uma linha nessa lista merece destaque porque é a razão mecânica pela qual esse pareamento chega a funcionar: o modelo de rascunho não é um pequeno modelo de visão. Ele não tem codificador de visão e nunca toca a imagem. No momento em que os tokens chegam às camadas ocultas das quais ele faz o rascunho, um patch de imagem e um token de texto são ambos apenas tensores, portanto a modalidade é invisível para a computação de rascunho. Foi isso que permitiu à Liquid portar uma técnica desenvolvida para modelos de texto para um VLM sem redesenha-la.

O que o redator altera e o que deixa como está

O modelo alvo não muda. Isso não é marketing — é a propriedade de correção da decodificação especulativa. Na decodificação gulosa, cada token de rascunho é verificado pelo alvo, então a saída é exatamente o que o alvo teria produzido sozinho. Em configurações de amostragem equivalentes com temperatura diferente de zero, a distribuição de saída corresponde à do alvo. O modelo de rascunho troca memória por tempo e não mexe em mais nada.

O que significa que todos os números de qualidade que encontrar para o LFM2.5-VL-3B se aplicam sem alterações à configuração emparelhada. Na avaliação da própria Liquid, o modelo-alvo obtém 80,7 no ScreenSpot-v2, 61,5 no BLINK, 58,3 no MuirBench, 73,1 no MME, 63,3 no MMStar, 81,3 no ChartQA e 88,7 no POPE — todos relatados pelo fornecedor, nenhum reproduzido de forma independente, e todos igualmente verdadeiros quer o modelo de rascunho esteja associado ou não. Não há qualquer trade-off entre qualidade e velocidade a ponderar aqui, e qualquer página de comparação que apresente um leu mal o modelo.

O que muda é o custo de um token em tempo de relógio. A Liquid mede ganhos de velocidade de decodificação de 2,04× a 2,66× em uma única H100 em BF16 via SGLang com tamanho de bloco 9, de 2,30× a 3,13× em um Apple M5 Max via MLX-VLM com tamanho de bloco 8, e de 1,57× a 2,14× em um M3 Ultra via llama.cpp. De ponta a ponta, as mesmas execuções ficam em 1,64×–2,27×, 1,56×–2,62× e 1,30×–1,77×, respectivamente. Esses pares são todo o argumento: a decodificação melhora aproximadamente duas vezes mais do que a ponta a ponta, e a diferença é a parte da carga de trabalho que o drafter não consegue tocar.

O problema do prefill, declarado pelo fornecedor

A frase mais útil no anúncio da própria Liquid é a que argumenta contra uma leitura ilimitada de sua manchete. A inferência de visão-linguagem paga um custo de prefill que a inferência de texto não paga: a imagem passa por um codificador de visão, e o backbone de linguagem então processa as centenas de tokens visuais que esse codificador emite. Em um dispositivo de borda, esse prefill representa uma grande parcela da latência ponta a ponta. A decodificação especulativa acelera apenas o decode — a codificação de visão e o prefill permanecem inalterados. Onde o prefill domina, um ganho de velocidade de 3× no decode se converte em um ganho ponta a ponta muito menor.

Essa é a lei de Amdahl aplicada pelo fornecedor ao produto do próprio fornecedor, e isso deveria determinar quem lê esta página. Uma transcrição longa de uma única página digitalizada, uma legenda, uma conversa com vários turnos levando uma imagem adiante — com uso intenso de decodificação — e o modelo de rascunho justifica seus 279,5 milhões de parâmetros. Uma pergunta curta sobre uma imagem grande de alta resolução — com uso intenso de prefill — e não o faz. Coloque o mesmo alvo em um servidor com alta concorrência e o cenário muda de novo: o Liquid mede uma fronteira entre throughput e interatividade em vez de um único número, e relata que o DSpark mantém sua vantagem em todos os níveis de concorrência testados, ao passo que a diferença diminui conforme a concorrência aumenta.

Duas notas menores de escopo da mesma fonte. Todas as medições usam processamento de 16 bits tanto para o codificador visual quanto para o backbone de linguagem, e a aceleração de modelos quantizados está fora do escopo da versão. Se seu plano era combinar uma exportação alvo de 4 bits com o drafter porque todo o apelo de um VLM de 3B é caber em alguns gigabytes, não foi essa combinação que foi medida.

O que anexá-lo realmente custa a você

A memória é o custo visível e o card quantifica isso: 8,9% mais parâmetros no stack implantado. A complexidade de execução é a invisível. O SGLang precisa da v0.5.19 ou mais recente e de uma linha de inicialização contendo --speculative-algorithm DSPARK, o caminho do modelo draft e um tamanho de bloco; o exemplo do próprio card também desativa o cache radix e fixa uma fração de memória estática, que são decisões de serving sobre as quais você agora precisa ponderar. O MLX-VLM precisa da v0.7.2 ou mais recente e recebe o drafter por meio de --draft-model, mas a decodificação DSpark lá atualmente usa amostragem greedy, então a temperatura precisa ser forçada a 0 — uma restrição real se a sua aplicação depende da diversidade de amostragem. O llama.cpp funciona por meio do drafter GGUF emparelhado com o alvo GGUF, não com o checkpoint safetensors original.

Há mais um custo que aparece em produção, e não em um benchmark: o modelo de rascunho e o modelo alvo precisam caminhar juntos. A defasagem de versão entre eles é um modo de falha que não existe em uma implantação de modelo único, e fazer o rollout de qualquer um dos dois de forma independente agora é um problema de dois artefatos.

Este é um pareamento auto-hospedado. O OrcaRouter não roteia o LFM2.5-VL-3B nem seu drafter — você baixa os dois e os serve por conta própria —, então a questão de roteamento diz respeito a tudo para o que o modelo pequeno repassa. A maioria das implantações que combina um VLM de borda de 3B com o drafter ainda tem consultas que o modelo pequeno não deveria responder, e enviá-las para um único endpoint que cobre mais de 200 modelos pelo preço de tabela de cada provedor, com failover automático se um provedor degradar, é uma integração em vez de uma por fornecedor. Também significa que, no momento em que um provedor reduz um preço, sua tarifa reflete isso no mesmo dia, em vez de na próxima renovação de contrato.

Qual deles baixar

Se a sua carga de trabalho for pesada em decodificação e o seu hardware for um dos três que a Liquid testou, acople o modelo de rascunho — a desvantagem é limitada, porque a saída é comprovadamente a do alvo e o custo de memória fica abaixo de um décimo de um modelo. Se a sua latência for dominada pelo prefill, ou se você estiver executando um alvo quantizado, ou se depender de amostragem não gulosa em um runtime que ainda não removeu essa restrição, execute o LFM2.5-VL-3B sozinho. Ele é rápido nos seus próprios termos: 228 tokens por segundo em um M5 Max, 116 em um AMD Ryzen AI Max+ 395 e 20 em um Galaxy S26 Ultra, todos números do fornecedor, em cerca de 3 GB de memória.

O que ninguém pode lhe dizer ainda é se os números da Liquid se sustentam no seu hardware. O drafter tinha 37 downloads no Hugging Face no momento em que este texto foi escrito e nenhuma reprodução independente de qualquer número em suas tabelas. A engenharia é sólida e o argumento de correção é uma prova, não uma afirmação, mas a magnitude é uma medição — e medições de um único laboratório em um único conjunto de máquinas são exatamente o tipo de número que você deve verificar por conta própria antes de colocá-lo em um plano de capacidade.

O OrcaRouter alcança mais de 200 modelos por meio de uma única chave, com o preço de tabela de cada provedor repassado diretamente com 0% de markup e failover automático entre provedores. preço de tabela do provedor repassado com 0% de markup O pareamento nesta página é auto-hospedado de qualquer forma - o roteador serve para tudo a que o modelo pequeno repassa, e isso significa que um corte de preço do provedor aparece na sua tarifa no mesmo dia.