Para ser honesto, fiquei surpreso. Quando conectei duas unidades DGX Spark em cluster e rodei o DeepSeek-V4-Flash, o resultado foi 1,78x mais rápido no tempo total de geração (tempo real de parede) em comparação com o Mac Studio M3 Ultra — ou seja, terminou a tarefa em cerca de metade do tempo. E isso com o DGX Spark rodando o modelo oficial FP8 sem qualquer quantização adicional.
Ao fazer esses benchmarks, senti que o ponto que venho defendendo repetidamente foi mais uma vez comprovado pelos números. Isto é:
O desempenho de LLMs não pode ser medido apenas pela velocidade de decodificação (tokens por segundo, TPS) baseada na largura de banda da memória.
Potência de processamento da GPU, comunicação entre nós, hierarquia de memória, qualidade da quantização, comprimento do contexto, processamento paralelo e assim por diante — o "equilíbrio" de todos esses fatores determina a experiência real do usuário. E o DGX Spark simplesmente tinha um equilíbrio melhor.
O Benchmark Utilizado: Coding Benchmark do shi3z
Para a medição, usei o benchmark de codificação do Japanese LLM Benchmark do shi3z. A tarefa é "completar um chat app que roda em React em uma única geração." O código gerado é de fato iniciado no Docker e testado automaticamente usando Playwright para login, amigos, DM e atualizações em tempo real, com uma pontuação funcional de 80 pontos.
Os resultados da execução do DeepSeek-V4-Flash Q4 (quantização de 4 bits) em um Mac Studio M3 Ultra via mecanismo de inferência ds4 do antirez estão listados no repositório do shi3z. A tabela abaixo compara esses resultados com os desta vez do cluster de 2 unidades DGX Spark + FP8 oficial.
Resultados do Benchmark
Por que "Perde em tok/s mas Ganha em Tempo Real"
Se você olhar para a tabela e pensar, "Pera, o Mac é mais rápido em tok/s," você está correto. Olhando apenas para a velocidade instantânea de cuspir um token (decode TPS), o Mac Studio M3 Ultra é 1,58x mais rápido. Isso se deve à enorme largura de banda de memória do Apple Silicon.
No entanto, há uma armadilha aqui. Para completar o mesmo chat app com "pontuação perfeita 80/80", o Mac escreveu 8.036 tokens, enquanto o DGX Spark escreveu 2.866 tokens. Essa é uma diferença de cerca de 2,8x.
Ambos usaram DeepSeek-V4-Flash sem degradação oficial de qualidade, mas é natural interpretar que o lado do Mac, quantizado para Q4, se tornou redundante, enquanto o lado do Spark, rodando em FP8 de qualidade total, manteve-se conciso. É um fenômeno comum onde o impacto da quantização na distribuição da saída não aparece na velocidade de decodificação, mas afeta silenciosamente a estratégia de geração.
Como resultado, o cálculo fica assim:
Tempo Real de Parede = (Tokens de Saída) ÷ (tok/s)
Mac: 8.036 ÷ 26,2 = 307 segundos Nós: 2.866 ÷ 16,6 = 172 segundos
Perder em tok/s mas ganhar em tempo real significa "atingir a mesma resposta correta em menos passos." No uso prático, o que os humanos experimentam é o "tempo até a tarefa ser concluída," não o tok/s instantâneo.
Configuração Utilizada
- Hardware: DGX Spark × 2 (NVIDIA GB10, baseado em Blackwell, 128 GB de memória unificada cada)
- Interconexão entre Nós: Conexão direta via ConnectX-7 200 Gbps RoCE (Tensor Parallel = 2, backend distribuído PyTorch)
- Mecanismo de Inferência: Receita do Aiden, que integra b12x (um conjunto de kernels CuTe DSL específicos para GB10) no vLLM 0.21.1dev
- Modelo: DeepSeek-V4-Flash oficial FP8 (154 GB, atenção FP8, MoE MXFP4 — este é o formato oficial lançado pela DeepSeek)
- Contexto: 524.288 tokens (512K), util 0,82, cache KV 19,85 GiB, concorrência 3,89×
- Multi-Token Prediction (MTP): Decodificação especulativa com uma taxa de aceitação de cerca de 62% (ganhando velocidade sem sacrificar a qualidade da saída)
Um Olhar Mais Aprofundado sobre o Desempenho
Além dos números deste benchmark, medi separadamente as velocidades puras de decodificação e preenchimento:
- Velocidade Pura de Decodificação (Texto curto, excluindo TTFT): Estável em cerca de 39 tok/s
- Velocidade de Preenchimento (Contexto grande): 1.277 tok/s (Isso é cerca de 6,5x mais rápido que os 196 tok/s da configuração antiga sem kernels b12x)
- Decodificação com Contexto Longo: Mesmo aumentando de 8K → 64K → 128K → 256K → 512K → 768K, a velocidade de decodificação não caiu drasticamente; na verdade, acelerou (106 tok/s em 768K). Isso ocorre porque o Sparse Attention (DSA) da DeepSeek é implementado nativamente nos kernels b12x, tornando os cálculos de atenção quase independentes do comprimento do contexto.
Este é um Resultado com "Sem Quantização, Qualidade Total"
Outro ponto que quero enfatizar é que o lado do DGX Spark não usou qualquer quantização adicional no modelo. Carregamos os 154 GB oficiais distribuídos no HuggingFace como estão e os executamos no formato de quantização oficial projetado pela DeepSeek: atenção FP8 + MoE MXFP4.
No mundo dos LLMs locais, tornou-se senso comum comprimir modelos enormes para IQ2 (2 bits) ou Q4 para fazê-los rodar, mas isso definitivamente reduz a qualidade. Na verdade, tentei anteriormente a versão IQ2XXS (2 bits) do DeepSeek-V4-Flash e vi um resultado de 55/80 + colapso do comportamento do agente no mesmo benchmark. Quantização não é almoço grátis.
Uma configuração que pode garantir 256 GB de memória unificada com dois DGX Sparks torna a opção de "rodar modelos enormes com qualidade total" uma realidade pela primeira vez. Acho que isso é um avanço mais significativo do que os números sugerem.
Por que o "Equilíbrio" do Spark Funcionou
Detalhando os elementos técnicos que apoiaram este resultado:
- Suíte de Kernels b12x: Quatro tipos de kernels (NVFP4 fused MoE GEMM, NVFP4 dense GEMM, FP8 paged attention e sparse MLA attention) escritos especificamente para GB10 / SM12.x usando CuTe DSL. Ao contrário do caminho MARLIN no vLLM geral, estes calculam diretamente em modo fundido sem desquantizar.
- Conexão Direta 200 Gbps RoCE: Embora o all-reduce TP=2 entre nós ocorra duas vezes por camada, a conexão direta de 200 Gbps mantém a latência efetiva baixa, então não se torna um gargalo para a decodificação.
- 128 GB de Memória Unificada × 2: Uma vantagem do Grace Blackwell, que não separa HBM e DDR. Permite que o modelo oficial FP8 de 154 GB seja dividido entre duas unidades como está, com espaço suficiente para um cache KV de 19,85 GiB para um contexto de 512K.
- Implementação Nativa do DeepSeek Sparse Attention (DSA): Os kernels b12x lidam corretamente com o design onde a complexidade da atenção não depende do comprimento do contexto usando operações esparsas nativas do GB10. Isso levou ao resultado onde a velocidade de decodificação não despenca com o comprimento do contexto.
Em outras palavras, se apenas um desses elementos — largura de banda de memória, poder de computação, comunicação entre nós, otimização de contexto longo ou qualidade de quantização — fosse excepcional, este resultado não teria acontecido. O Spark fornece todos esses elementos em um nível superior a qualquer configuração de máquina única na mesma faixa de preço. Esta é a verdadeira natureza de seu "equilíbrio."
O que Muda no Uso Prático?
Para ir além da teoria abstrata, aqui estão alguns benefícios concretos:
- A sumarização e análise de código de documentos enormes se tornam realistas: Com um contexto de 512K e uma velocidade de preenchimento de 1.277 tok/s, você pode carregar e resumir um livro inteiro (~300.000 tokens) em cerca de 4 minutos.
- Loops de agente não travam: Com concorrência de 3,89×, você pode executar chat e sumarização de textos longos simultaneamente (por exemplo, com Hermes Agent) sem que a decodificação colapse.
- Sem problemas de "Agente é só conversa" devido à falha de quantização: Esta é uma armadilha na qual caí muitas vezes com modelos da série IQ2; com qualidade total, simplesmente não acontece.
- Competitivo com o Mac em termos de consumo de energia: O consumo total de energia de dois GB10s durante a inferência é de cerca de 100W–140W, o que é próximo ao Mac Studio M3 Ultra em potência máxima. Considerando o desempenho 1,78x, a eficiência energética também não é ruim.
Conclusão: A Era de Julgar o Desempenho de LLMs Apenas pelo TPS Acabou
A velocidade instantânea de cuspir um token — o decode TPS — é certamente uma métrica importante. No entanto, é como a "velocidade máxima de uma corrida de 100m." O que é necessário na prática é o "tempo para atingir a mesma resposta correta," "qualidade da resposta," "quantos podem rodar simultaneamente," "quão longo contexto pode ser manipulado," e "se os loops de agente funcionam." Estas são as pontuações totais.
O que este resultado mostrou é que o DGX Spark está começando a se destacar nesta pontuação total. Entramos em uma era onde você pode rodar um modelo enorme com qualidade oficial, contexto longo, mantendo a compatibilidade com agentes, a 1,78x a velocidade real de um Mac Studio, apenas conectando duas unidades em cluster.
Nos últimos anos, as pessoas disseram "LLMs são tudo sobre largura de banda de memória" e "decode TPS é tudo," mas depois de realmente rodar o Spark, sinto que minha afirmação de que "equilíbrio é desempenho prático" foi finalmente comprovada pelos números.
O RTX Spark também foi anunciado, e há uma sensação de que as coisas estão esquentando mais do que o esperado (embora a atmosfera possa esfriar quando o preço for divulgado...). Tenho grandes expectativas de que a comunidade crescerá e mais otimização e know-how serão acumulados!
Jensen é realmente incrível... Será que seu reinado continuará por muito tempo?
**
**
**
**
**
Bônus
Leitores mais atentos podem ter esta crítica:
"Então não seria uma comparação justa se você rodasse o FP8 oficial bruto no Mac Studio também?"
"A comparação não é injusta? O Mac Studio só se tornou redundante porque foi quantizado para Q4. Se você rodasse o FP8 oficial bruto no Mac Studio, não estaria no mesmo patamar em termos de qualidade?" Esta é uma pergunta razoável.
Para ir direto ao ponto: Atualmente, não há como rodar o 'FP8 oficial bruto + MoE MXFP4' em um Mac Studio em velocidades práticas.
- Primeiro, não há um mecanismo de inferência compatível.
Não parece existir um mecanismo que suporte totalmente o formato oficial do DeepSeek-V4-Flash (atenção FP8 + MoE MXFP4 + Lightning Indexer + DSA Sparse Attention) no Apple Silicon (de acordo com uma pesquisa do Claude Code).
- MLX (framework oficial de LLM para Apple Silicon da Apple): Sem implementação nativa de MoE MXFP4 fused GEMM, sem FP8 paged attention e sem implementação MLX do DSA Sparse Attention da DeepSeek. Se você tentasse rodar, provavelmente teria que fazer upcast para bf16.
- llama.cpp: Não pode carregar MXFP4 diretamente, então requer requantização para GGUF = acaba sendo convertido para Q4 / Q5 / IQ2, etc., e não é mais a versão "oficial bruta."
- vLLM: O suporte ao Apple Silicon é limitado para começar, e kernels específicos do GB10 como b12x não rodam em um Mac.
- antirez/ds4: Este é um mecanismo especializado escrito baseado em MLX especificamente para DeepSeek V4 Flash com a premissa de Q4. É a solução ótima atual para rodá-lo no Mac Studio, mas não é construído para lidar com "FP8 bruto."
O fato de antirez ter escrito um mecanismo dedicado para DeepSeek V4 Flash especificamente para Q4 fala da realidade de que atualmente não há um caminho prático para rodar a qualidade oficial como está no Apple Silicon.
- Mesmo se fosse executado com upcast bf16, a largura de banda seria quase totalmente consumida.
Para fins de argumentação, digamos que alguém criasse uma implementação MLX que fizesse upcast dos pesos oficiais para bf16. Você pode estimar o que aconteceria com um cálculo aproximado de largura de banda:
- DeepSeek-V4-Flash tem uma configuração MoE com cerca de 30B de parâmetros ativos.
- Em Q4 (4 bits), os parâmetros ativos ocupam cerca de 15 GB, e o ds4 atinge 26,2 tok/s (medido).
- Se o mesmo modelo for mantido em FP8 (8 bits), os parâmetros ativos ocupam cerca de 30 GB = 2x requisito de largura de banda = teoricamente ~13 tok/s no mesmo mecanismo.
- Além disso, fazer upcast para bf16 no MLX leva cerca de 60 GB para parâmetros ativos = 4x requisito de largura de banda = teoricamente ~6,5 tok/s.
- Como a largura de banda efetiva de memória do Mac Studio M3 Ultra é de cerca de 800 GB/s, ler 60 GB para cada token atingiria o limite de largura de banda.
Em outras palavras, a escolha de "obter a qualidade bruta" no Apple Silicon atualmente vem ao custo de "sacrificar mais que o dobro da velocidade." Rodar a 26,2 tok/s com ds4 + Q4 foi uma escolha mais prática do que obter apenas 6 tok/s com bf16 de qualidade total.
- É aqui que entra a vantagem estrutural do Spark.
Por outro lado, esta configuração do DGX Spark roda o "FP8 oficial bruto + MoE MXFP4 nativamente." Isso é suportado por:
- A suíte de kernels b12x específicos para GB10, que tem implementações para rodar NVFP4 fused MoE GEMM e FP8 paged attention "sem desquantização."
- Isso ainda não foi escrito para Apple Silicon.
- Como resultado, o Spark é atualmente a única solução realista para rodar "qualidade oficial como está" e "em velocidades práticas."
Para resumir, se você olhar apenas para a largura de banda do hardware, o valor absoluto do Mac Studio para uma única unidade está em um nível similar, mas a presença ou ausência de "implementações de kernel que rodam formatos oficiais de quantização nativamente" cria uma diferença decisiva. A vantagem do Spark vem não apenas do chip, mas de toda a combinação com a pilha de software especializada em GB10, como o b12x.
Se alguém escrever MXFP4 fused MoE GEMM, FP8 paged attention e DSA Sparse Attention para Apple Silicon no MLX no futuro, esta premissa irá ruir. O cenário mudará dependendo das implementações da comunidade. Por enquanto, o fato é que o Spark está um passo à frente em alcançar a combinação de "qualidade oficial × velocidade prática."
Estes são os resultados da análise fornecida pelo Claude Code.
