2人用AI把Python重写成Rust，CPU效率翻6倍

两名工程师，一个季度，把支撑ChatGPT的核心存储平台从Python重写成Rust。重写后的系统CPU效率是原来的6倍，内存效率是原来的15倍，平均延迟和尾延迟都明显下降。

这不是一次普通的语言迁移。它背后藏着一个更值得琢磨的问题：技术债到底该什么时候还？OpenAI给出的答案有点反直觉——先欠着，等AI长到足够强，再让AI来还。

Habitat是什么，为什么它这么重要

你登录ChatGPT、读取Codex设置、创建一次新对话，这些动作背后都要进行大量数据查询。任何一次请求变慢，产品就会显得迟钝；底层存储一旦失败，产品可能直接不可用。

Habitat就是OpenAI几乎所有产品背后的在线存储平台。它目前每秒处理超过7000万次请求，为每周超过10亿用户提供服务，覆盖接近40个地理区域，承载超过500PB的数据。

OpenAI表示，过去3年其业务规模连续每年增长超过10倍。通常基础设施工程师会按照10倍容量设计系统，希望撑上几年再准备下一次扩容，但OpenAI几乎每年都是这样的增长幅度。

它最初只是一个小型Python库

Habitat最早在2023年的DevDay大会上发布，当时只是一个与ChatGPT主服务器交互的小型Python库，底层的一小部分操作映射到Azure Cosmos DB。

它的设计目标很简单：让产品工程师不必为了存取数据而学习一整套数据库运维知识。Schema查询、数据路由、权限验证、加密、序列化、请求整形、连接池等工作全部由Habitat处理。调用方甚至不需要关心数据究竟来自Azure Cosmos DB、缓存还是其他存储系统。

这个Python库表现不错。尽管OpenAI并没有集中推动大家放弃自助式Postgres和Azure Cosmos DB，Habitat还是在公司产品工程师群体中迅速普及开来。

一次回滚引发的架构反思

随着内部产品越来越多、Habitat承担的逻辑越来越复杂，把所有逻辑做成客户端库变得难以维护。一个协议或者路由逻辑发生变化，就必须协调几十个服务分别升级客户端。

有一次，为了降低单一区域故障对关键数据的影响，团队准备把部分数据迁移到多个区域分布的Azure Cosmos DB账户中。为此，他们首先要修改客户端路由逻辑，并通过功能开关暂时关闭，再协调几十个服务升级客户端，整个过程花了几天。

后来团队觉得还不够保险，又决定增加影子流量，验证新的分片逻辑是否正确，又花了几天部署。期间发现Bug，再发布一个修复版本，又是几天。

而在所有东西终于准备好、即将打开功能开关时，一个无关团队因为一些原因回滚了自己的服务，结果连Habitat客户端也一起退回到了存在Bug的旧版本，最终反而触发了团队此前费尽力气想避免的故障。

这让OpenAI意识到，真正的问题已经不是某一次Bug事件，而是架构本身。

从客户端库到独立服务

于是，Habitat从一个嵌入几十个服务里的Python客户端库，被抽出来做成独立服务。这样Habitat逐渐成为OpenAI产品访问在线存储能力的统一平台，路由、部署、监控和基础设施升级都可以在中央完成，而不需要每次修改都推动几十支团队同时升级。

集中化还有一个更重要的收益：Habitat变成了OpenAI数据访问的统一“咽喉”。访问控制策略、审计日志，以及对Azure Cosmos DB等底层存储资源的权限，都可以集中执行。OpenAI特别提到，这一层同时承担保护用户数据、防止外部人员、内部人员以及Agent未经授权访问数据的重要职责。

问题在于，把原来的本地Python库变成一个真正承载海量流量的网络服务后，Python的成本会被迅速放大。

明知撑不住，为什么还选Python

OpenAI从一开始就知道这一点。使用Python来运行高吞吐量服务会增加网络延迟，并带来较高的CPU和内存扩展成本。团队甚至明确判断，如果Habitat继续增长100倍，Python的效率问题一定无法接受，“最终重写几乎是必然的”。

OpenAI把这个决定称为“战略性引入技术债”。当时真正紧迫的问题不是降低CPU成本，而是解除产品团队的阻塞、让平台稳定下来，并尽快把Habitat的核心API和基础设施形态确定下来。

使用Python意味着团队能够继续高速迭代，用一套已经熟悉的技术栈先解决这些问题，而不是在业务高速增长期间，同时启动一次庞大的语言迁移。

这笔技术债从一开始就带着一个深思熟虑后的赌注。OpenAI团队判断，自家的编程模型正在快速进步。如果把迁移推迟一段时间，那么等到Python真的不得不被替换时，Codex和GPT可能已经能显著降低整个迁移项目的难度。

“这个赌注最终被证明是正确的。”OpenAI团队说道。

等Codex长大之前，先把Python榨干

不过，在等Codex成长起来之前，OpenAI并没有简单放任Python服务低效运行。相反，接下来的一年里，他们几乎把Python这套架构能榨出来的性能榨到了极限。

Habitat面临的真正困难之一，是尾延迟。一个普通的OpenAI用户请求背后可能触发数百次数据库访问。即使绝大多数请求都很快，只要其中有一个异常缓慢，最终用户感受到的就是那一次最慢的请求。

Python的异步I/O框架asyncio可以让大量I/O请求并发执行，但无法绕过全局解释器锁（GIL）获得真正的CPU并行。而Habitat并不只是一个简单的数据转发代理，它还要处理路由、压缩、加密、校验、下游健康检查、请求影子流量和对冲请求等大量CPU任务和后台任务。

OpenAI发现，在高负载下，真正拖慢请求的有时甚至不是数据库。Azure Cosmos DB可能早已把结果返回，负责这个请求的Python协程却因为CPU正忙，没有及时被事件循环重新调度，于是只能在队列里等待。

在普通监控里，CPU、内存、网络、磁盘利用率可能看起来都正常，但用户已经开始感受到延迟。因此，OpenAI给Python服务增加了一套专门的asyncio事件循环监控：周期性调度后台任务，比较它“应该执行的时间”和“真正得到执行的时间”，以此实时测量事件循环本身的调度延迟。

结果显示，当CPU负载较高、后台任务较多时，即使每个Python进程只有相对有限的并发请求，也可能产生数百毫秒的调度抖动，在极端情况下甚至达到数秒。

最终，OpenAI采取了一种简单甚至有些暴力的方法：严格限制每个Python进程同时处理的请求数量。

2个人，一个季度，95%流量已经切换

今年第二季度，仅2名工程师借助Codex和GPT-5.5，就把整个Habitat服务从Python重写成了Rust。目前，Rust版本已经承担95%的生产请求，OpenAI计划在未来几周彻底下线Python版本。

新系统的CPU效率达到Python版本的6倍、内存效率达15倍，同时平均延迟和尾延迟也明显下降。

这可能是目前“大模型改变软件工程成本结构”最具体的案例之一：AI正在改变一个很传统的问题——什么时候应该偿还技术债。

OpenAI的做法给出了一个不那么标准的答案：如果重写的成本会随着模型能力提升而下降，那么推迟重写本身就是一种理性选择。前提是，你得先确认自己等得起，并且在等待期间把旧系统压榨到极限。