O desempenho por dólar está ficando mais rápido e mais barato

 (wafer.ai)
1 pontos por GN⁺ 4 시간 전 | 1 comentários | Compartilhar no WhatsApp
  • Enquanto a demanda por inferência supera a oferta e os custos de GPUs da NVIDIA e de tokens sobem, a AMD MI355X surge como uma alternativa de inferência de baixo custo, com preço médio por GPU cerca de 2,75 vezes menor que o da B300
  • A linha AMD Instinct MI350 compete com Blackwell no nível do silício, mas a vantagem em software e o suporte day-0 da NVIDIA determinam a velocidade real de serving e a dificuldade de adoção
  • A Wafer otimizou o GLM-5.2 na MI355X e atingiu 2626 tok/s/node e 2.4 rps em uma carga com 20k de entrada / 1k de saída e 60% de cache hit, o que equivale a 80% do desempenho medido na B200
  • Em stream único, registrou 213 tok/s com 10k tokens de entrada / 1,5k tokens de saída e, embora não lidere o ranking, considera ter vantagem em custo por desempenho
  • Como esse resultado foi obtido sem kernels customizados, apenas com correções de bugs no framework, quantização, speculative decode e ajuste fino da seleção de kernels MoE, o desafio da AMD passa a ser cada vez mais de suporte do que do próprio software

Custo de inferência da AMD e a diferença de software da NVIDIA

  • A demanda por inferência está crescendo rapidamente e superando a oferta, enquanto modelos de ponta como Claude Fable, GLM-5.2 e Minimax M3 estão surgindo quase a cada duas semanas, ampliando também a demanda por tokens
  • Como a oferta de Blackwell não é suficiente, os preços das GPUs da NVIDIA e o custo por token estão subindo juntos
  • A AMD MI355X custa, em média, cerca de 2,75 vezes menos por GPU que a B300, com especificações de hardware em nível comparável
  • A linha AMD Instinct MI350 compete com Blackwell no nível do silício, mas a NVIDIA consegue servir inferência dos modelos mais recentes com mais rapidez e menos atrito graças ao suporte day-0 e ao seu ecossistema de software
  • Na MI355X e na stack ROCm, muitas vezes o desempenho SOTA de modelos de ponta mais recentes não vem pronto por padrão, e pode ser difícil até encontrar uma imagem executável
  • Sem suporte day-0, são necessárias semanas de engenharia e compute para compilar e otimizar os modelos mais recentes; nesse meio-tempo, surgem modelos ainda mais novos, mantendo a AMD sempre correndo atrás

Desempenho do GLM-5.2 na MI355X

  • A Wafer avalia que, à medida que agentes melhoram na otimização de kernels e modelos, a diferença prática entre AMD e NVIDIA está diminuindo
  • Em uma carga com 20k de entrada / 1k de saída e 60% de cache hit, atingiu 2626 tok/s/node
    • RPS sustentado de 2.4 rps
    • O knee definido foi TTFT de no máximo 5 segundos
    • Equivale a 80% do desempenho medido na B200
    • A MI355X custa mais de 2 vezes menos
RPS sustentado tok/s/node agregado TTFT p50 / p95 Taxa de sucesso
0.5 449 0.59s / 0.60s 100%
1.0 974 0.60s / 0.81s 100%
1.5 1913 0.62s / 1.03s 100%
2.0 1944 0.62s / 1.05s 100%
2.25 2089 0.63s / 1.23s 100%
2.4 saturado 2626 0.81s / 2.22s 100%
  • Seguindo o critério da Artificial Analysis, o GLM-5.2 em stream único atingiu 213 tok/s com 10k tokens de entrada / 1,5k tokens de saída
  • Esse número não coloca o modelo no topo do ranking da Artificial Analysis, mas a Wafer considera que ele leva vantagem em custo por desempenho
  • O teste foi servido na capacidade AMD MI355X da TensorWave

Quantização e escolha do framework de inferência

  • A primeira etapa foi a escolha da quantização e do framework, e a Wafer quantizou o GLM-5.2 baseado em bf16 para MXFP4 com o AMD Quark
  • Em comparação com a quantização FP8 oficial da z-ai, o MXFP4 foi avaliado como praticamente sem perdas em GPQA-Diamond, tau2 e GSM8K
Avaliação Referência FP8 MXFP4 Δ
GSM8K, 200 questões, 5-shot, greedy 0.965 ± 0.013 0.955 ± 0.014 −0.010
GPQA-Diamond, 198 questões × 2 seeds, temp 1.0 0.9217 ± 0.027 0.9026 ± 0.029 −0.019
tau2 macro 0.819 0.834 +0.015
  • Os candidatos a framework de inferência eram vLLM, ATOM e sglang
    • O vLLM não conseguia executar o caminho MXFP4 + GlmMoeDsa, então não aproveitava as vantagens dos pesos MXFP4
    • O ATOM apresentava queda de qualidade de saída em contextos longos
    • O sglang tinha o menor atrito até o suporte nativo, aproveitando a quantização e mantendo saídas consistentes

Dois problemas que impediam o speculative decode

  • Para melhorar o throughput, a equipe tentou ativar speculative decode no sglang, mas a imagem ROCm do sglang não oferecia esse suporte por padrão
  • Para que o MTP funcionasse corretamente, foram necessárias duas correções
  • O primeiro problema era que o shared expert do head MTP era armazenado em bf16, mas a busca de quantização do sglang tentava construí-lo em MXFP4 devido a uma incompatibilidade no prefixo do módulo
    • O Quark nomeia o shared expert em bf16 como model.layers.78.mlp.shared_experts.*
    • O prefixo real da camada MTP é model.decoder.*
    • Por causa dessa inconsistência, no carregamento o sistema tentava ler pesos bf16 em largura total em slots 4-bit de meia largura, e a inicialização falhava por shape mismatch
    • A Wafer copiou mais uma vez os itens da camada 78 para o nome de decoder realmente usado pelo sglang, liberando o speculative decode e quase triplicando o throughput em stream único
  • O segundo problema era o bloqueio de speculative decode profundo, como a configuração 5/1/6 proposta pela z-ai
    • O kernel fused multi-step metadata necessário para draft depth 4 ou mais escrevia #include <cuda_runtime.h> sem guard para ROCm
    • A correção foi feita com um único guard #ifdef USE_ROCM
  • Depois que o speculative decode passou a funcionar corretamente, ajustes adicionais como --kv-cache-dtype fp8_e4m3 e --enable-aiter-allreduce-fusion levaram o decode em stream único a 213 tok/s

Gargalo de throughput agregado e ajuste de MoE

  • Na carga definida, otimizar apenas o decode não era suficiente, e com 20k de entrada e 60% de cache a principal limitação era o prefill
  • Em uma configuração TP8 voltada para decode em stream único, a MI355X executava o GLM-5.2-MXFP4 a 1461 tok/s/node
  • Ao migrar para TP4×DP2, atingiu 1944 tok/s/node e 2.0 RPS na mesma carga
  • Ainda assim, o desempenho medido pela Wafer em Blackwell foi de 3192 tok/s/node a 3.0 RPS, e o prefill da MI355X era relativamente mais lento
  • Um dos principais motivos foi que o fp4 MoE do GLM-5.2, na imagem do sglang, caía silenciosamente em um fallback heurístico lento do FlyDSL
    • O aiter fornece configurações ajustadas apenas para o caminho a8w8/fp8
    • A Wafer ajustou manualmente a seleção de kernels MoE para corresponder ao shape fp4 do GLM
    • O shape-alvo era model_dim 6144, moe_inter 2048, E=256, topk=8
  • Com esse ajuste, o throughput agregado chegou a 2626 tok/s/node e 2.4 RPS

O que é necessário para obter desempenho SOTA na AMD

  • O processo para atingir o melhor custo por desempenho na MI355X teve algum atrito, mas foi considerado não especialmente difícil
  • Ao contrário do trabalho com o Qwen3.5 397B, desta vez não foram escritos kernels customizados
  • Este estudo não considerou desempenho multinó, mas implantações em nó único continuam amplamente usadas em ambientes reais
  • O desafio de obter desempenho SOTA na AMD está se tornando cada vez mais uma questão de suporte do que do próprio software
  • A conclusão é que o moat do CUDA está enfraquecendo em tempo real

Leituras relacionadas

1 comentários

 
GN⁺ 4 시간 전
Comentários do Hacker News

  • Eu gostaria que comparações como essa também incluíssem desempenho por watt como métrica. Queria saber onde a AMD realmente fica em custo versus desempenho
    Conversando com empresas que querem construir data centers fora dos EUA, elas dizem que é difícil conseguir volume suficiente de Nvidia em escala adequada
    Se a AMD for competitiva em desempenho por watt e o suporte de software também for em geral confiável, isso importa bastante, já que fora dos EUA a eletricidade muitas vezes é relativamente cara
    Se ela tornar viáveis pequenos data centers por um preço adequado, parece que a AMD pode virar parte da stack em regiões onde a oferta da Nvidia é limitada
    Dito isso, não sei como é na prática a aquisição de GPUs AMD, e fora a Wafer nos EUA e algumas poucas empresas, quase nunca vejo empresas usando AMD, então talvez eu esteja preso dentro da bolha da Nvidia

    • Um DGX B200 custa algo em torno de US$ 500 mil e consome cerca de 14 kW
      Assumindo operação contínua a 100% por 8 anos, isso dá cerca de 1 GWh, o que mesmo em um lugar com eletricidade cara como a Alemanha fica em algo como 100 mil euros, então em comparação com o custo inicial de US$ 500 mil do equipamento não é tão relevante ao longo de 8 anos
      O verdadeiro problema do alto consumo de energia não é a conta de luz, mas o limite de fornecimento elétrico que se consegue trazer para o data center. Uma configuração mais eficiente significa que dá para colocar mais equipamentos dentro de uma entrada de energia limitada
    • Há alguns lugares usando AMD, e há ainda mais lugares começando a experimentar. Mas a AMD decepcionou por tanto tempo nessa área que ainda sou cauteloso em ficar otimista achando que finalmente haverá concorrência de verdade
      O mercado realmente precisa de um concorrente real para a Nvidia, e especialmente com desempenho/watt importante
    • A Meta usa AMD: https://www.amd.com/en/newsroom/press-releases/2026-2-24-amd...
      A OpenAI também: https://www.amd.com/en/newsroom/press-releases/2025-10-6-amd...
    • Também vale lembrar que a AMD vem basicamente dominando o lado de hardware dos consoles de videogame há vários anos. E não há sinal de que isso vá acabar tão cedo
    • Em geral, se uma empresa é grande o bastante para a Nvidia não conseguir atender todos os pedidos dela, ela provavelmente tem pelo menos algumas GPUs AMD

  • É legal, mas em uso real quase nunca há casos em que a quantização FP4 seja de fato sem perdas. Muitos provedores anunciam altas taxas de tokens por segundo com Kimi e GLM, mas o modelo acaba funcionalmente capado e já não fica perto da qualidade de ponta
    Espero que isso não seja verdade

    • O Kimi usa INT4 como formato padrão, então para esse modelo não existe a ideia de “melhor que precisão de 4 bits”
      Isso é diferente do GLM, cujo padrão é 16 bits e que também costuma usar 8 bits
    • A MI355X consegue fazer operações FP6 na mesma velocidade de FP4. Isso é uma característica exclusiva da AMD
      Então o ideal seria criar uma quantização MXFP6 que seja quase sem perdas e fique muito mais perto do desempenho de FP4 do que de FP8
    • A Nvidia também não afirma que NVFP4 é sem perdas?
      Eu não testei modelos convertidos pela Nvidia para NVFP4 o bastante além do GLM 5.2, mas me pareceu ok
      Na prática, a experiência variou bastante de modelo para modelo
    • Foi a primeira coisa que me chamou atenção também
    • Pelo que lembro, ficava em algo como 96~98% da precisão

  • Achei que iam discutir caminhos para melhorar ficando mais rápido e barato, mas neste texto parece que estão oferecendo a versão quantizada pelo mesmo preço da versão completa, e vendendo a versão rápida por muito mais

  • Isso não é quase óbvio? Desempenho por dólar deveria melhorar só em uma direção, como uma catraca. Como algo mais caro substituiria algo mais barato?

  • Acho que deveria ser ilegal publicar título assim sem especificar o método de quantização

    • É MXFP4
    • Também queria que proibissem usar “Why this matters” no título
    • Um bom filtro é ver se termina em .ai. Se terminar, há uma chance altíssima de ser conteúdo de baixo esforço, caça-cliques, raso, inútil ou enganoso

  • Computação em memória e paradigmas neuromórficos provavelmente vão empurrar muito mais essa tendência na próxima década
    À medida que melhorias mais radicais saírem dos laboratórios, novos materiais e nanodispositivos devem acabar entrando em cena, e a eficiência pode melhorar em várias ordens de grandeza
    Só de escalar tecnologias existentes como MRAM já há espaço para isso

  • Ao passar de fp8 para mxfp4 há uma perda de precisão perceptível

    • A Wafer encerrou seu plano principal de coding, o Wafer Pass, poucas semanas após o lançamento, e ainda teve que fazer reembolsos proporcionais
      Mesmo assim, agora está se gabando de ter reduzido ainda mais os custos com quantização, apesar de a implementação claramente deixar a desejar
      [1] https://www.ycombinator.com/launches/Q9i-wafer-pass-flat-rat...
    • E ainda assim, de algum jeito, afirmaram que era “sem perdas”.

  • Isso não é um fenômeno novo. Desempenho por dólar vem melhorando de forma exponencial e bastante consistente desde por volta de 1900
    1900~2010: https://www.thekurzweillibrary.com/exponential-growth-of-com...
    1939~2023: https://medium.com/@timventura/kurzweils-law-for-the-ai-age-...

  • Não surpreende competir com Blackwell. Rubin é 5 vezes mais rápido que Blackwell em inferência, e Blackwell é a última geração que a Nvidia não otimizou especificamente para inferência
    Se deixei passar algo, gostaria de saber

    • Não está nada claro o que exatamente haveria de especial no Rubin para dizer que ele foi otimizado para inferência
      Dá para ver uma configuração desagregada separando nós de prefill e nós de decoding, mas fora isso não sei o que mais haveria
    • Se a inferência está limitada por largura de banda de memória, como ela poderia ficar 5 vezes mais rápida? Conseguir 5 vezes a largura de banda de memória de um H100 parece fisicamente difícil

  • Especialmente agora que várias moedas estão se desvalorizando