先看证据
共享容器曾让不同业务互相影响
OpenAI在2026年10月发布的Habitat扩展文章中，介绍了这套在线存储平台如何支撑ChatGPT、API、Codex等产品访问数据。Habitat建立在Azure Cosmos DB之上，目标是在多个地理区域为产品提供快速、可靠的存储访问。文章聚焦的不是某个数据库功能，而是当许多产品共用底层存储时，怎样兼顾可靠性、性能和团队运维负担。
早期方案让不同产品用例共享Cosmos DB容器，但共享并不意味着负载天然兼容。不同业务可能使用相同的逻辑分区键，例如user_id或workspace_id；当热点集中到特定键或物理分区时，一个用例的流量就可能挤占其他用例的吞吐。OpenAI举出的实际冲突是，小众功能的负载曾干扰登录、注册等核心流程，资源利用率的收益因此带上了故障传播的代价。
独立容器解决了隔离，也带来了新负担
团队一度为关键新业务配置独立容器，把故障影响范围缩小到单个服务或功能。这种做法让所有权和隔离边界更清楚，也避免一个租户直接消耗共享容器的资源。但隔离并非免费的：每个容器都需要容量规划和预扩容，产品团队可能漏做；负载无法再依靠共享容器的汇总需求互相缓冲，低谷时也可能留下闲置容量。
这段回退说明，单租户和多租户解决的是不同问题。独立容器更容易限制故障半径，却把容量管理分散给更多团队；共享容器便于集中管理和汇总资源，却必须面对邻居噪声。Habitat最终转回“默认多租户”，不是取消隔离，而是尝试把隔离做成按业务和请求调整的控制措施，而不是给每个产品永久划一条容器边界。
把隔离落实到流量和分区管理
共享容器要可靠，首先得区分请求的价值和风险。OpenAI描述的做法包括优先限制最热的键，并把离线批量写入、数据提取等低优先级请求排在交互式请求之后；资源紧张时，先削减低优先级流量，尽量保护面向用户的关键路径。这样做没有消除共享资源争用，而是让系统在争用发生时决定谁先得到资源、谁先被限流。
另一个变化在数据库分区扩展上。Cosmos DB按逻辑分区键分布数据，物理分区承载吞吐；物理分区拆分后，原先集中的吞吐可能被分摊到新的分区。OpenAI称与Azure合作改进serverless模式，使物理分区可从旧有的每分区最高5,000 RU/s提升到10,000 RU/s，并增加按RU使用量拆分的方式，而不只依赖存储量触发拆分。对运维团队而言，重点是减少持续盯着容量、手动扩容容器的工作，但公开材料没有给出这项变化的成本对照。
全球低延迟靠组合，而非全量复制
面对跨区域访问，Habitat没有把所有数据都复制到所有地方。OpenAI称，容量允许时会把数据放到更靠近用户的位置；少数对延迟极敏感的数据，例如认证元数据，则采用跨区域复制。部分关键账户覆盖全部40个Azure区域，其他账户至少覆盖每个大洲一个区域。文章也承认，就近放置受存储容量、电力和冷却等约束，因此不可能对所有数据采用同一种全球部署策略。
缓存补上了另一部分读取路径：Habitat在靠近请求处理位置的Valkey集群中缓存近期访问的对象和关系，再通过Cosmos DB change feed的变更数据捕获管道传播缓存失效。管道处理每秒数百万条变更，并经由100多个Kafka topic分发；缓存同时设置TTL，以限制失效传播或异常时陈旧数据持续的时间。这套设计意味着读性能依赖的不只是缓存本身，还依赖变更传播、底层复制和故障时的行为；材料没有给出缓存命中率或正式的最大陈旧时间保证。
12倍读延迟改善，仍不是端到端承诺
OpenAI报告，Habitat全局读取p50延迟从约120毫秒降至约10毫秒，改善约12倍。团队把这项变化归因于区域内缓存、关键数据跨区域复制，以及将Habitat服务从Python重写为Rust等因素的组合。公司还称，最大的Cosmos DB账户存储数十PB、服务超过2,000万QPS，CDC覆盖数千个容器和数百万个容器分区。这些数字说明系统规模很大，但“面向超过10亿用户”没有交代统计周期或去重口径，不能直接读成10亿独立ChatGPT用户，也不是并发量指标。
对技术负责人来说，最可迁移的判断不是照搬某个RU上限或复制区域数，而是把业务关键性、请求优先级和数据延迟敏感度明确映射到资源策略：哪些流量必须受保护，哪些可以被限流，哪些数据值得付出跨区复制成本。12倍是OpenAI报告的总体读延迟结果，并未拆分各项优化的贡献，也不等于ChatGPT端到端响应时间改善12倍。多租户实践仍在演进，缓存陈旧度、成本和隔离规则的量化细节也未公开；采用类似方案前，团队应先定义自己的服务等级、陈旧数据容忍度与成本边界，再验证共享是否真的比独立部署合算。