OpenAI 在 2026 年 10 月底放出了 Habitat 存储平台扩容系列的第二篇，讲清了一件反直觉的事：给超过 10 亿用户做在线存储，最后不是堆更多机器，而是把租户策略、缓存失效、服务语言三件事重新做了一遍，换来全局读 p50 延迟从约 120 毫秒降到约 10 毫秒、提升 12 倍。Habitat 支撑着 ChatGPT、API、Codex 等所有在线服务，横跨 40 个区域、超过 500 PB 数据，最大的一个 Cosmos DB 账户顶到数千万 QPS。
多租户绕了一圈
Habitat 的多租户设计走了三个阶段，中间还开过一次倒车。最早直接依赖 Azure Cosmos DB 原生原语，所有负载挤在一个默认容器里，靠逻辑分区键 10K RU/s 的上限做背压。问题很快冒出来：热键冲突、吵闹邻居——一个小众功能的负载能干扰核心登录注册——以及"弱分区"：数据一涨物理分区就分裂，每片分到的吞吐反而变小，分裂前 10K RU/s 分裂后变成每片 5K RU/s。
于是第二阶段改单租户，给最关键的新用例开独立容器做强隔离。隔离解决了，容量规划却崩了：产品团队发功能前忘了扩容，发布日进 SEV 房间临时救火，这招在组织层面根本扩不动。
第三阶段又回到共享容器，但这次带着修好的工具：热键限流优先掐最热的键、请求分层 QoS 保护交互式流量、加上 Azure 专门为 OpenAI 做的改进版 serverless——物理分区提到 10K RU/s、按 RU 使用量分裂。回归共享之后，几个月里零配置事故、零吵闹邻居。
全局缓存的失效是难点
读请求占 Habitat 的九成以上，而计算和存储常不在一个区域，跨区域读不可避免。做法分四层：容量允许时把数据放用户附近，但很多区域放不下那么大的存储足迹；只把延迟最敏感的数据集高复制，比如每次请求都要的认证元数据，最多复制到全部 40 个区域；剩下的全靠一层集成的 lookaside 缓存，放在 Valkey 里贴近用户。
缓存最难的不是命中，是失效。传统 TTL 在命中率和新鲜度之间两难，显式失效又会在多区域下跟底层复制产生竞态。Habitat 的解法是拿 Azure Cosmos DB 的 change feed 做 CDC，在数秒内把失效信号广播到全球——服务消费 change feed，对本地缓存做失效，下次读取 miss 再回填最新值。这套思路借鉴了 Meta TAO 的做法。
服务本身也重写了
最后一步是把 Habitat 服务从 Python 重写成了 Rust，压代理开销、降延迟。三个动作叠加——数据复制到就近区域、区域内缓存上线、Rust 重写上线——对应了读延迟下降的三个节点，最终落到 12 倍。最慢的那部分请求仍要跨区域回底层存储取未缓存数据，官方说等更多容量上线后再解决"一开始就把数据放对位置"的问题。
对开发者意味着什么
这篇最值钱的是两句话。一句是"托管服务到了这个规模，就不再那么托管了"：OpenAI 自称是唯一以这种规模部署 Azure Cosmos DB 的公司，2024 年末一次停电后最大账户要数小时才能故障转移，双方都没在这么大规模下演练过，于是进入共管模式，联合监控、共用生产级测试账户、Teams 直接互找。另一句是缓存失效的姿势：用 change feed 的 CDC 做全局失效，而不是纯 TTL，这招在自建缓存层时能直接抄。
待观察
结尾抛了个更大的：为了下一个十亿，OpenAI 在自研 exabyte 级存储，用 RocksDB Cloud 内核加 Raft 复制，走分离式存储换更省闪存，代价是峰值 QPS 更低。这套东西成了，托管 Cosmos 的边界会再往外挪一格。另一个要打问号的是 12 倍这个数字的口径——它是读 p50 的全局均值，最慢那批请求仍要跨区域回源，对尾部延迟的用户，体验改善未必一致。