OpenAI 推出自研 Git 后端 Pando，推送延迟中位数降低近 80%

OpenAI 推出了 Pando，这是一个新的 Git 后端，目前已用于支撑其 monorepo 中的全部开发工作。OpenAI Pando Git 后端保留了标准的 Git 客户端和协议。工程师和 Codex agent 仍像以前一样执行 git push 和 git fetch。只有服务端变了。OpenAI 团队报告称，推送延迟中位数下降了近 80%。Pando 现在每天要传输近 1 PB 的 Git 数据。

TL;DR

• 规模：每天近 1 PB 的 Git 数据；峰值时 1 小时内超过 57 TB。
• 运行环境：商用硬件；标准云 VM 在 clone 和 fetch 时就能打满 10 Gbps 链路。
• 性能：根据 OpenAI 自己的测试，数千个并发推送者性能不降级。
• 最好的一面：推送延迟中位数下降近 80%（约 5 倍）。
• 最差的一面：未开源；重复推送分支会重发非 trunk 历史（p99 pack 小于 3 MiB）。

什么是 OpenAI Pando？

Pando 是 OpenAI 推出的 Git 兼容服务端后端，可为 monorepo 扩展并发 push 和 fetch。它用 Rust 编写，10 周内进入生产环境。一名工程师设计了核心，多个 Codex agent 团队负责实现。自 2026 年 4 月起，它已承载生产流量。

OpenAI 为什么需要新的 Git 后端？

Codex 让并行工作成倍增加。OpenAI 的提交图表显示，2026 年第三季度落到 master 上的提交数相比 2024 年第一季度增长了 1,378%。其对 2026 年第四季度的估计是增长 2,442%。现在每次 push 都会触发大量 CI fetch。到 2025 年底，fetch 和 push 变慢，merge 失败，可靠性有时跌破 90%。OpenAI 得出结论：瓶颈在于它提供 Git 服务的方式，而不是 Git 本身。

Pando 如何工作？

Pando 放弃了大多数 Git 服务器视为必需的两项假设：

1. 仓库级一致性：传统服务器会在整个仓库范围内对每次 ref 更新排序，因此不相关的 push 也要等待。Pando 改用因果一致性。每个分支各自串行化，客户端只有在推送同一个 ref 时才会冲突。代价是：读取多个分支的读者可能看到它们处于不同时间点。
2. 每个客户端一个唯一 packfile：标准服务器会为每次 fetch 构建新的 pack。Pando 将每次推送的 pack 存储为不可变 blob。一个“ref 版本”写入可扩展的元数据存储。一次 push 需要 O(1) 次元数据读写。一次 fetch 需要 O(log Δ) 次读取，其中 Δ 是要补齐的 ref 版本差距。

如何让 push 保持小且可复用？

在数百万个分支的情况下，完整的 ref 通告可能超过 100 MiB。Pando 只通告 trunk 分支，作为新 feature 分支 push 的基础。任何拥有 trunk 历史的读者随后都可以从 1 个存储的 pack 中 fetch 该分支。在 OpenAI 的 monorepo 中，pack 中位数小于 20 KiB。

如何以线速提供 fetch？

Pando 通过 packfile-uri 返回下载链接，这是 Git 协议已有的特性。它发送一个空的内联 pack。一个名为 Express 的交付服务使用一致性哈希在区域缓存 pack，命中率超过 99%。

什么取代了垃圾回收？

每次 push 都会创建一个“L0”pack。后台 worker 将 pack 分组成几何级增大的 cover，类似 LSM-tree compaction。该 monorepo 目前使用到 L4 的 cover。Cover 充当跳表，因此 pack 选择以对数时间运行。

生产数据如何？

以下所有数据均由 OpenAI 自行报告。

• 推送延迟中位数降低近 80%。
• 每天近 1 PB Git 数据，仅使用少量 CPU 核心。
• 一小时内提供超过 57 TB 的 pack，其中超过 99% 来自本地磁盘缓存。
• 在标准云 VM 上，clone 和 fetch 可打满 10 Gbps 链路。 OpenAI 还针对 3-phase-commit 和 write-ahead-log 设计运行了 1,000 个写入者的模拟。它将这些称为教学模型，而非基准测试。

Pando 与其他方案相比如何？

OpenAI PandoGitHub SpokesAnthropic Scion Git 客户端兼容是 是 否，自有 scn 客户端 写入协调按分支、因果一致性三阶段提交加 quorum服务端提交；ref 通过 compare-and-swap 默认副本未披露（blob + 元数据存储）5 个完整副本 无完全物化的仓库副本 读取路径通过 packfile-uri 复用 pack，Express 缓存最接近的同步副本分层 tree/blob 缓存 缓存命中率超过 99%未披露每层超过 99% 头条结果推送延迟中位数下降约 80%服务约 10 亿个仓库CPU/内存占用小 200 倍 构建投入10 周，Rust未披露7 人，5 个月 是否可供他人使用否是，支撑 GitHub否

Pando 如何构建和部署？

OpenAI 为 agent 编写了一套 Git 合规测试套件，并加入了确定性模拟测试。使用 GPT-6 Astra 的 agent 编写了 Lean 和 TLA+ 规范来查找 bug。 Pando 最初作为读写直通代理运行，因此流量迁移无需停机。OpenAI 向开发者机器和 ChatGPT 桌面应用发布自己的 Git 构建。

哪些改进回流到上游 Git？

OpenAI 修复了客户端处理并发、中断和恢复 pack 下载的问题，并加入了 packfile-uri 追踪。其构建增加了并行 pack 索引和“explicit haves”。部分修复已进入上游。其余位于公开补丁跟踪器中。

有哪些限制？

• Pando 未开源；OpenAI 团队表示正在探索分享该技术的方式。
• 跨分支读取没有单一时间点快照。
• 重复或堆叠的分支推送会重发 trunk 之外的所有内容。p99 pack 小于 3 MiB。
• 所有性能数据均为自行报告，尚无独立基准测试。

关键要点

• Pando 保留了 Git，但为并行 agent 流量重建了服务器。
• 按分支的因果一致性消除了仓库级写入争用。
• 存储且可复用的 pack 取代了按客户端生成 pack。
• 推送延迟中位数下降近 80%；每日流量接近 1 PB。
• 客户端修复进入上游；后端目前仍为内部使用。 查看完整的 OpenAI 工程博客文章、OpenAI Git 仓库和补丁跟踪器。也欢迎在 Twitter 上关注我们，别忘了加入我们 15 万+ 的 ML SubReddit 并订阅我们的 Newsletter。等等！你在用 Telegram 吗？现在你也可以在 Telegram 上加入我们。

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）