OpenAI criou o Pando, um backend Git que tornou os pushes 5 vezes mais rapidos sob a carga do Codex

Imagine que cada engenheiro de uma empresa receba de repente uma duzia de assistentes, e que cada um deles faca push de codigo, abra branches e execute CI. Foi exatamente isso que aconteceu na OpenAI quando o Codex comecou a escrever codigo em grande escala. O gargalo do monorepositorio deixou de ser as pessoas e passou a ser o proprio servidor Git.

O que quebrou

Desde o fim do ano passado, os sistemas ao redor do monorepo deixaram de dar conta: fetches e pushes lentos, merges com falha e confiabilidade as vezes abaixo de 90%. A carga cresce de forma multiplicativa: um engenheiro mantem varias alteracoes em CI, e cada push inicia varios jobs que buscam o mesmo commit.

Os engenheiros nao abandonaram o Git. Eles decidiram manter o protocolo e o cliente para que pessoas e agentes nao precisassem reaprender nada e para que as melhorias pudessem ser enviadas upstream. Apenas o backend foi substituido, sem interrupcao do servico. Assim surgiu o Pando.

Por que nao 3PC nem WAL

As abordagens classicas para escalar o Git esbarram em um unico ponto de coordenacao.

A primeira opcao envolve replicas completas e commit em tres fases. Cada push exige varias rodadas de comunicacao entre o coordenador e as replicas, enquanto os discos e as redes das replicas entram no caminho critico de escrita. Os refs sao atualizados um de cada vez.

A segunda opcao e um manifesto compartilhado em um armazenamento de blobs com um log de escrita antecipada. Os packs sao enviados em paralelo, mas cada atualizacao ainda modifica um unico manifesto por meio de compare-and-swap. Pushes para branches nao relacionadas disputam recursos entre si. O processamento em lotes ajuda, mas adiciona latencia.

Como o Pando funciona

Seus autores abandonaram duas premissas convencionais.

Primeira: a consistencia de todo o repositorio. O Pando armazena o packfile recebido como um blob imutavel e coloca seus metadados —a nova ponta da branch, o pack e as dependencias de versoes anteriores do ref— em um armazenamento horizontalmente escalavel. Cada branch e atualizada de forma independente, com serializabilidade dentro de um unico ref. Isso oferece consistencia causal: o leitor ve o historico de quem gravou o ref, mas nao uma unica fotografia de todo o repositorio.

Na pratica, isso significa que, durante a clonagem enquanto as branches foo e bar estao sendo atualizadas, um cliente pode ver foo na versao 1 e bar na versao 2, enquanto outro pode ver o contrario. Os autores afirmam que, para pessoas e agentes, o que importa e a ordem das atualizacoes dentro de uma branch, nao uma ordem global.

Segunda: um pack exclusivo para cada cliente. Normalmente, o servidor monta um pacote especifico para cada cliente a fim de evitar o envio de dados desnecessarios, o que consome CPU e disco. O Pando reutiliza packfiles: o cliente pode baixar alguns objetos que ja possui, mas o servidor fornece os mesmos bytes a muitos clientes praticamente sem processamento. O objetivo nas leituras e saturar toda a largura de banda de rede disponivel para o cliente.

Resultados e limitacoes

Em producao, a latencia mediana de push caiu quase 5 vezes, e o Pando fornece quase um petabyte de dados por dia. O preco e claro: nao ha uma fotografia global de todos os refs, e clientes que ja possuem parte dos objetos recebem trafego adicional.

O artigo tambem inclui uma simulacao com 1.000 clientes comparando tres modelos, mas os autores baseiam suas comparacoes de implementacoes em modelos, e nao em benchmarks independentes. O codigo do Pando nao foi publicado; em vez disso, a OpenAI promete aprimorar o cliente Git upstream.

O que fazer a respeito

Se seus agentes criam muitas branches e pushes paralelos, o gargalo pode em breve estar na hospedagem Git, e nao no modelo. Verifique quais processos realmente exigem uma fotografia globalmente consistente do repositorio e quais precisam apenas de ordenacao dentro de uma unica branch. Tambem vale a pena medir a latencia push-to-fetch: e essa metrica que mostra quanto tempo um agente espera ate que outro agente ou o CI veja seu commit. E acompanhe as melhorias upstream do Git: elas provavelmente chegarao a todos.