LFM2.5-VL-DSpark: como tratar o rascunhador de visão da Liquid AI como um sidecar verificado, não como um segundo modelo

O que a Liquid AI realmente lançou: um sidecar de rascunho de visão para o LFM2.5-VL-3B

A Liquid AI lançou seu rascunhador experimental de visão LFM2.5-VL-DSpark em 24 de setembro de 2026. É fácil interpretar isso de forma errada. O pequeno artefato DSpark parece algo que uma equipe poderia implantar ao lado de, ou talvez no lugar de, um modelo visão-linguagem maior. Essa leitura está errada. A pergunta útil não é: quão rápido é o modelo pequeno? A pergunta útil é se o alvo, o sidecar, o projetor, o runtime, o ponto de captura, a lógica de verificação e o caminho de reversão estão combinados com precisão suficiente para que o alvo tivesse produzido a mesma resposta.

A Liquid AI descreve o LFM2.5-VL-DSpark como um rascunhador experimental para LiquidAI/LFM2.5-VL-3B. O rascunhador tem cerca de 279,5M parâmetros BF16, quatro camadas de atenção e usa cabeças de Markov e de confiança. Ele lê estados ocultos do alvo em camadas de captura fixas depois que as entradas de imagem e texto entram na representação compartilhada. Em termos simples, ele não é um modelo visão-linguagem autônomo. Não é um substituto comprimido para o LFM2.5-VL-3B. Não é um atalho em torno do codificador de visão. É um sidecar de decodificação especulativa, útil apenas quando o alvo inalterado verifica os tokens propostos.

Essa distinção parece minuciosa até quebrar uma implantação. Uma equipe pode parear o sidecar errado, copiar um exemplo de modelo de texto, servir o rascunhador sozinho ou medir latência antes de verificar se as saídas greedy ainda correspondem ao caminho do alvo. Nenhuma dessas falhas seria exótica. Elas são exatamente o tipo de erro que acontece quando um lançamento é tratado como um botão de velocidade em vez de um contrato.

Se você ainda está avaliando o modelo base, o teste de aceitação local de visão do LFM2.5-VL-3B anterior da Optijara é o contexto principal. Este artigo é mais estreito. Ele trata do DSpark como um sidecar verificado. Para equipes que já trabalham com artefatos quantizados locais, o guia de caminho empacotado Transformers GGUF llama.cpp da Optijara também explica por que um nome de arquivo plausível não basta.

O contrato de execução do DSpark: rascunhar, verificar, reverter e então aceitar tokens

Em uma configuração correta de DSpark de visão, a imagem e o prompt ainda entram no caminho visão-linguagem do alvo. O alvo continua responsável pelo processador, tokenizer, modelo de prompt, projetor de visão, backbone de linguagem e verificação final. O DSpark lê informações de estado oculto em pontos de captura compatíveis e propõe tokens candidatos. O alvo verifica essas propostas. Tokens aceitos avançam. Propostas rejeitadas precisam de reversão de cache para que o sistema retorne a um estado consistente com o alvo.

O ponto de captura é o limite que importa. Um rascunhador treinado para ler um estado interno não pode ser colocado em um caminho de modelo arbitrário e ainda assim preservar o comportamento. O checkpoint alvo, o projetor, a camada de captura, as suposições de embedding compartilhado ou de cabeça LM e a implementação do runtime moldam se os tokens de rascunho são significativos.

A verificação é a proteção. Para decodificação greedy sob condições correspondentes, a decodificação especulativa é projetada para preservar a saída do alvo enquanto reduz etapas caras do alvo. Essa ideia algorítmica é útil. Ela também não é uma garantia em todos os backends. Diferenças de kernel, precisão, pré-processamento de imagem, modelos de prompt, revisões de runtime e implementações de sampling ainda podem criar divergências. A discussão do PR de visão do SGLang relata diferenças de tokens de saída em um contexto de teste devido a diferenças numéricas de formato de verificação. Trate isso como um convite para testar com cuidado, não como motivo para descartar o lançamento.

Os ganhos também têm uma forma. O DSpark não remove o pré-processamento de imagem nem o prefill de visão. Ele pode ajudar quando tokens de decode suficientes são aceitos para compensar o custo de rascunho, batching de verificação, propostas rejeitadas e tráfego de cache. Isso se relaciona ao timing por etapa, mas não é o mesmo problema que mapear timing de encode e decode com OpenVINO GenAI.

Framework original: o Mapa de Compatibilidade Rascunho-Alvo

O framework recomendado pela Optijara para este lançamento é o Mapa de Compatibilidade Rascunho-Alvo. Preencha-o antes de medir o DSpark. Se uma linha for desconhecida, o benchmark ainda não é confiável.

Para GGUF, prefira o par VL oficial atual: LiquidAI/LFM2.5-VL-3B-GGUF:F16 com LiquidAI/LFM2.5-VL-3B-DSpark-GGUF:F16, usando as flags de rascunho DSpark descritas no model card. Evite comandos genéricos do Hub que sugerem que o rascunhador pode ser servido sozinho. Evite também copiar um exemplo de rascunhador de texto para um lançamento de visão. Um sidecar DSpark de texto e um alvo VL não são intercambiáveis só porque os nomes parecem próximos.

O suporte de runtime merece o mesmo ceticismo. O model card do DSpark menciona suporte de versão do SGLang e suporte do MLX-VLM, mas as equipes devem verificar se o build instalado contém a capacidade de visão relevante, não apenas a string de versão. O PR de visão do SGLang expõe acesso aninhado à cabeça LM do modelo de linguagem e suporte a camada de captura. O PR do MLX-VLM conecta capturas de estado oculto no estilo DSpark, verificação especulativa e reversão de cache de estado convolucional. O PR do llama.cpp aborda a arquitetura do vocabulário alvo e a reordenação dupla de RoPE na conversão. Essas são capacidades a verificar, não rótulos a citar em um slide.

O que testar antes de confiar na tabela de aceleração

A Optijara inspecionou os model cards públicos e o código de integração para este artigo. Não executamos esses modelos nem reproduzimos os benchmarks; o plano de teste abaixo é trabalho proposto.

Comece pela paridade. Depois meça a latência. Um smoke test útil fixa o modelo, tokenizer, processador, projetor, template de chat, commit de runtime ou versão de pacote, precisão, pré-processamento de imagem, configurações de geração e configuração de bloco. Execute primeiro a saída greedy apenas do alvo. Execute em seguida a saída greedy do DSpark. Compare o texto exato. Se houver divergência, registre o prompt, hash da imagem, configurações, revisão do runtime e diff de saída antes de fazer qualquer afirmação de velocidade.

Os números de desempenho relatados pela Liquid AI são úteis, mas são resultados do fornecedor sob condições específicas. O model card enquadra resultados em torno de batch 1, temperatura 0, configurações de codificador e backbone de 16 bits, H100 BF16 com bloco 9, Apple FP16 com bloco 8; as medições da Apple usam até 2.048 tokens de saída. Ele relata exemplos como razões de decode e ponta a ponta em COCO no H100, além de resultados da Apple incluindo linhas M5 Max e M3 Ultra. Trate isso como evidência direcional para o lançamento, não como promessa para seu workload. Se a evidência de benchmark for comparada entre sistemas, use disciplina de protocolo como no guia de Evaluation Cards e protocolos de benchmark da Optijara: pontuação, conjunto de prompts, runtime, precisão e regras de medição precisam viajar juntos.

A média de tokens aceitos por passagem de verificação não é uma porcentagem de aceitação por si só. Comprimento aceito, trabalho rejeitado, custo do rascunhador, comportamento do batching de verificação, tráfego de cache e comprimento de saída determinam a velocidade realizada. Uma resposta curta pode gastar a maior parte do tempo em pré-processamento de visão e prefill. Uma resposta mais longa e intensiva em decode dá aos tokens de rascunho aceitos mais espaço para importar.

Aqui está a regra prática: se sua avaliação do DSpark começa pela tabela de aceleração, ela está apontada na direção errada. Comece pela paridade de saída e pelo pareamento de artefatos. A velocidade vem depois, e apenas se as verificações de compatibilidade passarem.

Erros comuns ao adotar o LFM2.5-VL-DSpark

O primeiro erro é tratar o sidecar como um segundo modelo de visão implantável. Ele é um rascunhador para um caminho alvo correspondente. Se seu plano de implantação diz para servir o arquivo DSpark como o modelo, o plano está errado.

O segundo erro é parear um sidecar DSpark de texto com o alvo VL. O material de lançamento da Liquid AI inclui exemplos que podem ser fáceis de copiar fora de contexto. Para o lançamento de visão, use o alvo de visão atual e os artefatos DSpark de visão atuais, depois verifique o projetor e o caminho de runtime.

O terceiro erro é medir tempo antes de provar paridade. Um caminho rápido que altera a saída greedy não é um caminho de aceleração válido para um decodificador especulativo que preserva o alvo. Ele ainda pode ser uma pesquisa interessante, mas não é evidência de que o DSpark acelera seu modelo alvo com segurança.

O quarto erro é ler uma razão de velocidade de decode como throughput, qualidade, economia de memória ou latência de produto. Velocidade de decode não é throughput de concorrência. Não é melhoria de qualidade. Não reduz automaticamente o pico de memória. Não remove prefill. Meça cada item separadamente.

O quinto erro é ignorar licença e proveniência de artefatos. A LFM Open License v1.0 inclui termos comerciais condicionados por receita e um limite descrito no texto da licença. Isso não é open source irrestrito. Revise a licença atual e obtenha aconselhamento jurídico para limites de implantação comercial.

Ressalvas e limites: onde o DSpark pode não ajudar

O DSpark pode ajudar menos em saídas curtas e prompts pesados em visão, nos quais pré-processamento e prefill dominam. Se um caso de uso pede uma legenda de uma linha, o sidecar pode não ter comprimento de decode suficiente para compensar o overhead. Se um caso de uso produz explicações mais longas de gráficos, raciocínio sobre documentos ou respostas fundamentadas em imagem com várias etapas, a avaliação é mais promissora, mas ainda depende do workload.

Drift de backend é outro limite. H100, Apple MLX, SGLang, llama.cpp, BF16, FP16, FlashAttention, templates de imagem e tratamento de tokenizer podem afetar paridade e desempenho. Um runtime que funciona para um caminho não prova que toda conversão ou backend é seguro.

Sampling exige cuidado adicional. Em princípio, a decodificação especulativa pode preservar a distribuição do alvo quando o sampling correspondente é implementado corretamente. Isso é diferente de produzir texto idêntico para cada seed em todos os backends. Para o DSpark hoje, faça da paridade greedy com temperatura 0 o primeiro gate de confiança, depois avalie sampling apenas se seu runtime documenta e oferece suporte ao algoritmo correspondente.

Matriz de decisão: quando uma equipe deve avaliar o DSpark agora

A decisão não é: o DSpark é bom? É: o contrato de sidecar deste lançamento se encaixa no seu alvo, backend, workload e disciplina operacional? Esse enquadramento evita que uma técnica promissora de aceleração se torne um atalho de implantação não verificado.

Checklist de implementação

Use este checklist para o primeiro sprint de avaliação. Escolha prompts de imagem representativos. Fixe o alvo, projetor, sidecar DSpark, tokenizer, processador, template, revisão de runtime, precisão, configuração de bloco e pré-processamento de imagem. Execute uma baseline greedy apenas do alvo. Execute a saída greedy do DSpark e compare o texto exato. Meça TTFT, latência ponta a ponta p50 e p95, pico de memória, comprimento de tokens aceitos, propostas rejeitadas, política de warmup, configurações de cache e comportamento de fallback apenas do alvo. Revise a licença. Decida o escopo de rollout apenas depois que a evidência de paridade e medição estiver no mesmo relatório.

{
  "target": "LiquidAI/LFM2.5-VL-3B",
  "sidecar": "LiquidAI/LFM2.5-VL-3B-DSpark",
  "runtime": "pinned revision with VL DSpark taps, verification, and rollback",
  "parity_status": "greedy target-only versus DSpark comparison required",
  "latency_status": "measure TTFT and p50/p95 end-to-end after parity",
  "memory_status": "measure peak runtime memory, not parameter count only",
  "license_review": "required before commercial rollout",
  "fallback_ready": "target-only path documented"
}

Se sua equipe precisa de ajuda para transformar isso em uma infraestrutura reprodutível de avaliação de inferência, a Optijara pode ajudar a definir o mapa de compatibilidade, o plano de fixação de artefatos e o registro de decisão de implantação. O trabalho de validação ainda precisa acontecer no seu workload, com suas imagens, prompts, runtime e restrições.