Google leva o Pathways, arquitetura de treinamento do Gemini, à disponibilidade geral no Cloud

O Pathways troca a sincronização rígida de DDP e FSDP por um único cliente que descreve todo o treinamento como grafo, com despacho assíncrono e um scheduler central cuidando da ordem entre os blocos.

O Google anunciou nesta segunda-feira (9 de novembro de 2026), em post no Google Developers Blog, a disponibilidade geral (GA) do Pathways no Google Cloud↳Google Cloud13 conteúdosPrograma da Google Cloud no Brasil projeta formar de forma gratuita 30 mil universitáriosDev (Back & Front) · mar 2026Google Cloud OnBoard capacita estudantes e desenvolvedores de TIGestão Dev & TI · mai 2019Desenvolvedores poderão participar de treinamento gratuito do Google CloudGestão Dev & TI · mai 2019Ver tudo em DevSecOps →. É o sistema distribuído que o próprio Google usa internamente para treinar seus modelos maiores, incluindo o Gemini, e que agora qualquer time pode contratar como serviço.

A proposta do Pathways não é concorrer com DDP ou FSDP na mesma categoria: é mudar a camada de execução por baixo deles. Enquanto DDP e FSDP seguem o modelo SPMD (Single Program, Multiple Data), em que todo acelerador roda a mesma cópia do script e sincroniza via coletivos como AllReduce, o Pathways introduz um único cliente Python↳Python56 conteúdosVSCode + Python + Alexa: Desenvolva e teste skills para alexa localmente com pythonDev (Back & Front) · out 2025Dominando decoradores em Python: um guia completo com exemplosDev (Back & Front) · jan 2025Desenvolvimento de software: diferenças entre Python, JavaScript e JavaGestão Dev & TI · nov 2024Ver tudo em Dev (Back & Front) → que descreve a computação inteira como um grafo, deixando o runtime decidir onde cada parte roda, como os tensores se movem e em que ordem tudo acontece.

Onde o SPMD trava

SPMD funciona bem quando o job é um programa só, rodando igual em cada chip. O problema aparece quando o trabalho deixa de ser uniforme. Um pipeline parallelism, por exemplo, divide o modelo em blocos que rodam código diferente em dispositivos diferentes: enquanto um bloco processa o primeiro micro-batch, os outros ficam ociosos, pagando conta sem produzir nada (o post chama isso de "pipeline bubble").

Outro caso citado pelo Google é o pós-treinamento por reinforcement learning (RL) de LLMs↳LLMs48 conteúdosConsiderações básicas de hardware para modelos de linguagem em código aberto: Memória, Desempenho e ViabilidadeMarketing Tech · out 2025Modelos de linguagem sob ataque: o lado obscuro da IA generativaDevSecOps · mai 2025Criando um LLM – modelo de linguagem de grande escala – do zero com TransformersAI · abr 2024Ver tudo em AI →: um sampler gera respostas, um reward model avalia, um trainer atualiza a política e devolve pesos novos ao sampler. São três programas distintos que precisam se sobrepor; se rodarem em sequência, o sampler fica parado enquanto o trainer trabalha, e vice-versa.

Em ambos os cenários, nenhum processo individual enxerga o grafo de dependências inteiro, porque cada worker só conhece seus próprios dispositivos e dados. Isso tem três consequências práticas, segundo o post:

• Falha derruba o job inteiro. Como cada processo segura seus aceleradores do início ao fim e todo coletivo bloqueia até todos terminarem, uma máquina perdida interrompe a coleta inteira e força reinício do último checkpoint. O Google cita que isso interrompeu o treinamento do Gemini 2.5 múltiplas vezes por hora.
• Capacidade não se realoca. Um estágio que precisa de menos chips continua prendendo os excedentes até o job terminar.
• Debug em múltiplos hosts é doloroso. Não existe um processo único onde dar breakpoint; quando trava, cada worker fica parado esperando o coletivo, sem um lugar central que mostre o job inteiro.

Como o Pathways resolve isso

Com Pathways, o desenvolvedor escreve contra dispositivos virtuais, não físicos. Um resource manager mapeia esses dispositivos virtuais para chips reais, e um worker em cada host acelerador executa os programas compilados que recebe. Essa indireção é o que permite remapear o trabalho para chips saudáveis quando um host cai, em vez de relançar o job inteiro, o que é a base do que o Google chama de elastic training.

O mesmo resource manager permite que um único cluster Pathways atenda vários clientes ao mesmo tempo. No Shared Pathways Service, o cluster roda como serviço de longa duração, e cada cliente conecta sob demanda (de um laptop ou VM), recebe suas slices de TPU do pool compartilhado e devolve ao desconectar.

A diferença de escala de rede explica por que isso importa. Num TPU v5p, cada chip tem 1.200 GB/s de banda bidirecional dentro do grupo tightly connected, mas apenas cerca de 6 GB/s (50 Gb/s) para a rede do datacenter entre grupos, duas ordens de grandeza a menos. Como cada passo de SPMD bloqueia nos seus coletivos, quanto mais grupos o job atravessa, maior a fatia de cada step gasta movendo dado em vez de computando.

Dispatch assíncrono e scheduler central

Para manter os aceleradores ocupados, o Pathways despacha com futures e dispatch assíncrono paralelo. Enquanto o bloco A ainda computa, o runtime já conhece os shapes e dtypes de entrada do bloco B, então aloca os buffers de B e agenda a transferência antes mesmo do output de A existir. Isso mantém o cliente único fora do caminho crítico: a coordenação acontece em paralelo com o que já roda nos chips, em vez de travar o acelerador entre steps.

O segundo mecanismo é um scheduler central. Em treinamento com pipeline, os dispositivos de um bloco frequentemente têm tanto o forward de um micro-batch novo quanto o backward de um mais antigo prontos para rodar ao mesmo tempo. Se cada dispositivo decidisse sozinho qual executar primeiro, os coletivos entrariam em conflito e o grupo travaria. O Pathways resolve isso colocando as operações de todos os programas numa única ordem consistente, garantindo que operações que precisam se comunicar comecem juntas.

Pathways não é Ray

O post do Google antecipa a comparação óbvia com o Ray, o framework open-source de orquestração de workloads Python em cluster. A diferença é de camada: Ray provisiona o cluster, agenda código Python como tasks e actors, e trata o acelerador como um recurso a escalonar, mas não muda como o treinamento roda dentro de cada worker, que continua sendo SPMD puro, com os coletivos de sempre.

O Pathways atua exatamente nessa camada que o Ray não toca: a execução dentro do step. Os dois são, segundo o próprio post, complementares, não concorrentes. Em tese, dá para usar Ray para orquestrar o pipeline de dados, treino e serving, e Pathways para controlar como cada step de treinamento executa dentro dos chips reservados pelo Ray.

O que muda para quem treina modelo no Brasil

A ressalva mais importante para quem lê isso pensando em aplicar amanhã: Pathways roda programas JAX em TPU, não é um substituto direto de DDP/FSDP para quem já investiu em PyTorch sobre GPU. Isso restringe a adoção a times que já estão (ou cogitam migrar) para JAX e para infraestrutura TPU no Google Cloud, cenário ainda minoritário fora de big techs e labs de pesquisa que publicam em JAX.

Dito isso, o valor prático do anúncio não é só para quem vai usar o Pathways literalmente. O diagnóstico que o post faz do SPMD, coletivos bloqueantes, falha que derruba o cluster inteiro, dificuldade de debug distribuído, é o mesmo gargalo que qualquer equipe rodando FSDP em múltiplos nós de GPU enfrenta hoje. Entender que existe uma alternativa arquitetural (single-controller com grafo de dataflow assíncrono) ajuda a avaliar, por exemplo, se vale a pena investir em soluções do ecossistema JAX/TPU para cargas que combinam treino e RL post-training, onde o pipeline bubble e a espera entre sampler, reward model e trainer custam caro em GPU alugada por hora.

Quem decide entre MaxText (um dos repositórios que o Google lista como recurso complementar ao Pathways) e uma stack PyTorch tradicional ganha agora um terceiro critério além de custo de chip e familiaridade de time: tolerância a falha de hardware em runs longos. Para treinos de dias ou semanas em clusters grandes, a promessa de remapear em torno de um host morto sem reiniciar do zero pesa de verdade; para fine-tuning curto em poucas GPUs, o ganho provavelmente não compensa a curva de aprendizado de migrar de PyTorch para JAX.

O Google publicou junto do anúncio a documentação do Pathways on Google Cloud, o paper acadêmico "Pathways: Asynchronous Distributed Dataflow for ML", a documentação de resilient training e os repositórios pathways-utils e MaxText no GitHub, material suficiente para quem já roda JAX avaliar uma prova de conceito antes de decidir se migra uma carga de treino inteira.

Fonte: Google Developers Blog