OpenAI 揭秘 ChatGPT 存储底座：靠定制 Azure 支撑 10 亿用户

支撑 10 亿人每天跟 ChatGPT 对话，底层存数据的系统到底长什么样？

很多人以为大模型公司最烧脑的是显卡和算力，其实海量用户涌进来时，后端的在线数据库更先喊救命。10 月 23 日，OpenAI 工程团队发文复盘了自研应用存储平台 Habitat 的演进史。

这套系统目前要在全球 40 个地区承接超过 10 亿用户，管理的数据量突破了 500 PB。为了扛住这个体量，OpenAI 联手微软 Azure 团队，把底层的 Azure Cosmos DB 折腾了个底朝天。

从被「吵闹邻居」搞垮，到全员上线救火

最开始，OpenAI 偷了个懒，把所有业务的数据塞进 Cosmos DB 的同一个大容器里。很快现实就上了一课：某个边缘小功能要是突然冒出一个超高频访问的「热键」，连带把同一个物理分区上的登录、注册流程全给挤瘫痪了。

更要命的是分区机制。随着数据越存越多，底层物理分区自动分裂，但总吞吐预算没变，结果每个分区分到的读写能力反而缩水。这意味着有些大容量业务就算请求量没涨，光靠堆数据就能把自己活活憋死。

为了止血，架构师们转头要求各业务线「分家」，给关键新功能单开独立容器。隔离效果确实立竿见影，却换来了组织上的灾难。

各个业务团队水平参差不齐，没人懂怎么算容量。经常是某个功能今天上线，团队忘了提前扩容，结果全员直接在故障警报室里手忙脚乱地临时拉配置。集中管会互相干扰，分散管大家又管不好。

找微软开外挂，再用 Rust 重写代理

折腾了一圈，OpenAI 决定杀回多租户架构，拉着微软 Azure 团队定制了一套「协同管理容器」。

他们从底层改了排队逻辑：谁访问最烫就先限流谁，绝不让单个大客户拖垮整个物理分区；再给请求分级，离线大批量写入必须给前台用户的交互式请求让路。

除了底层改造，工程团队还把数据尽量存到离用户最近的机房，只对延迟敏感的数据做跨区复制，加上内置缓存，并直接用 Rust 重写了代理逻辑。这一套组合拳下来，在撑住 500 PB 数据的同时，把数据读取速度直接拉高了 12 倍。

为什么重要

这篇架构复盘之所以值得看，是因为它把生成式 AI 从实验室推进到顶级国民级应用时，最真实的一道工程暗礁给摊开了。做模型是一回事，让全球几亿人同时秒级加载对话记录完全是另一回事。

对于大部分正在做 AI 应用的开发者和架构师来说，现在盲目去抄这套方案没有意义。500 PB 和 10 亿用户是极端规模下的极端解法，你大概率不需要自己去改底层分区逻辑。但他们踩过的坑极具参考价值，特别是过早拆分独立资源导致的容量规划失控，在任何中大型团队都屡见不鲜。

我们认为，OpenAI 这一步最聪明的地方在于没有盲目自研全新的分布式数据库，而是押注在云巨头的成熟组件上，反客为主逼着微软针对自己的极端负载打磨 Cosmos DB。这种深度定制既省去了造轮子的巨大风险，也把自身沉淀的工程壁垒顺手做进了微软的基础设施里。当然，隐患也很现实：这种高度协同让 OpenAI 与 Azure 绑得越来越深，日后想要跨云迁移或者分散云厂商依赖，成本只会高到难以想象。