谈到AI基础设施，大家第一反应通常是GPU。但当一个产品服务超过10亿周用户，登录、会话、权限、配置和历史记录中的任何一次普通查询变慢，用户感受到的仍然是"AI卡了"。OpenAI最新披露的Habitat提醒我们：模型决定能力上限，数据层决定产品能否每天稳定出现。
发生了什么
OpenAI在9月11日发布Habitat工程文章，称该在线存储平台目前处理每秒7000万次以上请求、服务500PB以上数据，覆盖近40个地理区域，支撑的产品每周用户超过10亿。
两年前，Habitat还是连接单一数据库的Python客户端库。随着产品和区域增长，它逐渐变成统一服务，在客户端与多种存储资源之间处理缓存、访问控制、数据驻留、加密、租户隔离、限流、路由和模式查询。
官方还披露，Python版本高峰时曾支撑每秒2000万次以上请求。2026年第二季度，两名工程师借助Codex和GPT-5.5将服务重写为Rust；新版本目前承载95%的生产请求，在这一特定系统中，CPU效率提升6倍、内存效率提升15倍，并降低了平均和尾部延迟。
为什么"做得少"反而重要
在线存储平台位于大量请求的共同路径上。功能越多，故障半径越大；任何额外计算、网络跳转或错误配置，都可能被数千万QPS放大。因此它的任务不是理解用户问题，而是以可预测方式把请求送到正确数据源，并保护下游不被突发流量压垮。
这类系统最难的往往是尾部延迟。平均10毫秒听起来很好，但一次用户操作若并行触发几十次读取，只要其中一个请求落入最慢的1%，整个页面就可能等待。连接池失衡、事件循环延迟、配置读取和下游洪峰，都会成为看似偶发的卡顿。
Habitat从客户端库变成独立服务，也体现了架构权衡。客户端库少一次网络跳转、起步简单，但每个产品都要升级版本，路由和保护策略容易分散。独立服务增加了一跳，却能集中发布规则、观察全局流量并统一保护存储资源。规模小时，集中层可能显得多余；当产品、区域和数据库不断增加时，它会成为控制复杂度的边界。这里不存在永远正确的架构，只有与组织规模相匹配的架构。
Rust数字应该怎样理解
"6倍CPU、15倍内存效率"很吸引人，但不能推导出"所有Python服务改Rust都能提升15倍"。Habitat的请求规模、并发模型、对象分配和网络路径十分特殊。收益既来自语言，也可能来自重写过程中删除历史包袱、重新设计数据结构和优化运行方式。
更值得学习的是迁移时机。团队没有在第一天追求完美语言，而是让Python系统先承担增长，集中解决更紧迫的问题；当服务成为核心消耗者、架构趋于成熟后，再重写高收益部分。过早重写会把时间花在未知需求上，过晚重写则会持续支付资源与可靠性成本。
对普通开发团队的启发
小团队不需要复制500PB架构，但可以复制决策顺序。先测量请求路径，再找共同瓶颈；先保护数据库，再讨论语言；先看P95和P99延迟，再庆祝平均值；先建立限流和降级，再追求无限扩容。
还要警惕缓存带来的"另一种正确性"。缓存提高速度，却可能让权限变更、账号状态或配置更新延迟生效。对推荐列表，几秒旧数据通常可以接受；对权限撤销和支付状态，同样的延迟可能构成事故。设计缓存前应先为数据分类：哪些允许短暂过期，哪些必须强一致，哪些在依赖失败时宁可拒绝也不能返回旧值。
我的判断是，AI应用未来会越来越像数据系统。提示词只是入口，真正的产品价值来自用户状态、企业知识、权限、审计和长期任务记录。谁能让这些数据既快又可信，谁才有资格让Agent持续替用户工作。
可以立即执行的检查
- 画出一次用户请求经过的全部数据服务。
- 分别记录平均、P95和P99延迟。
- 检查连接池是否会在流量突增时压垮数据库。
- 为非关键读取设置缓存、超时和降级结果。
- 在考虑重写前，用真实负载确认CPU、内存还是网络才是瓶颈。
如果只能先优化一个环节，你会选择更快的模型还是更可靠的数据层？
关注「蜗牛聊AI」，一起看懂技术变化背后的真正机会。
本文首发于 java4u.cn，转载请注明出处。