Para ser honesto, fiquei surpreso. Quando conectei duas unidades DGX Spark em cluster e executei 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, concluiu a tarefa em cerca de metade do tempo. E isso foi com o DGX Spark executando o modelo FP8 oficial sem qualquer quantização adicional.
Ao realizar esses benchmarks, senti que o ponto que venho defendendo repetidamente foi mais uma vez comprovado por números. Ou seja:
O desempenho de LLMs não pode ser medido apenas pela velocidade de decodificação (tokens por segundo, TPS) com base 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 é iniciado no Docker e testado automaticamente usando Playwright para login, amigos, DM e atualizações em tempo real, com uma pontuação funcional de até 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á certo. Olhando apenas para a velocidade instantânea de gerar 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. Isso é 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 "alcançar a mesma resposta correta em menos etapas." 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 de 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 FP8 oficial (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 no Desempenho
Além dos números neste 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 porque a Atenção Esparsa (DSA) do DeepSeek é implementada 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 nenhuma quantização adicional no modelo. Carregamos os 154 GB oficiais distribuídos no HuggingFace como estão e 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 funcionar, 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 de comportamento do agente no mesmo benchmark. Quantização não é um 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 "executar modelos enormes com qualidade total" uma realidade pela primeira vez. Acho que este é 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:
- Conjunto 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. Diferente do caminho MARLIN no vLLM geral, estes calculam diretamente em modo fundido sem desquantizar.
- Conexão Direta RoCE de 200 Gbps: Embora o all-reduce entre nós TP=2 aconteça duas vezes por camada, a conexão direta de 200 Gbps mantém a latência efetiva baixa, de modo que 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 FP8 oficial 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 da Atenção Esparsa do DeepSeek (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 de que 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 computacional, comunicação entre nós, otimização de contexto longo ou qualidade da quantização — fosse excepcional, este resultado não teria acontecido. O Spark fornece todos esses elementos em um nível mais alto do que qualquer configuração de máquina única na mesma faixa de preço. Esta é a verdadeira natureza do 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 texto longo simultaneamente (por exemplo, com o Hermes Agent) sem que a decodificação colapse.
- Não há problemas de "Agente só fala" devido a falha de quantização: Esta é uma armadilha na qual caí muitas vezes com modelos da série IQ2; com qualidade total, isso 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 do LLM Apenas pelo TPS Acabou
A velocidade instantânea de gerar 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 alcançar a mesma resposta correta", "qualidade da resposta", "quantos podem ser executados 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 executar um modelo enorme com qualidade oficial, contexto longo, mantendo a compatibilidade com agentes, a 1,78x a velocidade de parede de um Mac Studio, apenas conectando duas unidades em cluster.
Nos últimos anos, as pessoas diziam "LLMs são tudo sobre largura de banda de memória" e "decode TPS é tudo", mas depois de realmente executar 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á a 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 conhecimento se acumularão!
Jensen é realmente incrível... Será que o reinado dele 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ê executasse o FP8 oficial puro 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ê executasse o FP8 oficial puro 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 executar o 'FP8 oficial puro + MoE MXFP4' em um Mac Studio em velocidades práticas.
- Primeiro de tudo, não há um mecanismo de inferência compatível.
Não parece haver 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 do Apple Silicon para Apple): Sem implementação nativa de MoE MXFP4 fused GEMM, sem atenção paginada FP8 e sem implementação MLX da DSA Sparse Attention do DeepSeek. Se você tentasse executá-lo, 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 pura".
- vLLM: O suporte ao Apple Silicon é limitado para começar, e kernels específicos do GB10 como b12x não rodarão em um Mac.
- antirez/ds4: Este é um mecanismo especializado escrito baseado em MLX especificamente para DeepSeek V4 Flash com a suposição de Q4. É a solução ideal atual para executá-lo no Mac Studio, mas não foi construído para lidar com "FP8 puro".
O fato de antirez ter escrito um mecanismo dedicado para DeepSeek V4 Flash especificamente para Q4 mostra a realidade de que atualmente não há um caminho prático para executar a qualidade oficial como está no Apple Silicon.
- Mesmo se fosse executado com upcast para 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 = requisito de largura de banda 2x = 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 = requisito de largura de banda 4x = 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 "ter a qualidade pura" no Apple Silicon atualmente tem o custo de "sacrificar mais que o dobro da velocidade." Executar 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 executa o "FP8 oficial puro + MoE MXFP4 nativamente." Isso é suportado por:
- O conjunto de kernels b12x específicos do GB10, que tem implementações para executar 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 executar "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 semelhante, mas a presença ou ausência de "implementações de kernel que executam formatos de quantização oficial 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, essa premissa irá desmoronar. 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.
