官方更新 OpenAI Blog Fri, 23 Oct 2026 正文 thin 6 words

快速扩展在线存储以服务超 10 亿 ChatGPT 用户(第二部分)

英文标题:Rapidly scaling online storage to serve over 1 billion ChatGPT users (Part II)

随着 ChatGPT 用户规模突破 10 亿,OpenAI 对其自研在线存储平台 Habitat 进行了深度架构升级。通过构建可靠的多租户隔离机制、全局多级分布式缓存架构,并深度集成 Azure Cosmos DB,系统成功将读操作性能提升了 12 倍。这一实践为大规模 AI 原生应用处理高并发会话元数据、跨区域极速访问与海量数据持久化提供了关键的技术范式。
打开原文相关 2.4 · 机会 1

中文

快速扩展在线存储以服务超 10 亿 ChatGPT 用户(第二部分)

在 ChatGPT 的全球活跃用户突破 10 亿规模的过程中,底层基础设施面临着前所未有的吞吐量与低延迟考验。对话历史、用户会话状态以及各类 Agent 运行时的元数据,对在线存储的可用性、伸缩性和访问速度提出了极高要求。在第一部分探讨了基础存储选型与数据模型后,本文将深入解析 OpenAI 如何通过内部存储抽象平台 Habitat 应对多租户竞争、跨区域延迟以及极端突发读写,实现读性能提升 12 倍的架构演进。


背景与核心瓶颈

随着 OpenAI 内部涌现出越来越多的业务线与 API 服务,底层数据库直接暴露给业务代码带来了诸多风险:

  • 资源竞争与“吵闹邻居”效应:非关键后台批处理任务容易打满连接池,影响 ChatGPT 用户端的核心交互。
  • 跨地域高延迟:全球用户分布广泛,如果每次会话加载都穿透到底层跨区域主库,网络往返时间(RTT)将严重拖慢首字生成速度。
  • 数据库扩容瓶颈:直接在高并发流量下水平扩展单体数据库,容易遭遇连接数上限与成本激增。

为此,OpenAI 构建并演进了统一在线存储抽象层 Habitat,充当业务系统与底层物理数据库之间的智能调度中枢。


架构优化策略

1. 构建高可靠的多租户隔离(Reliable Multi-tenancy)

为了保障 ChatGPT 核心业务的 SLA,Habitat 引入了严格的多租户治理机制:

  • 配额管理与动态限流:各业务系统(租户)通过声明式配置定义吞吐量上限(RU/s 或 QPS)。Habitat 在接入网关层实施基于令牌桶的分布式限流。
  • 优先级调度与背压(Backpressure):将流量划分为核心在线交互(如用户对话获取)与离线异步任务(如日志与数据同步)。在系统高负载时,优先保障在线交互流量,对后台请求自动触发排队或背压。
  • 故障域隔离:不同租户的数据分片和逻辑连接池完全解耦,单一业务异常导致的慢查询不会扩散至全站。

2. 全局多级分布式缓存(Global Caching)

为突破物理存储的吞吐边界,团队在 Habitat 中设计了全球缓存网络:

  • 边缘/本地多级缓存:在计算节点与服务集群本地部署高速缓存层,绝大多数热门对话会话和元数据均可在距离计算节点最近的层级被命中。
  • 缓存一致性与智能失效:采用写入穿透(Write-through)结合分布式事件驱动的主动失效机制,确保跨区域节点更新数据时,缓存视图能在毫秒级保持一致。
  • 12 倍读加速:在全局缓存架构落地后,ChatGPT 会话加载与元数据读取的穿透率大幅降低,整体读性能提升达 12 倍,极大削减了底层数据库的读压力并降低了端到端延迟。

3. 深度适配与集成 Azure Cosmos DB

在底层物理持久化方面,OpenAI 选择了 Azure Cosmos DB 作为核心分布式文档存储引擎,并配合 Habitat 做了多项定制调优:

  • 弹性伸缩与自动分区:结合业务键设计了细粒度分区键(Partition Key),避免热点分区倾斜,充分利用 Cosmos DB 的全球多区多活与自动扩缩容特性。
  • 连接与请求复用:Habitat 负责全局连接池管理与批处理聚合,合并高频小粒度请求,显著优化底层数据库资源消耗与计费效率。

总结与行业启示

通过对 Habitat 平台的持续迭代,OpenAI 在保障超 10 亿用户级系统的稳定性与性能之间找到了平衡。其核心经验表明:对于超大规模 AI 应用,将存储访问逻辑抽象化、实现细粒度多租户隔离,并依托全局多级缓存降低底层依赖,是实现兼具低延迟与高弹性基础设施的关键路径。

English / 原文

Enable JavaScript and cookies to continue