A Liquid AI entregou checkpoints de rascunho DSpark para três modelos LFM2.5 em 20 de agosto: o 1.2B-Instruct, 2.6B e 8B-A1B. A técnica de decodificação especulativa atinge 3.18x de throughput em H100 e 2.87x em M4 Max, sem degradação da qualidade de saída.
A decodificação especulativa executa um pequeno modelo de rascunho que propõe tokens candidatos, então permite que o modelo alvo verifique todo o lote em uma única passagem direta. DSpark adiciona três componentes: um backbone paralelo que gera estados ocultos para todos os tokens de rascunho em uma única passagem, um cabeçalho de Markov que modela dependências entre tokens para aumentar as taxas de aceitação, e um verificador de confiança programada que remove sufixos de baixa confiança antes que a sobrecarga de verificação exceda o ganho de aceleração.
Cada modelo de rascunho tem aproximadamente 300M parâmetros: 295.7M para o 1.2B, 327.7M para o 2.6B e 8B-A1B. O treinamento foi executado 15 épocas em dados SFT, chat, código e de chamada de função. O checkpoint de lançamento foi selecionado pela maior taxa de aceitação, não a menor perda.
Em H100, o 8B-A1B mostra os ganhos mais fortes: MATH500 atinge 3.18x (428 → 1362 tok/s, aceitação de 8.27/10), MT-Bench atinge 3.02x (426 → 1288 tok/s), e a média de cinco benchmarks é de 2.54x (418 → 1074 tok/s). O 2.6B tem média de 2.67x em H100 (323 → 864 tok/s). O 1.2B tem média de 2.10x (656 → 1384 tok/s absoluto). A latência de chamada de função cai 57% no 2.6B em cenários multi-ferramentas. A saída é idêntica à decodificação gulosa desassistida por construção: tokens de rascunho rejeitados são substituídos pelo próprio token do modelo alvo.
Os resultados em dispositivo são mistos. O 2.6B em M4 Max atinge 2.27x (61 → 139 tok/s), igualando ou superando a maioria das APIs de nuvem proprietárias na borda. O 1.2B em M4 Max tem média de 2.54x (138 → 350 tok/s média em cinco benchmarks; MATH500 especificamente atinge 140 → 366 tok/s, HumanEval 136 → 389 tok/s). O 8B-A1B, entretanto, tem média de apenas 1.18x em M4 Max (90 → 106 tok/s) versus 2.54x em H100. A lacuna decorre da implementação de MoE do backend Metal do llama.cpp: verificar um bloco de token ativa mais especialistas por etapa, gerando mais tráfego de peso do que a linha de base e erodindo o ganho de decodificação especulativa.
A aceitação de GSM8K para o 8B-A1B cai para 4.02/10—a mais baixa em todas as combinações—produzindo aceleração de 1.29x (385 → 496 tok/s) em vez de 3.18x. A taxa de aceitação é a alavanca primária: a sobrecarga do modelo de rascunho cancela a economia quando os tokens são rejeitados. As equipes avaliando DSpark devem perfil as taxas de aceitação em seus dados específicos antes de se comprometerem.
DSpark entrega ganhos H100 substanciais em todos os três tamanhos sem regressão de precisão, mas MoE em Apple Silicon permanece problemático. Defira 8B-A1B em dispositivo até que o caminho de MoE de Metal do llama.cpp amadureça.