快速扩展在线存储，服务超10亿ChatGPT用户
内容提要
OpenAI自研在线存储平台Habitat，每秒处理超7000万请求，服务超10亿用户，数据量超500PB。它最初是Python客户端库，2025年因多产品协调困难转为独立服务，集中管理部署、安全与可观测性。团队用Python应对超高速增长，通过监控asyncio延迟、修复连接池LIFO导致的亚稳态故障、用Envoy汇聚连接来优化性能。最终用Rust重写，CPU效率提升6倍，内存效率提升15倍。
延伸解读
从库到服务：集中化管控的收益
Habitat最初是Python客户端库，但跨数十个服务的协调部署变得脆弱且易出错。转为独立服务后，OpenAI获得了部署、可观测性和平台增强的单一控制点，能集中实施访问控制、审计日志和限制底层存储访问，从而加强数据安全并减少运营故障。
Python服务下的尾延迟挑战
Python的asyncio提供并发但受GIL限制，无法实现CPU并行。Habitat处理大量CPU密集型任务，导致事件循环调度延迟成为尾延迟主因。OpenAI通过监控asyncio循环延迟，并限制每进程并发请求数、大规模扩展工作进程来缓解。
连接池LIFO引发的亚稳态故障
Python aiohttp默认LIFO连接复用，在突发流量下，较慢服务器最后归还连接，却被后续请求优先选中，导致流量不断集中到已过载的进程，形成亚稳态故障。改为FIFO复用打破了这一反馈循环，降低了请求方差。
Rust重写：效率的显著提升
在Python服务达到每秒超2000万请求峰值后，OpenAI用2名工程师、Codex和GPT-5.5在2026年Q2将服务重写为Rust。新服务处理95%生产请求，CPU效率提升6倍，内存效率提升15倍，平均和尾延迟显著降低。
Q&A
Habitat是什么？它在OpenAI中扮演什么角色？
Habitat是OpenAI自研的在线存储平台，旨在让OpenAI产品能够快速可靠地访问所需信息。它处理每秒超过7000万次请求，支持每周超过10亿用户使用的产品，覆盖近40个地理区域，管理超过500PB数据。
为什么OpenAI将Habitat从Python客户端库转变为独立服务？
到2025年中期，Habitat作为客户端库已达到极限。随着服务数量增加，向后兼容的协议变更变得不可行，跨数十个服务协调部署耗时数天且脆弱，容易导致操作失败。转为独立服务后，实现了部署、可观测性和平台增强的单一控制点，并能集中实施数据安全策略。
Habitat在Python服务阶段遇到了哪些性能挑战？如何解决？
主要挑战是管理尾延迟。由于asyncio调度延迟，CPU密集型任务导致请求在等待协程重新调度时停滞。解决方案包括：监控asyncio事件循环延迟，保持每个进程仅处理少量并发请求并大量扩展Python工作进程；优化功能标志配置（减少JSON解析频率、增加抖动）；调整连接池为FIFO以避免亚稳态故障；使用Envoy进行连接汇聚和HTTP/2多路复用。
Habitat为什么采用NoSQL API而不是支持任意SQL查询？
Habitat有意采用简单的NoSQL API，以保持请求成本可预测。任意SQL查询可能导致大表扫描或复杂连接，造成成本失衡和操作危险。Habitat优化简单、可预测、恒定工作量的请求，使昂贵查询在客户端显而易见。对于复杂查询需求，提供通过Rockset的离线二级视图，使用CDC近实时同步数据。
Habitat从Python迁移到Rust后取得了哪些性能提升？
在2026年第二季度，仅用2名工程师、Codex和GPT-5.5，将整个服务重写为Rust。新Rust服务处理95%的生产请求，CPU效率提升6倍，内存效率提升15倍，平均和尾延迟显著降低。Python版本将在未来几周内完全弃用。
Habitat如何避免下游资源被洪水般的请求淹没？
Habitat依赖Envoy来最大化连接汇聚：将Python的HTTP/1连接升级为HTTP/2以利用多路复用，池化连接并延长生命周期。Envoy还提供集中式速率限制和熔断器，这些在单个Python进程中效果较差。此外，通过调整部署节奏避免连接循环引起的CPU波动，并防止连接泄漏饱和NAT网关。
