# Does Remote GPU Serving Actually Work for Multi-Robot VLA Fleets?

**Up to 18% throughput improvement** — that's the headline result from Armory, a new batched policy-serving system designed to offload [Vision-Language-Action model](https://humanoidintel.ai/glossary/vision-language-action-model) inference from constrained on-device hardware to a centralized remote GPU. Published August 4, 2026 by researchers Rohan Bansal, David He, Nadun Ranawaka Arachchige, Zhenyang Chen, Soobum Kim, Kexin Rong, and Danfei Xu, the paper formalizes a problem that every humanoid operator scaling beyond a handful of units will eventually face: how do you serve a single powerful policy model to a heterogeneous fleet without starving robots of timely action commands?

The core finding is both technically precise and commercially significant. Naive batching strategies — the kind borrowed directly from LLM serving infrastructure — work adequately when every robot in the fleet consumes action chunks at the same rate. The moment that homogeneity breaks down (different robot morphologies, variable task loads, uneven network conditions), conventional batching introduces dangerous timing mismatches with closed-loop control requirements. Armory addresses this with a scheduling algorithm purpose-built for the heterogeneous consumption rates that characterize real deployments.

The paper validates Armory on both simulated and real robot fleets, grounding the 18% throughput claim in physical hardware experiments rather than simulation-only benchmarks.

---

## The Problem Nobody Has Formally Solved Until Now

The humanoid robotics industry has spent the last two years debating whether [Physical Intelligence (π)](https://humanoidintel.ai/companies/physical-intelligence), [Skild AI](https://humanoidintel.ai/companies/skild-ai), and similar foundation model providers should run inference on the edge or in the cloud. What's been missing from that debate is a rigorous treatment of the scheduling layer sitting between the two.

VLA and other robot foundation models are computationally demanding by design — they process visual observations, language instructions, and proprioceptive state to output action sequences. Fitting that workload on-device means accepting severe power and space constraints that compound at scale. A humanoid designed to operate in a warehouse or manufacturing environment can't carry a data-center-class GPU. The natural architectural answer is remote inference, but that immediately creates a new class of problems that traditional cloud serving infrastructure wasn't designed to handle.

The key insight in this paper is the concept of **action chunk consumption heterogeneity**. In standard LLM serving, all clients consume tokens at roughly comparable rates — the serving system can batch requests with relatively uniform assumptions. Robot policy serving is structurally different: one robot executing a slow manipulation task might hold an action chunk for several seconds, while another running a faster locomotion primitive burns through the same chunk in a fraction of that time. Standard batching that ignores this heterogeneity either over-serves slow consumers (wasting GPU cycles) or under-serves fast consumers (introducing control lag that can cascade into task failure).

This isn't a theoretical concern. It's the exact failure mode that will emerge when operators like [Agility Robotics](https://humanoidintel.ai/companies/agility-robotics) or [Figure AI](https://humanoidintel.ai/companies/figure-ai) attempt to run mixed fleets — some units doing [dexterous manipulation](https://humanoidintel.ai/glossary/dexterous-manipulation), others doing logistics locomotion — off a shared inference server.

---

## What Armory Actually Does

The paper introduces Armory as a serving system that reframes multi-robot policy deployment as a scheduling problem with explicit heterogeneity awareness. Rather than treating all robots in a batch as equivalent consumers, Armory's scheduling algorithm accounts for differing action chunk consumption rates across the fleet and optimizes batch composition and timing accordingly.

The authors validate the system in two settings:
- **Simulated robot fleets**, used for controlled experiments across scheduling heuristics
- **Real robot hardware**, where the 18% throughput improvement over naive scheduling is measured

The paper explicitly notes that naive heuristics perform "well" when all robots are identical — which is a useful calibration point. If your deployment is a perfectly homogeneous fleet doing a single task type, you may not need Armory's full scheduling machinery. The value proposition sharpens as fleet heterogeneity increases, which is precisely the direction the industry is heading.

What the paper does not provide — at least in the abstract — is a breakdown of latency percentile improvements, the specific robot platforms used in real experiments, or how Armory's performance degrades under network jitter and varying GPU availability. These are meaningful open questions for operators evaluating whether to build on this approach.

---

## Industry Implications: Inference as Infrastructure

The deeper significance of this work isn't the 18% number — it's the formalization of a problem category. As humanoid fleets scale from dozens to hundreds of units, the compute architecture question becomes as critical as the mechanical design question. 

Remote GPU serving introduces a dependency on network reliability and inference latency that on-device compute doesn't have. But on-device compute at the power levels required for capable VLA inference isn't viable in most current form factors. The industry needs a middle path, and that middle path runs through exactly the kind of scheduling infrastructure Armory represents.

For [Physical AI](https://humanoidintel.ai/glossary/physical-ai) companies building the software stack — whether that's Pi, Skild, or internal teams at hardware manufacturers — this paper establishes a concrete baseline and a formal problem framing they can build on. The sim-to-real transfer challenge for scheduling algorithms is notably different from the sim-to-real challenge for motor control policies, but it's no less real: a scheduler that works in simulation needs to account for production network variance, GPU preemption, and real-world task timing noise.

The authors' decision to test on real hardware before publishing is meaningful given how many inference optimization papers claim results that evaporate outside the simulator. The 18% improvement figure comes from physical experiments, which gives it practical credibility even absent full replication.

---

## Key Takeaways

- **Armory** is a new batched policy-serving system that offloads VLA inference from constrained on-device compute to a remote GPU, validated on both simulated and real robot fleets
- **Up to 18% throughput improvement** over naive scheduling was measured in real-world experiments — the gain comes from explicitly modeling heterogeneous action chunk consumption rates across robots
- **Naive batching works for homogeneous fleets** but fails when robots consume action chunks at different rates, creating a fundamental mismatch with closed-loop control timing requirements
- **The paper formalizes remote policy serving as a scheduling problem**, a framing the industry needed but hadn't formally established
- **The key constraint** driving this work is that on-device compute for powerful VLA models is bounded by power and space — remote inference is architecturally inevitable at fleet scale
- **Open questions** include latency percentile behavior under network variance, performance on specific robot platforms, and graceful degradation under GPU contention

---

## Frequently Asked Questions

**What is action chunk scheduling in robot policy serving?**
Action chunk scheduling refers to how a centralized inference server assigns computation time and batches inference requests across multiple robots, each of which consumes policy outputs (action chunks) at different rates. Armory introduces a scheduling algorithm that accounts for this heterogeneity to improve overall fleet throughput.

**Why can't humanoid robots just run VLA models on-device?**
VLA and other robot foundation models require significant GPU compute. On-device hardware in humanoid robots is constrained by power budgets and physical space, making it impractical to run large foundation models locally. Remote GPU serving is the natural architectural response, but it introduces new latency and scheduling challenges.

**How much does Armory improve throughput over baseline scheduling?**
The paper reports up to 18% throughput improvement in real-world experiments compared to naive scheduling heuristics. The gain is most pronounced when the robot fleet is heterogeneous — i.e., different robots consuming action chunks at different rates.

**Does naive batching work at all for robot fleets?**
According to the paper, naive scheduling heuristics perform well when all robots in the fleet are identical and consuming action chunks at the same rate. The performance gap with Armory emerges specifically in heterogeneous fleet scenarios.

**What companies are most affected by remote VLA serving challenges?**
Any operator running multi-robot humanoid fleets at scale — including companies deploying general-purpose humanoids in logistics, manufacturing, or warehousing — faces this challenge. AI stack providers building shared inference infrastructure for humanoid fleets are the most direct audience for this research.