支撑 10 亿级 ChatGPT 用户的在线存储如何快速扩容（下篇）

了解 OpenAI 如何通过可靠的多租户架构、全局缓存和 Azure Cosmos DB 来扩展 Habitat，为 ChatGPT 实现快 12 倍的读取速度。

OpenAI 工程团队公开 Habitat 在线存储系统的第二篇实践：通过可靠的多租户隔离、全局缓存和 Azure Cosmos DB，把 ChatGPT 的读取性能提升到 12 倍。

• OpenAI 工程团队公开 Habitat 在线存储系统的第二篇实践：通过可靠的多租户隔离、全局缓存和 Azure Cosmos DB，把 ChatGPT 的读取性能提升到 12 倍。
• 原贴提到：Learn how OpenAI scaled Habitat with reliable multi-tenancy, global cach
• 来源：openai.com

这是什么信号

OpenAI 发布了 Habitat 系列工程博客的第二篇，主题是“在线存储如何快速扩容以服务 10 亿以上 ChatGPT 用户”。这篇内容披露了三个工程重点：可靠的多租户、全局缓存，以及基于 Azure Cosmos DB 的存储方案，最终带来 ChatGPT 读取速度 12 倍的提升。

这不是一次产品发布，而是一次基础设施能力披露。它说明 OpenAI 已经把叙事重心从“模型能做什么”推进到“模型背后的系统能撑住多少人”。

为什么重要

10 亿用户量级下，存储面临的挑战不再是容量，而是共享资源下的稳定读取。多租户意味着不同客户、不同请求共用同一套底层系统，任何一个租户的异常都可能影响其他租户；缓存意味着延迟和数据库负载之间的取舍；托管数据库则意味着把一部分可靠性交给外部云厂商。这三件事同时被拿出来讲，说明真正的瓶颈是“在共享资源的前提下，持续提供低延迟、可预期的读取”。

对做 AI 应用的公司来说，这是一个明确的参照：当你的产品从几十万用户走到百万、千万级，最先撑不住的地方通常不是模型调用，而是会话、消息、文件、向量这类在线存储的读写路径。

对谁有价值

• 正在把 AI 产品从早期验证推向规模化的技术负责人和架构师；
• 需要设计多租户 SaaS 或对外 API 平台的团队；
• 在用 Azure 技术栈、正在评估 Cosmos DB 与缓存层组合的工程团队；
• 关心头部 AI 公司基础设施演进路径的产品与投资侧观察者。

可以怎么行动

• 先检查自己的读取路径：哪些请求可以走缓存、哪些必须落到数据库，把这条边界画清楚；
• 做多租户隔离时，优先明确“隔离到什么粒度、超限时如何限流和降级”，而不是先争论技术选型；
• 把“读取性能”做成可观测指标（P99 延迟、缓存命中率、单租户热点），再谈优化倍数；
• 如果你在用托管数据库，评估跨区分发、一致性与成本之间的关系，而不是只看单次查询速度。

风险与限制

• 原文只给出了架构方向和读取提速倍数，没有披露具体压测条件、数据规模和成本变化，因此不能直接把“12 倍”当作通用预期；
• 多租户、全局缓存与托管数据库的组合会引入新的运维复杂度，对小团队来说很可能得不偿失；
• 缓存带来的一致性代价在实时性强的场景（如对话状态、计费、权限）需要单独设计，不能整体照搬；
• 把可靠性的重要部分交给云厂商，同时也意味着成本与可用性会在一定程度上依赖外部服务。

这条内容的真正价值，不只是“有人发布了一个新功能”，而是它揭示了 openai.com 背后的产品方向、工作流变化或竞争信号。对 OPC 来说，这种信息可以转化成持续追踪的栏目选题。

如果把《支撑 10 亿级 ChatGPT 用户的在线存储如何快速扩容（下篇）》放到你的内容系统里，它最大的价值在于帮助读者更快看懂“为什么值得关注”，而不是只看到一条碎片化动态。

• OpenAI News 原帖