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 me empolguei. 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,5 vezes mais largura de banda (1.792 GB/s), mesmo contando com apenas 32 GB de VRAM.

No lançamento do Spark, práticas de engenharia de inferência como decodificação especulativa ainda não eram tão difundidas, e a maioria dos modelos pequenos não era tão capaz.

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

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

Hoje, o DGX Spark consegue rodar modelos muito inteligentes na mesma velocidade dos serviços em 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, entenda 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 pelo custo por token, então cada um recebe uma fatia menor. Em casa, a máquina é toda sua. 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 isso, 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ó precisa ser ligado 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 conectar 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 com dois Sparks
• 819 GB/s com três
• 1.092 GB/s com quatro

Isso escala de forma quase linear. No teste da própria NVIDIA, a escrita ficou 2 vezes mais rápida com dois Sparks e 3,7 vezes 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 motivo aqui).

A memória se soma da mesma forma: 128 GB cada, 512 GB com quatro, sendo que cerca de 120 GB por Spark ficam efetivamente disponíveis para cargas de trabalho de IA.

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

DGX Sparks conectados 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, 9 vezes 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 ao usuário apesar do tamanho total do modelo.

O MoE não é bom só para o DGX Spark. É uma arquitetura melhor também 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 ultrapassaram essa barreira, 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 muita computação para gerar um token correto.

Isso melhora significativamente a capacidade de processamento dos Sparks, 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, essas tecnologias foram o que empurrou a IA local para além do 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 simultâneas, todas mantendo velocidade de conversa. Por exemplo, o Qwen3.6-35B, capaz de programação básica, uso de computador e navegador, edição de vídeo e imagem e suporte geral, pode atender até 8 sessões concorrentes, 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. Atender 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 dá cerca de 11 vezes 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: 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 o 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, em 21 de setembro, 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. Postagem

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 os mesmos softwares 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, ruído e a conta de luz

O barulho e o calor que GPUs dedicadas geram não são brincadeira; com 4x 3090 você facilmente consome de 1.600 a 2.000 W para ter 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 a 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 gastando uns 240 W. Cerca de US$ 66 a 100 por mês, e todos cabem em uma ú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 representa um tipo diferente de medição, então aqui estão lado a lado. O custo mensal considera a máquina rodando nesse consumo 24 horas por dia, a 18 centavos por kWh:

Meus testes

Por que quatro Sparks gastam mais do que quatro vezes 90 W. O valor de 90 W é de um único 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 períodos ociosos, 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, chegando a uns 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 ao mesmo tempo.

Ruído do DGX Spark

E o barulho? Meu setup de GPUs soa como a turbina de um avião. Este é 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, modelos de mundo, geração de imagens etc.
• Deixe-os deitados de lado. Os meus esquentam menos assim, com espaço livre 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 uso

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 já 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 prever; texto corrido, não. Por isso, 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. Então, cada velocidade aqui informa 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 com 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) Postagem

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

• 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 conseguem caber

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 significa menor; mais abaixo significa 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 ocupa 176 GB e cabe em dois Sparks. Em 2 bits, fica com 85 GB e cabe em um só, 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 quanto a versão reduzida se mantém fiel à original. Dois números para procurar:

• Top-1 agreement (concordância Top-1): com que frequência o modelo menor 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 as previsões 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 o 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 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 usando isso. Coloque num arquivo .env, nunca direto no repositório.
4. Verifique o disco. Modelos são pesados. Uma receita para um Spark precisa de 25 a 130 GB livres. A receita do DeepSeek para quatro Sparks exige cerca de 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 confirma que a máquina funciona antes de você mexer em algo mais complexo.

Depois, passe para uma receita. As 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

Este é 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 de 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 da sua escolha. Não use USB-C nem a porta 10 GbE para isso. São lentas demais.

Configure o link. Siga o playbook de conexão de 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, insira 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 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 em um triângulo de três Sparks a 51,0 tok/s para um usuário, com 256K de contexto. Tem um comando doctor que checa SSH, Docker e os links de rede antes de começar.
• GLM-5.3-Flash com mais folga. 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. Confira 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 com 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: "Não acho que exista negócio melhor no mercado do que 4 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 de quatro Sparks. Ainda está em fase alfa, então fixe uma versão específica.
• Esta receita do GLM-5.3-Flash roda num anel de quatro Sparks com 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

Os meus melhores resultados com quatro unidades foram 118 tok/s para o GLM-5.3-Flash com 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 monitorizar todos os teus Sparks numa única janela. GPU, memória, rede e tokens por segundo em tempo real. Várias das velocidades deste guia foram medidas com ele.
• \\Playbooks da NVIDIA para o Spark:\\ guias oficiais para LM Studio, Ollama, vLLM, ligação de Sparks e muito mais.
• \\local-ai-registry:\\ as minhas receitas e todos os testes de velocidade que fiz.
• \\b12x:\\ a matemática rápida que está por baixo de muitas receitas para o Spark. Não o instalas manualmente; as receitas fazem isso. Vê as notas avançadas abaixo.

Conclusão

O Spark é uma caixa de memória. Guarda modelos grandes, roda-os silenciosamente na tomada de casa e fica melhor cada vez que adicionas mais um.

Se estás a começar hoje:

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

Voltaria a comprá-los? Sim. E se estivesse a começar do zero, compraria dois logo no primeiro dia.

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

Não precisas disto para usar um Spark. É para quando quiseres perceber porque é que os números são o que são.

Quase linear, na escrita

Cada palavra que o modelo escreve significa ler os pesos ativos do modelo da memória. Divide o modelo entre vários Sparks e cada um lê a sua parte ao mesmo tempo, por isso as velocidades de leitura somam-se.

A NVIDIA mediu isto. Ao passar de um para dois e depois para quatro Sparks, o tempo para escrever cada palavra caiu de 269 ms para 133 ms e depois para 72 ms. Isso dá 2,0x com dois e 3,7x com quatro (blog da NVIDIA, tabela 3).

Chega tão perto disso porque a ligação ConnectX-7 tem latência muito baixa, e as trocas de dados entre os Sparks podem acontecer dentro do próprio código da GPU. Esta explicação para Macs cobre a mesma ideia com mais detalhe.

Depois de cada camada, os Sparks trocam os seus resultados parciais antes que a camada seguinte possa começar. A troca é pequena, mas acontece em cada camada e em cada palavra. Cada uma custa um pouco de tempo que não diminui quando adicionas mais Sparks.

• A ligação é de 200 Gb/s, cerca de 25 GB/s. Isso é um décimo da velocidade da própria memória do Spark. Não há problema, porque as trocas são pequenas.
• Usa RDMA. Os dados vão diretamente da memória de um Spark para a do outro, sem que a CPU precise de os copiar. Cada porta QSFP aparece como duas metades de 100 Gb/s, e o software tem de usar ambas para atingir os 200 completos (detalhes). O NCCL, a biblioteca da NVIDIA para isto, trata de tudo.
• A leitura escala pior do que a escrita. 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 move muito mais dados entre os Sparks a cada passo.
• Anéis adicionam saltos. Num triângulo de três Sparks, cada Spark está ligado por cabo aos outros dois. Num anel de quatro Sparks, alguns pares comunicam através de um vizinho. Um switch deixa toda a gente a um salto de distância. O SparkRing escreve o 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 tensor parallel com "expert parallel", onde diferentes Sparks guardam diferentes especialistas.

As outras duas formas de ir mais rápido

• Muitos usuários ao mesmo tempo. O Spark lê o modelo uma vez por passo e responde a todos a partir dessa única leitura. Por isso, a velocidade total sobe muito mais depressa do que a velocidade para um único usuário.
• Um modelo de descodificação especulativa que adivinha à frente. MTP, DSpark e DFlash2 fazem exatamente isto. Um auxiliar pequeno e rápido rascunha várias palavras, e o modelo grande verifica todas de uma só vez. Quando os palpites estão certos, ganhas várias palavras pelo preço de uma. É assim que o GLM-5.3-Flash passa de 27 tok/s em texto corrido para 65 em saídas estruturadas na mesma receita.

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

IA na Cloud e IA Local são coisas diferentes

Uma GPU na cloud é muito mais rápida que um Spark. Mas os fornecedores de cloud partilham cada GPU entre muitos usuários, e escolhem um ponto de equilíbrio entre o custo por token e a velocidade por usuário. A maioria escolhe o custo, por isso cada usuário recebe menos tokens por segundo do que o hardware poderia dar a uma só pessoa. O InferenceX ilustra esse compromisso para o Qwen3.8-Flash-Next.

Em casa, esse compromisso não existe. A máquina é tua, por isso podes gastar toda a capacidade dela numa única pessoa. É por isso que um Spark pode parecer tão rápido quanto um serviço na cloud, mesmo que o hardware não seja.

sm_121: porque o software do Spark é um mundo à parte

Todas as GPUs da NVIDIA têm um número de "capacidade de computação" que diz ao software quais as instruções disponíveis. A GPU do Spark é 12.1, ou sm_121 (primeira análise do Simon Willison). A RTX 5090 e a RTX PRO 6000 são sm_120, uma prima próxima. 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, muito desse código simplesmente não corria ou corria devagar (fórum da NVIDIA, issue no vLLM).

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

• A 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. Cobre matemática matricial de 4 bits (NVFP4, MXFP4), atenção para modelos estilo DeepSeek, camadas mixture-of-experts e um carregador de modelos rápido. Instala-se com pip install b12x, e as receitas do vLLM ativam-na com flags como flashinfer_b12x. A receita do Qwen3.6-35B usa-a.
• SparkInfer é o nome antigo da b12x. O link antigo agora redireciona para a b12x. A minha receita de DeepSeek para um Spark usa o código de atenção dela tanto para leitura como para escrita. Não confundir com o sparkinfer da gittensor, um runtime separado para placas RTX (apenas sm_120).
• A ExLlamaV3 é o que faz correr os modelos EXL3. O MiaAI Lab mantém um fork com o port para Arm (GB10) e suporte a modelos auxiliares.
• O lil é o launcher do Local Inference Lab. Ele lê a configuração da máquina e constrói o comando vLLM certo para um Spark ou para um grupo ligado.

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

Esta é a parte que eu não esperava. O Spark é lento a escrever, mas é muito bom a ler. E a maior parte do trabalho de pesquisa com modelos é leitura.

O que o Spark faz melhor: prefill

Um modelo faz dois trabalhos diferentes:

• Prefill é ler o teu prompt. O prompt inteiro entra de uma vez, por isso o limite é o poder de computação bruto. O GB10 tem de sobra: até 1 petaflop de cálculos de 4 bits.
• Decode é escrever a resposta, uma palavra de cada vez. Cada palavra significa ler o modelo da memória outra vez, por isso o limite é a velocidade da memória. Esse é o ponto fraco do Spark.

Assim, um Spark lê prompts 13 a 41 vezes mais rápido do que escreve:

DeepSeek-V4.1-Flash em quatro Sparks: 3.360 tok/s a ler um prompt de 32K tokens, 3.273 a 131K, enquanto a escrita se mantém entre 70 e 95. (20 de setembro) Post

Porque é que isto é o que a pesquisa precisa

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

• Quantização (menos bits). As versões EXL3 e NVFP4 são criadas passando texto de amostra pelo modelo e medindo quanto cada camada perde em cada largura de bits. Isso é leitura.
• Pruning (menos especialistas). O REAP passa texto de amostra por um modelo mixture-of-experts e regista quanto cada especialista é usado. Os menos úteis são cortados. O meu GLM-5.3 de 197 GB mantém 168 dos 256 especialistas. Isso também é leitura.
• Verificar qualidade. A concordância top-1 e a divergência KL vêm de ler o mesmo texto com o modelo original e com o modelo pequeno e comparar os seus palpites. Leitura outra vez.
• Testes de contexto longo. Confirmar que um modelo consegue encontrar um facto em 262.000 tokens é, basicamente, uma leitura muito longa.

O meu próprio fluxo de trabalho mudou exatamente por esta razão. "Agora estou a fazer todo o meu pruning/exl3/benchmarking nos DGX Sparks, deixo as 6000 para inferência. É mais lento, mas 2-3 dias contra 12h está ótimo." O DeepSeek para um único Spark que passou dos 100.000 downloads é um modelo podado com REAP e comprimido com EXL3.

Como isto se liga aos objetivos de pesquisa

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

• Ele guarda o modelo grande. Podes medir um modelo de 300B numa ou duas máquinas em vez de alugares um cluster.
• Fica ligado durante dias na tomada de casa. Trabalhos longos de calibração e avaliação podem correr sem supervisão e sem uma conta gigante de luz.
• Liberta o teu hardware rápido. As minhas GPUs servem modelos enquanto os Sparks fazem o trabalho lento e cuidadoso.
• Podes calibrar com os teus próprios dados. Já fiz pruning de modelos usando as minhas próprias sessões de agentes e textos, que são privados e ficam na minha secretária.
• É um bom hospedeiro para agentes de pesquisa. Já tive quatro agentes a trabalhar em objetivos de pesquisa nos Sparks ao mesmo tempo, cada um a cerca de 120 tok/s.
• O treino escala bem entre Sparks. No teste da NVIDIA, o fine-tuning correu 2x mais rápido com dois Sparks e 4x mais rápido com quatro, porque os Sparks só sincronizam uma vez por passo (tabela 5). Os playbooks da NVIDIA cobrem fine-tuning com PyTorch. Eu próprio ainda não cronometrei treinos.

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

"GB" significa Grace Blackwell: uma CPU Arm e uma GPU Blackwell num único pacote, partilhando memória através de uma ligação rápida chamada NVLink-C2C. O GB10 no Spark é a versão mais pequena dessa ideia, com uma CPU Arm de 20 núcleos desenvolvida com a MediaTek.

O GB300 é a versão para data centers: uma CPU Grace com GPUs Blackwell Ultra (B300). Fica nos racks GB300 NVL72 da NVIDIA, e um GB300 alimenta a DGX Station. O GB10 não é um pedaço cortado de um GB300. É o mesmo design, feito em tamanho reduzido, e é por isso que o mesmo software corre em ambos.

Conclusão

O DGX Spark conquistou o seu espaço cá em casa e cresce em suporte, utilidade e capacidade a cada dia que passa.

Fontes e leituras adicionais

• Os meus posts: tudo o que tem data 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, os 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.
• Ligar Sparks: Documentação de clustering da NVIDIA, blog de scaling da NVIDIA, playbook com switch, guia de cabos, guia de benchmarking para dois Sparks da NVIDIA.
• Energia: Review do ServeTheHome, Tom's Hardware sobre consumo em idle, Preços de eletricidade 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 cloud: InferenceX da SemiAnalysis.
• GB300: Especificações do GB300 NVL72, Especificações da DGX Station, EXO sobre Spark mais Mac Studio.
• Para começar: Playbooks da NVIDIA para o Spark.
• O panorama geral: State of Local AI: 2026.