OpenAI公开了支撑ChatGPT的在线存储平台Habitat，说明该平台已在近40个地区为每周超10亿用户提供服务，并管理超过500PB数据。文章介绍了Habitat从Python客户端库演进为集中式服务、以Rust重写以显著提升效率，以及在线/离线层分工和安全控制的工程实践与挑战。
OpenAI公开了支撑ChatGPT及其他产品的一套在线存储平台Habitat。公司称，这个平台目前每秒处理超过7000万次请求，在近40个地理区域为每周超过10亿人使用的产品提供数据服务，并管理超过500PB数据。
这篇题为《Rapidly scaling online storage to serve over 1 billion ChatGPT users》的工程文章，是OpenAI两篇在线存储技术系列文章中的第一篇。文章重点并不是公布一种全新的数据库，而是解释一个原本简单的Python客户端库，如何在用户和产品需求连续多年以超过10倍速度增长的情况下，逐步演变为集中式存储服务。
这一披露也说明，ChatGPT的规模问题已经不只是模型推理所需的GPU问题。登录、读取账户设置、启动对话，以及Codex等产品中的大量操作，都会触发一连串数据查询。对用户而言，任何一个关键查询变慢，都可能表现为整个产品变慢；查询失败，则可能直接变成服务中断。
从一个Python库变成统一的存储服务
Habitat最初在2024年年中建立，是一个供ChatGPT主服务器调用的小型Python库，底层连接Azure Cosmos DB。它的目标是让产品工程师不必直接处理数据库管理，而是通过统一接口完成数据存取。
按照OpenAI的描述，Habitat替产品团队处理了模式查找、路由、授权、加密、序列化、请求整形和连接池等工作。随着产品团队不断加入客户端缓存、压缩和加密等功能，这个库迅速成为多个产品共享的基础层。
但客户端库的模式也带来了新的运维问题。到2025年年中，Habitat需要支持更多服务，协议变化必须协调数十个客户端同时部署。OpenAI举例说，为了将部分关键数据迁移到多区域分布的Cosmos DB账户，团队需要把新的路由逻辑推送到所有客户端、进行影子流量测试，再逐步打开功能开关。任何一个服务回滚到旧版本，都可能重新引入已经修复的问题。
因此，OpenAI把Habitat从客户端库改造成独立服务。这样做的核心目的不是立刻追求最低成本，而是建立一个统一的部署、观测和策略控制点。数据访问控制、审计日志，以及对底层Cosmos DB资源的限制，也可以集中执行。这一点对需要处理用户数据、内部系统和AI代理访问权限的产品尤其重要。
Python的代价：尾延迟成为主要问题
OpenAI没有一开始就把Habitat改写成更接近底层硬件的语言。公司承认，以Python运行高吞吐服务会增加网络延迟，也会带来更多CPU和内存成本，但当时更紧迫的任务是稳定平台、确定核心API，并让产品团队能够继续开发。
Habitat不仅负责转发数据库请求，还要处理路由、压缩、加密、校验和、下游健康检查、请求影子测试和请求对冲等工作。这些任务中有相当一部分消耗CPU。Python的asyncio可以并发处理输入输出，却不能绕过全局解释器锁来提供CPU级并行，因此调度延迟会直接影响高分位延迟。
OpenAI表示，在早期服务版本中，即使下游存储已经快速返回，请求也可能因为负责的协程没有及时获得调度而停顿。团队因此不仅监控CPU、内存、网络和磁盘，还持续测量事件循环的调度延迟，并限制每个进程同时处理的请求数量，再通过增加Python工作进程的方式扩展吞吐。
一次实际的性能排查还发现，Statsig功能开关配置每分钟同时刷新，而且每个配置包含所有生产规则。多个Python进程在同一时间解析这些配置，造成周期性的CPU尖峰和事件循环抖动。OpenAI通过降低配置规模、增加随机抖动等方式，减少了这类与主业务无关的集中式负载。
两名工程师、代码模型与一次Rust重写
随着Habitat成为OpenAI按核心数计算的第二大服务，继续使用Python的成本越来越明显。公司称，在2026年第二季度，两名工程师借助Codex和GPT-5.5，把整个服务重写为Rust。新的Rust版本目前承载95%的生产请求，Python版本计划在随后几周内退役。
OpenAI报告称，Rust服务的CPU效率是Python版本的6倍，内存效率是后者的15倍，同时平均延迟和尾延迟也明显降低。这里的数字来自OpenAI自身的生产数据，文章没有提供独立机构的复核结果，也没有披露完整的测试条件，因此更适合视为公司工程团队对迁移结果的总结，而不是可直接复制的通用基准。
这次迁移还带有一个更广泛的含义：OpenAI把代码模型本身视为基础设施升级的一部分。公司在文章中表示，推迟Python重写一年，给了团队时间先解决架构和可靠性问题；等到必须迁移时，Codex和GPT已经足以帮助完成规模可观的服务重写。它并不意味着AI可以替代系统工程师，但显示出代码代理开始参与大型生产系统迁移的可能性。
500PB数据不能只靠一个查询模型
Habitat对外提供的是一种围绕对象和边的NoSQL接口。客户端预先定义对象类型和边类型，系统把一个对象及其关联边放在同一个存储分区中，以便横向扩展。这种设计有利于分片，却不适合复杂的多跳图遍历：一次查询可能需要从不同区域、不同Cosmos DB账户读取相互关联的对象。
OpenAI的处理方式是把简单查询留在在线存储层，把复杂分析和搜索需求转移到独立的离线视图。Habitat通过变更数据捕获把数据近实时传输到Rockset，再由各个客户端团队自行扩展Rockset实例。这样做牺牲了一部分使用便利性，却把重读、分析和搜索负载与在线交易隔离开来。
这种“在线层负责简单、稳定、低延迟访问，离线层负责复杂查询”的分工，与OpenAI此前披露的PostgreSQL扩展策略相互呼应。在《Scaling PostgreSQL to power 800 million ChatGPT users》中，OpenAI称其通过一个主实例和近50个跨区域只读副本处理数百万级每秒查询，同时把可分片、写入密集型负载逐步迁移到Azure Cosmos DB等系统。InfoQ对这一架构的报道也指出，OpenAI把PostgreSQL保留给更适合关系模型和强一致性的工作负载。
“十亿用户”需要区分统计口径
OpenAI在Habitat文章中使用的是“每周超过10亿人”这一口径，描述的是由该平台支撑的产品覆盖范围，并没有在这篇工程文章中进一步说明统计方法或用户定义。
这与路透社6月援引Sensor Tower估计的“ChatGPT应用在2026年5月达到10亿月活跃用户”并非同一个指标。路透社报道说，ChatGPT应用达到10亿月活跃用户的时间约为上线三年后；这是第三方市场数据机构对应用使用情况的估计。两组数字都反映出ChatGPT的规模，但不能简单相加，也不能把月活跃应用用户直接等同于Habitat覆盖的每周产品用户。
存储平台也成为安全控制面
Habitat的变化反映了一个容易被忽视的趋势：当AI产品开始连接更多应用、文件和代理工具时，存储层不再只是保存数据的后台组件，也成为权限和安全策略的执行位置。
在集中式服务中，OpenAI可以统一实施访问控制、审计记录、加密和底层资源隔离。对代理而言，这意味着系统需要回答的不只是“数据在哪里”，还包括“哪个代理、代表哪个用户、以什么权限、在什么时间访问了哪些数据”。AIFlux此前关于AI代理接入云数据库的报道显示，临时凭据、命令分级和人工确认，正在成为这类工具设计中的重要控制点。
同样，在线数据基础设施的成本也正在影响产品架构。多云和本地计算环境会让数据迁移、缓存和出网费用成为实际瓶颈；此前AIFlux对跨云零出网存储的报道，也体现了存储位置与计算位置逐渐分离后的工程取舍。
下一步仍是多租户和Cosmos DB扩展
OpenAI称，这次公开的文章只是两篇系列文章的第一部分。下一篇将讨论Habitat如何在多租户环境中维持可靠性、如何分层优化读取性能，以及它如何与Azure Cosmos DB合作，应对更高的需求。
因此，当前披露仍留下几个问题：500PB数据在不同数据类型、区域和租户之间如何分布；70M以上每秒请求中，缓存命中与底层数据库访问分别占多少；Rust迁移后节省的资源是否能够抵消用户增长；以及跨区域故障切换和数据一致性如何在更大规模上维持。
可以确认的是，OpenAI正在用一套由在线服务、分片存储、缓存、离线视图和严格访问控制组成的组合架构，应对ChatGPT的快速扩张。尚不能据此推断单一技术路线适用于所有AI产品。Habitat更像是一份关于超高速增长如何迫使系统不断重排职责的工程记录：先让产品继续运行，再把分散的复杂性集中起来，最后用更高效的运行时替换已经承担过渡任务的旧组件。