OpenAI a levé le voile sur Habitat, la plateforme de stockage en ligne qui alimente ChatGPT, Codex et ses autres produits. Le système traite désormais plus de 70 millions de requêtes par seconde, répartit plus de 500 pétaoctets de données sur près de 40 régions et dessert des services utilisés par plus d’un milliard de personnes chaque semaine.
Habitat ne stocke pas les modèles eux-mêmes. Il fournit aux produits d’OpenAI un accès rapide aux informations nécessaires à chaque interaction, comme l’authentification, les réglages de Codex ou les données d’une conversation. Une seule action visible par l’utilisateur peut déclencher des centaines de lectures en base, ce qui rend la latence et la disponibilité de cette couche particulièrement sensibles.
D’une bibliothèque Python à un service distribué
La première version de Habitat a été créée pour le lancement des GPTs lors du DevDay 2023. Elle prenait la forme d’une bibliothèque Python reliée à une seule base de données. Ce composant masquait aux équipes produit le routage, les autorisations, le chiffrement, la sérialisation et la gestion des connexions vers Azure Cosmos DB ou les caches.
Cette approche a toutefois atteint ses limites au milieu de 2025. Chaque évolution du protocole imposait alors de coordonner le déploiement d’une nouvelle version du client dans des dizaines de services. Un retour en arrière sur l’un d’entre eux pouvait même réintroduire un défaut déjà corrigé. OpenAI a donc transformé Habitat en service autonome afin de centraliser les déploiements, l’observabilité, les politiques d’accès et les améliorations de la plateforme.
La croissance annoncée est rapide : OpenAI affirme que la charge de Habitat a été multipliée par plus de dix chaque année pendant trois ans. L’entreprise a néanmoins conservé Python pour stabiliser rapidement ses interfaces, tout en acceptant un coût supérieur en processeur et en mémoire avant une migration ultérieure.
Les limites de Python observées à grande échelle
Le principal problème décrit par les ingénieurs concerne les délais de l’event loop asyncio. Habitat combine des opérations réseau avec des tâches gourmandes en calcul, notamment le routage, la compression, le chiffrement, les sommes de contrôle et la surveillance des dépendances. À forte charge, une coroutine pouvait attendre plusieurs centaines de millisecondes, voire plusieurs secondes dans certains cas, avant de reprendre son exécution.
OpenAI a réduit cette latence en limitant le nombre de requêtes simultanées par processus et en multipliant les processus Python. L’équipe a aussi isolé un ralentissement périodique provoqué par l’analyse simultanée de gros fichiers de configuration. Des configurations plus ciblées, des intervalles plus longs et un décalage aléatoire des tâches ont corrigé ce pic.
Un autre incident provenait de la réutilisation LIFO des connexions par aiohttp. Après une pointe de trafic, les connexions vers les serveurs les plus lents étaient réutilisées en priorité, concentrant davantage de charge sur eux. Le passage à une logique FIFO a cassé cette boucle, tandis qu’Istio et Envoy assurent désormais l’essentiel du regroupement des connexions et de l’équilibrage.
Une interface volontairement limitée
Habitat expose une API NoSQL contrainte, plutôt que des requêtes SQL libres. OpenAI privilégie ainsi des opérations simples dont le coût reste prévisible. Les analyses complexes sont déportées vers des vues secondaires alimentées en quasi-temps réel, afin qu’une requête lourde ne puisse pas dégrader le stockage utilisé par les produits en ligne.
Cette publication constitue la première partie du retour d’expérience d’OpenAI. Une seconde doit détailler l’isolation entre clients, les optimisations de lecture et la montée en charge avec Azure Cosmos DB. Elle doit aussi éclairer la réécriture en Rust évoquée par l’entreprise, rendue possible selon elle par ses propres outils de programmation assistée.
