Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Este artigo apresenta o benchmarking de IA do HPC no Azure. Ele foi projetado para arquitetos, engenheiros e tomadores de decisão que precisam:
- Avaliar a infraestrutura do Azure para cargas de trabalho novas ou existentes
- Estabelecer linhas de base de desempenho
- Comparar famílias de VM usando dados objetivos
- Otimizar o desempenho e a eficiência de custo
Por que o benchmarking importa
O benchmarking fornece insights baseados em evidências que dão suporte a decisões técnicas e de negócios. Ele serve a várias finalidades críticas para cargas de trabalho de HPC e IA:
- Escolha a infraestrutura certa: alinhe as características de carga de trabalho à família de máquinas virtuais do Azure mais adequada.
- Validar o desempenho: confirme se os sistemas implantados atendem às metas de taxa de transferência e latência esperadas.
- Otimizar configurações: identifique gargalos em computação, memória, armazenamento e rede.
- Analisar a eficiência de custo: compare as taxas de preço-desempenho entre as opções de VM.
- Dar suporte a decisões de aquisição: forneça dados de desempenho repetíveis e defensáveis aos stakeholders.
Principais métricas de desempenho
Entender as principais métricas usadas para medir o desempenho do sistema HPC é essencial para uma avaliação e comparação significativas do sistema. Eles fornecem medidas objetivas para comparação, identificam gargalos do sistema, permitindo o ajuste de desempenho e ajudam a prever o desempenho do aplicativo. As métricas variam de acordo com o tipo de carga de trabalho, mas geralmente se enquadram em quatro categorias.
As métricas de desempenho de computação descrevem a capacidade bruta de processamento de um sistema e a eficiência com que essa funcionalidade é realizada na prática. FLOPS (operações de ponto flutuante por segundo) são comumente usados para quantificar a taxa de transferência computacional e geralmente são relatados por parâmetros de comparação, como HPL (LINPACK). Embora o desempenho de pico represente a capacidade máxima teórica do hardware, o desempenho sustentado reflete o que os aplicativos realmente alcançam em cargas de trabalho reais e, portanto, é um indicador mais significativo para a maioria das avaliações.
Famílias de VM do Azure para HPC e IA
O Azure fornece famílias de VM especializadas ajustadas para diferentes padrões de carga de trabalho.
HPC baseado em CPU (série HB)
As VMs da série HB são otimizadas para largura de banda de memória e rede de baixa latência, tornando-as adequadas para cargas de trabalho HPC tradicionais, como:
- CFD (dinâmica de fluido computacional)
- Modelagem do tempo e do clima
- Análise de elemento finito
As principais características incluem:
- Processadores AMD EPYC de alta contagem de núcleos
- Largura de banda de memória grande (incluindo HBM em gerações mais recentes)
- Rede InfiniBand de alta velocidade
IA baseada em GPU (série ND)
As VMs da série ND foram projetadas para cargas de trabalho aceleradas por GPU, incluindo:
- Treinamento de aprendizado profundo
- Inferência de Modelos de Linguagem de Grande Escala (LLM)
- Pesquisa e experimentação de IA
Estas VMs possuem:
- NVIDIA data center GPUs (H100, H200, Blackwell)
- Capacidade de memória de GPU grande
- Interconexões GPU-para-GPU e GPU-para-rede de alta largura de banda
Categorias de benchmarking
Diferentes parâmetros de comparação respondem a perguntas diferentes. Selecione parâmetros de comparação com base no aspecto do desempenho que você deseja avaliar.
Parâmetros de comparação sintéticos
Os parâmetros de comparação sintéticos isolam componentes específicos do sistema e são úteis para validação de linha de base:
- STREAM – Mede a largura de banda de memória sustentável
- HPL (LINPACK) – Mede o desempenho de pico de computação em ponto flutuante
- HPCG – Avalia o desempenho da álgebra linear esparsa, mais próxima das cargas de trabalho de HPC do mundo real
- OSU Micro-Benchmarks – valida a latência e a largura de banda de MPI
- Testes NCCL – Mede o desempenho da comunicação coletiva de GPU
Parâmetros de comparação de aplicativo
Os parâmetros de comparação de aplicativo refletem o comportamento do mundo real e geralmente são mais representativos:
- ANSYS Fluent – Desempenho do solucionador de CFD
- WRF – Modelagem meteorológica e atmosférica
- GROMACS/NAMD – Taxa de transferência de dinâmica molecular
- Treinamento MLPerf – desempenho do treinamento de IA de ponta a ponta
- Inferência MLPerf – Modelo que atende taxa de transferência e latência
Como começar
Siga este caminho recomendado para iniciar o benchmarking no Azure:
1. Set up infrastructure
└── Setting Up Your First HPC Cluster (CycleCloud + Slurm)
2. Run baseline benchmarks
├── Running Your First Benchmark: STREAM (CPU/memory)
└── Running NCCL Benchmarks (GPU communication)
3. Compare VM options
├── CPU HPC VMs Comparison
└── GPU AI VMs Comparison
4. Optimize for your workload
└── Optimizing NCCL for Azure (AI training)
Práticas recomendadas
A seguir estão algumas diretrizes para parâmetros de comparação confiáveis e reproduzíveis:
Antes de fazer benchmark
- Usar imagens otimizadas para HPC/IA: comece com imagens de HPC do Azure (AlmaLinux-HPC, Ubuntu-HPC) que incluem drivers e bibliotecas pré-configurados
- Verificar versões do driver: verifique se os drivers de GPU, os drivers InfiniBand e as versões NCCL são atuais
- Verificar topologia: Confirmar a configuração NUMA e a afinidade GPU-NIC
Durante a comparação de desempenho
- Execuções de aquecimento: descartar execuções iniciais para permitir que os caches se estabilizem
- Várias iterações: execute pelo menos 5 iterações e relate a mediana ou a média
- Condições consistentes: manter o sistema operacional, drivers e configurações idênticos entre comparações
- Documente tudo: registrar versões de software, variáveis de ambiente e parâmetros de linha de comando
Armadilhas comuns a serem evitadas
- Períodos de aquecimento insuficientes
- Comparando diferentes versões de software
- Ignorando a topologia NUMA
- Usando configurações padrão sem otimização
- Tamanhos de exemplo inadequados