ChatGPT服务10亿周用户后，最难扩展的可能不是模型
内容提要
OpenAI披露Habitat存储平台，每秒处理超7000万请求、500PB数据，支撑10亿周用户。该平台从Python客户端库演变为统一服务，2026年用Rust重写后CPU效率提升6倍、内存效率提升15倍。文章指出AI产品瓶颈常在数据层，应优先优化P95/P99延迟、限流降级与缓存一致性，而非只关注模型。
延伸解读
数据层：AI产品稳定性的隐形支柱
当产品服务10亿周用户时，登录、会话等普通查询的延迟会被放大为“AI卡了”。Habitat处理每秒7000万请求、500PB数据，说明数据层是产品每天稳定出现的关键。模型决定能力上限，但数据层决定产品能否可靠运行。对开发团队而言，优先优化数据层比单纯追求模型升级更能提升用户体验。
尾部延迟：用户体验的隐形杀手
平均延迟10毫秒看似良好，但一次用户操作可能并行触发几十次读取，只要一个请求落入最慢的1%，整个页面就会等待。连接池失衡、事件循环延迟等都会导致偶发卡顿。因此，关注P95/P99延迟比平均值更重要，这是保障流畅体验的关键。
Rust重写：效率提升背后的条件
Habitat用Rust重写后CPU效率提升6倍、内存效率提升15倍，但这并非通用结论。收益可能来自语言特性，也可能来自删除历史包袱、重新设计数据结构。团队应选择合适时机：让Python先承担增长，待架构成熟后再重写高收益部分，避免过早优化未知需求。
缓存一致性：速度与正确性的权衡
缓存能提高速度，但可能导致权限变更、支付状态等延迟生效。对推荐列表，几秒旧数据可接受；对权限撤销，则可能构成事故。设计缓存前应为数据分类：哪些允许短暂过期，哪些必须强一致，哪些宁可拒绝也不能返回旧值。这是避免“另一种正确性”问题的关键。
Q&A
OpenAI的Habitat存储平台是什么？它支撑了多大规模？
Habitat是OpenAI披露的在线存储平台，目前处理每秒7000万次以上请求，服务500PB以上数据，覆盖近40个地理区域，支撑的产品每周用户超过10亿。
Habitat从Python客户端库演变为独立服务，这种架构变化有什么利弊？
客户端库少一次网络跳转、起步简单，但每个产品都要升级版本，路由和保护策略容易分散。独立服务增加了一跳，却能集中发布规则、观察全局流量并统一保护存储资源。规模小时集中层可能显得多余，当产品、区域和数据库不断增加时，它会成为控制复杂度的边界。
Habitat用Rust重写后性能提升了多少？这些数字能直接套用到其他Python服务吗？
2026年第二季度，两名工程师借助Codex和GPT-5.5将服务重写为Rust，新版本承载95%的生产请求，CPU效率提升6倍、内存效率提升15倍，并降低了平均和尾部延迟。但不能推导出所有Python服务改Rust都能提升15倍，因为Habitat的请求规模、并发模型、对象分配和网络路径十分特殊，收益也可能来自重写过程中删除历史包袱、重新设计数据结构和优化运行方式。
为什么在线存储平台要尽量“做得少”？尾部延迟为什么关键？
在线存储平台位于大量请求的共同路径上，功能越多故障半径越大，任何额外计算、网络跳转或错误配置都可能被数千万QPS放大。它的任务是以可预测方式把请求送到正确数据源，并保护下游不被突发流量压垮。尾部延迟关键是因为一次用户操作若并行触发几十次读取，只要其中一个请求落入最慢的1%，整个页面就可能等待。连接池失衡、事件循环延迟、配置读取和下游洪峰都会成为看似偶发的卡顿。
对于普通开发团队，从Habitat案例中可以学到哪些可执行的优化顺序？
先测量请求路径，再找共同瓶颈；先保护数据库，再讨论语言；先看P95和P99延迟，再庆祝平均值；先建立限流和降级，再追求无限扩容。具体检查包括：画出一次用户请求经过的全部数据服务；分别记录平均、P95和P99延迟；检查连接池是否会在流量突增时压垮数据库；为非关键读取设置缓存、超时和降级结果；在考虑重写前，用真实负载确认CPU、内存还是网络才是瓶颈。
使用缓存时需要注意什么？如何根据数据特性设计缓存策略？
缓存提高速度，却可能让权限变更、账号状态或配置更新延迟生效。对推荐列表，几秒旧数据通常可以接受；对权限撤销和支付状态，同样的延迟可能构成事故。设计缓存前应先为数据分类：哪些允许短暂过期，哪些必须强一致，哪些在依赖失败时宁可拒绝也不能返回旧值。
