AI 产品扩张到十亿用户，平台先要限制自由度

一个产品从一百万用户走到十亿用户，最先失控的往往不是模型，而是那些“看起来很方便”的基础能力：任意查询、任意数据关系、每个服务各自升级、每个团队自行决定怎么连数据库。

OpenAI 在 2026 年 9 月 11 日公开了在线存储平台 Habitat 的演进过程。这个平台现在每秒处理超过 7,000 万次请求，服务每周超过 10 亿人，覆盖近 40 个地理区域和超过 500 PB 数据。它最初却只是一个连接单个数据库的 Python 客户端库。

这段演进最值得产品团队借鉴的，不是某个数据库或语言选型，而是一个更反直觉的判断：规模越大，平台越不能把所有自由度交给上层；稳定性要靠把危险的选择变得不容易做。

先看 Habitat 解决的不是“存储”，而是产品团队的认知负担#

Habitat 最早服务于 GPTs。产品工程师只需要读写数据，不必自己处理 schema lookup、路由、授权、加密、序列化、请求整形和连接池，也不必知道请求最终落在 Azure Cosmos DB、缓存还是其他存储上。

这是一种很典型的平台产品：它隐藏基础设施的复杂性，但没有把复杂性消灭。复杂性被集中到一个可以统一发布、观测和治理的边界里。

当 Habitat 还只是客户端库时，产品团队可以在共享库里继续加缓存、压缩和加密。但随着服务数量增加，任何协议变化都要协调几十个服务一起升级。OpenAI 记录了一次区域分布迁移：路由逻辑、shadowing、feature flag 和回滚都需要跨团队协调，最后一个服务回滚到旧客户端，反而触发了本来要避免的故障。

把 Habitat 拆成独立服务之后，变化只需要在一个控制点完成。这个控制点还可以集中执行访问控制、审计日志和底层存储权限，减少外部、内部以及 Agent 对数据的越权访问面。

大规模系统最怕的不是平均值，而是尾部和反馈回路#

Habitat 选择继续用 Python 提供服务时，OpenAI 并没有把“能跑起来”当成可接受的性能。一个用户请求可能触发数百次数据库调用，用户感受到的是其中最慢的一次。

文章把几个容易被平均延迟掩盖的问题讲得很具体：

现象	原因	处理方式
p99 请求停顿	asyncio 事件循环被压缩、加密、校验和健康检查等 CPU 工作占用	记录事件循环调度延迟，降低单进程并发，横向增加 worker 数量
每分钟出现集体抖动	每个 Pod 同时解析包含所有生产规则的大型 feature flag 配置	缩小配置、拉长刷新间隔、给后台任务加 jitter
部分进程越忙越接收请求	aiohttp 连接池的 LIFO 复用把新流量继续送给慢进程	改用 FIFO 打破反馈回路，后来交给 Envoy 做服务级连接池与负载感知
下游被连接洪峰压垮	大量 Python 进程让连接数和连接轮换被放大	用 Envoy 做连接汇聚、HTTP/2 多路复用、限流和熔断

这些做法共同指向一个平台指标：不能只看 CPU、内存和平均延迟，还要看调度等待、尾延迟、连接分布和请求在系统中的反馈路径。故障经常不是某个组件“坏了”，而是系统把更多工作继续推给了已经变慢的组件。

“少做一点”反而更容易扩张#

Habitat 没有开放任意 SQL，而是提供一个受限的 NoSQL API：请求应该是简单、可预测、接近固定工作量的操作。复杂查询被放到离线的 Rockset 视图，产品团队需要自己为这部分分析能力负责扩展。

这不是技术能力不足，而是有意限制 API 的表达力。任意 SQL 很容易写出代价昂贵的查询；查询复杂度一旦不可预测，隔离、负载均衡和容量规划都会变难，系统还会出现难以恢复的延迟悬崖。

对 AI 产品来说，这个取舍尤其重要。Agent 会不断组合工具、数据和上下文，如果底层接口允许无限制的 fanout，单个提示就可能放大成一串无法估算的读写操作。一个“能力更强”的 API，可能正是一个更难上线的 API。

平台产品应该把高风险自由度移到显式的异步流程、离线任务或人工审核里，而不是把所有选择都塞进在线热路径。

先用不完美的栈买时间，再在证据足够时换栈#

OpenAI 承认 Python 服务在网络延迟、CPU 和内存成本上并不理想，但当时首要目标是解锁产品团队、建立稳定的核心 API，而不是提前追求资源最优。

这是一笔明确标注过的技术债，而不是“以后再说”。当 Habitat 成为 OpenAI 按核心数计第二大的服务、Python 在峰值承担超过每秒 2,000 万请求后，团队才开始迁移：2026 年第二季度，两名工程师借助 Codex 和 GPT‑5.5 重写了整个服务；新的 Rust 服务已经处理 95% 的生产请求，CPU 效率提升 6 倍，内存效率提升 15 倍，平均和尾延迟也明显降低。

这个结果不能被理解成“Rust 一定比 Python 好”，更不能推成“两个工程师就能重写任何基础设施”。它说明的是：先用可接受的技术债把平台边界和 API 稳定下来，再用真实的瓶颈证据决定是否迁移，往往比一开始就押注最终架构更稳。

给 AI 产品团队的四个落地判断#

1. 把平台能力写成有边界的产品契约#

明确哪些查询是在线热路径允许的，哪些必须进入离线任务；限制单次请求的 fanout、预算、超时和重试；对高成本操作提供可观测的异步接口，而不是隐藏在一个“万能工具”里。

2. 把尾部事件放进验收，而不只看平均体验#

产品指标除了成功率和平均耗时，还应记录 p95/p99、排队等待、下游连接分布、超时后的重试链和熔断次数。用户感觉到的“偶尔卡死”，通常不会出现在平均值里。

3. 把平台控制点当成安全边界#

统一的路由、授权、审计和数据驻留策略，能够让产品团队少复制一套安全逻辑。对 Agent 而言，平台还应保留独立的速率限制、工具权限和可回放日志，避免模型或客户端直接接触底层资源。

4. 给技术债设置“重新评估触发器”#

技术债可以被接受，但必须写下触发条件：核心数、尾延迟、内存成本、部署扇出或变更失败率达到什么阈值时重新评估。没有触发器的“先这样”，最后通常会变成永久架构。

来源与边界#

• 原始来源：OpenAI Engineering，Rapidly scaling online storage to serve over 1 billion ChatGPT users，发布于 2026 年 9 月 11 日；作者为 Jon Lee、Chaomin Yu、Ben Ries。
• 研究对象：OpenAI 的在线存储平台 Habitat。原文描述它从支持 GPTs 的 Python 客户端库，演进为服务 ChatGPT、API、Codex 和内部服务的集中式平台。
• 公开设置与关键数字：Habitat 每秒处理超过 7,000 万次请求，服务每周超过 10 亿人，覆盖近 40 个区域，数据规模超过 500 PB；Python 版本峰值超过每秒 2,000 万请求；Rust 重写由 2 名工程师、Codex 和 GPT‑5.5 完成，已承接 95% 的生产请求，CPU 效率提升 6 倍、内存效率提升 15 倍。
• 原文方法：通过独立服务集中部署、观测、权限和数据访问；监测 asyncio 调度延迟；调整进程并发、feature flag 刷新、连接池复用和 Envoy 连接汇聚；用受限 NoSQL API 让在线请求保持可预测，把复杂查询放到 Rockset 离线视图。
• 原文能说明什么：在 OpenAI 这套产品规模和基础设施约束下，限制在线 API 的自由度、集中控制面、观测尾部行为和分阶段偿还技术债，帮助平台继续扩张。
• 原文不能证明什么：这些数字不是所有公司或所有数据库的通用基准，也不能证明 Rust 迁移必然带来同样的 6 倍 CPU、15 倍内存收益；文章是 OpenAI 单一平台的工程复盘，尚未公开第二部分的存储层细节。
• 本文产品化解读：把在线能力做成可预测的运行契约、把复杂操作移出热路径，并给技术债设置触发器，是面向 AI 产品的架构建议，不是 OpenAI 的通用产品规范。