AREX Feed Article
OpenAI 官宣自研 Git 后端 Pando：称 push 延迟降约 80%、日服务近 1PB 数据，并考虑对外提供
北京时间 11 月 3 日上午 8 点 09 分，OpenAI 开发者官方账号 @OpenAIDevs 宣布，公司为自家 monorepo（所有代码共用一个仓库的开发模式）构建了新的 Git 后端 Pando，用意是在不改变工程师和智能体（agent）使用 Git 方式的前提下，承载更多 push 与 fetch。OpenAI 称，Pando 已把 push 延迟降低约 80%，现在每天服务接近 1PB（petabyte，约 100 万 GB）的 Git 数据，「我们可以让 Git 容量随 agent 用量一同扩展」。（）
此前的北京时间 11 月 2 日深夜，OpenAI 已发布技术博客《Scaling Git at OpenAI》，披露更多细节：Pando 目前支撑 OpenAI monorepo 的全部开发流量，从立项到进入生产环境只用了 10 周。（）11 月 3 日上午 9 点 54 分，OpenAI 联合创始人兼总裁 Greg Brockman 单独发帖佐证：「Pando 是一个可以扩展到超大型 monorepo 的 Git 后端。我们选择了继续使用 Git 这条更难的路，这意味着启用 Pando 不需要对开发者体验（devex）做任何改变。」他同时表示「在考虑把它提供给其他人」，有意者可以联系 。（）
上述性能数字均为 OpenAI 单方披露，目前没有第三方独立验证；Brockman 所说的「提供」也只是意向表达。
一致性换扩展：不同分支的 push 并行，同一分支仍要排队
Codex 改变了 OpenAI 的开发规模与节奏：工程师能并行推进多得多的工作，随之而来的是更多分支和 push、更多 merge，以及来自开发环境、研究任务和 CI（持续集成）的更多 fetch 与 clone。这些需求相互叠加——一名工程师同时有多个变更等待 CI，每次 push 又会让多个任务去 fetch 同一个 commit。从 2025 年底前后开始，支撑 monorepo 的系统逐渐跟不上：fetch 和 push 变慢、merge 失败，可靠性有时跌破 90%。（）
团队没有更换 Git，而是重写了后端。@OpenAIDevs 的推文线程把新系统的取舍讲得直白：工程师 push 到不同分支时，Pando 可以并行更新这两支；push 到同一分支时，更新仍然按顺序排列。代价是，读取方同时查看多个分支时，看到的可能不是同一时间点的仓库。（）
博客把这称为因果一致性（causal consistency）：每次 push 把收到的 packfile（Git 打包多个对象进行传输和存储的格式）作为不可变对象写入 blob（二进制大对象）存储，同时在元数据存储里记录一个新的 ref（引用）版本，内容涵盖新分支端点、来源 pack 以及依赖的更早版本；服务器在流式写入的同时完成校验，不解包进任何本地仓库，整次写入只需常数次元数据读写。push 到同一分支的竞争点只剩 ref 指针本身，由一个类 compare-and-swap 的原子操作保护。（）
10 周建成：核心一人设计、多组 agent 实现，今年 4 月接手生产流量
按博客的说法，Pando 本身就是用 Codex 建成的：核心架构由一名工程师设计，实现交给多组 agent，部署由少数工程师完成，从立项到投产用了 10 周，今年 4 月开始承接生产流量。
工程实现上，Pando 用 Rust 从零写起、不带遗留依赖。团队准备了一套一致性测试套件，让 agent 能对照标准 Git 行为验证自己的改动；再用确定性仿真测试抓出协商与 pack 规划中的竞态和回归。随着模型更新，GPT-6 Astra 驱动的 agent 用 Lean 和 TLA+ 写出形式化的「theory of Pando」，用来找出并修复实现 bug、证明系统性质；连续数百小时的会话负责清理边界情况，另有一批 agent 全天候用具备 Daybreak 能力的模型对 Git 和 Pando 做红队测试。
上线过程刻意保守。Pando 先作为旧源码控制系统的读写直通代理运行，与旧系统保持同步，再把工作负载逐个迁过去，全程没有停机；数百个依赖旧 API、webhook 和仓库下载的集成一并迁移。OpenAI 还把自家构建的公开版 Git 分发到开发者机器和 ChatGPT 桌面应用，用一个 Git CLI 内部封装分阶段迁移客户端，开发者可以直接让 Codex 迁移自己的开发环境和服务。（）
只通告一个 trunk：push 变小，也变得可复用
push 时 Pando 不按传统方式「亮出所有牌」。常规 Git 服务器会把所有分支通告给客户端，让客户端尽量排除服务器已有的对象，但博客估计，数百万分支的全量通告可能超过 100 MiB。Pando 默认只通告一个指定的 trunk（主干）分支作基底，通告大小不随分支数增长，客户端生成的 pack 只依赖 trunk，方便日后复用；代价是反复 push 同一分支、或把分支叠在分支上时，客户端要重发 trunk 之外的全部内容。在 OpenAI 的 monorepo，这样生成的 pack 中位数不到 20 KiB，99 分位不到 3 MiB。博客称，切换到 Pando 后，中位数 push 的延迟下降接近 80%，合并可靠性也有所提升。（）
读路径：不现算 packfile，直接发已有 pack 的链接
读取侧是另一组数字的来源。fetch 时，Git 客户端告诉 Pando 自己已有哪些提交（commit）、想要哪些；Pando 返回一组已存储 packfile 的链接，覆盖这个缺口，包括缺失的分支依赖。这些 packfile 可能包含客户端已有的对象，但 OpenAI 的思路是：把同一份字节在大量读取方之间复用，换取接近 CDN 的性能。（）
实现上，Git 协议在一次 fetch 或 clone 的响应里只允许内联一个 packfile，Pando 用上了协议中少有人用的 packfile-uri 特性：内联空 pack，以链接形式返回其余 pack，并为该特性向上游贡献了一批改进。pack 的投递交给名为 Express 的服务：OpenAI 在各区域维护带本地缓存的 Pando 集群，用一致性哈希把请求路由到 Express，缓存命中率超过 99%。博客称，只用标准云厂商的虚拟机，clone 和 fetch 就能打满 10 Gbps 链路；支撑这一交付量只需少量 CPU 核心，单小时曾交付超过 57 TB，其中 99% 以上的字节来自本地磁盘缓存。（）
为免客户端每次追赶都要下载数以万计的小 pack，Pando 在后台把 L0 pack 逐层合并成越来越大的覆盖集，目前 monorepo 用到 L4，思路类似日志结构合并树（LSM-tree）的 compaction。每一层的 pack 都保留下来、持续用于响应读取，而不是合并后丢弃。
回馈上游 Git：中断下载后的清理等修复已进上游
Pando 直接把可复用的 pack 递给客户端，下载和索引这些 pack 因此成为系统快和稳的关键一环。OpenAI 说，这暴露出 Git 在并发下载、中断传输后的清理、续传已完成下载等路径上的边界情况；他们修复了这些路径，并在 fetch 接受已存在的 pack 时加入校验，把工作回馈给上游。推文里举的例子是「中断的 packfile 下载后的清理」。（）
此外，OpenAI 给 packfile-uri 下载加了追踪、给 pack 生成加了字节计数，用于区分一次慢 fetch 究竟慢在生成还是传输；在 OpenAI 的 Git 构建中，客户端可以并行下载和索引独立 pack；还加入「explicit haves」，把分支当前端点与推送客户端可能省略的历史分开通告，客户端于是能用 --force-with-lease 确认特性分支未移动、只对 trunk 构建 pack，任何拥有 trunk 历史的客户端都能用同一个 pack 拉取该分支。博客称，其中若干改进已进入上游 Git，其余放在 OpenAI 的公开仓库，进展可以通过公开 patch tracker（补丁追踪器）追踪。（）
对外提供：意向先行，形态和时间表都未定
至于对外的具体安排，两份材料都没有给出：没有产品形态、时间表和定价，也没有面向第三方工作负载的基准数据。博客中相关的表述是「我们正在探索把让 Pando 成为可能的技术分享给用户的方式」，并提到正在研究 monorepo 之外的用途，包括大量 agent 在同一个 Git 仓库上协作的场景。
在官宣推文的回复里，开源是被反复追问的话题：Miguel（@MigTavares）问「Pando 到底会不会开源」，这条回复拿到 42 个赞（）；工程师 Joshua Hayes（@friedglue）则问「你们已经开源了……对吧」。（）OpenAI 目前交到社区手上的，是对 Git 上游的修复和一个公开 patch tracker，Pando 本体没有随博客发布。截至北京时间 3 日 14 时许，这条官宣推文的浏览量超过 63 万次、点赞超过 4,100 次。
Pando 会不会开源、什么时候以什么形态对外提供，目前都还没有答案；Brockman 留下的 是唯一的公开对接方式。