Fleet compute

Smarter robots keep a bigger brain on the floor.

Deploy frontier models, one hop from every robot. That's how fleets graduate from demos.

Backed by & building with

Why the floor
On the robot Too small for a frontier model.
or
In the cloud Too far for the loop's tail.
or
On the floor Big enough, one hop away.
Why believe it
5-33 ms
the action loop's budget.
A region away, the tail misses it.
control-loop physics · 30-200 Hz loops
99.96%
actions on time, one pool, 32 robots.
0% without a scheduler.
NVIDIA Research + Stanford, ROSA · 8× H200 · their numbers, not ours yet
The whole argument, with the diagramWhy the brain belongs on the floorThe full argument, the published pattern, and the diagram.Read the long page
What we run for you

Bring your models. Connect your fleet. We run the pool.

Inside the node on your floor · on your LAN
Hardware

The Box

The GPUs on your floor. Sized in robots, not chips, with headroom to grow.

Software · operator console

The Console

The screen you run it from. The architecture NVIDIA Research and Stanford published, reproduced on our rig. Try it in the sandbox.

Software · reliability loop

The Brain

The loop that keeps the pool dependable. Fuses GPU, power, cooling, network and workload signals; holds tail latency in band.

Procure

Opex only.

Reliability

24/7 ops, run for you.

Capacity

Headroom from day one.

Staffing

Your team builds robots.

Data sovereignty

Your data stays on your floor.

Workload data - payloads, prompts, logs - never leaves your network.

Only operational telemetry goes out; only managed updates come in. Never your data, never models learned from your fleet.

How it starts

Start in the sandbox.

Twenty minutes in the operator console, the one that runs on the box, on seeded telemetry. Set up a fleet, run the dry-run, break it.

01

The sandbox

One link, your name on every screen. Pick the picking-cell template or describe your own cell in a sentence, run the dry-run against your declared fleet, and take the session record with you.

by invitethe console that runs the boxnumbers from real GPU runs
FAQ

Questions fleet operators ask

Shared, on-site AI compute that serves a whole fleet's real-time inference from one pool - close enough for the control loop, big enough for the model. Instead of a GPU sized for each robot's peak, one pooled Box on your floor serves every agent and trains between shifts. Nectar delivers and operates it as a service.

Tight control loops run 30-200 Hz - a 5-33 ms budget. Practical cloud round-trips measure 50-150 ms: outside the loop, before egress cost. The Box keeps inference and data on-site.

Neither. The Box serves the inference your stack calls; your agent control and orchestration stay yours, with a safe fallback if the Box is unavailable. Reflexes stay on the robot - ~100 Hz local control and safety fallback - while the fleet's heavy models run from the pool.

Exactly - the serving pattern is public, and we embed it rather than reinvent it. What you pay for is what doesn't commoditize: the Box on your floor, the reliability loop underneath it - thermal, power, network, failure, everything the pattern assumes stable - and the operation: install, monitoring, 24/7 NOC, and hardware refresh on our clock.

More questions - deployment, hardware, data, the sandbox - are answered on the long page. Still weighing it? The sandbox is non-binding - start there.

Ask for a link

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.

Non-binding. We reply within one business day.

We use your details only to respond and coordinate - we don't sell or share them. Privacy.