OpenAI正在扩展在线存储基础设施以服务超过10亿ChatGPT用户，反映平台负载和用户生成数据的大幅增长。

OpenAI产品需要快速、可靠地访问数据——无论用户是登录、调整他们的Codex设置，还是开启新的ChatGPT对话。每个操作都可能在产品响应前触发数十次数据库查询。缓慢的请求会让产品感觉迟缓；失败的请求则会完全中断产品。

Habitat是一个在线存储平台，旨在为OpenAI产品提供可靠、高速的数据访问。该平台目前处理每秒超过7000万个请求，支持全球近40个地理区域内超过10亿周活跃用户使用的产品。两年前作为连接到单一数据库的简单Python客户端库起步的项目，已演变成为服务超过500petabytes数据的复杂分布式系统。

在这种规模下构建基础设施会面临常规挑战，但OpenAI的情况独特：公司在过去三年内每年扩展了十倍多，同时还在构建成熟的平台。大多数系统工程师会为10倍增长进行设计，希望能维持多年。运维Habitat需要一系列战术决策和排序——从现有堆栈中提取最大效率，同时管理存储和计算约束，为基础设施投资争取时间。

Habitat经历了不同的阶段：首先变得足够可靠以支持关键业务流量，然后足够快以服务全球用户，最后能够在大规模下可靠运行。这一演进需要将Habitat从一个库转变为一个服务。

最初，在2024年中期，Habitat是一个与ChatGPT主服务器交互的小型Python库。它支持一套有限的操作，映射到底层数据库应用Azure Cosmos DB。该库向产品工程师隐藏数据库管理细节，处理模式查询、路由、授权、加密、序列化、请求塑形和连接池。开发人员无需了解数据来自Azure Cosmos DB、缓存还是其他存储类型。

该库虽然没有正式组织推动从自助Postgres和Azure Cosmos DB迁移，但仍然获得了快速采用。随着产品需求演变，共享库轻松容纳了客户端缓存、压缩和加密等新功能。

到2025年中期，Habitat已经超出了客户端模型的容量。随着该层变得更复杂，OpenAI的服务数量增加，向后兼容的协议更改变得不可行。一个例子是：OpenAI想要通过迁移到区域分布式Azure Cosmos DB账户来降低关键数据集因地区故障的影响范围。实现这一点需要在特性开关后面向客户端引入路由逻辑，协调数十个服务的推出——这个过程耗时数天。额外的影子工作、错误修复和重新协调进一步延长了时间表。最终，当一个团队因不相关的原因将其服务回滚到之前的有缺陷的客户端版本时，它触发了协调工作试图阻止的确切故障。

操作上的碎片化使得客户端库的更改越来越脆弱且易出故障。为了减少这种分布式的复杂性，OpenAI将Habitat转换为中央化服务。这为部署、可观测性和平台增强建立了单一控制点——用集中式改进替代了分散式更新，使每个产品立即受益。该服务也成为了关键的安全检查点，集中执行访问控制策略、审计日志，并限制对底层存储资源的访问，同时保护用户数据免受外部、内部和基于代理的威胁。

以规模运行Python服务存在固有的权衡。作为服务，Python的开销会增加网络延迟，相比本地库执行会增加实质性的CPU和内存扩展成本。OpenAI意识到Python的低效率无法扩展到100倍需求，使得最终重写成为必然。不过，他们将其视为战略性技术债：优先考虑解除产品开发人员的障碍和实现平台稳定性，而不是近期成本优化。此外，他们打赌快速发展的自身编码模型最终会简化从Python的迁移——这个赌注最终证明是正确的。

性能权衡是不可避免的，但显著的延迟下降是不可接受的。当普通用户请求触发数百次数据库调用时，最慢的调用决定了感知速度。在这种规模运行Python的中心挑战是管理尾部延迟。

Python的asyncio处理I/O绑定并发，但无法绕过全局解释器锁或提供CPU并行性。除了I/O密集的请求代理外，Habitat还处理CPU密集的责任：路由、压缩、加密、校验和、下游健康检查、请求影子处理和对冲。由于有这么多CPU密集的工作负载和后台任务，asyncio调度延迟很容易主导尾部请求延迟。初始跟踪显示，对于p99及更高延迟的请求，下游存储响应迅速，但请求经常停滞等待负责的协程被重新调度以解析响应。