AREX Feed Article
239 GB 重传只过网 2.6 MB：microagi 披露 PB 级机器人数据分发管线，逾 1 PB 分发约 500 美元
2026 年 10 月 26 日，Hugging Face 联合创始人 Thomas Wolf（@Thom_Wolf）了机器人数据公司 microagi 团队发布在其官网的：一个 239 GB、18,788 个文件的数据集做小幅修改后重新上传到 Hugging Face，只有约 2.6 MB 真正经过网络，全程约 1 分钟。Wolf 在帖文中写道，这种收益随规模扩大持续成立，“因为机器人录制数据高度重复（相同的场景、相同的采集装置）”；数据随后经 Cloudflare Workers 分发到任意云，超过 1 PB 的分发成本约 500 美元。
这份题为 “A petabyte a day, into anyone's cloud”（一天交付一个 PB，送进任何人的云）的解析给出的管线分两跳：先把录像暂存进 Hugging Face Bucket 一份中立副本，再用 Cloudflare Workers 发往 AWS S3、Google Cloud、Azure Blob 等客户自己的对象存储。文中数字均为 microagi 团队自述口径，尚无独立核实。
靠 Xet 分块去重：桶里已有的数据不再过网
microagi 在解析中解释，这次近乎零传输的重传靠的是 Hugging Face Buckets 底层的 Xet 存储：Xet 把文件按内容寻址的分块（content-addressed chunks）保存，两个文件只要共享内容，无论在桶里什么位置，就共享同一批数据块。
该团队第一次体会到这一点，是已暂存的录像需要带小幅修改重新上传：桶里已经装着每一个数据块，没有剩下要发送的东西；第二个要同一批数据的客户，暂存成本也几乎为零。
这笔账在规模上同样成立，原因写在解析里：机器人录制数据自己会重复，相同的场景、采集装置和标定，一场接一场。在一次暂存运行中，122 TB 写入桶，真正过网的只有其中约五分之一的字节；正因过网字节少，单次运行才能在 3.1 小时内完成这 122 TB 的暂存。该团队还记下一个测量教训：存进去的字节数不等于发出去的字节数，Xet 的上传速率统计的是落入桶中的数据量，实际过网字节少得多；只看这一个速率曾误导过他们，后来两个都测。
一份数据要交付很多次：为什么先暂存再分发
解析开头描述了这类交付的规模：机器人靠看人叠衣服学会叠衣服，需要数千小时、多个机位、每帧带深度和位姿的录像。随着客户规模扩大，一次数据交付不再是一个文件夹，而是数百万小时录像、几个 PB、数百万个文件，且下一个请求已经在路上；数据还必须落到客户训练的地方，各自的云、各自的区域、各自的桶，有的团队用 AWS，有的用 Google Cloud，有的用 Cloudflare 或 Hugging Face，还有一家用的是 microagi 一周前从没听说过的对象存储。
该团队为此定了三条规则：任何目的地，只要对方讲 S3 协议或接近 S3 就交付；多客户并发交付互不拖慢；不共享凭证，每次交付的访问范围只限这一次交付。架构相应分两跳：第一跳把源存储的录像读一次，暂存进 Hugging Face Bucket，S3 兼容、按客户隔离、底层是 Xet；第二跳从这份中立副本分发。暂存的理由很直接：同一批录像要交付不止一次，给多个客户、给同一个客户的两个区域、下个月同一批数据加一段新会话再交一次。
该团队追求的是让第一跳“运维起来平淡无奇”（boring to operate），靠三条性质做到：worker 只追加文件、从不删除或重写；重启的 worker 跳过已存在的文件，重跑一次已完成的交付什么都不会上传；每个 worker 在上报完成前对照源逐文件校验。解析同时记录了两个教训。其一，数百万小文件的瓶颈不是带宽：每个上传 worker 逐个核对文件，约 56 秒花在查找上，线上传输只占 31 秒，把查找并行化是他们写明的下一项大提速。其二，文件缓存反而拖慢读取：早期版本在对象存储前加了缓存，工作集超出缓存后每次逐出都变成完整重新下载，源被重复读了 10～18 遍；上传本来每个文件只读一次，修复办法是干脆不用缓存。
Worker 消息只带 URL 不带凭证：无出口费的第二跳
第二跳是一支 Cloudflare Worker 舰队，从 Hugging Face Bucket 拉取、推进客户的桶，中间没有计费链路。对象按大小走两条路：低于 Cloudflare 单请求 100 MB 体积上限的小对象，一条队列消息、一次读取、一次写入；超过的大对象走分段上传，发布方在目的地开启上传，把对象切成若干组分块，为每组预签名 URL，每组发一条消息，消息里只带 URL、不带任何凭证。Worker 消费队列，把来自 Hugging Face 的分段读取直接流式写进目的地的签名写入，全程不把整个对象装进内存；各分块之间没有协调者，目的地的分段上传自己记录哪些分块已到达，谁落进最后一块谁完成对象。
该团队称，这套舰队横向扩展：一个分片是一对队列加一个 Worker，每个 Worker 最多 250 个并发调用（Cloudflare 的上限），一百个分片就是 25,000 个在途传输；到这个规模，发布方已经来不及把消息排成积压，舰队随到随清。早期版本把每个大文件整个交给一个 Worker，速度只有每秒个位数 MB；把分块组摊到多个调用后，单文件速度约提高 100 倍，第二跳达到 59 TB/小时，不再是管线最慢的一段。
成本数字同样来自 microagi：Cloudflare 按 Workers 的计算时间计费，不按带宽，而一个流式搬运字节的 Worker 几乎所有时间都在等网络。该团队写道，搬运数百万个文件、超过 1 PB 数据，在 Cloudflare Workers 上花费约 500 美元；加上第一跳，整条管线从他们的存储到客户桶约 40 TB/小时。解析里还有一个反例：Cloudflare 会部分按错误率伸缩队列消费者，一个藏在停顿流拆解代码里的未处理 rejection 被平台记成失败调用，自动伸缩器把每个 Worker 压在约 20 个并发调用，不到上限的十分之一；把错误路径处理干净后，并发才爬回 250。
交付何时算完成也有明确判定：每个对象落地时，源存储持有的校验和随交付签入分段完成请求，字节不符目的地就拒绝存储；队列清空后还要比对所有文件是否发布正确，缺的从 Hugging Face Bucket 定向补发，比对干净才算交付完成。
日志寄给平台方之后：hf-xet 1.7.0 与 Cloudflare 的三条建议
与 Hugging Face 的 Xet 团队，microagi 两次踩中客户端 bug。第一次是“永远传不完的上传”：他们最大的提交一批 500 条视频、约 62 GB，有时到达 100% 就停住不动；把日志和工作负载描述发给对方后，等修复期间改成每批 100 个文件提交，连续 52 次顺利通过，另一次 6.7 TB 的上传一次也没卡住。Xet 团队靠这些日志找到根因：双方客户端和服务器共用的 HTTP 库深处有一个罕见 bug，会让连接在大型上传中途永远等待；上游已有修复，他们升级后用 microagi 卡住的那批数据做了验证。第二次是“对不上的字节数”：近重复视频上 Xet 报告的字节比实际发送的多，逐目录校验开始整批失败，文件本身没问题，错的只是数字。microagi 做了一个不依赖网络的最小复现发过去，对方确认修复已进入下一个版本，几天后 hf-xet 1.7.0 发布，顺带带来更快的下载。
Cloudflare Queues 团队的一次联合工作会改写了第二跳的几个决定。microagi 列出三条收获：队列在全球就近接收消息，但消费者全跑在北美西部，把队列铺向世界各地不会更快，这条结论让他们省掉一次尝试；一个 Worker 同时只能有六个请求在等响应，但数据开始流动后请求就不再计数，单个 Worker 能流式处理远超六路传输；把超过 100 MB 的文件切块、分头入队，这条建议后来直接变成了第二跳的分块扇出设计。
交付之后：直接从桶里回看每一段录像
解析结尾透露了管线的下一步：一个录像查看器。交付完成后的下一个问题常常是“里面到底是什么”。打开任何一条已交付的录像，它直接从 Hugging Face Bucket 播放，无需先下载；视频、深度、位姿并排显示，客户可以逐场查看每次会话拍到了什么。该团队写道，桶里的 PB 级数据很难有手感，查看器让人一次看一场地把交付内容浏览一遍。
文中附的截图显示：第一人称视角下，一双手正在用电动螺丝刀拆装打印机部件，画面上叠加了手部追踪关键点，右侧是深度视图、SLAM 相机轨迹和一条带标注的子任务时间线，当前子任务为“用电动螺丝刀拧下机械部件上的其余紧固件”。
这些功能部分已经可用。按解析的说法，很快会有更多可展示的内容。