OpenAI在9月11日披露了内部在线存储平台Habitat的扩展过程。官方给出的规模很直观：这套平台目前支撑每周超过10亿用户，覆盖接近40个地理区域，每秒处理超过7000万次请求，服务的数据规模超过500PB。它最初只是2023年DevDay前后为GPT产品准备的一层Python客户端库，如今已演变为连接Azure Cosmos DB、缓存、对象存储与变更数据捕获系统的统一服务。相比又一次模型能力升级，这篇工程复盘更像是在解释一个常被忽视的事实：聊天窗口能否迅速打开，首先取决于后面的数据系统能否稳定工作。
一次登录、查看Codex设置或发起新对话，背后可能触发多次数据读取。任何一个请求变慢，用户都会感到卡顿；如果关键读取失败，产品可能直接不可用。早期Habitat把路由、授权、加密、序列化、连接池和请求整形封装在客户端库里，让产品团队不用直接理解底层数据库。随着产品数量、数据类型和地域要求增加，这种做法逐渐暴露出版本分散、部署困难和缺乏统一控制的问题，团队于是把它从库改造成独立服务。
从Python库到平台服务，真正解决的是统一控制而不是“换一种写法”
把存储逻辑集中起来后，Habitat成为观察、部署和保护下游资源的共同入口。产品团队仍然使用相对简单的接口，平台却能在后台决定数据来自Cosmos DB、Valkey缓存、Nanobase还是Blob存储，并执行访问控制、数据驻留、限流和隔离。这种架构的价值不在于让每次读取看起来更聪明，而是把几十个团队原本各自实现的基础动作收拢，使错误能够在一个地方被发现和修正。
规模快速增长也迫使团队做大量并不显眼的取舍。Habitat需要监控Python asyncio事件循环延迟，减少功能开关带来的尾延迟，平衡不同连接池，并避免流量尖峰把下游数据库压垮。平均延迟漂亮并不够，真正影响体验的是最慢的那一小部分请求。一个对话页面同时依赖多个读取时，某项服务的长尾会被放大，用户只会看到页面迟迟没有响应。因此，大规模在线系统往往更关心P99延迟、超时和降级策略，而不是单次基准测试的最好成绩。
OpenAI称，过去三年需求每年增长超过10倍。常规工程可以为下一个十倍规模提前设计，再用几年逐步迁移；连续高速增长却让团队必须一边维持线上系统，一边为基础重构争取时间。Habitat的策略因此不是从第一天建设完美平台，而是先压榨现有组件、解决最紧急的容量和可靠性问题，再逐步补上服务化、隔离和新的存储层。这种顺序感比“全部推倒重来”更接近真实生产环境。
复杂查询也被刻意放到主路径之外。Habitat的在线接口强调简单、可预测的读写；需要分析和搜索的团队通过变更数据捕获，把数据近实时流向隔离的Rockset实例。这样做增加了部分使用摩擦，却避免沉重查询和在线产品流量争抢同一数据库。对任何同时承担交易路径与分析任务的平台来说，把两类负载分开，往往比给主库不断加机器更稳妥。
两名工程师用Codex重写Rust服务，数字亮眼但迁移仍未结束
官方还披露，2026年第二季度，两名工程师借助Codex和GPT-5.5把整套服务从Python重写为Rust。新服务目前承担95%的生产请求，CPU效率提高6倍、内存效率提高15倍，平均和尾部延迟也显著下降。Python版本高峰时已经能处理每秒超过2000万次请求，这说明迁移并不是因为旧系统完全不能工作，而是在规模继续上升后，运行成本、资源效率和延迟稳定性开始值得付出重写代价。
这些数据不能简单理解为“Rust永远比Python快十五倍”。实际差异同时来自语言运行时、内存模型、网络栈、并发方式以及重写时顺带完成的架构优化。官方也说明，Python仍承担约5%的生产流量，计划在未来几周内弃用，而不是已经彻底下线。迁移过程中最重要的工作通常是双写或影子流量、结果一致性、逐步放量和可回滚，而非代码翻译本身。
对其他公司而言，Habitat的启示不是照抄技术栈。大多数团队既没有每秒7000万次请求，也不需要500PB在线数据。更普遍的经验是：先把高频存储动作做窄，给复杂查询提供隔离出口；让权限、路由、限流和观测成为平台能力；重写前先量化瓶颈；迁移时保留旧路径，逐步验证。只有当资源成本与增长压力足够大时，语言迁移才可能比持续优化原系统划算。
OpenAI这次公开的是两部分系列的第一篇，数据库层和多租户优化还会在后续文章中展开。因此，目前能确认的是Habitat的总体规模、服务化路径与Rust迁移结果，不能据此推断OpenAI所有存储问题已经解决。AI产品给人的第一印象来自模型，长期可用性却来自这些不容易被看见的工程层。越接近十亿级用户，竞争越不只是模型会回答什么，也在于每一次读取能否在正确的权限、地域和时间内完成。