LFM2.5-24B-A2B-DSpark vs LFM2.5-8B-A1B-DSpark: o mesmo arquivo de 328M, duas apostas muito diferentes

Baixe qualquer um dos arquivos e você obtém 655.421.522 bytes. LFM2.5-24B-A2B-DSpark e LFM2.5-8B-A1B-DSpark têm o mesmo tamanho byte a byte, compartilham uma espinha dorsal de cinco camadas, a mesma cabeça Markov de rank 256, o mesmo tamanho de bloco de 9 e o mesmo vocabulário de 128.000 tokens — e nenhum dos dois consegue responder a um único prompt, porque ambos são modelos de rascunho para decodificação especulativa que existem apenas para adivinhar tokens para um modelo-alvo. O que os separa não é a especificação deles. É contra qual alvo foram treinados, e quanta evidência existe de que o truque funciona nele. Um tem medições publicadas de GPU e MacBook de um post de lançamento; o outro tem uma tabela de GPU e nenhum anúncio. Escolher entre eles, portanto, não é de modo algum uma comparação de modelos — é uma comparação de duas apostas, e apenas uma delas foi paga. As falhas documentadas de IA e incidentes com agentes por trás de lançamentos como este estão reunidos em the OrcaRouter AI Incident Archive onde cada entrada traz suas próprias fontes, gravidade, grau de confiança e sinalização de disputa.

Os arquivos são gêmeos; os trabalhos não.

Leia os dois arquivos config.json lado a lado e quase todos os campos coincidem: tamanho oculto 2.048, tamanho intermediário 6.144, ativação SiLU, 32 cabeças de atenção sobre 8 cabeças KV com dimensão de cabeça 64, cinco camadas de atenção completa, tamanho de bloco 9, enable_confidence_head: true, uma cabeça de Markov padrão de rank 256. A contagem de parâmetros é idêntica, e é por isso que os arquivos safetensors coincidem byte a byte.

Três campos diferem, e cada um é essencial.

• Taps de camadas do alvo — o drafter de 8B lê os estados ocultos das camadas 2, 6, 10, 14 e 18 de um alvo de 24 camadas; o drafter de 24B lê as camadas 2, 10, 18, 26 e 34 de um alvo de 40 camadas. Este é o campo que torna os arquivos não intercambiáveis.

• Posições máximas — 128.000 para o modelo preliminar de 8B, contra 131.072 para o de 24B, acompanhando as janelas de contexto de seus respectivos modelos-alvo.

RoPE theta — 5.000.000 contra 10.000.000, definido pela codificação posicional do alvo, e não por qualquer característica do drafter.

Esse último par é a evidência mais clara de que esses checkpoints foram treinados por alvo, em vez de escalados a partir de uma base comum. O drafter não tem identidade independente: sua distribuição de entrada é aquilo que os estados ocultos do alvo parecem ser, e eles mudam quando a arquitetura e o treinamento do alvo mudam. Direcione o drafter de 8B para o modelo de 24B e apenas os índices de camada já o tornam sem sentido; mesmo que eles se alinhassem, os logits que ele foi treinado para prever não se alinhariam.

O que cada um está realmente acelerando

Os modelos-alvo são mais diferentes do que a nomenclatura "8B versus 24B" sugere, e a diferença vai na direção errada para quem presume que o modelo maior é a carga mais pesada no dispositivo.

• Parâmetros totais e ativos — o LFM2.5-8B-A1B tem 8,3B no total, com 1,5B ativos por token; o LFM2.5-24B-A2B tem 24,0B no total, com 2,45B ativos.

• Profundidade — 24 camadas (18 convoluções com gate mais 6 GQA) contra 40 camadas (30 convoluções mais 10 GQA).

• Contexto — 128.000 tokens contra 131.072.

• Orçamento de treinamento — 38T tokens contra 36T, então o modelo menor não foi subtreinado em relação ao maior.

• Roteamento — o 8B usa um MoE de 64 especialistas com roteamento top-4, assim como o 24B, então ambos pagam a penalidade de ativação de especialistas que prejudica a verificação.

Ambos são modelos de raciocínio que pensam antes de responder, o que aqui importa mais do que o número de parâmetros. A maior fraqueza da decodificação especulativa é a saída longa e irrestrita, e uma cadeia de pensamento é exatamente isso. As tabelas dos fornecedores mostram isso: as linhas de maior aceitação em ambos os lançamentos são benchmarks de respostas curtas, como MBPP e MT-Bench, e as mais baixas são aquelas em que o modelo precisa inventar um longo caminho de solução.

A lacuna de evidências é a diferença real.

É aqui que os dois lançamentos deixam de ser comparáveis. O drafter 8B foi disponibilizado em 2026-08-20 como parte do anúncio de uma família completa, com medições em duas máquinas muito diferentes: uma única H100 de 80 GB em BF16 por meio do SGLang, e um MacBook Pro M4 Max executando pesos GGUF FP16 por meio do llama.cpp com kernels Metal experimentais. Ele teve média de 2,54× na H100, com pico de 3,18× no MATH-500, e apenas 1,18× no MacBook — 90 a 106 tokens por segundo, em média, em cinco conjuntos de dados.

O drafter de 24B tem uma única linha de hardware: um único NVIDIA B300 com o alvo FP8, cache KV BF16, temperatura 0. Ele tem média de 2,38× com concorrência 1, 2,69× com concorrência 32 e 1,71× com concorrência 256 em oito conjuntos de dados, com um pico de 3,28× no MBPP com concorrência 32. Não há linha para Mac, nem linha para H100, e nenhuma publicação de anúncio para explicar a omissão.

Para o modelo cujo discurso inteiro é sobre agentes no dispositivo — o post de lançamento da Liquid para o 24B abre com 184 tokens por segundo em um Apple M5 Max —, o número ausente do MacBook é a lacuna mais significativa do lançamento. O resultado do 8B explica por que ele pode ser pequeno: verificar um bloco de tokens ativa mais especialistas do que decodificar um, então um alvo MoE movimenta mais peso por token aceito. E a aceitação por si só não é o preditor: o modelo rascunho de 8B na verdade teve em média mais tokens aceitos por passo do que relata a ficha do 24B (6,95 em cinco conjuntos de dados contra 5,16 em oito) e ainda assim entregou apenas 1,18× em um MacBook. Esse é o ponto que vale reter — no 8B, uma aceitação forte não salvou a vazão no dispositivo. Supor que o 24B se comporte de forma diferente é uma aposta sem um número por trás.

Lendo as duas tabelas em relação uma à outra

As razões divulgadas não são diretamente comparáveis e não devem ser subtraídas entre si. GPU diferente, precisão-alvo diferente, conjuntos de dados diferentes, varreduras de concorrência diferentes. Mas dois padrões sobrevivem a essa incompatibilidade.

Primeiro, o teto é semelhante. A melhor célula H100 do 8B foi 3,18× no MATH-500 com tamanho de lote 1; a melhor célula B300 do 24B é 3,28× no MBPP com concorrência 32. Os drafters deste design ficam na mesma faixa de 1,5×–3,3× independentemente do alvo que atendem, o que é o esperado quando a arquitetura do drafter é mantida fixa e apenas os pesos mudam.

Em segundo lugar, e de forma mais útil, é no piso que os alvos divergem. A célula H100 mais fraca do 8B foi o GSM8K, com 1,29×; a célula B300 mais fraca do 24B com concorrência 256 foi o LiveCodeBench, com 1,34×, e o AIME, com 1,36×. Nenhuma das versões produz um caso em que a especulação seja gratuita, e ambas produzem casos em que ela mal vale a memória.

Há também uma mudança na documentação entre os dois cards que é fácil de passar despercebida e vale a pena destacar. O material de agosto dizia que a saída sob decodificação greedy é idêntica à linha de base "por construção"; o card do 8B promete "exatamente as mesmas saídas". Já o card do 24B alerta que diferenças de ponto flutuante entre verificação em lote e decodificação simples podem produzir texto diferente, inclusive sob amostragem greedy. O card posterior é o mais cuidadoso e, se você executa diffs de saída em nível de byte no CI, vale a pena tratar ambos como potencialmente não idênticos em vez de confiar na promessa mais antiga.

Qual deles é relevante para você é decidido pelo seu objetivo, não pelo seu orçamento.

Não existe cenário em que uma equipe escolha um destes em vez do outro por mérito. Você usa o 24B porque precisa da capacidade de um modelo de 24B em uma máquina que consiga comportá-lo — 14,5 GB em Q4_K_M no formato GGUF, ou uma única B300 para a configuração de serving em FP8. Você usa o 8B porque 8,3B de parâmetros totais com 1,5B ativos é o que cabe em um dispositivo de borda ou em um laptop, e o modelo de rascunho recupera parte da velocidade de decodificação que você abriu mão ao optar pelo menor. O modelo de rascunho é um acessório dessa primeira decisão, e a decisão quase sempre é tomada com base em memória e qualidade muito antes de a especulação entrar na conversa.

O único caso em que a escolha está em aberto é a avaliação. Se você está testando se vale a pena adotar o DSpark no seu stack, o pareamento 8B é o experimento mais barato: cabe em uma H100, tem números de Mac que você pode comparar com os do seu próprio laptop, e seu modo de falha no dispositivo já foi documentado pelo fornecedor. O pareamento 24B é o experimento de produção mais interessante e o menos documentado.

Para qualquer um dos dois, o número que decide o resultado é o contador de aceitação, não a tabela do fornecedor. O SGLang expõe a aceitação da decodificação especulativa por requisição; o llama.cpp reporta draft_n e draft_n_accepted nos tempos por resposta. Rode seus próprios prompts por dez minutos e divida. Se a aceitação ficar próxima da média da placa, o drafter compensa; se ficar no limite inferior, você está comprando passagens de verificação e deve desacoplá-lo — e essa conclusão valerá para ambos os checkpoints, porque o mecanismo é o mesmo.

Nenhum dos checkpoints é um modelo que você pode chamar

Esta é a parte que pega as pessoas que encontram esses nomes num catálogo de modelos e assumem que são opções de um menu. Eles não são endpoints. Nenhum dos drafters tem preço por milhão de tokens, nenhum aparece numa listagem de API e nenhum jamais será roteado por uma plataforma que serve modelos — porque o pareamento correto é uma configuração do lado do servidor, não um parâmetro de requisição.

A Liquid AI vende o próprio modelo-alvo de 24B a US$ 0,10 por milhão de tokens de entrada, US$ 0,05 em cache e US$ 1,00 por milhão de saída, e qualquer especulação que ela execute por trás desse preço é invisível para o chamador. Essa é a forma comum do mercado agora: a engenharia interessante acontece dentro da pilha de serving, e o que chega ao desenvolvedor é uma tarifa e um número de tokens por segundo. Onde as plataformas de roteamento conquistam seu lugar é na comparação acima dessa camada — colocando um candidato ao lado dos modelos que ele precisa superar. A OrcaRouter executa um endpoint em mais de 200 modelos com 0% de markup sobre o preço de tabela do provedor, então, quando a tarifa de um fornecedor muda, a tarifa que você vê muda no mesmo dia, e o failover impede que um modelo candidato se torne um ponto único de falha enquanto você o avalia. A família LFM2.5 não está entre eles hoje, então um 8B ou 24B auto-hospedado com seu drafter anexado continua sendo uma implantação local; os modelos que vale a pena testar contra ele — Qwen3.6-35B-A3B no lado agêntico, Gemma 4 26B-A4B no lado da eficiência — são os que roteamos.

O que um ano de lançamentos do DSpark estabeleceu

A família agora abrange quatro alvos de texto e um alvo de visão, de 1,2B a 24B, todos compartilhando uma mesma receita de drafter: cerca de 300M parâmetros, cinco camadas de atenção, bloco 9, treinado nos próprios estados ocultos do alvo. Essa consistência é o achado real. A Liquid transformou a decodificação especulativa de um projeto de pesquisa por modelo em uma etapa de fabricação — o mesmo drafter, redirecionado, entregue em poucos dias após cada novo modelo. Se vale a pena adotar essa etapa no seu hardware é uma questão sobre o seu tráfego, e a resposta varia por carga de trabalho muito mais do que varia conforme qual desses dois arquivos você baixa.

O que o lançamento de 24B acrescenta a esse quadro não é uma proporção melhor. É a primeira vez que um drafter é lançado sem a documentação explicativa que o acompanha — e a primeira vez que a ficha do próprio fornecedor lhe diz, em linguagem clara, que as saídas podem, no fim das contas, não ser idênticas bit a bit.