Nuvem Privada de GPU: Arquitetura, Isolamento e Modelo Operacional

Nuvem Privada de GPU: Arquitetura, Isolamento e Modelo Operacional

Uma nuvem privada de GPU é infraestrutura de IA dedicada com provisionamento, governança e medição no estilo de nuvem. Ela pode operar em uma região de provedor, em um cluster privado hospedado, em uma sala de colocation ou no seu próprio data center, mas a pergunta de compra é a mesma: você precisa de capacidade de GPU isolada que sua equipe opere como uma plataforma, ou precisa apenas de acesso confiável a modelos com controles de custo?

Para equipes de IA corporativa, a resposta não deve começar com uma lista de logotipos. Comece com o limite da carga de trabalho, o limite de dados, o limite de rede, o limite do agendador e o limite de custo. Vale a pena avaliar uma nuvem privada de GPU quando pools públicos compartilhados de GPU, endpoints serverless ou APIs gerenciadas de modelos não conseguem atender a esses limites sem risco inaceitável, latência, atrito de conformidade ou incerteza de fila.

Este guia fornece uma arquitetura prática e um modelo operacional para decisões sobre nuvem privada de GPU. Ele cobre as camadas de isolamento que você deve inspecionar, a equipe de plataforma necessária para operá-la, os testes de aceitação que deve exigir antes de assinar e onde o Flatkey se encaixa quando a governança de modelos/APIs é suficiente sem precisar assumir a camada de GPU.

Resposta Rápida sobre Nuvem Privada de GPU

Escolha uma nuvem privada de GPU quando precisar de capacidade reservada de GPU, topologia de cluster previsível, rede privada, limites rígidos entre tenants, stacks de serving personalizados, controle direto do agendador ou evidências para revisão de segurança. Não escolha uma nuvem privada de GPU apenas porque "privada" parece mais segura. O isolamento só importa se o contrato, a rede, o armazenamento, o agendador, o IAM, a observabilidade e o processo de incidentes preservarem esse limite.

Uma proposta sólida de nuvem privada de GPU deve responder a estas perguntas:

• Quais GPUs, nós, racks e fabrics são dedicados a nós?
• As cargas de trabalho são isoladas por host físico, máquina virtual, namespace do Kubernetes, partição do Slurm, fatia MIG da NVIDIA ou uma combinação?
• Como imagens, pesos de modelos, prompts, saídas, logs e métricas são mantidos dentro do limite aprovado?
• Quem é responsável por patches, upgrades de driver, compatibilidade CUDA, política do agendador, aplicação de cotas, backup e resposta a incidentes?
• Como o custo é medido: alocação horária de GPU, capacidade reservada, tokens aceitos, jobs concluídos, armazenamento, egress, suporte ou taxas de serviço gerenciado?

Se um fornecedor não consegue mostrar esses detalhes, você não está avaliando uma nuvem privada de GPU. Você está avaliando um SKU de aluguel de GPU com palavras empresariais ao redor.

O Que "Privado" Pode Significar

A expressão nuvem privada de GPU é ambígua. As equipes de compras frequentemente comparam várias ofertas diferentes sob a mesma palavra-chave.

Para leitores do Flatkey, essa última linha importa. O Flatkey oferece às equipes uma chave, um saldo, uma fatura, controles de ledger de uso, endpoints oficiais de modelos e governança em modelos e APIs de ferramentas. Isso não substitui uma nuvem privada de GPU quando você precisa de isolamento de hardware reservado. É o caminho mais simples quando a necessidade real é acesso a múltiplos modelos, visibilidade de custos, failover e controles corporativos sem operar infraestrutura de GPU. Para esse caminho de comparação, use o guia complementar sobre nuvem de GPU vs API de modelo.

Arquitetura de Referência

Uma nuvem privada de GPU em produção tem mais camadas do que nós de GPU. Trate-a como uma plataforma de IA com seis planos de controle.

1. Plano de Capacidade

O plano de capacidade define o limite físico e contratual:

• Geração de GPU e formato: H100, H200, B200, GB200, L40S, A100 ou outros aceleradores.
• Formato do nó: inferência em nó único, nós de treinamento com 8 GPUs, pods multinó, sistemas em escala de rack ou formas de VM em nuvem.
• Fabric: NVLink/NVSwitch dentro dos nós, InfiniBand, RoCE, EFA, GPUDirect RDMA ou rede de IA específica do provedor.
• Modelo de reserva: sob demanda, comprometido, reservado, cluster dedicado, bloco de capacidade ou nuvem privada hospedada.
• Direitos de substituição: o que acontece quando uma GPU, NIC, disco, rack ou zona falha.

Não normalize ofertas de nuvem privada de GPU apenas pelo preço horário da GPU. Normalize pela topologia utilizável. Um pool mais barato que não consegue alocar oito GPUs com o fabric de rede necessário pode custar mais por trabalho concluído do que um bloco privado com preço mais alto. Se a discussão ainda estiver no nível da tabela de tarifas, primeiro normalize as entradas com uma planilha de preços de aluguel de GPU.

2. Plano de Rede

O plano de rede decide se o cluster é realmente acessível e isolado da forma que sua equipe de segurança espera.

Perguntas mínimas de design:

• O cluster está dentro da sua VPC, de uma VPC do provedor, de uma VLAN privada, de um segmento de direct-connect ou de uma conta de serviço gerenciada?
• As APIs de controle são expostas publicamente, privadamente ou por meio de um bastion/proxy de identidade?
• O tráfego east-west entre nós de GPU é isolado de outros tenants?
• Os endpoints de serving de modelos são privados por padrão?
• Os dados de treinamento, checkpoints, imagens de contêiner, pesos de modelo e logs podem trafegar sem caminhos pela internet pública?
• Há controles explícitos de egress, políticas de NAT, políticas de DNS e regras de firewall?

Para treinamento em larga escala e inferência de alto throughput, os detalhes de rede não são apenas detalhes de segurança. Eles alteram throughput, taxa de retry, tempo de checkpoint e comportamento de falha do job.

3. Plano do Scheduler

O plano do scheduler decide quem pode usar as GPUs e quando.

Opções comuns:

• Kubernetes com device plugins, GPU Operator, node pools, namespaces, quotas, taints, tolerations e políticas de admissão.
• Slurm com partitions, accounts, regras de qualidade de serviço, agendamento fair-share, preemption e arrays de jobs.
• Um plano de controle de inferência gerenciado para escalonamento de endpoints, enfileiramento, batching, autoscaling e implantações canary.
• Um modelo híbrido em que o Slurm gerencia o treinamento enquanto o Kubernetes gerencia o serving.

Uma nuvem privada de GPU sem política de scheduler rapidamente se torna uma planilha compartilhada. Defina regras de quota, classes de prioridade, limites de fila, regras de preempção, desligamento por inatividade, janelas de reserva e acesso de emergência break-glass antes que a primeira equipe faça a migração.

4. Plano de Runtime

O plano de runtime é onde a maioria das alegações de "GPU disponível" falha na prática.

Você precisa de uma responsabilidade clara para:

• Versões do driver NVIDIA, CUDA, cuDNN, NCCL e runtime de contêiner.
• GPU Operator ou ferramenta equivalente de ciclo de vida.
• vLLM, SGLang, TensorRT-LLM, Triton, Ray Serve ou frameworks de serving personalizados.
• Acesso ao registry de contêineres e verificação de imagens.
• Distribuição de pesos de modelo e verificação de checksum.
• Ajuste de kernel, huge pages, política NUMA, configurações GPUDirect e testes de topologia NCCL.
• Planos de rollback para upgrades de driver e upgrades do framework de serving.

Para equipes de inferência, uma nuvem privada de GPU útil deve expor uma camada de API compatível com OpenAI ou um contrato de serviço interno. Caso contrário, cada equipe de produto precisa reaprender batching, streaming, compatibilidade de tool-calling, retries e contabilização de requisições. Os detalhes de implementação são cobertos no guia de implantação do vLLM e na comparação vLLM vs SGLang.

5. Plano de Dados

O plano de dados inclui tudo o que os usuários esquecem durante a aquisição de GPU:

• Conjuntos de dados de treinamento e feature stores.
• Armazenamento de objetos, sistemas de arquivos compartilhados e NVMe local.
• Armazenamento de checkpoints e retenção de snapshots.
• Registry de modelos e promoção de artefatos.
• Retenção de prompts, saídas, telemetria e traces.
• Backup, restore e retenção legal.
• Replicação entre regiões ou entre zonas.

GPUs privadas não tornam automaticamente os dados privados. Seus controles devem cobrir onde os inputs do modelo, outputs do modelo, embeddings, logs, métricas, traces, checkpoints e requisições com falha são gravados.

6. Plano de Governança e FinOps

Uma nuvem privada de GPU ainda precisa de controles no estilo cloud:

• Funções IAM e acesso com menor privilégio.
• Quotas e orçamentos por equipe.
• Tags ou labels de alocação de custo.
• Horas de GPU, memória alocada, tokens aceitos, jobs concluídos, tempo de espera na fila e capacidade ociosa.
• Chargeback ou showback.
• Logs de auditoria de segurança.
• Regras de aprovação para exposição de endpoint público.
• Evidências de SLA, incidentes e escalonamento de suporte.

Se você não consegue atribuir o gasto com GPU a equipes, ambientes, projetos e saídas aceitas, a nuvem privada de GPU parecerá mais barata no orçamento e mais cara no fechamento do trimestre.

Modelo de Isolamento: Peça Evidências, Não Adjetivos

O isolamento de nuvem privada de GPU deve ser descrito em quatro níveis.

Isolamento Físico

Isolamento físico significa que hosts, racks, pods ou clusters são dedicados. É o mais forte para workloads regulados e para desempenho previsível, mas isso deve estar refletido no contrato e no processo operacional. Pergunte se hosts com falha são substituídos por hosts igualmente dedicados, se engenheiros de suporte podem acessar o ambiente e como o acesso remoto é auditado.

Isolamento de Virtualização

Máquinas virtuais podem fornecer limites operacionais fortes, mas você precisa confirmar o posicionamento no host, o passthrough de GPU ou o modo vGPU, a conexão de armazenamento, a segregação de rede e os eventos de manutenção. Para provedores que oferecem reservas de capacidade ou hosts dedicados, pergunte como suas GPUs são mapeadas para os hosts e como o posicionamento é comprovado durante auditorias.

Isolamento de Partição de GPU

O NVIDIA Multi-Instance GPU (MIG) pode particionar GPUs compatíveis em instâncias de GPU separadas. O MIG pode ser útil para densidade de inferência e controles de tenancy, mas não é um substituto universal para a dedicação de host inteiro ou de GPU inteira. Verifique quais modelos de GPU suportam MIG, quais perfis são permitidos, como os slices são atribuídos e como o monitoramento distingue os tenants.

Isolamento de Orquestração

Namespaces do Kubernetes, políticas de rede, service accounts, controles de admissão e quotas ajudam a separar equipes. Contas e partitions do Slurm ajudam a separar usuários de batch. Isso é necessário para operações de plataforma, mas não garante, por si só, isolamento físico. A arquitetura deve declarar exatamente onde termina o isolamento de orquestração e onde começa o isolamento no nível do host.

Modelo Operacional: Quem Executa O Quê?

Uma nuvem privada de GPU não é apenas uma compra. É um modelo operacional. Antes de assinar, defina a responsabilidade em uma tabela RACI.

Se a sua equipe não consegue prover engenharia de plataforma, operações de segurança, FinOps e suporte a aplicações, uma nuvem privada de GPU pode se tornar um ativo parado. Nesse caso, compare-a com APIs de modelos gerenciados, inferência serverless e opções de GPU cloud antes de se comprometer. Para capacidade multi-node especificamente, use a lista de verificação de aluguel de cluster de GPU antes de negociar um bloco privado.

Categorias de Provedores para Comparar

As principais plataformas de nuvem privada de GPU para IA empresarial geralmente se enquadram em cinco categorias:

1. Blocos de GPU de hyperscalers: AWS, Google Cloud, Azure e capacidade de VM ou cluster de GPU no estilo Oracle com rede privada, IAM, opções de capacidade reservada e aquisição empresarial.
2. Nuvens de GPU especializadas: CoreWeave, Lambda, Crusoe, Nebius, Voltage Park e provedores similares focados em capacidade para IA, fabrics de alta velocidade e operações de cluster.
3. Nuvens de GPU para desenvolvedores e marketplaces: RunPod, Vast.ai, TensorDock e opções similares para capacidade flexível, protótipos e descoberta de preços.
4. Stacks de IA privada hospedadas: HPE Private Cloud AI com NVIDIA e outras ofertas de nuvem privada em formato de appliance para empresas que querem hardware, software e suporte integrados.
5. Camada de governança de modelo/API: Flatkey e roteadores relacionados quando a necessidade é acesso oficial a modelos, controles de custo, auditabilidade e failover, em vez de propriedade do hardware.

Se você estiver comparando especificamente os serviços de nuvem privada de GPU da Vultr, separe o requisito em disponibilidade de VM com GPU, necessidades de bare metal ou host dedicado, isolamento de VPC/rede, capacidade comprometida, termos de suporte e evidências de conformidade. A página Cloud GPU de um provedor pode ser um bom ponto de partida, mas a resposta final muitas vezes está na cotação, no diagrama de arquitetura e no contrato de suporte.

Campos de TCO que os Compradores Ignoram

Construa o modelo de TCO da nuvem privada de GPU com base no trabalho concluído, não no preço de tabela.

Use esta planilha:

Depois compare com três alternativas:

• Aluguel de nuvem pública de GPU para jobs com picos.
• Inferência serverless ou gerenciada para demanda de produção irregular.
• Roteamento de modelo/API para equipes que querem governança, endpoints oficiais, registros de uso e uma única fatura sem operar GPUs.

É aqui que a Flatkey é útil na avaliação. Se o modelo de TCO mostrar que a nuvem privada de GPU está sendo justificada principalmente por acesso a múltiplos modelos, consolidação de faturas, auditabilidade ou controle de custo por token, avalie a Flatkey antes de assinar um compromisso de hardware. Se o modelo mostrar que o requisito é hardware dedicado, kernels personalizados, residência de dados ou treinamento específico da topologia, mantenha o caminho da nuvem privada de GPU aberto. Para a revisão financeira, combine isso com o modelo de TCO de cluster de GPU e com a estrutura mais ampla de comparação de preços de API de IA.

Testes de Aceitação Antes de Assinar

Não aceite um deck de slides como prova. Execute testes de aceitação na topologia exata ou em um ambiente contratualmente equivalente.

Testes de Segurança E Isolamento

• Confirme o acesso por endpoint privado a partir da sua rede.
• Verifique que nenhum endpoint público de plano de controle ou de serving de modelo é आवश्यकरीo.
• Verifique a separação de IAM entre administradores da plataforma, equipes de modelo, leitores de segurança e leitores de finanças.
• Confirme que o registro de contêiner, o armazenamento de objetos, o armazenamento de checkpoints e os logs permanecem dentro do perímetro aprovado.
• Revise os eventos de auditoria de login, pull de imagem, envio de job, implantação de endpoint, leitura de segredo, saída de dados e escalonamento de privilégio de administrador.

Testes de Performance

• Execute testes NCCL all-reduce e de topologia para treinamento multinó.
• Reproduza tráfego representativo de inferência pela stack de serving escolhida.
• Meça a latência p50, p95 e p99 sob carga estável e em pico.
• Meça tokens por segundo por GPU, tokens aceitos por dólar e consumo por requisição com falha.
• Teste o tempo de carregamento do modelo, o tempo de gravação de checkpoint, o tempo de rollback e o comportamento de drenagem de nó.

Testes de Operações

• Simule uma GPU com falha, um nó com falha, um mount de armazenamento com falha, um componente de plano de controle com falha e uma implantação de serving de modelo com falha.
• Teste a atualização e o rollback de driver em um pool de nós não produtivo.
• Confirme quem responde às 3h da manhã e quais informações essa pessoa pode acessar.
• Valide os campos de exportação de uso para finanças e auditoria.
• Confirme o que acontece quando a demanda excede a capacidade reservada.

Testes de Contrato

• Mapeie cada promessa de arquitetura a uma cláusula contratual ou documento de suporte.
• Defina datas de entrega de capacidade, SLAs de substituição, aviso de manutenção, exclusão de dados, notificação de incidentes e cooperação em auditoria.
• Confirme se "privado" cobre apenas computação, ou também armazenamento, logs, métricas, acesso de suporte e backups.

Padrão de Arquitetura Interna

Uma nuvem privada de GPU prática para IA empresarial costuma usar este padrão:

1. Perímetro de rede privado com conexão direta ou VPN.
2. Pools dedicados de nós de GPU divididos por tipo de carga: treinamento, inferência em lote, inferência online, avaliação e experimentos.
3. Kubernetes para serviços e Slurm para grandes lotes/treinamento quando necessário.
4. Registro de modelos e caminho de promoção de artefatos de experimento para staging e produção.
5. vLLM, SGLang, TensorRT-LLM, Triton ou Ray Serve atrás de um gateway interno.
6. Cotas por equipe, políticas de admissão e rótulos de custo.
7. Observabilidade para utilização de GPU, memória, tempo de espera na fila, latência, jobs com falha, saídas aceitas e gasto.
8. Fallback externo de modelo/API por meio de um roteador governado para overflow, modelos sem suporte ou comparação de custos.

O ponto final não é um atalho. É um padrão de resiliência. Mesmo equipes com uma nuvem privada de GPU frequentemente mantêm um roteador de modelo/API para overflow, comparação de modelos, fallback de fornecedor e casos de uso em que comprar a GPU não é racional.

Matriz de Decisão

Checklist de Aquisição de Nuvem Privada de GPU

Use este checklist antes da seleção preliminar de fornecedores:

• Defina as cargas de trabalho: treinamento, fine-tuning, inferência em lote, inferência online, avaliação, embeddings, geração de mídia ou notebooks.
• Defina o isolamento: físico, virtual, partição de GPU, orquestrador, rede, armazenamento e acesso de suporte.
• Defina a topologia: modelo de GPU, GPUs por nó, nós por cluster, fabric, armazenamento e região.
• Defina o runtime: CUDA, drivers, NCCL, Kubernetes, Slurm, vLLM, SGLang, TensorRT-LLM, Triton, Ray e observabilidade.
• Defina os controles de dados: pesos do modelo, prompts, saídas, logs, traces, checkpoints, backups, exclusão e retenção legal.
• Defina a unidade de custo: GPU-hora, job concluído, saída aceita, token aceito, hora do endpoint, armazenamento, egress, suporte e trabalho da plataforma.
• Defina os testes de aceitação: segurança, rede, orquestrador, desempenho, failover, exportação de uso e resposta a incidentes.
• Defina o fallback: overflow para nuvem pública de GPU, APIs de modelos ou rotas governadas pela Flatkey.

Fontes Oficiais a Verificar

Use fontes oficiais para as partes voláteis de uma avaliação de nuvem privada de GPU:

• Guia do Usuário do NVIDIA MIG para particionamento de GPU e suporte a perfis: Documentação NVIDIA MIG.
• Documentação do NVIDIA GPU Operator e do plugin de dispositivo do Kubernetes para ciclo de vida e agendamento de GPU no Kubernetes: GPU Operator e NVIDIA k8s-device-plugin.
• Documentação do plugin de dispositivo do Kubernetes para o modelo de integração do scheduler: plugins de dispositivo do Kubernetes.
• Documentação de instâncias GPU e capacidade do AWS EC2: instâncias Amazon EC2 P5 e EC2 Capacity Blocks for ML.
• Documentação de VMs otimizadas para aceleradores e do AI Hypercomputer do Google Cloud: máquinas otimizadas para aceleradores do Google Cloud e AI Hypercomputer.
• Documentação das VMs GPU da série ND do Microsoft Azure: Azure ND série H100 v5.
• Páginas de provedores para capacidade especializada de nuvem GPU, como Lambda Private Cloud, CoreWeave e Vultr Cloud GPU.
• HPE Private Cloud AI para avaliação de uma stack privada de IA integrada: HPE Private Cloud AI.
• FOCUS do FinOps para vocabulário de alocação de custos e estrutura de relatórios: FOCUS by the FinOps Foundation.
• Páginas de produto da Flatkey para a alternativa de governança de modelo/API: Flatkey, Flatkey Compute e preços da Flatkey.

Perguntas Frequentes

O que é uma nuvem privada de GPU?

Uma nuvem privada de GPU é uma infraestrutura de GPU dedicada ou fortemente isolada entregue com provisionamento, rede, segurança, medição e suporte no estilo de nuvem. Ela pode ser hospedada por um provedor, implantada em colocation ou executada on-premises. O ponto importante não é a localização. O ponto importante é o isolamento e o modelo operacional.

Nuvem privada de GPU é a mesma coisa que aluguel de GPU bare metal?

Não. O aluguel de GPU bare metal pode ser um dos blocos de construção de um design de nuvem privada de GPU, mas uma nuvem privada de GPU também deve definir isolamento de rede, limites de armazenamento, política do scheduler, controles de acesso, observabilidade, alocação de custos, suporte e resposta a incidentes.

Quando GPU como serviço em nuvem privada é melhor do que APIs de modelos?

A nuvem privada de GPU como serviço é melhor quando você precisa de hardware dedicado, controle de runtime personalizado, caminhos de rede privados, treinamento específico de topologia, tratamento de dados regulamentados ou capacidade reservada previsível. APIs de modelos geralmente são melhores quando você precisa de muitos modelos de fronteira, integração rápida, fallback, controles de ledger e baixa carga de infraestrutura.

Como as equipes de IA corporativa devem comparar as principais plataformas de nuvem privada de GPU?

Compare com base na adequação da carga de trabalho, evidências de isolamento, topologia, propriedade do agendador, fronteira de dados, observabilidade, modelo de suporte, exportação de custos e resultados de testes de aceitação. Não classifique as principais plataformas de nuvem privada de GPU para IA corporativa apenas pelo preço horário da GPU.

O que devo perguntar sobre os serviços de nuvem privada de GPU da Vultr?

Pergunte se sua आवश्यकता se encaixa em VMs Cloud GPU, bare metal, VPC/rede privada, capacidade comprometida, tempo de resposta do suporte, evidências de conformidade, fronteira de armazenamento e operações de serving de modelos. Peça também acesso a benchmarks antes de tratar a oferta como uma nuvem privada de GPU.

Onde a Flatkey se encaixa se já temos uma nuvem privada de GPU?

A Flatkey pode ficar ao lado de uma nuvem privada de GPU como a rota governada de modelo/API para modelos externos, overflow, fallback, comparação de custos e equipes que não precisam de controle no nível de hardware. Ela oferece uma chave, um saldo, uma fatura e controles de ledger de uso entre APIs oficiais de modelos e ferramentas.

Conclusão

Uma nuvem privada de GPU é um compromisso de plataforma, não um atalho de procurement. É a resposta certa quando as equipes de IA corporativa precisam de capacidade dedicada, controle de topologia, caminhos de dados privados e evidências operacionais. É a resposta errada quando a necessidade real é apenas acesso mais fácil a muitos modelos, uma fatura mais limpa e uma melhor governança de custos de API.

Use primeiro a checklist de arquitetura de nuvem privada de GPU. Depois, faça benchmark da topologia exata. Em seguida, compare o TCO com aluguel de GPU, inferência gerenciada e rotas de modelo/API governadas pela Flatkey. A melhor decisão é aquela que dá às suas equipes de IA a fronteira de que elas realmente precisam, sem fazê-las operar uma infraestrutura que não precisam. Se a escolha do hardware ainda estiver em aberto, comece com a melhor GPU para inferência de LLM antes de pedir um orçamento privado aos fornecedores.