[IA na veIA nº 39] De Jedi solitário para conselho dos magos distribuídos

IA na veIA é uma iniciativa que explica os avanços da inteligência artificial com bom humor e analogias divertidas vindas direto do universo Geek. Aqui, conceitos complexos ganham vida através de comparações com filmes, séries, games e HQs, tornando a tecnologia mais próxima e muito mais divertida para todos.

A missão é democratizar o conhecimento sobre inteligência artificial, aproximando a comunidade científica do público leigo sem aquele “tecniquês” que dá sono. Ao usar referências de sagas épicas, super-heróis ou mundos de fantasia, transformamos pesquisas e inovações em histórias que qualquer fã de cultura pop entende e curte.

Essa abordagem cria uma ponte entre especialistas e curiosos, incentivando debates sobre o impacto ético, social e econômico da IA de forma leve, mas consciente. O resultado é uma conversa mais inclusiva, onde qualquer pessoa pode entender e participar da construção do nosso futuro tecnológico.

Se você é fã de IA e também vibra com referências Geek, o IA na veIA é o seu portal para explorar ciência com uma boa dose de risadas e imaginação.

Vamos revisar o paper a seguir:

• Matrix: Peer-to-Peer Multi-Agent Synthetic Data Generation Framework
• Link do paper

---

Quem é Celso Sousa?

Celso Sousa é especialista e palestrante de inteligência artificial (IA), com doutorado em IA pela USP. Além disso, ele possui mais de 15 anos de experiência no mercado de IA para negócios.

Celso participou da gestão e/ou desenvolvimento de diversos projetos de IA nos setores financeiro e agronegócio. Alguns dos projetos de inteligência artificial mais relevantes na carreira dele são:

• previsão de produtividade de fazendas;
• reconhecimento visual de nematóides;
• visão computacional para monitoramento de rebanhos por drones;
• identificação de públicos vulneráveis;
• sistema de gerenciamento de pastejo rotacionado;
• identificação de irregularidades em notas fiscais de serviço.

Celso ministrou vários treinamentos e mentorias sobre inteligência artificial nos últimos anos. Ainda mais, ele foi Cientista Chefe na Secretaria das Finanças de Fortaleza-CE na auditoria fiscal.

O foco do Celso é desenvolver soluções de IA para empresas de todos os portes e segmentos. Entretanto, a prioridade é criar soluções de IA de baixo custo para empresas de pequeno e médio porte.

Celso iniciou a sua carreira ao abrir uma consultoria de inteligência artificial em 2009. Portanto, ele adquiriu muita experiência prática de como gerar resultados expressivos para as empresas usando IA.

A pesquisa científica do Celso é sobre classificação em grafos para alavancagem de negócios com marketing analytics. Além disso, ele publicou artigos científicos em diversas conferências internacionais de renome em 4 continentes.

Hoje ele aplica sua experiência na IA para ajudar os empresários a aumentarem os seus lucros. Ainda mais, ele implementa automações com agentes de IA para que os empresários tenham mais liberdade.

Essas automações podem ser aplicadas em diversos setores, como marketing, vendas, recursos humanos, tecnologia, financeiro, atendimento, etc.

Fale com o especialista e palestrante de inteligência artificial Celso Sousa nas redes sociais:

• Instagram: https://www.instagram.com/celsosousaia
• LinkedIn: https://www.linkedin.com/in/celso-sousa/

---

Visão geral do paper

Quando você olha para a forma como treinamos LLMs hoje, parece uma raid mal organizada em World of Warcraft. Todo mundo sabe que precisa de mais dados, mas quase ninguém pensa direito em como gerar esses dados de forma escalável, segura e menos burra. Grattafiori et al já mostraram que modelos de ponta estão ficando cada vez mais dependentes de dados sintéticos para fugir do lamaçal de datasets sujos e sensíveis.

Abdin et al lembram que dados humanos custam caro e carregam riscos de privacidade, tipo carregar item lendário com maldição embutida e só perceber quando já está equipado. Betker et al discutem como a simples qualidade das anotações muda completamente o teto do modelo, como se você trocasse a arma branca de nível 5 por uma épica nível 200. Bai et al mostram que pipelines multi-agente viraram padrão para gerar trajetórias ricas de ferramentas e raciocínio, mas com workflows cheios de ifs, loops e orquestração frágil.

Copet et al empilham agentes para engenharia de software automática, mas ainda presos em arquiteturas super específicas, quase como um deck de Magic todo montado em torno de uma única carta. Wu et al propõem frameworks genéricos de agentes, mas voltados mais para chatbots e demos bonitinhas do que para pipelines industriais de bilhões de tokens.

LangChain vira LangGraph, e você monta grafos cheios de estados, só que o runtime continua bem mais próximo de um tabuleiro de RPG com mestre central do que de um MMO realmente distribuído. CrewAI tenta vender colaboração entre agentes, mas por baixo dos panos o controle ainda é concentrado demais para escalar sem começar a engasgar.

Hendrycks et al e Wang et al já mostraram que benchmarks de raciocínio estão ficando cada vez mais cruéis com os modelos, exigindo cadeias de pensamento longas, uso de ferramentas e memória de contexto gigantesca. Jimenez et al criam ambientes com issues reais de GitHub, forçando os modelos a navegar em sistemas complexos.

Shi et al defendem geração automática de tarefas agenticas, mas o custo de rodar esses pipelines em escala ainda é proibitivo para muita gente. Mitra et al apostam em frameworks de ensino generativo, só que quanto mais sofisticado o fluxo, mais ele se parece com um raid leader sobrecarregado, controlando tudo sozinho.

No meio disso, a indústria olha para clusters inteiros de GPUs e usa como se fosse um PC gamer velho rodando LoL no mínimo. A limitação não está só no modelo, mas na forma como orquestramos agentes, tarefas, filas e serviços.

É bizarro que a parte mais “burra” da pipeline seja justamente a que deveria se comportar como um cérebro distribuído. Se não resolvermos essa camada de coordenação, vamos continuar treinando Jedi em academia com infraestrutura de Stormtrooper.

---

De pipeline engessado a raid descentralizada

Wang et al entram exatamente nesse caos e perguntam por que diabos ainda dependemos de um grande orquestrador central para pipelines multi-agente de dados sintéticos. A proposta da galera é Matrix, um framework onde controle e dados viram mensagens serializadas que saltam entre agentes como se fossem quests passando de NPC em NPC. A sacada é simples e brutal: os agentes são stateless, a “mente” da tarefa fica dentro de um objeto orquestrador que viaja pela rede.

Isso mata o papel do “chefe” central que organiza milhares de workflows assíncronos e vira gargalo assim que você escala. Em vez de um mestre de RPG controlando tudo, você tem uma guilda peer-to-peer, cada agente consumindo mensagens, aplicando sua lógica, atualizando estado e chutando a bola para o próximo. É quase como pegar o modelo mental de microserviços e aplicar diretamente à geração de dados agentica.

A importância disso para a comunidade é bem direta. Se você quer gerar bilhões de tokens de diálogos colaborativos, trajetórias de ferramenta, raciocínio longo ou extração web, precisa de algo que escale sem reescrever tudo a cada caso. Wang et al constroem Matrix em cima de Ray, vLLM, SGLang e containers via Apptainer, com foco explícito em throughput, paralelismo e configurabilidade. A promessa é transformar geração de dados sintéticos de um ritual artesanal para algo mais próximo de um servidor de MMO tunado para aguentar evento global.

---

Sem Matrix, seu cluster vira Stormtrooper mirando o próprio pé

Imagina tentar gerar dados agenticos em larga escala com um único orquestrador central segurando milhares de tasks em asyncio. Isso é basicamente rodar uma batalha de Naruto onde todos os jutsus têm que passar por um único Hokage para autorização. Sem algo como Matrix, qualquer aumento de escala vira fila infinita, tempo ocioso de GPU e o clássico gráfico de throughput que sobe bonito e depois estaciona.

Sem um runtime P2P, frameworks como Coral, Tau2-agent ou pipelines de raciocínio web precisam ser replicados, adaptados, embrulhados em sistemas externos tipo Airflow ou Kubernetes Jobs. Cada camada adicionada é mais uma peça de lego instável, pronta para cair quando você tenta rodar 10 mil workflows ao mesmo tempo. E quando você finalmente gera o dataset, descobre que desperdiçou metade do cluster esperando por batches lentos, como se todo o time de LoL ficasse parado base esperando o top farmar.

O resultado prático é simples. Menos dados, mais custo, menos experimentação, mais medo de rodar ablações sérias, e uma barreira enorme para labs médios entrarem no jogo de dados sintéticos agenticos. A comunidade fica presa em poucos players com infra absurda, enquanto o resto roda scripts improvisados que lembram mods bugados de Skyrim.

---

A engenharia da guilda: arquitetura de agentes tipo RPG

Orquestrador como grimório mágico de quest log

O núcleo de Matrix é o orquestrador, um objeto que carrega toda a história da tarefa. Ele guarda histórico de conversa, resultados intermediários, flags de controle, qual é o próximo agente e quando a quest acaba. Em vez de cada agente guardar estado próprio, o orquestrador funciona como grimório que passa de mago em mago na guilda, sempre atualizado com o último feitiço lançado.

Essa escolha muda a topologia da pipeline. Não existe mais “coordenador divino”, só um fluxo contínuo de mensagens que determinam quem age em seguida. O orquestrador pode ser sequencial, cíclico, hierárquico, tanto faz, desde que implemente a lógica para decidir o próximo passo. É como se o sistema inteiro fosse um enorme sistema de cartas, e o orquestrador fosse a mecânica de turno.

Agentes como classes de personagem, stateless e escaláveis

Cada agente em Matrix é um Ray Actor com event loop assíncrono, responsável por consumir orquestradores de uma fila local. O agente roda sua função process, atualiza o estado recebido e reenvia para o próximo papel indicado pelo orquestrador. Não tem apego, não tem sessão, não tem “minha memória”, só funções puras rodando em cima de mensagens.

Isso lembra construção de classes de personagem em RPG, onde cada papel tem habilidades específicas, mas a ficha do jogador é o que viaja. Se você precisa de mais “healers” ou “tanks”, só sobe mais instâncias daquele agente. E como o LLM e os containers são serviços externos, o agente em si é leve, quase como um bot de Discord orquestrando poderes de entidades bem maiores.

Serviços distribuídos como summons de alto custo

As partes pesadas ficam fora dos agentes. LLMs são expostos via Ray Serve com gRPC, usando vLLM, SGLang ou FastGen para maximizar throughput de tokens. Containers para ambientes complexos, como execução de código ou ferramentas de sistema, rodam via Apptainer, com mapeamento de IDs para reuso de instâncias.

Na prática, é como se os agentes fossem conjuradores de summons gigantes tipo Susanoo ou Hulk, chamados sob demanda. O truque é manter um pool de serviços e só passar identificadores, evitando transformar cada chamada em handshake ritualístico cheio de overhead HTTP. Isso permite que o cluster se comporte mais como uma arena de Dragon Ball com teleporte entre lutadores do que como fila de atendimento de operadora.

Escalonamento fino: paralelismo de linha, não de batch

A grande heresia em relação aos motores clássicos tipo Spark ou Ray Data é abandonar o batch como unidade principal. Matrix opera no nível da linha, cada orquestrador representando um item independente do dataset. Assim que uma linha termina uma etapa, ela já segue para a próxima, sem esperar as linhas irmãs.

Isso resolve o clássico problema de “bolha” de batch, onde uma tarefa lenta segura todo mundo. É como abandonar partida ranqueada onde todo time precisa terminar ao mesmo tempo e adotar matchmaking contínuo estilo FPS moderno, substituindo jogadores que já morreram por novos instantaneamente. O resultado é mais GPU ocupada e menos cluster bocejando.

---

Experimentos em modo sandbox de MMO distribuído

A parte mais divertida do trabalho é ver Matrix brigando com sistemas existentes em cenários reais. Nada de benchmark bonitinho com meia dúzia de exemplos; aqui o negócio é bilhões de tokens, milhões de documentos e milhares de workflows simultâneos. Os autores escolhem três arenas: diálogos colaborativos em Coral, curadoria de raciocínio em NaturalReasoning e trajetórias de suporte ao cliente em Tau2-bench.

Coral: duelo de Jedi em modo espelho

No cenário de Collaborative Reasoner, Ni et al já tinham mostrado que colocar dois agentes para discutir e chegar a acordo gera dados de raciocínio bem mais ricos. A implementação original usa um grande orquestrador central que controla milhares de tarefas assíncronas ao mesmo tempo. Em termos geek, é um Yoda tentando coordenar centenas de padawans ao vivo.

Com Matrix, o pipeline de Coral vira um conjunto de agentes P2P, com teacher, student, extrator de resposta, matcher e sink todos operando como nós independentes. Na prática, o orquestrador da tarefa pula de agente em agente até que a conversa converge ou atinge limite de rodadas. O mesmo modelo Llama-3.1-8B-Instruct é usado em ambas as implementações, então a comparação é de runtime, não de poder da Força.

Escala de GPUs: do modo solo ao raid de 248 GPUs

Os experimentos com Coral variam o número de nós A100, sempre com 8 GPUs por nó e 50 tasks por GPU. Isso dá 400 tasks concorrentes com um nó e até 12.400 tasks concorrentes com 31 nós. A versão original de Coral começa bem, mas rapidamente entra em modo “latência de servidor de Tibia em 2005”, com throughput subindo e depois achatando.

Com Matrix, o throughput escala quase linearmente com o número de GPUs. Em 31 nós com 248 GPUs, a pipeline P2P gera cerca de 2 bilhões de tokens em pouco mais de 4 horas, enquanto o Coral original fica em algo perto de 617 milhões de tokens em aproximadamente 9 horas. Isso dá cerca de 129.800 tokens por segundo para Matrix contra 18.900 para o baseline, um buff de 6,8× digno de patch quebrado de ARAM.

Qualidade: sem vender buff trocando por nerf escondido

A parte crítica é que esse ganho de throughput não vem acompanhado de queda de qualidade. A métrica de Coral é “agreement correctness”, basicamente quão frequentemente os diálogos auto-gerados acertam a resposta final. Matrix atinge valor em torno de 0,478, enquanto o Coral original fica perto de 0,473, o que é praticamente empate dentro de variação estatística normal.

É como trocar o motor do carro para algo muito mais potente e ainda terminar com o mesmo controle de tração. Não adianta gerar 2 bilhões de tokens se metade for lixo ao estilo fanfic ruim de crossover Naruto x Marvel. Aqui, a estrutura P2P mantém a mesma lógica de geração, só tira o garrote do pescoço da orquestração.

NaturalReasoning: mineração de quest rara em oceano de web trash

Yuan et al criaram NaturalReasoning como um mar de questões difíceis derivadas de textos da web. A pipeline original já era pesadinha, mas a ideia com Matrix é usá-lo como minerador automático em cima de até 25 milhões de documentos da DCLM. O fluxo tem três agentes principais: filtro, score e geração de pergunta.

Primeiro, um modelo LLaMA-3.1-3B classifica se o documento é inglês e se contém raciocínio. Depois, um LLaMA-3.3-70B avalia qualidade em múltiplos eixos. Só então outro agente extrai pergunta, resposta e cadeias de pensamento. No fim, apenas cerca de 5,45% dos documentos sobrevivem ao processo, algo como droprate de item lendário em gacha agressivo, gerando cerca de 1 milhão de pares pergunta-resposta com raciocínio.

Paralelismo triplo: dados, tarefas e agentes brigando por XP

Os autores tratam o espaço de paralelismo como se estivessem distribuindo roles em uma raid. Existe paralelismo de dados (número de partições de input), de tarefas assíncronas por partição e de agentes por papel. Em um experimento com 500 mil documentos e 32 nós A100, eles testam combinações como uma partição com 14 mil tasks, 20 partições com 700 tasks cada ou 240 partições com poucas tasks.

Quando o sistema roda com apenas uma partição e alvo de 14 mil tasks, a realidade é que só ~700 tasks ficam ativas de verdade. Isso porque 93% dos documentos morrem rapidamente no filtro, virando gargalo de I/O. Ao fatiar em 20 partições com 700 tasks cada, o sistema finalmente alcança 14 mil tasks ativas e o throughput sobe 1,61×. É a diferença entre ter um único corredor maratonista carregando todo o time e dividir o esforço entre várias lanes como em LoL.

Concorrência assíncrona: por que 50 tasks batem 240 partições

Quando eles comparam 240 partições com 1 task por vez contra 240 partições com 50 tasks assíncronas, o throughput melhora em 3,8×. Isso mostra que task parallelism é o buff mais forte dessa árvore de talentos. Aumentar partição demais começa a exigir mais CPUs e overhead de coordenação, enquanto poucas partições com muita concorrência assíncrona cada mantém as GPUs alimentadas.

Em termos de design de sistema, é como perceber que não adianta lotar o mapa com instâncias se cada instância processa jogadores em fila indiana. Melhor ter menos shards, mas com handling de sessão super assíncrono, estilo servidor bem desenhado de MMO moderno.

Agentes extras: quando adicionar mais magos não ajuda o DPS

Outra ablação varia o número de instâncias de agentes, mantendo os serviços de LLM no Ray Serve. Dobrar o número de agentes praticamente não muda o throughput, e multiplicar por dez piora levemente. O motivo é simples: as chamadas pesadas estão nos modelos, os agentes viram wrappers I/O-bound.

É o típico caso de time em que todo mundo quer jogar mid. Você pode ter cinco magos na composição, mas se só tem um carry de verdade causando dano, adicionar mais clones não muda muito. Para workflows onde os agentes fazem pré-processamento ou pós-processamento pesado, essa alavanca pode ser útil, mas aqui ela é praticamente cosmética.

Row-level vs batch-level: Ray Data como raid com fila única

Para bater de frente com a abordagem tradicional, os autores constroem um baseline usando Ray Data, onde cada batch é processado por um ator que dispara múltiplas tasks assíncronas. Parece moderno, mas o detalhe mortal é que o próximo batch só roda depois que o atual termina. Se algumas tasks são longas, o batch vira aquele jogador AFK que segura o surrender.

Rodando o mesmo setup de 14 mil tasks, com 56 réplicas de 70B, o baseline processa cerca de 9,3 milhões de documentos em quase 13 horas, gerando por volta de 130 milhões de tokens. Matrix, com agendamento por linha, processa 25 milhões de documentos em menos de 18 horas, gerando uns 379 milhões de tokens. Na métrica de tokens por segundo, Ray Data fica perto de 2.800 enquanto Matrix alcança quase 5.900, um ganho de 2,1×.

Tau2-bench: suporte técnico em modo campanha cooperativa

Barres et al criam Tau2-bench como arena onde um agente e um simulador de usuário compartilham ambiente com ferramentas reais de telecom. É basicamente um jogo de suporte técnico em que cada passo é tool call HTTP que altera estado em bases de dados. A referência oficial roda tudo em uma máquina, com threads Python gerenciando agentes e ferramentas.

Matrix desmonta esse monólito e transforma em workflow P2P com cinco papéis: user-simulator, assistant, executor de ferramentas, calculador de recompensa e sink. Ferramentas e cálculo de recompensa são empacotados em containers, LLMs vêm de serviços gpt-oss-120b. Cada trajetória vira uma corrida de mensagens entre agentes e serviços.

Throughput: do single-player ao cluster cheio de instâncias

Quando os autores aumentam a concorrência, o Tau2-agent original satura em algo como 500 threads, com throughput estabilizando. Matrix, por outro lado, continua escalando até 1.500 tarefas simultâneas em um cluster de 13 nós H100. O resultado é bem brutal: cerca de 1.500 trajetórias contra 22.800 em tempos parecidos, com tokens por segundo saltando de algo como 2.650 para 41.000, um buff de 15,4×.

A parte legal é que a recompensa média das trajetórias fica praticamente igual, algo na casa de 0,592 em ambos os casos. Ou seja, você não está farmando trajetórias aleatórias estilo RNG louco, mas replicando o comportamento de baseline com muito mais volume. Para quem quer finetunar agentes de ferramenta tipo Kimi K2, isso significa multiplicar a granularidade das políticas de raciocínio.

Otimização de rede: inventário de mensagens com bolsa extra-dimensional

Um detalhe técnico que muita gente ignora é o tamanho do histórico de conversas que viaja entre agentes. Em Tau2-bench, há mensagens que variam de algumas dezenas de bytes até mais de 1 KB. Se você ficar mandando o texto inteiro a cada salto, o cluster vira um correio de corujas sobrecarregado, estilo Hogwarts em semana de prova.

Matrix resolve isso com message offloading. Quando um item do histórico passa de um certo tamanho, o conteúdo vai para o object store distribuído de Ray e o orquestrador carrega apenas o identificador. Em cenários pesados, isso reduz a ocupação de rede em torno de 20%, o suficiente para evitar gargalos bobos de comunicação. É literalmente a diferença entre carregar todo o loot no inventário e usar um baú compartilhado com portal rápido.

---

Nem todo enxame de agentes é a nova Avengers Tower

É fácil olhar para Matrix e cair na tentação de achar que “multi-agent P2P” é a resposta universal. A hype atual de agentes já transformou scripts simples em “equipes autônomas”, tipo chamar três prompts diferentes de “squad de especialistas”. A diferença aqui é que Wang et al mexem na fundação de runtime, não só na fantasia da aplicação.

Ainda assim, isso não vira passe livre para sair ligando 50 agentes em qualquer problema. Tem workflow que continua linear, e enfiar P2P aí é igual colocar 20 sidekicks para fazer o trabalho de um Batman focado. Em cenários pequenos ou com poucas tasks, o overhead de Ray, serviços e mensagens pode virar perda de tempo, quase como subir um cluster Kubernetes para rodar script de TCC.

A hype de IA adora vender “agentes descentralizados” como se fossem um novo Conselho Jedi, mas sem medir custo, complexidade de debugging e esforço de observabilidade. Matrix traz monitoramento com métricas de filas, latência e uso de GPU, mas isso não apaga o fato de que você agora depura sistemas distribuídos inteiros. É o preço de trocar tabuleiro de RPG por MMO com shard global.

---

Próximas quests: como não virar NPC da hype

O que esse trabalho deixa muito claro é que a fronteira interessante de pesquisa não está só em modelos maiores, mas em como geramos e orquestramos dados sintéticos em escala. Em vez de ficar repetindo benchmark em MMLU como se fosse prova do ENEM infinita, podemos usar frameworks como Matrix para experimentar ambientes novos, recompensas diferentes e combinações de agentes realmente ousadas. A pergunta não é “qual LLM é maior”, mas “qual ecossistema de geração de dados permite iterar mais rápido e com menos desperdício de cluster”.

Há um monte de direções óbvias para pesquisa futura. Multi-modalidade cai quase naturalmente nesse tipo de arquitetura, com agentes de visão, áudio e texto trocando mensagens como classes diferentes em uma party de RPG. On-policy data synthesis também fica mais viável, com agentes consumindo modelos atualizados em tempo real e gerando novos dados enquanto o treinamento continua. A questão é se vamos usar isso para investigar problemas sérios ou só para gerar mais demo de agente comprando pizza.

Se você quer fugir da hype rasa, a jogada é tratar Matrix não como produto final, mas como engine. Dá para estudar políticas de agendamento, novos tipos de orquestrador, critérios de parada adaptativos, algoritmos de amostragem de tarefas e até mecanismos de reputação entre agentes, quase como um sistema de facções de MMO. Em vez de ser só mais um NPC repetindo “IA vai mudar tudo”, você pode ser quem mede o quanto a infraestrutura realmente permite isso.

Então, se você está pensando em trabalhar com dados sintéticos, agentes, finetuning de LLMs ou benchmarks complexos, vale muito a pena ler o paper completo. Ali tem detalhes de implementação, nuances da integração com Ray, vLLM, containers e decisões de design que não cabem em resumo de newsletter.

Leia como quem abre o manual avançado do sistema de magia do seu RPG favorito, porque as próximas pesquisas que você fizer podem depender diretamente de entender como essa guilda distribuída realmente funciona.