Em 20 de agosto, a Liquid AI publicou no Hugging Face um conjunto de modelos rascunho LFM2.5-DSpark, equipando três modelos próprios com decodificação especulativa: LFM2.5-1.2B-Instruct, 2.6B e 8B-A1B. Segundo a empresa, o ganho de velocidade chega a 3,18x, com resultados idênticos aos do modelo original.
A ideia por trás da decodificação especulativa não é complicada: um modelo pequeno prevê antecipadamente as próximas palavras, e o modelo grande deixa de calcular palavra por palavra, verificando em lote toda essa sequência de candidatas em uma única passagem direta. Se o palpite acerta, é usado direto; se erra, é recalculado. Todo o tempo economizado vem de evitar mover os pesos repetidamente.
655 MB trocados por duas ou três vezes mais velocidade
Os modelos rascunho que a Liquid AI acopla desta vez são todos bem pequenos. A versão para o 1.2B tem 295,7 milhões de parâmetros; 2.6B e 8B-A1B compartilham uma versão de 327,7 milhões de parâmetros. A estrutura é de 5 camadas de atenção completa, dimensão oculta de 2048, camada intermediária de 6144, 32 cabeças de consulta compartilhando 8 grupos KV, propondo 9 palavras candidatas a cada rodada. Em precisão BF16, o uso de VRAM é de 655 MB.
Fazendo as contas em um Mac com 16 GB de memória: 655 MB representam cerca de 4% da memória total, em troca de uma resposta de diálogo local mais de duas vezes mais rápida. Essa relação custo-benefício é bastante vantajosa em cenários on-device. O que mais falta em dispositivos locais nunca foi pico de poder computacional, e sim aqueles segundos de espera em branco.
Os números dependem do hardware
O benchmark oficial foi dividido em dois ambientes, e os resultados variam bastante.
| Modelo alvo | Média H100 | Pico H100 | Média M4 Max | Pico M4 Max |
|---|---|---|---|---|
| 1.2B-Instruct | 2,10x | 2,56x | 2,54x | 2,87x |
| 2.6B | 2,67x | 3,06x | 2,27x | 2,63x |
| 8B-A1B | 2,54x | 3,18x | 1,18x | 1,44x |
O 3,18x do título vem do melhor resultado do 8B-A1B no H100. O mesmo modelo, rodando em um notebook M4 Max, cai para apenas 1,18x. A própria Liquid AI explicou o motivo: o backend Metal do llama.cpp ainda não implementa bem as arquiteturas de mistura de especialistas (MoE), e o MoE on-device é o ponto fraco dessa solução.
Os dados de taxa de aceitação também foram divulgados. No MATH500, o 8B-A1B tem em média 8,27 de cada 10 palavras candidatas aceitas; no GSM8K, apenas 4,02. Textos de demonstração matemática têm estrutura regular e alta previsibilidade, então o modelo rascunho acerta mais; já em problemas de matemática do ensino fundamental, com redação mais livre, a taxa de acerto cai pela metade.
Outro dado mais próximo do uso prático: em cenários de chamadas de função com múltiplas ferramentas, a latência da versão 2.6B caiu em média 57%. Cada passo de um agente precisa esperar o modelo gerar uma chamada estruturada, e esse tipo de ida e volta é o que mais sofre com o acúmulo de latência.
De onde veio o método
O nome DSpark não foi criado pela Liquid AI. Ele vem de um trabalho publicado em código aberto no final de junho deste ano pela DeepSeek em conjunto com a Universidade de Pequim, usando uma espinha dorsal de rascunho paralela combinada com uma cabeça de Markov leve, além de um mecanismo que ajusta o comprimento de verificação conforme a carga da GPU em tempo real. Os dados divulgados na época mostravam ganho de 60% a 85% na velocidade de geração para um único usuário, e sob metas rígidas de latência, throughput por placa até 6,6x maior.
Dois meses depois, esse método apareceu no lançamento de uma empresa americana de modelos on-device. No SGLang, a ativação se dá adicionando o parâmetro --speculative-algorithm DSPARK; o llama.cpp já suportou, desde o primeiro dia, o formato FP16 GGUF no backend Metal. O fato de frameworks a montante transformarem o nome do algoritmo em valor de um parâmetro de linha de comando já mostra, por si só, que o método passou a ser tratado como padrão de fato.
Nos últimos dois anos, laboratórios chineses abriram o código de bastante trabalho de engenharia no lado de inferência, com discussões concentradas majoritariamente em economia de placas. Esse transbordamento do DSpark trouxe outro tipo de retorno: o método entrou no caminho padrão de terceiros, e as implantações futuras baseadas nesse framework passam a rodar essa linha de raciocínio.
A licença traça uma linha
Os pesos são disponibilizados nos formatos Safetensors e GGUF, sob a LFM Open License 1.0: entidades com receita anual abaixo de US$ 10 milhões podem usar comercialmente de graça; acima disso, é preciso negociar um acordo comercial à parte. A implantação só é possível de forma auto-hospedada; a Liquid AI não oferece API hospedada.
Essa linha fica exatamente entre startups e empresas de médio e grande porte, com intenção bem clara: usar a cota gratuita para conquistar a escolha padrão dos desenvolvedores, reservando a receita para quem pode pagar.
Fontes: blog oficial do Hugging Face, ficha do modelo da Liquid AI, CocoLoop, MarkTechPost; dados de ganho de velocidade, número de parâmetros e taxa de aceitação seguem a tabela de benchmark oficial, e os termos de licença seguem a página do modelo.