OpenAI 揭露 Habitat 存储架构：每周逾十亿人使用背后的规模与极限

2026 年 9 月 11 日，OpenAI 在官方工程博客发布文章《Rapidly scaling online storage to serve over 1 billion ChatGPT users》，说明内部存储平台 Habitat 这几年怎么从一个 Python 客户端库，演变成一套独立运作的服务。文章挂在 Engineering 分类下，作者具名为三位技术人员 Jon Lee、Chaomin Yu 与 Ben Ries，文末附上一个工程师招聘链接，是一篇技术博客，不是新产品或新方案的公告。

本文于 2026 年 9 月 18 日查核 OpenAI 官方文章原文、OpenAI 官方新闻 RSS feed，以及官方网站地图 Engineering 分类页。openai.com 的文章页在此前几天一度只回应访问限制页面，本文查核当天已能直接读取正文。以下数字全部是 OpenAI 自己的说法，本站没有做任何测试，也不提供任何购买或使用建议；本文没有使用虚构的生活场景。

这篇文章是什么：一篇工程博客，不是新产品公告

OpenAI 把这篇文章归类在 Engineering（工程）分类下，说明 Habitat 是自己打造的在线存储平台，让旗下产品能快速、可靠地获取所需的数据：用户登录、查看 Codex 设置或在 ChatGPT 开新对话，背后都可能牵涉多次数据查询。OpenAI 写道，这些查询一慢，产品就会让人觉得慢；查询失败，产品就直接无法运作。

文章开头的统计方框并列三个数字：每秒超过 7000 万次请求、每周超过 10 亿人，以及超过 500 PB 的数据量；OpenAI 说明 Habitat 最早是 2023 年 DevDay 为了支持 GPTs 而推出，一开始只是一个连到单一数据库的 Python 客户端库，如今已成长为一套复杂的分布式系统。

文章末尾附上一个工程师招聘链接（网址里带着西雅图的地名）；这是存储主题两篇系列文章的第一篇，第二篇预定说明多租户可靠性、读取性能分层策略，以及和 Azure Cosmos DB 的合作方式如何扩大。以官方网站地图与新闻 feed 查核到 2026 年 9 月 18 日，都还没有看到第二篇的项目，也没有公布日期。

OpenAI 说的规模：几个数字要放在一起看

OpenAI 在文章正文写道，Habitat 现在每秒处理超过 7000 万次请求，支撑旗下产品每周被超过 10 亿人使用，服务范围覆盖近 40 个地区；文章没有列出地区的国家或城市名称，只在一张自陈为“简化”的示意图上，出现 us0、us1、eu0 三个示例数据库代号，那是图上的标签，不是一份公布的地区清单。

值得留意的是，OpenAI 官方 RSS feed 与网页的元数据另外写着“22M requests per second”，但本文查核当天重新读过正文全文，这个数字只出现在摘要与元数据里，正文从头到尾没有再提过，也没有交代它和 7000 万、2000 万有什么关系。

OpenAI 也说明，过去 3 年他们每年增长幅度超过 10 倍；文中原句提到，系统工程师通常按 10 倍规模做设计，希望撑个几年，同时准备下一个 10 倍。

为什么一次变慢的查询，用户会感觉得到

OpenAI 解释，当一般用户的一次请求会带出几百次数据库调用时，用户感觉到的就是最慢的那一次。文章把管理这种“尾部延迟（tail latency）”（少数特别慢的查询）称为在这个规模下运行 Python 服务的主要挑战。

文章举了一个案例：Habitat 用 Statsig 这套功能开关工具，默认每分钟轮询一次更新后的配置、没有错开时间差，而那份配置包含每个服务的每一条正式环境规则；叠加“一个 Pod 最多运行 8 个 Python 进程”的架构决定后，变成每分钟每个 Pod 都会有某个瞬间，所有工作进程同时停下手上的请求，改去解析那份庞大的配置文件。OpenAI 说一旦用 CPU 剖析定位到根因，解决方法就很简单：改用范围更小的配置、拉长轮询间隔，并给这类后台工作加上随机时间差。

另一个案例和连接池有关：OpenAI 说 Python 的 aiohttp 库默认优先重复使用最近释放的连接，平常是合理的默认值；但流量突增时，比较慢、已经过载的服务器比较晚把连接还回池子，反而更常被后续请求选中，流量逐渐集中到本来就吃力的 Pod 上。OpenAI 称这是一种“亚稳态故障（metastable failure）”：造成过载的客户端停掉之后，仍有一部分进程持续恶化，要重启才恢复。改成优先使用最早释放的连接后，不只解掉反馈循环，连稳态下的请求量落差也跟着变小；现在这类连接管理大多交给 Istio 与 Envoy 负责。

OpenAI 没有在这篇文章说明的事

本文以英文原词逐字比对，文章没有出现 durability、backup、replica 这几个字，也没有写出一份数据会保留几个副本；OpenAI 只描述过一次想把最关键的数据集移到跨地区分布的 Azure Cosmos DB 账户、以缩小单一地区故障影响范围的经过，没有再说明保存或冗余机制。文章也没有任何可用性数字或服务级别协议，只描述了几次自家系统出过的状况，例如某个团队因为不相干的原因把自己的服务回滚到带有问题客户端的旧版本，反而引发原本想避免的事故，但没有标明日期、时长或对用户的实际影响。

地区方面，文章只写近 40 个地区，没有把任何国家或城市写成数据存放地点，也没有提到台湾或亚洲；比较接近地区信息的，是示意图上那三个数据库代号，以及招聘链接网址里的城市名。文章同样没有交代 Habitat 实际存放哪些数据——登录、查看 Codex 设置、开新对话都可能需要查数据，但没有明讲对话内容是否存在 Habitat 里，只说这里是保护用户数据、防止外部、内部与代理程序未经授权访问的关键位置。

改写成 Rust 之后的数字也一样：OpenAI 说自家数据显示，新版本的 CPU 效率是原本的 6 倍、内存效率是 15 倍，平均与尾部延迟都显著降低，目前处理 95% 的正式环境请求，并计划在未来几周内完全停用 Python 版本；OpenAI 也说之后会再发一篇分享更多心得，这个后续同样没有公布日期。文章没有附上测试方法、测试场景或第三方查核，这些数字目前只能视为 OpenAI 自己公布的内部测量结果。

读者可以怎么看待这篇文章

这篇文章没有公布任何新产品、新方案、新地区或新设置，ChatGPT 或 Codex 的用户不需要因此做任何调整；OpenAI 自己在文章里也没有宣称用户会感觉到更快或更省，改写的效益目前只停留在 OpenAI 自己内部的说法。

这篇文章比较适合当成一个提醒：服务背后都有自己的存储与可用性设计，而运营方自己公布的规模数字，不管是请求量、用户数或增长倍数，在有第三方查核之前都只能算厂商自己的说法；读者可以留意文章有没有提到耐久性、服务级别协议或事故细节，这通常比单一个亮眼数字更能反映服务的稳定程度。

想确认后续进度的读者，可以自己查两个免费的官方渠道：OpenAI 的新闻 RSS feed，以及工程分类的网站地图，本文就是用这两个渠道确认第二篇还没出现。要注意网站地图上标的时间和页面印出的发布日期对不上，不宜当成文章的发布日或更新日，这是本文查核当天的观察。

2026 年 AI 新闻总整理：1 月至 9 月的重点与生活应用

OpenAI 与 Broadcom 发布 Jalapeño 芯片：官方说的阶段、分工，与还没公布的事

• AI 工具
• 软件与应用
• AI 新闻与趋势