ChatGPT存储读速提升12倍

OpenAI近日披露了ChatGPT在线存储架构的第二阶段改造：其内部存储平台Habitat通过可靠多租户、全局缓存和Azure Cosmos DB，将读取速度提升至原来的12倍，并把服务规模扩展到超过10亿用户。

这次升级没有改变模型本身，却直接影响每一次对话能否快速打开、历史记录能否稳定加载，以及记忆、搜索和智能体任务能否在全球范围内持续运行。对于今天的ChatGPT而言，存储系统已经不再是模型之外的辅助设施，而是决定产品体验上限的核心组件。

Habitat是什么：ChatGPT背后的在线状态层

Habitat是OpenAI为ChatGPT构建的在线存储平台，负责以低延迟方式保存和读取用户、会话及产品功能所依赖的状态数据。

与训练数据仓库不同，Habitat处理的是正在被产品实时访问的在线数据。用户打开ChatGPT首页时看到的对话列表、切换设备后恢复的上下文、更新个人设置，以及部分记忆和智能体状态，都可能依赖这类在线存储能力。

OpenAI在第一阶段披露的信息显示，Habitat已经从一个Python库演进为全球分布式存储平台，每秒需要处理约2200万次请求。第二阶段解决的问题则更具体：当业务继续增长、不同工作负载开始互相影响时，怎样让这个平台在多租户环境下仍然足够快、足够稳。

“超过10亿用户”描述的是平台需要覆盖的总体用户规模，并不等同于10亿人同时在线。即便如此，只要其中一部分用户集中在热门时区打开对话、搜索历史或恢复任务，存储层就会在短时间内承受极高的读取压力。

12倍提速，不是数据库换了一个型号

读取速度提升12倍是一次系统级优化结果，而不是单纯升级数据库实例或增加服务器数量。

在线存储的端到端延迟通常由多段成本叠加而成，包括网络往返、身份验证、租户路由、缓存查询、数据库分区访问、序列化和反序列化。即便底层数据库只花费几毫秒，跨区域访问或热点分区仍然可能把用户可感知的等待拉长到数百毫秒。

OpenAI此次公开的三个关键抓手分别是可靠多租户、全局缓存和Azure Cosmos DB。三者解决的并不是同一个问题：多租户负责隔离风险，缓存负责缩短读取路径，Cosmos DB负责持久化数据并提供跨区域承载能力。

| 架构环节 | 主要解决的问题 | 对读取性能的作用 | 典型风险 | | --- | --- | --- | --- | | 可靠多租户 | 不同业务共享平台时相互干扰 | 控制资源竞争，稳定尾延迟 | 热门租户挤占容量 | | 全局缓存 | 重复数据被频繁跨区域读取 | 让请求在更靠近用户的位置命中 | 缓存失效与数据陈旧 | | Azure Cosmos DB | 全球持久化、分区和扩展 | 承接缓存未命中的权威读取 | 热分区、请求单元消耗 | | Habitat平台层 | 屏蔽底层存储复杂度 | 统一路由、策略和故障处理 | 抽象层过重或策略失配 |

12倍这个数字的价值不只在于让平均响应更快，而在于给ChatGPT留下更多容量余量。在线服务真正难处理的往往不是平均请求，而是流量突增时最慢的那1%甚至0.1%请求；这些尾部请求会占住连接和计算资源，并进一步放大排队效应。

OpenAI并未把12倍直接等同于ChatGPT整段回答速度提升12倍。回答生成仍然受模型推理、工具调用、搜索和网络传输影响，但历史会话加载、用户状态查询和任务恢复等以读取为主的路径，会更直接地从中受益。

多租户隔离，是规模化之后必须补的一课

可靠多租户是指多个产品、团队或工作负载共享同一套存储平台时，系统仍能保证资源隔离、故障边界和服务质量。

ChatGPT并不是一个只有“发送消息”和“生成文字”的单体应用。它同时承载普通对话、文件分析、联网搜索、图片功能、语音交互、企业工作区和智能体任务，不同功能的访问模式差异很大。

普通对话可能以短小且频繁的读取为主，文件与智能体任务则可能产生更大对象和更长生命周期。如果所有请求直接竞争同一组分区、连接和吞吐配额，一个快速增长的新功能就可能拖慢原本稳定的核心对话路径。

OpenAI强化多租户能力的核心意义，是把“谁在消耗资源”变成可识别、可限制和可调度的信息。平台可以针对租户设置容量边界、优先级和过载策略，让单个工作负载的突发流量不至于演变成全局事故。

这种设计也降低了ChatGPT内部团队使用存储服务的门槛。产品团队不必各自重复解决分区、扩容、限流和区域故障问题，而是通过Habitat获得相对一致的接口和运行保障。

但平台化并不意味着底层成本消失。统一抽象如果缺少配额治理，反而会让开发者看不到真实的数据访问成本，因此可靠多租户必须同时具备隔离、计量和可观测性，而不仅是给不同业务添加租户名称。

全局缓存，把数据放到离用户更近的位置

全局缓存是分布在多个地理区域、用于保存高频数据副本的缓存层，目标是在不访问远端权威数据库的情况下完成大部分读取。

ChatGPT的用户遍布不同国家和地区，而数据的权威副本不可能始终位于每个用户附近。如果亚洲用户的每一次会话列表读取都要跨洲访问数据库，网络光速和路由距离就会构成无法通过代码优化消除的延迟下限。

缓存的效果取决于命中率，而不是节点数量。一个数据项只有在被重复读取、更新频率相对可控时，缓存才真正划算；如果数据频繁变化或访问高度随机，大量缓存空间只会保存很快过期的内容。

ChatGPT天然存在适合缓存的读取模式。用户通常会反复打开最近几段对话，产品也会频繁读取相对稳定的账户配置和功能状态，这些数据在短时间窗口内具有较高复用率。

缓存最难的部分仍然是正确性。用户修改设置、删除对话或更新权限后，旧副本必须及时失效，否则系统可能返回过时内容；涉及企业工作区和访问控制时，错误缓存甚至可能成为安全问题。

OpenAI把全局缓存放在Habitat平台内统一管理是一个合理选择。由平台控制缓存键、生命周期和失效策略，比让每个产品团队自行接入缓存更容易维持一致语义，也更容易在发现问题时进行全局回退。

Cosmos DB承担的是权威数据层

Azure Cosmos DB是微软Azure提供的全球分布式NoSQL数据库服务，支持数据分区、多区域部署、弹性吞吐和多种一致性级别。

Cosmos DB适合Habitat的一点，是它把物理扩展问题抽象成逻辑分区和吞吐管理。对于规模快速变化的ChatGPT，平台可以围绕用户、工作区或其他业务标识设计分区键，再把数据和请求分散到更多底层资源。

分区键决定了数据如何被放置，也决定了系统能否真正横向扩展。若大量热门数据被映射到少数逻辑分区，即使数据库总容量充足，这些分区仍可能成为热点，导致局部限流和尾延迟升高。

Cosmos DB常用请求单元衡量数据库操作消耗，不同查询、对象大小和索引策略会产生不同成本。Habitat作为中间平台，可以集中优化访问模式，让上层业务减少昂贵扫描，并把重复读取尽量挡在缓存层。

缓存与Cosmos DB并不是互相替代的关系。Cosmos DB保存权威状态并提供持久性，全局缓存承担高频读取；缓存失效或未命中时，请求仍然需要回到数据库，因此底层分区设计和容量管理依旧决定系统下限。

为什么ChatGPT不能只靠传统关系数据库

传统关系数据库并非无法支撑大型产品，但ChatGPT面临的全球规模、访问频率和产品迭代速度，会迅速放大集中式架构的限制。

单一主库加只读副本可以覆盖许多常规互联网业务，但在每秒约2200万次请求的量级下，连接数、复制延迟、跨区域写入和热点表都会变成长期问题。继续纵向升级硬件只能换取有限空间，也会把故障集中在更昂贵的节点上。

| 方案 | 扩展方式 | 全球读取 | 一致性处理 | 更适合的场景 | | --- | --- | --- | --- | --- | | 单体关系数据库 | 以纵向扩容为主 | 依赖远程访问或只读副本 | 强事务能力突出 | 规模可控、事务复杂的业务 | | 分库分表关系数据库 | 应用管理分片 | 需要自行搭建多区域体系 | 跨分片事务复杂 | 访问模式稳定的大型业务 | | Cosmos DB加全局缓存 | 分区与区域横向扩展 | 可就近命中缓存或区域副本 | 可按需求权衡一致性 | 全球化、高并发在线状态 | | Habitat平台 | 在数据库之上统一治理 | 对业务屏蔽区域和路由细节 | 由平台规范读写语义 | 多团队、多产品共享基础设施 |

Habitat真正有价值的地方，是把数据库能力变成面向ChatGPT业务的存储产品。数据库提供分区和复制，但它不会自动理解哪个功能更重要、哪个租户需要限流，也不会替OpenAI决定删除操作应如何传播到全球缓存。

这套架构对开发者意味着什么

OpenAI的经验说明，生成式AI产品的瓶颈正从模型推理扩展到完整的数据路径。

很多AI应用在早期只关注Token生成速度，却忽略了会话、权限、文件、记忆和工具状态。当用户量增加后，模型可能在几百毫秒内开始输出，应用却要先用更长时间查询用户资料和历史记录，最终首字延迟仍然很差。

第一条可复用经验是按访问模式设计存储，而不是按页面设计数据表。高频读取、强一致写入、大对象和短生命周期任务状态应当被区分处理，因为它们对缓存、索引和分区的要求完全不同。

第二条可复用经验是提前建立租户边界。即便产品还没有企业客户，不同功能和内部团队也会形成事实上的租户；只有在请求链路中保留租户身份，后续才能做配额、优先级、成本核算和故障隔离。

第三条可复用经验是把缓存一致性当作产品语义问题。开发者需要明确哪些数据允许短暂陈旧、哪些操作必须立即可见，以及缓存不可用时系统应回源、降级还是拒绝请求。

第四条可复用经验是持续观察尾延迟。平均耗时从20毫秒降到10毫秒固然有意义，但如果P99仍然需要1秒，用户仍会频繁遇到明显卡顿；对于多步骤智能体任务，多个慢请求还会串联放大总耗时。

OpenAI这次升级的真正信号

OpenAI正在把ChatGPT从一个大模型聊天入口改造成长期在线的个人计算环境，而Habitat就是这个环境的状态底座。

当产品只负责一次性问答时，服务端可以尽量保持无状态；当ChatGPT开始记住用户偏好、连接外部工具、运行长时间任务并在不同设备间恢复进度时，可靠状态管理就与模型能力同等重要。

此次12倍读取提速值得肯定，因为它针对的是已经得到真实流量验证的系统瓶颈，而不是实验室跑分。相比更换一个模型名称，存储架构优化不容易成为发布会焦点，却更可能改善十亿级用户每天反复遇到的加载和恢复体验。

这套方案也并非没有代价。全球缓存、多区域数据库和多租户治理都会提高系统复杂度与云资源成本，团队需要处理缓存一致性、容量规划、跨区域故障以及数据驻留等问题；规模不足的产品照搬整套架构，很可能得不偿失。

OpenAI披露Habitat的意义最终不在于给出一份可以直接复制的架构图，而在于确认了一个趋势：头部AI产品的竞争已经进入模型、推理、存储和全球调度共同决定体验的阶段。模型回答得是否聪明仍然最重要，但在超过10亿用户的规模上，系统能否快速、稳定地找到正确数据，同样决定ChatGPT能不能真正成为基础设施。

参考来源

• OpenAI官方工程文章《Rapidly scaling online storage to serve over 1 billion ChatGPT users (Part II)》：本文核心事件来源，披露Habitat通过可靠多租户、全局缓存和Azure Cosmos DB实现12倍读取提速；依据指定域名规则不附站外链接。
• OpenAI官方工程文章《Rapidly scaling online storage to serve over 1 billion ChatGPT users (Part I)》：介绍Habitat从Python库演进为全球存储平台，并披露每秒约2200万次请求的规模；依据指定域名规则不附站外链接。
• Azure Cosmos DB Python SDK：微软官方开源SDK仓库，可用于核对Cosmos DB的分区、请求单元和客户端机制。
• Azure Cosmos DB Java SDK：微软官方Java SDK实现，提供Cosmos DB连接、分区路由与可靠性机制的工程参考。