OpenAI故意欠技术债，等Codex来还：仅2名工程师，把核心存储从Python重写成Rust

明知道Python撑不住未来的规模，OpenAI团队仍然选择先把核心在线存储平台Habitat做成Python服务，并主动接受这笔技术债。这是OpenAI的一个赌注：等真正需要还债的时候，Codex和GPT可能已经足够强，能够大幅降低整个系统重写的成本。 一年后，这个赌注兑现了。 今年第二季度，仅2名工程师借助Codex和GPT-5.5，就把整个Habitat服务从Python重写成了Rust。目前，Rust版本已经承担95%的生产请求，OpenAI计划在未来几周彻底下线Python版本。新系统的CPU效率达到Python版本的6倍、内存效率达15倍，同时平均延迟和尾延迟也明显下降。 这可能是目前“大模型改变软件工程成本结构”最具体的案例之一：AI正在改变一个很传统的问题，即什么时候应该偿还技术债。 明知道Python迟早要重写，OpenAI还是决定先欠债 用户登录ChatGPT、读取Codex设置、创建一次新对话，背后需要进行大量数据查询。任何一次请求变慢都会让产品感觉迟钝，而底层存储失败，产品可能直接不可用。 Habitat 是OpenAI几乎所有产品背后的在线存储平台。目前，Habitat每秒处理超过7000万次请求，为每周超过10亿用户提供服务，覆盖接近40个地理区域，承载超过500PB的数据。OpenAI表示，过去3年，其业务规模连续每年增长超过10倍。通常infra工程师会按照10倍容量设计系统，希望撑上几年再准备下一次扩容，但OpenAI几乎每年都是这样的增长幅度。 Habitat 最初的设计却没有这么复杂。 Habitat 最早在2023年的 DevDay 大会上发布，它只是一个与ChatGPT主服务器交互的小型Python库，底层的一小部分操作映射到Azure Cosmos DB。它的设计目标很简单，就是让产品工程师不为了存取数据而学习一整套数据库运维知识。Schema查询、数据路由、权限验证、加密、序列化、请求整形、连接池等工作全部由Habitat处理。调用方甚至不需要关心数据究竟来自Azure Cosmos DB、缓存还是其他存储系统。 这个 Python 库表现不错。尽管 OpenAI 并没有集中推动大家放弃自助式 Postgres 和 Azure Cosmos DB，但 Habitat 还是在公司产品工程师群体中迅速普及开来。 问题在2025年中开始出现。 随着OpenAI内部产品越来越多、Habitat承担的逻辑越来越复杂，把所有逻辑做成客户端库变得难以维护。一个协议或者路由逻辑发生变化，就必须协调几十个服务分别升级客户端。 比如有一次，为了降低单一区域故障对关键数据的影响，OpenAI团队准备把部分数据迁移到多个区域分布的Azure Cosmos DB账户中。为此，他们首先要修改客户端路由逻辑，并通过功能开关暂时关闭，再协调几十个服务升级客户端。整个过程花了几天的时间。后来，团队觉得还不够保险，又决定增加影子流量，验证新的分片逻辑是否正确，又花了几天部署。期间发现Bug，再发布一个修复版本，又是几天。 而在所有东西终于准备好、即将打开功能开关时，一个其他的无关团队因为一些原因回滚了自己的服务，结果连Habitat客户端也一起退回到了存在Bug的旧版本，最终反而触发了团队此前费尽力气想避免的故障。 这让OpenAI意识到，真正的问题已经不是某一次Bug事件，而是架构本身。 于是，Habitat从一个嵌入几十个服务里的Python客户端库，被抽出来做成独立服务，这样Habitat逐渐成为OpenAI产品访问在线存储能力的统一平台，路由、部署、监控和基础设施升级都可以在中央完成，而不需要每次修改都推动几十支团队同时升级。 集中化还有一个更重要的收益：Habitat变成了OpenAI数据访问的统一“咽喉”。访问控制策略、审计日志，以及对Azure Cosmos DB等底层存储资源的权限，都可以集中执行。OpenAI特别提到，这一层同时承担保护用户数据、防止外部人员、内部人员以及Agent未经授权访问数据的重要职责。 问题在于，把原来的本地Python库变成一个真正承载海量流量的网络服务后，Python的成本会被迅速放大。 OpenAI从一开始就知道这一点。使用 Python 来运行高吞吐量服务会增加网络延迟，并带来了较高的CPU和内存扩展成本。团队甚至明确判断，如果Habitat继续增长100倍，Python的效率问题一定无法接受，“最终重写几乎是必然的”。 但他们仍然决定暂时不迁移。 OpenAI把这个决定称为“战略性引入技术债”。当时，真正紧迫的问题不是降低CPU成本，而是解除产品团队的阻塞、让平台稳定下来，并尽快把Habitat的核心API和基础设施形态确定下来。使用Python意味着团队能够继续高速迭代，用一套已经熟悉的技术栈先解决这些问题，而不是在业务高速增长期间，同时启动一次庞大的语言迁移。 这笔技术债从一开始就带着一个深思熟虑后的赌注。OpenAI团队判断，自家的编程模型正在快速进步。如果把迁移推迟一段时间，那么等到Python真的不得不被替换时，Codex和GPT可能已经能显著降低整个迁移项目的难度。 “这个赌注最终被证明是正确的。”OpenAI团队说道。 迁移之前，如何把旧架构性能榨到极致 不过，在等Codex成长起来之前，OpenAI并没有简单放任Python服务低效运行。相反，接下来的一年里，他们几乎把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进程同时处理的请求数量，然后大量横向扩展Python worker。这让Python能够继续支撑增长，但也埋下了另一些规模化问题。 每分钟同一Pod里的worker同时“卡住” Habitat上线早