OpenAI Habitat 架构深度解析：ChatGPT十亿用户、500PB存储、Azure Cosmos DB、Valkey与12倍性能优化

一、ChatGPT 十亿用户背后为什么需要新的存储架构？

2026 年 10 月 23 日，OpenAI 发布技术博客《Rapidly scaling online storage to serve over 1 billion ChatGPT users (Part II)》。

文章介绍其内部存储平台 Habitat 如何随着 ChatGPT、Codex 和 API 等产品的增长，演变成覆盖全球的在线存储基础设施。

对于普通用户而言，ChatGPT 的核心似乎是模型生成回答。

但一次真实使用还涉及许多模型以外的操作。

例如，登录时读取用户身份。

打开聊天时读取历史记录。

切换设置时读取用户偏好。

使用 Codex 时读取项目配置。

这些操作需要快速访问持续保存的数据。

如果底层存储出现明显延迟，即使语言模型本身足够快，产品体验也可能受到影响。

因此，OpenAI 需要一套可靠的在线存储平台，将数据库、缓存、访问权限、区域路由和数据变更通知统一管理。

Habitat 就承担了这一类职责。

二、Habitat 是什么？

Habitat 不是一款公开售卖的独立大语言模型。

它是 OpenAI 内部的在线应用存储平台。

它为多个产品提供统一的数据访问能力，减少各产品团队直接管理底层数据库的复杂度。

根据官方架构图，Habitat 涉及以下组件。

这些组件组成的是一套内部工程体系。

不能把这张架构图直接理解为任何小型网站都需要同时部署全部服务。

系统设计应当根据实际业务规模和资源条件选择。

三、官方公布的系统规模有多大？

OpenAI 在文章中披露了多个重要数据。

这里需要严格区分不同口径。

超过 500PB 是 Habitat 平台总体数据规模。

最大单个 Cosmos DB 账户为数十 PB。

超过 2000 万 QPS 描述的是该最大账户的请求处理规模。

而 p50 延迟则反映全球读取请求的统计表现。

不能把这些数字混合成“所有数据都存在一个数据库中，每个请求延迟都只有 10ms”。

实际数据访问路径和延迟取决于区域、缓存命中及具体请求类型。

四、为什么 OpenAI 最初使用共享容器？

在系统早期，多个产品功能共享 Azure Cosmos DB 中的默认容器。

这种方式减少了基础设施配置工作。

例如，新开发团队可以直接存储数据，不需要为每个功能申请独立数据库。

对于产品快速迭代阶段，这种模式可以帮助开发人员集中精力实现业务。

但随着流量增长，共享容器的问题逐渐显现。

例如，某个热点用户可能产生大量请求。

另一个产品功能可能突然进行批量写入。

这些负载可能互相影响。

因此，平台开始遇到多租户隔离和数据库容量管理方面的挑战。

五、什么是多租户 Noisy Neighbor？

Noisy Neighbor 通常翻译为“吵闹邻居”。

它指共享基础设施中的某个租户占用了大量资源，影响其他租户的正常访问。

例如，一个 API 平台有多个业务客户。

某个客户在短时间内大量读取日志。

如果这些查询与普通用户登录共享数据库资源，就可能导致登录延迟上升。

OpenAI 在 Habitat 的早期阶段遇到了类似问题。

某些数据访问热点会占用共享物理分区的吞吐能力。

结果，一些普通业务功能也会受到影响。

因此，多租户数据库不仅需要隔离数据内容，还需要隔离或合理分配资源消耗。

六、Cosmos DB 的逻辑分区与物理分区有什么区别？

Azure Cosmos DB 使用分区键组织数据。

逻辑分区根据应用选择的键进行划分。

底层物理分区则负责实际保存和处理数据。

例如，开发者可能选择 user_id 作为分区键。

这样，同一用户的数据就更容易被关联处理。

但是，当某个用户特别活跃时，这个逻辑分区可能成为热点。

同时，多个逻辑分区可能共享同一个物理分区。

如果其中一个逻辑分区消耗大量吞吐，其他逻辑分区也可能受到影响。

OpenAI 发现，单纯依赖数据库默认的分区吞吐限制，无法完全避免这种相互影响。

因此，后续引入了更细致的热点控制。

七、什么是弱分区问题？

OpenAI 还描述了 Weak Partitions 问题。

在某些容量配置模式中，随着数据增长，数据库可能需要拆分物理分区。

但如果整个容器的总吞吐量没有同步增加，平均分配到各物理分区的吞吐能力可能下降。

例如，原先一个物理分区拥有较高吞吐配额。

拆分后，两个分区需要共享相同的整体吞吐预算。

结果可能出现数据量变大，但单个活跃分区可用吞吐反而下降的情况。

这对存储量持续增长、访问量却相对稳定的应用特别麻烦。

因此，数据库容量规划不能只根据请求数量。

还需要考虑数据增长与物理分区变化。

八、为什么 OpenAI 曾经转向独立容器？

为了降低共享容器中的相互影响，OpenAI 一度为重要服务单独创建 Cosmos DB 容器。

这样可以把部分业务负载隔离到独立资源中。

例如，用户登录与大型后台数据导入不再共享完全相同的吞吐预算。

这一方案在一定时期内降低了事故影响范围。

但新的问题随之出现。

每个业务团队都需要提前估算自己未来需要多少数据库容量。

如果估算不足，新功能正式发布后可能出现严重限流。

如果估算过高，则可能造成资源浪费。

OpenAI 发现，随着产品数量增加，让每个团队单独负责容量规划也难以长期维持。

九、为什么又回到多租户？

OpenAI 与 Azure Cosmos DB 团队合作，增强了多个基础能力。

首先是热点分区限流。

当某些键消耗资源过多时，系统可以优先限制它们，减少对其他业务的影响。

其次是 QoS，也就是服务质量分级。

例如，离线批量处理任务可以使用较低优先级。

当资源紧张时，优先限制批量任务，而不是影响在线用户请求。

第三是改善 Serverless 模式，让物理分区能够根据资源使用情况更合理地扩展。

通过这些措施，Habitat 可以再次以共享容器为默认选择。

这说明技术架构并非从共享走向独立就是永远正确。

真正的目标是在隔离效果、资源利用率和运维复杂度之间取得平衡。

十、QoS 为什么对 AI 平台重要？

一个 AI 服务平台通常同时处理在线和离线工作负载。

例如，在线用户正在登录和查询账户余额。

后台系统可能正在导出大量日志。

数据分析任务可能正在读取历史记录。

如果这些请求没有优先级区别，后台任务可能占用关键业务所需的资源。

OpenAI 的做法是让较低优先级负载在资源紧张时首先受到限制。

对于中小型 API 平台，同样可以参考这一原则。

例如，对管理后台报表使用单独的数据库只读连接或低优先级队列。

避免大量导出任务影响正常的用户请求。

但具体实现方式应根据当前数据库能力决定。

不应把 Cosmos DB 的内部机制直接照搬到 MySQL。

十一、为什么数据库扩容不能只看 CPU？

有些网站管理员发现，服务器 CPU 利用率很低，用户却仍然反馈页面变慢。

这可能与数据库、网络或存储有关。

例如，某些请求正在等待磁盘 I/O。

数据库连接池已经耗尽。

热点索引产生锁争用。

或者某条 SQL 执行时间较长。

Habitat 的案例说明，应用性能是多个系统共同决定的。

因此，不能只通过升级 CPU 判断问题是否解决。

真正的性能排查应该记录请求入口、应用执行时间、数据库访问次数和缓存命中率。

只有识别主要瓶颈，才能决定是否增加硬件资源。

十二、全球 40 个区域如何影响数据延迟？

OpenAI 的服务分布在全球多个区域。

但计算和数据存储不一定总位于同一地区。

如果请求需要跨越较远网络访问数据库，就可能增加延迟。

因此，Habitat 采用多层策略优化读取性能。

首先，在条件允许时尽量将数据放在用户附近。

其次，将体积小、延迟敏感的数据复制到更多区域。

例如，身份认证和关键配置可能需要被多个区域频繁读取。

对于其他大量普通数据，则更多依赖缓存减少远距离访问。

这是一种在存储容量、复制成本和用户体验之间进行权衡的方案。

十三、为什么不能把全部数据全球复制？

全球复制可以减少某些跨区域访问延迟。

但它并非没有成本。

例如，大规模复制会占用大量存储空间和网络带宽。

当数据需要满足地区限制时，还可能受到数据驻留政策约束。

OpenAI 提到，部分全球区域的物理数据中心容量有限。

因此，不可能把所有数据都无差别复制到全部区域。

对于大规模系统，更合理的策略是区分数据类型。

将关键的小型元数据广泛复制。

把其他数据按照使用频率和区域要求进行放置。

对能够容忍少量延迟的读取，使用缓存优化。

十四、Valkey 在 Habitat 中承担什么角色？

Valkey 是一个开源内存数据存储系统，与 Redis 生态存在密切关系。

OpenAI 使用 Valkey 构建分布式缓存层。

它把近期访问过的对象保存在更接近用户计算环境的位置。

这样，当下一次请求读取相同数据时，就可能避免再次跨区域访问底层数据库。

对于读多写少的业务，这种方式通常特别有效。

OpenAI 披露，Habitat 超过 90% 的请求属于读取操作。

因此，缓存命中率对整体性能具有明显影响。

但是，缓存并不是只要开启就一定稳定。

真正困难的是缓存内容更新。

十五、为什么简单 TTL 缓存不够？

TTL 表示缓存条目的过期时间。

例如，一个数据保存 60 秒，到期后重新从数据库读取。

这种方案实现相对简单。

但 TTL 越长，数据可能越旧。

TTL 越短，缓存未命中率可能越高。

对于用户设置和权限数据，长时间读取旧信息可能造成业务问题。

例如，管理员已经撤销某个用户权限，但其他区域的缓存仍然保存旧状态。

因此，OpenAI 采用更主动的缓存失效机制。

它不是完全依赖时间到期，而是通过数据变更通知让不同区域的缓存及时更新。

十六、CDC 如何实现缓存失效？

CDC 全称 Change Data Capture，即变更数据捕获。

当底层数据库发生数据修改时，系统可以把对应变更传递给其他服务。

Habitat 使用 Azure Cosmos DB 的 Change Feed 获取相关变化。

随后，通过自身服务将缓存失效消息发送到各个区域。

当某个对象被修改时，相关缓存条目可以被主动标记失效。

下次访问时，应用再从底层数据库读取较新的数据。

OpenAI 表示，这一机制通常能够在数秒内完成全球缓存失效传播。

但这里也存在分布式系统的一致性问题。

例如，失效通知可能比数据库复制更快到达某个区域。

因此，仍然需要处理网络延迟、重试和短暂数据不一致。

十七、Rust 为什么能够帮助降低延迟？

Habitat 在早期使用 Python 服务层。

这种选择帮助团队快速开发。

但随着全球请求规模增长，服务层自身的开销变得更加明显。

OpenAI 后续将重要服务路径迁移到 Rust。

Rust 能够提供较低的运行时开销，同时保持对内存安全的重视。

结合区域复制和缓存优化，OpenAI 报告全球读取中位延迟从约 120ms 降至约 10ms。

这是约 12 倍的改善。

但这一结果不是单纯把 Python 改成 Rust 就得到的全部收益。

它来自数据放置、缓存和服务实现的组合优化。

对于中小型应用，直接重写所有服务通常并不是最优先工作。

应先确认瓶颈是否真的在语言运行时。

十八、Kafka 如何支撑大量数据变更？

OpenAI 的 CDC 系统不仅用于缓存失效。

它还支持二级索引、数据迁移、离线分析和其他实时功能。

文章提到，平台每秒处理数百万个数据变更事件，并通过上百个 Kafka Topic 分发。

这需要大量 Worker 和可靠的状态管理。

例如，某个消费者失败后，系统需要知道哪些事件已经处理。

对于无法正常处理的事件，可以使用 Dead Letter Queue，简称 DLQ。

它能够把持续失败的消息隔离，避免阻塞后续正常事件。

同时，还需要考虑重复投递。

因此，消费端业务通常应具备幂等处理能力。

十九、Habitat 从大型故障中学到了什么？

OpenAI 报告介绍了 2024 年末发生的区域故障和随后的一次故障恢复问题。

在某次云区域电力故障后，系统发现大型 Cosmos DB 账户进行区域切换可能需要数小时。

而在后续切回原区域时，大量客户端重新建立连接，进一步放大了故障。

这说明系统不仅需要能够切换到备用区域。

还要验证切换过程中的连接行为、缓存状态和请求流量。

对于高并发系统，故障恢复往往比平时运行更加困难。

因为大量客户端可能同时重试。

因此，生产系统应该设置重试退避、连接复用和必要的流量控制。

不能只准备一台备用服务器，却从未真正演练切换流程。

二十、未来的 EB 级自研存储已经开放了吗？

OpenAI 在文章结尾提到，正在开发自有的 EB 级在线存储系统。

该系统计划结合 RocksDB Cloud 核心与基于 Raft 的复制机制。

设计目标包括减少大规模数据所需的高性能存储资源，并改善部分存储类型的经济性。

但这仍属于研发中的未来平台。

不能将它写成 OpenAI 已经全面替换 Azure Cosmos DB。

也不能根据概念设计推断它一定能够提供更低的所有请求延迟。

OpenAI 当前披露的主线仍然包括 Habitat 与 Azure Cosmos DB 的深度工程协作。

二十一、中小型 AI API 平台可以借鉴什么？

对于规模远小于 ChatGPT 的 API 网站，最值得借鉴的通常不是复制 OpenAI 的全球架构。

而是以下原则。

第一，数据库与 API 服务需要明确分离职责。

第二，频繁读取的配置可以采用适当缓存。

第三，重型报表和导出任务不应阻塞在线请求。

第四，对热点用户和高负载操作设置限流。

第五，记录慢 SQL、数据库连接和缓存命中情况。

第六，在多节点部署中验证故障切换。

第七，对关键财务数据保持可靠的源数据库记录，不要只依赖缓存。

尤其对于涉及充值余额和用量扣费的系统，应优先保证账务正确性，再考虑缓存性能。

二十二、FAQ：常见问题

Habitat 是 ChatGPT 使用的大语言模型吗？

不是。它是 OpenAI 的在线存储平台。

Habitat 总数据量超过 500PB 吗？

OpenAI 官方介绍的平台总体规模超过 500PB，但不同组件存储的数据口径不同。

最大 Cosmos DB 账户有多大？

官方称存储数十 PB 数据，并处理超过 2000 万 QPS。

所有请求都只需要 10ms 吗？

不是。10ms 是全球读取 p50 的约略指标，不代表全部请求。

OpenAI 为什么使用 Valkey？

主要用于分布式缓存，减少频繁的远距离数据库读取。

CDC 可以保证零延迟一致性吗？

不能。变更传播存在延迟，系统仍需处理相关边界条件。

OpenAI 已经停用 Cosmos DB 了吗？

没有。官方介绍了持续合作，同时公布未来自研存储计划。

小型网站应该照搬 Habitat 吗？

通常没有必要，应按当前业务规模选择合理的数据库、缓存和运维方案。

二十三、结语：真正的高并发能力来自系统性设计

OpenAI Habitat 的发展经历说明，支撑大型 AI 产品不只依靠更强的 GPU。

数据存储、多租户隔离、热点管理、缓存一致性和故障恢复，同样决定用户体验。

Habitat 从共享容器走向独立容器，再回到经过增强的多租户架构，体现了工程实践中的不断权衡。

对于中小型 AI 平台，最重要的启示不是盲目追求 2000 万 QPS。

而是让当前业务在高峰负载下保持可靠、可观测和可恢复。

当系统真正面临新的瓶颈时，再依据真实指标逐步扩展基础设施。

官方参考资料

1. OpenAI — Rapidly scaling online storage to serve over 1 billion ChatGPT users (Part II) https://openai.com/index/scaling-storage-one-billion-users-part-two/

2. OpenAI — Rapidly scaling online storage to serve over 1 billion ChatGPT users (Part I) https://openai.com/index/scaling-storage-one-billion-users-part-one/

3. Microsoft Azure Cosmos DB 文档 https://learn.microsoft.com/en-us/azure/cosmos-db/

4. Valkey 官方项目 https://valkey.io/