Analyse approfondie · Environ 7 min de lecture
Comment OpenAI a remanié Habitat : capacité partagée, caches régionaux et lectures accélérées de 12× sous conditions
OpenAI décrit les conteneurs Cosmos DB, l’invalidation CDC et Rust ; la baisse de la médiane combine plusieurs changements.
- Publié ici
- Date de la source
- Source vérifiée
Dans un article technique du 23 octobre, OpenAI explique l’évolution du stockage Azure Cosmos DB et du chemin de lecture de Habitat. Il s’agit de choix opérationnels et de mesures rapportés par l’entreprise, pas du lancement d’un modèle ou d’un service de stockage public.
Écouter les actualités
Écoutez cet article ou poursuivez la lecture des actualités.
Préparation de la lecture…
Voix de l’appareil
La voix est traitée par votre navigateur ou appareil. AISubHub n’envoie pas le texte à une API audio. Les voix et la lecture écran verrouillé dépendent de l’appareil.
La reprise peut répéter une courte phrase.
En bref
- OpenAI attribue le passage du p50 mondial des lectures d’environ 120 ms à 10 ms au placement des données, aux caches régionaux et à une réécriture Rust ; les lectures lentes sans cache atteignent encore un stockage distant.
- Habitat est passé de conteneurs partagés à des conteneurs isolés, puis au partage par défaut après une collaboration avec Azure. Un autre système à l’échelle de l’exaoctet reste en développement.
Pourquoi le partage pouvait limiter des fonctions sans rapport
OpenAI décrit Habitat comme une couche gérant plus de 500 pétaoctets, pour des produits servant plus d’un milliard d’utilisateurs dans 40 régions géographiques. Ces chiffres proviennent de l’auteur : ce n’est ni un comptage indépendant ni une annonce de nouveaux utilisateurs. Le problème consiste à mutualiser la capacité sans qu’une fonction en perturbe une autre. Au départ, chaque compte Cosmos DB utilisait un conteneur par défaut et les clients choisissaient leurs clés de partition logique. Des identifiants courants pouvaient donc faire partager une même limite à plusieurs usages.
RU/s désigne des unités de requête par seconde, pas un nombre fixe de requêtes. La conception initiale comptait sur une limite annoncée de 10 000 RU/s par clé logique, mais les limites sont imposées au niveau des partitions physiques partagées. Des clés sans rapport s’y concurrencent. Autre piège : si la croissance du stockage provoque une division sans hausse du débit total du conteneur, chaque partition fille reçoit moins de capacité. Des objets volumineux peuvent donc dégrader le service à trafic constant. Les schémas expliquent ces mécanismes ; leurs proportions ne sont pas des mesures de production.
L’isolation a réduit les dégâts et multiplié la planification
Des conteneurs dédiés ont donné aux services critiques des partitions physiques distinctes, réduisant la portée des voisins bruyants. L’équipe ajustait aussi le débit provisionné au nombre de partitions pour corriger les partitions faibles. En contrepartie, chaque service devait planifier sa capacité. Passer de tests internes au trafic public pouvait saturer un petit conteneur isolé, alors que le même ajout aurait peu affecté un grand ensemble partagé. L’isolation a déplacé les frontières de panne sans supprimer la prévision de demande avant lancement.
Habitat est revenu au partage par défaut avec limitation des clés chaudes, priorité inférieure des tâches massives et variante serverless conçue avec Azure. L’article oppose l’ancien plafond de 5 000 RU/s par partition physique à un mode adapté allant jusqu’à 10 000 RU/s, avec divisions déclenchées par les RU utilisées et le volume stocké. Cette collaboration précise ne démontre pas que chaque client Azure puisse activer le même mode. Notre analyse : mutualiser redevient fiable lorsque le contrôle protège le trafic interactif et que la capacité suit la demande.
Pourquoi un service géré a nécessité des tests conjoints
OpenAI affirme que son plus grand compte Cosmos DB stocke des dizaines de pétaoctets et sert plus de 20 millions de requêtes par seconde. Une panne électrique fin 2024 et un incident de retour environ un mois plus tard ont révélé des hypothèses non testées : une panne électrique a montré que les plus grands comptes mettraient plusieurs heures à basculer ; environ un mois plus tard, leur retour a déclenché une ruée de connexions saturant la passerelle initiale. Les clients se reconnectaient avant le retour de toutes les partitions concernées. Ce sont deux incidents à des étapes distinctes, pas une panne continue.
La réponse dépasse l’achat de capacité. Habitat et Azure surveillent ensemble les couches, testent un compte hors production de taille comparable, font évoluer les SDK et disposent de contacts directs entre ingénieurs. Le récit mentionne aussi cache de métadonnées de passerelle, protection contre la charge, réutilisation des connexions et séparation des tâches critiques et hors ligne. Nous en déduisons qu’il faut tester le retour aussi bien que le basculement à une échelle représentative. La gestion de la base par le fournisseur ne valide pas automatiquement les connexions du client, le délai de reprise ou la portée acceptable des pannes.
Ce que comprend réellement le gain de lecture de 12×
Selon OpenAI, plus de 90 % des requêtes Habitat sont des lectures. La stratégie rapproche les données lorsque la capacité le permet, réplique largement quelques petits jeux sensibles à la latence et utilise des caches Valkey proches pour les autres objets et relations fréquents. Certains comptes critiques sont répliqués dans les 40 régions Azure desservies ; cela ne signifie pas que toutes les données le sont partout. Stockage et calcul se disputent alimentation, refroidissement et espace. Le placement demeure un arbitrage de produit et de capacité, sans proximité illimitée garantie.
L’invalidation s’appuie sur le flux de changements Cosmos DB : les consommateurs CDC invalident les copies locales après modification et la lecture suivante les recharge. OpenAI annonce une propagation mondiale en quelques secondes, sans dépendre uniquement de l’expiration TTL ; ce n’est pas une cohérence instantanée. La réécriture Rust réduit aussi la surcharge logicielle du service. Ensemble, ces changements ont fait passer le p50 mondial d’environ 120 ms à 10 ms. Le graphique distingue réplication proche, cache régional et Rust. Le facteur 12× ne revient pas à Rust seul, ne décrit pas les écritures ni le temps total de réponse de ChatGPT pour chaque utilisateur.
CDC à grande échelle et frontière entre déploiement et projet
CDC alimente aussi index secondaires, déplacement de données et analyses. OpenAI rapporte des millions de changements par seconde sur des milliers de conteneurs et des millions de partitions, via plus de cent topics Kafka. Un plan de contrôle répartit régions et travailleurs ; lectures sur répliques et faible priorité protègent le trafic interactif. Isolation des flux, gestion des baux, files de messages en échec et changement de lecteurs après panne régionale traitent différents problèmes. Écarter une livraison définitivement défaillante évite de bloquer le flux, sans prouver que chaque consommateur est à jour.
Les limites restent essentielles : les lectures lentes sans cache atteignent le stockage distant, et l’article ne fournit ni comparaison contrôlée isolant chaque optimisation ni garantie universelle de latence de queue. OpenAI développe un système exaoctet utilisant le cœur RocksDB Cloud de Rockset, la réplication Raft et un modèle documentaire compatible Cosmos. Le stockage désagrégé et la réplication physique visent à réduire les besoins en flash en échange d’un QPS maximal inférieur. Le système reste en développement, sans remplacement achevé de Cosmos. Nous avons lu cette seconde partie et son graphique, sans vérifier indépendamment la première, les sources SDK ou les garanties de service liées.
Pourquoi cela compte
Les équipes peuvent comparer isolation, réserve globale de capacité et responsabilités opérationnelles. Fraîcheur du cache, reprise et latence de queue doivent être évaluées séparément.
Limites et disponibilité
Ce sont des affirmations d’OpenAI, sans reproduction par AISubHub ni garantie Azure. Le texte n’établit ni accès universel au mode serverless personnalisé, ni avantages d’abonnement, ni gain de latence pour toute l’application.
Sources et preuves
Date de la source: · Source vérifiée:
Articles assistés par IA, vérifiés avec les sources primaires citées. Les affirmations des fournisseurs sont attribuées ; la présence ne vaut pas recommandation.