Treinar um modelo agora acontece ao lado dos seus dados ou atrás de uma API. A avaliação continua sendo sua

Para a maioria das empresas, treinar ou adaptar um modelo sempre significou montar uma segunda plataforma: um cluster de GPU, um agendador, imagens de container, armazenamento de checkpoints e uma cópia dos dados de treino fora do ambiente governado onde eles normalmente vivem. Essa segunda plataforma é cara de operar e difícil de auditar, e é um dos motivos pelos quais tantos projetos de fine-tuning nunca chegam à produção.

Três anúncios em dois dias, 21 e 22 de outubro, apontam para essa segunda plataforma desaparecendo dentro da primeira.

Três jeitos de alugar a stack de treino

O Databricks AI Runtime está em disponibilidade geral. Ele leva GPUs serverless para dentro da plataforma da Databricks, com inicialização em segundos, treino em vários nós, containers próprios e Ray, e observabilidade no MLflow. As permissões do Unity Catalog valem para os dados de treino, os checkpoints e os logs, as cargas rodam com isolamento em nível de máquina virtual, e o consumo aparece nas tabelas de faturamento da Databricks por carga. A empresa diz que centenas de companhias já usam, entre elas Robinhood, Merck, FactSet e a brasileira PicPay. “Com o Databricks AI Runtime e o Serverless, conseguimos escalar o treino e a inferência de LLMs mais rápido”, diz Vitor Rolim, staff machine learning engineer do PicPay, citado pela Databricks.

A AWS transformou o loop de treino em chamadas de API. As novas APIs de sessões de treino do SageMaker AI, em disponibilidade geral na Virgínia do Norte, no Oregon e em Mumbai, permitem escrever o próprio algoritmo de pós-treino, por exemplo uma recompensa sob medida para aprendizado por reforço, chamando operações como forward_backward(), optim_step() e sample() contra uma sessão ativa. O SageMaker cuida da alocação de GPUs, da execução distribuída, da recuperação de falhas e dos checkpoints, e cobra por token processado. Em paralelo, a AWS incluiu Muse Glimmer, Qwen 3.8 27B e Ministral 3 no seu serviço gerenciado de customização, com fine-tuning supervisionado, otimização por preferência e fine-tuning por reforço.

A Snowflake abriu os ML Jobs para containers próprios. Os times agora podem construir, validar e registrar as próprias imagens de runtime e rodar ML Jobs com elas, em disponibilidade geral desde 22 de outubro, com a mesma opção ainda em preview para notebooks.

O que você controla, e o que a plataforma assume

	Você controla	A plataforma assume
Databricks AI Runtime	Código, containers, frameworks, política de acesso aos dados	Capacidade de GPU, checagens de saúde, inicialização, isolamento, registros de faturamento
APIs de sessões de treino do SageMaker	O próprio algoritmo de treino, passo a passo	Cluster, distribuição, recuperação, checkpoints, cobrança por token
Customização gerenciada do SageMaker	Dados, escolha do modelo, técnica	Quase todo o resto
ML Jobs da Snowflake com imagens próprias	Dependências e pacotes da imagem	Computação e o perímetro governado dos dados
Todos eles	Avaliação, procedência dos dados, decisão de colocar em produção	Nada

A mudança está em onde os modelos são construídos

São produtos diferentes com uma direção comum: treinar está virando um serviço governado da plataforma de dados ou da nuvem, e não um cluster separado que um time precisa manter. Para as empresas, o efeito mais importante não é a velocidade. É que os dados de treino não precisam mais sair do lugar onde já vivem as regras de acesso, a linhagem e a trilha de auditoria. Um modelo ajustado dentro do Unity Catalog ou de uma conta Snowflake herda os controles dos dados com que aprendeu, o que torna a conversa com o encarregado de dados, no regime da LGPD, bem mais simples do que explicar uma cópia no storage de um fornecedor de GPU.

Há um segundo motor, e a Databricks o nomeia: agentes de código agora disparam experimentos de treino. Quando um agente consegue iniciar cem execuções durante a noite, como vimos com agentes rodando experimentos na Third Moment, a infraestrutura precisa ser rápida para subir, barata para parar e governada sem que uma pessoa aprove cada job.

O que não fica mais fácil

A avaliação. Nenhum desses serviços diz se o modelo treinado é melhor na sua tarefa. O teste da própria Microsoft, em que um modelo pequeno melhorou 85% na extração e o de fronteira ainda venceu, é o lembrete: customizar é uma aposta que precisa ser medida contra usar um modelo mais forte com um bom prompt, nos seus dados, antes de chegar perto da produção.

A disciplina de custo. GPUs serverless eliminam clusters ociosos, não o consumo. Cobrar por token ou por segundo deixa visível um loop de experimentos descontrolado, mas só se alguém ler os registros de faturamento. Treino disparado por agentes precisa dos mesmos orçamentos com alertas que a inferência disparada por agentes.

A responsabilidade pelas imagens próprias. Um container próprio é a sua cadeia de fornecimento de software. As imagens próprias da Snowflake e os containers trazidos à Databricks passam ao seu time a atualização de dependências e a gestão de vulnerabilidades.

As regiões. As APIs de sessões de treino do SageMaker estrearam em três regiões, nenhuma na América do Sul, e a customização gerenciada em quatro, também sem São Paulo. Onde o treino roda é uma decisão de residência de dados, e hoje a escolha para quem precisa manter dados no Brasil é mais estreita do que os anúncios sugerem.

A ordem prática

Se a sua empresa pensa em fine-tuning ou pós-treino este ano, a sequência que se sustenta é: escrever a avaliação primeiro, com exemplos próprios; tentar a adaptação mais barata, muitas vezes um prompt melhor ou uma busca melhor; treinar só quando a avaliação mostrar que o prompt chegou ao limite; e rodar o treino onde a governança dos dados já se aplica. As plataformas facilitaram muito o terceiro passo. O primeiro continua sendo seu.