OpenAI自研Pando：Git后端推送延迟降80%

OpenAI 为超大型单体仓库自建了一套 Git 后端 Pando，官方披露其将中位推送延迟压低了近 80%，每天承载近 PB 级别的 Git 数据传输。这条消息的价值不只是一次性能优化，更暴露了一个常被忽视的事实：当代码库规模跨过某个阈值，标准 Git 的架构假设就开始失效。

单体仓库撞上 Git 的天花板

OpenAI 的代码集中在一个巨大的 monorepo 中，这种组织方式换来的是跨项目依赖与统一构建的便利，代价则落在版本控制层。传统 Git 服务端在处理海量分支与频繁拉取时，大量工作被重复计算——每次 fetch 往往需要重新生成或重新打包对象，分支之间的操作也难以彼此隔离。

Pando 的出发点很明确：不再把 Git 当作一个必须整体适配的黑盒，而是重写后端，让存储与传输逻辑贴合单体仓库的实际访问模式。这与业界其他超大规模代码托管平台的思路一致，但 OpenAI 选择完全自研而非改造现成方案。

什么是 packfile：Git 在传输和存储对象时，会把大量松散对象（loose objects）打包成一个或多个 packfile，并为其中的对象建立索引（.idx 文件）。打包过程涉及对象遍历、增量压缩（delta compression）和重新组织，属于计算密集型操作。仓库越大、对象越多，单次重新打包的成本就越高，这也是大仓库 fetch 慢的主要来源之一。复用已有 packfile 的本质，是跳过重复的打包计算，直接把已验证的打包结果交给客户端。

什么是 fetch：fetch 是 Git 从远端拉取对象与引用更新的操作，与 pull 的区别在于它不自动合并到本地分支。在单体仓库中，fetch 频率高、涉及对象多，服务端每次都要决定发送哪些对象、如何打包，因此成为延迟优化的核心战场。

三个关键设计选择

官方对 Pando 的描述集中在三项能力上，每一项都指向标准 Git 在超大仓库中的具体痛点。

分支独立处理

Pando 让各分支的处理相互独立。在传统实现中，分支数量膨胀后，服务端的引用管理与对象遍历成本会非线性上升；独立处理意味着单个分支的读写不再被其他分支的规模拖累，对动辄数以万计活跃分支的单体仓库而言，这是控制延迟方差的关键。

引用与对象遍历的成本：Git 的引用（refs）本质是指向提交对象的指针，分支即一类引用。服务端在处理请求时需要解析引用、遍历提交历史、判断客户端已有哪些对象（通过 negotiation 协商）。当活跃分支数量达到数万级别，引用管理和可达性分析的开销会随分支数增长而放大，且不同分支的操作容易相互阻塞。分支独立处理的意义在于把这种全局耦合拆开，使单分支请求的处理路径不再随仓库总分支规模线性恶化。

跨 fetch 复用 packfile

Pando 会在多次 fetch 之间复用已存储的 packfile。Git 协议本就支持打包传输，但标准路径下服务端经常要为每次请求重新组织对象集合。复用已有打包结果，等于把重复的打包开销从热路径上移除，直接降低了大仓库拉取的等待时间。

延迟与吞吐的双重收益

上述设计最终体现为两个指标：中位 push 延迟下降近 80%，以及每日近 PB 的 Git 数据投递量。前者反映开发者日常操作的体感，后者验证了这套后端在高负载下的稳定性——两者同时成立，说明优化不是以牺牲吞吐换来的。

为什么这件事值得关注

OpenAI 并未将 Pando 作为产品发布，它更像一次基础设施层面的自证。但它释放的信号有普遍意义。

其一，超大代码库的版本控制正在从「配置优化」走向「后端重写」。当仓库规模达到一定量级，靠调参和缓存已难以解决问题，重新设计存储与传输路径成为唯一出路。

其二，AI 公司对研发基础设施的投入正在加深。训练与推理之外，代码协作链路的效率同样影响迭代速度，Pando 属于这类隐性但关键的工程投资。

其三，Git 兼容性被保留下来。Pando 作为 Git 兼容后端，意味着现有客户端与工作流无需改动，这种「后端替换、前端无感」的路径，对同样受困于单体仓库的团队具有参考价值。

monorepo 的版本控制权衡：单体仓库把多个项目放进同一代码库，带来原子提交、统一依赖和跨项目重构的便利，但也让版本控制层承压：克隆体积大、分支众多、CI 需要按路径做增量构建。业界应对方式大致分两类——一类是虚拟文件系统（如 VFS for Git、Sapling 的部分思路），按需物化文件；另一类是重写服务端传输与存储，Pando 属于后者。理解这一分野，有助于判断不同方案适用的规模区间。

局限与待观察之处

目前公开信息有限：Pando 是否开源、是否适配非 OpenAI 规模的仓库、近 PB 日流量背后的具体对象分布，均未披露。近 80% 的延迟降幅是在 OpenAI 自身工作负载下测得的中位数，迁移到其他团队能否复现，取决于访问模式是否相似。对多数中小团队而言，标准 Git 仍是更经济的选择；Pando 的意义在于标定了自研后端这条路的可行性边界。