DSpark: Aceleração da inferência de LLM com speculative decoding [pdf]

• DSpark: framework de speculative decoding que combina geração semiautorregressiva (semi-autoregressive) e agendamento por confiança
• O parallel drafter propõe blocos longos de tokens em uma única passada forward, mas a ausência de dependência entre tokens causa queda acentuada da taxa de aceitação no fim do bloco (acceptance decay); o problema é resolvido simultaneamente com uma estrutura semiautorregressiva e verificação sensível à carga
• Injeta dependências internas no bloco ao combinar um backbone paralelo pesado com um módulo sequencial leve, mantendo a velocidade de draft e mitigando o suffix decay
• O confidence head estima a probabilidade de sobrevivência do prefixo por posição, e o scheduler sensível ao hardware ajusta dinamicamente o comprimento de verificação de cada requisição de acordo com a curva de throughput do motor
• Em benchmarks offline, mostra melhora consistente no accepted length em relação ao baseline autorregressivo (Eagle3) e ao baseline paralelo (DFlash), além de reduzir desperdício de verificação na implantação em produção do DeepSeek-V4
• Em comparação com o baseline de produção anterior, MTP-1, acelera a velocidade de geração por usuário em 60–85% com o mesmo throughput, abrindo uma faixa de desempenho antes inalcançável sob restrições rígidas de interatividade e expandindo a fronteira de Pareto

---

Definição do problema — dois gargalos do parallel drafter

• LLMs geram tokens de forma autorregressiva; cada token exige uma passada forward condicionada a todos os tokens anteriores, de modo que a latência de inferência cresce proporcionalmente ao comprimento da saída, tornando baixa utilização de GPU e alta latência os principais gargalos do serving em produção
• No speculative decoding, um modelo draft leve propõe um bloco de candidatos e o modelo target o verifica em uma única passada forward; por rejection sampling, aceita-se o prefixo mais longo que coincide com a distribuição do target, acelerando sem perda de qualidade

• Limites do drafter autorregressivo

  • Cada posição é condicionada aos tokens anteriores, o que dá forte capacidade de modelagem, mas o custo de drafting cresce linearmente com o tamanho do bloco (𝑇draft ∝ 𝛾), restringindo-o a blocos pequenos e arquiteturas rasas

• Limites do drafter paralelo

  • Gera todas as posições de uma vez, então a latência do draft quase não depende do tamanho do bloco, permitindo blocos grandes (por exemplo, 𝛾=16)
  • Como prevê cada posição de forma independente, não consegue modelar dependências entre tokens, causando multi-modal collision e forte queda da taxa de aceitação nas posições finais
  • Verificar indiscriminadamente todo um bloco longo reduz o throughput; em especial sob alta concorrência, tokens com alto risco de rejeição ocupam capacidade do batch
  • O comprimento ideal de verificação varia em dois eixos — no lado dos dados (requisições estruturadas, como código, têm alta taxa de aceitação; chat aberto, baixa) e no lado do sistema (com baixa carga, verificação extra é quase grátis; com alta carga, consome capacidade de outras requisições ativas)

Arquitetura — dois componentes complementares

• A latência por token é 𝐿 = (𝑇draft + 𝑇verify)/𝜏, e a aceleração se reduz a três alavancas: diminuir 𝑇draft, aumentar 𝜏 e reduzir o 𝑇verify efetivo

• Ciclo de decodificação: a partir do prompt ABC, o modelo target gera o próximo token D (atuando como âncora) → o backbone paralelo e o head sequencial geram o draft EFGH e as pontuações de confiança c1–c4 → o scheduler mantém o prefixo EFG e remove o token H de baixa confiança → o modelo target verifica em paralelo; se E e F forem aceitos e G rejeitado, gera o token corrigido G*

• Geração semiautorregressiva (Semi-Autoregressive Generation)

  • Um drafter paralelo pode gerar combinações incoerentes como “of problem” em continuidades multimodais como “of course”/“no problem”, porque cada posição marginaliza sobre todos os possíveis tokens anteriores, e não sobre os tokens anteriores realmente amostrados
  • Etapa paralela (Parallel stage): o backbone paralelo (adotando DFlash) faz uma única passada forward no bloco inteiro, gerando estados ocultos e logits básicos; a própria âncora é tratada como a primeira posição de predição, produzindo 𝛾 logits a partir de 𝛾 entradas e reduzindo computação de draft
  • Etapa sequencial (Sequential stage): adiciona aos logits básicos um viés de transição dependente do prefixo 𝐵𝑘, fazendo cada posição ser condicionada aos tokens amostrados anteriormente dentro do bloco e induzindo uma distribuição causal por fatoração autorregressiva; por ser sequencial, precisa ser muito mais leve que a etapa paralela (𝑇sequential ≪ 𝑇parallel)
    • Head de Markov: simplifica para uma transição de primeira ordem dependente apenas do token imediatamente anterior; aproxima a matriz completa 𝑉×𝑉 por fatoração de baixo posto 𝐵 = 𝑊1𝑊2 (padrão 𝑟=256), minimizando armazenamento e computação por passo, reforçando “course” e suprimindo “problem” após a amostragem de “of”, o que reduz colisões entre modos
    • Head RNN: acumula todo o histórico do prefixo dentro do bloco em um estado recorrente 𝑠𝑘 e, com atualização por gates, acessa informações de antes do token imediatamente anterior; porém, a complexidade de implementação é maior e as características de deploy são menos favoráveis

• Verificação com agendamento por confiança (Confidence-Scheduled Verification)

  • Como a taxa de aceitação do draft varia por domínio (alta em código, baixa em chat aberto) e o custo de verificar tokens extras depende da carga do motor, é necessário um mecanismo unificado que direcione computação do target apenas para tokens com retorno esperado positivo
  • Confidence head: em cada posição 𝑘, produz uma estimativa escalar 𝑐𝑘 ∈ (0,1), modelando a probabilidade condicional de o token na posição 𝑘 passar na verificação, dado que todos os tokens anteriores foram aceitos; usa uma projeção linear leve + sigmoid
    • É treinado com o sinal analítico de taxa de aceitação por passo 𝑐*𝑘 = 1 − ½‖𝑝𝑑𝑘 − 𝑝𝑡𝑘‖1 (distância de variação total entre as distribuições draft e target)
  • Calibração posterior — Sequential Temperature Scaling (STS): o agendamento sensível ao hardware exige valores absolutos de probabilidade acumulada de aceitação, mas a confiança da rede neural tende a ser superconfiante; como cada 𝑐𝑖 é uma probabilidade condicional, ela é fatorada pelo produto cumulativo do prefixo, e em um conjunto de validação held-out faz-se uma busca em grade 1D da esquerda para a direita para minimizar ECE, preservando a ordem dos tokens
  • Hardware-Aware Prefix Scheduler: formaliza a escolha do comprimento de verificação como um problema de maximização do throughput global; para 𝑅 requisições ativas, usa SPS(𝐵) (uma tabela de custo perfilada uma vez na inicialização do motor), maximizando 𝛩 = 𝜏·SPS(𝐵)
    • Como a probabilidade de sobrevivência 𝑎𝑟,𝑗 é monotonicamente não crescente em relação a 𝑗, a ordenação global com seleção gulosa respeita naturalmente a dependência de prefixo dentro do bloco, com consulta incremental à tabela de custo em 𝑂(1)
    • O speculative decoding sem perda exige a propriedade non-anticipating; como a característica de Markov depende dos tokens amostrados anteriormente, uma busca global posterior vazaria a informação 𝑥𝑟,𝑘 e introduziria viés de seleção
    • Um mecanismo de early-stopping interrompe imediatamente quando o throughput cair, impondo causalidade para que a decisão de admissão dependa apenas do prefixo processado até aquele passo; a garantia do ótimo global só vale quando o objetivo 𝛩 é unimodal

Treinamento (Training)

• Múltiplas posições-âncora são amostradas aleatoriamente em sequências target para compor dados de treino em blocos de 𝛾 tokens
• O modelo target permanece frozen durante todo o processo; o modelo draft compartilha a camada de embedding e o LM head, também congelados, e apenas o backbone drafter, o bloco sequencial e o confidence head são atualizados
• O objetivo de treino é uma soma ponderada de três termos — perda de entropia cruzada Lce, perda de alinhamento de distribuição Ltv e perda de confiança Lconf
  • Todos os termos recebem pesos por posição 𝑤𝑘 = exp(−(𝑘−1)/𝛾), enfatizando posições iniciais que contribuem mais para o accepted length esperado na verificação baseada em prefixo
  • Ltv penaliza a distância de variação total; como a probabilidade de aceitação por passo é 1 − ½‖𝑝𝑑 − 𝑝𝑡‖1, minimizar Ltv equivale a maximizar a taxa de aceitação esperada
  • Pesos padrão: 𝛼ce = 0.1, 𝛼tv = 0.9, 𝛼conf = 1.0

Experimentos — benchmark offline

• Configuração

  • Modelos target: Qwen3-{4B, 8B, 14B}, Gemma4-12B / drafters de comparação: o drafter paralelo SOTA DFlash e o drafter autorregressivo Eagle3
  • Tudo foi retreinado sob o mesmo framework e dados; o horizonte TTT (7) do Eagle3 foi alinhado ao tamanho de bloco (7) de DFlash e DSpark; profundidade do draft: Eagle3 com 1 camada, DSpark e DFlash com 5
  • Dados de treino: Open-PerfectBlend com 1,3 milhão de amostras (chat 17,6%, matemática 39,4%, código 38,9%, instruction-following 4,1%); apenas os prompts foram usados, e as respostas foram regeneradas por cada modelo target; treino por 10 épocas
  • Domínios de avaliação: matemática (GSM8K, MATH500, AIME25), código (MBPP, HumanEval, LiveCodeBench), chat cotidiano (MT-Bench, Alpaca, Arena-Hard), com temperatura de amostragem 1.0 e relatório do accepted length por rodada 𝜏

• Resultados principais

  • A avaliação offline desativou o scheduler de confiança para isolar, com bloco fixo, apenas a qualidade pura do draft
  • Em Qwen3-4B, 8B e 14B, o accepted length médio macro melhorou 30,9%·26,7%·30,0% sobre o Eagle3 e 16,3%·18,4%·18,3% sobre o DFlash; o Gemma4-12B também mostrou ganhos consistentes, indicando generalização entre famílias de modelos
  • O accepted length é maior em tarefas estruturadas do que em chat aberto (no Qwen3-4B, matemática 5.57 e código 5.12 vs chat 3.49), e essa variação de previsibilidade dos dados motiva o uso de agendamento por confiança para evitar desperdício com comprimento de verificação estático

Análise dos experimentos

• Por que a geração paralela supera a autorregressiva

  • Uma observação contraintuitiva é que os drafters paralelos e semiautorregressivos alcançam accepted length maior que o Eagle3 totalmente autorregressivo; isso é analisado pela taxa de aceitação condicional por posição (contando no denominador apenas os casos em que todas as posições anteriores foram aceitas)
  • Vantagem de capacidade na posição 1: a primeira posição depende apenas do contexto target; o Eagle3 fica restrito a redes rasas por causa da latência 𝑂(𝛾), enquanto o drafter paralelo 𝑂(1) pode usar redes profundas; o DFlash começa acima do Eagle3 (matemática 0.88 vs 0.81, chat 0.72 vs 0.53), e como a rejeição do primeiro token invalida todo o bloco, essa vantagem inicial pesa muito no accepted length final
  • Limite de independência nas posições finais: da posição 2 à 7, o Eagle3 mantém ou eleva seu desempenho usando certeza condicional (chat 0.53→0.74), enquanto o DFlash cai bastante (código 0.87→0.78, chat 0.72→0.63), gerando sufixos incoerentes por multi-modal collision
  • Mitigação do suffix decay pelo modelo semiautorregressivo: o DSpark herda a alta aceitação inicial do backbone paralelo profundo (começando em 0.93 em matemática) e reduz o colapso nas posições finais com um head sequencial leve, mantendo taxas de aceitação condicionais altas e estáveis ao longo de todo o bloco

• Pouca autorregressão já gera grande efeito

  • Profundidade do drafter: com tamanho de bloco 7 fixo, o desempenho do DSpark melhora monotonicamente ao aumentar as camadas de 1 para 5; o maior ganho marginal está de 1 para 2 camadas, e o DSpark de 2 camadas supera o DFlash de 5 camadas em todos os domínios, comprovando a eficiência de parâmetros do head sequencial
  • Comprimento da proposta: com profundidade 5 fixa, ao ampliar o comprimento do draft em {4,8,12,16}, o DSpark supera o DFlash em todos os comprimentos, e a diferença cresce com 𝛾 (em 𝛾=7, matemática 16%, código 15%, chat 18%; em 𝛾=15, 30%, 26%, 22%); o head RNN dá apenas pequeno ganho adicional em comprimentos longos, então o head de Markov foi adotado como padrão
  • Overhead de latência: com batch 128 e comprimentos de contexto médios em {512,1024,2048,4096}, a latência do bloco sequencial é desprezível; ao expandir o comprimento do draft de 4 para 16, adiciona apenas 0,2–1,3% à latência total por rodada, enquanto melhora o accepted length em até 30%

• O papel do confidence head — verificar com mais inteligência, não apenas por mais tempo

  • Com Qwen3-4B, uma varredura de limiar estático mostrou que elevar o limiar aumenta a taxa de aceitação ao filtrar tokens rejeitados, com maior efeito em chat (45,7%→95,7%), enquanto matemática (76,9%→92,5%) e código (67,6%→92,0%) sobem mais gradualmente
  • Limiares estáticos ignoram a carga do sistema e são subótimos em serving dinâmico; o modelo de confiança tem forte poder discriminativo (ROC-AUC 0.81–0.90), mas é superconfiante (ECE 3–8%); após aplicar STS, o ECE médio cai para cerca de 1%, tornando confiáveis as estimativas de sobrevivência

Implantação em produção

• Treinamento escalável

  • Implantado em conjunto com o preview do DeepSeek-V4-Flash e Pro; o backbone paralelo usa 3 camadas MoE com mHC e sliding window attention 128, com tamanho máximo de bloco 𝛾=5 e head de Markov; o confidence head é treinado end-to-end e depois calibrado com STS
  • Comunicação de estados ocultos (Hidden state communication): em vez de transmitir logits do vocabulário inteiro (𝑉≈10⁵), transmite-se apenas o estado oculto antes do LM head, e o LM head é executado localmente no worker de draft apenas nas posições amostradas, reduzindo a complexidade de comunicação por token para 𝑂(𝑑)
  • Anchor-bounded sequence packing: amostra um número fixo de âncoras de draft e empacota blocos isolados de predição em um batch denso, mantendo máscara causal entre múltiplas sequências independentes com índices de attention em nível de token e evitando overhead de padding

• Aplicação prática do scheduler

  • Há dois conflitos: o algoritmo assume uma curva de capacidade suave e unimodal, mas o SPS(𝐵) real tem quedas discretas em degraus; além disso, o agendamento dinâmico de tokens por passo entra em conflito com o replay contínuo de CUDA graph e com o Zero-Overhead Scheduling (ZOS)
  • A adaptação usa agendamento assíncrono: como o ZOS precisa do próximo tamanho de batch antes da conclusão da etapa atual, aproxima-se a capacidade de verificação usando a saída de confiança de duas etapas antes; os candidatos da etapa atual são ordenados pela confiança acumulada mais recente, enquanto previsões passadas servem apenas para decidir o comprimento de corte dinâmico (𝐾), sendo convertido em seleção top-𝐾 dinâmica
  • O early-stopping é removido para permitir busca global sem restrições; como a avaliação usa apenas histórico de duas etapas antes, ela fica isolada da realização atual do token 𝑥𝑟,𝑘, criando uma barreira causal e conciliando maximização do throughput físico com preservação exata da distribuição target

• Inferência com alto throughput e baixa latência

  • O serving em produção busca otimizar simultaneamente a latência por requisição e o throughput total; nesta implantação, restrições de capacidade de KV-cache e tráfego de usuários mantêm o tamanho efetivo do batch abaixo do limiar de saturação da GPU, de forma que os dois objetivos ficam fortemente correlacionados, e não em competição
  • Suportar consultas de comprimento variável é um desafio; em kernels de decode de comprimento fixo, um tratamento simples leva a padding e carga desigual, com baixa utilização de GPU; a solução foi achatar todos os tokens das requisições e tratá-los como elementos independentes, transmitindo as dependências intra-sequência via marker tensor da sparse attention; no DeepSeek-V4, apenas os kernels index-attention e compress foram modificados para suportar esse roteamento de comprimento variável

• Desempenho com tráfego real de usuários

  • O DSpark-5 (𝛾=5) foi comparado ao baseline MTP-1 nos motores de produção V4-Flash e V4-Pro; o MTP-1 mantinha configuração de token único porque drafters estáticos multi-token (MTP-3/5) reduziam o throughput em alta concorrência, e foi substituído pelo DSpark duas semanas após o lançamento do DeepSeek-V4-preview
  • V4-Flash: ganho de 51% em throughput no SLA de 80 tok/s/user; em 120 tok/s/user, o MTP-1 se aproxima do limite operacional, resultando em vantagem nominal de 661% (interpretada não como multiplicador absoluto, mas como evidência da expansão da fronteira de interatividade); no mesmo throughput, a geração por usuário acelera 60–85%
  • V4-Pro: ganho de 52% em 35 tok/s/user e vantagem nominal de 406% em 50 tok/s/user; na mesma capacidade, aceleração de 57–78%, deslocando a fronteira throughput–interatividade para fora em termos gerais
  • Comportamento adaptativo à carga: em concorrência intermediária (menos de 200 requisições no V4-Flash e 150 no V4-Pro), o scheduler expande os 2 tokens estáticos do MTP-1 para cerca de 4–6 tokens por requisição, aumentando os tokens aceitos por passada forward; quando a concorrência satura, reduz suavemente o comprimento de verificação para podar tokens de baixa confiança antes que consumam a capacidade do batch

• Limitações

  • Embora o prefix scheduler minimize desperdício na verificação target, ainda existe o custo fixo de draft para gerar o bloco inicial de 𝛾 tokens no backbone paralelo; em consultas complexas com taxa de aceitação intrinsecamente baixa, essa computação antecipada é irrecuperável
  • Como trabalho futuro, o draft model pode incorporar early exiting sensível à dificuldade (difficulty-aware early exiting) para permitir que essas requisições ignorem a geração do bloco completo

Conclusão

• Do ponto de vista estrutural, o paradigma semiautorregressivo que combina um backbone paralelo pesado com um head sequencial leve mitiga o forte colapso de sufixo dos drafters paralelos independentes
• Do ponto de vista de sistema, a escolha do comprimento de verificação é formulada como um problema de maximização do throughput global, ajustando dinamicamente o orçamento de verificação com um prefix scheduler sensível ao hardware, baseado em probabilidades de sobrevivência calibradas e na carga do motor em tempo real
• Em ampla avaliação offline, supera os baselines SOTA autorregressivos e paralelos; na implantação real do DeepSeek-V4, demonstrou valor prático ao manter alta concorrência sob carga, acelerar a geração por usuário e expandir a fronteira de Pareto do serving de LLM

[GN⁺]

Opiniões no Hacker News

• A DeepSeek não está apenas expandindo os limites; ela também publica artigos excelentes explicando como alcançou seus ganhos de desempenho.
  Infelizmente, os laboratórios dos EUA já não fazem muito esse tipo de divulgação, e parece que o trabalho mais interessante em IA hoje está sendo feito por laboratórios chineses.

  • O Google ainda publica muita pesquisa de arquitetura de LLMs.
    Em 2022, apresentou a decodificação especulativa para LLMs[1], e neste ano também publicou código para fazer decodificação especulativa nos modelos Gemma 4[2].

    [1] https://arxiv.org/abs/2211.17192

    [2] https://github.com/google-gemma/cookbook/blob/main/docs/mtp/...

  • As empresas de IA dos EUA precisam prestar contas por investimentos enormes, então parecem estar procurando um fosso mágico que justifique suas avaliações.
    Se divulgarem esse tipo de otimização, sua vantagem competitiva diminuirá bastante.

  • Talvez seja uma abertura por necessidade.
    Como os laboratórios dos EUA estão desbravando a fronteira, a especulação é que a DeepSeek esteja abrindo o que tem em código aberto para nivelar o campo de jogo.

  • A DeepSeek está comoditizando os ganhos de desempenho dos quais os laboratórios dos EUA dependem para ganhar dinheiro para seus investidores.

  • Já passou da hora de o Ocidente abandonar a visão de que chineses são apenas “pessoas muito ruins sob uma ditadura”.

• Os modelos no Hugging Face já estão no ar, e parecem vir com um módulo de decodificação especulativa embutido no modelo original, o que é bem legal.

  Flash: https://huggingface.co/deepseek-ai/DeepSeek-V4-Flash-DSpark

  Pro: https://huggingface.co/deepseek-ai/DeepSeek-V4-Pro-DSpark

  Estou curioso para ver se isso também vai entrar no DwarfStar para inferência local.
  Desde que o antirez publicou a quantização de 2 bits, tenho usado bastante o modelo Flash.

  • Há chance de isso ser aplicado também ao Qwen 27B?

• A impressão agora é que a DeepSeek é quase a única empresa de IA realmente tentando inovar, em vez de simplesmente mirar o primeiro lugar nos benchmarks.
  Lugares como OpenAI, Anthropic e Google parecem mais focados em competir entre si do que em continuar inovando.

  • Acho que também é preciso incluir outros laboratórios chineses, como a Moonshot (criadora do Kimi) e a Z.ai (criadora do GLM).
    Eles também estão inovando e continuam compartilhando suas pesquisas publicamente.
    Pelo que sei, o fundador da Moonshot chegou a postar no Twitter um vídeo de 40 minutos explicando as técnicas que sustentam o Kimi.

  • Há muito tempo, muitas empresas dos EUA adotam como estratégia prender o usuário, por qualquer meio que seja.
    Qualidade e inovação vêm em segundo lugar; elas querem dominar o mercado, aprisionar os usuários e depois exercer influência sobre regulação e lobby para manter seu poder.

  • Essas empresas também competem entre si por meio de inovação.
    A inovação oferece mais utilidade aos clientes, mas a tecnologia simplesmente não é divulgada.
    Segredos comerciais são secretos por um motivo.

    O motivo de a DeepSeek parecer “a mais inovadora” talvez seja que isso é o que se consegue observar de fora.
    É uma ilusão parecida com concluir que, só porque nem todo mundo publica fotos ao público, os modelos que publicaram seriam os mais bonitos de toda a população.

  • Os grandes laboratórios já vinham fazendo isso há pelo menos um ano.

  • O Qwen também.

• Estou usando o DeepSeek v4 pro há um mês no Kilo Code, e ele é excelente.
  É rápido, estável, tem uma janela de contexto grande e é realmente barato.
  Usei 1,5 bilhão de tokens este mês e custou US$ 40; a maior parte foi cacheada, mas ainda assim é barato.

  • No omp, estou usando DeepSeek como agentes task e quicktask, e Sonnet para o resto.
    Meus gastos com IA caíram bastante, de US$ 40 por dia para US$ 10 por dia.
  • Fiquei curioso sobre qual provedor você usou.
    No OpenRouter, gastei US$ 40 bem rápido.
    Não houve muitas idas e vindas na conversa, o contexto era de cerca de 300 mil, e a saída, de umas 15 mil linhas.
    Eu estava usando opencode, mas não sei bem se dá para fazer ele mostrar o número total de tokens.
  • Estou curioso para saber se você comparou o Kilo com Pi ou OpenCode.
    Estou acostumado com os dois, mas sempre procuro alternativas.
  • Existe algum jeito de ver quantos tokens foram usados no Claude Code Pro?

• Isso é algo mais novo ou melhor do que a decodificação especulativa de 2022? https://arxiv.org/abs/2211.17192

  • Esse artigo é citado nas seções “introduction” e “background” deste artigo.
    Este artigo trata de melhorias ao remover alguns gargalos.
  • Parece que o foco é melhorar o modelo de rascunho e a política de verificação para que, na escala da DeepSeek, a especulação resulte em ganho puro de velocidade, e não em trabalho de verificação desperdiçado.

• O momento não parece coincidência.
  Parece uma forma de contrapor abertura a regulação pesada.

  • China = aberta, EUA = regulação pesada é uma linha do tempo estranha.
    Ainda assim, isso é possível porque está alinhado aos objetivos de Xi.
  • Ninguém obrigou a Anthropic a fazer uma ofensiva midiática exagerando os riscos de novos modelos de IA.
    Francamente, foi ela que procurou isso.

• O título é ruim.
  Não é o título do artigo; pegaram a primeira linha do resumo.
  A decodificação especulativa para inferência de LLMs já foi publicada em 2022: https://arxiv.org/abs/2211.17192

  Este artigo parece ser uma melhoria da decodificação especulativa, mas ainda não li.

• Pelo nome, achei inicialmente que tivesse relação com o DGX Spark.
  Por coincidência, recentemente houve bastante trabalho para melhorar o desempenho de inferência do DGX Spark e, com MTP, surgiram ganhos de velocidade de 50% a 100%, então o DSpark também parece bem útil para esse objetivo.

• Provavelmente isso já estava sendo usado em produção havia algum tempo, e deve ter sido um dos motivos pelos quais eles conseguiram reduzir bastante os preços um mês atrás.

  • Sim.
    A seção 5 trata da implantação real.
    A seção 5.1 diz “DSpark draft models are co-deployed with the preview versions of DeepSeek-V4-Flash and DeepSeek-V4-Pro”, e a 5.4 diz “MTP-1 represents the former production setup, having been superseded by DSpark two weeks following the DeepSeek-V4-preview release”.
  • Lookahead Sparse Attention também deve ter tido um papel importante,
    porque reduz bastante o uso de memória.
  • Boa observação.
    Eles reduziram o preço em 75%, o que parece bater exatamente com os ganhos de velocidade e de otimização de inferência.

• Acho que em breve viveremos em um mundo com uma variedade enorme de modelos pequenos para decodificação especulativa, específicos para cada caso de uso, empresa e até pessoa.

  • Tomara que sim, e espero que o hardware não se torne impossível de conseguir.

  • Sim.
    Isso virá fortemente restringido por guardrails sofisticados.

    Definitivamente estamos caminhando nessa direção.
    Modelos gigantescos que tentam devorar o mundo inteiro têm retornos extremamente decrescentes em comparação.

  • Claramente você não leu os artigos recentes sobre decodificação especulativa.
    Já faz um tempo que qualquer modelo pode ser usado para especular para outro modelo.
    O problema de tokenização que impedia isso no passado foi resolvido.