Pular para o conteúdo
← Voltar para o Skalablog

Artigo publicado

DGX Spark vs AMD: o que explica o ganho de 3,4x

Engenharia de Software

Uma GPU de 32 GB não consegue segurar um arquivo de modelo de quase 100 GB. Ainda assim, no confronto DGX Spark vs AMD, a caixa da AMD decodifica mais rápido. O truque não é mágica: num modelo MoE, só 4,6% dos pesos são usados por token, e eles cabem na memória rápida.

DGX Spark vs AMD: o que cada máquina oferece de hardware

O confronto é entre a NVIDIA DGX Spark, estação de trabalho compacta da NVIDIA com um único pool de memória a 273 GB/s, e o Lucebox Zero 495, uma workstation de startup que combina um APU AMD Ryzen AI Max+ com 128 GB de memória a 273 GB/s e uma placa AMD Radeon AI PRO R9700 com 32 GB a 640 GB/s.

A tabela resume o papel de cada peça, segundo os dados divulgados pelo próprio fabricante da caixa AMD.

ComponenteMemóriaLargura de bandaPapel no sistema
DGX Spark128 GB unificados273 GB/sPool único que guarda o arquivo inteiro
Ryzen AI Max+ 495128 GB273 GB/sGuarda os especialistas pouco escolhidos
Radeon AI PRO R970032 GB640 GB/sSegura caminho denso, especialistas quentes e cache
Interconexão entre os poolsnão divulgadaassumida lentaSó transporta tensores intermediários

Os dois pontos de partida são parecidos: a memória principal dos dois sistemas roda na mesma faixa de 273 GB/s. A diferença é que a caixa AMD adiciona um segundo pool rápido e um alocador que decide o que mora nele. O preço listado é de US$ 5.999 para o modelo de 128 GB, com entregas previstas para janeiro de 2027, sempre segundo o blog do fabricante.

Por que uma GPU de 32 GB acelera um modelo de ~98 GB

Uma GPU de 32 GB acelera esse modelo porque o DeepSeek V4 Flash é um modelo mistura de especialistas (MoE) que ativa só uma fração mínima dos pesos em cada token. A placa não precisa guardar o arquivo inteiro, apenas os blocos que quase todo token usa.

Segundo a ficha da DeepSeek, 13 bilhões dos 284 bilhões de pesos são ativados por token, cerca de 4,6%. A camada tem 256 especialistas roteados mais um compartilhado, e o roteador escolhe 6 dos 256 por token, ao longo de 43 camadas.

A intuição de que isso funciona vem de evidência anterior. O artigo Mixtral of Experts (2024) documentou que um especialista da última camada foi reutilizado 15 ou mais vezes numa mesma sequência, e que, após mais de 1.000 sequências, as contagens de reuso se equalizam. Ou seja: parte dos pesos é quente e previsível; a cauda longa é raramente tocada.

Fica então uma conta simples de teto. Se 13 bilhões de pesos ativos representam cerca de 4,5 GB de leitura por token, uma memória de 273 GB/s limita o decode perto de 60 tokens/s. Essa é uma estimativa calculada a partir dos números do fabricante, não uma medida publicada, e cache e mix de larguras de bits mudam o resultado.

Como funciona a alocação assimétrica de memória

A alocação assimétrica funciona fixando os pesos mais acessados na memória rápida da R9700 e deixando os especialistas frios na RAM lenta do APU, sem mover pesos pelo link. O design trata a banda do link como custo e evita que os dois lados fiquem ociosos.

O que mora na placa rápida

A R9700 de 32 GB recebe o caminho denso (atenção e especialista compartilhado, que rodam em todo token), os especialistas mais escolhidos, um modelo rascunho de 11,3 GB e o cache de trabalho. Isso já é quase um terço do arquivo de 98,29 GB ocupado antes dos especialistas quentes.

Nenhum peso cruza a conexão. Em cada fronteira de camada passa um tensor de estado de 4 × 4.096 números, cerca de 64 KB por token assumindo float de 32 bits. São gigabytes de leitura local contra quilobytes trafegados, e é por isso que um link lento não vira gargalo.

Como o alocador decide

O alocador adiciona o próximo especialista quente à R9700 somente se isso reduzir o tempo do ramal mais lento dos dois. Como a placa lê memória cerca de 2,3 vezes mais rápido (640 dividido por 273), um corte em partes iguais deixaria a GPU esperando. A divisão é desigual de propósito: os especialistas da placa são poucos, mas capturam uma parcela de escolhas acima de um terço.

Os números do benchmark e por que o 3,4x não é só hardware

O 3,4x não mede só hardware: ele compara quantizações, softwares e técnicas de decodificação diferentes em cada lado. Todos os números de throughput publicados vêm da equipe do próprio fabricante; nenhum revisor independente testou a máquina de produção.

As três medições do fabricante

O blog do fabricante rodou um teste de serviço com prompt de 2K tokens e 128 de saída, dois aquecimentos, três medições e temperatura zero. A mediana foi 51,1 tokens/s contra 14,09 na DGX Spark, um fator de 3,63. Num varredura de contexto casada em 2K, 4K, 8K e 16K, os ganhos variaram de 3,09 a 3,60. O README ainda lista 86 tokens/s a 2K, um terceiro número que usa speculative decoding e não pareia com as outras medições.

O que difere entre os lados

A Spark rodou uma build comprimida em Q2; o Zero 495 rodou uma quantização própria em formato ROCmFPX, com especialistas em 2 a 3 bits e pesos sempre ativos em 4 bits. O lado da AMD também usou speculative decoding com aceitação reportada de 0,97, o que permite checar vários tokens chutados por única leitura de pesos. O relato de imprensa de média de 47,75 contra 14,09 (3,39x) mistura esses testes distintos.

O baseline da Spark pode estar subestimado

Um repositório comunitário datado de 21 de agosto de 2026 mediu 44 a 47 tokens/s numa única Spark usando um checkpoint de 3 bits que descarta 40 dos 256 especialistas por camada. O setup não é comparável ao do fabricante, mas sugere que os 14,09 refletem a build Q2 e seu software, não um teto físico do hardware da NVIDIA.

Há também uma inconsistência não resolvida: o README lista 42 tokens/s só no chip Ryzen a 8K de contexto, enquanto a página do modelo no Hugging Face lista 18,1 a 22,3 tokens/s para a mesma build nesse chip. As fontes não explicam a diferença, então o tamanho real do ganho trazido pela placa extra segue incerto.

Limitações do método e do comparativo

O método tem limites claros e o comparativo, lacunas. Modelos densos se beneficiam pouco, porque usam todos os pesos em todo token e não têm especialistas frios para deixar na memória lenta. Nenhum teste público avaliou um modelo denso nessa caixa.

Do lado do software, especialistas em formatos adaptativos não podem ser divididos entre os dois pools; só arquivos de quantização de codebook fixo suportam o split. O guia do fabricante também documenta que page concurrency não roda junto com modelos rascunho e alguns outros recursos.

A cobertura da imprensa segue o mesmo viés. O número de 1.077 tokens/s da Spark em processamento de prompt é relato de segunda mão e não verificado; os 788 tokens/s do README são decode a 2K. A manchete fala de velocidade de geração de resposta, não de leitura de prompt longo.

E o preço da comparação mudou no caminho. O blog testou uma Spark de 128 GB a US$ 4.699, valor anterior; relatos recentes citam US$ 6.950 para esse modelo e uma nova Spark de 64 GB a US$ 4.999, que nem consegue carregar o arquivo de 98 GB. Trate o 3,4x como alegação do fabricante até existir revisão independente com a mesma quantização nos dois lados.

Como replicar a ideia no seu PC com llama.cpp

Você replica a essência da ideia com o llama.cpp, sem segunda placa nem perfilamento: manter atenção e especialista compartilhado na GPU e empurrar os especialistas roteados para a RAM do sistema. A lógica é a mesma, escolher os pesos em memória mais rápida.

  1. Rode llama server com o seu modelo MoE.
  2. Adicione a flag -ngl 999 para colocar todas as camadas na GPU.
  3. Adicione --n-cpu-moe N, definindo quantas camadas mantêm seus especialistas na RAM do sistema.
  4. Ajuste o número observando sua VRAM livre e os tokens por segundo.

A versão caseira difere em dois pontos: a CPU calcula os especialistas na RAM, onde o Zero 495 usa uma segunda GPU; e a divisão é por camada, onde o fabricante usa perfil de quentura medido no seu workload. Nenhuma fonte pública dá ganho numérico para esse arranjo doméstico, então meça seus tokens por segundo antes e depois da mudança.

FAQ

  • A DGX Spark é mais lenta que o Lucebox Zero 495 em tudo? Não. O comparativo cobre decodificação de um modelo MoE específico. No processamento de prompt, um relato de segunda mão indica que a Spark lê prompts mais rápido, cerca de 1.077 tokens/s, mas esse número não foi verificado.
  • Por que os 32 GB da placa bastam se o modelo tem ~98 GB? Porque em um modelo mistura de especialistas apenas 4,6% dos pesos são ativados por token. A placa guarda o caminho denso e os especialistas mais escolhidos; a cauda longa fica na RAM lenta e nunca atravessa o link.
  • O ganho de 3,4x foi medido por alguém independente? Não. Todos os números de throughput do Zero 495 vêm da equipe de testes do fabricante, e a primeira unidade de produção só deve ser enviada em janeiro de 2027. Até lá, trate o fator como alegação do fabricante.
  • Comprar agora ou esperar? Se a compra depende do número de 3,4x, esperar por uma revisão independente é a escolha prudente. Se você já tem um PC com GPU, o guia do llama.cpp permite testar a ideia de colocação de especialistas sem gastar nada.

Source video