Scale Robot Intelligence With Customer Pilots—Not Superclusters

If you build robots for real customers, you have probably heard some version of this pitch: to make the AI good enough, you need a massive training cluster, a multi-hundred-million-dollar GPU bill, and a fundraising story that looks like a foundation-model lab. That path is real—for a very small number of companies.

For everyone else, it is the wrong race. Physical systems already run under hard power, thermal, latency, and cost constraints. The models that ship on vehicles and robots are typically far smaller than frontier chat LLMs. That is not a weakness. It is the opening for a capital-efficient strategy: start from strong open weights, fine-tune on real customer work, and—when you are ready—use federated learning so many sites improve the product together instead of restarting in isolation every time.

Pretrained open models get you to a pilot. Fine-tuning gets you to one customer's job. Federated learning turns every deployment into training that helps the next one—without shipping raw data to a central lake.

The wrong race: exclusive pretrain scale

Frontier text and multimodal labs still compete on enormous training runs. Accelerated compute and power are booked years out. That scarcity is structural. It favors hyperscalers and a handful of well-capitalized labs.

Robot companies that try to win the same way inherit the same bottlenecks: multi-year chip supply, giant cluster ops, and a fundraising narrative that crowds out robots, field reliability, and go-to-market. A few will pull it off. Most will burn runway on infrastructure that never becomes their moat.

The better question is not "How do we raise for a private Dojo?" It is:

How do we get better with every pilot without becoming a foundation-model lab?

Physical AI is edge-bound—and that is good news

Deployed physical AI is constrained by on-robot and on-vehicle compute. That is why many production and near-production stacks live in the roughly 1B–10B parameter band rather than multi-trillion-parameter chat models. Public reporting around Tesla's Full Self-Driving stack illustrates the pattern: the current "small" model is commonly described as on the order of ~1B parameters, with a larger ~10× / ~10B-class model discussed for a future unsupervised / Robotaxi-oriented step—not as proof that every company should copy Tesla's org chart, but as evidence that high-value physical models can stay edge-sized.

Safety claims around any production stack should be treated carefully: company metrics and independent critiques disagree on how large the gap vs human baselines really is. For robot builders, the strategic takeaway is simpler. Excellent real-world behavior does not require chat-scale parameter counts. Edge constraints force compact models—and compact models fit the GPUs your customers and field teams can actually operate.

Humanoids and mobile manipulators face similar budgets: limited power, heat, memory bandwidth, and cost. There is every reason to believe denser data on long-tail edge cases will keep improving competence without always requiring a step-function jump in model size. When size stays modest, overnight adaptation on docked hardware becomes realistic.

What already works: open bases and consumer-grade fine-tuning

You do not need to pretrain a foundation model from scratch to start creating customer value. The open ecosystem already provides strong starting points: vision-language-action and manipulation stacks, LeRobot-style tooling, Hugging Face examples, and community projects that demonstrate full pipelines—from data collection to fine-tune to evaluation—on accessible hardware. Open clothes-folding and household manipulation projects are useful not because laundry is your TAM, but because they prove the cost of entry: a small team can iterate on real robot tasks without a secret model or a national GPU cluster.

Parameter-efficient fine-tuning (LoRA, QLoRA, and related methods) is the practical bridge. Full fine-tunes of multi-billion-parameter models are possible but heavy. Adapters make it normal to start from an open checkpoint, adapt to a customer site on a single 24GB-class GPU or edge kit, and ship an improved policy without replaying a multi-million-dollar pretrain.

Think of a ladder, not a slogan about "gaming PCs forever":

Raise capital for robots, reliability, and go-to-market. Treat giant exclusive pretrain as optional, not as the default ticket to play.

Pilot hell: fine-tuning that never compounds

Most robot companies already fine-tune. The trap is isolation: open base → Customer A works → Customer B starts cold → repeat forever.

Each pilot burns engineering time. Lessons from mine site dust, hospital hallway clutter, or warehouse lighting rarely become a shared product asset—especially when raw video cannot leave the premises. You ship robots, but the intelligence product does not compound with revenue. That is the gap federated learning is built to close.

Federated learning: the multiplier on fine-tuning

Federated learning (FL) does not replace open bases or local fine-tuning. It boosts them. Devices (or robots, or site servers) train on local data and share model updates—gradients, adapters, weight deltas—not the raw sensor stream.

The historical proof of concept at consumer scale is familiar: Google introduced federated learning publicly in 2017 and applied it to Gboard on Android so keyboards could improve query suggestions and next-word prediction while keeping typing data on device. Classic ops constraints still apply and map cleanly to robots: learn when the device is powered, idle, and connected—for phones, often charging on Wi‑Fi; for robots, docked after a shift.

For companies building robots, that is the commercial punchline: customer-purchased robots become distributed compute and data. Incremental GPU hours after the sale improve the product for everyone in the cohort. You are not asking the Series A to fund a national training campus before you have ten happy sites.

Who should go first: aligned fleets, not "all competitors day one"

Cross-company open collaboration is a beautiful end state. Enterprise deals start simpler.

The natural first wedge is one robot manufacturer serving many customer sites—industrial cleaning fleets, mining and heavy equipment in harsh environments, multi-warehouse logistics cells. Those customers often share a KPI language: fewer injuries, less downtime, less damage, more throughput. When incentives align, the motivation to poison the shared model drops. You are not asking rivals to train one brain together on day one; you are letting your product learn across the deployments you already support.

Aligned incentives mitigate adversarial behavior. They do not erase it. Compromised units, spoofed clients, and Byzantine updates remain engineering problems. Design for opt-in cohorts, vertical separation, and release gates. Treat FL as a product capability with a threat model—not as magic trust.

When trust cannot be assumed

Healthcare, defense, and multi-vendor marketplaces will not accept "just trust the aggregator." That is where the developing stack of zero-knowledge proofs, attested compute, and blockchain-anchored provenance matters: prove that an update came from an authorized policy run on authorized data classes without revealing the data itself.

That layer is early. Do not wait for perfect cryptography to ship multi-site learning for your own fleet. Do design so verification can be added when the market demands it. That ladder—aligned OEM fleets first, verifiable FL where trust is scarce—is how you expand use cases without stalling the roadmap.

What this is not

Honesty keeps serious buyers in the room:

• Not "nobody ever needs centralized compute." Pretrain, distillation, simulation, and safety regression still benefit from solid central GPUs. The claim is that customer value and fleet learning need not wait on a supercluster monopoly.
• Not "skip evaluation." Federated updates still need offline eval, canaries, and rollback. Safety-critical robots cannot promote adapters on vibes.
• Not automatic cross-customer fusion. Contracts, competition, and data governance may keep cohorts private. FL still pays off inside one OEM's multi-site footprint.
• Not free lunch on non-IID data. Mine A is not warehouse B. Expect domain shift, personalization heads, and careful aggregation—solved problems in FL research, real work in product.

Where zk0.bot fits

zk0.bot is open infrastructure for that loop: federated coordination for robotics AI so nodes can train on local experience and contribute improvements without centralizing private data. It builds on mature pieces of the stack—Flower-style federated orchestration, PyTorch training, Dockerized node ops—and aims at the roadmap from practical multi-site learning toward verifiable updates.

If you want the origin story, meetups, and architecture walkthrough, see the companion insight Decentralized Robotics AI: Building zk0.bot. This piece is the commercial thesis for robot builders: how intelligence scales with pilots you can actually sell.

What robot companies should do this quarter

• Pick one vertical cohort (e.g. three customer sites with similar tasks) and define success metrics: interventions per hour, damage events, cycle time.
• Standardize on an open base + adapter format so every pilot produces compatible updates, not one-off notebooks.
• Budget idle compute on purpose—docked overnight training is a product feature, not an accident.
• Write the data story into the contract: what stays on-prem, what updates leave, who owns improved weights.
• Instrument for FL before you need it: per-site datasets, versioned adapters, eval suites. Federated aggregation is much easier when the plumbing already exists.

The companies that win physical AI will not all be the ones with the biggest training clusters. Many will be the ones whose robots learn from every shift their customers already paid for—and whose next pilot starts where the last ten left off.

Written by Ivelin Ivanov, founder of Pirin.ai and creator of zk0.bot. Draft for review—July 2026. FSD parameter counts and safety statistics are summarized from public reporting and company materials; treat them as illustrative of edge-model scale, not as formal benchmarks.