LFM2.5-VL-3B-DSpark: O Drafter de 279,5M da Liquid AI foi lançado seis dias antes de alguém anunciá-lo

Existe uma versão desta história em que o LFM2.5-VL-3B-DSpark é um novo modelo. Não é. Ele é um modelo draft de decodificação especulativa com 279,5 milhões de parâmetros que existe exatamente para um único propósito — fazer o modelo de visão-linguagem da própria Liquid AI, o LFM2.5-VL-3B, decodificar mais rápido — e não consegue gerar uma resposta utilizável sozinho. O motivo pelo qual ainda vale a pena ler sobre ele é a linha do tempo: os pesos chegaram ao Hugging Face em 18 de setembro de 2026, sem nenhum anúncio associado, ficaram lá por seis dias e só receberam um post no blog do fornecedor em 24 de setembro. O Radar encontrou o repositório nesse intervalo.

Essa lacuna também é a fronteira do que é possível saber neste momento. Tudo no repositório — o detalhamento dos parâmetros, o tamanho do bloco, as integrações com frameworks, a licença — é um arquivo em disco que você ou eu podemos abrir. Todo número de ganho de velocidade é medido pelo fornecedor, com a própria estrutura de benchmark da Liquid, e ninguém fora da empresa publicou uma reprodução. Este artigo mantém essas duas pilhas separadas de propósito.

O que o repositório realmente contém

Abra a ficha do modelo e a forma da coisa é inequívoca. LFM2.5-VL-3B-DSpark é um modelo de rascunho cujo alvo está fixado em seus metadados: base_model: LiquidAI/LFM2.5-VL-3B. Você não o aponta para um modelo diferente nem o serve sozinho.

• Parâmetros totais do draft — 279,5M, BF16, dos quais 193,0M correspondem à pilha do decodificador de 4 camadas, 65,5M a uma cabeça de Markov, 21,0M a uma projeção de estado oculto, e 6,4k a normalizações mais uma cabeça de confiança

• Backbone — 4 camadas de atenção completa, tamanho oculto 2.048, tamanho intermediário 6.144 com SiLU/SwiGLU, atenção de consulta agrupada com 32 cabeças de atenção e 8 cabeças de chave-valor, dimensão da cabeça 64

• Cabeças extras — uma cabeça de Markov com rank 256 e uma cabeça de confiança, que é o que separa a geração de rascunhos do DSpark de um modelo de rascunho paralelo comum

• Tamanho do bloco — 9 durante o treinamento; 8 ou 9 na inferência, dependendo do hardware, e 8 especificamente em Apple silicon

• Vocabulário — 128.000, vinculado ao destino em vez de carregado pelo rascunho

• Peso na pilha implantada — Liquid afirma que o drafter aumenta a contagem de parâmetros implantados em 8,9%

O 8,9% é o número a reter. O argumento para esta classe de modelo nunca é "inferência mais rápida é de graça"; é "inferência mais rápida custa cerca de um décimo do tamanho de um modelo em memória". Com 279,5 milhões de parâmetros extras somados a um modelo alvo de 3,1 bilhões, isso é um custo menor do que o tamanho do drafter sozinho sugeriria, porque o embedding e a LM head estão atrelados ao modelo alvo e não são duplicados.

O DSpark é uma técnica da DeepSeek antes de ser um modelo da Liquid

A nomenclatura convida à confusão, por isso vale a pena ser preciso. DSpark não é uma invenção da Liquid AI nem uma família de modelos. É um framework de decodificação especulativa de uma linha de pesquisa separada, descrito num artigo de julho de 2026 como decodificação especulativa com agendamento por confiança e geração semiautoregressiva. As suas três ideias: uma espinha dorsal paralela que rascunha um bloco inteiro numa única passagem direta, um módulo sequencial leve que restaura alguma dependência entre tokens de rascunho vizinhos para que a aceitação não colapse no fim do bloco, e um verificador que encurta a janela de verificação por pedido quando a própria confiança do rascunho sugere que a cauda será rejeitada.

O que a Liquid fez foi aplicar essa receita a modelos de visão-linguagem e lançar um checkpoint. A ficha do modelo é sincera ao admitir que essa transferência é menos dramática do que parece: do ponto de vista do modelo de rascunho, a modalidade é irrelevante, porque, quando os tokens chegam às camadas ocultas, um patch de imagem e um token de texto são apenas tensores. É por isso que uma técnica desenvolvida em modelos de texto é portada para um VLM sem precisar ser reinventada — e também é por isso que o modelo de rascunho não pode ser vendido como uma nova capacidade.

Liquid já havia lançado os drafters de texto DSpark — os modelos complementares 2.6B, 8B-A1B e 1.2B-Instruct foram disponibilizados em agosto de 2026, com as exportações GGUF vindo na sequência em 19 de agosto. O drafter de visão é a mesma ideia estendida ao ramo multimodal, e a quarta ou quinta entrada de uma linha, não uma estreia.

Os números de speedup, e quem os mediu

Todos os números abaixo são da própria Liquid, coletados na infraestrutura de benchmarking da Liquid, e nenhum deles tem reprodução independente. Trate-os como um benchmark de fornecedor, não como um resultado esperado. O cartão separa o ganho de velocidade de decodificação do ganho de velocidade ponta a ponta, o que importa mais do que a manchete.

• Melhor aceleração de decodificação — 3,13× no COCO, medido com MLX-VLM em um Apple M5 Max com tamanho de bloco 8, FP16, tamanho de lote 1, temperatura 0

• Melhor aceleração de decodificação em GPU — 2,66× no COCO, SGLang em uma única H100 80GB, BF16, tamanho de bloco 9

• Melhor aceleração de decodificação do llama.cpp — 2,14× no COCO, Apple M3 Ultra, tamanho do bloco 8

• Faixa de decodificação do H100 em seis tarefas de visão — 2,04× a 2,66×, com ponta a ponta em 1,64× a 2,27×

• Intervalo de decodificação do M5 Max — 2,30× a 3,13×, ponta a ponta 1,56× a 2,62×

• Faixa de decodificação do M3 Ultra — 1,57× a 2,14×, ponta a ponta 1,30× a 1,77×

• Aceitação de rascunho — cerca de 3,2 a 4,5 tokens aceitos por passagem de verificação do alvo, nas três stacks

O padrão nessas faixas é a parte honesta. Os ganhos de ponta a ponta são consistentemente a metade menor de cada par, porque o modelo de rascunho acelera a decodificação e nada mais. Observe também que o mesmo modelo de rascunho, no mesmo tamanho de bloco, chega a 3,13× em uma pilha e a 1,57× em outra — a taxa de aceitação é uma propriedade do modelo de rascunho e da carga de trabalho, mas o ganho em tempo de relógio é uma propriedade do hardware e da sobrecarga do runtime. Uma afirmação de "2,66× mais rápido" sem uma pilha associada não é uma afirmação sobre a qual se possa agir.

Dois pontos de correção da ficha merecem ser ditos sem rodeios, porque são eles que tornam um modelo de rascunho aceitável em produção. Na decodificação gulosa, a decodificação especulativa é exata: o alvo verifica cada token proposto, então o texto é o que o alvo teria produzido sozinho. Em configurações de amostragem equivalentes com temperatura diferente de zero, ela preserva a distribuição de saída do alvo. A formulação da Liquid — você obtém a aceleração, não um modelo diferente — é precisa até onde vai, e a ficha é honesta ao dizer que aumentar a temperatura reduz a aceitação e, portanto, corrói o benefício de vazão.

O que o próprio post da Liquid admite

O post do blog de 24 de setembro é mais útil do que o cartão de modelo por um motivo: ele nomeia o limite. A inferência de visão-linguagem paga um custo de prefill que a inferência de texto não paga — a imagem precisa passar por um codificador de visão, e o backbone de linguagem então precisa processar as centenas de tokens visuais que esse codificador produz. Em um dispositivo, esse prefill domina a latência ponta a ponta. A decodificação especulativa acelera apenas a decodificação. A codificação de visão e o prefill não são afetados. A Liquid invoca a lei de Amdahl contra seu próprio produto e aponta que, onde o prefill é uma grande parcela do tempo de relógio, um grande ganho de velocidade na decodificação rende apenas uma melhoria modesta de ponta a ponta.

Essa é uma restrição real para a decisão de compra, e explica por que o tempo até o primeiro token não está na lista de coisas que este modelo de rascunho melhora. Também implica que as cargas de trabalho que mais se beneficiam são aquelas que geram saídas longas a partir de uma imagem modesta — uma legenda, uma transcrição longa de OCR, uma conversa de vários turnos com uma única imagem mantida em contexto — em vez daquelas que respondem a uma pergunta curta sobre uma imagem grande.

O post adiciona mais dois limites de escopo. Todos os números usam processamento de 16 bits tanto para o codificador de visão quanto para o backbone de linguagem, e a aceleração de modelos quantizados está fora do escopo desta versão. Dado que o principal atrativo de um VLM de borda de 3B é rodar em alguns gigabytes, "os ganhos de velocidade são medidos em FP16" é uma ressalva significativa para quem planejava combiná-lo com uma exportação de 4 bits. A Liquid também observa que o drafter foi treinado inteiramente em hardware AMD.

Executando.

O suporte desde o primeiro dia é real e cobre três runtimes, o que é mais do que a maioria dos drafters recebe. O SGLang em NVIDIA requer v0.5.19 ou mais recente e passa o drafter por --speculative-algorithm DSPARK com o caminho de draft e um tamanho de bloco de 9. O MLX-VLM em Apple silicon requer v0.7.2 ou mais recente e detecta o drafter quando ele é passado com --draft-model; há um ponto de atenção — a decodificação do DSpark no MLX-VLM atualmente usa amostragem greedy, então a temperatura precisa ser definida como 0. Para o llama.cpp há um repositório GGUF separado, com um único export F16 de aproximadamente 567 MB, e o card deixa explícito que você deve combinar o drafter quantizado com o alvo quantizado, e não com o checkpoint safetensors original.

O ponto em que uma camada de roteamento se justifica aqui não é neste modelo — o OrcaRouter não roteia o LFM2.5-VL-3B-DSpark nem o LFM2.5-VL-3B, e este é um emparelhamento de drafter auto-hospedado que você mesmo baixa e serve. É no restante da stack ao redor dele. O mesmo aplicativo que executa um pequeno modelo de visão de pesos abertos no dispositivo normalmente tem um caminho de fallback para as consultas que o modelo pequeno não consegue lidar, e apontar esse caminho para um único endpoint que cobre mais de 200 modelos — cobrado pelo preço de tabela de cada provedor, sem markup adicionado, com failover automático quando um provedor apresenta degradação — é uma integração menor do que montar um segundo contrato com fornecedor. O drafter melhora uma parte dessa arquitetura; o roteador é o que impede que a outra parte se torne um segundo projeto.

O que ainda não se sabe

O repositório tem 37 downloads e 6 curtidas no momento em que escrevo. Não há entrada para este drafter em nenhum agregador público de benchmarks, nenhuma reprodução por terceiros de qualquer uma das faixas de aceleração e nenhuma medição independente da taxa de aceitação em hardware que a Liquid não testou. Também não há benchmarks de qualidade no card por motivos óbvios — o drafter preserva a saída por construção, então os números de qualidade pertencem ao LFM2.5-VL-3B, e o card aponta para os benchmarks desse modelo em vez de inventar os seus próprios.

Um detalhe nos metadados é um pequeno indício de quão novo isto é: o modelo carrega uma tag de biblioteca SGLang e uma flag de algoritmo SGLang que existe especificamente para o invocar. O suporte da framework teve de chegar antes do anúncio, o que é consistente com o intervalo de seis dias entre o repositório e o post do blog.

Então: uma peça de engenharia genuína, útil e de escopo estreito, anunciada uma semana depois de ter sido lançada, cuja proposta de valor inteira é um número medido pelo fornecedor em hardware que você pode não ter. Se você está servindo o LFM2.5-VL-3B em um H100 ou em um Mac da série M e sua carga de trabalho é intensiva em decodificação, o custo de memória é de 8,9% e a desvantagem é quase nula, porque a saída é comprovadamente a do alvo. Se sua latência é dominada pelo prefill, ou você contava com a exportação em 4 bits, o próprio post da Liquid diz que isso não vai ajudar. A reprodução, quando vier, é o que vale esperar.

O OrcaRouter coloca mais de 200 modelos atrás de uma única chave pelo preço de tabela do provedor, com 0% de margem, e expressa o caminho de fallback como uma camada de roteamento em vez de código de aplicação. O drafter é auto-hospedado de qualquer forma — o roteador é o que impede que a etapa para a qual seu modelo pequeno repassa a tarefa se torne um segundo projeto.