Qual GPU custa menos para o mesmo resultado de ML?

Definir o que contará como resultado aceito

Escreva a decisão antes dos testes: "Qual configuração processa todos os meus documentos, atende à minha qualidade mínima e termina antes do meu prazo, pelo menor orçamento comprometido?" Fixe o cenário: aqui, um corpus processado offline. Uma aplicação interativa exigiria também definir a chegada das requisições, sua concorrência e a latência admissível; seu ranking não se deduz apenas desse teste.

Chame de corpus validado um conjunto completo de saídas que passa por todos os seus controles. Um arquivo criado ainda não é um resultado aceito. Verifique os identificadores, o formato, a cobertura e uma métrica ligada ao seu uso. Registre o limiar e a tolerância em relação a uma referência antes de olhar os tempos. Assim, duas configurações podem ser equivalentes para a decisão sem produzir números idênticos bit a bit.

Essa separação entre conjunto de dados, objetivo de qualidade e cenário também existe nos princípios do MLPerf Inference. O protocolo abaixo é o nosso método de trabalho, a adaptar ao seu projeto; ele não constitui nem uma execução nem uma certificação MLPerf.

Fontes técnicas: MLCommons — cenários, métricas e objetivos de qualidade

Preparar as entradas, a referência e o manifesto

Você precisa de um corpus que tenha o direito de usar, de respostas de referência ou de um procedimento de avaliação, do código de inferência e de um ambiente capaz de executar o modelo escolhido. Separe os dados usados para ajustar a configuração do corpus final de comparação. Se você ajustar os limiares depois de ver este último, prepare uma nova avaliação independente para sustentar a conclusão.

Dê um identificador estável a cada entrada. Guarde uma impressão digital do corpus, a ordem de passagem, a revisão do modelo e do tokenizer, as versões do código e das dependências. O manifesto descreve também as GPUs utilizadas, a precisão, a quantização, a compilação, o backend de atenção, a política de padding e o comprimento máximo. Uma truncagem diferente mudaria o trabalho a comparar.

Registre o driver e o backend efetivamente presentes. Para uma variante AMD, verifique a combinação de sistema, GPU, ROCm e framework na matriz oficial. Uma documentação consultada ou o nome de uma placa não prova que esse ambiente está instalado. Se as pilhas de software diferirem entre dois ensaios, a conclusão recairá sobre as configurações completas testadas.

Fontes técnicas: AMD — matriz de compatibilidade ROCm

Exemplo: classificar os mesmos 1 000 textos

Eis um experimento a construir com seus dados, sem resultado de desempenho presumido. Você quer classificar 1 000 textos nas categorias do seu projeto. Reserve 600 entradas curtas, 300 intermediárias e 100 longas; defina os limites com o tokenizer escolhido e mantenha uma distribuição representativa das classes. Essa divisão é um exemplo de protocolo, não um corpus fornecido nem uma recomendação universal de proporções.

Compare batches de 1, 4 e 8 com o mesmo modelo, a mesma precisão, a mesma ordem e a mesma regra de padding. A única variável dessa primeira série é o batch. Uma segunda série poderá mudar a precisão ou o hardware, mantendo as outras escolhas explicitamente fixadas. Um agrupamento por comprimento é uma nova variante a declarar, pois modifica a organização do trabalho.

Para cada passagem, exporte as 1 000 previsões com seus identificadores. O controle deve encontrar exatamente os identificadores esperados, sem duplicata nem omissão. Mantenha as previsões erradas: elas servem para o cálculo de qualidade. Remover os exemplos difíceis melhoraria artificialmente a pontuação e reduziria o corpus realmente processado.

Separar inicialização, aquecimento e passagem medida

Registre o download necessário, a instalação, o carregamento e a compilação separadamente do processamento estabilizado. Eles podem ser excluídos do cronômetro de uma passagem, ainda que ocupem parte da locação. Fixe uma regra de aquecimento idêntica para todas as variantes: entradas cobertas, número de passagens e tratamento das recompilações. Não ajuste essa regra depois de ver qual variante se beneficia dela.

Defina os limites do tempo principal. Para este exemplo offline, meça a leitura do corpus, a tokenização, as transferências, a inferência e a materialização das previsões no host. Cronometre em seguida a avaliação e a escrita dos entregáveis separadamente para estabelecer a campanha completa. Uma duração limitada ao cálculo da GPU não se compara diretamente a esse tempo de processamento.

As operações CUDA são assíncronas: um cronômetro no host deve aguardar o fim das operações anteriores antes de sua partida e o fim do trabalho medido antes de sua parada. Eventos CUDA são adequados para um perímetro de GPU corretamente definido. Para uma operação isolada, torch.utils.benchmark.Timer cuida do aquecimento e da sincronização. Mantenha as mesmas fronteiras de medição entre variantes.

Fontes técnicas: PyTorch 2.14 — execução CUDA assíncrona · PyTorch — medir com torch.utils.benchmark

Repetir e conservar as falhas

Preveja cinco passagens completas por variante para esta primeira comparação. Alterne a ordem delas, por exemplo 1–4–8, depois 4–8–1, depois 8–1–4, para que uma única variante não seja sempre a primeira. Mantenha a política de processos, de caches e de aquecimento. Essas cinco passagens descrevem sua pequena série; elas não demonstram por si só a estabilidade em um longo período.

Uma linha da tabela bruta representa uma passagem tentada, incluindo uma interrupção. Ela liga a variante e o corpus aos parâmetros, à duração e ao veredito de qualidade. Os campos expected_ids e observed_ids registram os números de entradas; ids_match confirma a igualdade dos conjuntos, controlada nos arquivos de previsões mantidos separadamente. corpus_accepted contém o veredito da passagem. Registre os erros e o caminho das saídas em notes. Se faltar uma medida, deixe sua célula vazia e indique por quê. A ausência de GPU não é uma medida de zero segundo ou de zero byte.

Se o batch 8 exceder a memória nas entradas longas, mantenha a linha de falha e o número de entradas concluídas. Não substitua silenciosamente essa passagem por um batch menor. O ajuste de retomada se torna uma variante distinta; seu tempo e suas tentativas fazem parte do balanço. Uma interrupção ou um erro de formato nunca é um sucesso econômico só porque foi rápida.

Ler as durações sem superinterpretar cinco ensaios

Apresente as cinco durações brutas, sua mediana, seu mínimo e seu máximo, com o número de sucessos e de falhas. A mediana descreve o centro dessas observações; ela não elimina os incidentes. Se uma passagem for excluída por uma causa externa documentada, mantenha seu registro e aplique a mesma regra de exclusão a todas as variantes.

Não apresente um p95 calculado sobre cinco passagens como uma estimativa robusta dos casos lentos. Para estudar a latência das requisições, colete um conjunto adequado de tempos individuais com o cenário de chegada e a concorrência. As cinco durações de corpus e as latências de 1.000 requisições não são a mesma população.

Se a dispersão observada for comparável à diferença entre as medianas, a série ainda não desempata as opções. Adicione repetições em um protocolo comum ou examine uma causa precisa: carregamento, formas de entrada, compilação, atividade concorrente. Evite reter apenas a melhor passagem de cada placa.

Verificar a qualidade após uma mudança de precisão

Para comparar FP32, BF16 ou uma quantização, parta das mesmas entradas e da mesma referência. Avalie o formato, a métrica principal e os subgrupos previstos. Uma variante que ultrapassa sua tolerância pode ser interessante para outro objetivo; ela não entra na comparação a qualidade equivalente ao baixar o limiar depois.

Registre as sementes e as opções determinísticas utilizadas. O PyTorch não garante reprodutibilidade completa entre versões, plataformas ou execuções em CPU e GPU, mesmo com a mesma semente. Especifique, portanto, o que você busca reproduzir: saídas idênticas, desvio numérico limitado ou qualidade de negócio aceitável. Para um protocolo estocástico, preveja várias sementes comuns e conserve seus resultados separadamente.

Fontes técnicas: PyTorch 2.14 — alcance e limites da reprodutibilidade

Usar a memória como critério de viabilidade

Uma opção deve concluir o corpus com suas entradas longas antes que seu custo seja comparado. Registre o pico de memória por dispositivo e o escopo do contador. Com o PyTorch, memory_allocated acompanha os tensores e memory_reserved a memória gerenciada pelo alocador: esses valores não se somam. Os picos correspondentes podem ocorrer em instantes diferentes.

O notebook da pasta de memória ajuda a distinguir estimativa de observação. Seu exercício não substitui a medição do seu modelo: carregue seu ambiente, mantenha os parâmetros e reexecute sua carga. Uma capacidade anunciada por placa e um preço de lote não permitem deduzir uma vazão, uma interconexão ou uma distribuição automática do modelo entre várias GPUs.

Fontes técnicas: PyTorch 2.14 — contadores e alocador de memória

Escolher a duração com o calendário completo

A duração necessária não é apenas a soma dos kernels de GPU. Construa uma janela de acesso que vá da preparação na locação até a recuperação dos entregáveis: instalação, controles, aquecimento, comparações, retomadas previstas, avaliação e exportação. Adicione os períodos de espera durante os quais você ainda precisa manter a locação. Quando tarefas se sobrepõem, raciocine sobre o calendário real em vez de somar duas vezes suas durações.

Exemplo de cronograma, sem suposição de velocidade: você quer manter o acesso de segunda-feira às 9h até sexta-feira às 9h, no mesmo fuso e fora do horário de verão. Essa janela cobre 96 horas. Ela ultrapassa as 72 horas de um pacote de 3 dias e cabe nas 168 horas de um pacote de 7 dias. Isso não prova que seus processamentos terminarão a tempo: suas durações ainda precisam ser medidas.

A calculadora permite informar sua janela total e exibe os pacotes de 3, 7 e 30 dias. Um pacote que cobre o cronograma se torna um candidato. Se a campanha ultrapassar o período escolhido, modifique o programa ou orce explicitamente os períodos adicionais necessários; não presuma uma prorrogação automática.

Calcular o custo comprometido com nossos pacotes

O orçamento de uma locação é o preço do pacote por lote, multiplicado pelo número de lotes. O custo por corpus validado divide então esse valor total pelos corpus úteis efetivamente aceitos no escopo anunciado. Se nenhum corpus for aceito, o índice é indefinido. A despesa comprometida, por sua vez, permanece no balanço.

Os preços abaixo vêm do nosso catálogo, versão de 24 de setembro de 2026. Eles ilustram a regra de cálculo, sem estabelecer qual GPU termina sua carga mais rápido. Um lote B200 já inclui duas placas: multiplicar seu preço uma segunda vez por dois contaria essas placas em dobro. Assim, dois lotes de RTX 4090 por 7 dias custam 220 USD; um lote de dois B200 por 7 dias custa 2.071 USD.

Uma passagem curta não transforma o pacote em fatura por hora. A calculadora usa o total do pacote, mesmo que parte do período fique sem uso. Para um orçamento de projeto mais amplo, registre separadamente as outras despesas realmente aplicáveis e sua justificativa. Não misture custos medidos em uma das variantes com itens esquecidos na outra.

Fontes técnicas: IteraGPU — pacotes do catálogo

Contar entregáveis úteis, não repetições de medição

As cinco repetições de um mesmo benchmark servem para observar a dispersão. Elas não se tornam cinco corpus de produção úteis só porque cinco arquivos foram gravados. Defina os entregáveis esperados antes da campanha e conte cada entregável aceito apenas uma vez. Se o trabalho real envolver vários corpus, cada configuração deve processar os mesmos corpus e aplicar a mesma regra de qualidade.

Na calculadora, deixe o número de corpus vazio enquanto os entregáveis úteis não estiverem realmente concluídos e validados. A caixa de qualidade confirma sua própria verificação; a ferramenta não lê suas previsões nem suas métricas. Informe apenas a quantidade constatada. A janela de campanha pode ser uma hipótese de planejamento, mas uma previsão de capacidade não substitui resultados aceitos.

O balanço final reúne, para cada configuração admissível, os vereditos de qualidade, as durações brutas, a janela de campanha, o pacote comprometido e o número de entregáveis aceitos. Uma opção rápida pode ser útil para um prazo apertado sem ser a mais barata. Duas opções que cabem no mesmo cronograma podem ser desempatadas pelo seu custo comprometido, suas falhas ou pela incerteza que permanece.

Baixar o protocolo e manter uma prova reutilizável

A pasta IteraGPU Lab v1 reúne os materiais desta comparação e da medição de memória. Comece pelo README e pelo protocolo de qualidade, depois complemente a tabela bruta com suas passagens. As células de desempenho permanecem em branco antes de uma execução; os preços são dados de catálogo, separados das medições.

Para calcular dois lotes de RTX 4090 por 7 dias, coloque calcul_forfaits.py e tarifs-forfaits.csv na mesma pasta, abra um terminal nessa pasta e execute o comando abaixo com Python 3.10 ou mais recente. Ele exibe um forfait de 220,00 USD para duas GPUs. A opção facultativa --accepted-results recebe seu número inteiro de corpus úteis distintos realmente concluídos e validados. Omita-a enquanto esse resultado não existir: o script então calcula apenas o forfait, sem inventar um custo por resultado.

Mantenha juntos o manifesto, as impressões digitais das entradas, as predições, os veredictos e a tabela de tentativas. A nota de decisão indica a configuração escolhida, a carga coberta e o motivo da escolha. Você poderá relacioná-la com sua locação no caderno IteraGPU e relançar exatamente a questão experimental ao mudar de modelo ou de versão.

Esse protocolo offline não qualifica por si só um serviço interativo, um treinamento até a convergência ou outro conjunto de dados. Para esses usos, redefina a unidade útil e os controles antes de comparar. Os arquivos fornecidos servem para preparar e registrar seus ensaios; esta pasta não apresenta nenhuma comparação medida entre as configurações do catálogo nem economia observada.

python calcul_forfaits.py --gpu rtx-4090 --days 7 --lots 2

• IteraGPU Lab v1 — pacote completo ↓

  Arquivo dos scripts, do notebook, das tabelas e das instruções.

• Protocolo de qualidade ↓

  Entradas, critérios de aceitação e regras de comparação a definir antes dos ensaios.

• Tabela de resultados brutos ↓

  Planilha em branco para guardar os parâmetros, as medições, os veredictos e as falhas.

• Cálculo dos forfaits ↓

  Cálculo do orçamento com preço por lote, durações de 3, 7 e 30 dias e corpus validados.

• Tarifas dos forfaits ↓

  Instantâneo dos preços do nosso catálogo usados pelo cálculo fornecido.

• Notebook de medição de memória ↓

  Cálculos e exercício de medição a interpretar com o pacote de memória.

• Script de medição de memória ↓

  Versão Python do exercício, com verificação do ambiente.

• Instruções e pré-requisitos ↓

  Escopo das ferramentas e procedimento para executá-las e guardar as saídas.

• Licença dos recursos ↓

  Condições de reutilização dos recursos originais do pacote.