1PB 机器人训练数据：Native LeRobot v3、Self-contained Lance Blob v2 与 External-Blob Lance v2 + Shared Native

我会把前面两轮内容合并、纠错，并以 Lance 官方最新Blob v2（Blob v2）文档为主线重新组织。重点会明确区分三种方案的物理布局、训练 I/O 路径、快照一致性、生命周期/GC、NFS 元数据压力、可移植性、LeRobot 原生兼容性与 1PB 级部署取舍，并用 Mermaid 把数据面和训练热路径画清楚。目前最关键的修正已经确认：Lance 官方文档明确说明Blob v2（Blob v2）在data_storage_version = 2.2中可以混合保存内联字节（inline bytes）、外部 URI（external URI）和外部 URI 切片（external URI slice）；同时read_blob_ranges可以对多行做计划式字节区间读取，take_blobs则提供可 seek 的BlobFile。因此，第三种方案不能再描述成“Lance 里只是一个video_uri字符串”，而应当定义为真正的External-Blob Lance v2。还有一个需要写进最终文档的关键纠错：所谓自包含 Lance（Self-contained Lance）并不等于“大 MP4 字节一定内嵌在.lance数据文件里”。Blob v2 默认会把小于 16 KiB 的值内联，中等值放进共享.blobsidecar，而大于 2 MiB 的值通常放进独立.blob文件；“self-contained”的准确含义是这些 payload 仍由同一 Lance dataset 的清单、版本和生命周期管理。同时，LeRobot/Lance 的最新代码状态也已核对：lerobot-lancedb0.3 已删除旧的LeRobotLanceDataset/LeRobotLanceVideoDatasetloader，转为lerobot-lance-convert+ doctor；新的读取路径正在 LeRobot Core 的 PR #4363 中，以frames.lance + videos.lance + meta.lance形式接入，视频表保存 Blob v2 与 MP4 byte-index 列。该 PR 截至 2026 年 8 月 24 日仍是 Open，因此最终文档会把“已发布能力”和“正在上游中的实现”明确分开。:::writing{variant=“document” id=“58321” title=“1PB 机器人训练数据：Native LeRobot v3、Self-contained Lance Blob v2 与 External-Blob Lance v2 + Shared Native MP4 架构对比”}1PB 机器人训练数据：Native LeRobot v3、Self-contained Lance Blob v2 与 External-Blob Lance v2 + Shared Native MP4 架构对比官方文档Lance 官方文档：Blob Columns / Blob V2这是目前最直接、最完整的Blob V2（Blob V2）使用文档，涵盖：Blob V2 写入（Blob V2 Write）：blob_field、blob_arrayBlob V2 读取（Blob V2 Read）：read_blobs、read_blob_ranges、take_blobs外部 Blob（External Blob）内联存储（Inline Storage）打包存储（Packed Storage）独立存储（Dedicated Storage）BlobFile 流式/随机读取（Streaming / Random Access）Blob V1 → Blob V2 迁移data_storage_version="2.2"的版本兼容规则需要特别注意：Blob V2（Blob V2）要求 Lance 文件格式版本（Lance File Format Version）为 2.2 或更高；旧的lance-encoding:blob属于旧版 Blob 方案，在 2.2+ 新写入中不再使用。(Lance)官方设计介绍Lance Blob V2: Making Multimodal Data a First-Class Citizen in the Lakehouse这篇更适合理解Blob V2 的底层设计（Blob V2 Format Design）。Blob V2 将 Blob 的物理存储划分为四种语义：Inline→ 主数据文件Packed→ 共享.blob文件Dedicated→ 独立.blob文件External→ 外部对象，例如 S3 上已有的视频/图片底层统一通过 Blob 描述符表示，从而让上层 API 不必关心数据究竟存在哪种物理位置。(LanceDB)另外，官方Lance File Format 2.2（Lance 文件格式 2.2）介绍也值得看：Lance File Format 2.2: Taming Complex Data如果你是在研究Lance Blob V2 的底层格式/源码实现，我也可以继续给你整理Blob V2 的磁盘布局、Inline/Packed/Dedicated/External 四种模式、descriptor 结构以及读写流程，并严格翻译成中文。1. 结论先行对于以企业级 NFS 为主存储、数据规模约 1 PB、需要长期兼容 LeRobot 原生生态，同时又希望使用 Lance 的随机访问、列式扫描、批量读取与训练数据加载能力的机器人训练平台，建议把候选架构严格限定为以下三种：方案视频物理存储低维数据Lance BlobNative LeRobot v3 兼容如果同时保留 Native 时的视频重复Native LeRobot v3独立 MP4Parquet无原生0Self-contained Lance Blob v2Lance 管理的 Blob v2 payloadLanceInternal Blob v2需要单独 Native 副本约 1 份额外视频External-Blob Lance v2 + Shared Native MP4与 Native 共用同一批 MP4LanceExternal Blob v2原生目录可继续存在0最重要的修正是：第三种方案不应设计成video_uri: string + Python open()，而应设计成真正的外部 Blob v2（External Blob v2）。Lance Blob v2 原生允许同一 Blob column 中包含内联字节、外部 URI、外部 URI 切片以及空值，并且仍可通过read_blob_ranges执行计划式字节区间读取，或者通过take_blobs获得支持 seek 的BlobFile。因此，视频是否物理复制进 Lance dataset，并不决定是否能够继续使用 Lance 的 Blob-aware I/O。第二个必须修正的概念是：自包含 Lance（Self-contained Lance）并不意味着大 MP4 一定直接嵌在某个.lance文件内部。在 Blob v2 中，Lance 默认将很小的 payload 内联，将中等 payload 放入共享.blobsidecar，而大于约 2 MiB 的 payload 通常放进独立.blob文件。对于机器人 MP4，绝大多数实际上会成为 Lance dataset 管理范围内的独立.blobpayload 文件。所谓 self-contained，更准确的含义是：视频 payload、表数据、manifest、版本与生命周期都属于同一个 Lance dataset，而不是“所有字节必须位于单一.lance文件”。因此，在 NFS 上比较第二、第三种方案时，真正的问题不是：MP4 file vs one giant Lance file而更接近：Self-contained NFS/.../videos.lance/.../*.blob vs External-Blob NFS/.../videos/.../*.mp4两者最终都可能是 NFS 上的大型文件，并通过 seek / range read 访问。真正的差异是：谁拥有这些视频字节的生命周期、版本、一致性和命名空间。2. 当前 Lance 与 LeRobot 技术状态2.1 Lance Blob v2 的正式语义当前 Lance 官方文档规定，新的Blob v2（Blob v2）使用扩展类型lance.blob.v2，需要 Lancedata_storage_version = 2.2。旧的lance-encoding:blobmetadata 方式适用于2.1及更早格式，两套机制互斥。新数据集应使用 Blob v2。当前 Lance 文件格式说明同时标记2.3为 unstable，不建议生产环境使用。因此，如果现在建设 PB 级长期生产数据平台，更稳妥的策略是显式固定经过验证的Lance 2.2 文件格式（Lance File Format 2.2），而不是依赖next或实验性的 2.3。Blob v2 支持四类值：Blob v2 ├── Inline bytes ├── Lance-managed .blob payload ├── External URI ├── External URI Slice └── Null官方示例明确展示：blob_array([b"inline-bytes","s3://bucket/path/video.mp4",Blob.from_uri("s3://bucket/archive.tar",position=4096,size=8192,),None,])也就是说，第三种架构所需的核心能力并不是额外发明一套“视频 URI schema”，而是 Lance Blob v2 已经具备的正式能力。2.2 Blob v2 的三种读取方式Lance 官方目前区分：API返回结果最适合read_blobs完整 bytes批处理、需要完整 payloadread_blob_ranges指定 Blob 的若干 byte ranges视频窗口、部分读取、计划式 I/Otake_blobsBlobFileseek、流式访问、decoder file-like source官方特别建议：如果需要完整 Blob，不应自己围绕take_blobs()建线程池逐个read()，而应让read_blobs()通过 Lance scheduler 进行批量规划。对于机器人视频窗口，更关键的是read_blob_ranges()。2.3 LeRobot v3 原生结构LeRobot v3（LeRobot v3）本身采用 file-based layout：低维 state、action、timestamp 等放入 Parquet，大量 episode 合并进较大的 Parquet shard；视觉数据编码成 MP4，不再要求一 episode 一个文件；episode 边界、offset、task、schema 和统计信息则放入 metadata。其逻辑可以简化为：LeRobot v3 meta/ ├── info.json ├── stats.json ├── tasks.* └── episodes/ data/ └── chunk-xxx/file-xxx.parquet videos/ └── camera/chunk-xxx/file-xxx.mp4这意味着 Native LeRobot v3 本身已经针对“大量小文件”问题做过一次聚合，相比早期每 episode 一个 MP4 的模式，更适合大型共享文件系统。2.4 当前 LeRobot × Lance 实现状态截至 2026 年 8 月 24 日，旧的 standalonelerobot-lancedbplugin 架构已经发生了实质变化。lerobot-lancedb0.3 的主线已经删除旧的LeRobotLanceDataset和LeRobotLanceVideoDatasetreader，项目被重新定位为 LeRobot Core Lance reader 的 companion tooling。目前主要提供：lerobot-lance-convert lerobot-lance-doctor转换后的主要结构是：frames.lance videos.lance meta.lance其中videos.lance是一条 source MP4 对应一条记录，保存 Blob v2 和视频 byte-index 信息。新的读取能力正在 Hugging Face LeRobot Core PR #4363 中开发。该设计将LeRobotDataset保持为唯一公共 API，根据 metadata 中的 storage format 在内部选择 Lance backend；PR 当前仍为 Open，因此这一部分应视作正在上游集成中的能力，而不是已经进入所有稳定版 LeRobot 环境的既成事实。3. 三种方案的总架构Robot Training DatasetNative LeRobot v3Self-contained Lance Blob v2External-Blob Lance v2 + Shared Native MP4ParquetNative MP4Metadataframes.lancevideos.lanceLance-managed Blob v2meta.lance / metadataframes.lancevideos.lanceExternal Blob v2Shared Native MP4三种方案的核心区别可以浓缩成：Native LeRobot v3 Dataset owns MP4 paths Parquet owns tabular encoding Self-contained Lance Blob v2 Lance owns tabular encoding Lance also owns video payload lifecycle External-Blob Lance v2 + Shared Native MP4 Lance owns tabular/index semantics External immutable store owns video bytes LeRobot and Lance share those same bytes4. 方案一：Native LeRobot v34.1 物理结构meta/data/*.parquetvideos/*.mp4LeRobotDatasetNative 模式以：Parquet + MP4 + metadata构成完整数据集。对于你给出的apayan/so100_ball1，当前 Hugging Face 目录显示总大小约 55.8 MB，其中videos/为 55.6 MB，而data/只有约 83.9 kB。也就是说，该具体数据集几乎全部存储空间都由视频决定。 turn311582view0turn311582view1这种比例对分析 PB 级机器人数据非常重要：如果视觉数据占据绝大部分容量，那么是否复制 MP4 会远比是否同时保留一份 Parquet 和一份 Lance tabular representation 更重要。4.2 优势Native 的最大优势是生态兼容性（Ecosystem Compatibility）。现有 LeRobot 数据检查、训练、Hub 数据集、视频工具、metadata 工具以及大量围绕LeRobotDataset建立的代码都天然理解这一布局。其第二个优势是数据可检查性（Inspectability）。管理员可以直接：ls ffprobe ffmpeg rsync cp sha256sum操作 MP4。第三个优势是发布格式简单（Simple Publication Model）。不要求下游安装 Lance，即可理解数据的 Parquet + MP4 表示。4.3 训练方面的劣势Native 不代表必然慢，但原生训练路径需要自己承担：sample ↓ resolve metadata ↓ find Parquet row ↓ find MP4 ↓ decoder seek ↓ decode temporal window真正影响视觉训练性能的通常不是“MP4 是普通文件”本身，而包括：是否能够快速从训练 sample 定位到 source video；是否有 MP4 keyframe/byte offset 索引；是否重复执行 decoder initialization；是否能够把一个 batch 的窗口读取合并；是否执行全局随机采样还是流式近似 shuffle；是否存在 node-local cache；是否把许多彼此接近的 byte ranges 合并。LeRobot Core 当前正在开发的 Lance backend 正是在这些位置进行优化，包括 batch row fetching、视频 byte index、range fetching、range coalescing 与 decoder cache。 turn331865view2因此：Native LeRobot v3 的主要限制不是 MP4 文件格式，而是它原生没有自动获得 Lance table + Blob-aware batch I/O 所提供的统一访问层。4.4 适用定位Native LeRobot v3 最适合：Canonical interchange format LeRobot ecosystem compatibility Data collection Dataset publishing Dataset inspection Raw archive / source representation如果系统只有 Native，而没有其他索引、cache 和高性能 training view，在数百 GPU 的训练集群上则可能需要额外的数据服务层来降低随机 I/O 与 decoder 初始化成本。5. 方案二：Self-contained Lance Blob v25.1 正确理解 Self-contained这里的自包含（Self-contained）是一个逻辑生命周期概念，而不是“所有视频 bytes 都塞进一个.lancefile”。Blob v2 默认 placement roughly 为：Very small ↓ inline in Lance data Medium ↓ packed shared .blob sidecar Large ↓ dedicated .blob file官方默认阈值为约： 16 KiB inline middle-sized packed .blob 2 MiB dedicated .blob而机器人 MP4 通常明显大于 2 MiB，因此 Self-contained Lance 中的大量视频很可能在物理上表现为一个个 Lance 管理的.blob文件。所以结构更接近：Self-contained Lance DatasetManifest / Versionsframes.lancevideos.lancemeta.lanceLance-managed .blob payloads5.2 当前 LeRobot Lance 路线当前新的转换工具将 Native LeRobot v3 转换成：frames.lance videos.lance meta.lance其中 source MP4 被写入 Blob v2，同时videos.lance保存视频 byte index。lerobot-lancedb0.3 的转换器就是围绕该 schema 建设的。LeRobot Core PR #4363 当前描述的 schema 为：frames.lance one row per frame videos.lance one row per source MP4 blob v2 byte-index columns meta.lance metadata transport5.3 MP4 byte index 的意义训练 temporal window 时，真正需要的通常只是 MP4 中的一小段。例如训练样本需要：frame 100 frame 101 ... frame 107理想的数据加载器不应该：read complete 500 MB MP4而应该先得到：nearest keyframe + media byte offsets + container metadata再将目标时间窗口转成 byte ranges。当前 LeRobot Lance PR 中已经实现/实验了类似信息：file_size moov location keyframe frame indices keyframe byte offsets并将 batch 中所需的 header、moov 和 window ranges 组合成并行 range fetch。训练热路径可以理解为：