How Much Pretraining Data Does a Robot Foundation Model Need?

There is no fixed answer, because published pretraining corpora differ by an order of magnitude depending on the lab, the model, and how heavily the team weighted diversity over raw hours. EgoVerse ships 1,362 hours; EgoScale pretrains on 20,854 hours; Egocentric-10K totals roughly 10,000 hours; GEN-0 draws on more than 270,000 hours of egocentric human video. All four are legitimate, published pretraining datasets, which is itself evidence that "how many hours" is the wrong first question.

The more useful question is what those hours cover and whether they are validated and action-labeled, not just recorded. A smaller, well-specified, diverse corpus with reliable labels can train a more capable pretraining stage than a much larger corpus that is redundant or under-labeled. Scaling-law evidence (below) backs this: composition, not just volume, predicts downstream performance.

Four public reference points, each from an official source, span nearly three orders of magnitude in scale:

These are the only hour counts used on this page, each taken exactly as published by its official source. No hour count for Firsthand-collected data is implied by this table.

The spread across these four corpora is itself informative. EgoVerse, at 1,362 hours, is roughly two orders of magnitude smaller than GEN-0, yet both are used as pretraining sources in published work. That gap is not a sign that one team collected "enough" and the other did not — the datasets differ in scope, modality mix, and the model architectures they were built to feed. Treating any single number from this table as a target to match, rather than as a reference point for how wide the range actually is, misreads what the table shows.

Raw hours conflate three different things: how much was recorded, how much survived quality review, and how much carries usable labels. A raw-hour budget overstates what a team actually trains on, because teams routinely discard footage that fails calibration, sync, or coverage checks. The more meaningful unit is validated hours — footage that passed QA against a written spec — combined with the diversity of scenes, tasks, objects and people it spans.

• Diversity of scenes, tasks, objects and people — a corpus concentrated on a few environments underperforms a smaller, more varied one
• Validated hours, not raw recording — footage that passed QA against a spec, not everything captured
• Action labels — hand pose, wrist trajectories and segment boundaries that make video usable for training, not just viewable
• Calibration and sync quality — matched intrinsics and time-aligned streams that make geometry and depth usable across a dataset

The EgoScale scaling-law study reports a log-linear relationship between pretraining-data volume and downstream performance: task-completion success improved roughly log-linearly with data scale, and the paper measured a 54% improvement on a 22-degree-of-freedom hand task when scaling from a smaller to the full 20,854-hour corpus, exactly as reported in the study (arXiv 2602.16710, NVIDIA GEAR).

GEN-0, drawing on 270,000+ hours, reports that scaling was accompanied by an emphasis on data quality and diversity — not sheer hour count alone — as reported on its official blog (Generalist AI). Read together, the two data points do not contradict each other: log-linear returns mean that early hours in an underrepresented condition move performance more than additional hours in an already well-covered condition. That is a diversity argument, not a volume argument.

See also: Do robot foundation models follow data scaling laws?, which covers the EgoScale and GEN-0 findings in full.

Pretraining is not the only stage that needs data. EgoScale's published recipe adds an aligned mid-training stage of roughly 50 hours of human video plus roughly 4 hours of matched robot demonstrations across 344 tabletop tasks, exactly as reported in the paper. That is a small fraction of the pretraining corpus, but it is where embodiment alignment happens — matching viewpoints and calibrated intrinsics between the human and robot data.

Post-training (fine-tuning) is smaller again and closer to a policy-training budget: a practical starting point elsewhere on this site is 50–100 validated hours per skill, scaled further only where held-out evaluation shows the policy is still thin. So the three stages differ by orders of magnitude in typical size: pretraining largest, mid-training a thin aligned slice, post-training scoped per skill.

This has a practical implication for planning: a team should not expect one collection or one hour budget to serve all three stages. A pretraining collection optimized for broad coverage of scenes, tasks and people looks different from a mid-training collection optimized for tight embodiment alignment between matched human and robot viewpoints, which in turn looks different from a post-training collection scoped to a narrow set of skills a specific policy needs to learn. Planning each stage against its own goal, rather than one aggregate hour target, is what keeps a data budget from being spent in the wrong place.

That distinction also affects who reviews the data. Pretraining footage is typically reviewed for breadth — does it cover the intended scenes, tasks, objects and people — while mid-training footage is reviewed for alignment quality between the matched human and robot recordings, and post-training footage is reviewed against the specific skill a policy is being trained on. Using the same review checklist for all three stages tends to under-scrutinize the property each stage actually depends on.

• Write a spec that lists target scenes, tasks, objects and people before setting an hour target
• Run a pilot collection to validate calibration, sync and label quality before scaling volume
• Scale the pilot once quality is confirmed, adding hours into underrepresented cells first
• Re-evaluate coverage against the spec periodically rather than tracking a single running hour count

This mirrors the same pilot-then-scale approach used for the general validated-hours guidance on this site: start with a tightly scoped pilot, evaluate, then expand only where the evaluation shows thin coverage.

A pilot also surfaces problems cheaply that would be expensive to discover after scaling. Calibration drift, unsynchronized streams, or a labeling gap on hand-pose data are each straightforward to fix in a few hundred hours and expensive to fix retroactively across tens of thousands. Sizing a pilot to validate the capture spec, not just to produce a usable first slice of data, is what makes the subsequent scale-up predictable rather than a source of rework.

It also helps to decide upfront how coverage will be tracked. A running hour total answers "how much did we record" but not "what is still missing." Tracking coverage against the written spec — which scene, task, object and person cells are filled and which are thin — turns the pilot-then-scale loop into something that closes gaps in a predictable order instead of adding hours wherever collection happens to be easiest.

The same coverage tracking makes it easier to communicate progress to stakeholders outside the data team, since "62 of 80 planned scene-task cells are filled" is a clearer signal of readiness than a raw hour count that says nothing about what remains uncovered.

A common mistake is treating the published hour counts above as targets to match rather than as reference points for scale. EgoScale, GEN-0, EgoVerse and Egocentric-10K were each built for a specific model and research goal; the right size for a given team's pretraining collection depends on that team's target embodiment, task set, and evaluation results, not on matching someone else's published total.