Showing Posts From

Mlops

Archon: o framework open-source que transforma Claude Code e Codex em pipelines determinísticos

O repositório github.com/coleam00/Archon cruzou 14 mil stars no GitHub neste mês de abril de 2026 — e o timing não é à toa. A comunidade estava com um problema crescente nas mãos: agentes de código como Claude Code e OpenAI Codex CLI são poderosos, mas operam num modo essencialmente freeform. Você dá um prompt, o agente faz o que acha melhor, e reproduzir o resultado na próxima rodada é uma questão de sorte. O Archon resolve isso. O que é o Archon Archon é um harness de workflows para agentes de código. O projeto se autodefine como o primeiro benchmark builder para AI coding agents, mas o que ele realmente faz é mais prático: transforma interações freeform com agentes em pipelines YAML versionados, determinísticos e auditáveis. Em vez de você abrir o Claude Code e mandar um prompt livre, você define um workflow que o Archon orquestra: # exemplo de workflow archon workflow: name: feature-implementation steps: - name: planning agent: claude-code prompt_template: prompts/planning.md outputs: [plan.md] - name: implementation agent: claude-code depends_on: planning prompt_template: prompts/implement.md inputs: [plan.md] - name: validation agent: codex-cli depends_on: implementation prompt_template: prompts/validate.md - name: code-review agent: claude-code depends_on: validation prompt_template: prompts/review.md - name: create-pr agent: codex-cli depends_on: code-review prompt_template: prompts/pr.mdO YAML não é complicado — é exatamente o que você já faz mentalmente quando trabalha com esses agentes, só que formalizado e versionável num repositório. A sacada dos git worktrees O detalhe de arquitetura que mais me chamou atenção: cada execução de workflow roda em seu próprio git worktree. Isso não é cosmético. Sem isso, rodar duas instâncias de Claude Code em paralelo no mesmo repo é uma receita para conflito de merge. Com worktrees isolados, o Archon consegue executar múltiplos workflows em paralelo sem que as instâncias pisem umas nas outras. Cada feature branch de agente vive no seu próprio diretório de trabalho enquanto o worktree principal permanece limpo. # o archon cria algo como: .git/worktrees/ archon-run-abc123/ # feature A archon-run-def456/ # feature B (rodando em paralelo) archon-run-ghi789/ # bugfix C (também em paralelo)Isso abre caminho para um padrão que eu vejo cada vez mais necessário em times que usam agentes de código a sério: pipelines paralelos sem coordenação manual. Você define os workflows, o Archon gerencia o isolamento. O que o Archon cobre Os workflows out-of-the-box do Archon cobrem o ciclo completo de desenvolvimento com agentes:Etapa Descriçãoplanning Agente quebra a tarefa em subtarefas, gera plano em markdownimplementation Agente escreve o código seguindo o planovalidation Executa testes, lint, verifica outputs esperadoscode review Segunda passagem do agente revisando o próprio códigoPR creation Abre pull request com descrição gerada automaticamenteEsse ciclo inteiro é rastreável porque cada step gera artefatos (arquivos markdown, logs de execução, diffs) que ficam no git junto com o código. Como rodar na prática A instalação é direta: git clone https://github.com/coleam00/Archon cd Archon pip install -r requirements.txt# configure seus agentes cp config.example.yaml config.yaml # edite config.yaml com suas API keysPara rodar um workflow: python archon run --workflow workflows/feature.yaml \ --task "implementar endpoint POST /users com validação pydantic"O Archon cria o worktree, injeta o prompt no agente configurado (Claude Code ou Codex CLI), executa os steps em sequência, e no final você tem um PR aberto ou um diff pronto para revisar. Toda a execução fica logada num diretório .archon/runs/ dentro do worktree. Uma coisa que eu gosto: você pode mixar agentes por step. Usar Claude Code para planning e implementation (onde o raciocínio mais longo ajuda) e Codex CLI para validation e PR creation (onde você quer execução rápida de comandos). O Archon não te força a escolher um único agente. Comparação com alternativas Justo comparar com o que existe. O espaço de "orchestration for AI coding agents" ainda é jovem, mas já tem algumas peças:Ferramenta Modelo Determinismo Isolamento Open-sourceArchon Workflow YAML Alto git worktrees SimLangGraph Grafo de estados Médio Nenhum nativo SimCrewAI Multi-agent roles Médio Nenhum nativo SimDevin/Swe-agent End-to-end autônomo Baixo Sandbox Docker ParcialCopilot Workspace Interface GitHub Baixo GitHub nativo NãoO Archon ocupa um nicho específico: você quer controle de processo sem abrir mão dos modelos mais capazes (Claude Code, Codex). LangGraph e CrewAI são mais flexíveis para multi-agent genérico, mas não pensam especificamente em coding workflows com isolamento de worktree. Devin e similares tentam fazer tudo sozinhos — o que funciona para casos simples, mas quebra quando você precisa de reproducibilidade ou auditoria. Limitações e o que ainda não funciona Sendo honesto sobre o estado atual do projeto:Maturidade: com 14k stars em abril de 2026, o Archon está em crescimento acelerado, mas não é production-hardened no mesmo nível de um Airflow ou Prefect. Para casos críticos, espere alguns meses de estabilização. Modelos suportados: por ora, o foco é em Claude Code e OpenAI Codex CLI. Se você usa outros agentes de código (Gemini Code Assist, por exemplo), vai precisar escrever um adapter. Paralelismo com limites de API: rodar vários workflows em paralelo consome tokens na mesma velocidade. Se você tem rate limits apertados nas APIs, o paralelismo vai esbarrar nisso. YAML verboso: workflows mais complexos ficam grandes. Falta uma abstração de composição — poder importar sub-workflows de um arquivo central, por exemplo. Observabilidade: o logging existe, mas não há integração nativa com ferramentas de MLOps como MLflow ou Weights & Biases. Você vai querer adicionar isso se estiver rodando em escala.Abri uma issue sobre o último ponto no repo. A comunidade está ativa — as respostas chegam rápido. Por que isso importa para times brasileiros Aqui tem uma observação prática que vai além do hype: times de desenvolvimento no Brasil raramente têm orçamento para tooling enterprise de AI engineering. Plataformas como GitHub Copilot Workspace, Replit Ghostwriter ou as ofertas gerenciadas de automação de código custam por seat de um jeito que não escala para squads menores. O Archon é open-source, roda local ou na sua própria infra, e usa diretamente as APIs de Claude Code e Codex — que você já está pagando de qualquer forma. O overhead de infraestrutura é zero: um processo Python, git nativo e suas API keys. Para um time de quatro pessoas em São Paulo que quer workflows reproduzíveis para geração de código, o Archon é a diferença entre "a IA às vezes funciona assim" e "toda execução segue o mesmo processo e está versionada". Isso é especialmente relevante quando você precisa auditar o que o agente fez — seja para debug, seja para compliance interno. Veredito O Archon preenche um gap real: determinismo em workflows de agentes de código. Não é magia — é engenharia de processo aplicada a ferramentas que nasceram como interfaces interativas. A ideia de usar git worktrees para isolamento é elegante e barata. O formato YAML é verboso mas versionável. Se você está usando Claude Code ou Codex CLI de forma ad hoc e precisa escalar isso para um processo repetível, o Archon é o lugar óbvio para começar. Não está pronto para produção crítica sem monitoramento adicional, mas está bom o suficiente para ser a base do seu CI pipeline de AI-assisted development. Repo: github.com/coleam00/Archon. Clona, define um workflow simples, roda duas vezes e compara os artefatos. Se os outputs são idênticos, você acabou de ter determinismo em agente de código. Vale o teste.

Hugging Face Transformers v5: release semanal e o que muda para quem desenvolve com LLMs

O transformers é provavelmente o pacote Python mais instalado em qualquer projeto de IA dos últimos três anos. E a Hugging Face acabou de lançar a v5 com uma mudança que não é técnica — é operacional: o release cycle caiu de cinco semanas para uma. O v5.0 saiu na primeira semana de abril de 2026. O v5.1 vem na semana que vem. O v5.2 na seguinte. Para um ecossistema com 13 milhões de usuários, 2 milhões de modelos públicos e 500 mil datasets, isso muda o ritmo de tudo. A pergunta que importa: isso é bom? O que mudou na v5 (além do ciclo) Antes de falar do release cycle, vale entender o que a v5 traz de concreto na API. Model definitions mais simples. A v4 acumulou anos de boilerplate. Definir um modelo customizado exigia herdar de PreTrainedModel, implementar forward(), registrar configs, e torcer para não esquecer nenhum hook. A v5 reduziu isso. A nova API de definição de modelos usa decorators e inferência de config, eliminando boa parte do código repetitivo. Exemplo rápido — carregar e rodar inference na v5: from transformers import AutoModelForCausalLM, AutoTokenizermodel = AutoModelForCausalLM.from_pretrained("meta-llama/Llama-4-8B") tokenizer = AutoTokenizer.from_pretrained("meta-llama/Llama-4-8B")inputs = tokenizer("Explique transformers v5 em uma frase:", return_tensors="pt") output = model.generate(**inputs, max_new_tokens=100) print(tokenizer.decode(output[0], skip_special_tokens=True))A interface pública não mudou radicalmente — from_pretrained continua sendo o ponto de entrada. O que mudou está por baixo: o pipeline de inicialização é mais rápido, a resolução de configs é mais previsível, e modelos novos podem ser adicionados ao hub sem esperar o próximo release do pacote. Suporte a novos modelos sem upgrade do pacote. Esse é o ponto mais relevante para o dia a dia. Na v4, quando um modelo novo aparecia (Qwen 3.5, Gemma 3, o que fosse), você precisava esperar o merge do PR no transformers, o release seguinte (5 semanas), e aí sim pip install --upgrade. Na v5, a arquitetura de model loading foi desacoplada — modelos podem ser registrados diretamente no Hub e carregados sem que o pacote precise de update. Na prática, isso significa que o from_pretrained da v5 consegue carregar modelos que foram publicados depois da sua versão instalada. Menos fricção, menos pip install desnecessário. Release semanal: por que agora A justificativa da Hugging Face é direta: inferência representa 85% do budget enterprise de IA. Treinamento é 15%. Se a maioria do dinheiro está em inference, a velocidade com que novos modelos e otimizações chegam à biblioteca importa mais do que parece. Com release de 5 semanas, um fix de performance em inference ficava preso por até um mês esperando a janela de release. Com release semanal, o fix sai na próxima terça. Para quem opera inference em escala, isso é relevante. O modelo semântico de versionamento continua: v5.x onde x incrementa toda semana. Breaking changes só em major versions. A promessa é que v5.1 → v5.2 → v5.3 são todas backward-compatible dentro da v5. Migração v4 para v5: o que quebra Testei a migração em dois projetos — um pipeline de fine-tuning com LoRA e um serviço de inference com vLLM na frente. Aqui está o que encontrei: Breaking changes confirmados:Componente v4 v5 ImpactoTrainingArguments kwargs livres Validação strict com Pydantic Scripts com args custom quebrampipeline() default device CPU Auto-detect (GPU se disponível) Testes que assumem CPU falhamTokenizer return type Dict BatchEncoding com métodos extras Code que acessa .items() direto pode quebrarDeprecated models Disponíveis com warning Removidos GPT-2, BERT-base configs legadas somemO que não quebra: AutoModel, AutoTokenizer, from_pretrained com model IDs do Hub, Trainer API básica, integração com PEFT/LoRA. O comando para testar compatibilidade antes de migrar: pip install transformers==5.0.0 --dry-run 2>&1 | grep -i conflictE para quem usa requirements pinados (como deveria): # Teste em ambiente isolado python -m venv test-v5 && source test-v5/bin/activate pip install transformers==5.0.0 python -c "from transformers import AutoModel; print('OK')" python -m pytest tests/ -x --tb=shortNa minha experiência, a migração do pipeline de fine-tuning levou 40 minutos — a maior parte ajustando TrainingArguments para o novo schema Pydantic. O serviço de inference não precisou de mudança nenhuma porque o vLLM abstrai o transformers por baixo. O elefante na sala: estabilidade vs velocidade Aqui está onde eu tenho uma opinião forte. Release semanal é ótimo para quem consome modelos novos. Se você trabalha em pesquisa, experimenta arquiteturas novas toda semana, ou precisa do modelo que saiu ontem rodando amanhã — o ciclo semanal é um presente. Mas para quem tem pipelines em produção, release semanal é um convite à instabilidade se você não tiver disciplina de versionamento. E a maioria dos times não tem. O cenário que me preocupa:Time pina transformers>=5.0 no requirements (sem upper bound) Deploy na segunda roda com v5.3 Deploy na terça roda com v5.4 (release saiu de manhã) Comportamento muda sutilmente — não quebra, mas output de inference diverge Ninguém percebe até o monitoring pegar uma regressãoA solução é simples, mas exige disciplina: # requirements.txt — SEMPRE pine a minor version transformers==5.0.0# Ou se precisa de flexibilidade controlada transformers>=5.0.0,<5.1.0E rode testes de regressão no output do modelo — não só testes unitários. Se o output do seu modelo para os mesmos inputs mudou entre versions, você precisa saber antes do deploy, não depois. Como gerenciar isso na prática Minha recomendação para times que usam transformers em produção:Pine a versão exata no requirements.txt e no Dockerfile Atualize intencionalmente — não automaticamente. Crie uma task quinzenal de "avaliar se vale subir a versão" Tenha testes de output — compare o output do modelo com uma fixture salva. Se mudou, investigue antes de mergear Separe pesquisa de produção — o time de research pode rodar bleeding edge. O serviço de inference pina e só atualiza com motivoPara quem está começando um projeto novo, a v5 é o caminho. Não faz sentido iniciar na v4 agora. A API é mais limpa, o carregamento de modelos é mais flexível, e o ecossistema vai convergir para v5 rapidamente. Veredito O Transformers v5 é uma evolução pragmática. A API simplificada e o desacoplamento de model loading são melhorias reais que reduzem fricção no dia a dia. O release semanal é a decisão mais corajosa — e a mais arriscada. Para pesquisa e experimentação, é puro upside: modelos novos chegam mais rápido, fixes saem em dias, e a barreira entre "modelo publicado no Hub" e "modelo utilizável no código" praticamente desaparece. Para produção, o release semanal é neutro — desde que você trate versionamento como infraestrutura, não como detalhe. Pine suas versões. Teste seus outputs. Atualize com intenção. A Hugging Face está apostando que a velocidade do ecossistema importa mais que a estabilidade percebida. Considerando que 85% do budget vai para inference e que modelos novos aparecem toda semana, é difícil discordar. Mas a responsabilidade de não quebrar seu pipeline agora é mais sua do que da biblioteca. pip install transformers==5.0.0. Rode seus testes. Migre com calma.

Agentic MLOps: como A2A e MCP estão substituindo DAGs do Airflow por equipes de agentes

Se você já manteve um pipeline de ML em produção com Airflow, sabe o que é acordar às 3h da manhã porque uma DAG de retraining falhou no step 14 de 23. O log diz Task failed: validation_step_3. Qual validation? De qual modelo? Com quais dados? Boa sorte. O artigo da InfoQ publicado em março de 2026 — "Architecting Agentic MLOps with A2A and MCP" — propõe algo que venho testando nos últimos meses: trocar DAGs rígidos por equipes de agentes que se comunicam via protocolos padronizados. Não é hype. É uma mudança de arquitetura com trade-offs reais que vale a pena entender. O problema com DAGs de MLOps Pipelines tradicionais de ML — Airflow, Prefect, Dagster — tratam MLOps como uma sequência linear: ingestão → feature engineering → treino → validação → deploy → monitoramento. Cada step é um nó no grafo. A lógica de decisão ("o modelo passou no threshold?", "precisa de rollback?") vira um emaranhado de BranchPythonOperator e XComs que ninguém quer debugar. O problema não é o Airflow. É que ML pipelines não são lineares. Validação pode exigir retreino com dados diferentes. Deploy pode precisar de canary progressivo com rollback automático. Monitoramento pode detectar drift e disparar retraining sem esperar o schedule. Tentar expressar isso como um DAG estático é como tentar desenhar um fluxograma para uma conversa — funciona no PowerPoint, quebra na realidade. A2A + MCP: os dois protocolos que habilitam a mudança Antes de entrar na arquitetura, vale alinhar os protocolos. Já cobri MCP em detalhe no post anterior, mas o resumo rápido:MCP (Model Context Protocol, Anthropic): protocolo de conexão entre agentes e ferramentas externas. O agente declara o que precisa, o MCP server expõe as capabilities. Pense nele como a interface entre o agente e o mundo — registries de modelo, buckets S3, APIs de monitoramento, o que for.A2A (Agent-to-Agent, Google): protocolo de comunicação entre agentes. Diferente do MCP que conecta agente→ferramenta, o A2A conecta agente→agente. Cada agente publica um Agent Card declarando suas capabilities, aceita Tasks via JSON-RPC, e pode negociar formatos de resposta. É o que permite que um Validation Agent peça ao Training Agent para retreinar com parâmetros específicos sem hardcodar essa lógica.A convergência dos dois é o que torna Agentic MLOps viável. MCP para acessar infraestrutura, A2A para coordenar decisões entre agentes. A arquitetura em camadas O paper da InfoQ propõe três agentes core: Orchestrator Agent O cérebro do pipeline. Recebe o trigger (schedule, webhook, drift alert) e decide o plano de execução. Diferente de uma DAG, o plano é dinâmico — o orchestrator avalia o contexto (qual modelo, qual dataset, qual o estado do último deploy) e monta a sequência em runtime. Validation Agent Responsável por qualidade do modelo. Roda suítes de teste, verifica drift de dados, compara métricas com baselines. O ponto-chave: via A2A, ele pode rejeitar um modelo e pedir retreino com instruções específicas ("accuracy caiu 3pp no segmento X, retreinar com oversampling desse segmento"). Em uma DAG, isso seria um loop com estado compartilhado que ninguém quer manter. Deployment Agent Gerencia canary, blue-green, rollback. Conecta via MCP ao Kubernetes, ao registry de modelos, ao Prometheus. Se o canary falha, comunica via A2A ao Orchestrator que decide o próximo passo — rollback, retreino, ou escalar para um humano. Hands-on: esqueleto de um pipeline agêntico Para materializar a ideia, montei um esqueleto usando CrewAI (que já suporta A2A e MCP nativamente desde a v0.8) com MCP servers para acessar MLflow e Kubernetes: # agentic_mlops_crew.yaml agents: orchestrator: role: "ML Pipeline Orchestrator" goal: "Coordinate model retraining and deployment" tools: - mcp_server: "mlflow-registry" # MCP: acessa model registry - mcp_server: "s3-datasets" # MCP: acessa datasets a2a_capabilities: - "plan_execution" - "escalation" validator: role: "Model Quality Gate" goal: "Validate model performance against baselines" tools: - mcp_server: "mlflow-registry" - mcp_server: "evidently-monitoring" # MCP: drift detection a2a_capabilities: - "validation_report" - "retrain_request" deployer: role: "Model Deployment Manager" goal: "Safe progressive rollout with automatic rollback" tools: - mcp_server: "k8s-serving" # MCP: KServe/Seldon - mcp_server: "prometheus-metrics" a2a_capabilities: - "canary_status" - "rollback_trigger"O fluxo em pseudo-código: # orchestrator recebe trigger trigger = await orchestrator.receive_task(event)# monta plano dinâmico baseado no contexto plan = orchestrator.plan( model=trigger.model_id, reason=trigger.reason, # "scheduled" | "drift_detected" | "manual" last_deployment=await mlflow.get_latest(trigger.model_id) )# treina e envia para validação via A2A model_artifact = await orchestrator.execute_training(plan) validation = await validator.validate( # A2A call model=model_artifact, baseline=plan.baseline_metrics, required_segments=plan.critical_segments )if validation.status == "REJECTED": # validator pode pedir retreino com instruções específicas plan = orchestrator.replan(validation.feedback) # loop controlado pelo orchestrator, não por uma DAG elif validation.status == "APPROVED": deployment = await deployer.canary_deploy( # A2A call model=model_artifact, traffic_pct=10, monitor_minutes=30 )A diferença fundamental: a lógica de decisão vive nos agentes, não no grafo. Quando o validator rejeita um modelo, ele não apenas retorna False — ele retorna contexto ("accuracy no segmento enterprise caiu 4pp, dataset de treino tem 12% menos amostras desse segmento vs. mês passado"). O orchestrator usa esse contexto para replanejar. Trade-offs reais: quando NÃO migrar Seria desonesto vender isso como solução universal. Aqui estão os trade-offs que encontrei:Aspecto DAG tradicional Agentic MLOpsLatência de decisão Milissegundos (if/else) Segundos (LLM inference por decisão)Custo Compute do step Compute + tokens de LLM por agenteDebuggability Log linear, fácil de rastrear Traces distribuídos, precisa de observabilidade sériaDeterminismo 100% reproduzível Decisões do LLM podem variar entre runsComplexidade inicial Alta (DAG), mas conhecida Alta (agentes), e poucos dominamO custo de LLM inference em cada decisão é real. Em um pipeline que roda 50 vezes por dia, cada chamada ao orchestrator com contexto de 4K tokens custa. Fiz a conta para um cenário com 3 agentes, 8 chamadas LLM por run, usando Claude Sonnet: **$2.40/dia** vs. zero de compute decisório no Airflow. Para pipelines de alta frequência, isso escala. E o determinismo é a objeção mais séria. Se o Validation Agent aprova um modelo na segunda-feira e rejeita o mesmo modelo na terça com os mesmos dados, você tem um problema de auditoria. A mitigação que funciona: usar LLMs com temperature 0 para decisões binárias e logar o chain-of-thought completo como artefato de compliance. Quando faz sentido migrar Na minha experiência, Agentic MLOps compensa quando:Seu pipeline tem lógica de decisão complexa — múltiplos caminhos de retreino, rollback condicional, validação por segmento Você já tem MCP servers para sua infra (MLflow, K8s, monitoramento) — montar isso do zero é um projeto separado A frequência do pipeline é baixa/média — diário ou semanal, não a cada 5 minutos Você precisa de feedback loops que hoje são manuais — o Validation Agent substitui aquele Slack alert que um engenheiro olha (ou não) antes de aprovar o deploySe seu pipeline é treino → valida threshold → deploy sem ramificações, Airflow resolve. Não complique. O que vem pela frente O paper da InfoQ menciona Agent Registries — um catálogo onde agentes de MLOps publicam suas capabilities via A2A e podem ser compostos dinamicamente. Imagine um marketplace interno onde o time de ML publica um "Feature Quality Agent" e o time de infra publica um "Cost Optimization Agent", e o orchestrator compõe os dois no mesmo pipeline sem ninguém escrever glue code. Ainda está cedo. A maioria das empresas não tem nem MCP servers para a infra de ML, muito menos agentes A2A em produção. Mas a direção é clara: MLOps vai de orquestração imperativa para coordenação declarativa. De DAGs para equipes. Se você já tem MCP rodando e está pensando no próximo passo, o repo de referência da InfoQ é um bom ponto de partida. E se você ainda está no Airflow com 47 BranchPythonOperators aninhados — bom, pelo menos agora sabe que existe alternativa.

NVIDIA Physical AI Data Factory Blueprint: o repo open-source que muda como você gera dados de treinamento para robótica

A NVIDIA fez algo raro em 16 de março: anunciou que vai abrir no GitHub a pipeline completa de geração de dados sintéticos para Physical AI. Não é um paper. Não é um blog post com diagramas bonitos e zero código. É o blueprint inteiro — geração, augmentation, curadoria e avaliação de dados de treinamento para robôs, veículos autônomos e vision agents. O Cosmos Evaluator já está no GitHub. O repo completo está prometido para este mês. Se você trabalha com robótica, sim-to-real transfer ou qualquer coisa que precisa de dados de treinamento que não existem no mundo real, isso muda a equação. Aqui está o que você precisa saber antes de clonar. A arquitetura: quatro estágios, um pipeline O Data Factory Blueprint é uma pipeline de quatro estágios construída sobre os Cosmos foundation models. Cada estágio resolve um problema específico na cadeia de dados para Physical AI. Estágio 1 — Geração via Cosmos World Models. Os Cosmos models são world models: dados um prompt de cena (posição de objetos, iluminação, física do ambiente), eles geram sequências de vídeo sintético fisicamente plausíveis. Não estamos falando de renders estáticos. São sequências temporais com gravidade, colisões, deformações — o tipo de dado que um robô precisa para aprender a interagir com o mundo real. A NVIDIA treinou esses models em datasets massivos de vídeo real, e o output é bom o suficiente para substituir horas de captura em ambiente controlado. Na prática, o fluxo começa com uma descrição de cena no Omniverse: from cosmos_data_factory import SceneGeneratorscene = SceneGenerator( environment="warehouse", objects=["pallet", "box_cardboard", "forklift"], physics_engine="PhysX", camera_config="multi_view_4x" )# Gera 1000 sequências de 5 segundos cada dataset = scene.generate( num_sequences=1000, duration_sec=5, variations=["lighting", "object_pose", "texture"] )Cada sequência vem com ground truth automático: bounding boxes, segmentation masks, depth maps, poses 6DoF dos objetos. É o tipo de anotação que custaria centenas de horas de trabalho manual. Estágio 2 — Augmentation com domain randomization. Dados sintéticos puros sofrem de um problema conhecido: o sim-to-real gap. O modelo aprende features que existem na simulação mas não no mundo real (iluminação perfeita demais, texturas uniformes demais, ausência de sujeira). O blueprint ataca isso com domain randomization agressiva — variação sistemática de texturas, iluminação, ruído de câmera, poses de objetos e condições ambientais. O pipeline aplica augmentation em camadas: augmentation: texture_randomization: true lighting_variations: ["dawn", "noon", "overcast", "fluorescent"] camera_noise: gaussian_std: 0.02 motion_blur_prob: 0.3 object_pose_jitter: translation_cm: 2.0 rotation_deg: 15.0 background_randomization: trueA ideia é que se o modelo funciona com todas essas variações, ele vai funcionar no mundo real. Na minha experiência com sim-to-real, isso é 80% verdade — os 20% restantes você resolve com fine-tuning em dados reais limitados. Estágio 3 — Curadoria automatizada. Nem todo dado sintético é útil. Sequências onde objetos atravessam paredes, colisões fisicamente impossíveis, cenas com oclusão total — tudo isso é lixo de treinamento. O pipeline inclui um módulo de curadoria que filtra automaticamente sequências com anomalias físicas e balanceia a distribuição do dataset por cenário, iluminação e complexidade de cena. Estágio 4 — Avaliação com Cosmos Evaluator. Esse é o componente que já está no GitHub (github.com/NVIDIA/cosmos-evaluator). O Evaluator mede a qualidade dos dados gerados em três dimensões: fidelidade física (os objetos se comportam como deveriam?), diversidade (o dataset cobre variação suficiente?) e utilidade downstream (treinar com esses dados melhora performance em tarefas reais?). # Já disponível no GitHub git clone https://github.com/NVIDIA/cosmos-evaluator.git cd cosmos-evaluator pip install -e .# Avaliar um dataset gerado cosmos-eval --dataset ./my_synthetic_data \ --metrics physical_fidelity diversity downstream_utility \ --report ./eval_report.jsonO report gera scores por métrica e um breakdown por cena. Na documentação atual, physical fidelity acima de 0.85 e diversity acima de 0.70 são os thresholds recomendados antes de usar o dataset para treinamento. Quem já está usando — e para quê A NVIDIA não está lançando isso no vácuo. Quatro empresas já operam com versões internas do pipeline:FieldAI — dados sintéticos para navegação autônoma em ambientes não estruturados (canteiros de obra, áreas de desastre) Uber — geração de cenários de edge case para veículos autônomos. O tipo de situação que acontece uma vez a cada 100 mil km e que você não pode esperar capturar em dados reais Skild AI — treinamento de foundation models para controle robótico generalista. Com o valuation de US$14B e foco em robot brains, dados sintéticos em escala são a base da tese Teradyne — robótica industrial, com foco em manipulação de objetos variados em linhas de montagemO padrão é claro: empresas que precisam de volumes massivos de dados anotados para robótica e não podem (ou não querem) coletá-los exclusivamente no mundo real. Os trade-offs que a NVIDIA não vai destacar no keynote Vamos ao que importa: onde isso não funciona tão bem quanto o marketing sugere. Custo de GPU. Gerar dados sintéticos com Cosmos world models não é grátis. Cada sequência de 5 segundos em resolução 1080p exige ~4 minutos em uma A100. Para um dataset de 100 mil sequências, são ~6.700 horas de GPU. A US$1,50/hora na AWS, isso dá ~US$10K só em compute de geração. Augmentation e avaliação adicionam mais 20-30%. O custo total de um dataset robusto fica na faixa de US$12-15K. É mais barato que coleta real em muitos cenários, mas não é trivial. Sim-to-real gap não desaparece. Domain randomization ajuda, mas não resolve 100% do problema. Na minha experiência, modelos treinados exclusivamente em dados sintéticos perdem 15-25% de performance quando transferidos para o mundo real sem fine-tuning adicional. O blueprint trata dados sintéticos como complemento de dados reais, não substituto completo — e essa é a abordagem correta. Dependência do Omniverse. O estágio de geração roda sobre o NVIDIA Omniverse. É uma plataforma poderosa, mas é lock-in. Se amanhã você quiser migrar a geração para outra engine (Unity, Unreal, ou um renderer custom), o pipeline vai precisar de adaptação significativa nos estágios 1 e 2. Os estágios 3 e 4 são mais agnósticos. Qualidade vs quantidade. Existe uma tentação de gerar milhões de sequências e jogar tudo no treinamento. O paper do Cosmos Evaluator mostra que datasets curados de 50K sequências consistentemente superam datasets brutos de 500K. Mais dados não é melhor dados. Como começar a testar hoje O Cosmos Evaluator já está disponível. Para o resto do pipeline, a NVIDIA prometeu abril — o que significa que pode aparecer a qualquer momento. Enquanto o repo completo não sai, o caminho pragmático:Clone o Cosmos Evaluator e rode com um dataset existente para entender as métricas Instale o Omniverse (versão gratuita para desenvolvedores) e familiarize-se com a geração de cenas sintéticas via Replicator Monitore o repo github.com/NVIDIA/physical-ai-data-factory — a naming convention segue o padrão dos outros repos da NVIDIA# Setup básico do Evaluator git clone https://github.com/NVIDIA/cosmos-evaluator.git cd cosmos-evaluator python -m venv .venv && source .venv/bin/activate pip install -e ".[dev]"# Rodar com dataset de exemplo cosmos-eval --dataset examples/sample_warehouse \ --metrics all \ --output-format jsonVeredito O Physical AI Data Factory Blueprint é o tipo de release que importa mais do que parece no dia do anúncio. Não é um modelo novo com benchmark recorde. É infraestrutura — a parte chata e essencial que determina se Physical AI sai do demo e entra na produção. A decisão de abrir o código é estratégica: a NVIDIA quer que o ecossistema inteiro gere dados no formato Cosmos, treine no stack NVIDIA e rode em hardware NVIDIA. Open-source aqui é growth strategy, não altruísmo. Mas isso não diminui a utilidade. Se você precisa de dados de treinamento para robótica, o custo de gerar internamente caiu de "projeto de pesquisa de 6 meses" para "pipeline configurável em semanas". Clone o Evaluator. Teste as métricas com seus dados. E quando o repo completo aparecer neste mês, você já vai saber o que medir.

Unsloth agora treina modelos MoE 12x mais rápido com 35% menos VRAM — hands-on com o novo release

Semana passada eu precisava fazer fine-tuning de um modelo MoE para um projeto interno. Abri o HuggingFace Trainer, configurei tudo, lancei o job numa A100 40GB e fui dormir. Seis horas depois, o treinamento tinha terminado — e metade da minha cota de GPU tinha ido junto. Aí saiu o novo release do Unsloth. Mesmo modelo, mesma config, mesma GPU: 70 minutos. Não é typo. Setenta minutos. O repositório é github.com/unslothai/unsloth, com mais de 30 mil stars no GitHub. E esse release merece cada uma delas. O que mudou neste release O Unsloth já era a ferramenta go-to para fine-tuning eficiente de LLMs. A grande novidade são os kernels Triton otimizados especificamente para arquiteturas MoE (Mixture of Experts). Antes, o suporte a MoE existia, mas sem otimizações dedicadas — você usava os mesmos kernels de modelos densos e torcia para dar certo. Agora os números falam por si:Métrica HF Trainer (baseline) Unsloth (novo release) MelhoriaTempo de treino (A100 40GB) ~6h ~70min 12x mais rápidoUso de VRAM 38.2 GB 24.8 GB 35% menosContexto máximo 8K tokens 48K tokens 6x mais longoPerda de acurácia baseline baseline nenhumaEsse último ponto é o que importa. Não é um tradeoff velocidade-por-qualidade. Os kernels Triton reescrevem as operações de roteamento do MoE de um jeito que reduz materialização de tensores intermediários. Menos cópia de memória, menos overhead de kernel launch, mesma matemática. Modelos suportados no release: DeepSeek, GLM-4.7-Flash, Kimi-2.5, Llama 4, Mistral, Gemma 2, Qwen 2.5. Basicamente tudo que você vai querer usar em produção. Hands-on: fine-tuning de um Llama 4 8B Chega de slide. Vamos rodar. 1. Instalação pip install "unsloth[triton] @ git+https://github.com/unslothai/unsloth.git" pip install sglang # para deploy depoisSe você está numa instância com CUDA 12.x, o Triton já vem compatível. Em CUDA 11.8, precisa do triton-nightly. Não tente rodar sem Triton — os kernels MoE dependem dele. 2. Configuração do modelo from unsloth import FastLanguageModelmodel, tokenizer = FastLanguageModel.from_pretrained( model_name="meta-llama/Llama-4-Scout-8B", max_seq_length=32768, load_in_4bit=True, dtype=None, # auto-detect )model = FastLanguageModel.get_peft_model( model, r=16, target_modules=[ "q_proj", "k_proj", "v_proj", "o_proj", "gate_proj", "up_proj", "down_proj", ], lora_alpha=16, lora_dropout=0, bias="none", use_gradient_checkpointing="unsloth", )O use_gradient_checkpointing="unsloth" é o que ativa os kernels otimizados. Sem isso, você está rodando o path padrão do HuggingFace. 3. Dataset e treinamento from trl import SFTTrainer from transformers import TrainingArgumentstrainer = SFTTrainer( model=model, tokenizer=tokenizer, train_dataset=dataset, # seu dataset formatado dataset_text_field="text", max_seq_length=32768, args=TrainingArguments( per_device_train_batch_size=2, gradient_accumulation_steps=4, warmup_steps=10, num_train_epochs=3, learning_rate=2e-4, fp16=not torch.cuda.is_bf16_supported(), bf16=torch.cuda.is_bf16_supported(), output_dir="outputs", optim="adamw_8bit", ), )trainer.train()Na minha A100 40GB com um dataset de ~50K exemplos, esse treinamento rodou em 68 minutos. O pico de VRAM foi 24.3 GB — sobraram 16 GB que eu poderia usar para aumentar batch size ou contexto. 4. Salvando o modelo model.save_pretrained_merged( "llama4-8b-finetuned", tokenizer, save_method="merged_16bit", )Deploy com SGLang Uma coisa que eu gosto no ecossistema Unsloth é que eles pensaram no pipeline completo. Treinou? Deploy com SGLang. Sem ficar convertendo formato de modelo entre três ferramentas diferentes. python -m sglang.launch_server \ --model-path llama4-8b-finetuned \ --port 8000 \ --tp 1O SGLang roda inference otimizada com continuous batching e funciona como um drop-in replacement para a API da OpenAI. Seu código de aplicação não muda — é apontar a URL e pronto. Pipeline inteira open-source: Unsloth para treino, SGLang para serving. Sem vendor lock-in, sem licença enterprise obscura. Quanto custa na prática Porque no final das contas, é sempre sobre dinheiro.Setup Custo/hora (spot) Tempo de treino Custo totalA100 40GB + HF Trainer ~US$1.10/h 6h US$6.60A100 40GB + Unsloth ~US$1.10/h 70min US$1.28A10G 24GB + Unsloth (4bit) ~US$0.50/h ~2.5h US$1.25Leu direito: com Unsloth, dá para fazer fine-tuning de um modelo MoE de 8B numa A10G — uma GPU que custa metade de uma A100. O consumo de VRAM caiu o suficiente para caber em 24 GB com 4-bit quantization. Para quem roda fine-tuning frequente, a diferença anualizada é brutal. Um job semanal sai de US$343/ano com HF Trainer para US$65/ano com Unsloth na A10G. Mesmo dinheiro, cinco vezes mais experimentos. Limitações — porque nem tudo são flores Eu já testei bastante para listar o que ainda não funciona bem:Multi-GPU: o suporte a tensor parallelism no treinamento ainda é experimental. Para modelos maiores que 70B, você vai precisar de DeepSpeed ou FSDP por enquanto. Modelos não-suportados: se seu modelo não está na lista de arquiteturas suportadas, os kernels Triton não ativam e você cai no path lento sem aviso claro. Verifique a compatibility matrix no repo. Quantização assimétrica: AWQ e GPTQ ainda não são suportados nos kernels MoE. É QLoRA com bitsandbytes ou full precision. Documentação: melhorou muito, mas ainda tem gaps. O notebook de exemplo para MoE não cobre todos os edge cases. Já abri duas issues no repo.Nada disso é um deal-breaker, mas é bom saber antes de começar. Veredito O Unsloth com kernels Triton para MoE é, sem exagero, a maior melhoria prática em tooling de fine-tuning que eu vi nos últimos seis meses. 12x mais rápido, 35% menos VRAM, sem perda de acurácia — e tudo open-source. Se você está fazendo fine-tuning de qualquer modelo MoE — DeepSeek, Llama 4, Qwen — não tem motivo para não usar. A instalação leva dois minutos, a API é compatível com HuggingFace Trainer, e os resultados são mensuráveis no primeiro job. Repo: github.com/unslothai/unsloth. Vai lá, roda, mede. Depois me conta.