OpenAI rediseña Git para su propio monorepo
OpenAI construyó Pando, un nuevo backend para repositorios Git, sin interrumpir el trabajo de ingeniería ni cambiar cómo su equipo usa Git. Según la compañía, Pando ya mueve todo el desarrollo de su monorepo, el repositorio central donde conviven sus proyectos y servicios.
El objetivo era doble: lograr escrituras escalables horizontalmente, optimizadas para pushes concurrentes a muchas ramas, y obtener el máximo rendimiento de lectura posible para saturar el ancho de banda disponible. Todo ello manteniendo la compatibilidad con el protocolo y el cliente Git, de modo que el cambio de infraestructura no exigiera cambiar la forma de trabajar de los desarrolladores.
La magnitud del problema: Codex multiplicó la actividad
El impulso para construir Pando llegó con Codex. El uso de agentes de programación disparó el número de ramas, pushes, fusiones, fetches y clones en paralelo, una carga muy distinta a la de un flujo de trabajo tradicional basado en humanos.
Hacia finales del año pasado, la fiabilidad de la infraestructura Git de OpenAI llegó a caer por debajo del 90%, con fetches y pushes lentos y fusiones fallidas. En ese contexto, la compañía decidió construir un sistema pensado desde el principio para la escala de los agentes, en lugar de seguir parcheando el anterior.
Resultados en producción, según OpenAI
En producción, Pando recortó la latencia mediana de push casi 5 veces, una reducción de casi el 80% según otro punto del artículo publicado por OpenAI. Además, el sistema entrega casi un petabyte de datos Git al día.
En un pico concreto, Pando sirvió más de 57 terabytes de packs Git en una sola hora, con más del 99% de esos bytes procedentes de la caché local de disco. Es una muestra de hasta qué punto el rendimiento depende tanto de la arquitectura de escritura como de la eficiencia de lectura.
Cómo funciona Pando por dentro
Pando coordina las actualizaciones de cada rama de forma independiente, en lugar de tratar el repositorio como un bloque único que debe actualizarse de golpe. Ese diseño permite escalar las escrituras horizontalmente y absorber pushes concurrentes a muchas ramas sin que unas bloqueen a otras.
Otra decisión clave es la reutilización de packfiles entre fetches: en lugar de generar un pack nuevo para cada cliente, Pando reutiliza los packs ya construidos cuando es posible. El resultado es menos trabajo repetido y una lectura más eficiente.
El sistema usa consistencia causal, no una instantánea global de todas las referencias. Es decir, garantiza un orden causal coherente entre las actualizaciones relacionadas, sin imponer el coste de congelar todas las refs en un único estado global.
Push validado durante la transmisión y costes acotados
En Pando, el push se valida mientras se transmite al almacén de blobs, sin necesidad de desempaquetarlo en un repositorio local. Esa validación en streaming evita un paso intermedio costoso y acelera el camino de escritura.
En términos de coste, la escritura requiere O(1) lecturas y escrituras de metadatos, mientras que el fetch escala como O(log Δ), donde Δ es la distancia más corta en versiones de referencia entre lo que el cliente tiene y lo que quiere. Es un diseño pensado para que el coste no crezca de forma descontrolada a medida que el repositorio y la actividad crecen.
Packfile-uri, Express y cachés regionales
Pando usa packfile-uri para devolver enlaces a packs adicionales, en lugar de enviar todos los datos por el mismo canal. El servicio Express y las cachés regionales completan el diseño de lectura, con más del 99% de aciertos en caché.
Para validar el rendimiento, OpenAI probó clones y fetches saturando enlaces de 10 Gbps con máquinas virtuales estándar en la nube. El objetivo era demostrar que el sistema puede aprovechar todo el ancho de banda disponible sin hardware especializado.
Compactación estilo LSM-tree, de L0 a L4
Como en muchos sistemas de almacenamiento, los packs se acumulan con el tiempo y necesitan compactarse. En Pando, la compactación agrupa packs L0 en coberturas hasta L4, con un enfoque estilo LSM-tree.
Esa organización por niveles permite mantener la lectura eficiente a medida que se generan nuevos packs, sin que la fragmentación degrade el rendimiento con el paso del tiempo.
Construido con Codex en 10 semanas y en Rust
Pando se construyó con Codex en 10 semanas. El núcleo fue diseñado por un solo ingeniero, implementado por equipos de agentes y desplegado por un puñado de ingenieros, un ejemplo del propio modelo de desarrollo que el sistema debía soportar.
El sistema empezó a servir tráfico de producción en abril de este año y está implementado en Rust, sin dependencias heredadas. Además, OpenAI contribuyó mejoras de packfile-uri al proyecto Git, devolviendo al ecosistema parte del trabajo realizado.
Qué significa Pando para equipos que usan Git a escala
Pando no es un nuevo cliente ni un cambio en el flujo de trabajo de Git: es un backend que mantiene la compatibilidad con el protocolo y el cliente existentes, mientras rediseña por dentro cómo se escriben, se leen y se sirven los repositorios.
Para OpenAI, el resultado es un sistema que absorbe la carga concurrente de Codex, reduce la latencia de push de forma drástica y entrega volúmenes masivos de datos Git al día, con una arquitectura que puede seguir escalando horizontalmente.
OpenAI en contexto
OpenAI es la empresa detrás de ChatGPT y Codex, y con Pando también distribuye su propia versión pública de Git en las máquinas de sus desarrolladores y dentro de la aplicación de escritorio de ChatGPT, según su propio artículo.
