Habitat : OpenAI revient au stockage mutualisé

NNoor

Alors, Habitat avait d’abord été conçu autour d’un stockage partagé, puis OpenAI a séparé certains usages dans des conteneurs dédiés pour limiter les effets d’un service très sollicité sur les autres. L’entreprise revient maintenant à une organisation multi-locataire, où plusieurs usages s’appuient de nouveau sur des conteneurs co-gérés avec l’équipe Azure. OpenAI décrit aussi l’emploi d’Azure Cosmos DB et d’une mise en cache mondiale, afin d’accélérer les lectures de ChatGPT. L’entreprise annonce des lectures 12 fois plus rapides avec cette architecture, mais ne donne pas ici le détail des conditions de mesure. Le changement n’est donc pas seulement un retour à une infrastructure commune : il associe mutualisation, cache à l’échelle mondiale et travail avec Azure, après une période où l’isolation avait répondu à des problèmes de fiabilité.

NNoor

Dans une architecture multi-locataire, plusieurs services utilisent une infrastructure de stockage commune, au lieu de disposer chacun d’un conteneur indépendant. Cela permet de faire coexister des charges différentes et de partager la capacité disponible. Mais cette proximité peut aussi créer un effet de voisinage : lorsqu’un usage consomme beaucoup, il risque de peser sur les autres. Avec la hausse des incidents de production, OpenAI a donc isolé certains services ou grandes fonctionnalités dans des conteneurs dédiés. D’après Brief IA, ce cloisonnement a permis d’éviter des pannes plus étendues en limitant parfois les conséquences à une fonctionnalité ou à un service. L’isolation ne supprimait pas les incidents, mais elle en circonscrivait la portée. Cette stratégie a toutefois créé une autre difficulté : chaque conteneur devait être géré et dimensionné séparément. Habitat est ainsi passé du partage à des usages isolés, puis revient au modèle partagé comme fonctionnement général.

NNoor

OpenAI indique que Habitat fournit une couche de base de données mutualisée à de nombreux produits. D’après Brief IA, l’infrastructure soutient plus d’un milliard d’utilisateurs et traite plus de 500 pétaoctets de données. Ces ordres de grandeur expliquent pourquoi l’organisation du stockage compte : la plateforme doit accompagner des usages nombreux, avec des niveaux d’activité qui peuvent varier. La mutualisation permet de partager les ressources entre ces usages plutôt que de réserver une capacité distincte à chaque service. Cela ne signifie pas que chaque utilisateur échange directement avec Habitat, ni que tous les produits l’emploient de façon identique. Le point essentiel est que cette infrastructure se trouve sous plusieurs produits et doit contribuer à leur fonctionnement. Dans ce contexte, OpenAI met en avant l’amélioration des lectures à l’échelle mondiale. La description ne précise pas, produit par produit, quels changements sont perceptibles pour les utilisateurs.

NNoor

Un conteneur dédié doit disposer de sa propre capacité et faire l’objet d’une planification distincte. Les équipes doivent donc estimer le débit attendu, puis prévoir les ressources nécessaires avant le lancement d’un service ou d’une fonctionnalité. Si l’estimation est insuffisante, il peut être nécessaire d’augmenter la capacité au dernier moment. Le stockage partagé réduit cette séparation des capacités : les usages peuvent profiter d’une infrastructure commune, où leurs variations se combinent. Mais le cloisonnement a aussi montré son intérêt, puisqu’il a contenu certains incidents au lieu de les laisser affecter un ensemble plus large. OpenAI ne l’abandonne donc pas entièrement et réserve désormais les conteneurs dédiés aux cas d’usage critiques. L’arbitrage consiste à garder une protection ciblée, sans imposer partout les coûts et la planification qu’exige l’isolation.

NNoor

OpenAI annonce une amélioration d’un facteur 12 pour les lectures avec cette architecture. L’entreprise associe cette évolution à plusieurs éléments : le partage entre locataires, la mise en cache mondiale, Azure Cosmos DB et le travail avec l’équipe Azure. Il faut donc retenir qu’il s’agit d’un gain annoncé par OpenAI, sans en déduire un effet uniforme sur chaque produit ou chaque requête. L’objectif présenté est d’améliorer les lectures à l’échelle mondiale, tout en revenant à une infrastructure mutualisée. Cette organisation peut mieux partager les ressources, mais elle doit toujours gérer le risque qu’un usage intense affecte les autres. Les conteneurs dédiés restent une réponse possible pour les besoins jugés critiques. Le résultat dépend ainsi d’un équilibre entre performances, capacité, coûts et maîtrise des incidents.

NNoor

Bon, OpenAI ne revient pas simplement à une ancienne configuration : l’entreprise fait de nouveau du stockage partagé son modèle général, avec des conteneurs co-gérés et Azure Cosmos DB. La mise en cache mondiale fait également partie de l’architecture décrite pour accélérer les lectures, et le gain annoncé est de 12 fois. Le détour par les conteneurs dédiés a permis de limiter la propagation de certains incidents, mais il a aussi augmenté les coûts et imposé une planification séparée de la capacité. Ces conteneurs sont donc conservés pour les usages critiques, plutôt que déployés partout. Habitat soutient de nombreux produits et son infrastructure traite plus de 500 pétaoctets de données pour une base de plus d’un milliard d’utilisateurs. À cette échelle, le défi est de bénéficier du partage sans négliger les effets de voisinage. OpenAI présente cette évolution comme un travail en cours, avec un compromis entre lectures plus rapides, ressources mutualisées et isolation ciblée.