OpenAI 自己重写了 Git 后端：推送延迟降近 5 倍，每天要扛近 1PB 数据

OpenAI 在工程博客里披露了一件不太像”模型公司”会干的事：他们从零写了一个 Git 后端，取名 Pando，现在支撑着整个 OpenAI monorepo 的日常开发。工程师和 Codex agent 用的还是原来的 Git 命令，工作流没变。

为什么 Git 突然不够用了

过去一年，OpenAI 内部仓库的规模和对它的压力涨得很快。Codex 让一个工程师可以同时推进多个改动，每个改动都在等 CI；一次 push 又会触发好几个任务去拉同一个 commit。写和读的压力叠加，问题在去年年底集中爆发：fetch、push 变慢，merge 开始失败，可靠性一度掉到 90% 以下。

他们先要回答一个问题：这是 Git 本身的极限，还是自己服务仓库的方式到了极限？结论是后者——Git 本身还能用，但后端得重做。

Pando 的两个设计取舍

扩容源代码管理只有两个维度：很多人在往不同分支写，很多人同时在读同一段历史。Pando 分别针对这两点做了选择。

第一，按分支独立协调更新。不相关分支的写入可以并行，读某个分支的客户端只拿这个 revision 需要的历史。代价是：同时看多个分支的读者，可能看到它们停在不同时间点。

第二，跨请求复用 packfile。传统做法是给每个客户端单独打一个包，Pando 让多个客户端共用同一份压缩数据，服务器算一次就能服务很多人。客户端可能多下载一些自己已经有的对象，但换来了服务端计算量的大幅下降。

效果和代价

生产环境里，Pando 把 push 延迟中位数压低了近 5 倍，现在每天要交付接近 1PB 的 Git 数据。他们没有另造一套版本控制，而是保留了 Git 协议和客户端兼容性，改的是后端。OpenAI 还把对 Git 客户端的改进放进了自己的 fork，计划回馈上游。

核心看点

• Pando 已承载 OpenAI 全部 monorepo 开发，工程师与 agent 无感知迁移
• push 延迟中位数降低近 5 倍，日交付近 1PB Git 数据
• 按分支并行写 + packfile 跨客户端复用，是这次扩容的关键
• 保留 Git 兼容，改进有机会回馈开源社区

为什么值得看

AI 编程工具把开发节奏抬高了一个量级，最先撑不住的往往不是模型，而是代码托管、CI 这类”老地基”。OpenAI 的选择也给出了一个方向：与其让所有人换工具，不如把后端重写一遍、把兼容性留住。对正在被 agent 洪流冲击的工程团队来说，这比又一个 benchmark 数字更有参考价值。