OpenAI 自研存储平台 Habitat：给十亿用户的毫秒级数据访问是怎么做到的？

先说结论

OpenAI 在 2026 年 10 月 23 日发布工程博客《Rapidly scaling online storage to serve over 1 billion ChatGPT users (Part II)》，公开了其统一存储平台 Habitat 的存储层架构：基于 Azure Cosmos DB 的多租户演进、与 Azure 团队的联合运维模式、全球读延迟从约 120ms 降到约 10ms 的优化路径，以及面向下一阶段的自研 EB 级存储系统预告。官方数据：Habitat 每秒处理超 7000 万请求、服务超 10 亿周活用户、覆盖约 40 个地理区域、存储超 500PB。

我的判断是：这篇博客真正的信息量不在规模数字，而在两个工程决策——“从多租户到单租户再回到多租户”的螺旋路线，以及”托管服务在头部规模会退化成联合工程”的运维模式判断。这两条对任何正在把 Agent 产品从 demo 推向大规模的团队都直接可用。

发生了什么

主来源是 OpenAI 官方工程博客《Rapidly scaling online storage to serve over 1 billion ChatGPT users (Part II)》，发布日期 2026 年 10 月 23 日，原始 URL：https://openai.com/index/scaling-storage-one-billion-users-part-two。作者为 OpenAI 技术成员 Jon Lee、Hrachya Hakobyan、Chaomin Yu。这是 9 月 11 日 Part I（讲 Habitat 服务层如何把 Python 服务推到极限）的续篇，本篇聚焦存储层。

官方事实一：Habitat 的规模数字。 每秒处理超过 7000 万请求，支持 ChatGPT、API、Codex 等产品，服务超过 10 亿周活用户，覆盖约 40 个地理区域，存储超过 500PB 数据。官方明确说，据他们所知 OpenAI 是唯一一家在此规模部署 Azure Cosmos DB 的公司——最大的单个账户存了数十 PB 数据、每秒处理超 2000 万 QPS。

官方事实二：存储层走了一个”三段式”螺旋。 第一阶段依赖 Cosmos DB 原生能力，全产品共享一个多租户容器；第二阶段为关键用例拆分单租户容器以获得隔离；第三阶段又回到多租户默认，但这次是带着 Azure 团队专门工程化的新能力回去的。官方说”我们仍在多租户故事的非常早期”。

官方事实三：全球读延迟 12 倍优化。 通过关键数据近地复制、区域内分布式缓存（基于 Valkey 的 lookaside cache，用 Cosmos DB change feed 做秒级全局失效传播）、Habitat 代理层用 Rust 重写三件事，全球读 p50 从约 120ms 降到约 10ms。官方称读请求占 Habitat 总请求的 90% 以上。

官方事实四：下一代系统已在开发。 为服务”下一个十亿用户”，OpenAI 正在自研 EB 级在线存储系统：拿 Rockset 的 RocksDB Cloud 内核加上 Raft 复制，实现与 Cosmos DB 相同的文档模型，但用解耦存储（disaggregated storage）和物理复制来降低闪存容量需求，代价是更低的峰值 QPS。

官方事实五：CDC 平台独立成层。 每秒数百万条变更捕获、跨数千容器、100+ Kafka topic，支撑二级索引、数据管道、离线分析。CDC 平台抽象掉”监听哪些账户、哪个区域、worker 怎么扩缩”的全部复杂性，客户端只注册回调函数。

以上是官方发布内容；下文的工程解读是我的判断，与官方无关。

技术细节

1. 多租户 vs 单租户：三个失败模式逼出来的螺旋

第一阶段的问题全部来自”逻辑分区键”与”物理分区”的错配：

• 逻辑分区键碰撞：早期 API 把分区键选择直接暴露给客户端，导致不同产品用例在 user_id、workspace_id 这类通用键上频繁碰撞。因为 Cosmos DB 的限制按逻辑分区键计算，同一个用户的总吞吐被不相关的用例共同分摊了。
• Noisy neighbor：文档写的限制是”每个逻辑分区键 10K RU/s”，但实际限流发生在物理分区层。一个冷门功能的工作负载可以拖慢核心登录流程——不同用户的逻辑分区落在同一个物理分区上，共享限流上限。
• 弱分区（weak partitions）：容器吞吐按物理分区数量均摊，数据增长触发物理分区分裂时，总量不变、分母变大，每个分区的有效吞吐随存储增长而下降。存储涨、请求量不变，吞吐上限却自己往下掉——这是最反直觉的失败模式。

第二阶段拆分单租户容器确实解决了隔离问题，但制造了组织问题：新用例从 0 涨到 100 万 QPS，在共享容器里只占总余量的 5%，在专属容器里是基线的 10000 倍。产品团队忘记预扩容，launch day 坐在 SEV 会议室里临时扩容成了常态。官方原话：这”在组织层面无法扩展”。

第三阶段带回来的新能力：热键节流（先限最热的键，防止一个热键打满整个物理分区）、QoS 分级（离线批量写入先被限流，保护交互式请求）、新 serverless 模式（每个物理分区可到 10K RU/s，并引入基于 RU 用量的分裂——不再只按存储量分裂，弱分区问题从机制上消除）。官方称此后数月再无扩容或 noisy neighbor 事故。

2. 托管服务在头部规模”退化”成联合工程

这是全篇最值得 Infrastructure 团队细读的一段。官方的表述是：当你的规模成为云厂商基础设施里的离群值，”managed” 就不再 managed。具体合作形式包括：共享测试、共享 dashboard、直接工程通道、跳过 support 分层直接互相 paging、在生产规格但非生产的账户上共同测试变更、共同迭代 SDK。

2024 年底的区域故障是转折点：最大账户之一的主区域断电，故障演练发现这个规模的故障转移要数小时——双方都没在自己规模下测过。一个月后回迁时又触发连接风暴，打垮了原区域的 Cosmos DB 网关：网关模式客户端的 failover 特性导致所有客户端在只有部分物理分区迁回时就立即重连并全量发请求。

3. 读优化三层：数据近地、缓存、Rust

读请求占 90% 以上，所以优化全压在读路径上：

• 数据近地：受物理容量约束，只能对数据驻留合规和少数关键数据集做到；很多区域装不下对应的存储足迹，官方明确说这是”延迟优化 vs 存储容量”的直接权衡——省下容量放计算，存储请求就要绕远路。
• 认证元数据全域复制：每个请求都要查的认证元数据复制到全部 40 个区域（或至少每大洲一个），用复制拓扑换 RTT。为此提前建设了透明数据移动层。
• CDC 驱动的缓存失效：不走 TTL 权衡的老路，而是学习 Meta TAO：用 Cosmos DB change feed 消费变更、秒级传播失效到各区域 Valkey 缓存。高命中率 + 低陈旧度同时拿到。
• Rust 重写代理层：Part I 的 Python 服务层经验延续——把代理层从 Python 重写为 Rust 持续压延迟。

四件事合计把全球读 p50 从约 120ms 压到约 10ms（12 倍），官方说是”今年年初开始聚焦性能以来”的成果。

4. 对 Agent 工程的直接映射

Agent 产品的存储需求天然是”读重 + 热键”形态：会话历史按 user_id/session_id 聚簇，热门组织或热门 Agent 工作空间就是天然的 hot key。OpenAI 早期在 Postgres 时代就被 hot organization 打垮过整库，这套经验完整适用于任何 Agent 产品。

第二个映射是 CDC 驱动的缓存失效模式。Agent 系统里的工具状态、会话状态、权限快照都适合”读重写少 + 要求低陈旧度”的场景，change feed → 缓存失效这条链路可以直接复制。

第三个映射是”组织扩展性”这个约束本身：单租户隔离买的是可靠性，付出的是每个团队都要做容量规划的组织成本。Agent 平台团队在”每个业务线自建存储”和”统一平台层”之间的选择，本质是同一个权衡。

对 Agent / 工程的影响

第一，Agent 存储层应该默认多租户 + 平台层，跳过”每团队一库”阶段。 OpenAI 的螺旋证明了极端单租户在组织上不可扩展；如果你的 Agent 产品还在让每个业务团队自己运维数据库，这篇博客给出的方向是收拢到一个平台层，把隔离问题交给热键节流 + QoS + 分区机制解决。

第二，读路径优化优先级：缓存失效机制 > 缓存本身。 TTL 缓存在多区域场景下必然撞上陈旧度权衡；CDC 驱动的失效是已被两个超大规模生产系统（TAO、Habitat）验证的模式。Agent 会话历史、工具调用记录这类数据的读放大比写放大高一个数量级，值得直接复用此模式。

第三，分区键设计要提前做防御。 把 user_id 这类通用键直接暴露给业务方会导致跨用例碰撞；Habitat 的做法是在平台层做 schema lookup 和路由，而不是让客户端自选分区键。Agent 平台如果允许业务方自选分区键，早晚撞上同一个问题。

第四，托管服务的规模化极限要提前评估。 如果你的 Agent 基础设施依赖某项托管服务，且流量规模进入云厂商的”最大客户”区间，就要准备好”共享测试、共享 dashboard、直接工程通道”这种深度合作模式，或者准备好自研替代。官方的原话是 managed services become less managed——这句话值得写在每个 infra 团队的评估文档里。

第五，读延迟 12 倍优化是产品速度问题，不是基础设施问题。 官方明确说延迟优化之前，产品开发者被迫做客户端缓存、请求合并、关键路径规避等”围绕数据库问题做产品设计”，拖慢了产品迭代。存储快了，产品才能做简单。Agent 产品同理：存储层慢，产品逻辑就要绕着它设计。

我的判断

一，多租户螺旋路线是对的，但多数团队应该跳过第二阶段：除非你的某个用例流量模式极端离群，否则直接做平台层 + 热键节流 + QoS，不要走”先拆单租户再合并”的弯路。二，CDC 驱动的缓存失效值得立即引入 Agent 存储设计，TTL-only 的缓存设计在多区域场景下已被两次证明是次优解。三，自研存储的触发条件很清晰：当托管服务的故障转移时长和限流机制开始定义你的产品 SLO 时，就是启动自研的时点——OpenAI 是在 2024 年底那次数小时的 failover 演练后开始动手的。

Q&A

Q1：来源、发布日期和原始 URL 是什么？

A：主来源是 OpenAI 官方工程博客《Rapidly scaling online storage to serve over 1 billion ChatGPT users (Part II)》，发布日期 2026-10-23，原始 URL：https://openai.com/index/scaling-storage-one-billion-users-part-two。背景参考同系列 Part I（2026-09-11）：https://openai.com/index/scaling-storage-one-billion-users-part-one。官方还发布了中文版本（zh-Hans-CN 路径）。

Q2：能不能复现或验证？

A：部分可以。多租户的三个失败模式可以用任何按分区限流的数据库小规模复现：建一个多租户容器，两个业务用例共用逻辑分区键，压测其中一个，观察另一个的尾延迟变化；再持续写入数据触发分区分裂，记录有效吞吐随分裂数量下降的曲线。12 倍读延迟优化无法直接复现，但”近地复制 + 缓存 + 代理层重写”三层可以在自己的系统上逐层测量各自的贡献。

Q3：适用边界是什么？

A：官方方案绑定 Azure Cosmos DB 的分区原语、change feed 和 serverless 模式；热键节流和 QoS 分级是 Azure 团队为 OpenAI 定制的工程成果，普通用户拿到的 Cosmos DB 不一定有同款能力。文中的失败模式和权衡是通用的，具体机制不可直接照搬。EB 级自研存储系统仍在开发中，官方没有给出可用时间表。

Q4：和已有方案的对比？

A：与同存储层旧方案（多容器单租户）相比，新方案把容量规划从产品团队收归平台，组织成本显著下降；与 Meta TAO 相比，Habitat 的缓存失效同样走 change data capture 路线，但底层是托管数据库的 change feed 而非自建存储；与自研路线相比，Cosmos DB 多租户方案省掉了存储引擎维护，代价是峰值 QPS 上限和厂商绑定。

Q5：风险和坑？

A：三个：一是缓存失效链路自身就是新的故障面，CDC 服务、Kafka、失效 worker 任何一环出问题都会放大陈旧度，官方为此专门做了死信队列和区域切换；二是”托管服务变联合工程”意味着深度绑定单一云厂商，迁移成本随合作深度同步增长；三是 Rust 重写代理层是整个 Part I + Part II 里投入产出比最难复制的一环，没有对应工程团队时不要轻易启动。

字数自检：正文超 1500 个中文字符
隐私自检：未写入姓名、账号、用户输入、内部网络细节、凭据或会话标识
来源：OpenAI 官方工程博客，2026-10-23，https://openai.com/index/scaling-storage-one-billion-users-part-two