OpenAI Habitat 扩展以服务超过 10 亿 ChatGPT 用户
TL;DR
OpenAI 透露其 Habitat 存储平台现在处理 >70 M requests/s，存储 >500 PB，并支持 >1 B weekly ChatGPT users，在从一个简单的 Python 客户端库演变为一个分布式服务之后，目前正在用 Rust 重写以提高效率。
Habitat 增长概览
Habitat 现在每秒处理超过 70 M requests，服务遍布 ~40 个区域的超过 1 B weekly users，并存储 >500 PB 的数据。 该系统始于 2024 年中期，最初是基于 Azure Cosmos DB 的一个轻量级 Python 客户端库，现已成为一个复杂的、全球分布式的存储服务。
为什么服务取代了库
在数十个服务之间协调协议变更变得脆弱，促使了向中心化服务的迁移。 客户端库需要进行功能特性标志（feature-flag）发布、影子测试（shadowing）和多区域路由逻辑，这些操作需要数天时间来协调，且仍会导致停机。将存储逻辑中心化可以为 OpenAI 提供部署、可观测性、安全性以及策略执行的单一控制点。
架构选择与权衡
Python 服务作为战略切入点
- Running Habitat as a Python service 引入了更高的延迟和 CPU/memory 成本，但允许快速交付核心 API 和平台稳定性。
- OpenAI 接受了性能惩罚，赌注在于未来的 Codex/GPT-based tooling 会使后期的迁移更加容易。
管理 Python 中的尾部延迟
- Asyncio scheduling delay 占据了 p99+ 延迟的主要部分，因为 CPU 密集型任务（routing, compression, encryption, health checks）阻塞了事件循环。
- 通过监控事件循环延迟并限制每个进程的并发请求数，迫使了工作进程的大规模水平扩展。
功能特性标志配置瓶颈
- 定期对大型 Statsig config 进行 JSON parsing 导致 pod 里的所有 worker 都会在每分钟一次地停顿。
- 修复方案：减小 config size，增加刷新间隔，并为后台任务添加 jitter。
连接池负载均衡问题
- aiohttp 的
TCPConnector默认的 LIFO reuse 策略在创建了一个亚稳态反馈循环：较慢的 pod 都会延迟返回连接，导致后续请求被路由回它们，从而放大了过载。 - 切换到 FIFO reuse 策略打破了该循环并降低了每个进程利用率的方差。
- Envoy/Istio 现在提供连接池、HTTP/2 multiplexing 和中心化化速率限制，以避免惊群效应（thundering-herd effects）。
受限的 NoSQL API 作为扩展性杠杆
Habitat 刻意提供一个简单的 NoSQL API 而非任意的 SQL，以保持请求成本的可预测性。 客户端定义对象和边（inspired by TAO），但不能发起无限制的查询，从而防止了昂贵的表扫描，并保护服务免受误用。复杂的分析型查询被通过 CDC streams 卸载到 Rockset。
从 Python 到 Rust 的迁移
在 2026 年第二季度，OpenAI 重写了 Habitat 的 Rust 实现，现在处理 95% 的生产环境流量。 据报道，Rust 服务比 CPU 效率高 6x，内存效率高 15x，且平均延迟和尾部延迟都显著降低。曾经达到过 >20 M requests/s 的 Python 实现将会在接下来的几周内被弃用。
未来方向 (Part II)
- Part II 将详细介绍多租户可靠性、读性能分层、以及支撑 500 PB 存储层的 Azure Cosmos DB 合作伙伴关系。
- 目前的工作包括进一步优化连接扇入（connection fan-in）、熔断器（circuit-breaking）和扩展 Rust 服务以应对持续的用户增长，以维持在当前 10x YoY trajectory 轨迹下的增长趋势。
关键要点
- Habitat 的演进过程说明了如何一个快速移动的产品组织可以优先考虑开发者速度（Python service）并注重长期的长期效率（Rust rewrite）。
- 对 API surface 表面层进行严格控制、对事件循环进行仔细的监控、以及采用适当的连接池策略对于扩展一个高吞吐量存储服务至关重要。* 对存储逻辑进行中心化，可以实现统一的安全、可观测性以及在大规模、全球分布式的用户群中快速发布新功能。