OpenAI verlaagt p50-leeslatency in Habitat van 120 naar 10 ms

OpenAI meldt op 23 oktober dat zijn opslagplatform Habitat de wereldwijde p50-leeslatency terugbrengt van circa 120 naar 10 milliseconden met regionale replicatie, caching en een herschrijving in Rust.

Een databaseaanroep op een klantgericht scherm kost tijd; aparte containers vragen teams om piekcapaciteit vooraf te reserveren. Voor een snelgroeiend Nederlands softwareproduct raken latency, foutisolatie en capaciteit direct aan productkeuzes. Deze p50-meting geldt voor Habitat, niet als algemene Cosmos DB-benchmark.

OpenAI keerde terug naar gedeelde containers

Habitat is de opslaglaag achter ChatGPT, Codex, de API en interne diensten. OpenAI zegt dat het meer dan 500 petabyte aan data bedient voor meer dan een miljard gebruikers in veertig regio’s. Het grootste Cosmos DB-account omvat volgens OpenAI tientallen petabytes en verwerkt meer dan twintig miljoen verzoeken per seconde. Het bedrijf zegt voor zover bekend de enige klant te zijn die Cosmos DB op die schaal inzet.

In juli meldde OpenAI meer dan een miljard actieve gebruikers en twee miljoen bedrijven voor zijn modellen. De opslagpost specificeert geen identieke gebruikersmaat, dus de miljarden zijn niet rechtstreeks vergelijkbaar.

OpenAI begon met één gedeelde Cosmos DB-container, zette daarna nieuwe of kritieke toepassingen in aparte containers en keerde terug naar gedeeld gebruik als standaard. Delen houdt beheer en capaciteit bij elkaar, maar een piek kan andere toepassingen verdringen. Aparte containers begrenzen de gevolgen van een storing, maar vragen elk om eigen planning.

Betrouwbaarheid speelde ook in de voorgeschiedenis. Een stroomuitval in een primaire regio eind 2024 liet zien dat de grootste accounts uren nodig konden hebben om naar een tweede regio over te schakelen. Een maand later overbelastte een verbindingsgolf bij het terugschakelen de oorspronkelijke gateway. OpenAI en Azure delen sindsdien tests, dashboards en operationele verantwoordelijkheid.

Capaciteitsplanning verschoof naar productteams

Isolatie maakte pieken moeilijker voorspelbaar. In een gedeelde container kon een nieuwe toepassing groeien van nul naar een miljoen verzoeken per seconde zonder het totale volume sterk te veranderen. In een eigen container kon dezelfde sprong een duizendvoudige stijging zijn ten opzichte van het interne testgebruik. OpenAI schrijft dat teams geregeld vergaten vóór een lancering capaciteit bij te schalen en dat engineers dan op de lanceringsdag alsnog moesten ingrijpen.

OpenAI keerde met Azure terug naar gedeelde containers en voegde maatregelen tegen die pieken toe. De opslaglaag remt de heetste sleutels eerst af, zodat één sleutel niet alle capaciteit van een partitie gebruikt. Prioriteitsregels geven batchwerk, zoals grote invoeracties of data-extracties, een lagere prioriteit dan interactieve verzoeken. Opslaggroei kon partities splitsen en zo de beschikbare capaciteit per partitie verlagen, ook als het verkeer gelijk bleef. Een aangepaste serverloze modus verhoogde de capaciteit per fysieke partitie van 5.000 naar 10.000 request units per seconde (RU/s) en laat partities ook splitsen op basis van verbruik, niet alleen opslag. OpenAI meldt dat er sindsdien maandenlang geen incidenten waren door capaciteitsinstellingen of een toepassing die andere werklasten verdrong.

Caching verlaagt de mediane leestijd

Meer dan 90 procent van Habitat-verzoeken zijn leesverzoeken. OpenAI plaatst daarom alleen de kleinste, meest tijdkritische gegevens breed in regio’s dicht bij gebruikers. Sommige Cosmos DB-accounts repliceren naar alle veertig regio’s; andere naar minstens één Azure-regio per continent. Opslag, stroom en koeling beperken die spreiding.

Andere gegevens gaan via een verdeelde Valkey-cache dicht bij verzoeken. Lange bewaartermijnen kunnen verouderde data tonen; korte termijnen vragen vaker om een nieuwe opvraag. Habitat gebruikt change data capture, een stroom met databasewijzigingen, uit de Cosmos DB-change feed om caches wereldwijd binnen seconden ongeldig te maken na een update. Bij een volgende opvraag haalt de cache de nieuwste waarde op. OpenAI herschreef delen van de Python-service in Rust om extra verwerking in de tussenlaag te verminderen.

OpenAI zegt dat die ingrepen de wereldwijde p50-leeslatency vroeg in 2026 van circa 120 naar 10 milliseconden brachten, een daling met factor twaalf. P50 is de mediaan: de helft van de leesverzoeken duurt korter, de helft langer. De traagste verzoeken halen nog ongecachete data op, soms uit een verre regio. De meting geldt voor leesverzoeken via Habitat, niet voor elke applicatierespons of Cosmos DB-klant.

De cijfers hebben een smalle scope

Microsoft beschrijft Azure Cosmos DB als een dienst die data over gekozen regio’s repliceert en lokale leesverzoeken mogelijk maakt. De documentatie noemt lees- en schrijfverzoeken onder 10 milliseconden op het 99e percentiel voor accounts die vanuit meerdere regio’s kunnen schrijven. Dat is een andere configuratie en percentielmaat dan Habitat’s wereldwijde p50. Het is geen algemene Cosmos DB-prestatiebelofte.

Voor de volgende miljard gebruikers bouwt OpenAI een eigen online opslagsysteem op exabyteschaal, oftewel duizend petabytes. Het systeem is in ontwikkeling en combineert de RocksDB Cloud-kern van Rockset met Raft-replicatie, een protocol dat wijzigingen tussen kopieën afstemt. Het gebruikt hetzelfde documentmodel als Cosmos DB, maar scheidt opslag en verwerking en repliceert data fysiek om flashcapaciteit te besparen. Dat gaat volgens OpenAI ten koste van een lager maximaal aantal verzoeken per seconde. FourWeekMBA meldt dat zijn analyse op OpenAI’s engineeringposts rust en niet onafhankelijk is gecontroleerd; de publicaties geven geen lanceringsdatum, kosten of migratieplan voor het nieuwe systeem.

De wisseling tussen gedeelde opslag en aparte containers verbindt latency met capaciteitsplanning en isolatie. Fysieke datacenterruimte en stroom bepalen mede waar data dichtbij kan staan, een beperking die ook in Nederland speelt: vergunningstrajecten duren gemiddeld 4,5 jaar en een netaansluiting kan tot tien jaar vragen. OpenAI’s eigen opslagontwerp accepteert lagere pieksnelheid in ruil voor minder flashcapaciteit, maar publiceert nog geen kosten of planning. De afweging tussen snelheid, opslagdichtheid en operationele ruimte hangt af van de werkbelasting.