OpenAI 官方博客介绍了其在线存储平台 Habitat 的演进过程。Habitat 是 OpenAI 自建的在线存储平台，目前每秒处理超过 7000 万次请求，支撑每周超过 10 亿用户的产品，存储数据超过 500 PB，覆盖近 40 个地理区域。

Habitat 始于 2024 年中，最初只是一个简单的 Python 客户端库，直接对接 ChatGPT 主服务器，底层使用 Azure Cosmos DB。这个库的目标是让产品工程师无需关心数据库管理，包括 schema 查找、路由、鉴权、加密、序列化、请求整形和连接池等细节。由于使用简单，它在 OpenAI 内部被快速采纳。

到 2025 年中，客户端库模式达到极限。一次为了将关键数据集迁移到区域分布的 Azure Cosmos DB 账户，需要引入新的路由逻辑、通过 feature flag 控制、协调数十个服务逐步发布，整个过程耗时数天，且最终因某个团队回滚到旧版客户端而引发故障。这促使团队将 Habitat 从库重构为独立服务，从而获得部署、可观测性和平台增强的单一控制点，也能集中实施访问控制、审计日志和底层存储资源限制。

团队选择继续使用 Python 构建服务，尽管 Python 在高吞吐场景下会增加网络延迟和 CPU、内存成本。这是有意的技术债：优先解决产品开发阻塞和平台稳定性，同时押注自家 coding model（Codex、GPT）未来能简化迁移。这个赌注最终被证明是正确的。

运行 Python 高吞吐服务的核心挑战是尾部延迟。由于 Habitat 除了 I/O 代理，还承担路由、压缩、加密、校验和、健康检查、请求 shadowing 和 hedging 等大量 CPU 密集任务，asyncio 调度延迟很容易主导 p99 延迟。团队通过周期性调度后台任务并记录预期与实际执行时间的差值，实时测量事件循环调度延迟，发现高利用率下调度抖动可达数百毫秒甚至数秒。对策是让每个进程只处理少量并发请求，同时大规模增加 Python worker 进程数量。

一个具体的尾部延迟根因是 Statsig 的 feature flag 配置解析。默认配置每分钟无抖动轮询，且包含所有服务的全部生产规则，加上每个 pod 最多 8 个 Python 进程，导致每分钟所有 worker 都会停滞处理请求去解析巨型配置文件。修复方式是部署更小的定向配置、延长刷新间隔、为后台任务增加抖动。

连接池的 LIFO 复用机制曾引发 metastable failure。Python aiohttp TCPConnector 默认 LIFO 复用连接，突发流量后较慢服务器返回连接更晚，反而被后续请求更频繁选中，导致流量持续集中到已过载的 pod。改为 FIFO 复用后打破了反馈循环，也降低了稳态请求方差。现在 OpenAI 主要依赖 Istio 和 Envoy 提供连接池和负载感知的均衡策略。

大量 Python 进程带来的另一个问题是容易淹没下游依赖，即 thundering herd。团队依赖 Envoy 做连接 fan-in，将 HTTP/1 升级为 HTTP/2 多路复用，并集中实现限流和熔断。

Habitat 能扩展到如此规模，部分原因是其 API 受限。它不提供任意 SQL 查询，而是暴露类似 TAO 的 NoSQL API，围绕客户端定义的对象和边类型建模。每个对象及其边在存储层共置，但对象与边指向的远端对象不做数据库级共置，因此模型易于水平分区，但图遍历效率低。复杂查询通过 CDC 流到隔离的 Rockset 实例处理，由各客户端团队自行扩展。这是明确的设计取舍：让简单查询成为默认，同时为复杂查询提供逃生舱。

2026 年 Q2，团队仅用 2 名工程师、Codex 和 GPT-5.5 就将整个服务用 Rust 重写。新 Rust 服务已处理 95% 的生产请求，CPU 效率提升 6 倍，内存效率提升 15 倍，平均和尾部延迟显著降低。Python 版本峰值时每秒处理超过 2000 万请求。团队计划在后续文章中分享更多细节。