Liquid AI lança LFM2.5-VL-DSpark: modelo de visão 3B com modelo de rascunho, decodificação até 3,13x mais rápida
Segundo publicação do blog da Liquid AI de setembro de 2026, a Liquid AI lançou um modelo de rascunho experimental DSpark para o modelo de linguagem visual de pesos abertos LFM2.5-VL-3B, acrescentando cerca de 280 milhões de parâmetros (aumento de 8,9% em relação ao modelo-alvo de 3B), com alegação de decodificação até 3,13x mais rápida em dispositivos e até 2,66x em H100, com suporte no primeiro dia a llama.cpp, MLX-VLM e SGLang.
O que mudou
A Liquid AI lançou em setembro de 2026 o modelo de rascunho experimental DSpark, que acompanha seu modelo de linguagem visual LFM2.5-VL-3B. Segundo o blog do fabricante, esse modelo de rascunho segue a linha arquitetural do DSpark da versão textual do LFM2.5: captura os estados ocultos do modelo-alvo em camadas de acesso fixas e, com base nisso, redige um lote de tokens candidatos; os patches de imagem e os tokens de texto são projetados para um espaço de representação compartilhado antes de entrar nessas camadas, de modo que o modelo de rascunho processa estados ocultos de dimensão consistente, e o algoritmo de inferência é o mesmo do modelo textual. O modelo de rascunho adota uma estrutura de 4 camadas apenas com atenção, block size de 9 e cerca de 279,5 milhões de parâmetros, decompostos em 193 milhões para a pilha do decodificador, 21 milhões para a projeção de estados ocultos, 65,5 milhões para o Markov head e 6400 para Norms e head de confiança. O fabricante afirma que, no M5 Max com MLX, a decodificação por tarefa é de 2,30 a 3,13 vezes mais rápida e o tempo de ponta a ponta de 1,56 a 2,62 vezes melhor; no M3 Ultra com llama.cpp, a decodificação é de 1,57 a 2,14 vezes mais rápida; no H100, os dados de decodificação e de ponta a ponta aparentam ter anomalia tipográfica no texto original. O fabricante enfatiza que a decodificação especulativa é exata, que o modelo-alvo verifica cada token proposto, que a saída gulosa é idêntica à do uso isolado do modelo-alvo, e que o modelo de rascunho é oferecido no Hugging Face nos formatos Safetensors e GGUF.
Impacto para desenvolvedores
Para desenvolvedores que implantam modelos multimodais localmente ou em dispositivos de borda, o significado deste lançamento não está nos números absolutos de velocidade, mas na razão de parâmetros entre o modelo de rascunho e o modelo-alvo — cerca de 8,9% —, o que significa que o incremento de memória de vídeo e de memória é controlável. Porém, a maioria das taxas de aceleração são métricas da fase de decodificação, e o ganho de ponta a ponta depende da proporção de codificação visual e prefill na carga de trabalho, o que o próprio fabricante explicou citando a Lei de Amdahl. Isso cria uma bifurcação: cenários com saídas longas, diálogo multi-turno ou descrição de imagens podem se aproximar dos números de ponta a ponta alegados pelo fabricante; cenários de pergunta e resposta com uma única imagem longa, que exigem processar primeiro muitos tokens visuais e terminam rápido, terão ganho bem menor. Além disso, executar o modelo de rascunho depende de branches do llama.cpp, MLX-VLM e SGLang ainda não integradas à linha principal ou que exigem builds específicos, e o custo de integração não pode ser ignorado. Vale notar que, até o momento desta verificação, o catálogo atual de modelos do KimiSeek não tem entradas para LFM2.5-VL-3B ou LFM2.5-VL-DSpark, e a disponibilidade de API e de pesos mencionada na fonte é alegação do fabricante.
Integração e avaliação
Recomendação 1: meça primeiro a proporção da decodificação no tempo total de latência da sua carga antes de decidir se vale introduzir o modelo de rascunho. A fonte menciona que a decodificação especulativa acelera apenas a decodificação, não a codificação visual nem o prefill, e que em dispositivos de borda o prefill representa proporção maior da latência de ponta a ponta. O pré-requisito é ter dados discriminados de latência do primeiro token e de tempo de decodificação; recomenda-se rodar duas configurações, baseline e modelo de rascunho, com o mesmo conjunto de seis tipos de tarefas visuais (VQA geral, VQA de texto, descrição de imagens, VQA de gráficos, raciocínio complexo e diálogo multi-turno), avaliando por quantis de latência de ponta a ponta em vez de apenas throughput de decodificação. Se sua carga for predominantemente de imagens curtas com saídas longas, o modelo de rascunho pode compensar; se for predominantemente de pergunta e resposta com uma única imagem longa, o teto de ganho é limitado pelo prefill. Recomendação 2: escolha entre llama.cpp e SGLang pela forma de implantação, não pela aceleração de pico alegada. A fonte indica modos de inicialização diferentes: o SGLang monta o modelo de rascunho por parâmetros como --speculative-dspark-block-size e exige explicitamente desativar o radix cache; o lado do llama.cpp requer --spec-type draft-dspark junto com --spec-draft-n-max 8. O pré-requisito é que o build usado contenha o PR correspondente, caso contrário esses parâmetros não estarão disponíveis. Na avaliação, recomenda-se registrar draft_n e draft_n_accepted de cada resposta, usando a taxa de aceitação para julgar se block size 8 ou 9 é mais adequado; se a taxa de aceitação for baixa, vale reverificar se a distribuição das tarefas se desviou da mistura de dados de treino. Essas são práticas recomendadas, não promessas do fabricante.
Limites e pontos a confirmar
Primeiro, até o momento desta verificação, o catálogo atual de modelos do KimiSeek não tem entradas exatas para LFM2.5-VL-3B ou LFM2.5-VL-DSpark, portanto essa versão não está atualmente listada no KimiSeek; o download de pesos, os formatos e os modos de integração mencionados na fonte são alegações do fabricante e não representam disponibilidade neste site. Segundo, no texto original do fabricante, o intervalo de aceleração de decodificação no H100 em um ponto está escrito como "20,4 vezes a 2,66 vezes", o que é claramente uma anomalia tipográfica ou de transcrição e não deve ser citado como limite superior confiável. Terceiro, o fabricante afirma que o modelo de rascunho é experimental, que sua estrutura de 4 camadas e block size 9 vêm de ablações com 3, 4 e 5 camadas, e que a mistura de dados de treino é ponderada pela carga esperada, portanto a taxa de aceitação e a aceleração variam conforme a distribuição real das tarefas. Quarto, os números de aceleração vêm de testes próprios do fabricante em M5 Max, M3 Ultra e H100, avaliados pelas seis tarefas do benchmark MMSpec, e o desempenho em outros hardwares, formatos de quantização, comprimentos de contexto e configurações de batching não foi verificado de forma independente. Quinto, a fonte descreve o modelo como de pesos abertos, livre para download, ajuste fino e implantação, mas o blog não fornece termos de licença específicos; a disponibilidade dos pesos não equivale a licença de código aberto, e os direitos de uso comercial e redistribuição devem se basear na licença real da página do modelo no Hugging Face.
Ilustrações da notícia original
