The Pulse
OpenAI ripensa lo storage di Habitat per il suo prossimo miliardo di utenti
OpenAI afferma che la sua piattaforma di storage Habitat serve più di 1 miliardo di utenti in 40 regioni e conserva oltre 500 petabyte di dati. L’azienda descrive le modifiche alla configurazione di Azure Cosmos DB, alla cache e al servizio
AI.info Team · Scritto con l’IA · verificato ·
«Nel complesso, queste modifiche hanno ridotto il p50 globale delle letture da circa 120 ms a circa 10 ms: un miglioramento di 12 volte da quando abbiamo iniziato a concentrarci sulle prestazioni in precedenza quest’anno».
Jon Lee, Hrachya Hakobyan e Chaomin Yu, membri del personale tecnico, OpenAI
Habitat, la piattaforma di storage di OpenAI, serve ora più di 1 miliardo di utenti in 40 regioni geografiche e gestisce oltre 500 petabyte di dati, ha dichiarato l’azienda in un articolo pubblicato il 23 ottobre 2026. Il resoconto tecnico si concentra sul livello database alla base di Habitat e sulle modifiche operative apportate da OpenAI durante la sua espansione. La lezione principale: né un unico container di database condiviso né un container separato per ogni carico di lavoro funzionavano bene da soli.
Habitat supporta prodotti tra cui ChatGPT, l’API e Codex. Oltre all’accesso al database, gestisce l’instradamento, la residenza dei dati, la crittografia, l’autorizzazione, i limiti alle richieste e la cache. OpenAI afferma che il suo approccio attuale prevede l’uso predefinito di container Azure Cosmos DB condivisi, insieme a strumenti per isolare i carichi di lavoro e spostare i dati dove necessario.
Perché OpenAI è tornata ai container condivisi
OpenAI ha iniziato con un container Azure Cosmos DB condiviso, poi ha aggiunto container dedicati per i servizi critici o in rapida crescita. I container separati riducevano il rischio che un carico di lavoro interferisse con gli altri, ma trasferivano la pianificazione della capacità ai singoli team di prodotto. I team dovevano prevedere il traffico prima dei lanci; OpenAI afferma che alcune funzionalità sono passate da 1.000 richieste al secondo durante i test di carico a 1 milione al momento del lancio.
La separazione eliminava anche un vantaggio dei sistemi condivisi: la crescita aggregata di molti carichi di lavoro può offrire capacità disponibile a un nuovo servizio che è piccolo nei test ma grande in produzione. Con i container dedicati, i team dovevano predisporre la capacità per ogni carico di lavoro in modo indipendente. OpenAI afferma che i costi operativi aggiuntivi e una pianificazione disomogenea hanno infine spinto l’azienda a tornare verso un’infrastruttura condivisa tra più utenti.
Anche la configurazione condivisa presentava problemi. Una partizione molto utilizzata poteva consumare capacità e influire sugli altri carichi di lavoro, mentre la crescita dei dati archiviati poteva causare la suddivisione delle partizioni fisiche e ridurre la capacità di elaborazione disponibile per ciascuna. OpenAI afferma di aver collaborato con il team Azure di Microsoft a modifiche per affrontare questi limiti, anziché continuare ad aggiungere container e a gestirne separatamente la capacità.
Le modifiche ad Azure puntano a gestire le chiavi più richieste e la pianificazione della capacità
La nuova configurazione combina container condivisi e controlli per isolare i carichi di lavoro. OpenAI descrive l’applicazione di limiti anzitutto alle chiavi del database più richieste, per contenerne l’effetto sul resto del traffico, e l’assegnazione di una priorità inferiore alle operazioni offline, come gli inserimenti in blocco e le estrazioni di dati, affinché le richieste interattive abbiano la precedenza.
Una modalità serverless rivista, realizzata dal team Azure Cosmos DB per OpenAI, consente a ogni partizione fisica di arrivare a 10.000 unità di richiesta al secondo e può suddividere le partizioni in base sia all’utilizzo delle unità di richiesta sia allo spazio di archiviazione. OpenAI afferma che una precedente opzione serverless era limitata a 5.000 unità di richiesta al secondo per partizione e si espandeva solo in base allo spazio di archiviazione. L’azienda afferma di aver poi adottato un unico container condiviso come impostazione predefinita e di non aver registrato, nei mesi precedenti la pubblicazione dell’articolo, incidenti legati alla predisposizione della capacità o all’interferenza tra carichi di lavoro.
Cache e replica riducono la latenza globale delle letture
OpenAI afferma di replicare ampiamente solo dati selezionati per i quali la latenza è critica. I metadati di autenticazione, necessari ai servizi per ogni richiesta, possono essere replicati in tutte le 40 regioni Azure in cui OpenAI serve il traffico; altri account vengono replicati in almeno una regione per continente. L’azienda afferma che i vincoli di capacità le impediscono di applicare questo livello di replica a ogni dataset.
Per altri dati letti di frequente, Habitat usa una cache distribuita basata su server Valkey vicini all’infrastruttura che gestisce le richieste degli utenti. Per mantenere aggiornati i dati nella cache, un servizio acquisisce il flusso delle modifiche di Azure Cosmos DB e propaga le invalidazioni a livello globale entro pochi secondi. Quando un oggetto cambia, la voce di cache interessata viene cancellata e recuperata di nuovo alla lettura successiva.
OpenAI attribuisce la riduzione segnalata della latenza mediana globale delle letture, da circa 120 millisecondi a circa 10, all’insieme di diverse modifiche: la replica di dati selezionati più vicino agli utenti, l’aggiunta di una cache all’interno della regione e la riscrittura del servizio Habitat in Rust. L’articolo non attribuisce l’intero miglioramento a uno solo di questi interventi.
Il prossimo sistema è ancora in fase di sviluppo
OpenAI afferma di stare realizzando internamente un sistema di storage online su scala di exabyte per i dati voluminosi di Habitat e per l’archiviazione delle conversazioni future. Il progetto combina il nucleo di RocksDB Cloud di Rockset con una replica basata su Raft e mantiene il modello a documenti usato da Azure Cosmos DB. OpenAI afferma che la separazione tra storage e calcolo e la replica fisica dovrebbero ridurre il fabbisogno di capacità flash, a fronte di un minor numero di query al secondo nei picchi.
Il sistema è ancora in fase di sviluppo. Per ora, il resoconto pubblicato descrive una piattaforma basata su container di database condivisi, replica selettiva, invalidazione della cache e modifiche a livello di servizio, e riferisce che l’insieme di questi interventi ha portato le letture globali mediane a circa 10 millisecondi.