Join the foundation and contribute to the future of robotic infrastructure & protocols
Apply today
Originally published by NuNet on 4 May 2026. Full essay reproduced below.
Greetings NuNetopians,
The robot doesn’t care where the cloud is. It needs an answer now.
A drone making collision avoidance decisions needs a response in 10 to 30 milliseconds. A cloud round-trip adds 50 to 200ms. For a robot moving at speed, that gap is the difference between adjusting course and hitting a wall.
This isn’t a theoretical problem. As AI moves off screens and into physical machines (robots, autonomous vehicles, smart buildings, factory floors), the entire compute model that worked for chatbots and image generators starts to fall apart. Physical AI can’t tolerate the latency, connectivity assumptions, or single points of failure that centralized cloud infrastructure depends on.
And the industry knows it. Jensen Huang called it at CES 2026: “The ChatGPT moment for physical AI is here.” Deloitte named multiagent systems a top 2026 trend. Arm is building an entire platform around physical and edge AI. The shift from cloud-first to edge-first AI is no longer a prediction. It’s happening.
The question is: what does the compute infrastructure for this actually look like?
Cloud computing was designed for request-response workloads. A user sends a query, a server processes it, a result comes back. Latency is annoying but not dangerous. If a response takes 500ms instead of 200ms, nobody crashes.
Robots operate differently. They run continuous perception-action loops. A warehouse robot scanning for obstacles, a drone adjusting flight path, an energy management system rebalancing loads across a building, all of these need compute decisions in real time, often without reliable internet connectivity.
Three specific problems make centralized cloud a poor fit:
Latency is a dealbreaker, not a nuisance. Real-time robot coordination (think drone swarms, factory floors, delivery fleets) requires decisions in single-digit milliseconds. Edge AI collapses this latency by keeping intelligence on or near the device. A centralized controller adds unacceptable delay and creates a single point of failure. If the connection drops, the robot goes blind.
Swarms need peer-to-peer coordination. A fleet of robots can’t depend on one central server to tell each machine what to do. If that server goes down (or gets jammed, or loses connectivity), the entire system stops. Research shows that distributed systems using peer-to-peer coordination achieve 41.6% accuracy improvements over centralized setups while running on commodity hardware. But the coordination overhead is the hard part. Managing state and consensus across hundreds of agents is harder than deploying them individually.
The hardware is wildly mixed. A real robot deployment might combine embedded GPUs on the robot itself, Raspberry Pi-class edge devices nearby, an on-premise server for heavier inference, and cloud burst capacity for training. Mixture-of-experts routing across this kind of heterogeneous stack can improve battery life 3 to 5x and learning convergence 5 to 10x. But it requires an orchestration layer that understands what each piece of hardware can do and routes workloads accordingly.
Here’s what’s interesting: most of the conversation about AI infrastructure for robotics focuses on getting more GPUs. More VRAM, more FLOPS, more capacity. And GPUs matter, obviously.
But Intel’s own research tells a different story. Their recent white paper on CPU-to-GPU ratios found that in production AI inference pipelines, CPUs handle 85 to 100% of the pipeline stages before anything touches a GPU. Data loading, batching, scheduling, orchestration. The CPU is the bottleneck, not the GPU. And as agentic AI workloads scale (robots being a prime example), that ratio keeps climbing.
The missing piece for physical AI isn’t raw compute power. It’s the coordination layer: the system that decides which machine runs which task, handles failures when a node goes offline, moves workloads when a robot relocates, and settles payments between machine owners who don’t know each other.
This is orchestration. And for distributed, multi-owner, mixed-hardware environments like robotics, it doesn’t exist in traditional cloud infrastructure.
NuNet is a peer-to-peer protocol for discovering, orchestrating, and settling compute across distributed infrastructure. Think of it like what internet protocols did for independent networks: NuNet connects independent compute resources (GPUs, CPUs, edge devices, full machines) into a system where workloads can find and use the right hardware automatically.
For robotics specifically, several capabilities map directly to the problems described above:
Edge-to-cloud span. NuNet works across any device, from a Raspberry Pi running a robot’s local perception to a GPU server handling heavier inference. The protocol is hardware-agnostic and designed for intermittent connectivity, which is the reality of any physical deployment.
Workloads find compute autonomously. In NuNet, the software itself discovers available resources and routes tasks to them. A robot running object detection locally can offload face recognition to a nearby GPU node through NuNet’s ensemble orchestration, with local network latency around 10ms versus 800 to 2400ms for a cloud round-trip.
Multi-owner coordination. This is the hard problem that most infrastructure projects skip entirely. In a real-world deployment (say, robots operating across multiple buildings owned by different companies), you need compute sharing with access control, accountability, and payment settlement between organizations that don’t share infrastructure. NuNet’s protocol handles discovery, orchestration, and economic settlement across trust boundaries.
Machine-to-machine payments. Every compute transaction between devices settles through NTX, NuNet’s utility token. A robot that offloads inference to a nearby compute node can pay for that service automatically, creating the economic layer that makes multi-owner compute sharing viable.
NuNet’s partnerships in physical AI aren’t hypothetical.
The Homepute369 project (with AL’MA, a billion-euro European construction partner) has completed a Proof of Concept validating that energy AI agents can run directly on edge hardware like Raspberry Pis, coordinated through NuNet’s orchestration layer. The agents handle real-time energy optimization (solar, battery, EV chargers, smart meters) without centralized cloud dependency. Next phase: physical hardware deployment in newly built housing units with an NVIDIA-certified partner. The architecture that works for smart buildings is the same architecture that works for robot fleets.
The Auki/Posemesh partnership targets decentralized machine perception for AR, robotics, and spatial AI. Robots operating in shared spaces need shared intelligence, pooled compute, and dynamic workload offloading. NuNet deploys and orchestrates Posemesh perception nodes across environments.
NuNet is also building a robotics demo internally: a hexapod robot running on a Raspberry Pi 5 that does local lightweight detection but offloads heavier AI inference (face recognition, scene description via vision-language models) to a nearby GPU machine through NuNet’s ensemble orchestration. The dashboard shows task routing and latency comparisons in real time.
The emerging consensus across CES presentations, industry reports, and builder communities points to the same set of requirements for robotics AI infrastructure:
These aren’t nice-to-haves. They’re the minimum viable infrastructure for physical AI at scale. And they’re exactly the capabilities that NuNet’s protocol was designed around.
The cloud worked for the era of AI that lived on screens. The next era of AI lives in buildings, on factory floors, inside vehicles, and on robots. The infrastructure has to meet it there.
