OpenAI centralise Habitat : 70 M req/s et 500 Po pour ChatGPT

OpenAI a extrait Habitat, sa couche d’accès aux données, en un service centralisé pour fiabiliser les déploiements et renforcer les contrôles d’accès. La plateforme porte désormais plus de 70 millions de requêtes par seconde et gère plus de 500 pétaoctets, au service d’un milliard d’utilisateurs hebdomadaires, tout en assumant temporairement les limites de Python à très haut débit.

Un service unique pour la sécurité, l’audit et la résilience

OpenAI a transformé Habitat en service autonome afin de réduire la dispersion opérationnelle des déploiements et disposer d’un point de contrôle unique pour les mises à jour et l’observabilité. Cette centralisation permet d’appliquer les politiques de contrôle d’accès, d’exécuter des journaux d’audit et de limiter l’exposition aux ressources de stockage comme Azure Cosmos DB. Habitat joue ainsi un rôle critique dans la protection des données et la prévention d’accès non autorisés, qu’ils proviennent d’acteurs externes, internes ou d’agents. Cette évolution répond aussi à des enjeux de résilience : la volonté de répartir des ensembles de données critiques sur des comptes Azure Cosmos DB par région a mis en évidence la lourdeur d’un déploiement coordonné derrière un drapeau de fonctionnalité. Entre déploiements étalés sur plusieurs jours, introduction de shadowing pour valider le partitionnement, correctifs successifs et le retour arrière d’une équipe qui a déclenché la panne redoutée, la coordination via une bibliothèque cliente s’est révélée fragile et coûteuse. Le service centralisé vise à éliminer ces points de défaillance organisationnels.

Une couche de données dimensionnée au milliard d’utilisateurs

Habitat traite plus de 70 millions de requêtes par seconde pour des produits utilisés par plus d’un milliard de personnes chaque semaine et opérant dans près de 40 régions. Le système distribué gère désormais plus de 500 pétaoctets de données. Ces chiffres montrent l’échelle à laquelle la plateforme d’accès aux données est exploitée quotidiennement.

Des choix techniques assumés autour de Python

OpenAI a choisi de lancer Habitat comme service sans quitter immédiatement Python, malgré une latence réseau accrue et des coûts CPU et mémoire supérieurs à une bibliothèque locale. Les limites attendues de Python à 100 fois l’échelle rendaient probable une réécriture ultérieure, un compromis présenté comme une dette technique assumée pour prioriser la stabilité de plateforme et l’agilité des équipes. L’établissement des API de base et d’une infrastructure robuste a été jugé prioritaire, en misant sur les progrès rapides de ses modèles de codage. Le pari que Codex et GPT faciliteraient une migration ultérieure s’est confirmé. Même si exécuter Habitat en Python reste sous-optimal en performances, l’objectif était de contenir les latences de fin de file, cruciales lorsque des centaines d’appels à la base de données peuvent composer une requête utilisateur et que le plus lent dicte la perception du service.

Abstraire la complexité des bases pour les équipes produit

Dès l’origine, Habitat visait à décharger les ingénieurs produits de la gestion des bases : à la mi-2024, une petite bibliothèque Python reliée au serveur principal de ChatGPT traduisait un jeu d’opérations vers Azure Cosmos DB. La couche identifiait les types de données, leur source et vérifiait les autorisations, tout en prenant en charge la recherche de schéma, le routage, le chiffrement, la sérialisation, la mise en forme des requêtes et les connexions, indépendamment que les données proviennent d’Azure Cosmos DB, de caches ou d’autres stockages. Dans des produits où la connexion, la vérification de paramètres ou l’ouverture d’un chat déclenchent de multiples consultations de données, cette abstraction limite l’impact des lenteurs et des échecs qui, sinon, se répercuteraient immédiatement côté utilisateur. Deux ans après ses débuts comme simple bibliothèque reliée à une base unique, Habitat a évolué vers une architecture distribuée.