2026 年 10 月 23 日，OpenAI 工程团队成员 Jon Lee、Hrachya Hakobyan 与 Chaomin Yu 发布了工程技术连载博客第二篇《Rapidly scaling online storage to serve over 1 billion ChatGPT users (Part II)》，披露了其应用存储平台 Habitat 如何基于 Azure Cosmos DB 应对超大规模增长的架构演进。10 月 24 日该主题在 Hacker News 社区出现收录，公开记录显示为 2 票、0 条回复。虽然社区互动平淡，但其公开的存储隔离机制为理解 ChatGPT、Codex 及商业 API 的线上数据存取边界提供了直接依据。
根据官方披露，Habitat 是 OpenAI 承载所有产品在线数据访问的核心平台，目前在 40 个地理区域为全球超过 10 亿用户提供毫秒级响应，底层纳管的数据规模已突破 500 PB。在第一篇博客介绍了该平台从 Python 客户端演化为独立服务后，本篇重点梳理了底层 Cosmos DB 存储资源的多租户演进。
从单租户探索重回默认多租户：QoS 与热点限流
官方披露，面对爆发式增长与新兴业务负载，Habitat 的存储设计经历了三个关键阶段的权衡：
- Phase I（依赖云数据库原生机制）：早期直接利用 Azure Cosmos DB 的容器与分区能力。但随着业务快速膨胀，平台相继遭遇逻辑分区键上限、分区拆分后单分区吞吐能力下降（Weak partitions）以及突发流量造成的“嘈杂邻居（Noisy neighbors）”资源争用。
- Phase II（工作负载隔离与单租户尝试）：为了避免不同业务相互干扰，团队曾尝试单租户方案，让各个产品表面团队各自维护独立的系统。这种模式虽然边界清晰、降低了爆炸半径，但无法利用整体聚合增长的平滑效应。各团队不得不独立做容量规划，最终造成了严重的资源过度预配与高昂的运行成本。
- Phase III（默认多租户与数据迁移能力）：团队最终确立了以联合管理容器为基础的多租户默认架构。该阶段引入了热点键限流（Hot key throttling）、服务质量分级（QoS）以及 Serverless 模式，在保持集中化容量调配效率的同时，针对消耗异常资源的租户执行限制，保障关键交互请求的资源配给。
Weak partitions 的具体机制是：容器的总预配吞吐量大致分配给物理分区；数据增长触发分区拆分，而总吞吐量未同步增加时，单个分区分得的容量会下降。它不能简单等同于数据分布倾斜。
全球性能考量：缓存依赖与代理减负
在整体架构上，Habitat 整合了多项底层资源，除 Azure Cosmos DB 外，还包括 Nanobase、基于 Valkey 的缓存、Blob 存储以及接入 Databricks、Rockset 和 Kafka 的变更数据捕获（CDC）服务。
针对跨地域访问的性能优化，官方在文章目录中列出了清晰的工程取舍方向：
- 数据放置与复制：本次取得的目录列出了容量允许时将数据放近用户、广泛复制较小且延迟敏感的数据集、其余依靠集成缓存等方向。对应章节正文未完整提供，因此不进一步推定具体部署范围或实际延迟效果。
- Rust 代理减负：针对网关链路的消耗，官方博客目录中列出了“Reduce proxy overhead with Rust”这一章节，体现出利用 Rust 降低代理层资源开销的工程演进（注：已公开节选尚未展开具体实测数值）。
- 保障交互式请求：通过 QoS 策略，系统优先满足 ChatGPT 和 Codex 终端用户的在线交互请求，防止后台大吞吐离线任务抢占宝贵的在线 I/O 资源。
理解工程边界：基础设施治理不等于套餐权益扩容
结合本次披露的内容，终端用户与开发者应当清晰区分存储基础设施与模型推理之间的技术边界：
一方面，Habitat 解决的是高并发环境下元数据读写、历史会话存取和鉴权信息的毫秒级可用性，重在降低多业务混部时的级联阻塞风险。但文本生成每秒输出多少 Token，主要取决于 GPU 集群上的模型推理算力，存储优化并不直接决定推理生成的整体耗时。
另一方面，本次取得的正文节选与目录重点介绍存储架构，未提供足以确认个人存储空间、上下文窗口或调用额度调整的资料。不能从这份节选推定权益增加，也不能据此断言完整文章或其他公告没有这些信息。
在日常使用中若遇到聊天记录加载异常或服务波动，可参考专业排查步骤确认是网络环境、本地缓存还是服务端状态所致（详见ChatGPT 故障降级排查指南）。若业务开发需要稳定高并发支持或评估团队订阅方案，可查阅 PayForChat 当前套餐入口；而关于调用额度与订阅等级的具体计算，则建议参考Codex 配额与 ChatGPT Pro 升级解析的实际说明。
注：本文基于 OpenAI 官方工程博客于 2026 年 10 月 23 日发布的《Rapidly scaling online storage to serve over 1 billion ChatGPT users (Part II)》及社区公开记录进行核实整理（核实日期：2026 年 10 月 25 日）。受限于公开来源的正文节选范围，文中所涉及的技术设计与演进方向均以已核实文本为准。
常见问题解答 (FAQ)
Q: Habitat 在 OpenAI 架构中扮演什么角色？ A: Habitat 是 OpenAI 自建的应用在线存储平台，位于 ChatGPT、API、Codex 等前台客户端与底层存储资源（Cosmos DB、Nanobase、Valkey、Blob 等）之间，负责元数据路由、缓存、访问控制、数据驻留与流量限流。
Q: 底层存储扩容是否意味着 ChatGPT 生成文本的速度会变快？ A: 在线存储和模型推理是不同环节。本次提供的节选没有足以量化推理生成速度变化的资料，不能据此保证回答提速，也不能据此否定其他完整资料可能说明的性能变化。
Q: OpenAI 为什么放弃了纯粹的单租户隔离模式？ A: 官方披露在 Phase II 尝试单租户时，各产品团队必须各自独立预估和配置容量，无法利用全平台聚合增长的平滑效应，导致资源严重过度配置且运维成本高昂，因而最终转向具备精细隔离手段的默认多租户架构。
Q: 遇到聊天记录偶尔加载缓慢时，属于 Habitat 的故障吗？ A: 聊天记录展示涉及在线存储读取、网关鉴权及客户端网络传输等多个链路。Habitat 的 QoS 与防嘈杂邻居机制旨在降低存储侧的负载争抢，但最终用户侧的感知延迟仍可能受网络链路或整体服务状态波动影响。
Q: 本次官方工程分享是否附带 ChatGPT Plus 或 Pro 会员存储容量的增加？ A: 本次取得的节选未提供会员容量调整的具体信息，不能据此确认增加，也不能推断全文或其他公告均未涉及。会员权益应按当前专门的套餐说明核对。
Q: 针对高并发 API 请求，官方设计了哪些存储隔离机制？ A: 官方在 Phase III 架构中引入了热点键限流、服务质量分级（QoS）以及 Serverless 弹性模式，其设计目标是限制个别高负载租户过度占用资源，保障关键请求的优先级，但本次取得的节选未提供可用于判断接口 5xx 或超时率改善幅度的完整数据。