NVIDIA libera quatro modelos abertos do Cosmos 3 para simular carros e robôs

Quatro peças abertas pra simular o mundo sem depender de API fechada

Em 5 de novembro de 2026, a NVIDIA publicou no Hugging Face Blog quatro novos checkpoints que entram na família Cosmos 3: Cosmos3-Nano-Transfer-Auto, Cosmos3-Nano-Sim-Auto, Cosmos3-Nano-Sim-Transfer e Cosmos3-Nano-Sim-Bimanual. Todos nascem de pós-treinamento sobre o Cosmos3-Nano, têm 16 bilhões de parâmetros treináveis e saem sob a licença OpenMDW1.1, que permite uso comercial e não comercial dentro dos termos definidos pela própria NVIDIA.

Para quem constrói simulação de veículos autônomos ou robótica, a novidade não é o Cosmos 3 em si, a plataforma já existia. É o fato de esse pedaço específico do pipeline, gerar vídeo condicionado a ações e controles de cena, agora poder ser baixado e rodado localmente, em vez de depender de uma API fechada de fornecedor terceiro.

Os quatro modelos, um por pedaço do problema

Os dois primeiros formam um par: o Transfer-Auto é a base bidirecional para geração offline, e o Sim-Auto é a versão destilada dele, treinada de forma causal pra rodar em streaming. Quem precisa adaptar o Cosmos 3 a um rig de câmeras e LiDAR próprio começa pelo Transfer-Auto e só depois destila pro Sim-Auto. Já o Sim-Transfer e o Sim-Bimanual resolvem o mesmo problema de formas opostas: no primeiro, a física mora no simulador externo e o modelo só pinta o RGB; no segundo, o modelo prevê a cena inteira direto a partir da ação, sem simulador físico por trás.

No caso do Sim-Bimanual, o exemplo de ação mista divulgado pela NVIDIA usa 59 valores de controle, preenchidos até 64 durante o treino, com um esquema que define sistemas de coordenadas, rotações, calibração de garra e máscaras de validade. É um contrato de dados rígido: quem for plugar seu próprio braço robótico precisa respeitar exatamente essa convenção, senão o modelo interpreta mal a ação.

Por baixo do capô: streaming, atenção causal e quatro estágios de treino

O backbone do Cosmos 3 é uma Mixture-of-Transformers que liga uma rede de processamento de texto a uma rede de geração visual por atenção. O modelo não trabalha em pixel cru: opera sobre representações comprimidas chamadas latentes, em que cada passo latente equivale a quatro frames de RGB. O Transfer-Auto prevê um passo por bloco gerado; a configuração otimizada do Bimanual prevê dois. Blocos menores deixam o controle influenciar a geração com mais frequência, ao custo de mais chamadas ao modelo.

A atenção é temporal-causal: o modelo lê o histórico e os controles disponíveis, mas tem bloqueado o acesso às observações futuras que está tentando prever. Um cache de chave-valor guarda o que já foi processado para a próxima predição, o mesmo tipo de truque usado pra acelerar inferência em LLMs↳LLMs48 conteúdosConsiderações básicas de hardware para modelos de linguagem em código aberto: Memória, Desempenho e ViabilidadeMarketing Tech · out 2025Modelos de linguagem sob ataque: o lado obscuro da IA generativaDevSecOps · mai 2025Criando um LLM – modelo de linguagem de grande escala – do zero com TransformersAI · abr 2024Ver tudo em AI →.

O treino segue uma receita de quatro estágios:

1. Estágio 0, adaptação bidirecional: aprende o domínio e a relação entre controle e vídeo a partir de clipes completos já gravados.
2. Estágio 1, teacher forcing: prediz cada trecho usando observações gravadas anteriores e os controles disponíveis, com a resposta certa escondida.
3. Estágio 2, destilação por consistência: um professor congelado treina um aluno capaz de gerar cada trecho em quatro passos de denoising.
4. Estágio 3, self-forcing: o modelo treina sobre o próprio histórico gerado, com sinal de um professor congelado e de um modelo de score auxiliar.

O último estágio é o que evita que o modelo degrade ao longo de uma simulação longa: um objeto levemente mal previsto vira contexto pra todos os frames seguintes, então pequenos erros tendem a se acumular. Treinar sobre histórico gerado, e não só sobre dados reais, expõe o modelo a esse tipo de erro antes de ele sair pra produção.

O preço de rodar isso fora de um datacenter

Antes de baixar qualquer checkpoint, vale olhar os requisitos que a própria NVIDIA publicou: Linux↳Linux34 conteúdosKali Linux em um Servidor VPS: como, quando e por que usar?DevSecOps · dez 2024Construindo um Windows Service ou Linux Daemon com Worker Service & .NET Core – Parte 2Dev (Back & Front) · jul 2020Criando uma WebApi utilizando .NET, Linux e VSCodeDev (Back & Front) · ago 2019Ver tudo em DevSecOps →, GPU NVIDIA, Docker e NVIDIA Container Toolkit. O setup de referência, usando vLLM-Omni, foi testado numa única GB200, e a NVIDIA é explícita: isso não é uma especificação de memória mínima, é só o hardware em que o time testou.

Na prática, isso significa que ninguém sabe ao certo qual é o piso real de VRAM pra rodar um modelo de 16 bilhões de parâmetros com geração em streaming. Pra um time no Brasil sem GPU de datacenter à mão, o caminho mais realista é alugar instância em nuvem com GPU de classe data center, não rodar localmente numa placa de consumo. Isso muda o cálculo de custo do protótipo: o modelo em si é gratuito e a licença OpenMDW1.1 permite uso comercial, mas a conta de GPU na nuvem continua existindo, só que agora sem taxa por chamada de API.

Pensado pra agente de código, não só pra humano com terminal

Um detalhe que chama atenção no material da NVIDIA é a forma como a documentação é organizada: para cada checkpoint, a orientação é literalmente apontar um agente de código pra uma "skill" aberta e deixar que ele rode a inferência, além de notebooks prontos pra quem prefere explorar manualmente. Essa escolha de documentação encaixa no jeito como boa parte do público técnico já trabalha hoje, delegando setup e execução a um assistente de código em vez de montar o ambiente linha a linha.

Isso reduz fricção de onboarding, mas não resolve o problema de hardware descrito acima. Um agente de código bem orientado ainda vai esbarrar na exigência de GPU NVIDIA com Docker e Container Toolkit configurados; o que muda é o tempo gasto lendo documentação pra chegar lá.

Quando vale a pena, e quando não vale

Vale a pena pra quem já trabalha com robótica usando embodiments como YAM ou AgiBot e precisa de ambiente de simulação que responda a ações reais de um braço bimanual; pra times de direção autônoma que querem gerar dados sintéticos multi-sensor (câmera e LiDAR) variando clima e iluminação sem depender de frota real rodando nas ruas; e pra quem já tem um simulador físico próprio e só precisa de uma camada de renderização fotorrealista em cima dos controles de profundidade e segmentação que esse simulador já calcula.

Não vale a pena pra quem quer prototipar localmente um jogo ou uma demo interativa simples: a pegada de hardware, com teste em GB200 e 16 bilhões de parâmetros, está muito acima do que cabe num notebook ou numa GPU de consumo. Times que não trabalham com direção autônoma ou robótica física também não têm uso direto pros World Scenario Maps e pros controles de LiDAR que sustentam dois dos quatro checkpoints. Vale lembrar ainda que os pesos exportados pra inferência não trazem estado de otimizador: quem quiser continuar o pós-treinamento precisa guardar os checkpoints completos de treino, não só os de inferência.

Fonte: Hugging Face Blog