先看证据
Agent 把推送频率推到了旧模型的边界
经典 Git 服务器的假设是人在提交：频率不高，冲突靠合并请求或显式锁串行化。Agent 的工作方式不同，每隔几分钟就推送一次，CI 在每次推送后立刻拉取。Reason Machines 的描述是，经典服务器会把发往同一仓库的推送排进同一个队列，并且为每次拉取重新生成一个 pack。于是服务器的工作量随客户端数量增长，而不是随新增代码量增长。
OpenAI 撞上过这堵墙，为此自建了 Pando，称其把推送中位延迟降低近 5 倍，每天服务近 1 PB 的 Git 数据。值得一提的是，这些是 OpenAI 对自家生产系统的报告，测试条件与 Aspen 不同，不能直接拿来横向比较。Aspen 走的是另一条路：它没有复刻 Pando 的代码，而是照着公开的设计另写了一份，以 Apache 2.0 许可放出，可以自行部署。
把比较并交换下沉到分支
Aspen 放弃了两条多数 Git 服务器仍在坚持的假设。第一条是锁的粒度。每个分支在 PostgreSQL 里是一行记录，保存一串版本；一次推送先上传自己的 pack，再用一次比较并交换移动分支指针。发往不同分支的推送因此从不互相等待。如果两次推送在同一分支上抢跑，只有一个会赢，另一个收到 Git 惯常的“先拉取”错误——冲突处理仍在客户端的既有路径上。代价是，读取时不同分支可能来自略微不同的时刻。
第二条是 pack 的生成方式。Aspen 不解包推送内容，只校验 pack、补齐缺失的基线对象，然后原样存进 S3 兼容的对象存储。拉取时，它把客户端缺少的那些已存 pack 直接流式发出，不做任何重压缩；这些 pack 也可以通过签名 URL 交给 CDN 分发。为了把协商成本压住，推送方只能看到 trunk 分支，即使仓库有上百万个分支，协商面也很小；后台的压缩按层级、每次合并 16 个 pack，类似日志结构合并树，落后很多的客户端拿到的是几十个 pack 而不是几千个。深度为 1 的 CI 拉取则共享一个只构建一次的 tip pack。
567 次/秒是怎么测出来的
测试用的是一台 8 核服务器、S3 Standard 和一台 4 核 PostgreSQL，目标仓库是 git.git 的副本，约 4,500 个文件、75,000 个提交，推送打到分支专属 URL。结果是连续 5 分钟维持每秒 567 次推送且没有报错，每次推送在 Git 输出“ok”之前都已落到 S3 和 PostgreSQL。推送延迟中位数 208 毫秒，99 分位 314 毫秒；另一个客户端在推送被确认后，中位数约 30 毫秒看到这次推送。
这些数字的口径需要说清楚。README 自己把 Aspen 的数据称为“indicative”，而非性能承诺；这是厂商自测，没有第三方复现。Aspen 的公开基准说明里还有另一套配置——单台 4 vCPU 跑 aspen dev，用 SQLite 和本地磁盘——其中部分对比在不同内存条件下完成，每项通常只跑一次，且 1,000 并发浅克隆的测试曾出现大量失败，修复之后才复测。把两套结果混在一起谈是不对的。作为外部参照，Cursor 称其基于 S3 Standard 的系统每秒可处理 120 次推送，换到 S3 Express One Zone 超过 300 次，但那是其自有单体仓库上的复制集群，配置与 Aspen 不同。
它能跑多快，取决于你往哪个分支写
567 次/秒只在分支分散的前提下成立。所有更新都落到 main 时，每次提交都必须建立在前一次结果之上，Reason Machines 称这种落主干的方式目前约为每秒 4 次。同一分支上的竞争也仍会发生，只是被转化成了标准的 Git“先拉取”错误，由客户端重试——对高频 Agent 来说，这意味着重试逻辑与分支划分策略会直接影响实际吞吐。
深度为 1 的拉取风暴测试显示，Aspen 传输的字节数是 git.git 上原生 git upload-pack 的 1.029 倍，基本持平。这说明复用已存 pack 的策略并没有以带宽换 CPU。但总体而言，这些数字描述的是一个特定仓库规模、特定存储后端的场景，不能外推为“Aspen 在所有仓库和负载下都能达到该速率”。