两个工程师，没有新增硬件，没有大规模招聘，甚至没有重写底层存储。只用了一个编程语言和一个AI辅助工具，就把全球最大AI公司最核心的存储基础设施效率提升了六到十五倍。
这不是概念验证。这是正在发生的生产环境重构。
2026年9月11日，OpenAI工程团队发布了一篇题为“Rapidly scaling online storage to serve over 1 billion ChatGPT users”的技术博客，详细披露了其内部在线存储平台Habitat从Python到Rust的全量迁移细节。这台每秒处理超过7000万次请求、承载超过500PB数据、服务每周超10亿用户的“隐形引擎”，在2026年第二季度被彻底更换了大脑。
一部Python撑起的“不可能”增长史
Habitat的故事起点并不宏大。2024年年中，它还只是ChatGPT主服务器上一个轻量的Python客户端库，连接一个Azure Cosmos DB数据库，提供简单的读写接口。产品工程师不需要关心数据从哪来、存在哪、怎么路由、如何授权。Habitat帮他们处理这一切。
这个库迅速在OpenAI内部被采用。没有强制推行的中央指令，产品团队主动放弃自建的PostgreSQL和独立Cosmos DB实例，涌入Habitat的生态。原因很简单：当ChatGPT以周为单位迭代新功能时，没人愿意花时间管理数据库。
到2025年年中，Habitat已经不再是“一个库”能承载的了。它需要处理的逻辑越来越复杂——路由、分片、缓存、压缩、加密、多区域容灾——而所有这些逻辑都嵌在数十个独立服务的客户端代码中。每次需要修改，工程团队都要协调数十个服务的部署顺序，打上feature flag，灰度上线，再逐步启用。一次简单的路由变更需要“数天”才能完成。一次因某团队意外回滚旧版本客户端库导致的故障，直接抹平了团队数周的努力。
OpenAI的决定是把Habitat抽离为独立服务。这是分布式系统史上的经典剧本：当你的基础设施逻辑嵌入在每个服务的sidecar里，任何变更都变成了一场交响乐团的同步演出，而总有一个乐手会走调。
Habitat服务化之后，团队获得了单点控制权。部署、可观测性、安全策略、访问控制——所有东西集中管理。这也是Habitat能承载后续爆炸式增长的架构前提。
Python在2000万QPS撞上的天花板
但一个尖锐的矛盾很快浮出水面：Habitat是用Python写的。
Python在OpenAI的栈中并非异类。这家以AI著称的公司有大量的Python基础设施，模型训练用Python，推理框架也用Python。但“存储平台层用Python”是一个更激进的决策。在高并发OLTP系统中，Python几乎是“不应该出现”的选项。
OpenAI工程团队在博客中坦诚地列举了他们遇到的三个典型问题。
第一个是asyncio调度延迟。Python的异步模型本质上是协作式的。当某个CPU密集的后台任务开始执行——比如解析JSON格式的特性Flag配置——它就会阻塞事件循环。如果这个操作在8个进程的每个worker中同时触发，整个pod的所有worker都会同时停滞。尾部延迟（tail latency）从毫秒级飙升到秒级。
第二个是连接池的metastable failure。在Python的异步框架中，连接池管理是出了名的脆弱。当某个瞬间流量脉冲导致少量请求超时，这些超时会迅速传播到整个连接池。大量请求排队等待已有连接释放，新请求被拒绝，连接池状态进入一种“看起来正常、实际上正在死去”的亚稳态。
第三个是Envoy和Istio带来的thundering herd（惊群效应）。Habitat使用Envoy作为服务网格代理，而Envoy与Python异步层的交互在极限负载下会产生指数级的震荡。一个节点延迟上升，流量被重试到其他节点，其他节点随即过载，引发更大规模的级联失败。
这些不是Python本身的bug。它们是Python擅长的事情（快速迭代、丰富生态、高开发效率）与它不擅长的事情（超大规模并发、精确的资源控制、可预测的尾部延迟）之间的固有冲突。Habitat在Python下峰值达到了每秒2000万次请求。对于一个Python服务而言，这已经是一个令人瞠目的数字。但对于即将承载每周10亿用户的OpenAI来说，这远远不够。
2名工程师加AI：一场轻量级的“换心手术”
2026年第一季度，Habitat已经成为OpenAI内部按核心数计算的第二大服务、Envoy流量足迹的第四大服务。增长曲线没有放缓的迹象。团队知道：必须从Python迁移出去。
但“迁移”和“用Rust重写”之间存在巨大的差异。一个运行中的、承载事实现有生产流量的分布式存储平台，从头重写意味着数月的开发、数月的灰度验证、至少一个季度的新旧系统并行，以及一个足够庞大的工程团队。
OpenAI的方案刷新了行业的认知。2名工程师，配合Codex和GPT-5.5，在2026年第二季度完成了整个服务的Rust重写。
这不是“借助AI写一些辅助脚本”，而是从代码生成到调试到优化，全程用AI辅助编程工具完成的系统性工程。Codex和GPT-5.5组成的“虚拟工程师”，大幅压缩了Rust学习的曲线和代码生成的周期。
迁移结果令人震撼：
- CPU效率提升6倍：同等吞吐量下，Rust服务的CPU消耗仅为Python版本的六分之一
- 内存效率提升15倍：Python的垃圾回收、对象开销和动态类型在内存上的浪费被Rust的零成本抽象彻底消除
- 平均和尾部延迟显著降低：Rust的所有权模型和零开销异步运行时（tokio）提供了可预测的延迟特性，这正是OLTP系统最珍视的品质
目前，新的Rust服务已经承载了Habitat 95%的生产请求流量。Python版本将在“数周内”彻底弃用。
这个数据背后有一个更值得追问的对比：Python版本达到过2000万QPS的峰值，而Rust版本需要承载的是超过7000万QPS，增长了3.5倍。如果Habitat没有迁移，要支撑当前的流量规模，OpenAI需要将Python服务的硬件资源扩充到原来的3倍以上。按6倍的CPU效率差计算，实际节省可能远不止于此。
为什么是Rust，不是Go，不是C++？
在基础设施重写这件事上，Rust并不是唯一的选择。Go在云原生生态中的地位更为稳固——Kubernetes、Docker、Prometheus都是用Go写的。C++在极致性能场景下仍有不可替代的优势。
但OpenAI选择Rust的逻辑链条并不复杂。
首先，Habitat的核心诉求是可预测的尾部延迟。Go的垃圾回收机制虽然在最新版本中延迟已大幅降低，但GC停顿仍是不可控因素。在每秒7000万次请求的规模下，哪怕每次GC多停留1毫秒，累积效应也会制造出肉眼可见的延迟抖动。Rust的所有权模型在编译期解决了内存管理问题，运行时不依赖GC。这是确定性延迟的根源。
其次，内存效率。OpenAI的博客中明确提到，Habitat是按核心数计算的第二大服务。这意味着它在计算资源上的消耗是巨大的。15倍的内存效率提升，在Azure上对应的直接成本节省和资源释放，足以让任何CFO认真考虑一个全面的Rust化计划。
第三，AI辅助编程降低了Rust的采用门槛。Rust以陡峭的学习曲线闻名——借用检查器（borrow checker）、生命周期标注、所有权转移——这些概念对习惯Python动态类型的工程师来说是一个巨大的心智负担。但Codex和GPT-5.5的存在改变了这个等式。“2名工程师加AI”能完成整场重写，说明AI辅助工具已经能够有效处理Rust中最棘手的部分：内存安全和并发安全的编译期验证。这或许才是整件事中最具深远意义的信号。
可能被忽略的暗线：Python在OpenAI的位置
Habitat的迁移在OpenAI内部不是一个孤立事件。它标志着Python在AI基础设施中的角色正在被重新审视。
长期以来，AI行业有一个心照不宣的分工：模型训练用Python，工程部署用其他语言。PyTorch、TensorFlow、JAX、HuggingFace、LangChain——AI的生态几乎全部建立在Python之上。但在生产级基础设施层面，Python的统治力远没有数据科学领域那么牢固。
OpenAI的Habitat迁移说明了一个趋势：当AI公司从“实验室模式”进入“平台模式”，基础设施层的语言选择会回归到工程效率。而Python在OLTP场景中的弱点会变得越来越不可容忍。这并不意味着Python会从AI行业消失。恰恰相反，Python在数据科学、模型训练、快速原型领域仍然是不可替代的。但“Python做什么，不做什么”这条边界线，正在被重新绘制。
一个佐证是：OpenAI在2025年年中就意识到了Python的性能瓶颈，但他们刻意推迟了Rust重写。原因不是技术上的不确信，而是“有更紧迫的事情要处理”。直到2026年，平台成熟度、增长曲线和资源效率三者同时触发了“必须做”的条件。这种务实的分阶段策略——先用Python快速上线、验证需求、承受性能损失、在恰当的时机用更高效的语言接管——本身就是一个值得借鉴的平台工程方法论。
Habitat的下一步与行业启示
OpenAI已经预告了博客系列的Part II，将深入讨论多租户可靠性、读性能优化的分层策略，以及Azure Cosmos DB层面的深度协同优化。
但Part I已经释放了足够多的重要信号。
对于AI行业而言，基础设施层的“语言战争”已经结束。Rust正在成为高性能基础设施的事实标准。不仅是在存储层，在推理引擎（如Candle、Burn）、网络层（如Cloudflare的Pingora）、数据库（如Neon的Rust重写）等多个领域，Rust的渗透已经不可逆。
对于工程组织而言，AI辅助编程正在跨越“辅助”的门槛。2名工程师完成一个承载500PB以上数据、7000万QPS的系统重写。这个数字本身就是对“AI编程助手只是玩具”这一论调的最有力反驳。当GPT-5.5和Codex能够处理Rust borrow checker中最复杂的生命周期标注时，语言学习曲线的意义正在被重新定义。
对于决策者而言，“先Python验证，后用Rust重写”正在成为一条标准的产品化路径。Python的低启动成本和Rust的高运行效率被串联成了一条完整的从0到1再到N的工程路线。先用Python跑通，用Rust跑稳定。
最后，有一个数字值得反复回味：Python版本在峰值时服务了2000万QPS。对于一个“不应该被用于高并发”的语言来说，这是一个让人肃然起敬的成绩。但当流量增长到7000万QPS时，Python不再是答案。这不是Python的失败。这是增长对技术栈的终极审判。每个看似足够好的决策，最终都会撞上增长的墙。区别只在于，你是在墙前主动转向，还是等墙来找你。
OpenAI选择了在墙前转向。而它的工具包里有2个工程师、一个AI助手，和一门年轻但正在接管世界的系统语言。
快报