OpenAI自建Pando重构Git后端
Scaling Git at OpenAI
随着Codex的普及，OpenAI的代码库规模呈爆炸式增长，传统Git架构已难以支撑高频并发。我们并未抛弃Git，而是构建了名为Pando的全新后端系统。Pando在保持Git协议完全兼容的前提下，实现了水平可扩展的写入能力和极致的读取吞吐量。通过引入因果一致性模型和复用packfile策略，Pando将中位推送延迟降低了近5倍，每日处理数据量接近1PB。这套系统让工程师和AI代理能无缝沿用现有工作流，同时解决了多分支并发推送和大规模数据分发的瓶颈。
我们构建了Pando，这是一个全新的Git仓库后端，在完全不中断任何工程工作或不改变团队使用Git方式的前提下，支撑了OpenAI单体仓库的全部开发需求。
HN 评论区
108- usrme
据我统计，这篇 OpenAI 的文章是该主题下的第五篇重磅文章，前四篇分别是：
- Cursor: https://cursor.com/blog/git-at-any-scale
- GitHub: https://github.blog/engineering/architecture-optimization/bu...
- Anthropic: https://www.anthropic.com/research/redesigning-source-contro...
- GitHub: https://github.blog/engineering/architecture-optimization/th...
也许 East River Source Control 的那篇也算沾边：https://ersc.io/blog/what-comes-after-git。
我很好奇，在这些公司工作的人们之间，有多少想法的交叉融合以及后续实现细节的共享。这一切似乎都有可能会走向收敛。
- bigmadshoe
谁能给我解释一下，这海量的代码实际上是在做什么？显然他们拥有各种模型架构变体、训练基础设施、服务基础设施以及应用的源代码。
为什么任何这些内容的体量都会呈指数级增长？而且当（除了模型质量之外）他们的产品似乎并没有太大变化时，所有的工程师都在忙些什么？
- paxy
虽然我对此话题并无特殊兴趣，但这确实是一篇很棒的博文。没有每行都塞 AI，也没有无谓的营销或吹嘘。就是一群工程师用自己的声音，用数据、图表和可视化，非常详细地探讨了一个话题。
- pksunkara
我在文中没看到任何基准测试数据。比如，这系统每秒能处理多少次推送？能支持多少个并发推送者？等等。
声明：我正在 https://juju.bi 构建一个代码托管平台。
- cadamsdotcom
> 在处理推送时，Pando 会在将 packfile 流式传输到 blob 存储的同时对其进行验证，而无需将其解压到本地仓库
这难道没有被标记为重大风险吗？因为它似乎完全信任客户端。
尤其是考虑到我们在 2026 年看到的所有 rogue agents（失控智能体）以及收容/监控失效事件？
很想听听他们是如何认定这种验证方式已经足够充分的。
- japgolly
有趣的是他们同时使用了 Lean 和 TLA+。真希望他们能多谈谈这方面。我本以为他们会二选一。一般来说，它们做的是同一件事（证明规范），但方式截然不同。
- bob1029
如果你是一个价值万亿美元的庞然大物，为什么不采用完全不同的 VCS（版本控制系统）拓扑结构？为什么我们还要继续以“分布式”git 概念作为一切的基础？
在这个规模下，中心化恰恰是你想要的。服务器哪怕只增加一点点参与度，都会带来巨大的差异。
游戏工作室不使用 git 是有原因的。这不仅仅是因为大对象的问题。
- springtimesun
提交量增长图表中的百分比提升，是因为比 Anthropic 的速率低吗？这是一种“提交嫉妒”吗？
说正经的，我很享受阅读这些文章。我永远不会有在这个规模下工作的机会，但我喜欢阅读不同团队如何处理这类问题，我也好奇这些方法是否会随着大家提交得越来越多、越来越快，而逐渐渗透（或上传？）到常规实践中。