Test and port your software on a real GB10: aarch64, CUDA, sm_121

An issue says your library fails on a DGX Spark, and you don't own one. Or your wheels build on x86 and nobody has tried them on an Arm CPU with a Blackwell GPU. Rent a whole Spark for the minutes it takes to find out: a root shell on an NVIDIA GB10 (aarch64, CUDA compute capability 12.1) with the CUDA 13.0 toolkit installed. At $0.79 an hour, billed per minute, a 20-minute check costs about $0.26.

First top-up: pay $20, get $30 in credit. Billed per minute from prepaid credit. Terminate when you're done and billing ends. Most people who rent a Spark from me start the plain DGX OS image and bring their own stack, which is what this page is about.

What you get

The image called DGX OS 7 in the console is my build: Ubuntu 24.04 plus the packages above, in a container. It is not NVIDIA's DGX OS installer image, and /etc/dgx-release says so. What runs in a container, and what doesn't, is in the tenant environment notes.

A first check in five minutes

Deploy DGX Spark 1× with the DGX OS image, wait for running, and click Open terminal in browser on the instance page. Then confirm what you are on:

uname -m                                    # aarch64
nvidia-smi --query-gpu=name,compute_cap,driver_version --format=csv
nvcc --version | tail -n 2                  # CUDA 13.0

python3 -m venv /workspace/venv && . /workspace/venv/bin/activate
pip install torch --index-url https://download.pytorch.org/whl/cu130
python -c "import torch; print(torch.cuda.get_device_name(0), torch.cuda.get_device_capability(0))"

The last line prints the GB10 and (12, 1). Some PyTorch builds print a warning that sm_121 is not compatible; it is usually wrong, and the PyTorch on a DGX Spark guide explains why and which wheel to pick.

Build and test your project

cd /workspace
git clone https://github.com/your-org/your-project.git
cd your-project
pip install -e '.[test]'           # or your own build step
pytest -x -q
pip wheel . --no-deps -w dist/     # an aarch64 wheel to take home

Three things catch people out on this chip:

• Name the architecture. For your own CUDA code, compile with -gencode=arch=compute_121a,code=sm_121a, or -DCMAKE_CUDA_ARCHITECTURES=121a-real in CMake. The -arch=sm_121a shorthand can drop the "a" and with it the FP4 instructions, as an NVIDIA forum thread found (details in the TFLOPS guide). A build for another architecture can compile cleanly and then run badly.
• Expect source builds. Many aarch64 and sm_121 packages ship no wheel, so pip compiles them. Cap the parallel jobs (MAX_JOBS=4) so a large build does not run the 128 GB out of memory.
• Kernels for other Blackwell chips do not all carry over. sm_121 runs code built for sm_120, but kernels written for datacenter Blackwell (sm_100) do not, and some FP4 paths have run without errors and produced wrong output. Check results, not only that it ran.

To take build artefacts home, copy them with your own SSH key, then terminate:

# on your laptop
scp 'root@<name>.gpuwerk.com:/workspace/your-project/dist/*.whl' .

Scripted runs from your own CI

There is no ready-made CI integration. What there is: an API that deploys and terminates by the minute, so a job on your own runner can borrow a Spark, run its tests over SSH and give it back. Use an API key with the instances scope.

curl -s -X POST https://api.gpuwerk.com/v1/instances \
  -H "Authorization: Bearer $GPUWERK_TOKEN" -H "Content-Type: application/json" \
  -d '{"type":"spark-1x","image":"ubuntu"}'
# wait for status "running" in GET /v1/instances, run the job over SSH, then:
curl -s -X DELETE https://api.gpuwerk.com/v1/instances/<id> \
  -H "Authorization: Bearer $GPUWERK_TOKEN"     # billing ends, workspace deleted

A deploy needs credit for at least one hour (402 otherwise), and returns 409 when no machine is free, so your job has to handle that. API deploys go to a machine in the EEA unless you set location_country or partner_region. All fields are in the API reference.

What a check costs

Billing is per minute from prepaid credit and starts once the instance passes its readiness check. The account needs credit for one hour to deploy. First top-up: pay $20, get $30 in credit, about 37 hours on one Spark. A stopped instance keeps its workspace and is billed at 75% of the hourly rate; terminate it when you're done and billing ends, which deletes the workspace. Prices exclude VAT where applicable.

What a rented GB10 cannot tell you

• It is a container, not bare metal. You cannot load kernel modules or change the driver, and the driver version is whatever the host runs. Driver regressions are out of reach here.
• No Docker inside. There is no Docker daemon or socket, so docker build and docker run do not work. Build images elsewhere and test the binaries here.
• One chip. Passing on GB10 says nothing about Grace Hopper (sm_90), datacenter Blackwell (sm_100) or Jetson. Other makers' GB10 machines share the chip but can differ in firmware.
• No systemd and no NET_ADMIN. Start services from a shell, tmux or the startup hook; VPN clients and custom iptables rules do not run.
• No SLA and no backups. Copy anything you need off the machine before you terminate.

Where the Sparks are

This works on every location, because partner Sparks offer the same DGX OS and Ubuntu images. My own Sparks are in a datacenter in Hradec Králové, Czech Republic. Partner Sparks are owned and hosted by partners at their own premises in the USA, Sweden, the Netherlands, Slovakia and Hong Kong, and a partner has physical access to their machine. The console shows the country, and whether it is in the EEA, before you deploy.

Who runs this

GPUwerk is a new platform, and I'm the person behind it: Samuel Seidel, founder, operating as PRINT IT! SE, registered in Prague. Since September 2026, 94 developers have started 374 instances on it (as of 9 November 2026). Uptime and incidents are on status.gpuwerk.com. If you are not sure your stack will run, write to me through the contact page before you pay; I answer myself.

FAQ