NVIDIA lança Molt, framework de RL agêntico em PyTorch
O time NeMo da NVIDIA publicou o Molt, um framework de aprendizado por reforço para agentes escrito direto em PyTorch, sob licença Apache 2.0. O argumento é o tamanho: cerca de 8,6 mil linhas de código de RL, contra 62 mil do verl e 25 mil do slime pela mesma forma de contagem. Rodar as receitas que acompanham o projeto exige dois nós de oito GPUs H100, oito para treino e oito para geração.
O que é o Molt
Molt é um framework de aprendizado por reforço agêntico da NVIDIA, escrito em PyTorch e distribuído sob licença Apache 2.0. Ele treina agentes de LLM em tarefas de vários turnos, como uso de ferramenta, execução de código e ambientes de visão e linguagem, e tem cerca de 8,6 mil linhas de código de RL.
Um veículo cobriu o lançamento até o fechamento desta matéria: o MarkTechPost, em 1º de agosto de 2026, a partir do paper e do repositório. Os números abaixo saem dessa apuração. Ninguém publicou teste independente.
O problema que o Molt diz atacar
Pesquisa em RL agêntico é modificação constante de algoritmo. Estimador novo, etapa nova no pipeline, esquema novo de geração. Nos frameworks estabelecidos, cada mudança atravessa camadas de trainer, backend distribuído e cola de rollout. O pesquisador paga esse custo a cada iteração.
A NVIDIA declara um alvo de projeto pouco comum: a base de código precisa caber na cabeça de uma pessoa e ser pequena o bastante para um assistente de código de IA ler inteira e raciocinar sobre ela. É meta declarada. Ninguém mediu o resultado.
8,6 mil linhas, e como o número foi obtido
A contagem não cobre o repositório inteiro. Ela traça o grafo de importação a partir do ponto de entrada de RL de cada framework e soma o que entra na execução. Pelo mesmo método:
| Framework | Linhas de código de RL |
|---|---|
| verl | ~62.000 |
| slime | ~25.000 |
| Molt | ~8.600 |
| OpenRLHF | ~7.200 |
O OpenRLHF é menor que o Molt. Quem escolher por tamanho de código não encontra aqui o menor da categoria. A NVIDIA definiu a metodologia de contagem, e o material apurado não traz comparação de qualidade, velocidade ou resultado de treino entre os quatro.
O gargalo são 16 GPUs H100
O paper trata o Molt como infraestrutura de pesquisa, não como serviço de treino de produção. O projeto sai com scripts de lançamento, scripts para Slurm e um container pronto. As receitas publicadas pressupõem dezesseis H100 divididos em dois nós.
Esse número delimita quem consegue rodar: laboratórios de fronteira e adjacentes, startups de IA bem capitalizadas fazendo pós-treino, grupos de pesquisa corporativa em finanças, saúde e robótica que treinam agentes contra ambientes proprietários, e laboratórios acadêmicos com acesso multi-nó a H100 ou H200. A Apache 2.0 derruba a barreira jurídica e deixa a barreira de capital intacta.
Para quem tem o hardware, a lista de aplicações inclui agentes multi-turno de uso de ferramenta, agentes que executam código, ambientes de visão e linguagem (a receita geo3k vem incluída), laços de recompensa com LLM como juiz e destilação on-policy para um modelo estudante menor.
Ray, vLLM e AutoModel por baixo
O Molt compõe três peças que já existem: Ray para alocação e filas assíncronas, vLLM para geração, e o NVIDIA AutoModel com FSDP2 para treino. O projeto não forka nenhuma das três, então melhoria a montante chega como troca de versão do container, sem rebase. Isso reduz a dívida de manutenção de quem adota.
O runtime tem um pool de agentes, um conjunto de engines vLLM atrás de um roteador de requisições, e um único ator de política treinável. Um pool de streaming mantém grupos de prompt em voo para as engines não secarem enquanto o ator treina. Na atualização de pesos, o partial rollout pausa as engines, transmite os shards do ator por NCCL direto para cada uma e retoma as requisições retidas em vez de descartá-las.
Duas formas de escrever o agente
Uma execução de RL aponta para um módulo Python que exporta um AgentRunner. O resto é código comum, incluindo a função de recompensa.
Com Env, o framework é dono do laço do LLM, num step() alinhado ao padrão Gymnasium. Com ChatAgent, quem é dono do laço é o usuário, chamando pelo SDK de prateleira da OpenAI ou da Anthropic. O Molt sobe um servidor de loopback que fala os dois protocolos, e esse servidor decodifica cada requisição numa acumulação exata em tokens. Quando um agente de horizonte longo compacta o contexto e reescreve o prefixo, o servidor fecha o segmento corrente e abre outro sozinho.
Quem já escreveu agente com o SDK da OpenAI ou da Anthropic consegue treiná-lo sem reescrever o laço.
Três invariantes, e o caso do MoE
Três regras de correção organizam o desenho.
- Identidade de token. Os ids de token amostrados definem a trajetória, e não uma transcrição retokenizada.
- Semântica de versão de política. Tokens treináveis guardam as log-probabilidades da política que os gerou, e o uso assíncrono é corrigido token a token, atrás de um portão em nível de sequência.
- Consistência de forward. Geração e ator precisam concordar sobre a semântica do modelo.
A terceira pesa mais em política de mistura de especialistas. Os roteadores de geração e de treino escolhem experts de forma independente, e diferença numérica pequena vira escolha diferente no top-k. O Molt aplica replay de roteamento: o vLLM devolve os ids de expert por token, e o forward de treino repete a mesma escolha.
O que o material não responde
Falta número de desempenho. Nenhum benchmark de velocidade de treino, qualidade do agente resultante ou custo por execução compara o Molt aos frameworks que ele cita. Não há teste de terceiro nem declaração nominal de ninguém da NVIDIA no material apurado. Nada sobre disponibilidade ou custo de acesso a H100 em nuvem no Brasil.
Para quem decide no Brasil, o efeito é estreito. Quem já paga por cluster de H100 ganha uma alternativa aberta e enxuta para pós-treino de agentes, com laço compatível com os SDKs que a equipe já usa. Quem não tem o cluster ganha uma leitura de como o pós-treino de agente está sendo desenhado lá fora.
--- Apurado em 1 veículo de 1 país.