OpenAI披露Habitat支撑10亿用户

OpenAI在9月11日发布的Habitat工程复盘，把模型公司很少公开的一层基础设施放到了前台：在线存储。RSS摘要出现22M requests per second，正文主文则写明more than 70 million requests every second；本文按正文主文采用后者。同一篇正文还写到，Habitat支撑每周超过1B人使用的产品，跨近40个地理区域，服务超过500PB数据。

这是一条高置信的官方工程新闻，但它仍然是厂商自述。可确认的是发布时间、吞吐、数据规模、迁移比例和OpenAI对故障模式的解释。暂时不能确认的是OpenAI内部每条产品线的调用占比、尾延迟分布、Azure Cosmos DB合作扩容的具体容量，以及Codex在Rust重写里到底承担了多少代码生成和工程审查工作。

对读者最直接的影响在于评估AI平台的方式变了。ChatGPT、API和Codex的体验不只取决于模型权重和推理集群，还取决于登录、会话状态、设置读取、权限控制和数据访问这些低层路径能否在流量高峰下稳定运行。企业买方如果只问模型分数，已经看不全平台风险。

这篇复盘也把一个容易被忽略的问题摆出来：当AI产品进入十亿用户级别，存储系统会成为产品速度、安全策略和成本曲线的共同约束。OpenAI没有宣布新模型，却披露了支撑模型产品的运行账本，这就是它成为本期头条的原因。

这次新增了什么

OpenAI发布的是两篇系列文章的第一篇，主题是「Rapidly scaling online storage to serve over 1 billion ChatGPT users」。这篇文章的news peg很清楚：9月11日，OpenAI公开Habitat在线存储平台的扩容过程，并给出最新规模数字。

Habitat最初并不是一个庞大的平台。按OpenAI正文，两年前它还是一个连接单一数据库的Python客户端库。随着ChatGPT、API、Codex等产品路径同时依赖它，团队把它抽离成独立服务，用集中部署来处理观测、访问控制、下游保护和跨服务升级协调。

OpenAI举的入口路径很具体。用户登录、Codex读取设置、ChatGPT开始新对话，都需要快速、可靠地访问数据。这类路径的特点是业务上看起来琐碎，但一旦慢下来或失败，用户感知会非常直接。

更重要的是，OpenAI把规模口径写得很重。Habitat现在每秒处理超过70 million requests，支撑每周超过1 billion人使用的产品，覆盖近40个地理区域，并服务超过500PB数据。这是一份面向十亿用户产品线的数据平面复盘，已经超出内部小服务优化笔记的范围。

数字口径先校准

本篇最需要核对的是吞吐口径。OpenAI News RSS的description写的是「serving 1 billion ChatGPT users and 22M requests per second」。但采集到的OpenAI正文明确写成「Habitat now handles more than 70 million requests every second」。因此，本文采用正文中的70M+作为主口径，RSS只用于确认发布时间和列表发现。

英文措辞	本文采用	核查边界
Habitat now handles more than 70 million requests every second	Habitat每秒处理超过7000万次请求	只写RSS摘要的22M，或把22M当最新主结论
supporting products used by over 1 billion people each week	支撑每周超过10亿人使用的产品	写成每日用户或只指ChatGPT单一路径
serving over 500 petabytes of data	服务超过500PB数据	写成新增500PB或迁移500PB
the Rust service is now handling 95% of production requests	Rust服务已处理95%生产请求	写成计划处理95%，或已完全替换
6x more CPU efficient and 15x more memory efficient than the Python version	CPU效率为Python版6倍，内存效率为15倍	写成相对上次又提高，或不说明Python基准

这个表的意义不只是防止数字写错。工程复盘里的数字常常同时承担三种功能：事实披露、迁移进度和成本暗示。如果把「已承载95%生产请求」写成「即将承载」，读者会误判迁移阶段；如果把「6x和15x」去掉Python基准，读者会误以为它是跨语言、跨团队、跨服务都成立的普遍规律。

这里也要说明一个状态语义边界。本文没有把keep、remain、maintain这类维持状态词改写成再次提高；OpenAI这篇核心数字的主要动词是handles、supporting、serving、is now handling和is more efficient。对应中文应分别写为处理、支撑、服务、已处理和效率高于Python版。

Habitat为什么从库变成服务

把一个Python客户端库改造成独立服务，表面看是软件架构改造，实质上是在改变组织协作方式。客户端库模式的好处是接入快，业务服务直接调用就能跑。坏处是在规模增长后，每一次行为变化、限流策略、观测增强和访问控制调整，都可能变成跨团队升级。

OpenAI正文给出的转折点，是Habitat需要把公共能力从调用方代码里收回来。独立服务可以统一发布，也能在一个位置观察请求、施加访问控制、保护下游数据库，并把连接池、熔断、限流这些能力做成平台默认值。对十亿级产品来说，这些默认值会直接决定事故半径。

这也是为什么Habitat不是一篇普通的数据库使用经验。它承载的是产品层和数据层之间的控制面：谁能访问什么数据，访问失败时如何降级，热点请求如何被隔离，下游数据库压力如何被切开。模型越强，产品越多，这层控制面越像平台竞争的基础设施。

OpenAI在文中把服务化带来的收益写得很克制，没有宣称它解决了所有扩展问题。相反，文章花了不少篇幅解释Python服务在大规模下遇到的运行时和连接池问题。这种写法反而更有信息量，因为它说明瓶颈不是单一数据库容量，而是多层系统在高并发下的耦合。

Python瓶颈暴露的是什么

OpenAI点名了几个具体问题。第一类是Python asyncio调度延迟。异步模型可以支撑大量并发，但事件循环一旦被配置解析、同步代码或长尾任务拖住，尾延迟会放大。对登录和新对话这类路径来说，尾延迟比均值更接近用户体感。

第二类是配置系统带来的抖动。正文提到Statsig配置定时解析造成尾延迟。配置管理通常被视作产品实验和灰度发布工具，但到了核心数据路径上，配置解析本身也会变成性能事件。这里的启发是，平台团队不能只监控数据库和网络，也要监控运行时内的周期性任务。

第三类是连接复用策略。OpenAI提到aiohttp TCPConnector的LIFO连接复用会触发负载集中，进而造成metastable failure。这个词值得展开：系统在正常负载下看似稳定，但一次扰动会让请求集中到少量下游连接或节点，局部变慢后又吸引更多重试和排队，最后停在一个难以自动恢复的坏状态。

OpenAI列出的缓解动作包括FIFO连接复用、Envoy和Istio连接池、HTTP/2多路复用、限流和熔断。这些都是成熟工程手段，但放在Habitat语境里，它们共同回答的是一个问题：当AI产品有海量短请求时，数据库前面的服务层必须主动管理排队、连接和失败扩散。

问题层级	OpenAI披露的现象	对平台的含义
运行时调度	asyncio调度延迟影响尾部请求	语言运行时会进入用户体验链路
配置解析	Statsig定时解析造成尾延迟	实验系统也是生产路径风险源
连接复用	LIFO复用触发负载集中	连接池策略会放大局部故障
流量保护	限流、熔断、连接池成为必需项	数据服务要主动约束调用方
协议层	HTTP/2多路复用被纳入治理	请求模式比单机性能更关键

从这些细节看，Habitat的核心矛盾不是「Python不行，Rust就行」。更准确的说法是，Python版本把OpenAI带到了一个很高的规模上，峰值曾支撑每秒超过2000万次请求；只是随着年增长和产品复杂度上升，运行时成本、内存占用和尾延迟开始变成平台约束。

Rust重写不是孤立的语言选择

OpenAI称，平台成熟且规模继续增长后，团队在2026年第二季度由2名工程师借助Codex和GPT-5.5把服务重写为Rust。新服务现在处理95%生产请求，CPU效率比Python版本高6倍，内存效率高15倍，平均和尾部延迟也明显降低。

这组数字需要分两层读。第一层是工程结果：Rust版本已经进入生产主路径，95%这个比例说明迁移不是概念验证。第二层是组织结果：OpenAI愿意把「2名工程师、Codex和GPT-5.5」写进复盘，说明AI辅助工程已经从演示进入内部平台改造叙事。

但这里不能推出「两名工程师就能重写任意大规模系统」。Habitat已经有清晰的业务语义、成熟的运行指标和Python版本的行为参照。Rust重写更像是在已有平台边界内进行性能和可靠性再实现，而不是从零创建一个未知系统。

Codex在这里的角色也需要克制表述。OpenAI说工程师借助Codex和GPT-5.5完成重写，但没有披露模型生成了多少代码、多少测试、多少迁移计划，也没有公开review、回滚和灰度细节。可以确认的是AI工具被放入OpenAI自己的高风险基础设施改造叙事；不能确认的是它替代了多少资深工程判断。

维度	Python阶段	Rust阶段	仍未公开
承载规模	峰值超过20M请求每秒	已承载95%生产请求	剩余5%的业务类型
资源效率	作为对比基准	CPU效率6x，内存效率15x	测试硬件和负载分布
团队投入	多团队长期演进	2名工程师在Q2 2026重写	代码审查和灰度成本
AI辅助	未作为主叙事	使用Codex和GPT-5.5	自动化贡献比例
延迟表现	出现尾延迟压力	平均和尾部延迟降低	P50、P95、P99具体数值

这张表也说明，Rust在这里不是简单的「更快语言」标签。它代表OpenAI愿意为了平台可预测性，付出重写、迁移和验证成本。对基础设施团队来说，语言迁移只有在业务语义稳定、观测充分、回滚路径清晰时才合理；否则效率提升很容易被迁移风险吞掉。

Cosmos DB线索只适合作为背景

OpenAI正文最后预告，系列后续会谈到多租户可靠性、读性能优化，以及与Azure Cosmos DB的合作扩容。本篇不能提前替后续文章下结论，尤其不能从Microsoft文档反推OpenAI内部架构细节。

Microsoft Learn对Azure Cosmos DB的公开说明，可以帮助读者理解为什么这个名字会出现在Habitat复盘的后续预告里。Cosmos DB定位为完全托管的NoSQL和向量数据库，强调全球分布、低延迟、自动扩展、SLA支持，以及用Request Units进行吞吐和成本治理。

这些特征与Habitat面对的问题有明显语义相关性。Habitat需要跨近40个地理区域服务用户，需要管理巨量读写请求，也需要在多租户场景下保护下游资源。Cosmos DB的文档说明了这类系统通常如何表达容量、可用性和成本，但不证明OpenAI具体用了哪些配置。

因此，本稿把Microsoft Learn列为背景来源，而不是当天事实来源。当天事实只来自OpenAI正文和RSS日期锚点。这个区分很重要：背景资料可以帮助解释机制，但不能替OpenAI没有公开的容量边界背书。

对开发者和企业买方的含义

对开发者来说，Habitat复盘提醒了一件现实的事：AI应用的瓶颈常常不在模型调用本身。一个agent要读设置、拉上下文、保存会话、检查权限、写回状态，背后都是在线存储请求。模型更会写代码之后，这些请求的数量和复杂度不会减少，反而会因为自动化任务变多而上升。

对企业买方来说，这篇文章把采购问题从「哪个模型强」推进到「平台底座是否可审计」。企业在评估AI平台时，需要问数据驻留、访问控制、容量弹性、审计日志、故障隔离和多区域策略。OpenAI这次没有把这些全部讲完，但Habitat的存在本身说明这些问题已经是核心竞争变量。

对模型公司来说，Habitat是一个公开信号：谁能把底层数据访问平台化，谁就能更快把模型能力分发到多个产品。ChatGPT、API、Codex这些产品如果各自维护数据访问逻辑，扩展速度会被协作成本限制；统一平台会把增长压力集中到一个可治理层。

对云服务和数据库厂商来说，这也是AI工作负载进入常规数据库叙事的一次案例。过去AI基础设施讨论更集中在GPU、推理、缓存和向量检索；Habitat说明在线事务型数据、权限状态和多区域读写同样会被十亿用户级AI产品推到极限。

接下来看哪些验证点

系列第二篇是最直接的验证点。OpenAI已经预告会继续说明多租户可靠性、读性能优化和Azure Cosmos DB合作扩容。下一篇如果给出SLO、故障隔离、热点租户处理和读路径优化细节，这条线索的工程价值会明显上升。

迁移完成度也值得单独看。Rust服务当前已处理95%生产请求，但剩余5%没有说明。需要观察OpenAI是否公开Python服务完全退役时间，或解释哪些路径因为兼容性、依赖或风险控制仍留在旧实现上。

Codex参与软件工程的可审计性，是这篇复盘的另一条暗线。OpenAI已经把「2名工程师、Codex和GPT-5.5」写成重写过程的一部分。下一步更该看测试生成、代码审查、迁移计划、回滚演练和事故复盘是否也能被AI工具稳定辅助。

企业平台评估口径会决定这条线索的外溢价值。若OpenAI后续把Habitat的多租户隔离、数据访问审计、区域故障边界和容量治理讲清楚，企业买方会获得比模型benchmark更接近生产风险的材料。若这些细节继续缺席，Habitat更多仍是一篇高质量但单源的官方工程叙事。

核查备注

• OpenAI正文是主事实来源。它给出的主吞吐是more than 70 million requests every second，不是RSS摘要里的22M requests per second。
• RSS只用于确认OpenAI News在9月11日发布该条目。它的description没有被用于本文主结论。
• Rust迁移口径写为「已处理95%生产请求」。本文没有写成完全替换，也没有写成未来计划。
• 6x CPU和15x memory均以Python版本为基准。本文没有把它们写成绝对性能等级。
• Cosmos DB资料仅用于背景解释。本文没有用Microsoft文档替OpenAI未披露的合作容量背书。