A Liquid AI lançou modelos de rascunho DSpark para a família LFM2.5 (1.2B-Instruct, 2.6B e 8B-A1B), adicionando decodificação especulativa—uma técnica em que um pequeno modelo de rascunho propõe candidatos de token que um modelo de destino maior verifica em uma única passagem—sem alterar a qualidade de saída. Os aumentos de velocidade são substanciais: até 3,18x de melhoria de transferência em uma GPU H100 e até 2,87x em um MacBook Pro M4 Max usando inferência em dispositivo. Os modelos de rascunho têm aproximadamente 300M parâmetros cada, adicionando sobrecarga mínima de memória.
O impacto mais significativo aparece em cargas de trabalho agentes onde o modelo raciocina antes de cada chamada de ferramenta. Entre vários cenários de chamadas de função no benchmark BFCL, DSpark reduz a latência em 57% em média para LFM2.5-2.6B. Isso importa porque agentes incorrem no custo de decodificação várias vezes por turno—uma para planejamento, uma após cada chamada de ferramenta, e novamente para replanejamento. A velocidade varia por tarefa: raciocínio MATH em H100 atinge 3,18x, enquanto GSM8K (que requer menos saltos) produz 1,29x, acompanhando a taxa de aceitação do modelo.
A arquitetura DSpark unifica três componentes: uma espinha dorsal paralela de estilo DFlash que gera todos os tokens de rascunho em uma única passagem direta (rápido mas inicialmente incoerente), uma leve cabeça de cadeia de Markov sequencial que adiciona dependência entre tokens para aumentar aceitação em posições posteriores, e um verificador de acordo de confiança que remove sufixos de baixa aceitação quando o custo de verificação excede as economias. A técnica é exata: verificação de destino garante que a saída seja idêntica ao decodificação gulosa da linha de base, portanto nenhuma precisão é sacrificada.
Arquitetos implantando agentes locais e fluxos de trabalho de raciocínio em dispositivo devem rastrear este lançamento: LFM2.5-DSpark é fornecido com suporte no primeiro dia em llama.cpp e SGLang, tornando-o imediatamente usável. A equipe da Liquid AI treinou rascunhos em dados diversos (SFT, chat, código, chamada de função) e selecionou épocas pela taxa de aceitação em vez de perda—uma mudança de sinal que sugere o verdadeiro gargalo no desempenho de decodificação: não computação, mas largura de banda de memória e coeão de cache.