Nectar
Why the brain belongs on the floor
Per-robot GPUs idle by design, the published pooling pattern, and what Nectar runs on top of it.
One model, one robot, one GPU doesn't scale.
- Idle by design. The GPU waits on the robot's control loop; one robot can't batch.
- Bought for peak. Every robot sized for its own worst case.
- Outgrown by the model. Robot-grade silicon trails server-grade - the planning models don't fit.
Provision the whole fleet this way and per-robot and naively-shared serving both collapse at scale: in ROSA's factory-scale benchmarks, SLO-met falls to 0% as the fleet grows.
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
The rest of the questions
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 Brain's access, too: a scoped-RBAC joined-cluster mode, or a read-only shadow mode with no cluster access at all.
Security review starts light: read-only shadow mode needs zero cluster access, and the security pack arrives before anything touches production.
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. Your workload data never leaves your LAN. What crosses the boundary is operational, both ways: health and performance telemetry plus Brain's own aggregate-derived model and policy updates go out to Nectar; managed software and policy updates and remote remediation come in from the NOC. Never your data, never models learned from your fleet.
How do we get started?
In the sandbox. Twenty minutes in the operator console, the one that runs on the box, on seeded telemetry - by invite. Set up a fleet, run the dry-run, break it. Nothing to install, nothing to sign. Ask for a link below and we reply within a business day.
Is the sandbox running on real hardware?
Not in this tier. The console is the one that runs on the box, 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. That is why it costs nothing and needs nothing installed. A live-hardware tier follows the sandbox.
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.