OpenAI披露Git后端Pando：因果一致性换来分支写入扩展，自报推送延迟中位数降近80%，但模拟是教学模型且Pando未说明对外提供

2026年11月2日，OpenAI的三位工程师Aaron Friel、Taylor Blau和Ted Nyman发布《在OpenAI扩展Git》（Scaling Git at OpenAI）。文章介绍Pando：一个为Git仓库提供服务的新后端，现在支撑OpenAI单体仓库（monorepo）的全部开发。原因在于Codex：工程师并行做的事情多了很多，意味着开发环境、研究任务和持续集成发出更多分支、推送、合并、拉取和克隆。从去年底前后起，旧系统开始吃力，出现拉取和推送变慢、合并失败，可靠性有时低于90%。

Pando保留Git协议和客户端，所以工程师和智能体的工作方式没有改变。它有两个目标：写入能在多个分支上水平扩展，读取要快到能占满客户端的网络带宽。写入时，Pando把每个收到的packfile存为不可变的blob，并在元数据存储里记录一个“ref版本”。互不相关的分支更新各自独立进行，只有推送同一个ref才会冲突。读取时，它复用已存的packfile，而不是为每个客户端现生成专属包，并把packfile的URI交给客户端，由区域缓存提供。

作者把它和他们建模的两种常见设计作了比较：一是在完整副本之间做三阶段提交，每次推送需要多轮往返，副本磁盘落在写入路径上；二是在对象存储里用共享预写日志，每次推送都要争着更新同一个清单。他们的交互式模拟（1000个客户端）显示，前者在负载下写入变慢，后者读取变慢。页面标明该模拟是“合成的教学模型，不是生产基准”，所以它解释了设计，但不能证明生产数字。

生产方面的主张很具体。切换到Pando后合并可靠性提升，推送延迟中位数降低近80%，引言里表述为近5倍。Pando每天提供接近1PB的Git数据，单小时内提供过超过57TB的包，其中超过99%的字节来自本地磁盘缓存，验证中在标准云虚拟机上占满了10Gbps链路。包分发服务Express报告缓存命中率超过99%。这些是OpenAI对自己一个单体仓库给出的数字，文章没有独立测量，也没有在生产中和其他系统做对比。

文章对取舍很坦率。Pando提供因果一致性，而不是所有ref的时间点视图：克隆期间两个客户端可能看到两个分支处于不同版本，而对单个ref的更新仍可串行化。为让包可复用，Pando默认在推送时只通告指定的主干分支，因此对同一特性分支的反复推送，或叠加的分支，会重发更多数据。在OpenAI的单体仓库里，这样产生的包中位数小于20KiB，第99百分位小于3MiB。Pando还在每个压缩层级保留包，最多用到L4，使拉取规划的时间随距离呈对数增长，而不是下载成千上万个小包。

关于构建过程，作者说Pando从启动到上线用了10周，4月开始承接生产流量，核心由一名工程师设计，由多个智能体团队实现，由少数工程师部署。他们用Rust编写，有一致性测试套件和确定性模拟测试，并用GPT-6 Astra智能体编写Lean和TLA+模型来发现缺陷。上线从Pando充当旧系统的读写穿透代理开始，因此流量迁移没有停机。文章没有说Pando可在OpenAI之外使用。

OpenAI也向Git本身贡献代码。它修复了并发包下载、中断传输后的清理以及恢复已完成下载中的边界情况，为packfile-uri下载添加了追踪，并加入“explicit haves”，使推送客户端可以使用--force-with-lease，只相对主干构建包。部分改动已进入上游Git，其他在OpenAI的公开分支里。抓取时，GitHub上的这个分支是git/git的公开分叉，其codex分支领先git/git主分支115个提交、落后522个，最近有一个以packfile-uri复用命名的合并。对运营大型单体仓库的团队，经验在于这个取舍：放宽跨分支一致性换来了写入规模，而在这里行得通，是因为用户和智能体依赖的是单个ref的更新顺序，而不是全局顺序。

简单概括：Pando用因果一致性换来分支级的写入扩展，用包复用换来读取吞吐。“近5倍”和“近80%”是同一项改进的两种说法。1000个客户端的模拟是教学模型，不是生产基准。所有生产数字都是OpenAI自报，文章没有说Pando可以在OpenAI之外使用。

补充一点：Pando默认只在推送时通告指定的主干分支，所以对同一特性分支的反复推送，或叠加的分支，会重发更多数据；在OpenAI的单体仓库里，这样产生的包中位数小于20KiB，第99百分位小于3MiB。作者认为这是合理的取舍。