OpenAI Habitat 深度：500 PB 存储与 10 毫秒读取延迟

一句话结论：OpenAI 把 ChatGPT 的在线存储平台 Habitat 做到了 500 PB 规模、单个 Cosmos DB 账户每秒 2000 万次查询，并把全球读取的中位延迟从 120 毫秒压到 10 毫秒，中间还踩了两次自己也没演练过的故障。

2026 年 10 月 23 日，OpenAI 在官方工程博客放出 Habitat 系列的第二部分。Habitat 是承载 ChatGPT、API、Codex 和内部服务数据的在线存储平台，第一部分讲的是怎么从 Python 客户端库做成服务，这一部分往下挖一层，讲底层数据库 Azure Cosmos DB 怎么扛住的。

这次公开的信息密度比多数工程博客高，因为它罕见地把失败的部分也写了：多租户架构来回改了两轮才定下来，两次严重故障都发生在没有预先演练的路径上，而所谓托管服务在足够大的规模上会变得不那么托管。这篇按数据表和工程细节拆一遍。

规模数字：500 PB、40 个区域、2000 万 QPS

先把口径摆清楚。Habitat 服务超过 10 亿用户，覆盖 40 个地理区域，整体存储超过 500 PB。最大的一个 Azure Cosmos DB 账户存着数十 PB 数据，每秒处理超过 2000 万次查询，OpenAI 说据其所知没有第二家公司把 Cosmos DB 部署到这个规模。所有产品每秒钟要处理的请求量在 7000 万级别，其中超过 90% 是读请求。

支撑这些数字的组件是一套组合，不是一个数据库。Cosmos DB 是主在线存储，旁边还有 Nanobase 承担在线存储、Valkey 做缓存、对象存储放冷数据，变更数据捕获（CDC）流进 Databricks、Rockset 和 Kafka。Habitat 这一层负责的是缓存、ACL 授权、数据驻留与放置、加密、多租户隔离、限流和路由。

三阶段绕路：单租户和共享容器都试过，最后回到共享

第一阶段是每个 Azure Cosmos DB 账户里放一个默认共享容器，靠每逻辑分区键 10000 RU/s 的上限做背压。这一版暴露出三个问题。

分区键冲突是最直接的。因为早期 API 把逻辑分区键的选择权交给了客户端，不同产品线都爱用 user_id 和 workspace_id，于是它们共享同一份 10000 RU/s 的额度，单个用户的总吞吐被别人的分区键拖住。噪声邻居问题则来自限制的真实执行位置，10000 RU/s 是文档里的逻辑分区键上限，资源约束实际发生在物理分区上，同一个物理分区里的所有逻辑分区要一起分，一个小众功能的高负载就能挤掉核心的登录注册流程。弱分区问题更隐蔽，容器的预配吞吐量是均分到各物理分区的，数据增长触发分区拆分之后总吞吐量不变，单个分区能分到的就变少了，比如原本 10000 RU/s 拆成两个各 5000 RU/s，对存储量大但请求量平稳的类 Blob 场景，光是数据长胖就能把活跃负载的可用吞吐削掉一半。

第二阶段转向隔离。为关键新用例单独开容器，用脚本让预配吞吐量跟着物理分区数走。这一版基本消除了上面三个问题，也避免了大量全站级故障，但代价换了个位置出现。

共享容器有天然的聚合增长优势，一个新功能从 0 涨到 100 万 QPS，在一个大池子里总容量几乎不动；独立容器里同样的跳变就是从零到满。官方用了一组数字说明这个差别：一个 100M RU/s 的共享容器用了 80%，剩余 20M 余量，1000 RU/s 的压测只占余量的 0.005%，上线时 1M RU/s 也只占 5%；换成一个全新的 10K RU/s 独立容器，1000 RU/s 压测就占了 10%，上线 1M RU/s 直接是容量的 10000%。更现实的是产品团队经常忘记预扩容，基础设施工程师只能在发布当天坐在故障应急室里手动扩容器。

第三阶段回到默认共享容器，这次靠三个机制把前两阶段的毛病堵住。热键限流优先掐最热的键，避免单个租户把整个物理分区抽干；请求分级 QoS 把批量插入、数据提取这类离线活儿排在低优先级，先被限流，交互式请求受保护；改良版 serverless 模式是 Azure 团队专门为 OpenAI 做的，原版只按存储量伸缩且每物理分区封顶 5000 RU/s，新版把上限提到 10000 RU/s，并且分区除了按存储量拆分还按 RU 用量拆分，手工监控扩容的动作就此取消。结果是共享容器恢复、产品团队不用再做前置容量规划，官方称此后数月没有再发生配置事故和噪声邻居事故。这句无事故自述来自 OpenAI 自己，没有第三方验证。

两次故障：托管服务在足够大规模上会失灵

2024 年底，最大账户之一的 Azure 主区域发生区域性断电。故障切换过程中 OpenAI 才发现，最大的账户切到备用区域要花几个小时，这个路径两个团队都没在那个规模上试过。约一个月后回切主区域，连接风暴压垮了原区域的 Cosmos DB gateway，根因在 gateway 模式的客户端行为上，即便只有部分物理分区已经迁回原区域，所有客户端还是立刻连回原区发请求。

两次故障都走了事故流程、都定位到了根因、都做了修复，但 OpenAI 的结论落在组织层面。托管服务一旦大到某个程度，就得跟供应商共担故障。现在两个团队从服务层一路到 Cosmos DB 物理存储联合监控，改动要在生产规模的非生产账户上验证，SDK 一起迭代，可以直接呼叫对方工程同事而不用走支持工单。Azure 侧加了负载保护和 gateway 元数据缓存，OpenAI 侧做了连接池与连接复用、工作负载同置、以及用不同 VPC 把关键负载和离线负载隔开。

读性能是怎么降下来的：三层策略加一次重写

2025 年系统稳定之后，延迟成了主要约束。计算和存储往往不在同一个区域，跨区请求躲不掉，产品团队只能自己做客户端缓存、请求批处理、把工作移出关键路径，代码变复杂，迭代也变慢。

OpenAI 的三层做法。第一层是就近放置，容量允许时把数据存在用户附近，但很多区域装不下与流量份额相称的存储量，数据中心、电力或制冷吃紧时只能在本地存储和额外计算之间取舍，这是产品级的取舍不是纯技术优化。第二层是最小化广泛复制，只有认证元数据这类每个请求都要用的小数据集才被复制到全部 40 个服务区域，部分账户至少复制到每个大洲一个区域，为了在不同复制拓扑的账户之间搬数据，还提前建了一层透明的数据移动与路由。第三层是其余数据全走集成缓存，基于 Valkey 的分布式 lookaside cache 部署在靠近用户请求处理的位置，既提单区域性能也遮蔽跨区延迟。

缓存失效的处理比想象中讲究。单纯用 TTL 会卡在两头，TTL 短则命中低收益有限，TTL 长则可能长期返回陈旧数据；写时显式失效又会在部分失败时留下脏缓存，多区域网络下失效通知还可能和底层复制产生竞态。Habitat 的做法参考了 Meta 的 TAO 系统，用 Cosmos DB 的 change feed 拿 CDC，由专门服务消费变更流，在全球范围内数秒内传播失效，数据更新后本地缓存作废，下一次读产生 miss 再从底层存储回填。

最后一步是把关键代码从 Python 重写成 Rust。三个动作叠加的结果，是全球读取中位延迟从大约 120 毫秒降到大约 10 毫秒，12 倍提升。慢请求仍然是难点，那些没命中缓存又落在远端存储的数据仍然要付跨区代价。

面向下一个十亿：自研 EB 级存储

为了支撑再增加十亿用户以及会话存储这类体量更大的数据，OpenAI 在做自己的 EB 级在线存储系统，核心是 Rockset 的 RocksDB Cloud 引擎加上基于 Raft 的复制，文档模型与 Cosmos DB 保持一致，走分离式存储和物理复制。目标是减少所需闪存容量，代价是峰值 QPS 会降低。CDC 那条链的规模也值得记一笔，每秒数百万次变更，涉及数千个容器、数百万个容器分区、一百多个 Kafka topic，数千个 worker 分布在多个地理区域，并用死信队列挡住永久投递失败造成的队头阻塞。

常见问题

OpenAI 的 Habitat 是什么？h3>

Habitat 是 OpenAI 自建的在线存储平台，ChatGPT、OpenAI API、Codex 和内部服务的数据访问都走它。它提供缓存、授权、数据驻留与放置、加密、多租户隔离、限流和路由，底层由 Azure Cosmos DB、Nanobase、Valkey、对象存储以及 CDC 数据流组成。2023 年 DevDay 上它最初只是支撑 GPTs 的一个 Python 客户端库。

ChatGPT 的数据存在哪里？

主在线存储是微软 Azure Cosmos DB，OpenAI 最大规模的单个账户存着数十 PB 数据，每秒处理超过 2000 万次查询。此外还有 Nanobase 承担另一部分在线存储，Valkey 做缓存，变更数据通过 change feed 捕获后送入 Databricks、Rockset 和 Kafka。面向下一阶段的 EB 级自研存储正在开发中，底层是 RocksDB Cloud 引擎加 Raft 复制。

多租户数据库该用独立容器还是共享容器？

OpenAI 的答案经历了三阶段反复，最后是共享容器加隔离机制。共享的优势是容量吸收和无需产品团队做容量规划，风险是噪声邻居和弱分区；隔离能控制故障半径，代价是容量规划变成所有团队的负担、发布日常出扩容事故。他们的解法是热键限流、请求分级 QoS 以及按 RU 用量也能拆分的改良版 serverless 模式。对大多数团队，先把流量分级和缓存做扎实，比急着拆容器更划算。

小结

Habitat 这套东西的价值在于过程可复制。多租户数据库没有免费午餐，OpenAI 的路径是先撞墙再回头，中间两次故障也说明没有演练过的容灾路径在故障时会变成数小时的延迟。它给出的可迁移经验有三条：分区键不要暴露给客户端，文档级限流不等于物理级限流，托管服务在足够大规模上需要和供应商共担责任。至于 120 毫秒到 10 毫秒这个数字，本身并不关键，关键是知道它来自就近放置、最小集广泛复制、缓存加 CDC 失效传播、以及一次语言重写的叠加，而不是单一优化。