OpenAI presenta Pando : un backend Git che riduce di circa l’80% la latenza mediana dei push

OpenAI presenta Pando : un backend Git che riduce di circa l’80% la latenza mediana dei push
3 min di lettura

OpenAI ha presentato Pando, un nuovo backend Git che ora gestisce l’intero sviluppo nel suo monorepo, ovvero un unico repository di codice. Il client Git e il protocollo rimangono invariati: ingegneri e agenti Codex continuano a eseguire i comandi git push e git fetch come prima, è cambiato solo il server. Secondo l’azienda, la latenza mediana degli invii di codice (push) è diminuita di quasi l’80%.

  • OpenAI presenta Pando, un nuovo backend Git che gestisce il suo monorepo senza modificare client e protocollo.
  • Secondo l’azienda, la latenza mediana dei push è diminuita di quasi l’80%.
  • Pando usa coerenza causale per ramo e pacchetti immutabili messi in cache, eliminando la garbage collection tradizionale.
  • Le cifre sono auto-dichiarate, Pando non è open source e nessun benchmark indipendente è ancora disponibile.

Perché OpenAI ha cambiato backend

Gli agenti Codex hanno moltiplicato i lavori svolti in parallelo. Secondo il grafico dei commit pubblicato da OpenAI, i commit sul ramo master sono aumentati del 1.378% nel terzo trimestre 2026 rispetto al primo trimestre 2024, e la stima per il quarto trimestre 2026 raggiunge il +2.442%. Ogni invio ora innesca numerosi recuperi di codice da parte degli strumenti di integrazione continua. Alla fine del 2025, i recuperi e gli invii rallentavano, alcune fusioni fallivano e l’affidabilità è talvolta scesa sotto il 90%. L’azienda ha concluso che il collo di bottiglia derivava dal modo in cui serviva Git, e non da Git stesso.

Come funziona Pando

Secondo il post di ingegneria pubblicato da OpenAI, Pando scarta due ipotesi che la maggior parte dei server Git considera imprescindibili. La prima riguarda la coerenza a livello di repository: i server classici ordinano ogni aggiornamento di riferimento per l’intero repository, cosicché invii non correlati tra loro devono attendere. Pando adotta una coerenza causale, dove ogni ramo viene trattato separatamente e i client entrano in conflitto solo quando inviano lo stesso riferimento. Il compromesso è che un lettore che consulta più rami può vederli in momenti diversi.

La seconda ipotesi riguarda la generazione di un pacchetto distinto per ogni client. I server standard ne creano uno nuovo a ogni recupero, mentre Pando memorizza ogni pacchetto inviato come blob immutabile e registra una « versione di riferimento » in un archivio di metadati estensibile. Un invio richiede un numero costante di letture e scritture di metadati, mentre un recupero ne richiede un numero proporzionale al logaritmo del divario di versioni da colmare. Per limitare la dimensione degli invii, solo il ramo principale viene annunciato come base per i nuovi rami. Nel monorepo di OpenAI, il pacchetto mediano pesa meno di 20 KiB.

I pacchetti vengono poi distribuiti tramite packfile-uri, una funzionalità esistente del protocollo Git, e un servizio di consegna chiamato Express li memorizza nella cache per regione, con un tasso di successo superiore al 99%. Ogni invio crea un pacchetto « L0 » che processi in background raggruppano in pacchetti sempre più grandi, fino al livello L4 per l’attuale monorepo. Questo meccanismo sostituisce la tradizionale garbage collection di Git.

Cifre auto-dichiarate

OpenAI indica che Pando elabora quasi un petabyte di dati Git al giorno con solo pochi core di CPU e che ha servito oltre 57 TB di pacchetti in una sola ora, di cui più del 99% dalla cache del disco locale. Su macchine virtuali cloud standard, cloni e recuperi saturano collegamenti da 10 Gbit/s. L’azienda ha anche condotto test con diverse migliaia di mittenti simultanei, senza degradazione secondo quanto riferito. Tutte queste cifre sono auto-dichiarate e nessun benchmark indipendente è stato ancora pubblicato.

Pando non è open source e OpenAI indica di esplorare modi per condividere la tecnologia. Le letture che coinvolgono più rami non hanno un’istantanea unica del repository in un dato momento, e gli invii ripetuti di rami impilati restituiscono tutto il contenuto situato al di fuori del ramo principale. Le correzioni apportate al client Git sono state inviate upstream, mentre il backend rimane interno per ora.

S’abonner
Notification pour
guest

0 Commentaires
Le plus ancien
Le plus récent Le plus populaire
0
Nous aimerions avoir votre avis, veuillez laisser un commentaire.x