Reinforcement Learning MoE no Amazon EKS obtém 40% mais throughput, mas o benchmark tem limitações

A Amazon afirma que o reinforcement learning MoE no Amazon EKS alcançou 40% mais throughput agregado de rollouts depois que seus engenheiros habilitaram o DeepEP sobre o Elastic Fabric Adapter. O teste abrangeu 48 instâncias P5en, com 16 destinadas ao treinamento da política e 32 à geração de rollouts de inferência. Trata-se de um resultado substancial para uma etapa cara do pós-treinamento de grandes modelos.

A mudança importante não é simplesmente mais uma configuração de GPU mais rápida. A Amazon adaptou o caminho de comunicação entre especialistas do DeepEP para usar libfabric, dando ao DeepEP v2 suporte nativo às redes da AWS. Essa integração mira o padrão irregular de tráfego criado quando um modelo Mixture-of-Experts encaminha tokens entre especialistas em GPUs diferentes.

O resultado também exige uma contextualização cuidadosa. A AWS divulgou um ganho relativo de throughput para uma carga de trabalho MoE superesparsa, e não um benchmark universal para todos os modelos, clusters ou frameworks de reinforcement learning. Pesquisas independentes de sistemas documentaram a dificuldade de transportar comunicação paralela entre especialistas por diferentes arquiteturas de GPU e rede.

O que a Amazon mudou em sua stack de Reinforcement Learning MoE

O ganho relatado pela Amazon veio da mudança na forma como tokens roteados trafegam entre especialistas, e não da adição de mais máquinas ao cluster medido.

A arquitetura da AWS divide um trabalho de reinforcement learning em vários grupos de workers. Nós de GPU executam o treinamento da política, a inferência do modelo de recompensa e a geração de rollouts. Nós de CPU executam ambientes e pré-processamento, enquanto nós otimizados para memória armazenam buffers de experiência e caches de checkpoints.

O Amazon EKS atua como camada de orquestração. Ele aloca contêineres, gerencia grupos de nós separados, coordena falhas e permite que operadores escalem cada parte da carga de trabalho de forma independente. O Amazon S3 armazena datasets, checkpoints, pesos finais e outros artefatos duráveis fora do caminho de execução sensível à latência.

Essa separação importa porque reinforcement learning não é uma computação uniforme. Durante a geração de rollouts, um worker de inferência usa a política atual para interagir com um ambiente e produzir respostas ou trajetórias candidatas. Um sistema de recompensa avalia essas amostras, e os workers de treinamento da política consomem a experiência resultante.

Os pesos atualizados retornam então à frota de rollouts, iniciando outra iteração da política. Esse ciclo aparece no Reinforcement Learning from Human Feedback, ou RLHF, que usa sinais de preferência para aprimorar um modelo. Também aparece no Group Relative Policy Optimization, ou GRPO, que avalia saídas em relação a outras amostras de um grupo.

Cada etapa exerce pressão diferente sobre a infraestrutura. A geração de rollouts se assemelha à inferência distribuída e, muitas vezes, pode dividir o trabalho entre workers independentes. O treinamento da política exige sincronização mais estreita, pois as GPUs participantes precisam concluir operações coordenadas antes que a próxima etapa possa avançar.

Por isso, a arquitetura separa 32 instâncias de inferência de 16 instâncias de treinamento no teste relatado. Entre esses 48 sistemas P5en, a Amazon afirma que o DeepEP sobre EFA elevou o throughput agregado de rollouts em 40% em comparação com a configuração sem DeepEP.

As instâncias P5en usam GPUs NVIDIA H200 e redes AWS de alta largura de banda. Uma implantação completa de 48 instâncias representa centenas de aceleradores, embora a AWS informe que sua arquitetura maior pode se estender para cerca de mil aceleradores. O percentual publicado descreve a comparação com 48 instâncias, não todos os tamanhos possíveis de cluster.

O próprio modelo é descrito apenas como um modelo MoE superesparso. Um modelo Mixture-of-Experts contém vários blocos feed-forward especializados, mas ativa apenas um subconjunto deles para cada token. A esparsidade reduz a computação por token, mas cria um exigente problema de roteamento quando os especialistas residem em GPUs diferentes.

Operações coletivas padrão funcionam bem quando cada rank troca blocos previsíveis de tamanho semelhante. O roteamento em MoE é diferente. Os tokens escolhem especialistas dinamicamente, de modo que o tráfego pode ser esparso, desigual e composto por muitas transferências pequenas.

Essa diferença explica por que a infraestrutura importa tanto. Maior capacidade teórica do modelo não entrega automaticamente mais tokens úteis por segundo. Se o despacho aos especialistas e a coleta dos resultados sobrecarregarem a rede, GPUs caras aguardam ativações em vez de processá-las.

Por que o Reinforcement Learning MoE no Amazon EKS atinge um gargalo de rede

A computação esparsa economiza operações aritméticas, mas o paralelismo entre especialistas pode devolver esse custo na forma de atraso de comunicação.

O paralelismo entre especialistas distribui os especialistas de um modelo entre GPUs. Quando um roteador seleciona especialistas remotos, o sistema precisa despachar a ativação de cada token para o dispositivo correto. Depois que o especialista a processa, uma operação de combinação devolve a saída ao seu caminho de execução original.

Essas trocas ocorrem repetidamente por todo o modelo. Seus destinos dependem de decisões de roteamento tomadas em tempo de execução, e diferentes especialistas podem receber números diferentes de tokens. Portanto, a rede precisa lidar com muitas transferências detalhadas sem permitir que alguns destinos muito ocupados bloqueiem todos os participantes.

O DeepEP foi criado para esse padrão. O projeto DeepEP fornece kernels especializados de despacho e combinação para cargas de trabalho com paralelismo entre especialistas. Ele usa NVLink para comunicação dentro de um servidor e um transporte compatível com RDMA entre servidores.

Remote Direct Memory Access, ou RDMA, permite que uma máquina transfira dados diretamente para a memória de outra, com menor envolvimento da CPU. Esse caminho mais curto pode reduzir a sobrecarga de software e tornar o hardware de rede de alta velocidade mais útil.

Elastic Fabric Adapter, ou EFA, é a interface de rede de baixa latência da AWS para computação fortemente acoplada. A documentação do EFA descreve um caminho que contorna o sistema operacional, baseado em AWS Scalable Reliable Datagram. O EKS pode expor dispositivos EFA a pods que executam aplicações de machine learning distribuído.

Dentro de cada instância P5en, NVLink e NVSwitch transportam o tráfego de GPU pela malha local de aceleradores. Para transferências entre instâncias, o EFA se torna o caminho relevante. A integração da Amazon usa libfabric, uma interface que permite que aplicações acessem diferentes provedores de rede de alto desempenho por meio de uma API comum.

A Amazon afirma que seus engenheiros contribuíram com recursos que transferiram as primitivas de comunicação do DeepEP de um backend RDMA específico de CUDA para libfabric. Com esse trabalho, o DeepEP v2 pode enviar dados entre nós por EFA, mantendo kernels especializados para despacho e combinação entre especialistas.

A distinção entre operações especializadas para especialistas e coletivas densas é central para o resultado. O NCCL continua útil para operações regulares como all-reduce, all-gather e reduce-scatter. O DeepEP visa as trocas esparsas all-to-all em torno das camadas MoE.

Pesquisas recentes refletem essa divisão. Os autores de NCCL EP descrevem modos separados de baixa latência e alto throughput para comunicação entre especialistas. Seu projeto de alto throughput agrega dados dentro de domínios NVLink antes de transmiti-los por conexões RDMA entre nós.

Essa hierarquia reduz a quantidade de tráfego detalhado que cruza a fronteira mais lenta entre máquinas. Ela também reconhece que um cluster não é uma única rede uniforme. A comunicação dentro de um servidor tem características de largura de banda e latência diferentes da comunicação entre servidores.

A implementação da AWS segue o mesmo princípio geral. O tráfego local permanece no NVLink, enquanto a libfabric transporta o tráfego DeepEP entre nós pelo EFA. Esse caminho consciente da topologia substitui um tratamento genérico para cada transferência de token.

O aumento resultante de 40% refere-se à produção agregada de rollouts, não apenas a um microbenchmark de comunicação. Essa medida de ponta a ponta é valiosa porque um kernel mais rápido nem sempre acelera todo o ciclo de reinforcement learning. O ganho sugere que a comunicação entre especialistas era relevante o suficiente para afetar o trabalho de rollout concluído.

No entanto, o throughput de rollouts ainda é apenas uma camada do sistema. O tempo de iteração da política também depende da execução do ambiente, da avaliação de recompensas, do armazenamento de amostras em buffer, da publicação de checkpoints, da computação de treinamento e da sincronização de pesos. Otimizar uma etapa pode expor um gargalo em outra.

A verdadeira disputa é entre roteamento especializado e coletivas genéricas

A principal disputa ocorre entre uma comunicação projetada para roteamento dinâmico entre especialistas e operações coletivas projetadas para movimentação regular de dados.

Coletivas genéricas são atraentes porque são maduras, amplamente suportadas e mais fáceis de integrar. Elas funcionam em muitos frameworks de treinamento e configurações de hardware. Operadores também podem testá-las com ferramentas conhecidas e compreender seu comportamento de sincronização.

O tráfego MoE viola várias premissas que tornam essas coletivas eficientes. Cada token pode selecionar um conjunto diferente de especialistas. Alguns especialistas tornam-se temporariamente populares, os tamanhos das mensagens permanecem pequenos e o sistema executa operações de despacho e combinação em cada camada MoE.

Uma implementação convencional pode empacotar esse tráfego em operações all-to-all. Essa abordagem continua funcional, mas a sobrecarga de sincronização e tratamento de mensagens cresce à medida que o paralelismo entre especialistas abrange mais nós. Mais GPUs passam então a criar mais relações de comunicação, em vez de proporcionalmente mais computação útil.

O DeepEP ataca esse problema com kernels construídos em torno da semântica do roteamento entre especialistas. O kernel de despacho envia ativações de tokens aos especialistas selecionados. O kernel de combinação devolve ativações processadas, evitando trabalho que uma coletiva geral poderia executar para destinos não utilizados.

O projeto também busca sobrepor comunicação e computação. Se uma GPU puder continuar operações úteis de matriz enquanto as transferências avançam, parte do tempo de rede desaparece do caminho crítico. Essa sobreposição se torna mais difícil quando a comunicação exige coordenação repetida da CPU ou sincronização global rígida.

A migração para libfabric da Amazon é relevante porque a otimização original estava estreitamente associada a GPUs NVIDIA e redes no estilo InfiniBand. Uma biblioteca de comunicação que funciona bem em uma malha não preserva automaticamente seu comportamento em outra. Garantias de ordenação, início de mensagens e interfaces de dispositivos variam.

A integração, portanto, representa mais do que mudar um endereço de rede. As premissas do DeepEP precisam se mapear para a semântica de transporte do EFA, e a implementação precisa preservar a entrega correta de tokens. Ela também deve evitar introduzir sobrecarga de software suficiente para eliminar os benefícios do roteamento especializado.

A Amazon afirma que os sistemas P5 e P6 compatíveis podem usar GPUDirect RDMA com EFA. O GPUDirect RDMA permite que transferências de rede leiam e gravem na memória da GPU sem preparar cada carga útil na memória comum do host. O sistema operacional permanece fora do caminho principal dos dados.

Esse projeto pressiona implantações MoE genéricas que dependem apenas de coletivas padrão. Equipes de infraestrutura que usam grandes modelos com paralelismo entre especialistas agora têm evidências de que um caminho especializado pode aprimorar uma carga de trabalho de reinforcement learning relevante para produção.

O resultado também pressiona os mantenedores de frameworks. O suporte ao DeepEP precisa alcançar mecanismos de serving, sistemas de reinforcement learning, imagens de contêiner, agendadores e ferramentas de observabilidade. Um transporte rápido que exige uma build personalizada frágil pode perder sua vantagem durante a implantação ou recuperação.

O NCCL 2.31 acrescenta outra peça ao cenário. A AWS afirma que essa versão inclui otimizações mais recentes de EFA para comunicação coletiva densa. Portanto, uma pilha realista de treinamento de MoE usa mecanismos diferentes para classes de tráfego distintas, em vez de declarar um vencedor universal.

O DeepEP gerencia o despacho e a combinação irregulares de especialistas. O NCCL continua a cuidar da sincronização densa em torno das camadas de atenção, do paralelismo de tensor, do paralelismo de dados e do estado do otimizador. O EFA transporta ambas as classes entre máquinas por caminhos otimizados para seus respectivos padrões.

Essa divisão é a principal lição arquitetural. A escalabilidade de MoE depende de identificar a comunicação por formato e finalidade. Tratar cada transferência como intercambiável deixa desempenho disponível sem aproveitamento.

O que a alegação de 40% de throughput do DeepEP não estabelece

O benchmark sustenta uma decisão arquitetural específica, mas não estabelece um ganho universal de 40% do DeepEP sobre o EFA.

A Amazon identifica a alocação de instâncias, a melhoria relativa e o perfil amplo de esparsidade do modelo. Ela não publica a contagem de parâmetros do modelo, a quantidade de especialistas, a distribuição de roteamento, os comprimentos de sequência, os tamanhos de lote nem a configuração completa de referência.

Esses detalhes afetam diretamente a comunicação entre especialistas. Um modelo que ativa mais especialistas por token pode gerar mais tráfego. Lotes maiores podem combinar mensagens com mais eficiência, enquanto pequenos lotes de decodificação podem ampliar a latência fixa.

A expressão “throughput agregado de rollout” também precisa de contexto. A AWS não fornece, na publicação pública, o número absoluto de tokens de saída, trajetórias ou solicitações concluídas por segundo. Os leitores não podem calcular a utilização total do cluster nem compará-la diretamente com a de outro provedor.

A referência importa tanto quanto. “Sem DeepEP” pode significar uma implementação padrão de all-to-all do NCCL com escolhas específicas de ajuste. Agregação diferente de mensagens, posicionamento de especialistas, concorrência ou políticas de roteamento podem reduzir ou ampliar a diferença medida.

A Amazon relata um resultado controlado de sua própria carga de trabalho interna. A empresa não afirma que o benchmark tenha sido auditado de forma independente, e o material público não inclui a variância de execuções repetidas. Portanto, a formulação correta é que a AWS afirma que o throughput aumentou 40%.

Há também uma questão de portabilidade. Pesquisas anteriores sobre UCCL-EP argumentavam que sistemas de comunicação entre especialistas estreitamente vinculados a interfaces de GPU e rede criam um trabalho de integração substancial. O artigo examinou especificamente como semânticas de ordenação divergentes complicam o suporte a EFA e a outras redes que não usam InfiniBand.

Essa pesquisa antecede o trabalho nativo em EFA recém-descrito pela Amazon. Ela continua relevante porque explica a barreira técnica que a AWS afirma ter resolvido agora por meio de contribuições ao libfabric. Os dois relatos descrevem pontos diferentes em uma história de implementação que muda rapidamente.

O UCCL-EP segue outra rota. Ele mantém as decisões de roteamento nas GPUs, mas delega a execução de rede a proxies de CPU multithread, usando um canal de controle para superar diferenças de hardware. Seus autores relatam ganhos em sistemas NVIDIA mais EFA, mas esses testes envolvem seus próprios modelos, frameworks e configurações.

Nenhum resultado invalida o outro. Eles mostram que o desenho do transporte pode mudar o resultado e que “suporte a EFA” não identifica um único caminho fixo de execução. Os operadores precisam saber se uma compilação usa transferências iniciadas por GPU, proxies de CPU, agregação de mensagens ou outra camada de compatibilidade.

Os requisitos e os resultados de desempenho publicados pelo próprio DeepEP também evoluíram. A documentação atual do projeto relata boa largura de banda em configurações RDMA compatíveis, mas incentiva os usuários a testar diretamente implantações maiores com paralelismo de especialistas. Esse conselho é especialmente importante em infraestruturas de nuvem com topologia e comportamento de congestionamento distintos.

A escala do cluster introduz mais incerteza. O teste relatado usou 48 instâncias P5en, enquanto a AWS discute escalar a arquitetura mais ampla para aproximadamente mil aceleradores. Um desenho que funciona bem em 48 nós não necessariamente mantém a mesma eficiência em todas as escalas maiores.

A contenção de rede pode surgir quando vários grupos de trabalhadores compartilham a infraestrutura. O roteamento de tokens pode se tornar mais desequilibrado conforme o comportamento do modelo ou da carga de trabalho muda. Um único rank lento também pode atrasar operações de treinamento fortemente sincronizadas.

O aprendizado por reforço acrescenta sua própria fonte de variação. Comprimentos de prompts, comprimentos de respostas, latência do ambiente, configurações de amostragem e complexidade do modelo de recompensa afetam quanto tempo os trabalhadores de rollout passam se comunicando. Um ganho de 40% em uma carga de trabalho intensiva em comunicação pode diminuir quando a geração ou a execução do ambiente domina.

O resultado diz ainda menos sobre atendimento online. A inferência em produção costuma usar lotes menores e metas rígidas de latência por solicitação. Um kernel de alto throughput ajustado para geração de rollout não reduz automaticamente o tempo até o primeiro token nem o tempo por token de saída para usuários interativos.

O custo continua sem ser declarado como medida absoluta. Um throughput maior no mesmo cluster normalmente melhora o trabalho útil por hora de acelerador, mas a publicação não informa o custo total de treinamento. Ela também não compara a configuração otimizada com tipos alternativos de instância ou bibliotecas de rede.

Essas omissões não tornam o resultado irrelevante. Elas definem onde ele é útil. O benchmark é evidência de que a integração do DeepEP pela AWS pode eliminar um gargalo significativo em um pipeline grande de aprendizado por reforço com MoE.

EKS e capacidade Spot mudam o restante do sistema de RL

O ganho de comunicação só se torna operacionalmente útil quando o agendador, o buffer, o armazenamento e o modelo de falhas mantêm a frota de rollout mais rápida abastecida.

O Amazon EKS permite que a arquitetura atribua diferentes tipos de nós a tarefas distintas. Grupos de nós com GPU podem escalar conforme a demanda de treinamento e inferência. Grupos de CPU podem expandir para trabalhadores de ambiente, enquanto sistemas orientados à memória absorvem dados temporários de experiência.

Essa heterogeneidade é especialmente relevante para GRPO e RLHF. Os trabalhadores de rollout podem gerar grandes volumes de dados temporários, mas os treinadores de política os consomem em lotes sincronizados. Se as taxas de produção e consumo divergem, um lado espera enquanto o outro acumula uma fila.

Um buffer compartilhado de experiência em memória desacopla essas taxas por curtos períodos. Os trabalhadores de rollout publicam amostras concluídas, e os treinadores buscam lotes quando estão prontos. Caches de checkpoints ajudam a distribuir pesos atualizados sem forçar cada transferência a passar por armazenamento persistente de objetos.

O Amazon S3 desempenha um papel diferente. Ele armazena conjuntos de dados, checkpoints recuperáveis, artefatos de modelo concluídos e pesos finais. Manter esse caminho persistente fora da troca mais frequente de amostras impede que a latência do armazenamento de objetos controle cada etapa de treinamento.

Essa separação também esclarece o valor do EKS. O Kubernetes não está acelerando a multiplicação de matrizes nem kernels de especialistas. Ele está coordenando a coleção de serviços necessária para manter os aceleradores produtivos.

O EKS gerencia posicionamento, reinicializações, políticas de escalonamento e limites entre grupos de nós. Ele pode agendar capacidade estável de treinamento de política separadamente de trabalhadores de rollout mais elásticos. Esse limite sustenta a segunda otimização da Amazon: usar EC2 Spot Instances para parte da geração de rollout.

A capacidade Spot pode ser interrompida quando a AWS precisa recuperar as instâncias subjacentes. Esse risco é difícil para o treinamento de política fortemente sincronizado, porque a perda de um trabalhador pode paralisar ou reiniciar um trabalho coordenado. As tarefas de rollout são mais fáceis de particionar e repetir.

A Amazon recomenda atribuir aos trabalhadores de rollout unidades de trabalho delimitadas e publicar amostras com frequência. Quando chega um aviso de interrupção, um trabalhador pode concluir as solicitações ativas e devolver tarefas inacabadas a uma fila. Outros trabalhadores continuam sem reiniciar todo o grupo de treinamento de política.

A estratégia não elimina o custo das interrupções. Gerações parciais perdidas desperdiçam algum processamento, e os nós de substituição precisam de contêineres, pesos de modelo e bibliotecas de comunicação. As decisões de escalonamento automático também precisam considerar a profundidade da fila, o tempo de carregamento do modelo e a capacidade Spot disponível.

Ainda assim, a topologia isola dois domínios de falha. Os treinadores de política permanecem em capacidade estável, enquanto a geração de rollout usa um pool mais barato, porém menos previsível. Esse desenho corresponde aos diferentes requisitos de sincronização das duas etapas.

O aumento de 40% no throughput do DeepEP pode alterar esse equilíbrio. Trabalhadores de inferência mais rápidos podem entregar experiência mais depressa do que os treinadores a consomem. Nesse caso, os operadores precisam redimensionar grupos de nós, ajustar o agendamento de lotes ou reduzir a capacidade de inferência para evitar pagar por produção ociosa.

O oposto pode acontecer após uma atualização de política. A distribuição de pesos e o tempo de reinicialização dos trabalhadores podem temporariamente deixar o buffer de experiência sem dados. Portanto, um painel de produção útil deve acompanhar a iteração de política de ponta a ponta, e não apenas os tokens gerados por segundo.

As equipes também precisam de informações de compilação reproduzíveis. DeepEP, NCCL, CUDA, libfabric, drivers EFA, versões de frameworks e arquitetura de GPU influenciam o caminho de dados. Alterar um componente pode selecionar silenciosamente uma alternativa mais lenta.

Essa evidência operacional deve ficar junto dos registros de modelos e experimentos. As equipes de engenharia podem preservar decisões de configuração, notas de benchmark e relatórios de falhas em uma base de conhecimento técnico pesquisável. Essa prática se torna valiosa quando uma reconstrução posterior de imagem altera o throughput sem alterar o modelo.

Três sinais mostrarão se o ganho se generaliza

O próximo teste é a reprodutibilidade entre modelos, tamanhos de cluster e iterações completas de política.

O primeiro sinal é um pacote público de benchmarks com throughput absoluto. Resultados úteis incluiriam tokens ou trajetórias por segundo, distribuições de latência, desequilíbrio de carga entre especialistas, utilização de rede e variância entre execuções repetidas.

Esse pacote deve especificar a operação coletiva de referência, todas as versões relevantes de software e o caminho preciso de transporte do DeepEP. Ele também deve divulgar as dimensões do modelo, especialistas ativos por token, tamanhos de lote, comprimentos de prompts, comprimentos de respostas e grau de paralelismo de especialistas.

Se equipes independentes reproduzirem um ganho semelhante, a alegação da AWS se tornará mais forte. Se os resultados variarem muito, a integração continuará útil, mas específica para determinada carga de trabalho. Qualquer um dos resultados ajudaria os operadores a decidir quando sua complexidade adicional se justifica.

O segundo sinal é a eficiência de escalonamento além da configuração publicada de 48 instâncias. Resultados em vários tamanhos de cluster mostrariam se o throughput cresce proporcionalmente ou perde terreno para sincronização, congestionamento e desequilíbrio entre especialistas.

Um estudo de escalonamento significativo deve manter a definição da carga de trabalho constante enquanto aumenta os recursos. Ele deve relatar tanto a produção agregada quanto a eficiência por acelerador. O throughput agregado pode subir mesmo quando cada GPU adicional contribui com menos trabalho útil.

Uma eficiência forte rumo a aproximadamente mil aceleradores sustentaria a alegação arquitetural mais ampla da AWS. Uma queda acentuada indicaria que o DeepEP eliminou um gargalo enquanto outro surgiu em maior escala.

O terceiro sinal é o tempo de iteração de política de ponta a ponta sob falhas reais. O throughput de rollout importa porque os trabalhadores de treinamento precisam de experiência recente, não porque gerar tokens isolados seja o objetivo final.

Medições futuras devem incluir execução de ambiente, avaliação de recompensa, atrasos de buffer, atualizações de política, publicação de checkpoints e redistribuição de pesos. Elas também devem mostrar como as interrupções de Spot afetam as amostras concluídas e o tempo de recuperação.

Uma iteração completa mais curta confirmaria que a otimização de comunicação melhora o progresso do aprendizado por reforço, em vez de deslocar o tempo ocioso para outro lugar. Se o tempo de iteração quase não mudar, as equipes devem investigar treinamento, armazenamento ou sincronização antes de adicionar mais capacidade de rollout.

O aprendizado por reforço de MoE no Amazon EKS agora tem um caminho crível para combinar a orquestração do Kubernetes, a rede EFA e a comunicação especializada entre especialistas. O aumento reportado de 40% torna esse caminho digno de teste, mas ele continua sendo uma medição inicial, e não uma constante transferível. As equipes de infraestrutura devem reproduzir a comparação com seu próprio modelo, perfil de roteamento e loop de RL antes de padronizar a stack. A questão prática não é se o DeepEP consegue produzir um gráfico mais rápido. É se o mesmo cluster conclui mais atualizações de política validadas, com confiabilidade e custo aceitáveis, depois que todas as partes do sistema são contabilizadas.