Le milliard d’utilisateurs se joue aussi dans le stockage
La nouvelle annonce technique d’OpenAI ne concerne ni un modèle inédit, ni une fonction spectaculaire de ChatGPT. Elle porte sur Habitat, la plateforme de stockage en ligne qui permet aux produits d’OpenAI d’accéder rapidement aux données dont ils ont besoin. Selon l’entreprise, Habitat doit désormais répondre en quelques millisecondes pour plus d’un milliard d’utilisateurs répartis dans 40 régions géographiques, tout en soutenant une plateforme qui stocke plus de 500 pétaoctets de données .
C’est précisément ce qui rend cette publication intéressante. Derrière l’interface familière d’un chatbot, il faut maintenir de l’état personnalisé, de la métadonnée d’authentification, des règles d’autorisation, du routage, de la résidence des données, du cache, de la limitation de débit et des lectures de base de données. Avant même que le modèle ne commence à produire une réponse, toute une chaîne d’infrastructure doit trouver les bonnes données, au bon endroit, avec une latence suffisamment basse .
Le chiffre le plus frappant est la baisse de latence. OpenAI affirme que la latence médiane mondiale de lecture, mesurée au p50, est passée d’environ 120 millisecondes à environ 10 millisecondes après les travaux d’optimisation menés cette année, soit une amélioration de 12 fois . Plusieurs reprises de l’annonce ont toutefois rappelé une nuance importante: il s’agit d’une amélioration des lectures de stockage, pas d’une preuve que l’expérience complète de ChatGPT serait devenue douze fois plus rapide dans tous les cas .
Pourquoi Habitat a dû changer
Habitat est présenté par OpenAI comme une plateforme de stockage en ligne pour ses produits, notamment ChatGPT, l’API, Codex et des services internes. Dans l’architecture décrite, Habitat ne se contente pas d’appeler une base de données. Il prend aussi en charge le cache, les politiques d’accès, la résidence des données, le chiffrement, l’isolation entre charges de travail, la limitation de débit et le routage vers différentes ressources de stockage, dont Azure Cosmos DB .
L’évolution racontée par OpenAI est instructive, car elle ressemble à un aller-retour. Au départ, l’entreprise utilisait un conteneur Azure Cosmos DB partagé. Ce modèle rendait le lancement de nouveaux usages plus simple, car plusieurs équipes internes pouvaient profiter d’une capacité commune. Mais il exposait aussi la plateforme aux problèmes classiques de la mutualisation: clés très sollicitées, voisins bruyants, collisions logiques et effets de partition pouvant faire peser une charge sur d’autres usages .
OpenAI est ensuite passé vers davantage de conteneurs dédiés, en particulier pour des charges critiques ou à forte croissance. Cette approche isolait mieux les équipes, mais elle déplaçait le problème vers la planification de capacité. Chaque équipe devait anticiper son trafic, ses pics et ses lancements, ce qui devient difficile quand un produit interne peut passer très vite d’un test limité à une utilisation massive .
La solution actuelle consiste à revenir à des conteneurs partagés par défaut, mais avec davantage de mécanismes d’isolation et une collaboration plus profonde avec Azure. OpenAI affirme que ce modèle simplifie la planification pour les équipes produit tout en maintenant l’isolation, et dit ne pas avoir observé d’incident de provisionnement ou de voisin bruyant depuis plusieurs mois . Data Phoenix a justement souligné que cette affirmation reste déclarative et n’a pas été auditée de manière indépendante .
Cosmos DB au centre du récit
Cette publication est aussi une vitrine puissante pour Azure Cosmos DB. OpenAI affirme être devenu l’un des plus grands utilisateurs de Cosmos DB, avec un plus gros compte stockant des dizaines de pétaoctets et servant plus de 20 millions de requêtes par seconde . AI Chat Daily a repris ces chiffres comme l’un des faits clés de l’annonce, en présentant Habitat comme un cas extrême d’utilisation de Cosmos DB pour un produit d’IA grand public .
Mais le récit n’est pas simplement celui d’un service managé qui aurait tout absorbé sans friction. La leçon d’OpenAI est presque inverse: à cette échelle, un service managé cesse d’être “managé” au sens habituel du terme. OpenAI dit travailler avec Azure au moyen de tableaux de bord communs, de tests partagés, de canaux directs entre ingénieurs, d’essais sur des comptes non productifs de taille comparable à la production, de travail conjoint sur les SDK et d’une responsabilité partagée sur des modes de panne rares .
L’entreprise explique que des incidents passés ont rendu cette coopération nécessaire. Une panne régionale fin 2024 aurait montré que certains très grands comptes Cosmos DB pouvaient nécessiter plusieurs heures pour basculer vers une région secondaire. Puis, environ un mois plus tard, une opération de retour vers la région d’origine aurait provoqué une ruée de connexions surchargeant la passerelle de cette région . L’idée centrale n’est donc pas que Cosmos DB aurait échoué, mais qu’un usage à l’échelle d’OpenAI exige une co-ingénierie bien plus profonde que ce que suggère habituellement l’expression “base de données managée” .
Les trois leviers de la baisse de latence
OpenAI n’attribue pas le gain de 12 fois à une seule optimisation. Le premier levier est la réplication sélective des données les plus petites et les plus sensibles à la latence. Les métadonnées d’authentification, par exemple, peuvent être nécessaires à chaque requête. OpenAI indique donc que certains comptes répliquent ces données dans les 40 régions où le trafic est servi, tandis que d’autres maintiennent au moins une copie par continent .
Le deuxième levier est le cache régional. Pour les données qu’il n’est pas réaliste de répliquer massivement partout, Habitat place un cache distribué Valkey près de l’infrastructure qui sert les requêtes. En cas de cache miss, le système lit dans la base de données sous-jacente puis remplit le cache local pour les lectures suivantes . Pour éviter de servir trop longtemps des données obsolètes, Habitat consomme le change feed d’Azure Cosmos DB et propage des invalidations dans le monde en quelques secondes, de sorte qu’une donnée modifiée est retirée du cache puis relue à la demande suivante .
Le troisième levier est la réduction du coût du service lui-même. OpenAI explique avoir réécrit en Rust une partie du service Habitat, afin de réduire l’overhead par rapport au chemin historique en Python . AI.info résume ainsi le point essentiel: la baisse de latence combine des données placées plus près des utilisateurs, du cache en région et une couche de service plus performante, plutôt qu’une optimisation unique .
La mutualisation devient un enjeu de vitesse produit
L’un des aspects les plus intéressants de l’annonce est la manière dont OpenAI relie l’architecture de stockage à la vitesse de développement produit. Des conteneurs dédiés peuvent sembler plus sûrs, car ils isolent les charges et clarifient les responsabilités. Mais à l’échelle d’OpenAI, demander à chaque équipe de prévoir parfaitement sa capacité avant un lancement peut ralentir les expérimentations ou conduire à un sur-provisionnement coûteux .
La capacité partagée permet au contraire d’absorber plus facilement des croissances inégales. Son inconvénient est qu’il faut empêcher une charge de travail d’en dégrader une autre. OpenAI répond avec des mécanismes qui étranglent d’abord les clés les plus chaudes, donnent la priorité au trafic interactif par rapport aux travaux hors ligne ou massifs, et s’appuient sur des comportements côté Azure adaptés à ces usages extrêmes . Habitat devient donc une forme de plan de contrôle pour les équipes internes: il masque la complexité de la base de données afin que les produits puissent avancer sans transformer chaque équipe en spécialiste de capacité Cosmos DB.
C’est peut-être le message stratégique le plus important. Dans l’IA, on parle souvent de capacités de modèle comme du principal goulot d’étranglement. Habitat rappelle qu’à l’échelle du milliard d’utilisateurs, la latence du stockage, la fraîcheur du cache, la résidence des données, la planification de capacité et l’ergonomie interne des plateformes deviennent tout aussi critiques.
Ce qui reste à construire
OpenAI indique aussi que l’architecture n’est pas définitive. L’entreprise dit développer un système de stockage en ligne interne à l’échelle de l’exaoctet, destiné aux données Habitat volumineuses et au futur stockage des conversations. Ce système doit combiner le cœur RocksDB Cloud issu de Rockset avec une réplication fondée sur Raft, tout en conservant le modèle documentaire utilisé avec Cosmos DB .
AI.info souligne que ce système reste en développement. Pour l’instant, l’histoire de production demeure donc celle d’Azure Cosmos DB, de la réplication sélective, de l’invalidation de cache et d’un service Habitat optimisé . Le franchissement du milliard d’utilisateurs n’est pas seulement un jalon de croissance. C’est un rappel que l’IA grand public entre dans une phase où les schémas cloud ordinaires doivent être réinventés pour une demande extraordinaire. Pour Microsoft, c’est une publicité remarquable pour Cosmos DB. Pour OpenAI, c’est la preuve que même la base de données a parfois besoin d’une fenêtre de contexte beaucoup plus grande.
Commentaires
Sois le premier à commenter.