GPU H200: arquitetura, desempenho e guia de implantação na nuvem

GPU H200: arquitetura, desempenho e guia de implantação na nuvem

A GPU NVIDIA H200 é um acelerador para data center da geração Hopper cuja característica definidora para implantação é a memória: 141 GB de HBM3e e 4,8 TB/s de largura de banda de memória por GPU. Isso muda a forma de planejar inferência com contexto longo, lotes grandes e trabalhos de HPC limitados por memória — mas não torna opcional o planejamento de capacidade ou a validação na nuvem.

Este guia explica o que é a GPU H200, como H200 SXM e H200 NVL diferem, quando ela é adequada para uma carga de trabalho e como validar uma implantação na nuvem antes de assumir o compromisso com uma frota maior. Ele evita deliberadamente snapshots voláteis de preços de provedores. Use a lista de verificação abaixo com a região, o tipo de máquina, a topologia e o contrato exatos disponíveis para você.

A resposta curta

Escolha uma GPU H200 quando sua carga de trabalho for limitada pela capacidade ou pela largura de banda da memória da GPU e quando você puder validar o sistema ao redor — não apenas o acelerador. Para um servidor de modelos com uma única GPU, isso significa comprovar que os pesos do modelo, o espaço de trabalho do runtime e o cache KV cabem com margem de segurança. Para treinamento ou serving com várias GPUs, significa comprovar a malha GPU a GPU e, quando aplicável, a rede entre os nós.

A GPU H200 não é uma atualização universal. Se as solicitações forem curtas, os tamanhos de lote forem baixos ou a carga de trabalho for limitada por CPU, armazenamento ou rede, sua memória extra poderá não mudar o resultado que importa. Comece com um resumo da carga de trabalho e, depois, teste um trace representativo.

Especificações da GPU H200: o que muda seu plano de implantação

A NVIDIA lista a H200 como uma GPU de arquitetura Hopper com 141 GB de memória HBM3e e 4,8 TB/s de largura de banda de memória. Ela está disponível como H200 SXM e H200 NVL, com os mesmos números de memória em destaque, mas diferentes formatos físicos, limites de energia e opções de escalabilidade. Os números de pico publicados pela NVIDIA para Tensor Cores são úteis para comparar configurações de produtos, mas não são uma promessa de throughput da aplicação: os valores incluem condições de teste declaradas e premissas de esparsidade. Revise as especificações atuais do produto H200 antes de selecionar uma SKU.

Estes são números publicados pelo fornecedor, e a NVIDIA os classifica como preliminares em sua página de produto. Trate-os como uma referência de configuração e, depois, verifique a SKU exata da nuvem e sua topologia no ambiente em que você executará a carga.

Por que HBM3e é importante para a inferência de LLMs

Para servir LLMs, a memória da GPU é consumida por mais do que os pesos do modelo. Uma equação útil de primeira aproximação para capacidade é:

memória de GPU necessária = pesos + espaço de trabalho do runtime + cache KV no contexto p95 e simultaneidade + margem de segurança operacional

A GPU H200 pode ser atraente quando o cache KV se torna o termo limitante: prompts mais longos, mais sequências simultâneas ou um lote maior podem elevá-lo. A HBM adicional não elimina o risco de falta de memória, pois a política de cache, o comportamento do alocador, a quantização, o paralelismo de modelo e o formato do tráfego ainda importam. Para implantações de contexto longo, associe essa decisão a um plano de offload e tiering de cache KV, em vez de presumir que mais memória local é toda a resposta.

H200 SXM ou H200 NVL: escolha a topologia, não apenas a placa

O formato físico é uma escolha de implantação.

• H200 SXM é adequada para projetos de sistemas HGX H200 e NVIDIA-Certified com quatro ou oito GPUs. Geralmente, é o ponto de partida certo quando uma carga de trabalho precisa de um sistema com várias GPUs fortemente acoplado e a aplicação trocará dados frequentemente entre GPUs.
• H200 NVL é um projeto PCIe de slot duplo resfriado a ar. A NVIDIA lista configurações de ponte NVLink de 2 ou 4 vias, enquanto sistemas de parceiros e certificados podem conter até oito GPUs. Não deduza que todo servidor com oito GPUs oferece o mesmo caminho direto de GPU a GPU; inspecione a topologia real e avalie o desempenho das coletivas usadas pelo seu runtime.
• Réplicas independentes não precisam automaticamente da malha mais fortemente acoplada. Se cada réplica atende às suas próprias solicitações, priorize capacidade, disponibilidade, recursos do host e um limite de agendamento claro antes de pagar por uma topologia que a carga de trabalho não usará.

A NVIDIA documenta a capacidade MIG da H200, mas não trate os modos de compartilhamento de GPU como intercambiáveis. No Kubernetes, o MIG cria instâncias de GPU isoladas por hardware, enquanto a divisão de tempo intercala o trabalho e não fornece isolamento de memória ou de falhas entre réplicas. O guia de compartilhamento do GPU Operator explica o trade-off e seus limites de monitoramento.

Para uma comparação de compra mais aprofundada, consulte H200 vs. H100. Essa comparação é útil para a decisão; esta página é o manual de implantação quando a H200 é a candidata.

Quando uma GPU H200 é a escolha certa

Em geral, vale a pena testar uma GPU H200 quando uma destas restrições é real em produção:

1. Inferência de LLM limitada por memória. O comprimento de contexto p95 ou a concorrência esgota o orçamento prático de memória antes de o processamento ser totalmente utilizado.
2. IA ou HPC sensível à largura de banda. A criação de perfil mostra que o trabalho passa um tempo significativo esperando pela movimentação de memória, em vez de apenas saturar os cálculos dos Tensor Cores.
3. Um conjunto de trabalho residente em memória maior. Você precisa de mais espaço para um modelo, contexto de recuperação, lote, cache ou estrutura de dados científicos sem adicionar imediatamente outra GPU.
4. Trabalho multi-GPU fortemente acoplado. Você pode usar um sistema no estilo H200 SXM/HGX e tem evidências de que a aplicação se beneficia de seu fabric.
5. Um requisito de particionamento controlado. Você tem um motivo claro para usar as configurações MIG listadas, além de um agendador e um modelo de cobrança compatíveis com elas.

Não selecione a GPU H200 somente com base na contagem de parâmetros do modelo. A contagem de parâmetros diz pouco sobre precisão, espaço de trabalho do runtime, política de cache KV, contexto máximo, formato do lote e margem de disponibilidade. Ela também não diz nada sobre o gargalo de CPU do host, RAM, armazenamento ou rede que pode dominar uma carga de trabalho na nuvem.

Crie um plano de capacidade para H200 antes de alugar uma GPU na nuvem

Use este resumo de uma página antes de criar uma instância ou solicitar um pool de nós de cluster.

O valor deste resumo é tornar uma inadequação visível cedo. Por exemplo, uma configuração de uma GPU pode falhar devido ao contexto p95 e à pressão de cache, mesmo quando um teste sintético com prompts curtos parece excelente. Por outro lado, uma configuração multi-GPU pode ter desempenho inferior se estiver dividida em um fabric que o runtime não usa com eficiência.

Implantação na nuvem: um runbook escalonado para GPU H200

1. Confirme a configuração exata da nuvem

Peça ao provedor ou à equipe de plataforma o formato exato do acelerador, a contagem de GPUs, a alocação de CPU/RAM, o armazenamento local e persistente, as características de rede e a topologia de GPU. Registre a resposta no ticket de implantação. Apenas “H200” não é informação suficiente para estimar o desempenho multi-GPU.

Antes de reservar capacidade, valide estes detalhes em um piloto de curta duração:

• H200 SXM ou H200 NVL
• contagem de GPUs e a saída de nvidia-smi topo -m
• se a instância é exclusiva, particionada ou com divisão de tempo
• versões do driver, CUDA, runtime de contêiner e framework
• RAM de host disponível, núcleos de CPU, throughput de armazenamento e caminho de rede
• tempos de obtenção da imagem, download do modelo, checkpoint e reinicialização

2. Instale um caminho de software compatível

Para uma implantação no Kubernetes, o GPU Operator da NVIDIA pode gerenciar o driver NVIDIA, o toolkit de contêineres, o plugin de dispositivo, o GPU Feature Discovery, o monitoramento baseado em DCGM e componentes relacionados. O guia oficial de instalação destaca a consistência do sistema operacional dos nós quando o Operator gerencia drivers, bem como os pré-requisitos de runtime de contêiner e segurança de namespace. Siga as orientações atuais de instalação do GPU Operator em vez de copiar uma versão desatualizada do chart.

Uma instalação inicial segue este padrão; substitua a versão por uma que você tenha validado com seu cluster e sua política de drivers:

helm install --wait gpu-operator \
  -n gpu-operator --create-namespace \
  oci://nvcr.io/nvidia/cloud-native-charts/gpu-operator \
  --version=<validated-operator-version>

Após a instalação, valide os pods do Operator e o estado de ClusterPolicy antes de enviar a primeira carga de trabalho. O guia do Operator também mostra como confirmar que os nós reportam um recurso nvidia.com/gpu alocável.

3. Torne o agendamento explícito

Comece com uma solicitação exclusiva de GPU completa, a menos que você tenha projetado deliberadamente para um modo de compartilhamento:

resources:
  limits:
    nvidia.com/gpu: 1

Use um rótulo de pool de nós controlado pela plataforma ou um seletor de nuvem para direcionar aos nós H200 verificados; não codifique um rótulo de produto de um cluster de exemplo. O Kubernetes documenta o agendamento de GPUs por meio de plugins de dispositivo e recursos estendidos, incluindo o padrão de limite de recursos acima. Consulte a documentação de agendamento de GPUs do Kubernetes para conhecer o contrato atual.

Se você ativar o MIG, primeiro drene ou isole os nós relevantes. A NVIDIA observa que alterar o modo ou a geometria do MIG exige que as cargas de trabalho dos usuários estejam fora das GPUs e pode exigir uma reinicialização em alguns ambientes de nuvem. Revise o procedimento de MIG do GPU Operator antes de tratar alterações de partição como uma operação online.

4. Comprove uma carga de trabalho simples e, depois, sua carga de trabalho real

Execute três etapas de validação em ordem:

1. Validação da plataforma: o driver e o CUDA são carregados; o agendador vê o número esperado de GPUs; o contêiner pode criar um contexto CUDA.
2. Validação da interconexão: a topologia corresponde ao projeto previsto; os runtimes multi-GPU são inicializados e concluem um teste coletivo representativo.
3. Validação da aplicação: uma reprodução de prompts representativos, tamanhos de lote, comprimentos de contexto, padrões de checkpoint ou entradas de simulação atinge a meta exigida de latência, throughput e erros.

A terceira etapa é a etapa de decisão. Um benchmark genérico pode dizer que a GPU funciona; ele não pode dizer se sua distribuição de tráfego, seu servidor de modelos e sua política de cache funcionam.

Valide o desempenho antes de escalar

Crie testes de aceitação em torno do gargalo esperado e, em seguida, inspecione o resultado que pode refutar a premissa.

O NVIDIA DCGM separa o monitoramento passivo de integridade dos diagnósticos ativos. Seus fluxos de trabalho de diagnóstico podem testar caminhos de implantação, memória, PCIe, NVLink, computação, energia, térmicos e comunicação, mas consomem recursos e podem entrar em conflito com o trabalho de produção. Drene os nós ou agende uma janela de manutenção antes de executar um diagnóstico invasivo. Use as orientações atuais de diagnósticos do DCGM para selecionar o nível de teste apropriado.

Para serviços de LLM, acompanhe sinais tanto da aplicação quanto da infraestrutura:

• tempo p50/p95 até o primeiro token e latência entre tokens
• tokens de saída aceitos por segundo e solicitações concluídas por segundo
• profundidade da fila, cancelamentos, novas tentativas e taxa de erros
• memória de GPU alocada versus reservada, utilização da GPU, energia e temperatura
• comportamento de acertos/offload do cache e falhas relacionadas ao cache
• saturação da CPU do host, pressão de RAM, E/S de modelo/checkpoint e latência de rede

Se uma métrica melhora enquanto outra piora, ainda não escale. Uma taxa de tokens mais alta com latência p95 ou novas tentativas crescentes pode representar uma regressão para o serviço voltado ao cliente.

Otimize o custo pelo trabalho concluído, não pelo tempo de GPU por hora

As tarifas de GPUs H200 na nuvem variam conforme a região, o prazo de reserva, a configuração do host e a oferta, portanto uma tabela de preços estática fica desatualizada rapidamente. Em vez disso, use uma unidade de carga de trabalho que evidencie o tempo ocioso e o trabalho com falha:

custo horário totalmente carregado = acelerador + CPU/RAM anexadas + armazenamento + rede + licenças + sobrecarga operacional

custo por solicitação concluída = custo horário totalmente carregado / solicitações concluídas por hora

custo por milhão de tokens de saída aceitos = custo horário totalmente carregado / tokens de saída aceitos por hora × 1,000,000

Calcule isso com a mistura de tráfego que você espera lançar, não com uma demonstração de throughput máximo. Inclua a capacidade mantida para failover, carregamento de modelos, checkpoints e manutenção. Para um modelo mais detalhado, consulte Custo de LLM auto-hospedado por milhão de tokens.

Há também uma questão de limite: você precisa operar o runtime ou precisa de acesso confiável às saídas do modelo? Se precisar de kernels personalizados, de um runtime específico, de localidade de dados dedicada ou de experimentação de hardware controlada, um piloto de GPU H200 na nuvem pode ser justificável. Se você precisa principalmente de uma API de modelo, compare a carga operacional com o caminho da API antes de se comprometer com a infraestrutura. O guia de implantação de servidor GPU e o guia de cluster de GPU no Kubernetes podem ajudar a tornar esse limite explícito.

Checklist de implantação da GPU H200

Antes de considerar uma implantação de H200 pronta, verifique todos os itens a seguir:

• [ ] Formato exato da H200, número de GPUs e topologia registrados
• [ ] Orçamento de memória testado no contexto p95 e na simultaneidade esperada
• [ ] Compatibilidade de driver, CUDA, framework e imagem de contêiner validada
• [ ] Integridade do GPU Operator/plugin de dispositivo confirmada onde o Kubernetes é usado
• [ ] Agendador expõe a capacidade esperada de nvidia.com/gpu
• [ ] Teste coletivo multi-GPU é aprovado na topologia de produção
• [ ] Teste de carga representativo atende às metas de TTFT, latência, throughput e erros
• [ ] Integridade do DCGM e diagnósticos apropriados na janela de manutenção fazem parte do runbook
• [ ] Caminhos de armazenamento, rede, carregamento de modelo, checkpoint e reinicialização são medidos
• [ ] Custo é calculado por unidade útil concluída, incluindo capacidade ociosa e de recuperação

Perguntas frequentes

Quanta memória uma GPU H200 tem?

A NVIDIA informa 141 GB de memória HBM3e e 4,8 TB/s de largura de banda de memória tanto para a H200 SXM quanto para a H200 NVL. Confirme o SKU exato e a configuração do sistema com o provedor, pois o formato da placa e a interconexão diferem. As especificações da H200 da NVIDIA são a fonte dos números deste guia.

Uma GPU H200 é melhor do que uma H100 para inferência de LLM?

Pode ser, especialmente quando a capacidade de memória ou a largura de banda da memória limita a carga de trabalho. A resposta prática depende da precisão do modelo, do comprimento do contexto, do comportamento do cache KV, da simultaneidade, do runtime de serving e da topologia do sistema. Compare a carga de trabalho com um rastreamento representativo; não trate um benchmark de fornecedor como substituto para o SLO do seu serviço. Consulte a comparação entre H200 e H100 para conhecer o framework de decisão de hardware.

Devo escolher H200 SXM ou H200 NVL?

Escolha a partir da topologia. A H200 SXM é adequada para configurações multi-GPU fortemente acopladas no estilo HGX. A H200 NVL é uma opção PCIe refrigerada a ar com configurações de bridge NVLink de 2 ou 4 vias. Verifique a topologia, o host e o padrão de comunicação da carga de trabalho, em vez de escolher apenas com base na memória.

A GPU H200 oferece suporte a MIG?

A NVIDIA lista até sete instâncias MIG para a H200 SXM e a H200 NVL, com diferentes tamanhos de memória por instância informados. Use MIG quando precisar de isolamento de memória e de falhas com suporte de hardware. Não substitua isso por divisão de tempo quando essas propriedades de isolamento forem necessárias.

De quantas GPUs H200 eu preciso?

Comece com a menor configuração que passe em um teste representativo de memória, latência, throughput e recuperação. Adicione GPUs somente quando o orçamento de memória, a contagem de réplicas ou o plano de paralelismo validado exigir. Uma contagem maior de GPUs sem uma carga de trabalho ciente da malha pode aumentar o custo e a superfície operacional sem melhorar o resultado voltado ao cliente.

Comece com um piloto validado de GPU H200

A implantação correta de uma GPU H200 é um sistema medido: memória do acelerador, topologia, agendador, runtime, caminho de dados, observabilidade e economia da carga de trabalho precisam estar alinhados. Comece com um piloto instrumentado, reproduza tráfego realista, documente os modos de falha e escale somente depois que as evidências sustentarem a próxima etapa de capacidade.

Fontes

• Especificações da GPU NVIDIA H200
• Guia de instalação do NVIDIA GPU Operator
• Documentação sobre agendamento de GPUs no Kubernetes
• Documentação de diagnóstico do NVIDIA DCGM