Spark DGX Alpamayo + Alpasim

Spark DGX (GB10): Alpamayo + AlpaSim deployment friction

I’m running a Spark DGX (GB10) and trying to get Alpamayo + AlpaSim running locally. After many hours, I can get parts working, but the overall experience feels misaligned with Spark’s single-node architecture.

Specifically:
• Are there recommended NGC container versions for Spark DGX?
• Any guidance on disabling multi-node / DGX-scale assumptions?
• Is AlpaSim officially supported on Spark yet, or still DGX-centric?

The hardware is excellent—I’m just trying to understand the intended deployment path for Spark users today.

The Alpamayo is up and running on my DGX Spark!

Your insight to my questions would be appreciated.

Subject: SOLVED: Architecture mismatch (ARM vs. x86) & Hybrid Solution

An update for anyone else hitting this friction on the Spark (GB10):

I managed to get the full loop running, but the answer to my question regarding AlpaSim support is effectively “No”—at least not locally.

The Root Cause: The friction was the architecture mismatch. The DGX Spark (Grace Blackwell) is ARM-based, while AlpaSim currently requires an x86 environment for its physics and rendering pipelines.

The Solution (Hybrid Architecture): Instead of trying to force everything onto the single node, I split the stack:

  • Local (DGX Spark): Hosting the Alpamayo VLA model (Inference/Reasoning).
  • Cloud (x86 Instance): Hosting AlpaSim (Physics/Rendering).
  • Transport: Connected via SSH reverse tunnel passing gRPC commands.

It’s up and running now. The VLA reasons locally and streams controls to the simulation in the cloud. Latency is manageable for testing reasoning traces, though tight control loops are obviously harder over the network.

It’s up and running but I’ve documented what I think is a bug.