Liquid AI LFM2.5-VL-3B-DSpark acelera a decodificação visual, mas a manchete de 3,13x conta apenas metade da história

A Liquid AI lançou o LFM2.5-VL-3B-DSpark com o resultado de destaque de uma decodificação até 3,13x mais rápida para seu modelo compacto de visão e linguagem. A melhoria se concentra na geração de tokens, não em todo o processo de compreender uma imagem e produzir uma resposta.

Essa distinção define a relevância do Liquid AI LFM2.5-VL-3B-DSpark. O modelo experimental de rascunho mostra que a decodificação especulativa pode funcionar em tarefas visuais e textuais, tanto em hardware de datacenter quanto de consumo. No entanto, os próprios resultados da Liquid AI situam o melhor ganho de ponta a ponta em 2,62x, abaixo do pico de decodificação.

O lançamento leva desenvolvedores a reconsiderar como otimizam aplicações locais de visão e linguagem. A compressão de modelos e arquiteturas menores já não são as únicas rotas para reduzir a latência. Um gerador de rascunhos separado pode acelerar um modelo-alvo existente, preservando seu comportamento de saída sob configurações de decodificação equivalentes.

A comparação, portanto, não é entre a Liquid AI e um único modelo concorrente. Trata-se da decodificação especulativa em contraste com a prática convencional de tornar o principal modelo de visão e linguagem menor, mais simples ou menos preciso para ganhar velocidade.

Liquid AI LFM2.5-VL-3B-DSpark adiciona um modelo de rascunho dedicado

O lançamento separa a qualidade da resposta de uma parte importante do problema de latência.

O Liquid AI LFM2.5-VL-3B-DSpark é um modelo de rascunho de 279,5 milhões de parâmetros, criado especificamente para o LFM2.5-VL-3B. Ele não substitui o modelo-alvo de 3 bilhões de parâmetros nem responde a solicitações de forma independente. Em vez disso, propõe vários tokens prováveis antes que o modelo maior os verifique em conjunto.

Esse processo é chamado de decodificação especulativa, um método que usa um preditor menor para elaborar tokens que serão verificados em paralelo pelo modelo-alvo. Os tokens aceitos reduzem o número de passagens caras pelo modelo-alvo necessárias para gerar uma resposta. As propostas rejeitadas são corrigidas pelo alvo.

A Liquid AI afirma que o gerador de rascunhos contém quatro camadas de atenção completa, uma cabeça de Markov e uma cabeça de confiança. Seu bloco de treinamento contém nove tokens propostos. A implantação usa blocos de oito ou nove, dependendo do hardware e do framework de inferência.

A empresa publicou o modelo nos formatos Safetensors e GGUF por meio de seu repositório de modelos. Ele oferece suporte ao SGLang em GPUs Nvidia, ao MLX-VLM em Apple silicon e ao llama.cpp por meio do checkpoint GGUF.

Essa cobertura de frameworks é importante porque a aceleração de inferência frequentemente permanece restrita a um artigo ou a uma implementação de pesquisa personalizada. Aqui, a Liquid AI conectou seu gerador de rascunhos a três caminhos de implantação já usados em servidores, Macs e modelos quantizados locais.

O SGLang exige a versão 0.5.19 ou posterior para a configuração publicada. O MLX-VLM exige a versão 0.7.2 ou posterior e atualmente executa essa implementação DSpark com amostragem gulosa. A Liquid AI instrui usuários do MLX a definir a temperatura como zero.

O modelo-alvo chegou antes do gerador de rascunhos. A Liquid AI apresentou o LFM2.5-VL-3B em agosto de 2026 como um modelo de visão e linguagem com pesos abertos voltado à implantação na borda. O modelo combina uma base de linguagem com um codificador visual para imagens, documentos, grounding, reconhecimento óptico de caracteres e uso de ferramentas visuais.

A Liquid AI afirmou anteriormente que o alvo poderia decodificar 228 tokens por segundo em um M5 Max. Também relatou 116 tokens por segundo em um Ryzen AI Max+ 395 e 20 em um Galaxy S26 Ultra. Esses números anteriores vieram dos próprios testes da empresa.

O lançamento do DSpark altera o pacote de implantação, e não as capacidades aprendidas do modelo subjacente. Os desenvolvedores conectam o gerador de rascunhos durante a inferência, enquanto o LFM2.5-VL-3B continua responsável por aprovar cada token gerado.

Na decodificação gulosa, o alvo aceita um token de rascunho apenas quando ele corresponde ao token que o próprio alvo teria selecionado. Portanto, a resposta resultante deve corresponder à geração gulosa comum. Em temperaturas diferentes de zero, a amostragem correspondente pode preservar a distribuição de saída do modelo-alvo em vez de uma única sequência determinística.

Essa propriedade confere à decodificação especulativa uma proposta de valor diferente da quantização ou da destilação. Essas técnicas podem alterar a precisão numérica, o tamanho do modelo ou o comportamento aprendido. O DSpark, em vez disso, tenta reduzir o tempo gasto para chegar às decisões originais do modelo-alvo.

É por isso que o lançamento cria uma competição significativa entre duas rotas de otimização. Os desenvolvedores podem reduzir o trabalho realizado pelo modelo principal ou prever uma parcela maior desse trabalho e verificar essas previsões de modo eficiente.

O resultado de 3,13x depende de hardware, carga de trabalho e medição

O maior número da Liquid AI descreve um resultado de decodificação, não uma aceleração universal de aplicações.

A Liquid AI avaliou o gerador de rascunhos em seis categorias do MMSpec: perguntas e respostas visuais gerais, reconhecimento de texto, descrição de imagens, análise de gráficos, raciocínio complexo e conversa com múltiplos turnos. A empresa testou tamanho de lote um em hardware Apple e em uma GPU H100.

Em um M5 Max usando MLX-VLM, a Liquid AI relatou ganhos de decodificação entre 2,30x e 3,13x. As melhorias de ponta a ponta variaram de 1,56x a 2,62x. O pico de 3,13x ocorreu na carga de trabalho de descrição de imagens COCO.

A empresa também testou um M3 Ultra com llama.cpp. A decodificação melhorou entre 1,57x e 2,14x, segundo o relatório, enquanto o desempenho de ponta a ponta melhorou de 1,30x a 1,77x.

Em uma única GPU H100 de 80 GB com SGLang, a Liquid AI mediu ganhos de decodificação entre 2,04x e 2,66x. As melhorias de ponta a ponta variaram de 1,64x a 2,27x. A divulgação detalhada dos benchmarks da empresa apresenta configurações e resultados por tarefa.

Esses testes usaram processamento de 16 bits para o codificador visual e a base de linguagem. A configuração H100 usou BF16, um bloco de rascunho de nove, tamanho de lote um e temperatura zero. Os testes da Apple usaram FP16, um bloco de oito e até 2.048 tokens gerados.

O comprimento mediano das respostas na avaliação da Apple foi de 90 tokens. Esse detalhe é importante porque o comprimento da saída altera a parcela de uma solicitação dedicada à decodificação. Um sistema que produz uma descrição longa dá ao gerador de rascunhos mais tempo para compensar sua sobrecarga inicial.

Respostas curtas criam um equilíbrio menos favorável. Se uma aplicação retorna um rótulo, uma coordenada ou uma frase, a codificação da imagem e o processamento do prompt podem predominar. A geração mais rápida passa então a afetar uma parcela menor da espera total.

A aceitação dos rascunhos ajuda a explicar a aceleração relatada. A Liquid AI mediu aproximadamente 3,2 a 4,5 tokens aceitos por passagem de verificação nas pilhas Apple. Seus resultados na H100 variaram de 3,46 a 4,57 tokens aceitos.

Um comprimento de aceitação maior significa que o alvo valida mais saída útil a cada passagem. Ainda assim, a aceitação não se traduz diretamente em ganhos de velocidade equivalentes. A execução do gerador de rascunhos, a sincronização, o acesso à memória e a sobrecarga do framework ainda consomem tempo.

Os resultados também variam conforme a tarefa. A descrição de imagens produziu a maior melhoria de decodificação no MLX, enquanto a conversa com múltiplos turnos registrou 2,30x. Os ganhos de ponta a ponta foram de 2,59x e 1,91x, respectivamente.

Essa variação impede uma interpretação responsável de “até 3,13x” como resultado esperado para cada assistente visual. Trata-se de um teto observado em uma configuração publicada. O resultado de uma aplicação dependerá de seu hardware, comprimento do prompt, comprimento da saída, configurações de amostragem e carga de trabalho visual.

A Liquid AI afirma que o DSpark manteve vantagem em maior concorrência nos testes com H100. No entanto, a diferença diminuiu à medida que a concorrência aumentou. Isso sugere que o benefício relativo do gerador de rascunhos muda quando a GPU passa de uma decodificação limitada por memória para uma execução limitada por computação.

Para equipes de produto, a questão prática não é se o valor de pico é real dentro do teste da Liquid AI. A questão é se o perfil de latência delas se assemelha ao teste que o produziu. Isso exige medir cada fase da inferência, em vez de copiar um multiplicador de manchete para planos de capacidade.

Como a decodificação especulativa da Liquid AI preserva o modelo-alvo

O DSpark tenta elaborar rascunhos mais à frente sem transformar erros de previsão em saída final.

A geração autorregressiva padrão produz um token após o outro. Cada novo token exige outra passagem pelo modelo-alvo, mesmo quando a continuação é altamente previsível. Essa estrutura serial pode deixar o hardware subutilizado durante uma decodificação limitada por memória.

A decodificação especulativa insere um modelo menor nesse ciclo. O gerador de rascunhos propõe um bloco de tokens futuros, e o alvo avalia essas posições em conjunto. O trabalho é economizado quando várias propostas sobrevivem à verificação.

O desafio é produzir propostas com rapidez e precisão suficientes para justificar o modelo adicional. Um gerador de rascunhos fraco cria tokens rejeitados. Um gerador pesado prevê bem, mas consome tempo demais para produzir seu bloco.

O DSpark combina geração paralela com um componente sequencial leve. Sua cabeça de Markov introduz dependência limitada entre as posições propostas, enquanto a cabeça de confiança estima se propostas posteriores devem ser verificadas. Esse projeto busca preservar a coerência do bloco sem tornar a elaboração de rascunhos totalmente autorregressiva.

A pesquisa sobre DSpark descreve a abordagem como decodificação especulativa programada por confiança com geração semiautorregressiva. Seu principal equilíbrio envolve a qualidade das propostas, a latência do rascunho e o número de tokens enviados para verificação.

A elaboração puramente paralela pode gerar um bloco rapidamente, mas a precisão frequentemente cai para tokens mais distantes no bloco. Cada posição depende de um contexto que inclui suposições anteriores. Portanto, erros podem se acumular ao longo da proposta.

Um gerador de rascunhos totalmente autorregressivo mantém dependências mais fortes, mas recria parte do gargalo serial. A estrutura híbrida do DSpark tenta ocupar o meio-termo. Ela adiciona uma pequena cabeça sequencial após a operação paralela de rascunho.

O mecanismo de confiança aborda outra fonte de desperdício. Verificar um bloco fixo inteiro faz pouco sentido quando o gerador de rascunhos espera que seus tokens posteriores falhem. Um agendador pode encurtar o prefixo enviado antes que posições de baixa confiança consumam capacidade do alvo.

A configuração publicada do LFM2.5-VL-3B-DSpark usa uma cabeça de Markov de posto 256 e uma cabeça de confiança separada. Seu vocabulário contém 128.000 tokens. A arquitetura permanece vinculada ao seu modelo-alvo designado e não pode servir como um gerador de rascunhos genérico e intercambiável para todos os VLMs.

Essa relação específica com o modelo é tanto uma força quanto uma limitação. Treinar contra um único alvo pode melhorar o alinhamento das propostas. No entanto, uma equipe que mudar para outro modelo-alvo precisará de um checkpoint compatível, de um processo de treinamento e de integração com o runtime.

A descrição de “sem perdas” também exige uma interpretação precisa. Na decodificação gulosa com temperatura zero, a verificação preserva as escolhas exatas de tokens que o alvo faria sozinho. O gerador de rascunhos não recebe permissão para substituir uma alternativa apenas plausível.

Em temperaturas diferentes de zero, o objetivo passa de reproduzir uma sequência para preservar a distribuição do alvo. A amostragem especulativa correta pode fazer isso sob configurações equivalentes, de acordo com a pesquisa fundamental sobre amostragem. A velocidade ainda depende da frequência com que as distribuições do rascunho e do alvo se alinham.

A Liquid AI relata que o aumento da temperatura reduziu a aceitação em seus experimentos. Mais probabilidade se espalha para tokens de classificação inferior, criando mais oportunidades para que o gerador de rascunhos e o alvo discordem. Consequentemente, a amostragem criativa pode proporcionar ganhos menores do que a geração determinística.

Isso é importante para o design de aplicações. A extração de documentos, o grounding visual, a leitura de gráficos e as respostas restritas costumam usar temperaturas baixas. Conversas abertas sobre imagens podem usar mais amostragem, tornando os resultados gananciosos publicados menos representativos.

A decodificação especulativa da Liquid AI, portanto, é especialmente adequada para saídas previsíveis. Criar legendas para imagens padronizadas de produtos, ler recibos, descrever capturas de tela de interfaces e extrair fatos estruturados são cargas de trabalho plausíveis. Seus ganhos reais ainda exigem medição local.

A Decodificação Mais Rápida Não Elimina o Gargalo de Visão e Linguagem

A principal incerteza é quanto de uma solicitação real permanece fora da fase de decodificação acelerada.

Uma solicitação de visão e linguagem envolve mais trabalho do que a geração de texto. O sistema precisa codificar a imagem, transformá-la em representações visuais, processar esses tokens visuais junto com o prompt e, então, decodificar a resposta.

O DSpark acelera apenas a etapa final. Ele não torna a codificação de imagens mais rápida. Também deixa o prefill inalterado, o que significa que o modelo-alvo ainda processa o prompt e o contexto de tokens visuais antes de produzir seu primeiro token de resposta.

Esse limite explica a diferença entre os resultados de decodificação e os de ponta a ponta. A Liquid AI relatou decodificação até 3,13x mais rápida no M5 Max, mas sua maior melhoria total foi de 2,62x. Outras tarefas apresentaram diferenças maiores.

No TextVQA, a empresa mediu uma melhoria de 2,69x na decodificação e um ganho de 1,56x de ponta a ponta no M5 Max. O resultado indica que o processamento de imagens e o prefill consumiram uma parcela substancial do tempo original da solicitação.

A limitação segue a lei de Amdahl, que limita a aceleração geral quando parte de uma carga de trabalho permanece inalterada. Se a decodificação representa metade da latência de base, mesmo um decodificador infinitamente rápido não consegue melhorar toda a solicitação em mais de 2x.

O hardware de borda torna essa restrição especialmente relevante. Dispositivos de consumo oferecem menos capacidade computacional que GPUs de datacenter para codificação visual e prefill de contexto longo. Uma imagem grande ou um prompt com várias imagens pode atrasar o primeiro token antes que a decodificação especulativa comece a ajudar.

O benchmark independente MMSpec reforça a necessidade de uma interpretação cautelosa. Seus autores avaliaram 600 amostras em seis categorias de tarefas e dez métodos de decodificação especulativa. Eles concluíram que o ganho de throughput isoladamente não representava de forma confiável o desempenho de latência.

O MMSpec também constatou que técnicas projetadas para modelos de linguagem exclusivamente textuais podem se degradar em contextos multimodais. Dependências entre modalidades alteram quais propostas provavelmente serão aceitas. A percepção visual se torna mais importante à medida que os tamanhos de lote aumentam.

A Liquid AI seguiu as categorias de tarefas do MMSpec, o que amplia o escopo de sua avaliação interna. No entanto, a própria Liquid AI conduziu e publicou os testes de desempenho do DSpark. Réplicas independentes em dispositivos comuns e com prompts de produção ainda são limitadas.

A linha de base da comparação merece a mesma atenção. Os multiplicadores publicados comparam o mesmo modelo-alvo LFM2.5-VL-3B, com e sem seu drafter, sob frameworks especificados. Eles não estabelecem que o sistema combinado supera todos os VLMs concorrentes.

Também não comparam o sistema com estratégias alternativas de latência. Desenvolvedores podem quantizar o alvo, reduzir a resolução da imagem, armazenar embeddings visuais em cache, encurtar prompts, agrupar solicitações em lotes ou selecionar um modelo menor. Essas mudanças afetam partes diferentes do orçamento de latência.

A memória é outra consideração operacional. O drafter é pequeno ao lado do modelo-alvo de 3 bilhões de parâmetros, mas não é gratuito. Seus pesos, cache, estado de execução e integração consomem capacidade que importa em dispositivos com recursos limitados.

A compatibilidade cria mais atrito. SGLang, MLX-VLM e llama.cpp agora oferecem caminhos publicados, mas equipes que usam outros sistemas de serving não podem presumir suporte imediato. A adoção em produção requer carregamento estável, observabilidade, comportamento de batching e tratamento de falhas.

O caminho atual do DSpark no MLX-VLM, limitado à geração gananciosa, restringe seus casos de uso imediatos. Aplicações que dependem de geração amostrada precisam de outra stack compatível ou devem esperar por suporte mais amplo à amostragem. Mesmo assim, temperaturas mais altas podem reduzir a aceitação dos rascunhos.

Portanto, o lançamento deve ser avaliado como uma otimização de sistemas crível, com limites claramente declarados. Ele não prova que a inferência visual se tornou 3,13x mais rápida em todos os sentidos relevantes.

A Disputa Real É Entre Melhor Previsão e Menos Trabalho do Modelo

O DSpark fortalece uma abordagem em que os desenvolvedores mantêm o alvo intacto e otimizam a frequência com que ele precisa executar.

A resposta padrão da IA de borda à latência tem sido reduzir a carga de trabalho do modelo-alvo. As equipes usam menos parâmetros, menor precisão, prompts mais curtos, imagens menores ou destilação específica para a tarefa. Cada técnica pode melhorar a responsividade, mas também pode introduzir concessões em qualidade ou flexibilidade.

O Liquid AI LFM2.5-VL-3B-DSpark propõe outro caminho. Manter o alvo existente e prever várias etapas futuras com um acompanhante especializado. Permitir que o alvo verifique essas estimativas sem abrir mão do controle sobre a saída final.

Essa abordagem se torna atraente quando uma equipe já aceita as capacidades do modelo-alvo. Substituí-lo exigiria novas avaliações, alterações nos prompts, verificações de segurança e ajustes de produto. Anexar um drafter pode preservar uma parcela maior desse investimento.

A abordagem também é adequada para implantação local, onde a largura de banda de memória frequentemente limita a geração de tokens. Verificar um bloco pode usar o hardware com mais eficiência do que carregar repetidamente o estado do modelo para um único token. Os resultados da Liquid AI em dispositivos Apple tornam essa possibilidade concreta.

Ainda assim, modelos menores mantêm vantagens. Eles simplificam o empacotamento, reduzem o uso total de memória e aceleram etapas que uma otimização restrita ao decodificador não consegue alcançar. Um codificador visual compacto pode melhorar o tempo até o primeiro token, enquanto o DSpark não pode.

A quantização também pode ser combinada com a decodificação especulativa, em vez de competir exclusivamente com ela. A Liquid AI fornece um drafter GGUF compatível com seu alvo GGUF. Assim, uma stack local pode reduzir a precisão e adicionar drafting, desde que o runtime ofereça suporte correto ao par.

Essa combinação desloca a questão de engenharia de escolher uma técnica para atribuir cada técnica ao gargalo adequado. A quantização reduz o tamanho dos pesos e o custo aritmético. O pré-processamento de imagens altera o custo de visão. A especulação visa a geração autorregressiva.

É por isso que o profiling por fase se torna essencial. Um assistente de documentos que analisa páginas em alta resolução pode gastar a maior parte do tempo antes da decodificação. Uma ferramenta de chat visual que produz descrições detalhadas pode gastar muito mais tempo gerando a saída.

A mesma distinção se aplica à experiência do usuário. O tempo até o primeiro token determina se uma aplicação parece responsiva no início. Tokens por segundo determinam se uma resposta longa parece fluida depois que a geração começa.

O DSpark melhora diretamente a segunda medida. Ele melhora a latência total quando a decodificação ocupa uma parcela suficiente da solicitação. Não garante uma melhoria proporcional na primeira.

Os desenvolvedores também devem separar a velocidade para um único usuário do throughput de uma frota. A Liquid AI observou uma vantagem em todos os níveis medidos de concorrência no H100, mas a diferença diminuiu sob carga mais alta. A economia de produção depende das misturas de solicitações, do batching e das metas de nível de serviço.

O aspecto mais consequente do lançamento é, portanto, arquitetural. A Liquid AI empacotou a decodificação especulativa como parte de uma família de modelos visuais implantável, em vez de apresentá-la apenas como pesquisa.

Se esse padrão se disseminar, os lançamentos de modelos poderão incluir cada vez mais um alvo, várias quantizações e drafters específicos para hardware. A otimização de inferência passaria a fazer parte do artefato do modelo, em vez de ser uma decisão posterior de serving.

Essa direção pressiona outros desenvolvedores de modelos de pesos abertos. Publicar apenas um checkpoint deixa as equipes downstream responsáveis pela aceleração. Enviar um drafter compatível oferece uma história de latência mais completa, mesmo quando os ganhos medidos continuam dependentes da carga de trabalho.

Três Sinais Mostrarão se o Ganho de Velocidade Importa na Prática

Testes independentes, suporte mais amplo à amostragem e perfis de aplicações reais determinarão se o DSpark se tornará um padrão de implantação repetível.

O primeiro sinal é a replicação independente em hardware acessível. Os desenvolvedores devem acompanhar testes em Macs da série M, GPUs de consumo e sistemas de borda usando prompts idênticos com e sem o drafter.

Relatórios úteis precisam divulgar dimensões das imagens, comprimento do prompt, comprimento da saída, temperatura, quantização e versão do runtime. Um único número de tokens por segundo não explica se a resposta completa da aplicação se tornou significativamente mais rápida.

Uma replicação próxima das faixas da Liquid AI fortaleceria o argumento da empresa. Ganhos menores ou inconsistentes sugeririam que as cargas de trabalho publicadas favorecem o drafter mais do que as aplicações cotidianas.

O segundo sinal é um suporte mais amplo de runtime e amostragem. O MLX-VLM atualmente limita o caminho publicado do DSpark à geração gananciosa, enquanto o SGLang visa implantações Nvidia e o llama.cpp atende aos casos de uso do GGUF.

O suporte em motores de inferência adicionais reduziria o custo de integração. A amostragem estável com temperatura diferente de zero também tornaria o método mais relevante para ferramentas de chat visual e descrição criativa.

Os desenvolvedores devem examinar as taxas de aceitação à medida que a amostragem muda. A Liquid AI afirma que temperaturas mais altas reduziram a aceitação e o throughput em seus experimentos. Testes em produção devem revelar se essas quedas continuam aceitáveis para produtos conversacionais.

O terceiro sinal é se as equipes relatam ganhos por fase em aplicações reais. As métricas decisivas são tempo até o primeiro token, taxa de decodificação, latência de ponta a ponta, pico de memória e throughput sob a concorrência esperada.

Um assistente visual de formato longo pode se beneficiar substancialmente porque a geração domina sua sessão. Um fluxo de trabalho de OCR que retorna poucos campos pode ganhar muito menos porque a codificação visual e o prefill ocupam a maior parte da solicitação.

As equipes que avaliam o Liquid AI LFM2.5-VL-3B-DSpark devem começar com rastros, não com multiplicadores de manchete. Meçam a parcela de base consumida pela codificação de imagens, pelo prefill e pela decodificação. Em seguida, anexem o drafter e repitam a mesma carga de trabalho.

Verifiquem a equivalência da saída sob decodificação gananciosa e o comportamento distribucional sob amostragem compatível. Meçam separadamente inicializações quentes e frias. Incluam pressão de memória e desempenho térmico sustentado ao testar laptops ou sistemas da classe móvel.

O lançamento fornece detalhes de implementação suficientes para tornar essas avaliações possíveis. Também oferece aos desenvolvedores um lembrete útil: capacidade do modelo e comportamento de inferência são problemas de engenharia distintos.

O número de 3,13x da Liquid AI é melhor entendido como evidência de que um drafter compatível pode acelerar materialmente uma fase da inferência multimodal local. Os números de ponta a ponta mostram tanto o valor quanto o limite dessa afirmação.

Os modelos de rascunho compatíveis se tornarão acompanhantes padrão para VLMs de pesos abertos ou continuarão sendo otimizações especializadas para cargas de trabalho com saídas longas? A resposta virá de rastros de aplicações reproduzíveis, não de um único benchmark de pico.