Nectar
Why the brain belongs on the floor
The argument behind the homepage, for the reader who wants the paper. Why the model won't fit on the robot, why the tail won't fit in the cloud, what NVIDIA Research and Stanford measured when a fleet shares one pool, and the questions the homepage raises but doesn't answer. Written for you if you run a fleet on a floor, or you build the robots that have to survive one.
Back to the homepageThe model doesn't fit. And when it does, it idles.
- Too small for the model. Robot-grade silicon carries the reflexes. The planning and reasoning models that make a robot general outgrew it, and they keep growing.
- Idle when it fits. A GPU on a robot waits on that robot's control loop; one robot can't batch. Most of it sits unused.
- Bought for peak. Every robot sized for its own worst case, times the fleet.
The average makes it. The tail doesn't.
- A fleet is judged at p99, not at the median. A robotics cloud can shorten the average round trip. It can't bound the slowest one across a WAN and your Wi-Fi, and the slowest one is the one that stops a robot.
- Every frame leaves the building. Cloud inference streams the camera feed off-site, every robot, every shift, before a single training byte moves.
- Renting only wins below the shift. On-demand fits a lab that runs a policy a few hours a day. A two-shift floor runs sixteen. Above roughly three hours a day per GPU-equivalent, owning the compute is cheaper than renting it.
Same pool. The only question is how many hops away it sits.
One pool. The whole pipeline. Every agent.
NVIDIA Research + Stanford published ROSA (2026) - a fleet of robots sharing one server-class GPU pool, an SLO-aware scheduler routing every agent's full RFM pipeline, every action qualified against its latency budget.
Abstraction of ROSA, Figure 2 - system overview
one shared pool vs a GPU per robot
32 robots, one pool
same fleet, split or dedicated GPUs
ROSA · NVIDIA Research + Stanford · 8× H200, GR00T N1.6 · arXiv:2607.01088
What the paper measured · not our numbers yet
Bring your models. Connect your fleet. We run the pool.
The Box is the GPUs on your floor, sized in robots, not chips. The Console is the screen you run it from: the fleet-serving pipeline the published pattern describes - declare your fleet, dry-run the schedule against every model's latency budget, watch what runs where. The Brain is the loop that keeps the pool dependable. Installed and run for you; the detail is on the homepage.
The questions the homepage raises
What do you mean by a bigger brain?
The planning and reasoning models a robot can't carry. Robot-grade silicon runs the reflexes well; the models that make a robot general need server-class GPUs. Fleet compute puts those one hop away. It's a claim about where the model runs, not a claim that we make your model better.
What is a frontier model for a robot?
A robot foundation model, or several: an action model at tens of hertz, a planner and a safety check at a few hertz, a monitor watching the task. That pipeline is what the published pattern serves for a whole fleet, and what a single robot's compute can't hold.
Why not a robotics cloud?
For a lab iterating on a policy a few hours a day, you should; on-demand pricing fits bursty loads. Three things change on a production floor. Duty cycle: above roughly three hours a day per GPU-equivalent, owning the compute is cheaper than renting it, and a two-shift site runs sixteen. The tail: a robotics-tuned cloud can shorten the average round trip; it cannot bound p99 across a WAN plus your Wi-Fi, and a fleet SLO is written at p99. The data: cloud inference streams every camera frame off-site every shift; the Box keeps inference and the frames on your LAN. Same pool, one hop from the robot.
What's the Console, and how is it different from the Brain?
The Console is the screen you run the Box from: declare the fleet, dry-run the schedule against every model's latency budget, see what runs where. The Brain is the loop underneath it that keeps the pool dependable, fusing GPU, power, cooling, network and workload signals to hold tail latency in band. You can try the Console today in the sandbox. The Brain's numbers are proven on a live floor, not on a screen.
How does the Box deploy into our environment?
Two paths. K8s Join - the Box joins your existing control plane as a worker node via kubeadm or k3s-agent. Standalone - it runs alongside your stack with no cluster join. Either way, your workloads aren't re-platformed and your CI/CD runs as it stands.
You choose the Brain's access: a scoped-RBAC joined-cluster mode, or a read-only shadow mode with no cluster access at all. Security review starts there.
What hardware powers the Box?
Sized in robots, not chips: a Box serves your whole fleet's model set with every loop in budget and headroom to grow. Under the hood that's high-VRAM, server-class GPUs with reserved headroom so you can scale utilization without waiting on procurement. We describe the tier, not exact SKUs.
What happens when the GPUs go stale?
Refresh risk is ours, not yours. The silicon under your workload is matched to your workload's tier over its life, and upgrades happen on our side of the boundary - your fleet never waits on a procurement cycle.
Does our data leave the building?
No. Workload data - payloads, prompts, logs, frames - never leaves your network. Only operational telemetry goes out; only managed updates come in. Never your data, never models learned from your fleet.
What's in the sandbox, and is it real?
Twenty minutes in the operator console, the one that runs on the box, by invite. Set up a fleet, run the dry-run, break it. Nothing to install, nothing to sign. The console is real and the dry-run uses latency tables measured on real GPUs, but nothing is served while you are in it: the telemetry is seeded and no robot models run. A live-hardware tier follows the sandbox. Ask for a link below and we reply within a business day.
Ask for a sandbox link.
Twenty minutes, by invite. We read every request and reply within a business day.
- The console that runs the box.
- Seeded telemetry, numbers from real GPU runs.
- Your name on every screen.
- Non-binding.
- Your workload data never leaves your network.
Request received.
If a link is coming, it will come from Alex, within one business day.