OpenAI Habitat 存储服务用户数突破十亿，但 Python 已到极限

OpenAI 的 Habitat 存储服务如今支持每周有超过十亿人使用的产品，同时每秒处理逾 7000 万次请求。这一规模迫使 OpenAI 将一个内部 Python 库改造成全球分布式服务，随后又用 Rust 替换了大部分 Python 实现。

头部数字只是故事的一部分。根据 OpenAI 的存储架构，Habitat 横跨近 40 个地理区域，服务超过 500 PB 的数据。然而，这个系统在 2023 年起步时，只是位于产品代码与 Azure Cosmos DB 之间的一个小型库。

OpenAI 并非一开始就选定了理想架构，从而达到如今的规模。它接受了技术债，限制开发者对存储层提出的要求，并反复优化已经在生产环境中出现的瓶颈。这条路径让人联想到 Meta 早期围绕 TAO 所做的工作，但 OpenAI 面临的时间表更为紧迫：连续三年实现了超过十倍的增长。

OpenAI Habitat 存储服务成为全球控制层

决定性的变化既关乎组织，也关乎技术：OpenAI 将存储逻辑从数十个应用中抽离，并将其置于一项托管服务之后。

Habitat 最初在 2023 年 OpenAI DevDay 上随 GPTs 一同推出。它最初的任务，是在不暴露底层数据库细节的前提下，为产品工程师提供一组精简的存储操作。

该库负责确定数据的归属位置以及请求是否获得授权。它还负责处理模式查找、路由、加密、序列化、请求整形、缓存和连接池。

这种抽象在 OpenAI 内部传播开来，并没有依赖广泛的强制要求。产品团队可以使用 Habitat，而非直接集成 PostgreSQL 或 Azure Cosmos DB；也可以为其贡献压缩和客户端缓存等共享功能。

当 Habitat 规模尚小时，这种方式行之有效。随着更多 OpenAI 服务采用不同版本的库，且产品需求逐渐分化，管理难度开始上升。

到 2025 年年中，更改存储层需要协调部署数十项服务。由于每个参与应用都需要更新客户端，一条新的路由规则可能要花数天才能完成分发。

OpenAI 描述过一次旨在降低区域故障影响的迁移。工程师希望将关键数据集迁移至多个区域性的 Cosmos DB 账户，这需要新的路由逻辑和受控发布流程。

团队首先通过功能开关加入路由行为，随后协调升级、添加请求镜像以测试拟议路由，并在发现问题后分发修正方案。

当改动终于准备就绪时，一次无关应用的回滚恢复了旧版且存在缺陷的 Habitat 客户端。该回滚重新引入了这次迁移本要降低的确切故障风险。

这一事件暴露出将基础设施策略放进应用库的弱点。库可以简化开发，但每一个部署副本都会成为平台团队必须追踪的另一个版本。

OpenAI 的回应是将 Habitat 转变为独立服务。产品应用继续使用轻量客户端，但路由、访问控制、监控和存储决策都迁移到一个集中运营的接口之后。

这项服务为平台变更创造了单一部署点。OpenAI 可以一次更新路由或可靠性控制，而不必等待每个产品团队发布新代码。

集中化也建立了一个安全检查点。Habitat 可以从单一层级执行授权、记录审计事件，并限制对数据库的直接访问。

这很重要，因为存储请求如今不仅来自面向用户的应用。OpenAI 表示，Habitat 还必须保护资源免受未经授权的内部服务和由智能体驱动的活动影响。

由此形成的系统位于 ChatGPT、Codex、API 平台、内部服务以及多种存储技术之间。Azure Cosmos DB 仍是核心在线存储，而 Valkey、对象存储、Kafka、Rockset 和变更数据捕获服务则支持专门路径。

因此，Habitat 不再只是数据库封装层，而成为 OpenAI 管理快速变化产品组合的策略与流量层。

这种控制解决了部署问题，却带来了新的成本：每次数据库请求如今都必须穿过一个由 Python 实现的网络服务。

为什么十亿周活用户改变了工程优先级

OpenAI 的增长将原本需要数年的基础设施规划，压缩成一连串短期容量决策。

OpenAI 表示，Habitat 支持的产品每周被超过十亿人使用。该公司没有提供按产品划分的明细，因此这一数字不应被理解为经核实的独立 ChatGPT 账户数量。

该系统目前每秒处理超过 7000 万次请求，承载逾 500 PB 数据，并在近 40 个地理区域运行。

这些数字不同于 Habitat 在 Python 时代的早期吞吐量。OpenAI 表示，Python 实现在迁移至 Rust 前的峰值超过每秒 2000 万次请求；更大的 7000 万数字描述的是发布时更广泛平台的规模。

这一差别很重要。Habitat 的故事并不是一个 Python 程序突然处理了平台当前的负载，而是服务代码、代理、缓存、数据库和区域基础设施经历了一系列渐进式架构变更。

OpenAI 表示，其需求连续三年同比增长超过十倍。传统的容量规划通常会为系统预留十倍增长空间，并预期这部分余量能维持数年。

Habitat 却在一年内反复耗尽这一余量。工程师必须在为下一次极限到来前准备好替代方案的同时，从现有设计中挖掘更多容量。

这一时间表改变了团队评估技术债的方式。迁移至服务增加了 CPU 使用、内存消耗和网络延迟，却立即减少了部署协调成本。

OpenAI 接受了这些成本，因为运营控制已成为更紧迫的约束。当每一次平台改动都需要与数十个应用团队协调时，理论上高效的客户端库已不再真正高效。

这种取舍也给 Microsoft Azure 带来了压力。Habitat 高度依赖 Cosmos DB，而其模型会将数据和吞吐量分布在逻辑分区与物理分区之间。

Microsoft 的 Cosmos 分区文档说明，分区键的选择决定了数据和请求能够多均匀地分布。糟糕的分区键可能会集中流量、造成热点分区，或迫使系统执行代价高昂的跨分区查询。

在 Habitat 的规模下，这些问题会成为全平台风险。OpenAI 无法将数据放置、分区和区域容量视为某个单一产品团队的实现细节。

转向中央服务让 OpenAI 有了一个协调这些决策的统一位置，但也将故障责任集中在一个几乎所有主要产品都依赖的层级中。

一次缓慢的 Habitat 请求可能延迟身份验证、设置访问，或 ChatGPT 对话的开始。一次失败的存储路径可能阻止相关产品操作完成。

一次用户操作可能触发数百次数据库调用。用户感受到的是最慢的相关调用，而不是其他请求的平均性能。

这使尾部延迟——即请求分布中最慢的部分——比令人满意的平均值更重要。少量卡住的调用，可能影响大得多比例的用户交互。

这种规模也改变了微小低效的含义。每个工作进程额外占用的一点内存，在系统需要庞大工作进程集群时会变得可观；稍微失衡的连接池，也可能将数百万请求导向已承受压力的进程。

Habitat 让 OpenAI 陷入两难。公司需要立即获得集中控制，但最快的实现语言所带来的成本，会随着每一位新增用户而增长。

OpenAI 如何将 Python 扩展至经济性崩溃

Python 之所以仍然可行，是因为 OpenAI 严格控制了并发、请求行为和下游连接，并非因为该语言的开销消失了。

OpenAI 知道，与运行在每个应用内部的库相比，网络化 Python 服务会增加延迟；在相同工作负载下，它也会消耗更多 CPU 和内存。

团队仍推迟了重写。在系统 API 尚持续变化时，产品稳定性和一致的存储接口比早期资源优化更重要。

Habitat 使用 asyncio，这是 Python 用于在事件循环上并发运行大量输入输出操作的框架。并发让一项任务在等待网络响应时，另一项任务能够取得进展。

它并不会自动提供 CPU 并行能力。asyncio 事件循环会调度回调和任务，但 CPU 密集型工作仍可能延迟同一进程中其他已就绪的任务。

Habitat 承担的 CPU 工作比简单网络代理更多。其职责包括加密、压缩、校验和、路由、健康检查、请求镜像和对冲请求。

OpenAI 发现，即使下游存储可以迅速返回，Habitat 协程仍可能等待再次被调度。在高利用率下，事件循环延迟可达数百毫秒，极端情况下甚至数秒。

团队直接测量了这一延迟：他们定期调度后台任务，并比较其预期执行时间与事件循环实际运行它们的时间。

这一信号暴露出标准 CPU 或内存平均值中不可见的压力。一个进程表面上可能仍在正常运行，但已就绪的请求却在 CPU 密集型任务之后等待。

OpenAI 的应对方式是限制每个进程的并发请求数，然后增加工作进程数量，以基础设施规模换取更可预测的尾部延迟。

这一策略使单个事件循环不那么拥挤，但也增加了连接数量，并提高了压垮下游服务的风险。

功能开关处理造成了另一个延迟尖峰。Habitat 使用的 Statsig 配置最初包含来自整个 OpenAI 的生产规则，并且每分钟刷新一次，却没有随机化时机。

每个 Pod 最多可运行八个 Python 进程。这些工作进程有时会几乎同时解析大型配置，暂时将 CPU 从活跃请求中分流。

性能分析揭示了这一模式。OpenAI 缩小了配置范围、延长刷新间隔，并加入抖动，以避免工作进程同时执行该任务。

连接复用则带来了更隐蔽的故障。一些 Habitat 进程接收到的并发量是平均值的五到十倍，因为客户端连接未能均匀分配流量。

Python 的 aiohttp 连接器以“后进先出”顺序复用连接。在流量突增后，较慢的服务器会更晚归还连接，使这些连接排到复用队列前端。

新请求随后又被返回给较慢的进程。这些工作进程变得更慢，进一步加剧了路由失衡。

系统进入了一种亚稳态：即使最初的流量高峰结束后，性能仍持续恶化。Meta 曾在其网络基础设施中记录过类似的亚稳态故障，其中失衡会持续存在，直至外部干预改变条件。

OpenAI 测试了连接生命周期限制，并确认连接复用行为是问题的成因之一。随后，它将连接池改为先进先出复用，从而打破了这一反馈循环。

Habitat 目前主要依赖 Istio 和 Envoy 实现连接池与感知负载的均衡。Envoy 还会将上游 HTTP/1 流量转换为多路复用的 HTTP/2 连接，让大量请求共享更少的下游连接。

这种汇聚机制可保护数据库和网络基础设施免受“惊群效应”冲击。所谓惊群效应，是指大量工作进程同时对同一依赖项建立连接或重试任务。

代理层的速率限制和熔断器提供了额外保护。与期待每个 Python 进程独立响应相比，集中执行的效果更好。

这些措施让 Python 的处理能力超过每秒 2,000 万次请求。它们也使该平台成为 OpenAI 内部计算资源消耗最大的服务之一。

按 CPU 核心数计算，Habitat 成为 OpenAI 第二大的服务。根据工程团队的说法，其 Envoy 部署规模在公司内部排名第四。

到这一阶段，继续横向扩展 Python 工作进程已不再是中性的运维选择。资源开销会与其他服务争夺容量，同时增加平台需要管理的连接数量。

这种语言已经完成了其战略使命。OpenAI 已稳定接口并集中化存储策略，但持续增长使更高效的实现方式不可避免。

真正的机制是更小的存储契约

Habitat 之所以能达到这一规模，是因为它限制了应用程序可以请求的内容，将复杂性从关键在线路径中移走。

仅靠语言优化无法解释 Habitat 的吞吐量。OpenAI 还将该服务限制为计算成本可预测的简单操作。

Habitat 提供基于对象和边的 NoSQL 接口。产品团队定义对象类型、关系和直接查找，而不是发送任意 SQL 语句。

该模型借鉴了 Meta 的 TAO design，这是 Facebook 为其社交图谱开发的地理分布式存储系统。TAO 同样采用受约束的查询接口，以服务规模巨大的读取负载。

Habitat 将对象及其边放置在同一个存储分区中。这使直接关系查询更容易进行水平扩展。

该服务并不试图将每一个相连的远程对象放在同一数据库区域或分区内。因此，跨越多层关系的遍历可能需要调用不同的 Cosmos DB 账户。

OpenAI 接受这种低效，因为 Habitat 的在线路径不提供不受限制的图遍历。应用程序可以获取对象的直接边，但不能向服务提交任意图查询。

这种约束可防止单个请求膨胀为不可预测的工作量。无界扇出会使容量规划变得困难，因为一次成本很低的客户端操作可能产生大量存储调用。

OpenAI 曾在 PostgreSQL 上遭遇这种失衡。当公司规模和其 schema 集合都较小时，工程师能够审查查询，并确认关键路径使用了索引。

随着团队和产品增多，这一审查流程不再具备可扩展性。OpenAI 表示，繁忙路径上代价高昂的新查询反复成为数据库故障的原因。

SQL 本身并不是问题。运维层面的难题在于，一条简洁的查询可能要求执行扫描、连接，或采用共享平台难以控制成本的执行计划。

Habitat 让高成本行为对应用程序更加可见。如果某个产品需要多跳关系查询，其代码必须显式发出这些操作。

这一设计牺牲了开发便利性和查询灵活性。但它也为存储平台提供了可预测的工作单元，使其能够进行隔离、路由、限流和度量。

对于复杂查询，OpenAI 使用独立路径。变更数据捕获（CDC）会以近实时的新鲜度将更新从 Habitat 流式传输至隔离的 Rockset 实例。

每个客户端团队自行扩展其 Rockset 资源。因此，分析和重搜索请求不会直接与身份验证、对话启动或其他事务性操作竞争资源。

这种划分与大型在线系统中的一种更广泛模式相似：主存储负责有边界、对延迟敏感的操作，而次级系统支持灵活搜索和分析。

这一模式也厘清了谁来承担复杂性。Habitat 简化了最安全的常见操作，但产品团队必须围绕其限制进行设计，或运行独立基础设施。

当产品需要丰富的遍历或过滤功能时，这种选择可能会减缓功能开发。与能在服务器端执行连接操作的数据库相比，它也可能产生更多应用程序请求。

OpenAI 认为，这种摩擦优于不可预测的共享服务。在每秒 7,000 万次请求的规模下，一项具有意外扇出的灵活操作很快就可能引发平台事故。

这正是 OpenAI Habitat 存储背后的核心机制。平台通过拒绝提供某些数据库能力实现扩展，然后在最敏感路径之外提供隔离的替代方案。

对于构建内部知识系统的工程团队而言，这一教训的意义不止于 OpenAI。当事务性检索与重型分析拥有明确边界时，可搜索的知识库同样会从中受益。

关键区别在于实用的抽象与无限制的抽象。Habitat 为开发者提供了更简单的接口，但其规模化依赖于刻意保持该接口的狭窄。

Rust 降低了成本，但这些说法仍需背景说明

OpenAI 的 Rust 重写产生了引人注目的内部效率数据，但该公司尚未公布足够的方法细节，无法进行独立比较。

OpenAI 于 2026 年第二季度启动了完整服务重写。该公司称，两名工程师在 Codex 和 GPT-5.5 的协助下完成了这项工作。

截至发布时，Rust 服务已处理 Habitat 95% 的生产请求。OpenAI 计划在数周内移除剩余的 Python 实现。

该公司报告称，Rust 的 CPU 用量仅为 Python 版本的六分之一，内存用量仅为十五分之一。它还报告了更低的平均延迟和尾延迟。

这些数字很重要，因为 Habitat 已成为内部计算资源的重要消耗者。当这种六倍 CPU 改进应用于每秒数千万次请求时，可以释放可观的容量。

这次重写也检验了一项在 AI 辅助软件开发领域流传的观点。OpenAI 有意推迟迁移，部分原因是预计未来的编程模型会让后续重写更加容易。

据该公司称，这一押注得到了回报。在其接口和运维要求成熟之后，两名工程师和 OpenAI 的模型将这一既有服务迁移至 Rust。

这一过程比简单的 Python 与 Rust 对比更重要。OpenAI 并未要求模型从零开始发现 Habitat 的需求。

多年的生产实践已经定义了 API、指标、故障场景、路由规则、部署模式和兼容性边界。这些积累的知识降低了工程师和编程代理面临的不确定性。

因此，这次重写支持的是一个更有限的结论：对于行为稳定且生产信号丰富、已被充分理解的服务，AI 编程工具可以减少移植所需的人力。

它并不能证明两名工程师可以安全替换任意大型 Python 平台。OpenAI 尚未公布服务代码规模、测试覆盖率、审查工作量、事故记录，或相邻团队提供的总体支持。

效率对比同样来自 OpenAI 的内部测量。该公司未披露工作负载归一化方式、硬件细节、编译器配置，或每项测量所涵盖的精确边界。

读者应将六倍和十五倍的数据视为报告中的生产结果，而非可普遍复现的语言基准测试。

围绕运维复杂性还存在另一个未解问题。Rust 可以减少资源使用，并提供更强的编译期检查，但它也提高了部分贡献者所需的技能门槛。

Python 使 OpenAI 能够快速调整早期平台。在存储契约仍在成形时，产品工程师可以理解并修改共享客户端。

在该契约稳定后，Rust 实现会更容易得到合理化。若更早进行重写，可能会减缓试验速度，却无法消除之后仍需进行架构调整的必要性。

迁移也不会消除 Habitat 的其他扩展限制。数据库分区、区域容量、负载均衡、缓存行为和下游连接限制仍是相互独立的考量。

OpenAI 自己的说明也明确了这一点。服务重写只是 Habitat 的一部分，而存储层及其与 Cosmos DB 的合作承担了更大的 500 PB、每秒 7,000 万请求的工作负载。

该报告对 Python 的临时角色也异常坦率。OpenAI 将首个服务实现描述为有意承担的技术债务，以在超高速增长期间重新获得控制权。

这种表述为其他工程组织带来了有益的挑战：当团队明确其所解决的约束、衡量不断累积的成本，并定义替换信号时，技术债务是可以辩护的。

当“临时”基础设施没有迁移触发条件时，为其辩护就会变得更困难。Habitat 在其工作进程数量、核心资源消耗和持续增长使资源效率成为战略性问题时，越过了这一触发点。

OpenAI 关于编程模型促成迁移的主张尤其难以单独验证。该公司构建 Codex 和 GPT，提供工程师，拥有目标系统，并自行发布评估结果。

更有力的验证应包括详细的迁移指标。有价值的数据应涵盖工程师工时、生成代码的接受率、审查期间发现的缺陷、生产回归问题，以及上线后的维护工作。

在这些细节公布之前，这次重写是来自大型生产部署的可信证据，但并非对 AI 生成系统代码的受控评估。

OpenAI Habitat 存储接下来必须证明什么

下一项考验在于：随着 Rust 迁移、区域覆盖范围和存储量持续扩张，Habitat 能否维持可预测的延迟与隔离性。

第一个信号是彻底淘汰 Python。OpenAI 表示，剩余 5% 的生产流量将在数周内迁移，这使得转型成为一项近期的兼容性考验。

顺利淘汰将强化该公司关于低干扰重写的说法。若长期双轨运行或反复回滚，则表明剩余流量包含的困难依赖项可能比所报告的比例暗示得更多。

关键衡量标准并不只是 Rust 是否接收所有请求。OpenAI 必须在授权、路由、加密、影子流量、速率限制以及面向特定产品的兼容性方面保持行为一致。

第二个信号，是即将发布的 Habitat 数据库层技术说明。OpenAI 表示，下一篇内容将介绍多租户可靠性、分层读取优化，以及其与 Azure Cosmos DB 的合作。

这篇文章应能说明，超过 500 PB 的数据如何部署在近 40 个区域。它还应解释 Habitat 如何隔离高噪声租户，同时避免浪费大量预留容量。

数据库方面的证据可能会强化本文的核心判断。如果 OpenAI 能展示受控的运维操作、有效的分区策略和区域控制措施如何协同工作，Habitat 将更像是一套可持续的平台架构。

如果下一篇说明主要依赖于非常规的大规模容量配置，那么当前设计可能更难被其他组织复制。

第三个信号，是 Habitat 在产品持续增长期间的表现。该公司称，其用户和流量增长仍在加速，因此如今 7000 万请求的峰值不会是最终目标。

读者应关注后续公开的尾延迟、事故遏制能力和单请求资源使用量变化。这些指标能够反映，效率提升是否正转化为用户可感知的可靠性。

它们也能显示，集中化是否带来了不可接受的影响范围。一个控制层可以简化升级，但该层的缺陷可能会同时波及 ChatGPT、Codex、API 和内部服务。

Habitat 的演进并未提供一套扩展 AI 产品的万能方案。相反，它展现了一系列与各阶段最关键约束相对应的决策。

OpenAI 最初通过一个库来优化开发者接入。随后，它以局部效率换取集中式控制，对请求模型施加约束，调优 Python 的故障模式，并在资源成本成为主导因素后重写了服务。

这套决策序列才是更具可迁移性的成果。团队很少能在需求到来前就确定最终架构，尤其是在产品与流量同步变化时。

实际问题在于，他们能否保留足够的可观测性和接口规范性，以便日后替换临时组件。OpenAI 表示，Habitat 做到了这一点，代码模型帮助加速了最终迁移。

对于开发者和企业买家而言，OpenAI Habitat 存储也揭示了一个看似简单的提示框背后隐藏的系统。一次对话的开始，可能依赖于平台中数百次查询，而其中最慢的一次调用将塑造整体体验。

关注 Python 的退役、即将发布的 Cosmos DB 分析，以及 Habitat 下一组延迟数据。这些信号将共同表明，OpenAI 构建的是持久的存储基础，还是这场异常迅速的基础设施竞赛中的又一个临时阶段。