从 Python 库到分布式存储平台

OpenAI 于 9 月 11 日发布工程博客，披露其在线存储平台 Habitat 的演进。Habitat 目前每秒处理超过 7000 万次请求，每周服务超过 10 亿用户，管理的数据规模超过 500PB，覆盖近 40 个地理区域。它支撑着 ChatGPT、OpenAI API、Codex 等产品的数据存取。

Habitat 诞生于 2024 年中，最初是一个与 ChatGPT 主服务器交互的 Python 客户端库，底层对接 Azure Cosmos DB。其目标是让产品工程师无需直接管理数据库即可完成数据存取，系统代为处理数据类型识别、路由、授权、加密、序列化与连接池管理。

一次故障促成架构拆分

随着 OpenAI 产品数量与数据需求增长，客户端库架构在 2025 年中暴露出局限：每次修改共享库都要协调数十个服务部署，发布周期以天计，故障风险随之升高。OpenAI 因此将 Habitat 改造为独立服务，统一管控部署、监控与平台能力，并形成数据安全的一致性控制点——集中执行访问控制、审计日志与底层存储资源权限管理，防范外部、内部与智能体程序对用户数据的未授权访问。

为何离开 Python

OpenAI 在博客中将早期选择 Python 称为”有计划的战略技术债”：优先保证平台稳定与产品迭代速度。但在高并发场景下，Python 的 CPU 与内存开销成为瓶颈，尤其难以压住请求尾延迟。团队通过限定单进程并发、增加工作进程、优化异步调度，以及把连接复用策略从后进先出（LIFO）改为先进先出（FIFO），缓解了负载向慢进程聚集的问题。

2 名工程师加 AI 编码工具完成重写

2026 年第二季度，OpenAI 投入 2 名工程师，并借助 Codex 与 GPT-5.5，将 Habitat 整体用 Rust 重写。官方数据显示，新的 Rust 服务目前已承接 95% 的生产请求，CPU 效率提升 6 倍、内存效率提升 15 倍，平均延迟与尾延迟同步下降。OpenAI 计划在未来数周内彻底弃用 Python 版本。

工程启示

OpenAI 称，超大规模系统的现实路径往往不是一开始就追求”最优”，而是先让控制面、稳定性与产品迭代跑起来，再择机清偿性能债务。Habitat 还参考 TAO 模型只暴露可控的 NoSQL 风格接口，把复杂分析查询通过变更数据捕获（CDC）分流至 Rockset，避免拖累在线存储。后续文章将介绍其 Azure Cosmos DB 存储层扩展与多租户可靠性优化。