Jon Lee、Hrachya Hakobyan 与 Chaomin Yu 联合撰写了一篇技术复盘，披露了 OpenAI 核心存储平台 Habitat 的底层演进细节。很多工程团队往往对公有云托管服务抱有一种浪漫幻想，以为只要掏出足够预算，商业数据库宣称的无限弹性就能抹平一切容量与可用性泥潭。
但 Habitat 面临的是超 10亿 ChatGPT 用户、全球 40 个地理区域、总量超过 500 PB 数据，以及高达 7000万请求/秒 的综合峰值。在这套数字基座之下，没有理所当然的开箱即用。为了支撑这种体量，OpenAI 与微软 Azure 团队在底层 NoSQL 数据库 Azure Cosmos DB 上走了一场戏剧性的技术轮回。
弱分区的物理死穴
在迁移至 Cosmos DB 之前，OpenAI 的早期存储基于 Postgres。随着组织规模扩张，高热点组织与键值碰撞频发，未命中的缓存雪崩多次击穿底层数据库，促使团队自研 Habitat 存储抽象层并转投 Cosmos DB。
然而云托管并不是避风港，它只是把机械磁盘的物理限制转换成了分摊逻辑上的抽象漏洞。在 Cosmos DB 的设计中，一个容器被分配若干每秒请求单元（RU/s），数据根据逻辑分区键打散到有限的物理分区上。每个物理分区的吞吐量上限是 10,000 RU/s，而文档中宣称的逻辑分区配额并非独占，必须与落在同一个物理分区内的所有其他键值共享。
这就诱发了一个隐蔽的系统级故障：弱分区。当容器的总预置吞吐量固定时，随着写入数据量持续膨胀，一旦物理分区达到存储容量上限，系统就会自动将一个物理分区分裂成两个。分裂之后，总预置吞吐量被更密集的物理分区平分，每个分区实际能分到的 RU/s 额度反倒缩水了。
对于存放大量文件和上下文的大容量存储场景，调用频率哪怕没有任何增加，仅凭数据存储体积的自然增长，就能将有效吞吐量腰斩。这种吞吐量被逐步稀释的分区沦为弱分区，随之而来的便是冷门长尾功能突发的突增流量直接挤占物理节点配额，顺道把关键的用户登录与注册通道一并拖死。
隔离代价与微软的特权级补丁
为了截断单点故障的扩散半径，OpenAI 曾全面倒向单租户架构：强令各业务线创建各自独立的 Cosmos DB 容器。
这种业务隔离保住了核心系统的稳定性，却带来了严重的工程组织阻力。独立容器切断了多业务混合削峰填谷的平滑红利，要求每个产品团队必须具备精确的容量规划能力。新功能在内部测试时可能只需要 1,000 RU/s，发布当天瞬间爆发至百万 QPS，业务工程师经常遗漏提前预置，导致系统上线变成故障抢修。各自为政的超额预置更让基础设施账单迅速失控。
由于单租户无法在工程组织层面维系，OpenAI 只能掉头重新回归多租户模式，前提是由微软 Azure 团队在底层开辟特例通道。
微软公开文档中通用的 Serverless 配额上限长期停留在 5,000 RU/s/分区，且仅根据存储用量触发分裂。而 Azure 团队为 OpenAI 专门定制了增强型 Serverless 模式：不仅将单物理分区吞吐能力拔高到 10,000 RU/s，还新增了基于 RU 用量突增的主动分裂机制。
再叠加针对高热 Key 的单独流控，以及对离线批处理请求降级的 QoS 优先级调度，Habitat 借由云厂商的特例代码，才在单容器里稳住了业务混合负载。
任何全托管云服务的平稳表象，一旦越过规模临界点，都是靠底层的特权定制在硬撑。
10毫秒延迟背后的拦截网
很多行业观望者将 7000万 rps 与全球读延迟中位数 10 ms 的战绩，简单归功于 Cosmos DB 的全球多活。如果不看技术栈全貌，这种解读会带来灾难性的选型误判。
7000万 rps 是 Habitat 平台的综合吞吐，而非 Cosmos DB 底层承载的计费 RU 消耗。如果所有流量都直穿数据库，再庞大的预算也会被瞬间烧穿。
事实上，Habitat 的读延迟中位数早期高达 120 ms。能将其压制到 10 ms，关键在于这套系统在数据库上方筑起的三道防线：
- 就近部署的 Valkey 缓存层，在边缘截断了绝大多数常规读请求；
- 基于 Change Data Capture（CDC）的数据流失效机制，让各区域缓存能以极小开销同步变更；
- 将中间件性能瓶颈用 Rust 重构，剥离了早期 Python 服务层带来的序列化损耗。
依赖这种层层拦截，绝大部分热流量根本没有碰到 Cosmos DB 的物理盘。
- 风险.普通团队若在公有云上盲目照搬该方案，直接使用通用版 Cosmos DB 承载激增业务，不仅无法获得定制版的 RU 动态分裂，更会因缺少复杂的边缘缓存与多级一致性设计，直面高昂的账单账面与弱分区瘫痪。
终局：在断电与账单之后谋求脱钩
即便与云厂商结成深度的共管关系，裂痕依然会暴露。
2024 年底，一次突发断电袭击了 OpenAI 核心 Azure Cosmos DB 主区域。在随后的灾备演练中，团队发现超大账户的跨区域故障转移耗时数小时。更棘手的是，在随后的回切操作中，客户端网关逻辑缺陷引发了严重的连接风暴，大量请求在物理分区尚未就位前瞬间涌入，导致级联中断。托管服务的黑盒属性，在极端事故中展露无遗。
更深层的张力在于经济账本。面对超 500 PB 的规模，Cosmos DB 依赖全闪存支撑的商业计费，正在成为昂贵的财务负担。
OpenAI 在文末给出了明确转向：团队正基于 RocksDB Cloud 与 Raft 共识算法自研下一代分布式存储引擎。这一动作释放了极具价值的信号——在极高写入与吞吐场景下，他们宁愿牺牲一部分极端峰值性能，也要换取存储分层能力以大幅压低硬件成本。
从自建 Postgres 出走，到寄宿于全托管 Cosmos DB，再到联合打补丁的共管容器，最终走向基于开源生态重构私有存储引擎。技术架构绕了一大圈，顶级 AI 公司最终发现：没有哪家云厂商的商业产品，能永远替自己承担最底层的物理现实。