DGX Sparks Duplo vs Mac Studio M3 Ultra: Comparação Prática para Executar o Qwen3.5 397B Localmente

Comparação de Hardware para Qwen3.5 397B Local

Um desenvolvedor gastava US$ 2 mil/mês em tokens da API Claude antes de investir US$ 20 mil no total em hardware local: um Mac Studio M3 Ultra 512GB e uma configuração dual DGX Spark, cada um custando cerca de US$ 10 mil após impostos. Ambos foram testados executando o Qwen3.5 397B A17B localmente.

Desempenho do Mac Studio M3 Ultra 512GB

Usando quantização de 6 bits do MLX, o modelo de 323GB foi carregado na memória unificada de 512GB. A velocidade de geração foi de 30-40 tokens/segundo com largura de banda de memória de aproximadamente 800 GB/s, fazendo a geração de tokens parecer suave. A configuração foi fácil: instalar mlx vlm e apontá-lo para o modelo. As fraquezas incluíram pré-preenchimento lento (30+ segundos em prompts de sistema grandes) e degradação de desempenho ao executar embedding em lote junto com inferência. O desenvolvedor teve que escrever um proxy assíncrono de 500 linhas porque o mlx vlm não analisa chamadas de ferramentas ou remove tokens de pensamento nativamente.

Desempenho da Configuração Dual DGX Spark

Usando quantização INT4 AutoRound, 98GB foram carregados por nó em dois nós de 128GB via vLLM TP=2. A velocidade de geração foi de 27-28 tokens/segundo. A configuração aproveitou núcleos tensor CUDA, kernels vLLM e paralelismo tensor para pré-preenchimento mais rápido que o Mac Studio. Embedding em lote que levava dias no MLX foi concluído em horas no CUDA. A largura de banda de memória foi de aproximadamente 273 GB/s por nó, limitando a velocidade de geração apesar de mais computação.

Os desafios de configuração foram significativos: apenas um cabo QSFP funcionou (o segundo travou o NCCL), o IP do Node2 era efêmero, o limite de utilização de memória GPU era 0.88 (exigindo busca binária para encontrar), cada palpite errado custou 15 minutos enquanto os fragmentos do checkpoint recarregavam, o cache de página precisava ser limpo em ambos os nós antes de cada carregamento de modelo, e algumas unidades limitaram termicamente em 20 minutos. O desenvolvedor relatou que levou dias para alcançar estabilidade.

Arquitetura e Caso de Uso

O desenvolvedor manteve ambos os sistemas, usando o Mac Studio apenas para inferência (512GB completos para modelo e cache KV) e os Sparks para RAG, embedding, reranking e outras tarefas. Eles se comunicam via Tailscale. Essa separação impede que modelos de embedding compitam com o modelo principal por memória no Mac Studio, enquanto lhes dá recursos CUDA dedicados nos Sparks.

Especificações Cara a Cara

• Custo: Ambos US$ 10 mil
• Memória: Mac Studio 512GB unificada vs. Sparks 256GB (128×2)
• Largura de Banda: Mac Studio ~800 GB/s vs. Sparks ~273 GB/s por nó
• Quantização: Mac Studio MLX 6 bits (323GB) vs. Sparks INT4 AutoRound (98GB/nó)
• Velocidade de Geração: Mac Studio 30-40 tok/s vs. Sparks 27-28 tok/s
• Contexto Máximo: Mac Studio 256K tokens vs. Sparks 130K+ tokens
• Configuração: Mac Studio fácil porém prática vs. Sparks difícil
• Força: Mac Studio largura de banda vs. Sparks computação
• Fraqueza: Mac Studio computação vs. Sparks largura de banda

Recomendações

O Mac Studio é recomendado se você quer que simplesmente funcione, valoriza 800 GB/s de largura de banda para geração suave e não planeja cargas pesadas de embedding junto com inferência. Os Sparks duplos são recomendados se você está confortável com Linux e Docker, quer CUDA e vLLM nativamente, planeja executar RAG ou embedding junto com inferência e está disposto a gastar dias na configuração inicial para mais capacidade a longo prazo. O desenvolvedor descreve o Mac Studio como fornecendo 80% da experiência com 20% do esforço, enquanto os Sparks oferecem mais capacidade, mas extraem um custo real em tempo de configuração.

Cálculo do ponto de equilíbrio: gasto de US$ 2 mil/mês na API vs. US$ 20 mil total em hardware equivale a 10 meses para equilibrar, após os quais a inferência é gratuita com privacidade completa.