bingdadaOpenAI 的 Habitat 存储平台通过从单租户转向多租户、并与 Azure 团队共建共管容器方案，解决了 Cosmos DB 逻辑分区键碰撞与物理分区限流问题，从而在 40 个区域、500 PB 数据规模下支撑十亿级用户的毫秒级访问。
当 ChatGPT 的月活用户突破十亿量级，支撑其毫秒级数据访问的在线存储平台 Habitat 便不再只是一个工程组件，而成为决定产品体验与迭代速度的关键基础设施。OpenAI 工程团队近期披露了 Habitat 底层存储从单租户走向多租户的完整路径，其中对 Azure Cosmos DB 的调优与取舍，为所有面临规模化压力的团队提供了一份难得的实战样本。
Habitat 的定位很清晰：让 ChatGPT、API、Codex 以及内部服务能够快速、可靠地读取所需数据。它横跨 40 个地理区域，承载超过 500 PB 的数据，并需要在毫秒级完成响应。围绕这一目标，团队确立了一条递进式的优化路线——先做到足以承载关键业务流量的可靠性，再做到面向全球用户的低延迟，最后才是大规模下的精细化运营。
这条路线并非一次设计成型。Habitat 最初只是一个 Python 客户端库，后来演变为独立服务，再到今天成为多租户数据库层。每一步演进都伴随着对架构权衡的重新审视，而非简单的容量堆叠。
规模化过程中，基础设施团队几乎都会遇到同一个岔路口：继续维持单租户，还是转向多租户。
单租户模式下，每个产品团队维护自己的系统，故障影响面小、归属边界清晰、工作负载天然隔离。但随着产品面增多，这种模式的开销急剧上升——每个团队都要独立做容量规划，过度预留成为常态。多租户则把资源调配权交给集中化的数据库团队，专业度更高、利用率更好，但随之而来的是吵闹邻居问题：某个租户异常占用大量资源，拖累其他租户。
Habitat 在这条路上走过一个完整的循环：早期所有产品共用一个多租户容器，随后为部分场景单独划分租户容器，最终又回归到默认多租户。值得玩味的是，团队并未急于在这一领域投入大量自研，而是尽可能复用 Azure Cosmos DB 的原生能力来推迟相关建设。
最初的设计相当直接：允许任意客户端负载进入，依靠每个逻辑分区键 10K RU/s 的上限形成背压。每个账户只使用一个默认容器。这套方案在早期运转良好，但很快暴露出两个结构性问题。
其一是逻辑分区键的碰撞。由于早期 API 设计把分区键选择直接暴露给客户端，user_id、workspace_id 这类高频键在不同产品用例间频繁重叠。多个用例共享同一逻辑分区键的吞吐上限，等于给单个用户的数据访问设了天花板。
其二是物理分区才是真正的限流执行点。文档中标注的限制针对逻辑分区键，但实际执行落在物理分区上。这意味着逻辑分区往往无法真正跑满 10K RU/s，而是与同物理分区上的其他逻辑分区共享配额。
团队此前在 Postgres 上就吃过类似的亏：一个热点组织或热点键产生的请求，足以拖垮整个数据库。为此他们投入大量精力做缓存，并为缓存未命中设计租约机制，避免回源流量压垮底层存储。这段经历直接影响了 Habitat 的后续设计取向。
真正让 Habitat 在多租户下站稳脚跟的，是与 Azure 团队紧密协作后形成的共管容器（co-managed containers）模式。这一方案在超大规模下依然保持了出色的读取性能，同时把多租户的隔离成本控制在可接受范围内。
从公开信息看，Habitat 的架构已经形成了清晰的分层：接入层负责路由、请求整形、限流、模式查找与数据驻留策略；安全层处理加密、授权与 ACL；缓存层由 Valkey 承担；存储层则同时对接 Azure Cosmos DB、内部 Nanobase 与 Blob 存储；变更数据捕获链路将数据流向 Databricks、Rockset、Kafka 等下游系统。这种分层让每一类问题都能在合适的抽象层解决，而不是全部压给数据库。
对于希望深入了解 Cosmos DB 分区与吞吐模型的读者，微软官方文档中的分区与水平缩放说明是可靠的参考；而关于多租户架构的一般性权衡，可参阅 Microsoft Azure 架构中心的多租户指南。
OpenAI 选择在 Azure Cosmos DB 之上做多租户封装，本质上是在托管服务的能力边界内寻找最优解。国内厂商面对相似的十亿级流量时，路径则更多样。阿里云表格存储 Tablestore 与腾讯云 TcaplusDB 都提供了按逻辑分区自动分裂的能力，字节跳动等公司则倾向在自研分布式 KV 之上叠加多租户配额体系。
在数据库层面，TiDB 这类分布式 SQL 系统通过 Region 调度实现负载均衡，与 Cosmos DB 的物理分区思路有相通之处；而 OceanBase 在多租户资源隔离上提供了租户级 CPU 与内存配额，直接回应了吵闹邻居问题。对国内团队而言，OpenAI 这份经验最有价值的部分或许不是具体参数，而是那条演进原则：先用托管服务的原生能力撑住，把自研投入推迟到真正无法回避的时刻。
回看 Habitat 的演进，几个判断值得记录。第一，把分区键选择权交给客户端是危险的，它会把容量规划的责任隐性转移给调用方，最终以碰撞的形式反噬。第二，文档中的限制与实际执行点可能不在同一层，容量模型必须基于真实压测而非规格表。第三，多租户不是非此即彼的选择题，混合模式与阶段性回退都是合理选项。第四，缓存与背压机制的价值在热点场景下会被无限放大，值得提前设计。
这些经验并不局限于某一家云厂商。当在线存储平台需要同时服务数十个产品线和十亿级用户时，架构的复杂度管理能力，往往比单点性能更能决定长期成败。
Habitat 是 OpenAI 自建的在线存储平台，为 ChatGPT、API、Codex 及内部服务提供毫秒级数据访问，横跨 40 个地理区域，管理超过 500 PB 数据。
单租户导致每个产品团队重复做容量规划并普遍过度预留，成本过高；多租户由集中团队统一调配资源，利用率更高。团队通过共管容器方案缓解了吵闹邻居问题，因此默认回归多租户。
因为限流实际在物理分区执行，多个逻辑分区共享同一物理分区配额，单个逻辑分区通常无法跑满标称上限，高频键碰撞会进一步压缩可用吞吐。
Bingdada 是一个专注 SEO、GEO（生成式引擎优化）与 AEO（答案引擎优化）的内容平台，由资深内容编辑、SEO 技术工程师与 AI 研究专家组成的团队持续运营。我们追踪搜索引擎与生成式 AI 的最新动态，为读者提供准确、实用、可落地的方法论与行业洞察。
编辑团队：内容策划 · 技术编辑 · AI 研究组
网站：bingdada.com
© 2026 Bingdada. 保留所有权利。
SEO & GEO 技术探索者，专注于搜索引擎优化和生成式引擎优化。
AT&T 与 OpenAI 的合作揭示企业法务 AI 的新思路：不是替代律师，而是构建贯穿组织的知识层，用自然语言受理系统提升需求处理效率，让专业判断规模化。
一位经营三家联合品牌快餐店的加盟商，用ChatGPT Work把菜单重定价从5天压到2小时、月度现金对账从3小时缩到10分钟，并探索排班优化释放现金流的路径。
AI编程能力正从主流语言向COBOL、Fortran等低资源语言延伸。最新评估显示模型在跨语言构建与行为保真迁移上大幅进步，成本同步下降，为关键基础设施的现代化改造提供了新选项。
获取最新的 SEO 与 GEO 技术资讯。
我们尊重您的隐私，随时可以取消订阅。
