Manual do DGX Spark

Autor: @0xSero

Revisores: @alexocheema e @alexzfunk

Agradecimentos especiais a: @MiaAI_lab

Se você está pensando em rodar inferência localmente, com certeza vai acabar conhecendo esse tijolinho de ouro. É uma máquina feita para servir IA localmente, projetada para ser pequena, limpa, silenciosa e relativamente barata (página do DGX Spark da NVIDIA).

Quando ouvi falar do DGX Spark pela primeira vez, não curti muito. Apesar dos 128 GB de memória, a largura de banda de 273 GB/s parecia baixa demais. Para ter uma ideia, uma RTX 5090 tem cerca de 6,5x mais largura de banda (1.792 GB/s), mesmo tendo apenas 32 GB de VRAM.

Quando o Spark foi lançado, práticas de engenharia de inferência como decodificação especulativa ainda não eram tão populares, e a maioria dos modelos pequenos não era tão capaz assim.

Conforme a indústria de IA avança e cresce, a inteligência está sendo comprimida em tamanhos cada vez menores, o que permite que essas caixinhas sejam usadas em todo o seu potencial.

1. A engenharia de inferência está em alta demanda.
2. Os LLMs estão ficando mais competentes em engenharia de inferência.
3. Inferência de alta qualidade melhora o sistema.

Agora, o DGX Spark consegue rodar modelos superinteligentes no mesmo nível de velocidade dos serviços na nuvem, tudo no conforto da sua casa ou escritório. Existe uma infinidade de softwares de IA que podem te ajudar a programar, declarar impostos, estudar ou só te entreter.

Por velocidade, quero dizer os tokens por segundo que uma única pessoa vê. O hardware na nuvem é bem mais rápido, mas os provedores dividem ele entre vários usuários e otimizam o custo por token, então cada um recebe uma fatia menor. Em casa, a máquina é toda sua, então tudo vai para você. Mais detalhes nas notas avançadas.

Sparks foram feitos para serem conectados

Os DGX Sparks consomem pouquíssima energia. Eles costumam ficar na faixa dos 95 W com um modelo carregado e servindo requisições.

Por causa disso, não exigem muita refrigeração e são bem mais silenciosos que GPUs dedicadas. Você pode empilhar de 2 a 4 deles em um circuito elétrico americano padrão sem medo nenhum. E esse é justamente o ponto, não a eficiência bruta: por unidade de velocidade de memória, uma B300 de data center faz aproximadamente o dobro do trabalho por joule (veja as notas avançadas). O Spark é só plugar numa tomada comum.

Todo Spark tem uma placa de rede ConnectX-7 com duas portas QSFP, avaliadas em 200 Gb/s, ou 25 GB/s. Isso permite que você conecte os Sparks entre si para aumentar a memória e a largura de banda efetiva.

Como os DGX Sparks se conectam

Com o paralelismo de tensores, cada matriz de pesos é dividida entre os Sparks, e cada um lê apenas a sua parte, da sua própria memória, ao mesmo tempo que os outros. Assim, a velocidade de leitura se soma (teste de escalabilidade da própria NVIDIA):

• 546 GB/s para dois Sparks
• 819 GB/s para três
• 1.092 GB/s para quatro

Isso escala de forma quase linear. No teste da própria NVIDIA, a escrita ficou 2x mais rápida com dois Sparks e 3,7x mais rápida com quatro (tabela 3). Funciona tão bem porque o link ConnectX-7 tem latência baixíssima, e o CUDA consegue mover dados entre os Sparks de dentro do próprio código da GPU (mais sobre o porquê).

A memória se soma do mesmo jeito: 128 GB cada, 512 GB para quatro, com cerca de 120 GB por Spark efetivamente utilizáveis para cargas de trabalho de IA.

A possibilidade de empilhar Sparks resolve o maior problema dele: a largura de banda de memória mais baixa. O baixo consumo de energia numa tomada comum o torna incrível para um único usuário ou uma casa pequena.

DGX Spark conectado na vida real

Dense vs MoE

Hoje existem duas arquiteturas principais de modelos: esparsa e densa. Modelos Mixture-of-Experts (MoE) como o Qwen3.6-35B ativam apenas 3B de parâmetros por token gerado, 9x menos que o Qwen3.8-27B.

Isso torna os LLMs esparsos especialmente adequados para o DGX Spark. Eles combinam perfeitamente com a largura de banda de memória menor, entregando uma experiência rápida para o usuário apesar do tamanho total do modelo.

O MoE não é bom só para o DGX Spark. É uma arquitetura melhor até nos data centers. O que mudou para o uso local foi um limite: esperamos uma certa velocidade, e os modelos densos inteligentes o suficiente eram grandes demais para rodar nessa velocidade em casa. Os modelos MoE cruzaram essa linha, então agora são úteis e rápidos em hardware local. Os modelos densos podem chegar lá eventualmente também.

LLMs densos vs MoEs

Decodificação Especulativa

Qualquer LLM com MTP, DSpark ou DFlash vai se encaixar melhor, já que os modelos rascunho costumam ser minúsculos e não exigem muito poder de processamento para gerar um token correto.

Isso melhora significativamente o throughput que os Sparks conseguem entregar, custando apenas 1 a 2 GB de memória — algo que o Spark tem de sobra.

Assim como o MoE, a decodificação especulativa ajuda em qualquer lugar, não só em casa. Mas juntas, foram elas que empurraram a IA local para além desse limite. Antes, os melhores modelos abertos rodavam dolorosamente devagar em hardware doméstico.

Como a decodificação especulativa melhora o throughput

Vários agentes ao mesmo tempo

Um único Spark consegue atender oito ou mais requisições juntas, cada uma ainda na velocidade de uma conversa. Por exemplo, o Qwen3.6-35B, que dá conta de programação básica, uso de computador e navegador, edição de vídeo e imagem e suporte geral, pode servir até 8 sessões simultâneas, cada uma a cerca de 40 tok/s.

Para referência, na assinatura ChatGPT Pro, o GPT-6-Astra roda a uma velocidade média de 37 tok/s.

Velocidades médias do Astra

Isso funciona porque o Spark tem muito poder de processamento para a sua velocidade de memória. Servir oito pessoas ainda significa ler o modelo uma vez por etapa, mas fazendo oito vezes mais cálculos, e o Spark tem cálculo de sobra. Em 16 bits, ele entrega cerca de 100 TFLOPS para 273 GB/s, aproximadamente 370 operações por byte de memória lido. Um M3 Ultra tem cerca de 26 TFLOPS para 819 GB/s, aproximadamente 32 (números da EXO). Isso é cerca de 11x mais processamento por byte, antes mesmo de contar o hardware de 4 bits do Spark, que os Macs não têm.

Trabalho de verdade

O Qwen3.6-35B em um único Spark criou um vídeo que bateu mais de 80 mil visualizações em um dia. Levou apenas 3 minutos: ele pegou uma pasta com 3 vídeos, juntou tudo e acelerou o resultado em 4x, mantendo a taxa de quadros abaixo do limite do X.

https://x.com/0xSero/status/2072206209323802746

Custos

O DGX Spark foi lançado por US$ 3.999, e esse valor subiu para US$ 4.699. Os preços de todo tipo de hardware subiram em 2026.

O preço real é ainda maior. A loja oficial da NVIDIA está sem estoque. O mais barato que consigo achar custa uns US$ 5.000, os usados saem por cerca de US$ 6.000, e no dia 21 de setembro eu vi o site da NVIDIA pedindo US$ 7.999 pela mesma máquina pela qual paguei US$ 4.699 cinco semanas antes.

Preços do GX10

Marketplace da NVIDIA em 21 de setembro. Post

US$ 4.000 - US$ 4.700

Dicas de compra

• Qualquer máquina com GB10 serve. ASUS, Dell, MSI e outras vendem suas próprias versões do mesmo chip. Elas rodam o mesmo software e as mesmas receitas. Fique de olho no tamanho do SSD: 1 TB enche rápido quando você começa a guardar alguns modelos grandes. Eu iria de 4 TB.
• Compre o cabo junto com o segundo Spark, você vai precisar dele para conectar os dois.
• Alguns fabricantes oferecem Sparks com fluxo de ar melhor

Energia, barulho e sua conta de luz

O barulho e o calor que as GPUs dedicadas geram não são brincadeira; com 4x 3090 você facilmente consumiria 1.600-2.000 W para 1/5 da memória. Tive que tirar minha torre com RTX Pro 6000 do escritório porque ela vivia cozinhando o ambiente a 35 °C.

Um circuito residencial comum nos EUA aguenta rodar com segurança cerca de 1.440 watts o dia inteiro (código elétrico dos EUA). Qualquer coisa acima disso exige um circuito novo, o que significa chamar um eletricista.

• Um Spark rodando um modelo consome cerca de 90-200 watts (ServeTheHome). Isso dá uns US$ 12 por mês se você deixar ligado 24 horas por dia.
• Quatro Sparks consomem cerca de 500 watts juntos, mais um switch usando uns 240 W. Cerca de US$ 66-100 por mês, e todos cabem numa única tomada.
• Meu setup com quatro GPUs chega a picos de 1.600 watts. Isso é mais do que um único circuito suporta, e dá uns US$ 300 por mês.

De onde vêm esses números. Cada valor é um tipo diferente de medição, então aqui estão lado a lado. O custo mensal considera a máquina rodando naquele consumo 24 horas por dia, a 18 centavos de dólar por kWh:

Meus testes

Por que quatro Sparks usam mais do que quatro vezes 90 W. O valor de 90 W é de um Spark servindo um modelo sozinho. Quando um modelo grande é dividido entre quatro, cada Spark trabalha em cada palavra e mantém seu link de rede ocupado, então cada um puxa mais energia, cerca de 125 W em média na minha medição. Portanto, US$ 12 e US$ 66 por mês são os custos de rodar no talo 24 horas por dia. O uso real, com tempo ocioso, sai mais barato.

A energia elétrica também não está ficando mais barata. Os preços residenciais nos EUA subiram cerca de 5% este ano, para algo em torno de 18 centavos por kWh, em parte por causa de todos os novos data centers. Em agosto, minha própria conta dobrou para US$ 1.000 por mês, com o setup de GPUs, dois Sparks e quatro aparelhos de ar-condicionado ligados.

Barulho do DGX Spark

E o barulho? Meu setup de GPUs soa como a turbina de um avião. Esse é o máximo de ruído que meus quatro Sparks fazem:

Algumas observações práticas:

• Use-os com todo tipo de modelo de IA, world models, geração de imagens etc.
• Deixe-os deitados de lado. Os meus rodam mais frios assim, com espaço ao redor da grade.
• Entre em comunidades no Discord/Reddit/X para conseguir ajuda com debugging
• Configure o Tailscale em todo o seu parque de máquinas

Os seis modelos que eu realmente rodo

Já testei dezenas. Estes são os seis aos quais sempre volto.

Um token equivale a cerca de três quartos de uma palavra, e qualquer coisa acima de 30 parece uma conversa normal.

Por que cada número indica uma tarefa. A maioria dessas receitas usa decodificação especulativa, onde um modelo auxiliar pequeno tenta adivinhar o que vem pela frente. Código e JSON são fáceis de adivinhar, texto corrido não, então o mesmo modelo na mesma máquina pode rodar duas vezes mais rápido em um do que no outro. Prompts mais longos também deixam tudo mais lento. Por isso, cada velocidade aqui diz o que estava sendo escrito e qual era o tamanho do prompt:

Uma forma adequada de medir isso em várias tarefas é o SPEED-Bench da NVIDIA, que testa a decodificação especulativa em prompts reais de 11 categorias e comprimentos de entrada de 1K a 32K tokens. Ainda não rodei ele nos Sparks.

• Um Spark: Qwen3.6-35B, Qwen3.8-Flash-Next, Qwen3.8-27B
• Dois Sparks: GLM-5.3-Flash.
• Quatro Sparks: DeepSeek-V4.1-Flash.

Qwen3.8-Flash-Next em dois Sparks criando animações e um joguinho. (21 de setembro) Post

Onde encontrá-los. Cada modelo tem uma página oficial, e a seção 6 traz uma receita testada no Spark para cada um:

• Qwen3.6-35B, ou a versão de 4 bits da NVIDIA
• Qwen3.8-27B
• Qwen3.8-Flash-Next
• GLM-5.3-Flash, ou a minha versão para um Spark
• DeepSeek-V4.1-Flash
• GLM-5.3, ou a minha versão de 3 bits

Como modelos tão grandes sequer cabem

A resposta é quantização. A quantização comprime os pesos de um modelo, e o processo tem perdas: cada peso é armazenado com menos bits (digamos 4 em vez de 16), então o modelo encolhe para um quarto do tamanho, mas alguns detalhes se perdem. O objetivo é chegar o mais perto possível do comportamento do modelo original enquanto se comprimem os pesos.

Quanto mais você comprime, pior fica a qualidade. Turboderp mediu isso para o Qwen3.8-27B. Cada ponto é uma versão comprimida. Mais à esquerda é menor, mais abaixo é mais próximo do original:

Divergência KL média versus tamanho em disco para versões comprimidas do Qwen3.6-35B-A3B, de vários provedores. Escala logarítmica. Gráfico: https://huggingface.co/turboderp/Qwen3.8-27B-exl3

Dois formatos importam no Spark:

• NVFP4 é o formato de 4 bits da NVIDIA, e o chip do Spark o lê diretamente. O Qwen3.6-35B cai de 72 GB para 24 GB e cabe em um único Spark com espaço de sobra.
• EXL3 permite escolher exatamente quantos bits usar. O GLM-5.3-Flash em 4 bits tem 176 GB e cabe em dois Sparks. Em 2 bits, fica com 85 GB e cabe em um, embora perca um pouco de precisão.

Dica:

4 bits é o ponto ideal para modelos menores, 3 bits para modelos maiores

Como saber se um modelo comprimido ainda é bom. Bons model cards informam o quão próxima a versão reduzida permanece do original. Dois números para procurar:

• Concordância Top-1: com que frequência o modelo pequeno escolhe a mesma próxima palavra que o original. Quanto maior, melhor. Meu GLM-5.3-Flash para um Spark concorda cerca de 80% das vezes.
• Divergência KL: o quanto os palpites dele se afastam do original. Quanto menor, melhor. Meu GLM-5.3 não podado em 3 bits marca 0,089. A versão podada de 197 GB marca 0,511. Esse é o preço de caber em menos Sparks.

6. De um a quatro Sparks: um passo a passo

Essa é a parte sobre a qual mais me perguntam. Vá um passo de cada vez. Cada etapa funciona por conta própria, então pare onde estiver satisfeito.

A maioria das receitas abaixo vem do MiaAI Lab, que empacota as melhores configurações para Spark em repositórios que você pode clonar e iniciar com um único script. Algumas são minhas. Todas listam onde foram testadas e a velocidade alcançada.

Faça isso uma vez, em cada Spark:

1. Atualize-o. Rode as atualizações no DGX Dashboard e reinicie.
2. Acesse-o pelo seu notebook. Use o NVIDIA Sync ou SSH puro. Para acessar de fora de casa, a NVIDIA tem um playbook do Tailscale.
3. Crie uma conta e um token no Hugging Face. A maioria das receitas baixa modelos com ele. Coloque num arquivo .env, nunca direto no repositório.
4. Verifique o disco. Modelos são pesados. Uma receita para um Spark precisa de cerca de 25 a 130 GB livres. A receita do DeepSeek para quatro Sparks precisa de uns 476 GB livres no primeiro Spark.
5. O Docker já vem instalado. O DGX OS já inclui ele, e quase toda receita roda dentro dele, então você não precisa instalar pacotes Python manualmente.

Passo 1: um Spark

Comece pelo LM Studio. Siga o guia passo a passo da NVIDIA, baixe o Qwen3.6-35B e comece a conversar. Leva cerca de uma hora. Isso te garante que a máquina funciona antes de mexer em algo mais complexo.

Depois, vá para uma receita. Receitas usam vLLM ou SGLang, que são mais rápidos que o LM Studio e atendem vários agentes ao mesmo tempo. Escolha uma:

1. Qwen3.6-35B (NVFP4 de 4 bits) MiaAI Lab 95 tok/s para um usuário, 317 no total para oito ~50 GB
2. Qwen3.8-27B (NVFP4 de 4 bits) MiaAI Lab ~51 tok/s em código com o auxiliar DSpark, ~23 em chat ~24 GB
3. Qwen3.8-Flash-Next (NVFP4 de 4 bits) MiaAI Lab 48,7 tok/s para um usuário, 162,9 no total para oito ~130 GB
4. GLM-5.3-Flash (EXL3 de 2 bits) minha versão, ou a versão para um Spark da receita da Mia 10 a 25 tok/s, contexto de 262K, visão ~85 GB

A primeira é a mais fácil. São três linhas:

1git clone <https://github.com/MiaAI-Lab/Unsloth-Qwen3.6-35b-NVFP4-DGX-Spark.git>
2cd Unsloth-Qwen3.6-35b-NVFP4-DGX-Spark
3./start.sh

Quando subir, você terá um endereço no estilo OpenAI no Spark. Aponte o Pi, opencode, Open WebUI ou qualquer ferramenta que você use para ele.

Dica:

se um modelo não iniciar, quase sempre é falta de memória. Feche os outros modelos primeiro. Um Spark roda um modelo grande por vez.

Passo 2: dois Sparks

Esse é o setup que eu mais recomendo. Como eu disse em agosto: "2 DGX Sparks e você está pronto."

2 dgx sparks

O cabo. Você precisa de um cabo QSFP curto entre as duas portas QSFP. Qualquer um destes serve (guia de cabos):

• O da própria NVIDIA: Cabo QSFP 0,4 m para DGX Spark, US$ 99,99. Vive esgotado.
• Os citados na documentação da NVIDIA: Amphenol NJAAKK-N911 ou Luxshare LMTQF022-SD-R, 0,5 m, cerca de US$ 159 a US$ 187.
• Uma opção 200G mais barata: NVIDIA MCP1650-V00AE30, cerca de US$ 84.

O link roda a 200 Gb/s independentemente de qual você comprar. Não use USB-C nem a porta 10 GbE para isso. São lentas demais.

Configure o link. Siga o playbook para conectar dois Sparks da NVIDIA. Ele atribui um endereço a cada porta e verifica a velocidade. Depois, configure o SSH sem senha do primeiro Spark (o "head") para o segundo (o "worker"). Toda receita para dois Sparks exige isso.

Recomendo pedir para o Claude ou o GPT configurar isso para você, é mais fácil.

Escolha uma receita:

1. Qwen3.8-Flash-Next (NVFP4 de 4 bits) MiaAI Lab 52,1 tok/s para um usuário com MTP, até 1M de contexto
2. GLM-5.3-Flash (EXL3 de 4 bits) MiaAI Lab 62,9 tok/s para um usuário, 146,5 no total para quatro, contexto de 850K
3. DeepSeek-V4.1-Flash (EXL3 de 2,9 bits) MiaAI Lab 38,8 a 43,0 tok/s em código, contexto de 600K
4. GLM-5.3 (EXL3 de 3 bits, podado para 197 GB) meu model card cabe; velocidade ainda não medida

A maioria das receitas para dois Sparks é parecida: copie as configurações de exemplo, coloque os endereços dos dois Sparks, baixe e inicie. Esta é a do GLM-5.3-Flash:

1cp .env.example .env     # defina HEAD_IP e WORKER_IP
2./download.sh
3./start.sh

Atenção:

conectar os Sparks funciona, mas é onde o software é menos polido. Siga uma receita testada e reserve uma tarde inteira para a primeira vez.

Passo 3: três Sparks

Três Sparks não precisam de switch. Cada Spark tem duas portas QSFP, então você os conecta em triângulo: A em B, B em C, C em A. São três cabos. A NVIDIA suporta isso como um anel sem switch.

Três Sparks te dão cerca de 384 GB. Isso é suficiente para coisas que dois não comportam:

• DeepSeek-V4.1-Flash na sua precisão nativa. A receita do MiaAI Lab roda ele num triângulo de três Sparks a 51,0 tok/s para um usuário, com contexto de 256K. Tem um comando doctor que verifica SSH, Docker e os links de rede antes de começar.
• GLM-5.3-Flash com mais espaço. A receita EXL3 para dois Sparks tem um start-tp3.sh para três.
• GLM-5.3, não podado. Minha versão de 293 GB precisa de memória equivalente a uns três Sparks.

A receita do DeepSeek é um bom exemplo de como as maiores funcionam. São algumas etapas, não só uma:

1./start.sh doctor    # verifica ssh, docker, links, disco
2./start.sh share     # compartilha a pasta do modelo com os outros Sparks
3./start.sh serve     # inicia os workers e depois o head

Dica:

alguns modelos só dividem de forma uniforme por 2 ou 4. Verifique se a receita diz "3x" antes de comprar o terceiro.

Passo 4: quatro Sparks

Quatro Sparks te dão cerca de 512 GB. Existem duas formas de conectá-los.

Opção A: um switch (o que eu uso). Cada Spark recebe um cabo ligado a um switch 200 GbE, então cada um fica a apenas um salto de todos os outros. A NVIDIA tem um playbook para isso. Os switches que o pessoal usa:

• MikroTik CRS812-8DS-2DQ-2DDQ-RM. Suas portas 400G se dividem em dois links de 200G cada.
• MikroTik CRS804-4DDQ-hRM. Uma opção menor (notas de build para quatro Sparks).
• A Exxact tem uma boa lista de compras para um cluster de quatro Sparks: switch, cabos e energia.

Como eu disse em setembro: "Acho que não existe negócio melhor no mercado do que 4x Sparks com um switch MikroTik."

Opção B: sem switch. Conecte os quatro em anel, cada Spark ligado aos seus dois vizinhos. Os Sparks que não são vizinhos se comunicam através do que está no meio. Economiza o switch, mas é mais difícil de configurar:

• O SparkRing é uma stack de software completa para pares sem switch e anéis com quatro Sparks. Ainda está em fase alfa, então fixe uma versão específica.
• Esta receita do GLM-5.3-Flash roda em um anel de quatro Sparks usando quatro cabos curtos de 100G e um NCCL com patch. Cerca de 45 tok/s no uso normal, chegando a uns 100 quando o sistema já está aquecido.

Escolha uma receita:

• DeepSeek-V4.1-Flash (nativo) MiaAI Lab, start-tp4.sh 45,4 tok/s para um usuário, 134,2 no total para dezesseis, contexto de 1M
• GLM-5.3-Flash (NVFP4 de 4 bits) anel sem switch ~45 tok/s no uso normal, ~100 aquecido

Meus melhores resultados pessoais com quatro unidades foram 118 tok/s para o GLM-5.3-Flash usando um auxiliar DFlash2, e de 83,8 a 95,3 tok/s para o DeepSeek-V4.1-Flash em prompts curtos (post).

Ferramentas que ajudam em cada etapa

• \\sparkDash:\\ um painel web para monitorar todos os seus Sparks em uma única janela. GPU, memória, rede e tokens por segundo em tempo real. Várias das velocidades deste guia foram medidas com ele.
• \\Playbooks do Spark da NVIDIA:\\ guias oficiais para LM Studio, Ollama, vLLM, conexão de Sparks e muito mais.
• \\local-ai-registry:\\ minhas receitas e todos os testes de velocidade que já fiz.
• \\b12x:\\ a matemática rápida por trás de muitas receitas para Spark. Você não instala manualmente; as próprias receitas fazem isso. Veja as notas avançadas abaixo.

Conclusão

O Spark é uma caixa de memória. Ele acomoda modelos grandes, roda silenciosamente na tomada de casa e fica melhor cada vez que você adiciona mais um.

Se você está começando hoje:

1. Compre um e rode o Qwen3.6-35B pelo LM Studio logo no primeiro dia.
2. Passe para uma receita assim que quiser mais velocidade ou rodar vários agentes.
3. Compre o segundo Spark e o cabo quando quiser usar o GLM-5.3-Flash ou o DeepSeek-V4.1-Flash. Para a maioria das pessoas, é aqui que se deve parar.
4. Vá para três ou quatro apenas se quiser os maiores modelos ou rodar vários ao mesmo tempo.

Eu compraria de novo? Sim. E se fosse começar do zero, compraria dois logo no primeiro dia.

Avançado: como a conexão de Sparks escala

Você não precisa disso para usar um Spark. É para quando quiser entender por que os números são o que são.

Quase linear, na hora de gerar texto

Cada palavra que o modelo gera exige ler os pesos ativos dele na memória. Divida o modelo entre vários Sparks e cada um lê sua parte ao mesmo tempo, então as velocidades de leitura se somam.

A NVIDIA mediu isso. Passando de um para dois e depois para quatro Sparks, o tempo para gerar cada palavra caiu de 269 ms para 133 ms e depois para 72 ms. Isso representa 2,0x com dois e 3,7x com quatro (blog da NVIDIA, tabela 3).

Chega tão perto da linearidade porque o link ConnectX-7 tem latência baixíssima, e as trocas de dados entre os Sparks podem acontecer dentro do próprio código da GPU. Esta explicação para Macs detalha melhor essa mesma ideia.

Após cada camada, os Sparks trocam seus resultados parciais antes que a próxima camada possa começar. A troca é pequena, mas acontece em todas as camadas e para cada palavra. Cada uma custa um pouco de tempo que não diminui quando você adiciona mais Sparks.

• O link é de 200 Gb/s, cerca de 25 GB/s. Isso é um décimo da velocidade de memória do próprio Spark. Não há problema porque as trocas são pequenas.
• Ele usa RDMA. Os dados vão direto da memória de um Spark para a do outro, sem a CPU precisar copiá-los. Cada porta QSFP aparece como duas metades de 100 Gb/s, e o software precisa usar ambas para atingir os 200 completos (detalhes). O NCCL, biblioteca da NVIDIA para isso, cuida dessa parte.
• A leitura escala menos que a geração de texto. No mesmo teste da NVIDIA, ler um prompt de 32K tokens ficou 1,6x mais rápido com dois Sparks e 2,1x com quatro. A leitura movimenta muito mais dados entre os Sparks a cada passo.
• Anéis adicionam saltos. Em um triângulo de três Sparks, cada unidade é conectada por cabo às outras duas. Em um anel de quatro Sparks, alguns pares se comunicam passando por um vizinho. Um switch deixa todo mundo a apenas um salto de distância. O SparkRing escreve seu próprio código de troca (SIRCL) para tornar os anéis mais rápidos.
• Modelos mixture-of-experts adicionam uma segunda divisão. As receitas costumam combinar paralelismo de tensores com "paralelismo de especialistas", onde Sparks diferentes guardam especialistas diferentes.

As outras duas formas de ganhar velocidade

• Vários usuários ao mesmo tempo. O Spark lê o modelo uma vez por passo e responde a todo mundo a partir dessa única leitura. Por isso, a velocidade total sobe muito mais rápido que a velocidade para um único usuário.
• Um modelo decodificador especulativo que adianta o trabalho. MTP, DSpark e DFlash2 fazem isso. Um auxiliar pequeno e rápido rascunha várias palavras, e o modelo grande verifica todas de uma vez só. Quando os palpites estão certos, você ganha várias palavras pelo preço de uma. É assim que o GLM-5.3-Flash salta de 27 tok/s em textos corridos para 65 em saídas estruturadas na mesma receita.

Qwen3.6-35B-A3B a 4 bits em um único Spark, com auxiliar de aceleração ativado. Fonte: teste de velocidade do local-ai-registry, agosto de 2026.

IA na nuvem e IA local são coisas diferentes

Uma GPU na nuvem é bem mais rápida que um Spark. Mas os provedores dividem cada GPU entre muitos usuários e escolhem um ponto de equilíbrio entre custo por token e velocidade por usuário. A maioria prioriza o custo, então cada usuário recebe menos tokens por segundo do que o hardware poderia entregar para uma só pessoa. O InferenceX mapeia esse equilíbrio para o Qwen3.8-Flash-Next.

Em casa, esse dilema não existe. A máquina é sua, então você pode dedicar toda a capacidade dela a uma única pessoa. É por isso que um Spark pode parecer tão rápido quanto um serviço na nuvem, mesmo que o hardware em si não seja.

sm_121: por que o software do Spark é um mundo à parte

Toda GPU da NVIDIA tem um número de "capacidade de computação" que diz ao software quais instruções ela possui. A GPU do Spark é 12.1, ou sm_121 (primeiras impressões de Simon Willison). A RTX 5090 e a RTX PRO 6000 são sm_120, primas bem próximas. Já os chips de data center da NVIDIA, B200 e B300, são sm_100 e sm_103, uma família diferente.

Isso importa porque o código de IA mais rápido é escrito para uma família de cada vez. Quando o Spark foi lançado, boa parte dele simplesmente não rodava ou rodava devagar (fórum da NVIDIA, issue no vLLM).

A solução tem sido a comunidade escrevendo código específico para o Spark:

• b12x, do Local Inference Lab, é uma biblioteca de kernels para sm_120 e sm_121: o DGX Spark, o RTX Spark, a RTX 5090 e a RTX PRO 6000. Ela cobre operações matriciais de 4 bits (NVFP4, MXFP4), atenção para modelos estilo DeepSeek, camadas mixture-of-experts e um carregador de modelos rápido. Instala com pip install b12x, e as receitas do vLLM ativam com flags como flashinfer_b12x. A receita do Qwen3.6-35B usa essa biblioteca.
• SparkInfer é o nome antigo do b12x. O link antigo agora redireciona para o b12x. Minha receita de DeepSeek para um Spark usa o código de atenção dele tanto para leitura quanto para geração. Não confunda com o sparkinfer do gittensor, um runtime separado para placas RTX (apenas sm_120).
• ExLlamaV3 é o que roda os modelos EXL3. O MiaAI Lab mantém um fork com o port para Arm (GB10) e suporte a modelos auxiliares.
• lil é o launcher do Local Inference Lab. Ele lê a configuração da máquina e monta o comando certo do vLLM para um Spark ou para um grupo conectado.

Avançado: o Spark como máquina de pesquisa

Essa foi a parte que eu não esperava. O Spark é lento para gerar texto, mas é excelente para leitura. E a maior parte do trabalho de pesquisa com modelos é justamente leitura.

O que o Spark faz de melhor: prefill

Um modelo executa duas tarefas diferentes:

• Prefill é a leitura do seu prompt. O prompt inteiro passa de uma vez, então o limite é o poder bruto de processamento. O GB10 tem de sobra: até 1 petaflop em cálculos de 4 bits.
• Decode é a geração da resposta, uma palavra por vez. Cada palavra exige ler o modelo na memória de novo, então o limite é a velocidade da memória. E esse é o ponto fraco do Spark.

Por isso, um Spark lê prompts de 13 a 41 vezes mais rápido do que gera texto:

DeepSeek-V4.1-Flash em quatro Sparks: 3.360 tok/s lendo um prompt de 32K tokens, 3.273 em 131K, enquanto a geração fica entre 70 e 95. (20 de setembro) Post

Por que isso é exatamente o que a pesquisa precisa

Quase tudo o que faço para reduzir modelos é leitura, não geração:

• Quantização (menos bits). Versões EXL3 e NVFP4 são criadas rodando textos de amostra pelo modelo e medindo o quanto cada camada perde em cada largura de bits. Isso é leitura.
• Pruning (menos especialistas). O REAP roda textos de amostra por um modelo mixture-of-experts e registra o quanto cada especialista é usado. Os menos úteis são cortados. Meu GLM-5.3 de 197 GB mantém 168 dos 256 especialistas. Também é leitura.
• Verificação de qualidade. Concordância top-1 e divergência KL vêm de ler o mesmo texto no modelo original e no reduzido e comparar os resultados. Leitura de novo.
• Testes de contexto longo. Confirmar se um modelo consegue achar um fato em 262.000 tokens é basicamente uma leitura muito longa.

Meu próprio fluxo de trabalho mudou exatamente por esse motivo. "Estou rodando todo o meu pruning/exl3/benchmarking nos DGX Sparks agora, deixo as 6000 para inferência. É mais lento, mas 2-3 dias contra 12h está ótimo." O DeepSeek para um Spark que passou de 100.000 downloads é um modelo podado com REAP e comprimido em EXL3.

Como isso se conecta aos objetivos de pesquisa

Se o seu objetivo é aprender algo sobre um modelo, o Spark se encaixa perfeitamente:

• Ele comporta o modelo grande. Você pode medir um modelo de 300B em uma ou duas máquinas em vez de alugar um cluster.
• Roda por dias na tomada de casa. Calibrações longas e avaliações podem rodar sozinhas sem gerar uma conta de luz absurda.
• Libera seu hardware mais rápido. Minhas GPUs servem modelos enquanto os Sparks fazem o trabalho lento e minucioso.
• Você pode calibrar com seus próprios dados. Eu fiz pruning de modelos usando minhas próprias sessões de agente e textos, que são privados e ficam na minha mesa.
• É um ótimo host para agentes de pesquisa. Já cheguei a ter quatro agentes trabalhando em objetivos de pesquisa nos Sparks ao mesmo tempo, cada um a cerca de 120 tok/s.
• O treinamento escala bem entre Sparks. No teste da NVIDIA, o fine-tuning rodou 2x mais rápido com dois Sparks e 4x mais rápido com quatro, porque os Sparks sincronizam apenas uma vez por passo (tabela 5). Os playbooks da NVIDIA cobrem fine-tuning com PyTorch. Eu ainda não cronometrei treinamentos por conta própria.

Avançado: GB10, GB300 e o Spark como memória extra

"GB" significa Grace Blackwell: uma CPU Arm e uma GPU Blackwell em um único pacote, compartilhando memória por um link rápido chamado NVLink-C2C. O GB10 dentro do Spark é a menor versão dessa ideia, com uma CPU Arm de 20 núcleos desenvolvida junto com a MediaTek.

O GB300 é a versão para data centers: uma CPU Grace com GPUs Blackwell Ultra (B300). Ele equipa os racks GB300 NVL72 da NVIDIA, e um único GB300 dá vida à DGX Station. O GB10 não é um pedaço cortado de um GB300. É o mesmo projeto, só que miniaturizado — e é por isso que o mesmo software roda em ambos.

Conclusão

O DGX Spark conquistou seu espaço aqui em casa e vem ganhando mais suporte, utilidade e capacidade a cada dia.

Fontes e leituras complementares

• Meus posts: tudo datado acima está no meu perfil no X. As velocidades vêm dos meus próprios testes, publicados no local-ai-registry.
• Receitas: MiaAI Lab no GitHub, meus modelos no Hugging Face.
• Hardware e preço: Página do DGX Spark da NVIDIA, documentação de hardware da NVIDIA, VideoCardz sobre o aumento de preço, VideoCardz sobre os preços de setembro, rastreador de preços pi3g.
• Conexão de Sparks: Documentação de clustering da NVIDIA, blog de escalabilidade da NVIDIA, playbook com switch, guia de cabos, guia de benchmark com dois Sparks da NVIDIA.
• Energia: Review do ServeTheHome, Tom's Hardware sobre consumo em idle, Preços de energia nos EUA (EIA via Utility Dive), Código elétrico dos EUA sobre cargas contínuas.
• Formatos e software: NVIDIA sobre NVFP4, ExLlamaV3, b12x, REAP, capacidades de computação.
• Velocidade na nuvem: InferenceX da SemiAnalysis.
• GB300: Especificações do GB300 NVL72, Especificações da DGX Station, EXO sobre Spark + Mac Studio.
• Primeiros passos: Playbooks do Spark da NVIDIA.
• O panorama geral: State of Local AI: 2026.