Baseten disponibiliza Serverless Loops para pós-treinamento

Em 6 de novembro de 2026, Baseten anunciou a disponibilidade geral de Serverless Loops, abrindo para todos seu SDK gerenciado para ajuste fino supervisionado e aprendizado por reforço em modelos abertos. O serviço cobra pelo treinamento com base no número de tokens e oferece um caminho direto dos pontos de verificação para Baseten Dedicated Inference.

Loops foi concebido com uma divisão de tarefas: os usuários fornecem o sinal de treinamento, enquanto a Baseten opera as GPUs, os kernels, as arquiteturas dos modelos e a infraestrutura de treinamento distribuído. O SDK de Python treina adaptadores LoRA mantendo congelados os pesos do modelo-base. Os usuários escolhem o modelo-base, a classificação LoRA, a taxa de aprendizado, a função de perda, os dados ou o ambiente e o algoritmo; a Baseten executa o treinador, o amostrador, a sincronização de pesos e a infraestrutura de suporte.

Um pacote de compatibilidade preserva as importações do Tinker e as principais chamadas de treinamento e amostragem para equipes que migram scripts existentes. O guia de migração ainda exige mudar a autenticação para uma chave de API da Baseten, retorna os pontos de verificação como URLs de arquivos paginadas, exige entradas de imagem em linha e define a cobertura dos módulos LoRA por família de modelos. A compatibilidade abrange a API de treinamento, mas deixa vários detalhes específicos da infraestrutura para as equipes ajustarem.

Modelos sem servidor e cobrança

O catálogo sem servidor contém três modelos: Qwen/Qwen3.6-35B-A3B e zai-org/GLM-5.3-Flash para texto e visão, e zai-org/GLM-5.3 somente para texto. Cada um aceita um comprimento máximo de sequência de 262.144 tokens. A configuração de contexto longo do GLM-5.3 não é compatível com cross_entropy ou dpo funções de perda. O modo dedicado abrange um catálogo mais amplo de modelos, cobra pelo tempo de uso da GPU e oferece controles para réplicas, reutilização aquecida e capacidade spot.

As execuções sem servidor usam capacidade compartilhada sem exigir reservas de GPU e cobram pelos tokens usados no treinamento e na amostragem. O tempo gasto lendo resultados, alterando uma função de recompensa ou em inatividade não gera cobranças por tokens. A seleção de modo padrão pode recorrer à capacidade dedicada para um modelo, uma classificação LoRA ou um comprimento de sequência não compatível, ou quando uma execução reutiliza implantações de outra execução. Definir o escopo como sem servidor faz com que uma solicitação não compatível falhe, em vez disso.

A habilitação de um modelo não garante seu provisionamento. O acesso específico ao espaço de trabalho, a indisponibilidade de GPUs e os limites de treinadores definidos pela organização ainda podem impedir uma execução, estabelecendo limites práticos de capacidade para o modelo de cobrança por token além dos limites do catálogo publicado.

Pontos de verificação e inferência em produção

O guia de início rápido apresenta quatro operações principais: forward_backward para calcular perdas e gradientes, optim_step para atualizar adaptadores, sample para geração e save_state para treinamento retomável. A publicação dos pesos do amostrador cria um ponto de verificação que pode ser implantado e um cliente de amostragem vinculado a ele. Uma operação separada save_state preserva o estado do modelo e do otimizador. A primeira solicitação de amostragem pode levar vários minutos enquanto a capacidade sem servidor é iniciada, um aspecto prático a considerar em experimentos curtos.

Um ponto de verificação do amostrador é implantado como modelo-base com o adaptador LoRA treinado carregado. Os pontos de verificação permanecem disponíveis depois que suas execuções terminam e podem ser implantados pela CLI, pela API REST ou pelo painel usando um token de acesso do Hugging Face, pois a implantação baixa os pesos do modelo-base. O endpoint compatível com OpenAI resultante gera cobranças pelo uso da GPU enquanto está ativo. Excluir essa implantação interrompe a cobrança da GPU sem excluir o ponto de verificação; desativar a execução do Loops não remove a implantação.

Para o lançamento geral, a Baseten aprimorou o tratamento de erros temporários de rede e falhas de GPU, reduziu a sobrecarga de inicialização e acelerou as transferências de pesos entre treinadores e amostradores. Segundo a Baseten, essas mudanças dão suporte a mais cargas de trabalho simultâneas de clientes, e sua infraestrutura de inferência em produção atende a mais de 15 bilhões de solicitações por dia. O fluxo de produção inclui escalabilidade automática, gerenciamento de implantações e métricas de inferência, enquanto os usuários podem baixar pesos no formato Safetensors do Hugging Face.

Validação e primeiras cargas de trabalho de clientes

A Baseten afirma ter validado o serviço com testes numéricos e experimentos de aprendizado por reforço de ponta a ponta usando tarefas do τ-bench nos setores de varejo, aviação e serviços bancários, seguidos por avaliações com tarefas difíceis reservadas para teste. O projeto τ-bench descreve um benchmark que avalia se agentes conseguem conversar com usuários, chamar ferramentas, recuperar conhecimento e seguir políticas em diferentes domínios empresariais, com resultados verificados em relação a dados comprováveis de bancos de dados.

A Baseten informa que a NVIDIA fez o pós-treinamento do Nemotron Super 3.5 VL em tarefas de texto e visão, aumentando a precisão da classificação de intenção de 76,8% para 94% e alcançando F1 de validação de 87% na extração de recibos; o trabalho também incluiu aprendizado por reforço para contagem visual de objetos. A Datadog está usando aprendizado por reforço agêntico com múltiplas interações para testar ideias de treinamento para seu agente de SRE, e a Ambience Healthcare fez o pós-treinamento de modelos para corrigir erros de transcrição clínica e registrar com precisão a terminologia e a formatação médicas.

LangChain Labs está pós-treinando modelos com rastros de agentes para o LangSmith Engine, incluindo trabalhos que leem um repositório do GitHub para diagnosticar um problema e redigem o prompt ou a alteração de código para uma solicitação de pull. É possível alternar para um modelo menor de pesos abertos para classificar os rastros de acordo com o modo e a gravidade da falha ou associá-los a problemas existentes. O fluxo de trabalho da LangChain ilustra como o comportamento de um aplicativo se torna o alvo do treinamento, com o tamanho do modelo e a especialização da tarefa definidos de acordo com o trabalho.

Os relatos de clientes documentam o uso antes do anúncio da disponibilidade geral (GA) e mostram o ciclo de infraestrutura pretendido: os dados do aplicativo se tornam dados de entrada para o treinamento, os pontos de verificação são avaliados e os modelos selecionados avançam rumo à produção. Para as equipes de infraestrutura, o limite de custos é igualmente claro. As execuções sem servidor compatíveis dispensam reservas de GPUs e cobranças de tokens durante o tempo ocioso, enquanto um endpoint de inferência ativo continua cobrando pelo uso da GPU; o catálogo sem servidor e a capacidade do espaço de trabalho determinam onde a opção sem servidor pode ser aplicada.