OpenAI 如何把 ChatGPT 的存储扩到十亿级用户：Habitat 迁移 Rust 的工程启示

OpenAI 于 2026 年 9 月 11 日公开了 Habitat 在线存储平台的第一篇工程复盘。文章给出的核心答案是：当产品、数据和请求量快速增长时，扩容不只是增加机器，还要把缓存、权限、数据驻留、加密、租户隔离、限流和数据库层统一成可演进的平台。

官方披露了什么

• Habitat 为 ChatGPT、API、Codex 和内部服务提供在线存储能力；OpenAI 称该平台目前服务超过 500 PB 数据，并处理每秒超过 7000 万次请求。
• Habitat 集成缓存、ACL 权限、数据驻留、加密、多租户隔离、限流和路由等能力，底层包括 Azure Cosmos DB、Nanobase、Valkey、Blob Storage、CDC 服务、Databricks、Rockset 和 Kafka 等组件。
• OpenAI 称，Habitat 的 Python 服务峰值曾处理每秒超过 2000 万次请求；到 2026 年第二季度，团队用 2 名工程师、Codex 和 GPT-5.5 重写了整个服务的 Rust 版本。
• 官方数据显示，新 Rust 服务目前处理 95% 的生产请求，相比 Python 版本 CPU 效率提升 6 倍、内存效率提升 15 倍，并改善平均和尾延迟；Python 版本计划在后续几周逐步停用。
• OpenAI 表示将继续发布第二篇复盘，讨论存储层，以及 Habitat 如何服务超过 500 PB 和每秒超过 7000 万次请求。

这不是“Rust 自动让系统快六倍

这些数字是 OpenAI 对自身生产系统的披露，不是 WayToClawEarn 的实测，也没有给出完整的硬件、编译器、请求分布、负载模型和基线配置。因此，不能把 6 倍 CPU 效率或 15 倍内存效率直接外推到普通 SaaS 项目。

更值得借鉴的是架构顺序：先把平台边界、数据治理和资源保护机制做成共享层，再决定是否迁移语言。若一个团队还没有明确的服务边界、指标和回滚方案，先改写成 Rust 可能只是把复杂度搬到另一种语言。

小团队可以复用的四步检查

1. 先测清请求峰值、尾延迟、内存水位、连接池、缓存命中和下游错误，而不是只看平均响应时间。
2. 把权限、数据驻留、加密、租户隔离和限流当作平台能力，不要散落在每个业务服务里。
3. 迁移时保留 Python 与新实现的对照流量，记录输入、版本、硬件、请求类型、失败率和回滚条件。
4. 用固定负载比较 CPU 时间、内存、平均延迟、P95/P99、下游压力和运维成本；只有指标和失败边界同时改善，才值得继续扩大迁移比例。

对 AI 应用创业者的实际意义

当 Agent、语音和多模态功能让请求量快速增长时，最先暴露的未必是模型问题，而可能是存储、权限、队列和数据隔离问题。Habitat 的公开复盘提醒创业团队：可变现的 AI 功能必须和可观测、可恢复、可治理的基础设施一起设计，否则一次增长高峰就可能把单位成本和稳定性同时推向危险区。

证据边界

500 PB、7000 万请求/秒、95% 生产请求、6 倍 CPU 效率和 15 倍内存效率均来自 OpenAI 官方工程文章；Toolify 只对该文章标题和发布进行二次聚合，未独立验证这些指标。本文将它们标为厂商披露，没有转化成普遍性能承诺。

来源

• OpenAI 工程复盘：https://openai.com/index/scaling-storage-one-billion-users-part-one/
• Toolify 二次聚合：https://www.toolify.ai/daily-ai-news