LFM2.5-24B-A2B-DSpark vs LFM2.5-24B-A2B: Você deveria realmente acoplar o drafter?

Aqui está a decisão em uma linha: LFM2.5-24B-A2B-DSpark é um arquivo de 327,7M de parâmetros que você coloca ao lado de LFM2.5-24B-A2B para que o modelo de 24B produza o mesmo tipo de saída mais rápido. Ele não é uma alternativa ao modelo e não é algo que você escolhe em vez dele. A única questão real que os dois nomes levantam é de engenharia — você anexa o drafter à sua implantação ou o deixa de fora — e a resposta depende menos do aumento de velocidade divulgado pela Liquid AI do que de dois números que ninguém anuncia: em quantos tokens o rascunho é aceito no seu tráfego, e quanta concorrência você já está executando. As falhas de IA documentadas e os incidentes de agentes por trás de lançamentos como este estão reunidos em o OrcaRouter AI Incident Archive, onde cada entrada traz suas próprias fontes, gravidade, grau de confiança e sinalização de disputa.

A Liquid AI não publicou um post de lançamento para o drafter. O repositório tornou-se público em 2026-10-19 com pesos, um CSV de benchmark e flags de lançamento do SGLang, enquanto o model card do próprio modelo-alvo ainda rotula o drafter como "coming soon" e a página de documentação de decodificação especulativa da Liquid lista apenas os modelos-alvo 1.2B, 2.6B, 8B e VL-3B. Portanto, esta é uma comparação de um artefato já lançado com um modelo já lançado, escrita a partir do repositório e não de um comunicado à imprensa — o que significa que todos os números de desempenho abaixo são informados pelo fornecedor e nenhum deles foi reproduzido de forma independente.

O que o redator realmente altera, e o que não altera

O mecanismo vale trinta segundos porque determina todo o resto. A decodificação de um token é limitada pela memória: a GPU passa a maior parte do tempo transmitindo pesos para a SRAM, não fazendo aritmética. A decodificação especulativa explora isso fazendo um modelo pequeno dar um palpite sobre os próximos vários tokens de uma vez e, em seguida, fazer o modelo real verificar todo o palpite em uma única passagem direta. Se o palpite foi bom, você produziu nove tokens por aproximadamente o custo de um. Se foi ruim, o modelo alvo mantém o próprio token e você pagou um pouco a mais.

O que muda: tokens por segundo e a forma da utilização da sua GPU. O que não muda: os pesos do modelo, a sua janela de contexto, o seu comportamento de chamada de ferramentas ou os seus preços onde é vendido. O LFM2.5-24B-A2B mantém 24,0B de parâmetros totais com 2,45B ativos por token, 40 camadas divididas entre convoluções curtas com gate e atenção de consulta agrupada, 64 especialistas por bloco com roteamento top-4, um contexto de 131.072 tokens e um vocabulário de 128.000 tokens. O drafter adiciona cinco camadas de atenção, uma cabeça de Markov de posto 256 e uma cabeça de confiança, e reutiliza os embeddings e a cabeça LM do alvo em vez de carregar os seus próprios.

Uma ressalva mudou entre as duas versões e merece uma linha. Em agosto, o texto sobre o DSpark da Liquid dizia que a sequência emitida é "idêntica ao greedy de linha de base por construção". Já a ficha do drafter de 24B diz que diferenças de ponto flutuante entre verificação em lote e decodificação simples "podem produzir texto diferente, inclusive sob amostragem greedy". Ambas as afirmações são defensáveis — a primeira é verdadeira em aritmética exata —, mas, se seu harness de avaliação compara saídas byte a byte, espere que ele perceba.

O lado dos custos do balanço

O rascunhador não é gratuito. Ele ocupa 655 MB em BF16 na GPU (ou 664 MB em F16 GGUF na CPU), fica no mesmo pool de memória do modelo alvo, e cada passo que propõe custa um forward pass de verificação sobre um bloco de tokens em vez de um único token. Em um alvo MoE, essa última parte é mais cara do que parece: verificar nove tokens ativa mais especialistas do que decodificar um, então os bytes movidos por token verificado aumentam, não diminuem. A Liquid citou exatamente isso como o motivo de seu rascunhador de 8B ter entregado apenas 1,18× em um M4 Max, apesar da forte aceitação.

Em contrapartida, as economias são grandes o suficiente para serem medidas em horas de GPU. Usando os próprios números B300 do fornecedor provenientes de benchmarks/b300-fp8.csv, e não fazendo nada além de dividir um bilhão de tokens de saída pela vazão observada:

• MATH-500, concorrência 1 — 324 tok/s sozinho (857 horas de GPU por bilhão de tokens) versus 853 tok/s com o drafter (326 horas de GPU). Uma redução de 2,63× no tempo de computação.

• MATH-500, concorrência 256 — 15.423 tok/s sozinho (18,0 GPU-horas) versus 27.579 tok/s com o drafter (10,1 GPU-horas). Uma redução de 1,79×.

• GSM8K, concorrência 256 — 4.491 tok/s isoladamente (61,9 horas de GPU) versus 9.660 tok/s com o drafter (28,8 horas de GPU). Uma redução de 2,15×.

• LiveCodeBench, concorrência 256 — 18.812 tok/s isolado (14,8 horas de GPU) versus 25.231 tok/s com o drafter (11,0 horas de GPU). Apenas uma redução de 1,34×, a célula mais fraca da tabela.

Essas são razões de throughput convertidas em tempo, não em dinheiro, porque o dinheiro depende de quanto você paga por GPU-hora e este artigo não vai inventar uma tarifa. Mas a ordenação se mantém em qualquer tarifa: acoplar o drafter vale de duas a três horas a cada dez para tráfego de raciocínio e geração de código em baixa concorrência, e vale aproximadamente um terço disso em alta concorrência. Se sua implantação de 24B for um agente de usuário único em uma estação de trabalho, o argumento é forte. Se for um endpoint de lote saturado, o argumento é real, mas muito mais tênue do que a manchete de 2,4× sugere.

Onde o projetista se paga, em termos de carga de trabalho

A variação entre os oito conjuntos de dados na tabela do fornecedor não é ruído; ela corresponde aos tipos de prompt, e esse mapeamento é a coisa mais útil no lançamento. A aceitação variou de 6,70 tokens por passo no MBPP até 4,02 no LiveCodeBench. Os conjuntos de dados que tiveram pontuação alta são aqueles em que a saída do modelo é restrita pelo prompt — funções curtas no estilo de testes unitários, aritmética com um caminho verificável, respostas de múltipla escolha. Os que tiveram pontuação baixa são aqueles em que o modelo precisa inventar uma solução longa e sem restrições: problemas de programação competitiva e matemática no estilo AIME.

Essa é a intuição a levar para sua própria avaliação. Um modelo de raciocínio 24B vendido para trabalho agêntico gasta a maior parte dos tokens de saída dentro de uma cadeia de pensamento, que se parece mais com o LiveCodeBench do que com o MBPP. Um modelo usado para extração estruturada, classificação com um esquema ou um formato fixo de chamada de ferramenta se parece muito mais com as linhas de alta aceitação. Se sua carga de trabalho for a primeira, espere ficar mais perto do piso de 1,34× da faixa do que do topo de 3,28×. Ninguém publicou a aceitação por carga de trabalho para este modelo de rascunho, e os oito conjuntos de dados do cartão do modelo são o mais próximo de um guia.

Em contrapartida: o 24B é um modelo apenas de raciocínio. A Liquid diz que ele sempre pensa antes de responder — o template de chat insere automaticamente uma <think> tag. Essa é a pior forma possível para a especulação, porque o trecho de raciocínio é exatamente o longo trecho de baixa aceitação. O rascunhador ainda vai ajudar; vai ajudar mais na resposta final e menos na parte que leva mais tempo.

Como saber, no seu próprio hardware, em uma tarde

Você não precisa confiar em nada do que foi dito acima. Ambos os caminhos de inferência expõem o contador de aceitação, que é o único número que decide se o drafter está se pagando no seu tráfego.

No SGLang, inicie o alvo com o drafter anexado, tamanho de bloco 9 e dez tokens de rascunho, depois leia as métricas de decodificação especulativa que o servidor relata por requisição. A taxa de aceitação na tabela do fornecedor fica entre 0,33 e 0,65 dependendo do conjunto de dados; uma execução que fica bem abaixo da linha relevante significa que o drafter está adivinhando errado e você está pagando pela verificação sem obter o ganho de velocidade. No llama.cpp com o sidecar GGUF F16, os tempos por resposta trazem draft_n e draft_n_accepted diretamente. Divida um pelo outro.

Dois detalhes operacionais vão custar uma hora se você ignorá-los. O servidor SGLang precisa de um build que inclua o caminho LFM2-MoE DSpark mesclado em 2026-08-31 — em qualquer versão mais antiga, a arquitetura do drafter é simplesmente desconhecida. E o tamanho do bloco é uma propriedade do checkpoint, não um parâmetro livre: o llama.cpp limita --spec-draft-n-max ao valor de 9 nos metadados do sidecar, então pedir 12 não adianta nada.

A pergunta que esta comparação não pode responder

Existe uma versão de "devo anexar o drafter" que não tem nada a ver com GPUs, e é a que a maioria das equipes realmente enfrenta. Se você chama o LFM2.5-24B-A2B por meio de uma API hospedada, a decisão sobre o drafter não é sua. A stack de serving ou anexa um decodificador especulativo, ou não; você vê um número de tokens por segundo e um preço, e ambos foram decididos upstream. O próprio Console da Liquid lista o 24B a US$ 0,10 por milhão de tokens de entrada, US$ 0,05 de entrada em cache e US$ 1,00 por milhão de saída — uma tarifa publicada que já reflete o caminho de decodificação que eles executam, e que pode mudar sem aviso.

Essa é a costura em que o roteamento ajuda em vez de complicar. Uma chamada hospedada e uma implantação auto-hospedada não são planos concorrentes, e sim dois ajustes do mesmo botão de custo: a auto-hospedagem mais o drafter minimiza o custo por token se o seu volume mantiver a GPU ocupada, e um endpoint hospedado minimiza o trabalho de obter uma resposta. O OrcaRouter foi feito para a segunda opção — uma única chave para mais de 200 modelos com 0% de acréscimo sobre o preço de tabela do provedor, então uma mudança de preço do fornecedor aparece do nosso lado no mesmo dia, com failover automático se um provedor degradar e uma DSL de roteamento para dividir o tráfego em vez de fixar um único backend. Atualmente não atendemos a família LFM2.5, então, para este modelo específico, o lado hospedado significa a própria API da Liquid ou as suas próprias GPUs; a comparação que vale a pena fazer é com os modelos que nós oferecemos, como Qwen3.6-35B-A3B — o modelo com o qual a Liquid se compara em tarefas agênticas — ou Gemma 4 26B-A4B.

Então: anexá-lo ou não

Anexe-o se você estiver servindo o LFM2.5-24B-A2B por conta própria com concorrência modesta, especialmente para saídas estruturadas ou em formato de extração, e se tiver 655 MB de folga ao lado do alvo. Os números do fornecedor indicam que você reduzirá aproximadamente pela metade ou a um terço seu tempo de decodificação nesse cenário, e a desvantagem é limitada: um drafter ruim custa uma passada de verificação, não uma resposta errada.

Deixe-o desativado se o seu endpoint já estiver saturado na casa das centenas, se a sua saída for raciocínio longo em formato livre, ou se você precisar de números de Apple Silicon antes de decidir — a ficha não traz nenhum, e o análogo mais próximo da mesma família foi lançado a 1,18× num MacBook. E deixe-o desativado, obviamente, se você não estiver executando o modelo de jeito nenhum: um drafter é uma otimização para uma implantação, e não há nada para otimizar até que a implantação exista.

O que resolveria o resto seria uma publicação do fornecedor e uma medição em Mac. Nenhuma das duas existe até 2026-10-21, o que é um estado estranho para um lançamento cujos pesos já podem ser baixados — e, para quem estiver disposto a executar o contador de aceitação por conta própria, uma oportunidade incomumente barata de ser o primeiro número independente no placar.