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

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.

Microsoft Agent 365 chega em 1º de maio: o control plane que faltava para governar agentes em escala

Microsoft Agent 365 chega em 1º de maio: o control plane que faltava para governar agentes em escala

A Microsoft confirmou o general availability do Agent 365 para 1º de maio de 2026. Pricing: US$ 15 por usuário por mês. A proposta é ser a primeira plataforma enterprise de observabilidade e governança para agentes de IA multi-vendor — não apenas Copilot, mas agentes Salesforce, frameworks open-source e qualquer sistema que opere sob o protocolo de interoperabilidade da plataforma. Para o CIO que está tentando governar agentes de múltiplos vendors simultaneamente, o Agent 365 se posiciona como o missing piece. A pergunta que o board precisa responder no próximo mês é se essa peça resolve o problema de fato — ou se adiciona mais uma camada de complexidade a um stack que já está ingovernável. O problema que o Agent 365 endereça O cenário é conhecido por qualquer organização que avançou na adoção de IA agêntica: agentes de diferentes vendors operam em diferentes sistemas, com diferentes modelos de permissão, diferentes logs e diferentes níveis de observabilidade. O resultado é fragmentação. CIOs recebem dashboards parciais de cada vendor, mas nenhum oferece visão consolidada de todos os agentes em operação. Essa fragmentação gera três riscos concretos: Shadow agents. Equipes deployam agentes sem passar pelo processo formal de aprovação. Sem um registro centralizado multi-vendor, a organização não sabe quantos agentes operam, onde estão e o que fazem. A pesquisa da Cisco de março de 2026 mostrou que 53% das empresas não conseguem detectar IA não autorizada. Quando se trata de agentes que agem — e não apenas respondem —, o risco se multiplica. Audit trail inexistente. Cada vendor tem seu formato de log. Correlacionar ações de um agente Salesforce com ações de um agente Copilot num mesmo processo de negócio exige integração manual. Na prática, ninguém faz. Quando o regulador pede evidência de supervisão, a resposta é silêncio. Permissões inconsistentes. Um agente pode ter acesso restrito no ecossistema Microsoft e acesso amplo no Salesforce. Sem uma camada unificada de access control, o princípio de menor privilégio é aplicado por vendor — não por agente. O resultado é um modelo de segurança com furos estruturais. O que o Agent 365 entrega Segundo o que a Microsoft publicou no Tech Community e o que analistas do NY Report confirmaram, a plataforma oferece quatro capacidades centrais: Registry de agentes. Inventário centralizado de todos os agentes em operação na organização — independente do vendor. Cada agente recebe uma identidade única, com metadados de função, owner de negócio, sistemas acessados e classificação de risco. É o inventário que o Gartner vem pedindo e que a maioria das organizações não conseguiu construir internamente. Access control unificado. Políticas de permissão aplicadas na camada do Agent 365, não na camada de cada vendor individual. Isso permite implementar menor privilégio de forma consistente: o agente tem as mesmas restrições independentemente de qual sistema está acessando. Suporte a RBAC e políticas condicionais baseadas em contexto. Audit trail consolidado. Log unificado da cadeia de decisões e ações de todos os agentes registrados. Formato padronizado, correlação entre agentes de diferentes vendors, retenção configurável e exportação para SIEMs existentes. Para compliance — EU AI Act, LGPD, ISO 42001 — esse é o componente mais relevante. Interoperabilidade. Conectores nativos para agentes Copilot, Salesforce AgentForce, e um SDK aberto para frameworks open-source como LangGraph, CrewAI e Agents SDK da OpenAI. A promessa é que qualquer agente que implemente o protocolo de interoperabilidade pode ser registrado e governado pela plataforma. O que falta avaliar — e onde mora o risco A recomendação aqui é direta: o Agent 365 resolve um problema real, mas a avaliação precisa ir além do marketing deck. Lock-in. Uma plataforma de governança da Microsoft que governa agentes de outros vendors cria uma dependência significativa. Se o Agent 365 se torna o control plane da organização, trocar de plataforma de governança no futuro exige migrar registry, políticas, audit trails e integrações. O custo de saída é alto. CIOs precisam avaliar se estão dispostos a aceitar esse trade-off. Profundidade da interoperabilidade. Conectores nativos para Copilot e Salesforce são esperados. A questão é a qualidade da integração com frameworks open-source e agentes customizados. Um SDK aberto é uma promessa — a prova está na cobertura real de funcionalidades que o conector oferece. Registro e audit trail superficiais para agentes não-Microsoft transformam a plataforma num Copilot governance tool que tolera outros agentes, não num control plane genuinamente multi-vendor. Pricing em escala. US$ 15 por usuário por mês parece acessível. Mas a base de cálculo importa: são os usuários que interagem com agentes, os usuários cujos dados são processados por agentes, ou todos os usuários do tenant? Para uma organização de 10 mil colaboradores, a diferença entre essas interpretações pode ser de US$ 150 mil a US$ 1,8 milhão por ano. O CFO precisa dessa clareza antes do commitment. O contexto para organizações brasileiras Empresas brasileiras que operam com múltiplos vendors de IA enfrentam o mesmo problema de fragmentação — com o agravante de que a LGPD já exige explicabilidade de decisões automatizadas e o PL 2338 vai formalizar obrigações adicionais de supervisão e inventário. O Agent 365 pode ser relevante como acelerador de compliance para organizações que não têm capacidade interna de construir uma camada de governança multi-vendor. Mas o pricing em dólar precisa ser avaliado no contexto de margens brasileiras. A US$ 15 por usuário, uma operação de 5 mil pessoas está olhando para US$ 75 mil por mês — mais de R$ 400 mil ao câmbio atual. É investimento que exige business case robusto. A alternativa — construir internamente com ferramentas open-source — é viável para organizações com maturidade técnica, mas subestimam o custo operacional de manter essa camada atualizada com as mudanças de cada vendor. Não existe opção barata. Existe opção com trade-offs explícitos. O que fazer nos próximos 30 dias O GA é em 1º de maio. Falta um mês. A recomendação para CIOs e CAIOs é usar esse intervalo para três ações concretas:Inventariar agentes em operação. Antes de avaliar uma plataforma de governança, a organização precisa saber o que governa. Quantos agentes, de quais vendors, acessando quais sistemas, com quais permissões. Se esse inventário não existe, o Agent 365 não resolve o problema — organiza o caos.Avaliar o modelo de pricing. Solicitar à Microsoft a definição exata da base de usuários para billing. Rodar cenários de custo para 12 e 36 meses. Comparar com o custo estimado de construir internamente ou de usar alternativas emergentes.Levar a pauta ao board. Governança de agentes multi-vendor não é decisão de TI — é decisão de risco corporativo. O board precisa entender que a organização opera agentes de múltiplos vendors sem visão consolidada e que existe uma janela de oportunidade para corrigir isso antes que o regulador pergunte.O Agent 365 pode ser a resposta certa para muitas organizações. Mas nenhuma plataforma substitui a decisão executiva de tratar governança de agentes como prioridade estratégica. A ferramenta é meio. A decisão é do board.

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

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.

Q1 2026 fecha com US$300B em venture capital — e IA engoliu 81% do bolo

Q1 2026 fecha com US$300B em venture capital — e IA engoliu 81% do bolo

Trezentos bilhões de dólares. Esse é o número que o Crunchbase publicou hoje para o venture capital global no primeiro trimestre de 2026. Recorde absoluto — não de um mês, mas de um trimestre inteiro. Para referência: o Q1 de 2025 somou US$91 bilhões. O crescimento é de 230% em doze meses. O número impressiona. A composição, preocupa. IA absorveu 81% do capital total — US$243 bilhões dos US$300 bilhões. E quatro empresas levaram 64% de tudo que foi investido no planeta: OpenAI, Anthropic, xAI e Waymo. Juntas, US$192 bilhões. O recorde é de concentração, não de distribuição. A anatomia de um trimestre distorcido Vamos reconstruir. Janeiro abriu com a xAI levantando US$20 bilhões em Series E e a Humans& fechando um seed de US$480 milhões. Fevereiro foi o mês que quebrou todos os registros: US$189 bilhões investidos, com a megarrodada de US$110 bilhões da OpenAI e os US$30 bilhões da Anthropic. Março completou o quadro com mais de uma dúzia de rodadas acima de US$100 milhões, agora focadas em infraestrutura, segurança e operações de agentes. Mês a mês, a narrativa mudou — de modelos foundation para trust layer e operações. Mas a concentração de capital, não. As dez maiores rodadas do trimestre representaram mais de 75% dos US$300 bilhões. É uma lei de potência que seria extrema até para o venture capital, um mercado que já opera com distribuição absurdamente desigual. Os dados da Crunchbase mostram que o número de deals globais em Q1 2026 cresceu apenas 12% em relação a Q1 2025. O volume de capital cresceu 230%. Isso significa que o ticket médio explodiu — puxado por megarrodadas que distorcem toda a curva. 81% para IA: o que sobra para o resto Dos US$300 bilhões, US$243 bilhões foram para startups classificadas como IA. Os outros US$57 bilhões se dividiram entre fintech, climate tech, biotech, SaaS e tudo mais. É dinheiro — mas num contexto onde IA engoliu oito em cada dez dólares, categorias inteiras de startups estão competindo por restos. Climate tech, que tinha momentum real em 2024, sentiu o impacto. O funding para startups de energia limpa e descarbonização caiu 18% YoY no Q1 2026, segundo o TechCrunch. Não porque a tese enfraqueceu — os problemas climáticos não desapareceram — mas porque o capital tem custo de oportunidade. Se o LP pode colocar dinheiro num fundo focado em IA e ver retornos de 5x em dois anos, o incentivo para alocar em climate tech com horizonte de dez anos diminui. O mesmo padrão aparece em biotech e fintech. Não há crise — há reorientação gravitacional. O capital não fugiu dessas categorias. Ele foi atraído para um buraco negro chamado IA generativa. Quatro empresas, 64% do capital global Esse é o dado que deveria tirar o sono de qualquer fundador. OpenAI (US$110B), Anthropic (US$30B), xAI (US$20B) e Waymo (US$16B) concentraram, sozinhas, mais da metade de todo o venture capital investido no mundo nos primeiros três meses do ano. Somando as rodadas secundárias e extensões de capital que não aparecem nos headlines, o número sobe para 64%. Não é que o ecossistema parou de receber dinheiro. É que a escala mudou de forma irreversível. Quando uma rodada única de US$110 bilhões existe no mesmo mercado que seeds de US$2 milhões, as duas coisas são venture capital apenas no nome. Na prática, são mercados completamente diferentes operando sob o mesmo rótulo. O capital que foi para OpenAI e Anthropic financia treinamento de modelos com orçamentos de bilhões de dólares. O capital que vai para uma startup early-stage em São Paulo financia seis meses de runway. Chamar os dois de "venture capital" é como comparar o orçamento da NASA com o de um clube de foguetes de universidade. O que isso significa para o early-stage Aqui está o paradoxo: o dinheiro de seed e Series A em termos absolutos cresceu. A Crunchbase reporta que deals de seed somaram US$11,2 bilhões no Q1, contra US$9,8 bilhões no Q1 de 2025 — alta de 14%. Mas como proporção do total, o early-stage caiu de 10,8% para 3,7%. O bolo cresceu tanto que a fatia ficou invisível. Para fundadores, isso cria um ambiente estranho. Levantar um seed de US$3-5 milhões não ficou mais difícil em termos absolutos. Mas a atenção dos LPs, a cobertura de mídia e a dinâmica de mercado estão dominadas por megarrodadas. Quando a Sequoia aloca US$2 bilhões numa única empresa, o incentivo para o partner dedicar tempo a um seed de US$4 milhões diminui. Não por maldade — por economia de tempo. O efeito prático é que fundos especializados em early-stage estão ganhando importância relativa. Os generalistas foram sugados pela gravidade dos megarounds. Quem ainda olha para pre-seed e seed são os fundos que nasceram para isso — e, no Brasil, são poucos. E o Brasil nesse cenário? O ecossistema brasileiro de startups de IA tem 975 empresas ativas e o BNDES planejando um fundo de até R$1 bilhão. São números reais. Mas colocados contra US$300 bilhões globais, o Brasil é um erro de arredondamento. O ticket médio de seed no Brasil gira em torno de US$1,5 a US$2 milhões. Nos EUA, o seed médio para startups de IA passou de US$6 milhões no Q1, com outliers como a Humans& distorcendo a média para cima. A competição é assimétrica por definição — não porque fundadores brasileiros são piores, mas porque operam com 10x menos capital num mercado onde capital virou barreira de entrada. Três caminhos se destacam para startups brasileiras nesse contexto. Primeiro: vertical AI. Construir agentes e automação para setores onde o conhecimento local é vantagem — agro, tributário, saúde pública, logística. Nenhum frontier lab de San Francisco vai treinar um modelo que entende a legislação trabalhista brasileira melhor do que quem vive nela. Segundo: eficiência como estratégia. Quando seu competidor tem US$100 bilhões, gastar menos para resolver o mesmo problema não é limitação — é moat. Terceiro: captar fora. O capital brasileiro é insuficiente para competir em IA. Fundadores que conseguem acessar capital americano ou europeu multiplicam suas chances por uma ordem de magnitude. Onde a concentração leva O Q1 de 2026 confirma uma tendência que não é nova, mas que atingiu um ponto de inflexão. O venture capital global se bifurcou em dois mercados que mal se comunicam. De um lado, megarrodadas para frontier labs e infraestrutura de IA — capital medido em dezenas de bilhões, investidores que incluem fundos soberanos e Big Tech. Do outro, o ecossistema de startups "normais" — seeds, Series A, fundadores com pitch deck e doze meses de runway. O risco não é que o dinheiro acabe. O risco é que a concentração se torne auto-reforçante. Modelos maiores exigem mais capital. Mais capital gera modelos maiores. O ciclo cria uma barreira de entrada que transforma a camada foundation em oligopólio. Para quem constrói na camada de aplicação, isso pode ser oportunidade — modelos melhores e mais baratos como plataforma. Para quem queria competir na camada foundation, o jogo acabou. Trezentos bilhões de dólares em um trimestre. O número é histórico. Mas a pergunta que importa não é quanto entrou — é para onde foi. E a resposta, por enquanto, é que foi para o topo.

Salesforce Agentforce bate US$800M de ARR — agentes de IA já são linha de receita, não promessa

Salesforce Agentforce bate US$800M de ARR — agentes de IA já são linha de receita, não promessa

A Salesforce acabou de divulgar o resultado fiscal do Q4 2026 e enterrou, com um número, qualquer dúvida sobre a viabilidade comercial de agentes de IA. O Agentforce — a plataforma de agentes autônomos lançada em outubro de 2024 — atingiu US$800 milhões de receita recorrente anual. Crescimento de 169% year-over-year. São 29.000 deals fechados em apenas 15 meses de operação comercial. US$800 milhões. Não é pipeline. Não é projeção de analista. É ARR reportado em earnings call para investidores. Agentes de IA acabaram de se tornar uma linha de receita de quase um bilhão de dólares por ano dentro de uma única empresa. O poder da base instalada O que explica a velocidade? Distribuição. A Salesforce tem 150.000 clientes enterprise que já rodam CRM, Service Cloud, Marketing Cloud e uma constelação de produtos integrados. Quando o Agentforce chega, não precisa convencer o CIO a comprar um conceito novo. Precisa mostrar que o agente resolve um ticket, qualifica um lead ou automatiza um workflow dentro de um sistema que o cliente já usa, já paga e já depende. É a diferença brutal entre vender agentes para quem nunca usou IA e adicionar agentes ao stack de quem já está dentro do ecossistema. A Salesforce não vendeu 29.000 deals do zero — converteu 29.000 clientes existentes em compradores de uma nova camada de valor. Para startups, esse é o dado mais incômodo do earnings call. Não é que o Agentforce seja tecnicamente superior a qualquer concorrente. É que ele chega com CRM, dados do cliente, integrações e billing já resolvidos. A barreira de entrada para o cliente é mínima. Para a startup que compete pelo mesmo orçamento, a barreira é brutal. O mapa de quem está monetizando de verdade Vale colocar o número da Salesforce em contexto com os outros players que cobri aqui nos últimos meses. Salesforce Agentforce: US$800M de ARR. O incumbente. Crescimento por distribuição e base instalada. Modelo SaaS tradicional — cobra por uso dentro da plataforma existente. Não precisou inventar um mercado; adicionou uma feature monstruosa a um produto que já domina enterprise. Sierra: US$150M de ARR. A startup pura de agentes de atendimento, fundada por Bret Taylor (ex-co-CEO da própria Salesforce, aliás) e Clay Bavor. Cresceu de US$26M para US$150M em pouco mais de um ano. Cobra por resultado — por interação resolvida, não por seat. Provou que agentes verticais geram receita recorrente sem base instalada prévia. Harvey: US$11B de valuation. A referência em agentes jurídicos, com 100 mil advogados usando o produto em 1.300 organizações. Rodada de US$200M em março. Não divulga ARR, mas o valuation e a velocidade de adoção sugerem receita crescente e significativa. Rox: US$1.2B de valuation. Agentes autônomos de vendas B2B que substituem SDRs. Avaliação alcançada em março de 2026. Modelo de precificação por resultado — cobra por lead qualificado e reunião agendada. O padrão é claro: quem monetiza agentes de IA não é quem tem o demo mais impressionante. É quem tem distribuição (Salesforce), vertical defensável (Harvey, Sierra) ou modelo de negócio que alinha incentivos (Sierra, Rox). Demo sem distribuição é roadshow. Distribuição sem produto é vaporware. A interseção dos dois é receita. O que US$800M significa para o mercado de agentes Três implicações que importam. Primeiro, budget enterprise para agentes existe e é grande. Quando o CFO de uma Fortune 500 vê que a Salesforce — a empresa na qual ele já confia — gera resultados mensuráveis com agentes, a conversa de "deveríamos experimentar IA?" vira "quanto a mais vamos gastar com IA?". A Salesforce está normalizando a compra de agentes na mesma velocidade que normalizou a compra de CRM em nuvem duas décadas atrás. Isso abre mercado para todo mundo — inclusive para startups que oferecem algo que a Salesforce não cobre. Segundo, o modelo de precificação vai ser campo de batalha. A Salesforce cobra no modelo SaaS tradicional — add-on ao contrato existente. Sierra e Rox cobram por resultado. Quando os dois modelos competem pelo mesmo orçamento, o cliente vai comparar: "pago X fixo à Salesforce pelo agente dentro do meu CRM, ou pago Y variável à Sierra/Rox pelo mesmo trabalho feito?". Essa tensão vai definir margens e modelos de negócio pelos próximos três anos. Terceiro, a janela para startups de agentes horizontais está fechando. Um agente genérico de atendimento, vendas ou suporte que tenta competir head-to-head com o Agentforce dentro de empresas que já usam Salesforce tem uma probabilidade baixíssima de ganhar. A oportunidade real está nos verticais que a Salesforce não cobre — jurídico (Harvey), saúde, compliance, engenharia — e nos mercados onde a Salesforce não domina. O que startups brasileiras precisam entender Aqui é onde eu conecto com o ecossistema que acompanho de perto. O mercado enterprise brasileiro gasta com Salesforce — mas nem de longe na mesma proporção que os EUA. A penetração de CRM enterprise no Brasil ainda tem gaps significativos, especialmente em mid-market e em setores como agro, saúde e governo. Esses gaps são oportunidade. Uma startup brasileira de agentes que tenta competir com o Agentforce dentro de clientes Salesforce está morta antes de começar. Mas uma startup que constrói agentes para verticais brasileiros — atendimento em português com integração a TOTVS, agentes de cobrança que entendem o ciclo de inadimplência local, agentes de compliance que navegam LGPD e regulação setorial — essa não compete com a Salesforce. Compete por um orçamento diferente, num mercado que a Salesforce não atende bem. O dado de US$800M de ARR tem dois lados para founders brasileiros. O lado ruim: o incumbente está monetizando rápido e vai sugar uma fatia enorme do budget global de agentes enterprise. O lado bom: US$800M prova que o mercado existe. Quando a Salesforce valida a categoria, o cliente brasileiro que não é cliente Salesforce também começa a perguntar "e eu, preciso de agentes?". Quem tiver a resposta certa para o mercado local captura essa demanda. Agentes saíram do slide para o P&L Há seis meses, quando escrevi sobre o vale da morte dos agentes — 78% pilotam, 14% escalam — o cenário era de promessa e frustração. O dado da Salesforce não elimina o vale da morte. Ainda tem muita empresa emperrada em piloto. Mas mostra que quem cruza o vale encontra receita real do outro lado. US$800 milhões de ARR em 15 meses. 29.000 deals. 169% de crescimento. Agentes de IA deixaram de ser uma linha no slide de estratégia e viraram uma linha no P&L. A pergunta para quem constrói no espaço não é mais "agentes funcionam?" — é "como eu capturo minha fatia antes que os incumbentes fechem a porta?". A porta ainda está aberta. Mas está fechando rápido.

Proxy season 2026: boards que não demonstram AI literacy arriscam withhold de acionistas

Proxy season 2026: boards que não demonstram AI literacy arriscam withhold de acionistas

A proxy season 2026 está em andamento. Assembleias de acionistas acontecem entre abril e maio, e este ano trouxeram uma exigência que a maioria dos conselhos de administração não tinha no radar doze meses atrás: demonstrar, de forma documentada, que o board tem competência para supervisionar inteligência artificial. Não é recomendação genérica. Proxy advisors como ISS e Glass Lewis passaram a avaliar AI literacy como critério para recomendações de voto. Boards que não documentam frameworks de AI oversight nos proxy statements estão recebendo withhold recommendations — recomendações para que acionistas se abstenham de votar na reeleição de diretores específicos. O mecanismo é simples: se o acionista entende que o conselheiro não tem competência para supervisionar um risco material, ele retira o voto de confiança. Para quem lidera, isso deixou de ser pauta de governança para virar risco individual de reputação e responsabilidade. O que mudou em 2026 Até 2025, a supervisão de IA pelos boards era tratada como boa prática. Publicações como Corporate Board Member e firmas como WilmerHale já recomendavam que conselhos desenvolvessem competências em IA, mas o mercado tratava isso como aspiracional. Quem tivesse uma política genérica de tecnologia já marcava o checkbox. Em 2026, três movimentos convergiram para mudar o cenário:Proxy advisors atualizaram seus frameworks de avaliação. ISS e Glass Lewis passaram a incluir perguntas específicas sobre AI oversight nas análises de proxy statements. Não basta mais dizer que o board "monitora riscos tecnológicos". É preciso detalhar: qual comitê é responsável por IA, que tipo de treinamento os diretores receberam, com que frequência o board revisa métricas de risco e oportunidade de IA.Investidores institucionais passaram a cobrar disclosure. Fundos com mandatos ESG e de governança já incluem IA nos engagement letters enviados a empresas do portfólio. A lógica é direta: IA é risco material. Se é risco material, precisa de supervisão documentada. Se não tem supervisão documentada, é falha de governança.A jurisprudência Caremark ganhou uma nova dimensão. No direito societário americano, a doutrina Caremark estabelece que diretores têm o dever fiduciário de implementar sistemas de monitoramento para riscos materiais conhecidos. Com IA sendo adotada em escala — e os riscos de viés, alucinação, vazamento de dados e compliance já amplamente documentados — a ausência de um framework de supervisão de IA pode configurar breach of fiduciary duty. Não é teoria. Escritórios como WilmerHale já alertam que claims tipo Caremark contra diretores individuais são uma questão de quando, não de se.O que um withhold recommendation significa na prática Um withhold não é voto contra. Tecnicamente, é abstenção. Mas o efeito prático é devastador. Quando um proxy advisor emite withhold recommendation para um diretor, isso sinaliza ao mercado que aquele conselheiro não atende aos critérios mínimos de competência ou diligência para a função. Mesmo que o diretor seja reeleito — e na maioria dos casos é, porque a base acionária nem sempre segue o advisor — o dano reputacional é concreto. Os efeitos cascateiam:Sinal público de fragilidade de governança. Analistas e a imprensa especializada monitoram withhold rates. Um percentual acima de 20-30% de abstenções contra um diretor específico vira manchete. Pressão interna sobre o chair do board. Após um withhold significativo, o chair é pressionado a responder — o que frequentemente resulta em rotação de diretores ou criação apressada de comitês. Precedente para ações judiciais. Um withhold recommendation documentado por falta de AI oversight pode ser usado como evidência em uma ação Caremark. O argumento é claro: o mercado sinalizou que havia deficiência, e o board não agiu.O gap que os acionistas estão explorando Dados recentes mostram que 70% dos líderes do Fortune 500 reportam ter estruturas de governança de IA. Apenas 14% dizem estar de fato prontos para deploy de IA em escala. Esse gap entre política formal e prontidão operacional — que já foi discutido neste blog — agora tem um mecanismo de enforcement: o voto do acionista. Acionistas sofisticados conseguem ler um proxy statement e distinguir entre uma empresa que tem governança de IA real e uma que tem um documento genérico aprovado às pressas. Os indicadores que proxy advisors estão avaliando incluem:Existência de comitê designado para supervisão de IA (não apenas "tecnologia" genérica) Frequência de reporting de IA ao board (trimestral como mínimo) Competências documentadas de diretores em IA — formação, experiência operacional, certificações Framework de risk assessment específico para IA, separado do risk assessment de TI geral Métricas de uso de IA em produção e seus indicadores de risco (alucinação rate, bias audits, incident reports)A recomendação aqui é direta: se o proxy statement da sua empresa não endereça esses pontos, o conselho está exposto. O que fazer antes de maio A proxy season tem prazo. Assembleias acontecem. Proxy statements já foram ou estão sendo publicados. Para a maioria das empresas, o ciclo 2026 já está em andamento. Mas há ações que podem ser executadas agora e refletidas em comunicações suplementares ou no ciclo 2027: Para o ciclo atual (abril/maio 2026):Mapear se o proxy statement endereça AI oversight de forma específica. Se não, preparar talking points para o chair responder perguntas de acionistas na assembleia. Identificar quais diretores têm competências documentáveis em IA. Se nenhum tem, isso precisa ser endereçado publicamente com um plano de capacitação. Revisar se o comitê de auditoria ou de riscos tem mandato explícito para supervisão de IA.Para o ciclo 2027 (preparação começa agora):Implementar um AI oversight framework documentado — alinhado ao NIST AI RMF ou à ISO 42001. Incluir métricas de IA nos risk reports trimestrais ao board. Considerar a adição de um diretor com expertise operacional em IA. Não acadêmica — operacional. Alguém que já colocou IA em produção em escala. Documentar treinamentos de AI literacy para o board completo, com carga horária e conteúdo.O ângulo brasileiro Para empresas brasileiras listadas na B3 — ou com ADRs em bolsas americanas — a exposição é dupla. O código de governança da B3 já recomenda que conselhos monitorem riscos tecnológicos materiais. O PL 2338 (Marco Legal de IA), em análise final na Câmara, pode criar obrigações adicionais de supervisão e accountability para decisões algorítmicas. Conselhos que já têm o hábito de tratar IA como tema de board estão em vantagem. Os que tratam IA como "assunto de TI" estão acumulando risco de governança em duas jurisdições simultaneamente. O prazo é real A proxy season não espera. Acionistas estão votando. Proxy advisors já publicaram suas recomendações para os ciclos de abril e maio. Se o board da sua empresa não tem um framework documentado de AI oversight, a janela de preparação para 2026 já fechou. A de 2027 abriu agora. A pergunta que todo conselheiro deveria fazer a si mesmo neste momento: se um acionista perguntar o que o board fez para supervisionar IA no último ano, existe uma resposta documentada, específica e verificável? Se não existe, o risco não é hipotético. É o próximo ciclo de proxy.

HQQ — Half-Quadratic Quantization: quantize um 70B em 5 minutos sem calibration data

HQQ — Half-Quadratic Quantization: quantize um 70B em 5 minutos sem calibration data

O repo dropbox/hqq não tem a contagem de stars do Ollama ou do Unsloth, mas resolve um problema que todo mundo que roda LLM local enfrenta: quantização rápida sem precisar de dataset de calibração. Quantizar um Llama-2-70B com GPTQ leva horas. Com HQQ, leva menos de 5 minutos. E a qualidade é competitiva. Já testei em alguns cenários e o trade-off é real: você troca um pouco de perplexidade por uma velocidade de quantização absurda e zero dependência de dados externos. Para quem itera rápido — testando modelos novos toda semana — isso muda o workflow. O que é HQQ e como funciona HQQ significa Half-Quadratic Quantization. A ideia central vem de otimização convexa: em vez de resolver o problema de quantização de uma vez (minimizar erro de reconstrução dos pesos), o HQQ divide em dois subproblemas alternados — um que otimiza os pesos quantizados e outro que otimiza um termo auxiliar. Cada subproblema tem solução fechada, então converge rápido sem precisar de gradiente. Na prática, isso significa:Sem calibration data. GPTQ e AWQ precisam de um dataset (geralmente WikiText ou C4) para calibrar a quantização. HQQ trabalha apenas com os pesos do modelo. Isso elimina um passo que pode introduzir bias dependendo do dataset escolhido. 50x mais rápido que GPTQ. O Llama-2-70B quantiza em ~5 minutos vs horas com GPTQ. Numa A100 40GB, testei um Qwen 3.5 72B em 4-bit e levou 7 minutos. Suporta 8, 4, 3, 2 e 1-bit. A maioria dos métodos foca em 4-bit. HQQ vai até 1-bit (com perda de qualidade significativa, claro).O repo oficial está em github.com/dropbox/hqq, mantido pela Mobius Labs (adquirida pelo Dropbox). Já está integrado ao Hugging Face Transformers nativamente. Benchmark: HQQ vs GPTQ vs AWQ vs GGUF Números de perplexidade no WikiText-2 (menor = melhor). Modelo base: Llama-2-70B.Método 4-bit PPL 3-bit PPL 2-bit PPL Tempo de quantizaçãoFP16 (baseline) 3.32 — — —GPTQ 3.47 4.12 7.89 ~4hAWQ 3.44 4.08 — ~2hHQQ 3.52 4.21 5.86 ~5minGGUF (Q4_K_M) 3.49 — — ~15minEm 4-bit, HQQ fica ~0.05-0.08 de perplexidade atrás de GPTQ/AWQ. É mensurável mas irrelevante na prática para a maioria dos use cases. A diferença real é o tempo: 5 minutos vs horas. Em 2-bit, HQQ brilha. GPTQ degrada severamente (7.89), enquanto HQQ mantém 5.86. E o dado mais impressionante: um Llama-2-70B quantizado em 2-bit via HQQ tem perplexidade menor que um Llama-2-13B em FP16 — usando memória comparável. Como instalar e usar Instalação # Versão estável pip install hqq# Com backend torchao (recomendado para inference rápida) pip install hqq[torchao]# Com backend Marlin (kernels otimizados para 4-bit) pip install hqq[marlin]# Bleeding edge pip install git+https://github.com/dropbox/hqq.gitQuantização via Hugging Face Transformers A forma mais simples — já integrado no HF: from transformers import AutoModelForCausalLM, HqqConfigquant_config = HqqConfig( nbits=4, # bits por peso (8, 4, 3, 2, 1) group_size=64, # tamanho do grupo de quantização axis=1, # eixo de quantização )model = AutoModelForCausalLM.from_pretrained( "Qwen/Qwen2.5-72B-Instruct", quantization_config=quant_config, device_map="auto", )Pronto. O modelo carrega já quantizado. Sem dataset, sem etapa separada de calibração. Para inference mais rápida Depois de quantizar, troque o backend para kernels fusionados: # torchao int4 — ~158 tok/s no Llama3-8B numa 4090 from hqq.utils.patching import prepare_for_inference prepare_for_inference(model, backend="torchao")# Marlin — até ~200 tok/s na mesma config prepare_for_inference(model, backend="marlin")Na minha 4090, um Llama 4 8B quantizado em 4-bit com HQQ + backend torchao roda a 155 tokens/segundo. Com Marlin, sobe para 192. Comparável ao que se consegue com GGUF no llama.cpp. Quando usar HQQ vs alternativasCenário Melhor escolha Por quêIteração rápida, testando modelos novos HQQ 5min vs horas. Sem dataset.Deploy em produção, máxima qualidade 4-bit AWQ ou GPTQ ~0.05 PPL melhor em 4-bitRodar local no llama.cpp/Ollama GGUF Ecossistema maduro, CPU+GPUQuantização 2-bit agressiva HQQ Melhor quality/compression nesse rangeFine-tuning com LoRA pós-quantização HQQ Compatível com PEFT out-of-the-boxModelos não-LLM (vision, audio) HQQ Model-agnostic, funciona em qualquer arquiteturaO ponto fraco do HQQ: em 4-bit puro, GPTQ e AWQ ainda ganham em perplexidade se você tem tempo e dados de calibração. Se você vai deployar um modelo em produção e ele vai rodar meses sem mudar, vale investir as horas extras do GPTQ. Se você está experimentando, comparando 3 modelos diferentes na mesma tarde, HQQ é imbatível. O ângulo custo: por que quantização importa no Brasil Uma A100 40GB na AWS São Paulo custa ~US$3.50/hora. Em real, passa de R$20/hora. Um Qwen 3.5 72B em FP16 precisa de pelo menos 2x A100 80GB (~US$8/hora). Quantizado em 4-bit com HQQ, cabe numa única A100 40GB. Conta rápida: se você roda inference 8h/dia, 22 dias/mês:FP16 (2x A100 80GB): ~US$1.408/mês HQQ 4-bit (1x A100 40GB): ~US$616/mêsSão ~US$800/mês de diferença. Em real, R$4.400. Por modelo. Por mês. Quantização não é otimização — é survival skill. Limitações reais Perplexidade em 4-bit. HQQ perde ~0.05-0.08 para GPTQ/AWQ. Para a maioria dos use cases isso não importa, mas se você está servindo um modelo para milhões de queries e cada fração de qualidade conta, a diferença existe. Ecossistema de inference. llama.cpp e Ollama usam GGUF. vLLM suporta GPTQ e AWQ nativamente. HQQ funciona melhor no ecossistema Hugging Face / PyTorch. Se seu stack de serving é vLLM, a integração com HQQ é possível mas não tão polida. 1-bit e 2-bit. HQQ suporta, mas a qualidade em 1-bit é ruim para uso prático. 2-bit é usável para modelos grandes (70B+), mas não para modelos menores onde cada bit conta mais. Veredito HQQ resolve um problema real de forma elegante: quantização rápida, sem dados, com qualidade competitiva. Não é o melhor em tudo — GPTQ/AWQ ganham em 4-bit puro, GGUF tem ecossistema maior. Mas para quem itera rápido, testa modelos toda semana e precisa de resultados em minutos, é a melhor opção disponível. O repo: github.com/dropbox/hqq. Docs no HF: huggingface.co/docs/transformers/quantization/hqq. Instala com pip install hqq, quantiza em 5 minutos, mede no seu use case. Se for melhor que o que você usa hoje, migra. Se não for, pelo menos você gastou 5 minutos testando, não 5 horas.

DeepSeek V4: o modelo trilionário que ninguém consegue lançar

DeepSeek V4: o modelo trilionário que ninguém consegue lançar

O DeepSeek V4 deveria ter sido o modelo que provava que a China consegue competir no frontier da IA sem chips americanos. Um trilhão de parâmetros. Arquitetura MoE com 37 bilhões ativos por token. Multimodal — texto, imagem, vídeo. Otimizado para rodar em silício chinês da Huawei e Cambricon. O lançamento estava previsto para o início de março, antes das "Two Sessions" — o maior evento político anual da China, onde IA seria vitrine de soberania tecnológica. Março acabou. O V4 não saiu. O que se sabe sobre o modelo O DeepSeek V4 é ambicioso em todos os eixos. Um trilhão de parâmetros totais com arquitetura Mixture of Experts, ativando apenas 37 bilhões por token na inferência. Na teoria, isso combina a capacidade de um modelo massivo com o custo computacional de um modelo médio. O V3, com 671 bilhões de parâmetros e 37B ativos, já havia demonstrado que essa abordagem funciona. O V4 escala o conceito. A grande novidade técnica é a Engram memory architecture — um sistema de memória persistente que, segundo números vazados, atinge 97% no benchmark Needle-in-a-Haystack com janela de 1 milhão de tokens. Se confirmado, isso colocaria o V4 no mesmo patamar do Claude Opus 4.6 e do Gemini Ultra em capacidade de contexto longo. O modelo também é multimodal de nascença: processa texto, imagem e vídeo no mesmo pipeline. Não é uma extensão bolada depois — a multimodalidade foi projetada desde a arquitetura base. Isso importa porque multimodalidade nativa tende a gerar resultados mais coerentes do que adaptações pós-treinamento. O calendário que não se cumpriu A DeepSeek planejava lançar o V4 completo antes das Two Sessions, que começaram em 5 de março. A lógica era política e comercial: mostrar ao governo chinês e ao mundo que um laboratório chinês consegue entregar modelos frontier treinados em hardware chinês, mesmo sob as restrições de exportação americanas. Não aconteceu. Em 9 de março, uma versão chamada V4 Lite apareceu brevemente no site da DeepSeek. Não houve anúncio formal. O modelo ficou acessível por algumas horas e saiu do ar. Analistas que conseguiram testar reportaram que era uma versão reduzida — provavelmente o modelo destilado, não o modelo completo. Não houve comunicação oficial. Desde então, silêncio. Nenhum paper, nenhum blog post, nenhum anúncio de data. O site da DeepSeek continua oferecendo o V3 como modelo principal. Comunidades no Weibo e no X especulam, mas ninguém tem informação concreta. O que provavelmente está travando Treinar um modelo de 1T parâmetros é difícil. Treinar em chips que não são NVIDIA é mais difícil. Os indícios apontam para dois gargalos principais. Hardware chinês ainda não é NVIDIA. O DeepSeek V4 foi otimizado para chips Huawei Ascend 910B e Cambricon MLU370. São os melhores aceleradores de IA fabricados na China, mas os benchmarks públicos mostram que o Ascend 910B entrega cerca de 60-70% da performance de uma NVIDIA H100 em tarefas de treinamento de modelos grandes. Isso significa que o mesmo treinamento leva mais tempo, consome mais energia e tem mais chance de falha em clusters grandes. Treinar um modelo de 1T parâmetros exige milhares de aceleradores trabalhando em sincronia por semanas. Quanto menos eficiente o chip, maior a chance de instabilidades no treinamento — spikes de loss, checkpoints corrompidos, comunicação entre nós que não escala. O DeepSeek já demonstrou engenhosidade com o V3, usando paralelismo e otimizações criativas para compensar as limitações de hardware. Mas com o V4 o desafio é de outra escala. Multimodalidade nativa é mais cara do que se imagina. Processar texto, imagem e vídeo no mesmo modelo, desde o pré-treinamento, multiplica a quantidade de dados necessários, a complexidade do pipeline e o número de hiperparâmetros que precisam ser ajustados. O GPT-4 da OpenAI também levou mais tempo que o esperado por causa da multimodalidade. E a OpenAI tinha H100s à vontade. A dimensão geopolítica Os adiamentos do V4 não são apenas uma história técnica. São geopolítica em código. Os Estados Unidos restringiram a exportação de chips avançados de IA para a China em outubro de 2022, com atualizações em 2023 e 2024. O objetivo declarado é impedir que a China desenvolva modelos frontier que possam ser usados em aplicações militares e de vigilância. A resposta chinesa foi acelerar o desenvolvimento de silício doméstico. O DeepSeek V4 é, nesse contexto, um teste de viabilidade. Se a DeepSeek consegue entregar um modelo competitivo com o GPT-5 usando apenas hardware chinês, as restrições americanas perdem parte da eficácia. Se não consegue — ou se consegue com atrasos significativos — a dependência de silício americano fica exposta. Cada semana de atraso reforça o argumento de que as restrições de exportação estão funcionando. Não é coincidência que Washington esteja acompanhando de perto. E o Brasil? O DeepSeek V3 se tornou um dos modelos mais usados por desenvolvedores brasileiros. O motivo é simples: custo. A API do V3 cobra uma fração do que cobram OpenAI e Anthropic. Para startups e devs independentes que operam em real, a diferença é brutal — especialmente quando o dólar está acima de R$ 5,50. Um V4 funcional ampliaria isso. Multimodalidade a preço de DeepSeek seria um divisor para aplicações brasileiras que hoje não conseguem justificar o custo de usar GPT-4 ou Claude para processar imagens e vídeos. Healthtechs, edtechs, agritechs — tem demanda real por multimodalidade barata no Brasil. Mas enquanto o V4 não sai, a dependência do V3 continua. E o V3, por melhor que seja, não tem multimodalidade, tem janela de contexto menor e está ficando para trás na comparação com os lançamentos recentes de Anthropic e OpenAI. O que os adiamentos dizem Há uma narrativa confortável no mundo da IA: a de que o progresso é inevitável e linear. Modelos ficam maiores, melhores e mais baratos a cada trimestre. A realidade é mais complicada. O DeepSeek V4 mostra que modelos frontier continuam sendo projetos de engenharia de altíssima complexidade. Não basta ter a arquitetura certa no paper. É preciso hardware confiável, dados de qualidade em escala massiva, infraestrutura de treinamento estável e — talvez o mais subestimado — tempo. A DeepSeek vai lançar o V4 eventualmente. A empresa tem talento, capital e motivação política de sobra. Mas o fato de que até eles estão atrasados é um lembrete: na fronteira da IA, promessas são fáceis. Entregas são difíceis. E quando a entrega depende de hardware que um governo estrangeiro está ativamente tentando negar, são mais difíceis ainda.

Hark: o fundador da Figure AI aposta US$100M do próprio bolso em 'interface para AGI'

Hark: o fundador da Figure AI aposta US$100M do próprio bolso em 'interface para AGI'

Brett Adcock tem um padrão. Funda empresas ambiciosas, levanta capital agressivamente e aposta em teses que soam impossíveis até provarem que não são. Fez isso com a Vettery (recrutamento, vendida à Adecco), fez com a Archer Aviation (eVTOL, abriu capital via SPAC) e faz com a Figure AI, que construiu robôs humanoides e levantou mais de US$1.6 bilhão em dois anos. Agora, a nova aposta: Hark. A startup saiu de oito meses em stealth com uma tese que chama atenção pela ambição. Hark quer construir a "interface dedicada para AGI" — um dispositivo de hardware combinado com IA personalizada que, segundo Adcock, será o paradigma de interação com inteligência artificial que vai substituir chat e browser. E o detalhe que define o tom: os US$100 milhões iniciais saíram do bolso dele. O que "interface para AGI" significa na prática A tese da Hark parte de uma premissa que, isoladamente, faz sentido: se inteligência artificial geral eventualmente existir, interagir com ela via caixa de texto num navegador é subótimo. Um sistema genuinamente inteligente precisaria de uma interface que capture contexto visual, auditivo e ambiental em tempo real — não apenas texto digitado. Até aí, o argumento é racional. O problema começa quando tentamos traduzir isso em produto. Adcock não divulgou especificações do hardware, data de lançamento ou demonstrações funcionais. O que temos são declarações de visão: hardware proprietário, IA personalizada que aprende o comportamento do usuário, interação multimodal que vai além de tela e teclado. É uma pitch deck ambulante — convincente em PowerPoint, indefinida em engenharia. E aqui mora a tensão. A Hark está vendendo o futuro (AGI precisa de interface nova) enquanto o presente (chat funciona surpreendentemente bem) ainda não esgotou suas possibilidades. ChatGPT, Claude, Gemini — todos evoluíram de caixa de texto para interfaces multimodais com voz, visão e execução de código. A pergunta que a Hark precisa responder é: o que um hardware dedicado faz que um smartphone com app de IA não faz? O cemitério de hardware + IA É impossível analisar a Hark sem olhar para os cadáveres recentes. O Humane AI Pin foi lançado em 2024 como o "dispositivo pós-smartphone". Custava US$699 mais assinatura mensal de US$24. Projetava informações na palma da mão com um laser. As reviews foram devastadoras: lento, impreciso, bateria de 2 horas. A Humane tentou se vender, não encontrou comprador no valor que queria e virou case de estudo de como não lançar hardware de IA. O Rabbit R1 custava US$199 e prometia um "assistente universal" que operava apps por você via um modelo proprietário (LAM — Large Action Model). Na prática, fazia menos que os apps que prometia substituir. As vendas iniciais foram altas por curiosidade, mas o dispositivo acabou em gavetas. Ambos compartilham o mesmo erro: assumiram que IA precisa de um novo form factor antes que a IA em si estivesse boa o suficiente para justificar o form factor. Quando o software ainda está evoluindo a cada trimestre, fixar uma interface de hardware é apostar que você sabe como vai ser a interação com IA daqui a 3 anos. Ninguém sabe. O contra-argumento: por que Adcock pode estar certo Existe um cenário onde a Hark faz sentido. E ele depende de timing. Se AGI (ou algo próximo) chegar nos próximos 3-5 anos — como Anthropic, OpenAI e DeepMind parecem acreditar —, a interação com essa inteligência vai demandar mais do que uma janela de chat. Um sistema que vê o que você vê, ouve o que você ouve, entende seu contexto físico e responde em tempo real precisa de sensores, processamento local e uma interface pensada para fluxo contínuo, não para prompts discretos. Adcock pode estar construindo para esse momento. E o fato de usar US$100 milhões do próprio dinheiro — não de VCs — muda o cálculo. Ele não precisa mostrar métricas de tração em 18 meses. Não tem board cobrando pivots trimestrais. Tem runway para errar, iterar e esperar o momento certo. É uma vantagem estrutural que Humane e Rabbit não tinham. A Figure AI, sua outra empresa, também dá pistas. Adcock construiu robôs humanoides que operam em fábricas — hardware complexo que integra IA em tempo real. Ele sabe fazer hardware funcionar com modelos de IA. A questão é se essa competência em robótica se traduz para dispositivos pessoais, que são um mercado completamente diferente. O que falta na tese Três perguntas que a Hark ainda não respondeu: Distribuição. Hardware pessoal de IA compete com o smartphone. Não em funcionalidade — em hábito. Oito bilhões de pessoas já têm um dispositivo no bolso que faz chamadas, tira fotos e roda apps de IA. Convencer alguém a carregar um segundo dispositivo exige que ele faça algo que o smartphone categoricamente não pode fazer. Modelo de negócio. Hardware é margens baixas, supply chain complexa e ciclos de produto longos. A Apple leva 3 anos para desenvolver um iPhone. A Humane levou 4 anos e falhou. US$100 milhões cobrem prototipagem e primeiras iterações, mas se o produto precisar de escala de manufatura, o capital acaba rápido. Timing de AGI. A tese inteira depende de AGI chegar num horizonte onde o hardware da Hark ainda seja relevante. Se AGI demora 10 anos, a primeira geração do produto vai parecer tão datada quanto um Palm Pilot. O ângulo para o ecossistema Independentemente de a Hark ter sucesso, a movimentação de Adcock sinaliza algo relevante: founders com capital e track record estão começando a apostar que a era do "chat como interface de IA" tem prazo de validade. É uma minoria ainda, mas é uma minoria com dinheiro. Para o ecossistema brasileiro, o aprendizado é indireto mas importante. A maioria das startups de IA no Brasil está construindo sobre a camada de software: agentes, automações, integrações via API. Se a interface mudar, o que está por baixo (os agentes, os modelos, os pipelines de dados) continua valendo. Mas quem apostou toda a experiência do usuário em chat pode precisar repensar. A Hark é uma aposta de US$100 milhões numa pergunta que ainda não tem resposta: como vamos interagir com IA quando ela for inteligente de verdade? Brett Adcock acha que sabe. O cemitério de hardware de IA sugere cautela. E o mercado, como sempre, vai decidir com a carteira.

Apple adiou a Siri com Gemini — de novo. O que está travando?

Apple adiou a Siri com Gemini — de novo. O que está travando?

A Apple prometeu que o Siri ficaria inteligente. Prometeu em janeiro, quando anunciou o deal de $1 bilhão com o Google para integrar o Gemini 1.2T ao assistente via Private Cloud Compute. Prometeu em fevereiro, quando executivos garantiram que o iOS 26.4 traria as primeiras features. Prometeu de novo em março, quando o prazo virou iOS 26.5. Ontem, 30 de março, o iOS 26.5 beta saiu para desenvolvedores. Sem Gemini. Sem nada. Agora o novo prazo é iOS 27, previsto para ser apresentado na WWDC em junho. Terceiro adiamento em três meses. A pergunta não é mais "quando chega". É se chega. O que foi prometido Em janeiro de 2026, durante a CES, a Apple confirmou o que já era rumor havia meses: o Siri seria reformulado com o Gemini do Google. Não era um upgrade cosmético. O plano envolvia um modelo de 1.2 trilhão de parâmetros rodando via Private Cloud Compute — a infraestrutura de nuvem segura da Apple, onde os dados do usuário seriam processados sem sair do ecossistema. A ideia era simples e ambiciosa. O Siri deixaria de ser um atalho glorificado para comandos de voz e passaria a entender contexto, manter conversas longas, integrar com apps de terceiros de forma profunda e — finalmente — competir com o Google Assistant e o ChatGPT em capacidade real. O deal de $1 bilhão com o Google cobriria licenciamento do modelo, acesso à API e suporte para otimização do Gemini em hardware Apple. A promessa inicial era março de 2026, com o iOS 26.4. Três meses, três adiamentos Março chegou. O iOS 26.4 saiu com melhorias no Apple Intelligence — melhor sumarização de e-mails, ajustes no Image Playground — mas nada de Gemini no Siri. A Apple não comentou publicamente. Fontes próximas ao projeto disseram que a integração com o Private Cloud Compute estava mais complexa que o esperado. O prazo foi empurrado para o iOS 26.5. Desenvolvedores e analistas aceitaram. Integrações desse porte levam tempo. Faz sentido. Mas o iOS 26.5 beta, disponibilizado ontem para desenvolvedores, não traz nenhuma feature de Gemini. Nem parcial. Nem em flag escondida. A 9to5Mac vasculhou o código da build e não encontrou referências ativas à integração. O MacRumors confirmou: tudo foi empurrado para a WWDC e o iOS 27, previsto para setembro na versão final. Três adiamentos em três meses. O padrão é preocupante. O que provavelmente está travando A Apple não é transparente sobre motivos de atraso, mas os indícios apontam para três problemas: Privacidade e controle de dados. O Private Cloud Compute é o trunfo de privacidade da Apple. Rodar um modelo de 1.2T parâmetros nessa infraestrutura sem que dados de usuários vazem para o Google é um problema de engenharia não trivial. A Apple precisa garantir que o Gemini processa e descarta — sem reter, sem treinar, sem logar. Isso exige camadas de isolamento que provavelmente não existiam na versão original do PCC. Latência. Um modelo desse tamanho, rodando em nuvem, precisa responder em tempo real para que o Siri não pareça mais lento que o assistente de voz que ele está substituindo. Inferência de modelos trilionários com latência aceitável para interação por voz é um desafio que até o Google ainda está otimizando nos próprios dispositivos. Controle de qualidade. A Apple tem histórico de atrasar features até que funcionem de forma aceitável. O problema é que "aceitável" para a Apple é alto — e o Siri com Gemini precisa funcionar em dezenas de idiomas, incluindo português brasileiro. Alucinações, respostas inconsistentes ou perda de contexto seriam devastadoras para a marca. Nenhum desses problemas é surpresa. Todos eram previsíveis em janeiro. O que surpreende é que a Apple tenha se comprometido com prazos que aparentemente não podia cumprir. Apple Intelligence virou vaporware? Vaporware é duro. Mas o termo começa a caber. O Apple Intelligence foi anunciado na WWDC de 2024. Quase dois anos depois, as features entregues são incrementais — sumarização de texto, geração de emoji, reescrita de mensagens. Funcionalidades que o Google e a Microsoft já oferecem há mais de um ano. O Siri com Gemini era para ser o salto de qualidade. A feature que finalmente justificaria o "Intelligence" no nome. Enquanto isso, o Google roda o Gemini nativamente em Pixels e dispositivos Samsung. A Microsoft integra o Copilot no Windows, Office e Edge. O ChatGPT está em praticamente todo lugar. A Apple, que controla o hardware mais premium do mercado, está ficando para trás na camada de software que mais importa para o usuário. E o Brasil? Esse adiamento importa especialmente para o mercado brasileiro. O iPhone tem uma base instalada estimada em mais de 40 milhões de dispositivos no Brasil. É o smartphone aspiracional. E seus donos estão vendo usuários de Android acessar IA generativa no dispositivo enquanto o Siri continua respondendo "aqui está o que encontrei na web". Tem um agravante. O Apple Intelligence, mesmo nas features já lançadas, ainda não funciona em português brasileiro. A sumarização, a reescrita, o Image Playground — tudo em inglês. A promessa de suporte ao português foi feita para "2026", sem data específica. Com os adiamentos do Gemini, é razoável duvidar desse prazo também. Para desenvolvedores brasileiros que constroem apps para iOS, a mensagem é clara: não conte com APIs de IA da Apple a curto prazo. Quem precisa de IA no app continua dependendo de OpenAI, Anthropic ou Google diretamente. O que esperar A WWDC em junho será o momento da verdade. Se a Apple apresentar o Siri com Gemini funcionando — ao vivo, em tempo real, com qualidade — os adiamentos viram "a Apple levou o tempo necessário para acertar". Se houver mais um "coming later this year", a narrativa muda de atraso para incapacidade. O deal de $1 bilhão com o Google não vai simplesmente evaporar. Há dinheiro demais envolvido. Mas dinheiro não resolve problemas de engenharia sozinho. E a Apple, que construiu sua reputação em entregar quando promete, está acumulando um déficit de credibilidade em IA que cada adiamento aumenta. A única coisa certa é que, em 31 de março de 2026, o Siri continua sendo o Siri. E isso, por si só, já é a maior crítica possível.