Quando se fala do NVIDIA DGX Spark, duas coisas costumam vir à tona primeiro. A primeira é a especificação principal: 128 GB de memória unificada em um dispositivo desktop de aproximadamente US$ 4,000, um número que pareceria impensável para um engenheiro há apenas dois anos. A segunda é a rede de 200 GB na parte traseira da unidade. A presença de uma infraestrutura de rede de nível de data center em um dispositivo desktop é o que realmente chama a atenção, pois implica algo mais do que uma estação de trabalho mais rápida em um único dispositivo. Implica a capacidade de conectar Sparks e replicá-los fisicamente, o tipo de configuração com múltiplos nós que antes era exclusiva de racks.
Esta análise examina essa capacidade. Avaliamos a inferência distribuída em todas as três implementações de Spark de fabricantes de equipamentos originais (OEMs) que temos disponíveis, agrupadas em clusters de dois nós conectados pela rede de 200 Gb, e analisamos diferentes variantes de modelo e três formatos de carga de trabalho. Também fazemos uma escolha metodológica deliberada sobre como o modelo é dividido entre os dois servidores, que diverge da recomendação padrão da NVIDIA, e a defendemos com dados. Antes de tudo isso, porém, dois elementos contextuais moldam tudo o que se segue: a rede que torna o agrupamento possível em primeiro lugar e os motivos pelos quais alguém pode ou não querer usá-lo.
O tecido de 200 GB
Abordamos a implementação de rede em detalhes em nossa análise original do DGX Spark, mas vale a pena relembrar os conceitos básicos, pois tudo nesta análise depende deles. A parte traseira de cada Spark possui dois slots QSFP56, controlados por uma placa de rede inteligente NVIDIA ConnectX-7 integrada. Teoricamente, os dois slots sugerem 400 GB de conectividade agregada, mas o limite real é o PCIe: a ConnectX-7 opera por trás de um par de links Gen5 x4, e a plataforma atinge um máximo de 200 GB de largura de banda utilizável, independentemente da forma como os slots são conectados. Um único slot QSFP56 já oferece os 200 Gb suportados pelo dispositivo, portanto, a segunda porta serve para flexibilidade de topologia, e não para aumentar a taxa de transferência.
Essa flexibilidade se manifesta em três configurações comuns. A mais simples é uma única porta de 200 GB usada como um link direto Spark-para-Spark, que é o que a NVIDIA especifica na configuração validada de dois nós e o que usamos para esta análise. A segunda é uma configuração com duas portas de 100 Gb, criando uma topologia em anel entre os Sparks para formar um cluster sem a necessidade de um switch. A terceira é uma configuração de função dividida, onde uma das portas se conecta a um Spark par para clusterização e a outra se conecta a um armazenamento de alta velocidade via NVMe-oF, o que é útil quando o conjunto de dados de trabalho não cabe no NVMe interno do Spark.
A NVIDIA vende o Spark em três configurações que correspondem diretamente à forma como a rede é utilizada. Um único Spark para tarefas individuais em desktops, um cluster validado com dois Sparks conectados diretamente pela malha de 200 Gb para modelos estendidos e, a partir da GTC deste ano, uma configuração com quatro unidades que a NVIDIA demonstrou publicamente em resposta à demanda dos usuários para ultrapassar o limite de dois nós. A configuração com dois Sparks é a que a NVIDIA comercializa ativamente, a que a maioria dos leitores realmente implementará e a que acreditamos representar o limite superior sensato para inferência em nível de produção neste hardware. É também a configuração que esta análise avalia de ponta a ponta.
Por que faíscas em cluster, afinal?
A razão óbvia para agrupar instâncias do Spark em cluster é a mesma de qualquer outro cluster: um único servidor de 128 GB não comporta todos os modelos relevantes. Distribuir um modelo com 120 bilhões de parâmetros entre dois servidores possibilita a execução de uma classe de cargas de trabalho que, de outra forma, não caberiam. Esse é o principal caso de uso e o mais frequentemente demonstrado.
A razão menos óbvia, e possivelmente a mais importante para a base de clientes da NVIDIA nessa plataforma, é o aprendizado. A NVIDIA posiciona o Spark como um ponto de partida. documentação oficialOs notebooks de exemplo e os guias de parceiros tratam o dispositivo como uma ferramenta de ensino. Eles incluem guias de primeira linha para tudo, desde a inicialização de um modelo pré-construído por meio de uma interface de bate-papo local até a execução de um assistente de codificação em um endpoint hospedado, passando pelo ajuste fino de pequenos modelos e pela construção de aplicativos completos em PyTorch e JAX. A proposta é que alguém que nunca escreveu um kernel CUDA na vida possa ir do zero a um fluxo de trabalho de IA funcional em sua mesa em um fim de semana, e o mesmo se aplica a engenheiros de áreas não relacionadas a aprendizado de máquina que desejam um ambiente de teste independente que controlem totalmente. Um cluster com dois Sparks amplia essa superfície de aprendizado para o território de múltiplos nós: a mesma pessoa agora também pode aprender como o paralelismo de tensores, o paralelismo de pipeline e as bibliotecas de comunicação coletiva realmente se comportam, com uma rede suficientemente real para expor gargalos reais.
O que está visivelmente ausente de qualquer posicionamento da NVIDIA, no entanto, é a afirmação de que o Spark se destina ao atendimento de inferência em produção. Jensen tem falado sobre o design conjunto de hardware e software em praticamente todas as suas apresentações principais nos últimos anos, e o princípio se aplica aqui. Cada plataforma NVIDIA é otimizada para um formato de carga de trabalho específico, e o Spark é otimizado para exploração e aprendizado individuais, não para atendimento de tráfego. Nossas análises anteriores do Spark já mostraram que a plataforma é fortemente limitada pela largura de banda da memória na maioria das tarefas de inferência, e a rede apenas acentua essa limitação assim que você cria um cluster. Um único link de 200 Gb, embora impressionante para um desktop, é significativamente mais lento do que uma conexão PCIe Gen5 x16 dentro de um único chassi, e padrões de comunicação coletiva que funcionam perfeitamente em um par de GPUs de data center com ponte NVLink não podem ser transferidos para uma malha de 200 Gb sem incorrer em penalidades reais de latência.
Essa é a verdadeira razão pela qual a NVIDIA limitou a configuração oficialmente suportada a dois Sparks por tanto tempo, e por que a demonstração com quatro unidades na GTC foi uma resposta à demanda dos usuários, e não uma expansão orgânica do produto. Nada impede que o conjunto de softwares seja executado em quatro ou oito nós, e diversos usuários e veículos de comunicação já publicaram resultados de clusters maiores. Os números de desempenho desses experimentos geralmente não são animadores: a infraestrutura entre os nós se torna o custo dominante, o desempenho coletivo se degrada drasticamente e, além disso, a taxa de transferência por usuário no limite dessas configurações pode cair para a faixa de um dígito de tokens por segundo para qualquer modelo grande o suficiente para justificar o cluster. Nesse ponto, a configuração funciona mais como um laboratório de aprendizado do que como uma plataforma de serviço.
Nada disso deve ser interpretado como uma rejeição. O agrupamento de Sparks é uma maneira genuinamente excelente de desenvolver uma intuição para inferência e treinamento distribuídos, algo que, de outra forma, estaria bloqueado por centenas de milhares de dólares em hardware de data center. Além disso, o valor educacional de poder observar, na prática, bolhas no pipeline, gargalos de redução total e compensações de paralelismo em um sistema próprio é significativo. Nosso plano seguinte era aprofundar esse tema, treinando um pequeno modelo de 1 bilhão de parâmetros ou menos do zero em um cluster dual-Spark, com uma configuração escolhida para espelhar o mais fielmente possível as condições de operação de uma execução real de pré-treinamento distribuído. Assim, poderíamos demonstrar exatamente onde esse tipo de cluster faz sentido e onde não faz. Esse projeto está atualmente em segundo plano, enquanto trabalhamos em outros conteúdos que você talvez já tenha visto e aguardamos a chegada do nosso novo switch de núcleo de 800 Gb para o laboratório. Esperamos retomá-lo assim que a configuração do laboratório estiver concluída.
O que se segue foca-se no caso de uso para o qual a configuração dual-Spark é mais defensável: inferência distribuída de modelos suficientemente grandes para exigirem ambas as máquinas, com resultados comparados nas três implementações de fabricantes de equipamentos originais (OEMs) que temos disponíveis. Antes de apresentarmos os números por modelo, a próxima seção explica por que estamos relatando esses números sob uma configuração de pipeline paralelo em vez da configuração de tensor paralelo que a própria documentação da NVIDIA tende a usar por padrão.
Teste de Desempenho
Por que relatamos o paralelismo de pipeline e não o paralelismo de tensores?
A NVIDIA publicou Guias DGX Spark A maior parte do material de referência deles se baseia no paralelismo tensorial (TP) para descrever como escalar um modelo em duas instâncias do Spark. O TP divide cada multiplicação de matriz entre as duas GPUs, de modo que cada camada seja executada simultaneamente em ambos os dispositivos, e os resultados parciais são combinados por meio de uma operação all-reduce após cada bloco de atenção e MLP. O paralelismo de pipeline (PP) adota uma abordagem diferente: ele divide o modelo ao meio por camada, coloca a primeira metade em uma instância e a segunda metade na outra, e então transmite as ativações entre elas. Cada requisição ainda percorre o modelo completo, mas, em qualquer instante, apenas uma instância está realizando os cálculos para um determinado token enquanto a outra está processando o próximo microlote.
A questão central reside no que é transmitido pela rede. Uma pilha dual-Spark conecta os dois sistemas através de um link ConnectX-7 200 GbE, que é rápido para uma conexão de rede, mas lento em comparação com a largura de banda de memória de um único Spark. A operação all-reduce do TP é executada duas vezes por camada do transformador, portanto, um modelo de 80 camadas executando TP=2 gera 160 trocas entre caixas para cada token de saída, com cada uma dessas trocas bloqueando a próxima computação. O PP=2 repassa as ativações apenas uma vez por token, na junção entre as duas metades do modelo. Em um link 200 GbE com latência significativa, essa diferença se torna determinante.
Nossas medições com o GPT-OSS-120B comprovam isso claramente. Fora do tamanho de lote 1, onde a carga de trabalho é muito pequena para mascarar a sobrecarga de qualquer uma das estratégias, PP=2 assume a liderança e a mantém à medida que a concorrência aumenta. Na carga de trabalho Equal ISL/OSL, TP=2 atinge 252.01 tok/s com um tamanho de lote de 128, enquanto PP=2 sobe para 554.69 tok/s no mesmo hardware, uma vantagem de 2.20x. O cenário Prefill Heavy mostra o mesmo padrão, com PP=2 atingindo 310.63 tok/s contra TP=2, que alcança 164.99 tok/s. O cenário Decode Heavy é o mais próximo dos três, mas PP=2 ainda lidera do tamanho de lote 8 ao tamanho de lote 64, perdendo uma pequena vantagem apenas no tamanho de lote 128, onde a longa saída de 8K amplifica o custo da bolha do pipeline.
TP=2 apresenta uma pequena janela de oportunidade em que se destaca. Com tamanho de lote 1 em todos os cenários, TP oferece uma pequena, porém real, vantagem: 39.55 tok/s contra 28.79 tok/s em Equal, 37.97 contra 29.60 em Prefill Heavy e 39.42 contra 30.28 em Decode Heavy. Com apenas uma requisição em andamento, não há um segundo microbatch para manter o estágio ocioso do pipeline ocupado, então PP paga por um slot vazio a cada etapa, enquanto TP utiliza ambas as GPUs no único token existente. Este é o regime para o qual as diretrizes de TP da NVIDIA foram criadas: serviço interativo de fluxo único, onde a latência na primeira e única requisição importa mais do que a taxa de transferência agregada. Se uma implementação for genuinamente no estilo chat, com um usuário por dispositivo e metas de TTFT rigorosas, TP=2 é a escolha certa, e isso também está alinhado com a visão da NVIDIA sobre o Spark.
Para cargas de trabalho que atendem infraestrutura em escala, com inferência em lote e muitas solicitações simultâneas, o paralelismo de pipeline (TP) é a melhor opção para escalabilidade entre servidores, especialmente quando estratégias como o paralelismo especializado (Expert Parallelism) não estão em uso. A malha de 200 GbE não consegue suportar o tráfego de redução total por token do TP sem deixar recursos computacionais ociosos e, quando o tamanho do lote é 4 ou 8, o custo de bolha do PP desaparece no fluxo de estado estável. É por isso que todos os números por modelo no restante deste artigo são relatados com TP=1 e PP=2. Essa é a configuração que realmente representa o que uma implantação dual-Spark pode entregar quando solicitada a realizar trabalho real.
Escolhemos deliberadamente o GPT-OSS-120B como o gráfico principal de comparação entre TP e PP porque ele mostra a maior diferença. No entanto, também queremos mostrar que isso não se aplica a todos os modelos e que esses parâmetros dependem das características do modelo. O Llama-3.1-8B-Instruct no BF16 apresenta um cenário muito mais conservador. O modelo é pequeno o suficiente para que a computação de cada camada seja rápida e o tráfego de redução total do TP seja correspondentemente modesto. Em contraste, o custo de coordenação por etapa do PP é fixo, independentemente do tamanho do modelo. O resultado é que TP=2 mantém a liderança durante quase toda a varredura em lote. Em Equal ISL/OSL, TP=2 lidera desde o tamanho de lote 1 (23.2 vs 13.4 tok/s) até o tamanho de lote 32 (388.7 vs 349.3 tok/s), perdendo a liderança apenas nos tamanhos de lote 64 (524.8 vs 638.2 tok/s) e 128 (679.2 vs 1,047.1 tok/s). Prefill Heavy segue o mesmo padrão, com TP=2 à frente até o tamanho de lote 32, antes de PP=2 assumir a liderança nos tamanhos 64 e 128. Decode Heavy é o mais decisivo: TP=2 vence em todos os tamanhos de lote, terminando com 366.7 tok/s contra 330.5 tok/s para PP=2 no tamanho de lote 128.
Este contraexemplo reforça, em vez de contradizer, a mecânica subjacente. O PP=2 só vence quando os tamanhos dos lotes são suficientemente grandes para preencher o pipeline e amortizar totalmente o custo da bolha, e quando o próprio modelo é pequeno o suficiente para que a redução total por camada do TP seja barata; esse ponto de cruzamento é adiado. O resultado com Decodificação Pesada também é consistente: sequências de saída mais longas significam mais etapas de decodificação, mais bolhas do pipeline pagas consecutivamente e uma janela menor para o PP compensar a diferença. Em outras palavras, a mesma física que dá ao PP uma vitória de 2.20x no GPT-OSS-120B com tamanho de lote 128 também explica por que ele só vence nos dois maiores tamanhos de lote em um modelo de 8 bits e nunca vence na varredura com decodificação pesada.
GPT-OSS-120B
Em comparação com o Equal ISL/OSL, a Dell inicia com 67.06 tok/s e atinge 927.93 tok/s com um tamanho de lote de 64. A GIGABYTE começa um pouco abaixo, com 65.77 tok/s, mas termina com um desempenho melhor, chegando a 994.53 tok/s, enquanto a HP lidera o grupo no limite superior, com 1,009.75 tok/s. A diferença permanece pequena durante a maior parte da análise, com a HP assumindo a liderança a partir do tamanho de lote 32.
No Prefill Heavy, o aumento de produtividade é muito mais expressivo em todos os aspectos. A Dell passa de 164.42 tok/s para 2,097.80 tok/s, a GIGABYTE de 162.96 tok/s para 2,086.72 tok/s, e a HP apresenta o melhor resultado, subindo de 165.95 tok/s para 2,208.16 tok/s. A HP lidera em praticamente todos os tamanhos de lote, enquanto a Dell e a GIGABYTE permanecem bem próximas, especialmente nos tamanhos de lote 32 e 64.
Em Decode Heavy, o desempenho geral é menor, como esperado para a carga de trabalho de decodificação. A Dell varia de 41.20 tok/s a 563.98 tok/s, a GIGABYTE de 40.83 tok/s a 617.96 tok/s e a HP de 41.63 tok/s a 593.56 tok/s. A GIGABYTE apresenta o melhor resultado com um tamanho de lote de 64, enquanto a HP lidera na faixa intermediária e a Dell permanece próxima, mas ligeiramente atrás em níveis de concorrência mais altos.
GPT-OSS-20B
Em comparação com o Equal ISL/OSL, a Dell lidera a maior parte da análise, escalando de 88.73 tok/s no tamanho de lote 1 para 1,953.55 tok/s no tamanho de lote 64. A GIGABYTE vem logo em seguida, aumentando de 88.42 tok/s para 1,904.62 tok/s, enquanto a HP varia de 83.49 tok/s a 1,831.45 tok/s. A Dell mantém a escalabilidade mais forte na faixa superior, principalmente a partir do tamanho de lote 16.
No teste de Prefill Heavy, a taxa de transferência aumenta drasticamente nos três sistemas. A Dell apresenta o melhor resultado, passando de 216.05 tok/s para 4,261.96 tok/s com um tamanho de lote de 64. A GIGABYTE vem em seguida, com 4,011.86 tok/s, enquanto a HP atinge 3,785.25 tok/s. Os três sistemas permanecem bem próximos em tamanhos de lote menores, mas a Dell começa a se destacar a partir do tamanho de lote 16 e amplia sua vantagem durante o restante do teste.
Em Decode Heavy, a escalabilidade é mais gradual, mas permanece robusta em todas as plataformas. A Dell varia de 54.88 tok/s a 1,173.31 tok/s, a GIGABYTE escala de 55.24 tok/s a 1,181.94 tok/s e a HP aumenta de 53.20 tok/s para 1,082.23 tok/s. A GIGABYTE supera ligeiramente a Dell no tamanho de lote mais alto, enquanto a HP fica atrás de ambos os sistemas em níveis de concorrência mais elevados.
Base de instruções Llama 3.1 8B
Em ISL/OSL igual, a Dell escala de 27.69 tok/s para 1,376.38 tok/s com um tamanho de lote de 64, ficando ligeiramente à frente da GIGABYTE, que varia de 27.23 tok/s a 1,372.27 tok/s. A HP fica um pouco atrás em toda a varredura, escalando de 26.89 tok/s para 1,235.32 tok/s. Os três sistemas apresentam desempenhos muito próximos até um tamanho de lote de 16, antes que a Dell comece a abrir uma pequena vantagem em níveis de simultaneidade mais altos.
No Prefill Heavy, a produtividade aumenta drasticamente conforme o tamanho dos lotes aumenta. A Dell passa de 68.60 tok/s para 2,575.25 tok/s, enquanto a GIGABYTE apresenta o melhor resultado, escalando de 67.49 tok/s para 2,694.25 tok/s com um tamanho de lote de 64. A HP atinge 2,315.15 tok/s, mantendo-se competitiva, mas consistentemente atrás da Dell e da GIGABYTE em tamanhos de lote maiores. A GIGABYTE assume a liderança no limite superior, principalmente para tamanhos de lote de 64 ou mais.
No teste Decode Heavy, a escalabilidade permanece estável ao longo de toda a análise. A Dell varia de 17.19 tok/s a 726.22 tok/s, a GIGABYTE de 16.96 tok/s a 720.57 tok/s e a HP de 16.79 tok/s a 663.31 tok/s. Dell e GIGABYTE permanecem praticamente idênticas durante a maior parte do teste, com a Dell apresentando uma ligeira vantagem nos níveis mais altos de simultaneidade. Ao mesmo tempo, a HP fica um pouco para trás em tamanhos de lote maiores.
Lhama 3.1 8B Instruções FP4
Em condições de concorrência ISL/OSL iguais, a Dell escala de 69.71 tok/s para 2,849.20 tok/s com tamanho de lote 64, enquanto a GIGABYTE fica ligeiramente à frente, crescendo de 70.92 tok/s para 2,912.03 tok/s. A HP permanece competitiva, variando de 69.52 tok/s a 2,821.50 tok/s. Os três sistemas permanecem agrupados em toda a carga de trabalho, com apenas uma pequena separação aparecendo em níveis de concorrência mais altos.
No Prefill Heavy, o escalonamento torna-se muito mais agressivo, principalmente em tamanhos de lote maiores. A Dell aumenta de 170.09 tok/s para 4,417.65 tok/s, enquanto a GIGABYTE apresenta o melhor resultado do grupo, subindo de 173.55 tok/s para 4,767.43 tok/s com um tamanho de lote de 64. A HP escala de 170.12 tok/s para 4,214.57 tok/s. A GIGABYTE começa a se destacar dos demais após um tamanho de lote de 32, oferecendo o melhor desempenho em cargas de trabalho de alto desempenho.
No teste Decode Heavy, os três sistemas permanecem bastante alinhados durante a maior parte da varredura. A Dell varia de 43.19 tok/s a 1,260.24 tok/s, a GIGABYTE de 43.53 tok/s a 1,258.05 tok/s e a HP de 42.54 tok/s a 1,178.74 tok/s. Dell e GIGABYTE praticamente alternam a liderança dependendo do tamanho do lote, enquanto a HP fica ligeiramente atrás de ambos os sistemas nos maiores níveis de simultaneidade.
Lhama 3.1 8B Instruções FP8
No teste Equal ISL/OSL, a Dell escala de 46.93 tok/s para 2,206.52 tok/s com um tamanho de lote de 64, enquanto a GIGABYTE varia de 46.16 tok/s a 2,175.44 tok/s. A HP vem logo em seguida, aumentando de 46.40 tok/s para 2,149.15 tok/s. A diferença geral permanece pequena ao longo do teste, com os três sistemas mantendo um comportamento de escalabilidade quase idêntico até o tamanho de lote de 32.
No Prefill Heavy, a taxa de transferência aumenta de forma mais agressiva à medida que a simultaneidade aumenta. A Dell passa de 115.85 tok/s para 3,794.52 tok/s, enquanto a GIGABYTE apresenta o melhor resultado geral, escalando de 113.34 tok/s para 4,133.76 tok/s com um tamanho de lote de 64. A HP atinge 3,624.73 tok/s. A GIGABYTE começa a estabelecer uma vantagem mais acentuada em tamanhos de lote maiores, particularmente a partir do tamanho de lote 32.
No teste Decode Heavy, os três sistemas permanecem agrupados em níveis baixos de concorrência, antes de pequenas separações surgirem em níveis altos de concorrência. O desempenho da Dell varia de 29.11 tok/s a 1,077.07 tok/s, o da GIGABYTE de 28.64 tok/s a 1,068.92 tok/s e o da HP de 28.68 tok/s a 1,000.20 tok/s. A Dell mantém uma pequena vantagem na maior parte da carga de trabalho, com a GIGABYTE logo atrás, enquanto a HP fica ligeiramente para trás em lotes maiores.
Mistral Pequeno 3.1 24B
Em Equal ISL/OSL, a Dell escala de 10.41 tok/s para 498.56 tok/s com tamanho de lote de 64, enquanto a GIGABYTE fica ligeiramente à frente no limite superior, crescendo de 9.76 tok/s para 509.18 tok/s. A HP fica um pouco atrás de ambos os sistemas, variando de 9.25 tok/s a 477.25 tok/s. A diferença entre os sistemas permanece relativamente pequena em toda a carga de trabalho, particularmente em níveis de concorrência mais baixos e intermediários.
No Prefill Heavy, a escalabilidade melhora substancialmente em todos os três sistemas. A Dell aumenta de 25.91 tok/s para 1,079.19 tok/s, enquanto a GIGABYTE escala de 24.25 tok/s para 1,071.07 tok/s. A HP atinge 988.82 tok/s com um tamanho de lote de 64. Dell e GIGABYTE permanecem praticamente idênticas durante a maior parte da análise, com a Dell apresentando uma ligeira vantagem no nível de simultaneidade mais alto.
No teste de decodificação pesada, a taxa de transferência permanece significativamente menor no geral, como esperado para a carga de trabalho focada em decodificação em um modelo maior. A Dell apresenta taxas de transferência que variam de 6.49 tok/s a 297.82 tok/s, a GIGABYTE de 6.10 tok/s a 297.23 tok/s e a HP de 5.77 tok/s a 276.55 tok/s. Dell e GIGABYTE apresentam desempenhos muito próximos durante todo o teste, enquanto a HP fica consistentemente um pouco atrás de ambos os sistemas em tamanhos de lote maiores.
Codificador Qwen3 30B A3B Base
Em ISL/OSL igual, a Dell escala de 59.05 tok/s para 817.82 tok/s com tamanho de lote 64, enquanto a GIGABYTE varia de 59.81 tok/s a 809.88 tok/s. A HP fica ligeiramente atrás de ambos os sistemas, aumentando de 56.51 tok/s para 780.21 tok/s. O desempenho entre Dell e GIGABYTE permanece quase idêntico durante a maior parte da varredura, com apenas pequenas variações aparecendo em tamanhos de lote maiores.
No teste Prefill Heavy, a taxa de transferência aumenta significativamente com o aumento da concorrência. A Dell passa de 144.81 tok/s para 1,756.99 tok/s, enquanto a GIGABYTE apresenta a escalabilidade geral mais forte, aumentando de 147.55 tok/s para 1,862.40 tok/s com um tamanho de lote de 64. A HP atinge 1,751.17 tok/s, mantendo-se competitiva, mas ligeiramente atrás dos outros dois sistemas na extremidade superior. A GIGABYTE estabelece uma pequena vantagem a partir de um tamanho de lote de aproximadamente 32 e a mantém até o estágio final do teste.
Na tarefa de decodificação pesada, os três sistemas permanecem bastante semelhantes durante a maior parte da carga de trabalho. O desempenho da Dell varia de 36.69 tok/s a 427.48 tok/s, o da GIGABYTE de 36.92 tok/s a 417.42 tok/s e o da HP de 35.30 tok/s a 403.32 tok/s. A Dell mantém uma pequena vantagem nos tamanhos de lote mais altos, enquanto a HP fica ligeiramente atrás da Dell e da GIGABYTE na carga de trabalho focada em decodificação.
Codificador Qwen3 30B A3B FB8
Em ISL/OSL igual, a Dell escala de 98.65 tok/s para 1,379.26 tok/s com tamanho de lote 64, enquanto a GIGABYTE varia de 100.20 tok/s a 1,308.79 tok/s. A HP se mantém competitiva em todos os casos, aumentando de 97.06 tok/s para 1,354.23 tok/s. A HP chega a liderar brevemente em vários tamanhos de lote menores e intermediários, embora a Dell termine com o melhor desempenho geral em lotes maiores.
No teste de Prefill Heavy, a taxa de transferência aumenta consideravelmente nos três sistemas. A Dell passa de 240.43 tok/s para 3,041.72 tok/s, enquanto a GIGABYTE apresenta o melhor resultado geral, com um aumento de 245.92 tok/s para 3,088.62 tok/s no tamanho de lote 64. A HP atinge 2,857.80 tok/s. A GIGABYTE estabelece uma vantagem significativa a partir do tamanho de lote 4 e a mantém durante todo o período de testes.
Em Decode Heavy, a Dell apresenta o melhor desempenho geral em escalabilidade de alto nível. A Dell varia de 60.91 tok/s a 705.77 tok/s, enquanto a GIGABYTE escala de 61.53 tok/s a 639.80 tok/s e a HP aumenta de 59.85 tok/s para 635.25 tok/s. A HP chega a liderar brevemente em tamanhos de lote menores, mas a Dell assume a liderança em níveis de concorrência maiores, terminando com a maior taxa de transferência de decodificação do grupo.
Resumo da potência máxima de saída dos sistemas de ignição dupla
A tabela abaixo resume a taxa de transferência máxima de tokens observada durante os testes Distributed PP=2 nos sistemas dual-Spark da Dell, GIGABYTE e HP. Cada valor representa a maior taxa de transferência medida (tok/s) alcançada para esse cenário de carga de trabalho no tamanho de lote testado. Os valores em negrito indicam o sistema com melhor desempenho dentro desse cenário específico de carga de trabalho.
| Modelo | Cenário (BS – 64) | Saída máxima da Dell | Saída máxima da GIGABYTE | Saída de pico HP |
|---|---|---|---|---|
| Modelos GPT-OSS | ||||
| GPT-OSS-120B | ISL/OSL igual | 463.97 tok/s | 497.26 tok/s | 504.88 tok/s |
| GPT-OSS-120B | Pré-enchimento pesado | 419.56 tok/s | 417.34 tok/s | 441.63 tok/s |
| GPT-OSS-120B | Decodificar Pesado | 451.18 tok/s | 494.37 tok/s | 474.85 tok/s |
| GPT-OSS-20B | ISL/OSL igual | 976.77 tok/s | 952.31 tok/s | 915.72 tok/s |
| GPT-OSS-20B | Pré-enchimento pesado | 852.39 tok/s | 802.37 tok/s | 757.05 tok/s |
| GPT-OSS-20B | Decodificar Pesado | 938.65 tok/s | 945.55 tok/s | 865.78 tok/s |
| Modelos de lhama | ||||
| Lhama-3.1-8B-Instruir | ISL/OSL igual | 689.53 tok/s | 687.48 tok/s | 618.87 tok/s |
| Lhama-3.1-8B-Instruir | Pré-enchimento pesado | 515.45 tok/s | 539.27 tok/s | 463.39 tok/s |
| Lhama-3.1-8B-Instruir | Decodificar Pesado | 581.43 tok/s | 576.91 tok/s | 531.07 tok/s |
| Lhama-3.1-8B-FP4 | ISL/OSL igual | 1427.39 tok/s | 1458.86 tok/s | 1413.51 tok/s |
| Lhama-3.1-8B-FP4 | Pré-enchimento pesado | 884.22 tok/s | 954.23 tok/s | 843.57 tok/s |
| Lhama-3.1-8B-FP4 | Decodificar Pesado | 1008.98 tok/s | 1007.23 tok/s | 943.73 tok/s |
| Lhama-3.1-8B-FP8 | ISL/OSL igual | 1105.42 tok/s | 1089.85 tok/s | 1076.68 tok/s |
| Lhama-3.1-8B-FP8 | Pré-enchimento pesado | 759.50 tok/s | 827.40 tok/s | 725.51 tok/s |
| Lhama-3.1-8B-FP8 | Decodificar Pesado | 862.33 tok/s | 855.81 tok/s | 800.78 tok/s |
| Modelos Mistral e Qwen | ||||
| Mistral-Pequeno-3.1-24B | ISL/OSL igual | 249.77 tok/s | 255.09 tok/s | 239.09 tok/s |
| Mistral-Pequeno-3.1-24B | Pré-enchimento pesado | 216.01 tok/s | 214.38 tok/s | 197.92 tok/s |
| Mistral-Pequeno-3.1-24B | Decodificar Pesado | 238.44 tok/s | 237.97 tok/s | 221.41 tok/s |
Conclusão
A descoberta mais útil desta rodada de testes tem pouco a ver com qual fabricante se saiu melhor em qual carga de trabalho. Em todos os modelos e tipos de carga de trabalho testados, as três implementações do Spark da Dell, GIGABYTE e HP apresentaram desempenho semelhante. Pequenas vantagens surgiram em tamanhos de lote específicos, mas nenhuma plataforma se destacou completamente e nenhuma ficou consistentemente atrás. Os compradores que escolherem entre as três devem basear sua decisão no design do chassi, no comportamento térmico, nos termos da garantia e no suporte, em vez de nas diferenças nos benchmarks, que são próximas da variação de desempenho que qualquer sistema desktop apresenta sob carga contínua.
O resultado mais interessante é metodológico. Na malha de 200 GbE que conecta dois Sparks, a escolha entre paralelismo tensorial e paralelismo de pipeline importa mais do que qualquer diferença entre os três fabricantes, e para inferência em lote com qualquer nível razoável de concorrência, o paralelismo de pipeline é a melhor opção. O tráfego all-reduce por camada do TP=2 não sobrevive à travessia de um link ConnectX-7 sem deixar o poder computacional ocioso, e o custo de "bolha" do pipeline do PP=2 se amortiza no fluxo de estado estacionário assim que o lote preenche o pipeline. A documentação da NVIDIA usa TP como padrão por um motivo justificável: seu principal posicionamento para o Spark é o serviço interativo de fluxo único com TTFT (tempo até a primeira execução) curto, que é o único regime em que TP=2 se destaca. No momento em que a carga de trabalho se assemelha mais à infraestrutura de serviço do que a uma interface de bate-papo, o cálculo se inverte.
Essa inversão reforça o que o Spark é e o que não é. Um cluster Spark de dois nós é uma plataforma de desenvolvimento e aprendizado que permite a um único engenheiro observar o comportamento da inferência distribuída em primeira mão, em uma rede rápida o suficiente para simular a infraestrutura de um data center real, mas com restrições suficientes para expor os gargalos que as implantações de produção contornam em grande escala.
Configurações maiores do Spark merecem ser examinadas individualmente, com cargas de trabalho e estratégias de paralelismo adequadas a essa escala, e esse trabalho está em nosso planejamento. Em paralelo, o próximo experimento na fila, após este, muda da inferência para o treinamento: um modelo com menos de 1 bilhão de parâmetros, treinado do zero em um cluster dual-Spark, configurado para espelhar as condições de pré-treinamento distribuído de sistemas muito maiores. Esse trabalho está em pausa enquanto aguardamos a óptica para nosso novo switch de núcleo de laboratório de 800 Gb, e esperamos publicá-lo assim que o novo núcleo estiver online.
Amazon