OpenAI 工程团队披露，其自研在线存储平台 Habitat 目前支撑 7000 万以上每秒查询、500 PB 以上数据，并分布在约 40 个地理区域，服务于每周超过 10 亿活跃用户的 ChatGPT 等产品。更值得关注的是，这个关键基础设施在 2026 年第二季度由 2 名工程师借助 Codex 和 GPT-5.5 完成了从 Python 到 Rust 的重写，新服务目前已承接 95% 生产流量。
对于一家以大模型产品为核心的公司来说，Habitat 的演进提供了一个观察窗口：当用户规模以每年超过 10 倍的速度增长时，基础设施团队如何在不停机、不拖慢产品开发的前提下，逐步完成架构升级。
从 Python 客户端库到独立存储服务
Habitat 最早出现在 2023 年 DevDay 前后，当时只是一个 Python 客户端库加单个 Cosmos DB 数据库，主要为 GPTs 相关功能提供数据访问。随后两年，随着产品工程师的广泛采用，平台逐步加入缓存、压缩、加密等能力。到 2025 年中，客户端库形态触到瓶颈，OpenAI 将其拆分为独立服务。
客户端库形态的核心问题在于变更成本过高。OpenAI 在文中提到，为了缩小单区域故障影响范围，他们曾希望把关键数据集迁移到按地域分布的多个 Azure Cosmos DB 账号，并给客户端增加路由逻辑。但由于逻辑分散在几十个服务的客户端中，每一次更新都需要协调多个团队发版、做影子流量验证、修复问题后再重复流程。某次团队因无关原因回滚服务，回滚到了带有旧版客户端缺陷的版本，反而触发了原本想避免的故障。
把 Habitat 抽成独立服务后，OpenAI 获得了对数据访问路径的统一控制能力，也降低了产品团队的发布协调成本。尽管团队清楚 Python 在高吞吐场景下会带来更高的网络延迟和 CPU、内存成本，他们仍选择先以 Python 构建服务。原因是当时首要目标不是资源优化，而是解除产品开发阻塞、建立稳定 API 和基础设施。
Python 服务如何撑住 2000 万以上 QPS
Habitat 的 Python 服务在峰值阶段承载了 2000 万以上 QPS。OpenAI 表示，当平均一个用户请求会产生数百次数据库调用时，用户实际感受到的是最慢的一次调用。Python asyncio 可以处理 I/O 并发，但受 GIL 限制难以提供 CPU 并行，而 Habitat 需要处理路由、压缩、加密、校验和、下游健康检查、请求影子、请求对冲等 CPU 密集任务，事件循环调度延迟容易放大长尾。
OpenAI 的监控方法不仅包括常规 CPU、内存、网络、磁盘指标，还会专门测量 asyncio 事件循环本身的调度延迟。具体做法是周期性调度一个后台任务，记录其期望执行时间与实际执行时间的差值。实测显示，在高负载下，即使每个进程并发请求数量不多，调度抖动也可能达到数百毫秒，极端情况下可达数秒。
为此，OpenAI 让每个进程只服务少量并发请求，再通过大量水平扩展的 worker 进程补足吞吐。团队还发现，Statsig 特性开关配置的周期性 JSON 解析曾导致周期性延迟尖刺：多个 worker 会在同一时间解析一份大型 JSON，造成整个 pod 短暂停滞。修复方式包括下发更小的定向配置、拉长刷新间隔，并为后台任务增加随机抖动。
另一个典型问题来自连接池策略。由于客户端进程较多，而每个客户端进程只与少数服务端进程建立连接，负载分布不均。OpenAI 发现，Python aiohttp 的 TCPConnector 默认采用 LIFO 方式复用连接，即最近归还的连接最先被复用。在过载场景下，这会让请求持续流向响应更慢的节点，形成正反馈，导致部分服务端进程持续恶化，直到重启才恢复。最终，团队将连接池改为 FIFO 复用，打断该反馈回路，降低节点间负载差异和请求延迟波动。后续，Habitat 还把连接池和负载感知路由交由 Istio 与 Envoy 处理，使 Python 进程层专注并发模型，网格层负责连接管理与过载保护。
API 设计：复杂查询被推到离线链路
在 API 层面，Habitat 刻意保持简单。它不允许客户端构造任意 SQL，也不提供复杂扫描或多表 join，而是只暴露一个受限的 NoSQL 接口。数据建模借鉴了 Facebook 的 TAO 论文，采用对象和边模型：客户端可以预定义对象、边及其关系，但查询主要限于某个对象的直接边，不支持任意图遍历。每个对象与其边会被放在同一个存储分区，但系统不刻意做跨对象同置，以便水平扩展。
对于复杂查询、分析和搜索需求，OpenAI 没有让它们直接压到在线存储，而是通过 CDC 将在线存储变更近实时同步到各团队独占的 Rockset 实例。各团队自行负责自己的 Rockset 扩容。这样增加了接入成本，但把复杂计算与在线低延迟链路隔离开来，保证核心产品访问路径稳定。
两名工程师加 AI 完成 Rust 重写
2026 年第二季度，OpenAI 让 2 名工程师配合 Codex 和 GPT-5.5，把整个 Habitat 服务从 Python 重写为 Rust。新的 Rust 服务现已承接 95% 生产流量，Python 版本将在未来数周内全部退役。按 OpenAI 给出的数据，Rust 版本带来 6 倍 CPU 效率提升和 15 倍内存效率提升，平均延迟和长尾延迟也显著下降。
这次重写并不是突发式推倒重来。它发生在 Habitat 已经从客户端库迁移为独立服务、API 和基础设施相对稳定之后。OpenAI 早前选择 Python，是在产品开发优先的约束下接受短期技术债；而押注编码模型能力进步，则让后续迁移成本变得可控。文章称，这一押注最终被证明是正确的。
在大模型产品竞争进入基础设施比拼阶段后，Habitat 的案例显示，支撑 10 亿级用户的产品体验，不只取决于模型能力，也取决于存储、服务框架、网络调度和工程组织方式。OpenAI 下一篇工程文章将继续讨论 Habitat 存储层本身，包括多租户可靠性、读性能优化，以及与 Azure Cosmos DB 如何共同支撑 500 PB 数据和 7000 万以上 QPS。
原创文章，作者：点点，如若转载，请注明出处：https://www.dian8dian.com/openai-yong-liang-ming-gong-cheng-shi-he-ai-chong-xie-cun
