Resumo Técnico: Superando Gargalos de Orquestração em Escala Exa

Declaração do Problema

A computação científica está transitando de aplicações monolíticas para fluxos de trabalho acoplados de Simulação-IA (Sim-AI). Esses fluxos de trabalho consistem em tarefas altamente heterogêneas, que variam desde inferência serial de curta duração (subsegundo) até simulações MPI de múltiplos nós de longa duração (milhares de segundos). À medida que esses fluxos de trabalho escalam para sistemas de classe exascala (ex: Aurora, Frontier), eles geram tamanhos de ensemble extremos (milhões de tarefas concorrentes) e alta variância na duração das tarefas.

As abordagens de orquestração atuais enfrentam dois gargalos primários:

1. Escalonadores de Nível de Sistema: Ferramentas como Slurm e PBSPro são otimizadas para grandes alocações, mas lutam com o throughput extremo exigido por milhões de tarefas pequenas e dinâmicas, levando frequentemente a gargalos de escalonamento.
2. Ferramentas de Fluxo de Trabalho de Espaço do Usuário: Os frameworks existentes frequentemente dependem de planos de controle centralizados que criam gargalos de serialização em escala. Embora existam ferramentas descentralizadas, muitas carecem de suporte nativo para aplicações MPI de múltiplos nós ou impõem curvas de aprendizado íngremes. Além disso, a maioria das ferramentas carece de interfaces de escalonamento programáveis, impedindo que cientistas do domínio injetem políticas de tempo de execução personalizadas necessárias para abordar gargalos específicos de fluxo de trabalho.

Metodologia: EnsembleLauncher

Para enfrentar esses desafios, os autores desenvolveram o EnsembleLauncher, um orquestrador de fluxo de trabalho recursivamente hierárquico projetado para ensembles de Sim-AI em exascala.

Design Arquitetural

O EnsembleLauncher emprega um plano de controle totalmente descentralizado estruturado como uma árvore recursiva:

• Managers (Gerentes): Governam subárvores (Global Manager como raiz, Sub-Managers como nós intermediários). Eles lidam com o roteamento de tarefas de grão grosso e partição de recursos.
• Launchers (Lançadores): Servem como nós folha e motores de execução primários. Eles lidam com o ordenamento e a execução de tarefas de grão fino.
• Modo Híbrido Push-Pull: O sistema suporta uma arquitetura híbrida onde os níveis superiores usam Particionamento Estático (Push) para minimizar a comunicação do plano de controle, enquanto os níveis folha usam Balanceamento de Carga Dinâmico (Pull) para mitigar a disparidade no tempo de execução via roubo de trabalho (work-stealing).

Componentes Principais

• Interface de Escalonamento Programável: O sistema expõe interfaces de política em dois níveis:
  • Children Scheduler (Nível de Manager): Determina o roteamento de tarefas e a partição de recursos ($S_{i+1} = f(S_i, T, N, d)$).
  • Task Scheduler (Nível de Launcher): Determina o ordenamento de tarefas na fila de despacho ($P = f(T, S)$).
  • Essas interfaces permitem que os usuários implementem heurísticas customizadas (ex: FIFO, Shortest First, Largest First) sem modificar o orquestrador central.
• Abstração de Executor: Uma camada sem estado que desacopla o estado da orquestração dos mecanismos de execução, suportando pools de processos Python, pools de threads e pools de processos MPI. Isso permite o co-escalonamento de tarefas seriais e de MPI.
• Tolerância a Falhas: Cada orquestrador mantém um checkpointer local. Falhas disparam o encerramento localizado e o reinício da subárvore afetada, com mecanismos de heartbeat detectando filhos não responsivos.

Configuração de Avaliação

Experimentos foram conduzidos no supercomputador Aurora (10.624 nós, CPUs Intel Xeon Max, GPUs Intel Data Center). A avaliação comparou o EnsembleLauncher com ferramentas de última geração (Dask, Parsl) e uma linha de base MPI nativa através de:

• Micro-benchmarks: Throughput e latência de nó único.
• Testes de Escala: Escalonamento fraco (weak scaling - carga de trabalho proporcional aos nós) e escalonamento forte (strong scaling - carga de trabalho fixa, aumentando os nós) até 8.192 nós.
• Sensibilidade de Política: Análise do impacto da topologia do plano de controle e o efeito das políticas de escalonamento em cargas de trabalho heterogêneas.

Resultados Principais

1. Escalabilidade e Throughput

• Escalonamento em Exascala: O EnsembleLauncher escalou com sucesso para 8.192 nós com 8 milhões de tarefas seriais.
• Ganho de Desempenho: Superou ferramentas de última geração (Parsl e Dask) em mais de 4× em 2.048 nós, mesmo para tarefas de longa duração (60s).
• Topologia vs. Implementação: Experimentos controlados demonstraram que a topologia do plano de controle é o determinante primário do throughput, não a implementação específica do framework. Quando o Dask e o Parsl foram configurados com a mesma hierarquia de nível único, exibiram comportamento de escalonamento e pontos de falha quase idênticos.
• Vantagem Hierárquica: Uma hierarquia de dois níveis (Depth=2) no EnsembleLauncher eliminou a saturação do plano de controle que causava a fome (starvation) dos workers em configurações de nível único, mantendo um escalonamento forte quase ideal.

2. Latência

• Latência de Despacho: Em testes de nó único, o EnsembleLauncher alcançou uma latência de ida e volta mediana de 3ms (apenas Launcher) e 4ms (Manager-Launcher). Isso é significativamente menor que o Dask (10ms) e permanece bem abaixo da duração de tarefas típicas de inferência de Sim-AI (dezenas a centenas de milissegundos).
• Overhead: Embora cada nível hierárquico adicione aproximadamente 1ms de latência, esse overhead é negligenciável comparado ao tempo de execução das tarefas científicas.

3. Impacto das Políticas de Escalonamento

• Cargas de Trabalho Heterogêneas: Em experimentos com um "bag-of-tasks" apresentando alta variância em duração e requisitos de recursos, as políticas Largest First e Longest First reduziram significativamente o tempo total de execução em comparação ao FIFO conforme a variância aumentava.
• Pipelines de Sim-AI: Em um protótipo de workflow MOFA, uma política de roteamento Adaptativa (roteando dinamicamente para o filho menos carregado) alcançou 2× mais utilização de GPU e tempos de execução mais curtos em comparação com políticas de particionamento estático ou uniforme. O particionamento estático causou gargalos onde tarefas seriais saturaram nós específicos, bloqueando estágios subsequentes do pipeline.

Significância e Alegações

O artigo afirma que o EnsembleLauncher supera efetivamente os gargalos de orquestração em fluxos de trabalho de Sim-AI em exascala ao mudar o paradigma arquitetural de um controle centralizado para um modelo recursivamente hierárquico e descentralizado.

As principais contribuições incluem:

1. Demonstração da Dominância da Topologia: Provar que a topologia do plano de controle é o fator crítico para a escalabilidade, não a linguagem de implementação subjacente ou o algoritmo específico do escalonador.
2. Escalabilidade: Alcançar throughput em 8.192 nós que excede as ferramentas de última geração por um fator de quatro, permitindo a execução de ensembles com até 8 milhões de tarefas.
3. Programabilidade: Fornecer uma interface programável que permite aos cientistas do domínio ajustar políticas de escalonamento e roteamento para características específicas de carga de trabalho (ex: alta variância, tarefas mistas MPI/serial) sem modificar o código do orquestrador.
4. Co-Escalonamento: Integrar com sucesso a execução de tarefas de inferência serial granulares e simulações MPI massivas de múltiplos nós dentro de um único fluxo de trabalho.

Os autores concluem que, embora 8.192 nós representem a alocação máxima no Aurora, o design do sistema sugere que este não é o limite de escalabilidade do EnsembleLauncher. Trabalhos futuros visam integrar interfaces de Model Context Protocol (MCP) para fluxos de trabalho de agentes impulsionados por LLM e explorar políticas de escalonamento baseadas em IA que adaptem heurísticas em tempo de execução.