A mesma GPU, 60–85% mais rápida por usuário: o ganho de inferência que não exige trocar de modelo

§1 — O que o paper afirma

Antes dos números, o mecanismo — porque sem ele nada faz sentido. Decodificação especulativa (speculative decoding) é um truque para acelerar a geração de texto de um modelo grande sem trocá-lo: um modelo pequeno e rápido (o rascunhador, ou drafter) “chuta” vários tokens de uma vez; o modelo grande então confere todos esses chutes num único passo, aceita o maior prefixo que ele mesmo teria gerado e descarta o resto. O ponto crucial: o resultado é matematicamente idêntico ao do modelo grande sozinho — a técnica é lossless, não muda uma vírgula da qualidade da resposta, só a velocidade com que ela sai (§1; §2.1). É pura economia de tempo e de GPU, não um modelo “melhor”.

O paper (lido na íntegra do PDF publicado pela DeepSeek no repositório DeepSpec, no GitHub — este trabalho não está no arXiv) ataca dois gargalos dessa técnica com o método que batiza de DSpark:

1. Rascunho “semi-autoregressivo”. Rascunhadores paralelos chutam todos os tokens de uma vez (rápido), mas como cada posição é adivinhada isoladamente, os chutes do meio/fim do bloco erram muito — o paper chama isso de suffix decay (a taxa de acerto despenca ao longo do bloco). DSpark acopla um núcleo paralelo pesado a uma cabeça sequencial leve que injeta dependência entre os tokens, corrigindo esse decaimento a um custo de latência quase nulo (§3.1; Figura 2).
2. Verificação “agendada por confiança”. Em vez de verificar todos os chutes sempre, uma cabeça de confiança estima a probabilidade de cada token sobreviver, e um agendador ciente do hardware decide, conforme a carga do sistema, quantos vale a pena verificar — cortando trabalho desperdiçado quando o servidor está cheio (§3.2; Algoritmo 1).

Resultados offline (Tabela 1, §4.2). Medindo o “comprimento aceito” (quantos tokens o modelo grande aprova por rodada — quanto maior, mais rápido), o DSpark supera os dois melhores concorrentes em todos os modelos e domínios testados:

• Sobre o Eagle3 (rascunhador autoregressivo): +30,9%, +26,7% e +30,0% nos alvos Qwen3-4B, 8B e 14B.
• Sobre o DFlash (rascunhador paralelo estado-da-arte): +16,3%, +18,4% e +18,3% nos mesmos alvos.
• O ganho se mantém em outra família de modelos (Gemma4-12B), o que sugere que não é um artefato de um modelo só.
• Efeito de domínio relevante: tarefas estruturadas aceitam blocos mais longos (5,57 em matemática, 5,12 em código no Qwen3-4B) do que conversa aberta (3,49) — ou seja, o ganho é maior onde a saída é mais previsível.

Custo de latência quase zero (Figura 4, §4.3.2). Aumentar o tamanho do bloco de rascunho de 4 para 16 tokens adiciona só 0,2% a 1,3% de latência por rodada em relação ao DFlash, entregando até 30% mais tokens aceitos. A cabeça sequential praticamente não pesa.

Em produção, no DeepSeek-V4 (§5.4, Figuras 7–8). Aqui está o número que interessa à diretoria. Rodando dentro do sistema de serving do DeepSeek-V4 (versões preview Flash e Pro), sob tráfego real de usuários, comparado à configuração de produção anterior (MTP-1, um rascunhador de token único):

• +60% a 85% de velocidade de geração por usuário no V4-Flash, e +57% a 78% no V4-Pro — a mesma capacidade agregada de throughput, ou seja, sem custar mais GPU.
• O mecanismo: sob carga moderada o agendador expande o orçamento de verificação de 2 tokens fixos (do MTP-1) para ~4–6 tokens por requisição; sob alta concorrência, ele reduz automaticamente para não sufocar o servidor (Figura 8).
• Sob SLAs de latência apertados (ex.: garantir 120 tok/s por usuário no Flash, 50 no Pro), o DSpark sustenta throughput onde a baseline colapsa — os autores reportam ganhos nominais de até +661% (Flash) e +406% (Pro), mas eles próprios alertam que isso é o efeito de esticar a fronteira de interatividade num ponto onde a baseline mal funciona, e não um multiplicador de velocidade representativo (§5.4). O número honesto, em throughput comparável, é os 57–85% acima.

Aberto. A DeepSeek liberou os checkpoints do DSpark para o DeepSeek-V4-Flash e V4-Pro (preview) e o repositório de treino DeepSpec (que inclui também Eagle3 e DFlash) (§4.2; §5.4).

§2 — Por que importa para o negócio

A leitura para a diretoria não é “a DeepSeek lançou uma técnica de inferência”. É mais incômoda: o gargalo dos seus produtos de IA quase nunca é qual modelo você usa — é a velocidade com que ele responde. E latência não é detalhe de engenharia: é o que decide quais produtos existem e quais morrem na demo.

Um assistente de voz que responde em três segundos não é um assistente de voz — é uma URA irritante. Um copiloto que gagueja ninguém usa duas vezes. Um agente que leva dois minutos para cuspir um relatório vira um botão que o usuário aperta uma vez e abandona. Nenhum desses casos morre por falta de inteligência do modelo; morrem por falta de velocidade na entrega. E é exatamente essa camada que a diretoria não discute: gasta semanas escolhendo o modelo e zero minuto no serving, que é o que decide se o produto é usável.

O DSpark mostra o tamanho do que está em jogo nessa camada esquecida: o mesmo modelo, a mesma resposta — matematicamente idêntica —, 60–85% mais rápido por usuário, sem uma GPU a mais. Isso não é “melhoria incremental de infra”. É a fronteira entre o caso de uso que fecha conta e o que fica bonito no slide e nunca sobe para produção. E vem de graça em qualidade, porque não toca na qualidade.

Não confunda com upgrade de modelo — quem espera “IA mais inteligente” está olhando o eixo errado. E costuma ser o mesmo executivo que vai queimar o próximo trimestre trocando de fornecedor atrás de três pontos num benchmark, enquanto deixa 80% de velocidade parados no serving que já tem em casa. A ressalva, e ela basta: os 60–85% são da própria DeepSeek, medidos na infra deles contra a configuração anterior deles. É real, não é vaporware — mas o número que vale para você é o que você medir no seu ambiente, não o do paper.

§3 — O que fazer a respeito

• Esta semana, uma pergunta ao time — e não aceite rodeio: nosso serving já usa decodificação especulativa? Se a resposta for “não” ou “acho que não”, você acabou de encontrar velocidade e dinheiro parados na mesa. A técnica já é padrão de mercado; não usá-la é uma escolha — quase sempre não-intencional.
• Pare de tratar latência como problema de engenharia e trate como decisão de produto. É a alavanca que define o que é viável. Priorize onde ela faz ou quebra o negócio: cargas que cospem muito texto (código, relatórios, agentes) e qualquer coisa em tempo real (voz, copiloto).
• Proíba o slide com “80% mais rápido” até alguém medir no seu hardware. O ganho depende da razão entre tempo de rascunho e de verificação na sua stack — não na da DeepSeek. Meta sem medição é ficção de PowerPoint.
• Escolha o caminho com os olhos abertos. Roda DeepSeek-V4? Os checkpoints abertos são um atalho concreto. Não roda? Então usar a técnica significa treinar um rascunhador — custo de engenharia real. Decida isso antes de prometer o ganho, não depois.

§4 — Limite da evidência

Este é um caso em que a fonte importa tanto quanto o resultado.

• Não é arXiv, não passou por revisão por pares. É um preprint publicado pela DeepSeek no próprio repositório GitHub. Os números de produção são auto-reportados pela mesma equipe que opera o DeepSeek-V4 — não há terceiro independente confirmando os 60–85%. Isso não invalida o trabalho (a metodologia é detalhada e reprodutível na parte offline), mas exige a cautela que se aplica a qualquer benchmark de fornecedor sobre o próprio produto.
• O ganho é medido contra a baseline anterior da própria DeepSeek (MTP-1), um rascunhador de token único deliberadamente conservador — não contra o melhor método independente do mercado. É um ganho real sobre “o que eles rodavam antes”, não necessariamente sobre “o melhor que existe”.
• Os números dramáticos (+661%, +406%) são, por admissão dos próprios autores, artefato de fronteira — aparecem em pontos de SLA onde a baseline praticamente para de funcionar. Usar esses números como “6x mais rápido” seria desonesto; o paper explicitamente pede que não. O ganho representativo é 57–85%.
• É velocidade/custo, não inteligência. Por ser lossless, o DSpark não melhora a qualidade da resposta em nada — quem espera “modelo melhor” está olhando o eixo errado. O valor é servir o mesmo modelo mais barato e com menos latência.
• Reproduzir os ganhos de produção exige infra de escala DeepSeek. O deployment depende de kernels customizados, agendamento de sobrecarga zero (ZOS), o framework de treino HAI-LLM e a arquitetura MoE do V4. Os checkpoints abertos são específicos do V4-Flash/Pro (preview); para usar a técnica no seu próprio modelo é preciso treinar um rascunhador — custo de engenharia não trivial que o paper não dimensiona para terceiros.
• A métrica offline (comprimento aceito, τ) é um proxy. O ganho real de tempo de parede depende da razão entre o tempo de rascunho e o de verificação no seu hardware, que pode diferir do ambiente do paper.
• Limitação assumida (§5): o DSpark ainda paga um custo fixo de rascunho para gerar o bloco inicial; em consultas difíceis, de baixa taxa de aceitação, esse custo é irrecuperável. Os autores apontam “early exiting” ciente de dificuldade como trabalho futuro — ou seja, o método ainda não é ótimo para cargas de baixa previsibilidade.