Implementar modelos de ML em produção com dimensionamento automático

A lacuna da implementação em produção: porque é que a maioria dos modelos de ML nunca sai do notebook

Um modelo treinado num notebook e um modelo que responde a pedidos em tempo real são problemas de engenharia diferentes. O segundo é um ambiente de implementação com requisitos de disponibilidade, latência e dimensionamento, e é onde a maioria dos modelos de aprendizagem automática em produção estagna.

O que é necessário para servir um modelo à escala (cluster, entrada, dimensionamento automático, monitorização)

A seleção e o treino do modelo são problemas a montante. O caminho clássico para servir modelos em produção é um processo separado, um processo que requer um cluster, um controlador de entrada, uma política de dimensionamento, uma pilha de monitorização e um pipeline de lançamento. Cada um é uma decisão que necessita de um responsável. Um cientista de dados que terminou o desenvolvimento do modelo precisa agora de rede de cluster, regras de balanceamento de carga e um backend de métricas antes que um utilizador veja uma previsão.

A lista de verificação: um runtime de contentores, regras de entrada, políticas de dimensionamento, gestão de segredos e dados, envio de registos, pipelines de lançamento, além de uma cadeia de ferramentas para manter cada um. Cada item é essencial, requer responsabilidade técnica e nenhuma destas ferramentas melhora o modelo.

Para uma equipa pequena, são semanas de trabalho antes que qualquer valor de negócio apareça, e não termina no lançamento. O resultado é familiar: o desenvolvimento do modelo é bem-sucedido, a implementação estagna e o artefacto aguarda por uma infraestrutura que ninguém tem tempo para construir.

Porque é que VM + Flask + nginx feitos por si falham com tráfego real

O atalho é uma VM a executar uma aplicação Flask atrás de nginx. Funciona em testes e falha em produção. Um servidor é um ponto único de falha. A ausência de dimensionamento automático significa que um pico de carga coloca os pedidos em fila até que a latência se torne inaceitável. A ausência de uma distribuição contínua significa que cada nova versão implica tempo de inatividade.

Também esconde um problema de custos: a instância funciona continuamente, quer o endpoint sirva mil pedidos por dia ou nenhum, e alguém continua a atualizar o SO e a renovar certificados. Eficiente de configurar, dispendioso de manter.

O custo oculto das instâncias de GPU inativas nos endpoints dos grandes fornecedores de nuvem

Os endpoints de inferência geridos nos grandes fornecedores de nuvem resolvem a disponibilidade, mas mantêm a instância de computação a funcionar 24 horas por dia. Um endpoint de GPU dimensionado para um pico diurno continua a ser faturado às 3 da manhã sem nada para servir, e o tempo de inatividade representa a maior parte do dia.

A utilização é a métrica que importa. Um endpoint que serve alguns milhares de pedidos por dia numa GPU dimensionada para o pico pode utilizar uma pequena fração do que paga, todos os dias, durante meses. As instâncias de GPU na nuvem fazem sentido quando a carga é constante, mas uma instância por hora é a unidade errada para uma procura que chega em picos.

Faturação por réplica, por minuto, em vez de instâncias sempre ativas

A faturação é feita por réplica, por minuto. Uma implementação que mantém uma réplica durante a noite e oito a meio do dia custa a soma dos minutos que cada réplica esteve em execução, e não oito instâncias durante 24 horas. A faturação do dimensionamento automático é calculada com base no número mínimo de réplicas que definir, aumentando a capacidade apenas enquanto estiver em execução. A previsão é simples: o seu limite mínimo é o mínimo multiplicado pelo tempo, tudo o que estiver acima acompanha a procura e a fatura do software mantém a forma da curva de carga.

Taxas indicativas: CPU apenas a partir de 0,04 € por núcleo por hora para modelos clássicos como scikit-learn ou XGBoost; GPU L4 a partir de 0,91 € por réplica por hora para inferência 7B, visão e classificação; GPU A100 cerca de 1,52 € a 1,85 € para 7B a 30B; GPU H100 PCIe a partir de 3,10 € para modelos maiores e janelas de contexto longas. Confirme as taxas atuais na página de preços.

Dimensionamento para zero quando o tráfego diminui, aumento de escala em picos reais

O dimensionamento para zero está geralmente disponível: uma implementação reduz automaticamente para zero réplicas quando nada a solicita, e o custo de inatividade torna-se zero. Essa é a principal diferença económica entre um endpoint gerido escalável e uma instância fixa que gere por si próprio. Tem um compromisso honesto. O retorno a partir de zero significa um arranque a frio enquanto o contentor inicia e carrega os pesos, pelo que o primeiro pedido após a inatividade é lento. Para um trabalho em lote ou uma ferramenta interna, isso é aceitável. Para uma aplicação voltada para o utilizador com um orçamento de latência, mantenha um mínimo de uma réplica e aceite o custo base.

Dimensionamento estático vs. dimensionamento automático (CPU/RAM) vs. dimensionamento automático por métrica personalizada

Três estratégias de dimensionamento, e a escolha segue o perfil do seu tráfego.

Sondas de prontidão e atualizações contínuas sem tempo de inatividade

Uma sonda de prontidão é um caminho HTTP que a plataforma consulta antes de enviar tráfego para uma réplica. É assim que garante que o modelo está pronto: aponte-a para a sua rota /health e o ponto final não encaminha qualquer pedido até que o modelo esteja carregado. Sem ela, uma réplica aceita um pedido enquanto os pesos são carregados e devolve um erro que o seu cliente vê como um pedido falhado.

As atualizações graduais utilizam a mesma verificação. Envie uma nova versão e aplique a atualização, e as novas réplicas passam na prontidão antes de as antigas serem retiradas. Os utilizadores não veem pedidos falhados e uma versão que falha na sua sonda nunca recebe tráfego. Cada versão é endereçável, pelo que as versões diárias e uma reversão de emergência partilham o mesmo mecanismo.

Monitorização em tempo real de GPU, CPU e rede por réplica

O painel de controlo expõe um conjunto de métricas em tempo real por réplica: uma métrica de GPU, uma métrica de memória e uma métrica de rede, cada uma limitada a uma réplica em vez de ser calculada a média, juntamente com registos de aplicação no Painel de Controlo.

Esse conjunto responde se a implementação está saudável, se a métrica de escalonamento está a ser acionada e onde se situa a latência. Não responde se as previsões continuam a estar corretas. Para isso, precisa de uma métrica de aplicação que defina, sendo a precisão numa amostra rotulada a escolha habitual. As equipas que mantêm modelos em produção partilham normalmente um painel de controlo entre a ciência de dados e a engenharia de plataforma, para que ambas vejam os mesmos números. Esta funcionalidade de monitorização é padrão em todas as aplicações.

Etapa 1: Empacote o modelo numa imagem Docker (ou utilize uma pré-construída)

A conteinerização é um pré-requisito, não um extra opcional. A imagem de contentor pode vir do Docker Hub, do Managed Private Registry ou do GitHub Packages. Três requisitos são importantes: criar o diretório de trabalho no Dockerfile, visar linux/amd64 e servir na porta 8080, a menos que declare outro explicitamente, como o vLLM faz na 8000.

As equipas sem experiência em contentores podem começar pelo catálogo de imagens pré-construídas da OVHcloud com PyTorch, TensorFlow, HuggingFace ou FastAI já instalados. Isso reduz o trabalho; não elimina o requisito. Implementar aprendizagem automática desta forma é uma predefinição eficiente para a maioria das aplicações, e implementar modelos de ML diretamente a partir de uma imagem de catálogo é ainda mais rápido, e a experiência de manter a sua própria camada base raramente compensa no início.

Etapa 2: Configure recursos, dimensionamento e acesso através do Painel de Controlo, API ou CLI ovhai

Crie a implementação a partir do Painel de Controlo, da API ou da CLI ovhai. Escolha os seus recursos de computação, defina a estratégia de escalonamento, aponte a sonda de prontidão para o seu caminho e porta de estado de funcionamento e, em seguida, defina como o ponto final é alcançado.

Quanto ao acesso, uma regra: um endpoint público destina-se apenas a testes. As implementações em produção utilizam acesso restrito, com credenciais de utilizador da AI Platform ou um token, e políticas de acesso que mantém por si próprio. Cada endpoint também se encontra protegido por uma proteção DDoS nativa, e cada endpoint mantém as suas próprias credenciais.

ovhai app run --gpu 1 --default-http-port 8080 \
  --probe-path /health \
  --unsecure-http false \
  my-registry/my-model-server:v2

Etapa 3: Escolha a estratégia de dimensionamento correta para o seu padrão de tráfego

Faça corresponder a política à carga de trabalho. Pontuação interna estável: estática, uma ou duas réplicas, uma predefinição eficiente para aplicações internas e ferramentas de baixo volume. Uma API voltada para o cliente com picos diários: dimensionamento automático com base numa métrica de utilização, mínimo de uma réplica para evitar arranques a frio. Pontuação em lote ocasional: dimensionamento automático com redução para zero. O trabalho em lote é onde essa decisão é mais fácil, porque ninguém observa uma barra de progresso. Cada execução em lote é um custo que já calculou.

Defina o máximo deliberadamente. Limita o débito e a fatura ao mesmo tempo, e o limite máximo é de 10 réplicas por aplicação.

Etapa 4: Monitorize a inferência com o dashboard e a arquitetura de referência MKS

Comece com o dashboard integrado para métricas de recursos e registos. Para percentis de latência, débito ou precisão ao nível do modelo, adicione uma pilha externa: Serviço Kubernetes Gerido a executar Prometheus e Grafana, a recolher dados do seu endpoint. A OVHcloud publica isto como uma arquitetura de referência.

Duas coisas a monitorizar continuamente: sinais de infraestrutura que lhe dizem se o dimensionamento funciona, e o desempenho do modelo em produção, que lhe diz se o modelo ainda faz o seu trabalho. A monitorização do desempenho no segundo é o que deteta uma regressão silenciosa, e as métricas de desempenho de um conjunto de dados de treino não o avisarão sobre isso. A deriva aparece no segundo muito antes do primeiro. Exporte uma semana de métricas online para um ficheiro antes de otimizar um limiar, garantindo que a alteração segue a carga observada. Defina um alerta em cada um para garantir que uma regressão surge a partir dos seus próprios conhecimentos em vez de um cliente, garanta que o limiar se baseia numa linha de base real e garanta que tem um responsável.

Etapa 5: Envie uma nova versão com uma atualização contínua sem tempo de inatividade

Construa e envie a nova versão, depois execute ovhai app update ou aplique a alteração a partir do Painel de Controlo. A plataforma inicia novas réplicas, aguarda pela prontidão, desvia o tráfego e retira as antigas. Sem tempo de inatividade, sem janela de manutenção.

O Dockerfile é código: mantenha-o no controlo de versões e a base atualizada, uma vez que uma camada base obsoleta é uma causa comum de uma implementação falhada. Mantenha as etiquetas versionadas em vez de reutilizar a latest. O controlo de versões em cada versão é o que torna uma reversão uma operação de um comando em vez de uma investigação.

Porque é que a CPU/RAM é um indicador fraco para a carga de LLM

A inferência de aprendizagem profunda é uma carga de trabalho computacional com uma fila, não um ciclo limitado pela CPU, pelo que a prática padrão de dimensionamento no hardware falha. Um servidor LLM processa pedidos simultâneos em lote na GPU. A utilização da CPU permanece baixa enquanto a fila aumenta, pelo que esse limiar é acionado tarde ou nunca. O sinal que lhe interessa é quantos pedidos estão em curso, e uma métrica de hardware não o consegue ver.

Escalonamento com base em vllm:num_requests_running com Prometheus e Grafana no MKS

O vLLM expõe vllm:num_requests_running no seu endpoint de métricas. Recolha-o com o Prometheus e faça o escalonamento automático com base nesse valor em vez de um proxy de hardware. As réplicas chegam quando a concorrência real aumenta e saem quando a fila esvazia, mantendo a latência dentro do orçamento sem excesso de aprovisionamento.

Geralmente disponível e documentado como uma arquitetura de referência. Precisa do Prometheus e do Grafana juntamente com a sua implementação, por isso trate-o como a abordagem avançada, não como a predefinida.

Tempo de configuração, custo de inatividade e experiência operacional

A autogestão da inferência implica o aprovisionamento do cluster, pools de nós, um controlador de ingress e um autoscaler horizontal, tipicamente uma a duas semanas, além de experiência em DevOps e MLOps para o manter a funcionar. É responsável pelas políticas de escalonamento, pipelines de implementação, ficheiros de manifesto e estratégias de monitorização, e continua a sê-lo após o lançamento. As melhores práticas na área estão documentadas e as ferramentas são maduras, mas, neste campo, uma prática documentada não é um sistema robusto em funcionamento. O nó de GPU funciona normalmente de forma contínua, mesmo com tráfego zero.

O AI Deploy precisa de uma imagem e de um comando. A configuração demora menos de uma hora, basta apenas experiência em MLOps, e o escalonamento para zero elimina totalmente os custos de inatividade.

Os preços e valores são indicativos. Confirme as taxas em vigor na página de preços da OVHcloud antes de publicar.

Sem exposição ao CLOUD Act nos dados de inferência

Os dados de treino não são o único input sensível. Cada pedido para um endpoint de produção transporta dados de utilizador ou de negócio, cada pedido é registado algures, cada pedido é um input que não escolheu, e o tráfego do endpoint é contínuo em vez de uma transferência única. Se o endpoint funcionar num fornecedor com sede nos EUA, esses dados ficam sob jurisdição dos EUA, independentemente da região que os aloja.

A OVHcloud é europeia, sem empresa-mãe nos EUA e sem exposição estrutural ao CLOUD Act. Os dados de inferência permanecem sob jurisdição da UE ao abrigo da legislação da UE.

RGPD, HDS e ISO 27701 para cargas de trabalho regulamentadas

A OVHcloud detém as certificações ISO 27001, ISO 27017, ISO 27018 e ISO 27701, possui certificação SOC 2 e detém a certificação HDS para dados de saúde em França, relevante para inferência médica. O processamento dentro da UE simplifica uma Avaliação de Impacto sobre a Proteção de Dados, e os compromissos de privacidade de dados que assumiu perante os seus próprios utilizadores tornam-se mais simples de comprovar. O suporte pode responder a uma questão de privacidade sem escalar.

Uma fronteira a declarar claramente: O AI Deploy fornece infraestrutura de serviço soberana. As obrigações ao nível do modelo do Regulamento da UE sobre a IA, os cartões de modelo, os registos de auditoria e a deteção de enviesamentos permanecem da sua responsabilidade enquanto programador do sistema. A infraestrutura soberana apoia a conformidade; não a garante.