OpenAI creo Pando, un backend de Git que acelero los push 5 veces bajo la carga de Codex

Imagine que cada ingeniero de una empresa recibe de pronto una docena de asistentes y que cada uno hace push de codigo, abre ramas y ejecuta CI. Eso es exactamente lo que ocurrio en OpenAI cuando Codex empezo a escribir codigo a gran escala. El cuello de botella del monorepositorio dejo de estar en las personas y paso al propio servidor Git.

Que se rompio

Desde finales del ano pasado, los sistemas que rodeaban al monorepo dejaron de dar abasto: fetch y push lentos, merges fallidos y una fiabilidad que a veces bajaba del 90%. La carga crece de forma multiplicativa: un ingeniero mantiene varios cambios en CI y cada push inicia varios jobs que descargan el mismo commit.

Los ingenieros no renunciaron a Git. Decidieron conservar el protocolo y el cliente para que personas y agentes no tuvieran que reaprender nada y para poder aportar las mejoras upstream. Solo sustituyeron el backend, y lo hicieron sin interrumpir el servicio. Asi nacio Pando.

Por que no 3PC ni WAL

Las formas clasicas de escalar Git terminan chocando con un unico punto de coordinacion.

La primera opcion consiste en replicas completas y commit en tres fases. Cada push requiere varias rondas de comunicacion entre el coordinador y las replicas, y los discos y las redes de las replicas entran en la ruta critica de escritura. Los refs se actualizan uno por uno.

La segunda opcion consiste en un manifiesto compartido en almacenamiento de blobs con un registro de escritura anticipada. Los packs se cargan en paralelo, pero cada actualizacion sigue modificando un unico manifiesto mediante compare-and-swap. Los push a ramas no relacionadas compiten entre si. El procesamiento por lotes ayuda, pero anade latencia.

Como funciona Pando

Sus autores abandonaron dos supuestos habituales.

Primero: la consistencia de todo el repositorio. Pando guarda el packfile entrante como un blob inmutable y almacena sus metadatos —el nuevo extremo de la rama, el pack y las dependencias respecto a versiones anteriores del ref— en un sistema escalable horizontalmente. Cada rama se actualiza de forma independiente, con serializabilidad dentro de un unico ref. Esto proporciona consistencia causal: el lector ve el historial de quien escribio el ref, pero no una instantanea unica de todo el repositorio.

En la practica, esto significa que, si las ramas foo y bar se actualizan durante una clonacion, un cliente puede ver foo en la version 1 y bar en la version 2, mientras que otro puede ver lo contrario. Los autores sostienen que a las personas y a los agentes les importa el orden de las actualizaciones dentro de una rama, no un orden global.

Segundo: un pack unico para cada cliente. Normalmente, un servidor crea un paquete especifico para cada cliente con el fin de no enviar datos innecesarios, lo que consume CPU y disco. Pando reutiliza los packfiles: el cliente puede descargar algunos objetos que ya posee, pero el servidor entrega los mismos bytes a muchos clientes casi sin computacion. El objetivo en lectura es saturar todo el ancho de banda de red disponible para el cliente.

Resultados y limitaciones

En produccion, la latencia mediana de push se redujo casi 5 veces y Pando sirve casi un petabyte de datos al dia. El coste es evidente: no existe una instantanea global de todos los refs y los clientes que ya tienen parte de los objetos reciben trafico adicional.

El articulo tambien incluye una simulacion con 1.000 clientes que compara tres modelos, pero los autores basan sus comparaciones de implementaciones en modelos, no en benchmarks independientes. El codigo de Pando no se ha publicado; en su lugar, OpenAI promete mejorar el cliente Git upstream.

Que hacer al respecto

Si sus agentes crean muchas ramas y push en paralelo, el cuello de botella pronto puede estar en el alojamiento de Git y no en el modelo. Compruebe que procesos necesitan realmente una instantanea globalmente consistente del repositorio y para cuales basta con mantener el orden dentro de una sola rama. Tambien conviene medir la latencia push-to-fetch: esta metrica muestra cuanto espera un agente hasta que otro agente o CI ve su commit. Y siga las mejoras upstream de Git: probablemente terminaran llegando a todos.