OpenAI 发布 Pando：为 Agent 规模并行推送重做的 Git 后端，中位推送约快 5 倍
OpenAI 发布 Pando：给 Agent 规模并行推送重做的 Git 后端，中位推送约快 5 倍
OpenAI 发布自研 Git 后端 Pando，兼容 Git 协议与客户端，生产环境中位推送延迟约降到原来的 1/5，日均可吐近 1 PB Git 数据。Codex 带来的多分支并发写与海量并发读曾让旧系统慢推慢拉、可靠性一度低于 90%，Pando 改为单条 ref 可串行化、全仓只保因果一致，并把 pack 放进对象存储供跨客户端复用。项目约 10 周用 Codex 从立项到生产，Rust 重写，先双写代理再分期切流。
推荐理由
AI 评分 69
原文拆解了 Pando 用因果一致换写并行、用可复用 pack 换读扩展的取舍，可供理解大规模仓库后端设计。
主题
查看原帖我们构建了 Pando，这是我们 monorepo 的新 Git 后端，旨在处理更多推送和拉取，同时不改变工程师和 agent 使用 Git 的方式。 Pando 将推送延迟降低了约 80%，如今每天提供近 1 PB 的 Git 数据。我们可以让 Git 容量随 agent 使用量一同扩展。https://t.co/4c0YXOfKqK
查看原文
We built Pando, a new Git backend for our monorepo, to handle more pushes and fetches without changing how our engineers and agents use Git. Pando cut push latency by ~80% and now serves nearly a petabyte of Git data a day. We can grow Git capacity alongside agent usage. https://t.co/4c0YXOfKqK
正文
OpenAI 发布 Pando：给 Agent 规模并行推送重做的 Git 后端，中位推送约快 5 倍
Codex 把 OpenAI 单体仓推到「多分支并发写 + 海量并发读」的极限后，他们自研 Pando，兼容 Git 协议与客户端的新后端：分支级因果一致性、跨客户端复用 packfile；生产上中位推送延迟约降到原来的 1/5，日均可吐近 1 PB Git 数据。 https://t.co/lj8LXUD8nJ
Codex 让并行改动、分支、推送、CI 拉取同时放大，旧系统去年底起慢推慢拉、合并失败，可靠性一度低于 90%。他们没换掉 Git 工作流，而是换后端：无关分支可并行更新；读侧尽量用同一份已存 pack 吃满带宽。
对比过两条常见路：三阶段提交靠多副本多数派锁 ref，全仓更新偏串行，磁盘与协调压在推送路径；共享 WAL/清单能并行上传 pack，但无关分支仍抢同一 compare-and-swap，副本跟进建索引跟不上就拖「刚推完就能拉」。Pando 松掉两点假设（全仓某时刻一致、以及按客户端现算专用 pack）改成：单条 ref 可串行化，全仓只保因果一致；pack 进对象存储，元数据记 tip、依赖与包指针。推不同分支互不堵；读多条分支时，不必假设同一快照。
写入默认只广告主干作基，广告不随百万级分支膨胀，pack 更易复用；代价是叠分支可能多传。他们仓里中位 pack <20 KiB，P99 <3 MiB。读侧把 have/want 映射成已存 ref version，靠 packfile-uri 下发可缓存包（Express 命中率 >99%），标准机可吃满 10 Gbps。后台按 LSM 思路把 L0 合到更高等级（至 L4），既压缩又当跳跃索引，规划约 O(log Δ)。
约 10 周用 Codex 从立项到生产（约 4 月起接流量），Rust 重写，先双写代理再分期切流。效果含合并更稳、单小时曾送出 >57 TB（>99% 本地缓存）。改进回馈上游（并行下包、explicit haves 等）。仿真与生产口径需分开看；核心取舍是用因果一致换写并行、用可复用 pack 换读扩展，同时保住 Git 客户端兼容。