Ajuste modelos de IA em GPU na nuvem

Se a sua equipa está a planear um projeto de ajuste de LLM, a construir um pipeline RAG ou a experimentar um modelo multimodal que combina texto e conteúdo visual, o obstáculo é quase sempre o mesmo: alguém pediu-lhe para justificar a compra de um servidor de 100 000 a 500 000 euros antes de um único programador ter escrito uma linha de código de treino ou lançado uma aplicação. Essa conversa pode demorar meses e, enquanto espera que o departamento financeiro aprove o orçamento, os seus concorrentes já lançaram os seus produtos.

A alternativa é GPU as a Service. Aprovisiona um H100 ou A100 quando precisa dele, executa o seu trabalho de treino e paga apenas pelas horas que utiliza efetivamente. Sem filas de aprovisionamento, sem hardware parado, sem debate sobre CapEx. As soluções de IA da OVHcloud fornecem a pilha completa: notebooks geridos, tarefas de treino serverless, endpoints de inferência e um catálogo de modelos base de pesos abertos pré-treinados — tudo em infraestrutura soberana da UE.

Este guia explica por que razão o treino em GPU na nuvem faz sentido económico para a maioria das equipas de IA generativa, como é a plataforma OVHcloud na prática e exatamente como passar de um conjunto de dados para um endpoint de modelo implementado sem tocar num único servidor físico. Reflete uma das tendências mais claras na infraestrutura de IA generativa atual: pagar por horas de GPU, não por hardware de GPU.

Passo 1 — Inicie um AI Notebook com GPU e o seu framework de ML

Inicie sessão no Painel de Controlo OVHcloud, navegue para AI Notebooks e crie um novo notebook. Selecione o seu tipo de GPU (H100 ou V100S para trabalho exigente, L4 para experimentação mais leve), escolha Jupyter ou VS Code, e escolha uma imagem pré-construída que corresponda à sua stack. O notebook fica ativo em poucos minutos com CUDA, o seu framework escolhido e um terminal pronto a utilizar.
Ligue o seu bucket de Object Storage como um volume de dados no momento do lançamento. Isto significa que o seu conjunto de dados está disponível como um caminho local dentro do notebook sem qualquer cópia manual, e os seus pontos de verificação de modelo podem ser escritos diretamente no bucket durante a formação — um padrão simples e eficaz para qualquer equipa, não apenas para engenheiros de plataformas de ML especializados.

Passo 2 — Prepare o seu conjunto de dados no Object Storage

O Object Storage (compatível com S3)* é a camada de dados canónica para tarefas de AI Training. É compatível com S3, pelo que as suas ferramentas existentes (boto3, a AWS CLI, rclone) funcionam sem modificação. Carregue o seu corpus de formação, conjuntos de dados tokenizados e quaisquer artefactos pré-processados aqui antes de submeter uma tarefa de formação. Se o seu pipeline incluir passos de aumento de dados, execute-os a montante e armazene o conjunto de dados resultante juntamente com o original para reprodutibilidade e controlo de versão.

Uma vantagem prática: não existem taxas de saída entre serviços OVHcloud. Mover dados do Object Storage para uma instância GPU para formação, ler pontos de verificação de volta para o armazenamento a meio da tarefa, ou extrair artefactos de modelo para o AI Deploy após a formação — nenhuma destas transferências acarreta custos ocultos. Iterar sobre o seu conjunto de dados, e sobre a qualidade dos dados em geral, é barato.

Passo 3 — Submeta um trabalho de treino e escolha o tipo de GPU correto

Empacote o seu script de formação como uma imagem Docker (ou utilize uma imagem OVHcloud pré-construída) e submeta uma tarefa com a CLI ovhai:

ovhai job run --gpu 1 --flavor h100-1-gpu --volume my-bucket@GRA/dataset:/workspace/data:ro --volume my-bucket@GRA/output:/workspace/output:rw my-registry/my-training-image:latest

Escolha o seu tipo de GPU com base nos requisitos de VRAM: um ajuste fino de um modelo 7B cabe tipicamente num único H100 com 80 GB de VRAM; modelos maiores ou tamanhos de lote maiores podem exigir um H200, ou um pedido multi-GPU para acelerar a formação. A tarefa é executada sem servidor, monitorizada através de registos em tempo real no Painel de Controlo ou através da API. Quando termina, os seus artefactos de modelo estão no Object Storage.

Passo 4 — Sirva o seu modelo com AI Deploy ou AI Endpoints

Para um modelo personalizado ajustado (fine-tuned), crie uma aplicação AI Deploy que aponte para o seu artefacto de modelo no Object Storage. Configure o autoscaling com base no volume de pedidos e nos limites de memória, e ative o caching de respostas onde o seu padrão de tráfego o permita para reduzir ainda mais o custo de inferência — uma técnica simples que combina bem com o processamento em lote de pedidos para aplicações sensíveis ao débito. Cada camada de caching que adiciona reduz a latência média e melhora a relação custo-desempenho ao mesmo tempo. O seu endpoint fica ativo em minutos e escala para corresponder ao tráfego.

Para modelos padrão de pesos abertos, ignore totalmente o passo de implementação e consulte os AI Endpoints diretamente. A API é compatível com o formato de cliente OpenAI, pelo que as integrações existentes requerem frequentemente apenas uma alteração do URL base.

O ajuste fino de 7B que corre num único H100 em poucas horas

A grande maioria dos projetos de IA generativa não treina de raiz. Eles ajustam (fine-tune) um LLM de base pré-treinado e de pesos abertos existente — Mistral 7B, Llama 3 8B, Falcon ou uma arquitetura de modelo de linguagem semelhante — num conjunto de dados específico do domínio. O ajuste fino é, por si só, uma forma de aprendizagem por transferência: começa com um modelo que já gera linguagem fluente de forma abrangente e especializa-o para a sua tarefa com muito menos horas de GPU do que treinar um modelo do zero. Utilizando técnicas como LoRA ou QLoRA, e quantização para reduzir a utilização de memória durante o treino, um modelo 7B pode ser concluído num único H100 em 4 a 12 horas, dependendo do tamanho do conjunto de dados e do número de épocas. A maioria das equipas de desenvolvimento considera esta técnica muito mais acessível na plataforma OVHcloud do que gerir a sua própria arquitetura de treino.

Este é o cenário em que a computação pay-as-you-go é mais economicamente atrativa. Executa o seu trabalho de ajuste fino, avalia o resultado, ajusta o conjunto de dados ou os hiperparâmetros para evitar o sobreajuste (overfitting) num pequeno corpus específico do domínio e executa novamente. Cada iteração custa um número previsível de horas de GPU. Pode executar uma dúzia de experiências por menos do que a fatura mensal de eletricidade de um servidor físico, avaliar regularmente o desempenho do modelo e melhorar as capacidades do modelo e a qualidade do conteúdo gerado a cada passagem — depois, disponibilize o resultado assim que atingir o seu padrão.

Para modelos de média dimensão na gama de 13B a 70B parâmetros, são possíveis trabalhos multi-GPU na OVHcloud (até 4 GPUs por trabalho sob os limites atuais). Para o ajuste fino de 70B, planeie instâncias H100 ou H200 e recorra à quantização para gerir as restrições de VRAM e controlar a utilização de memória camada a camada.

Quando falar com um Arquiteto de Soluções sobre pré-treino em grande escala

Se o seu projeto envolve o pré-treino de um modelo de raiz com dezenas ou centenas de milhares de milhões de parâmetros — esse é um desafio arquitetónico fundamentalmente diferente e um tipo diferente de compromisso com o cliente. O treino distribuído através de muitas GPUs, a rede personalizada, a gestão de pontos de controlo à escala de petabytes e a orquestração de trabalhos de longa duração não são decisões de autosserviço; requerem ferramentas dedicadas e uma arquitetura de referência criada para o seu caso.

Para o pré-treino em grande escala, o primeiro passo certo é uma conversa com um Arquiteto de Soluções de IA da OVHcloud. Eles podem avaliar os seus requisitos de computação, discutir opções de clusters de GPU e a ferramenta certa para cada fase, e ajudá-lo a conceber uma arquitetura de treino que corresponda à sua escala e à melhoria de desempenho pretendida. A ligação para solicitar essa conversa encontra-se na secção 'Começar' abaixo.

Comparação de custos: servidor H100 local vs OVHcloud pay-as-you-go

Custo de aquisição, eletricidade, operações e amortização
O custo total de um servidor GPU local inclui mais do que o preço de etiqueta. Um sistema típico 8×H100 SXM custa entre 150 000 e 250 000 euros na aquisição. Adicione a isso: atualizações de infraestrutura de energia, refrigeração, espaço em bastidor, um contrato de manutenção de três anos e o salário do engenheiro responsável por mantê-lo a funcionar. Amortizado ao longo de 36 meses, o custo total de propriedade divide-se em valores substancialmente superiores ao preço de tabela do hardware isoladamente.

Na OVHcloud, não existe custo de aquisição. Paga apenas pelas horas de GPU que consome, faturadas ao minuto, sem compromisso e sem custos de inatividade. Se o seu projeto for cancelado, não paga nada além do que já executou.

Sem exposição ao CLOUD Act nos dados de treino

O CLOUD Act dos EUA permite que as autoridades dos EUA obriguem as empresas sediadas nos EUA a fornecer dados armazenados em qualquer parte do mundo, incluindo dados alojados em centros de dados europeus por fornecedores de nuvem dos EUA. Se o seu corpus de treino contiver dados pessoais, registos de saúde, documentos legais, transações financeiras ou qualquer outra categoria regulamentada, o treino em infraestruturas sujeitas à lei dos EUA cria um risco de conformidade que é difícil de mitigar totalmente apenas através de medidas contratuais.

A OVHcloud é uma empresa europeia sem empresa-mãe nos EUA. Não existe dependência estrutural do CLOUD Act. Os seus dados de treino permanecem na jurisdição da UE ao abrigo da lei da UE. Para equipas em setores regulamentados — cuidados de saúde, serviços financeiros, tecnologia jurídica, setor público — esta não é uma vantagem teórica; é um requisito e, cada vez mais, o critério principal sobre o qual as equipas de aprovisionamento perguntam desde o início.

Substrato do Regulamento da UE sobre a IA, RGPD, HDS e ISO 27701

A infraestrutura da OVHcloud possui certificações ISO 27001, ISO 27017, ISO 27018 e ISO 27701. A certificação HDS é relevante para equipas que treinam modelos com dados de saúde em França. Para o RGPD, os dados de treino processados na OVHcloud são armazenados e processados dentro da UE ao abrigo da legislação da UE, o que simplifica significativamente as Avaliações de Impacto sobre a Proteção de Dados e ajuda a garantir a conformidade contínua.

Um esclarecimento importante: A OVHcloud fornece o substrato de infraestrutura soberana. A conformidade com o Regulamento da UE sobre a IA ao nível do modelo — fichas de modelo, deteção de enviesamentos, registos de auditoria, obrigações de transparência — permanece da sua responsabilidade enquanto programador do sistema de IA. A infraestrutura soberana apoia as suas obrigações de conformidade; não as cumpre automaticamente.

Do lado dos analistas, o GigaOM Radar reconheceu a OVHcloud pela interconectividade e disponibilidade soberana, e a IDC nomeou a OVHcloud como um Major Player em IaaS de Nuvem Pública Europeia.