DGX Spark driver and firmware updates: what GPUwerk manages

A rented Spark splits cleanly into two zones: the node GPUwerk operates, and the container you get root on. This page draws that line for drivers, firmware and CUDA specifically, since it's the question that comes up once you're past "will it fit" and into "who keeps this working."

The root-container model this rests on

Every GPUwerk instance gives you root over SSH, landing in /workspace on a container running on a dedicated node, per GPUwerk's SSH keys documentation. /workspace is what survives a stop, and anything you install elsewhere in the container's filesystem lives only until a rebuild. That root-and-container split is also the split for maintenance responsibility: GPUwerk operates the machine underneath the container, you operate everything inside it.

What GPUwerk manages: the host

Below your container sits the node itself: DGX OS 7 on Ubuntu 24.04, per the hardware page's spec panel, the host-level NVIDIA driver that talks to the GB10 hardware, and whatever firmware keeps the machine and its GPU passthrough into your container functional. Keeping that layer patched and working is GPUwerk's job as the operator of the fleet, the same way a datacenter operator is responsible for the rack power and networking under a rented server. You don't see this layer and don't need to touch it; it's what makes the machine boot and expose a working GPU to whatever you run inside your container.

What's yours: everything inside the container

The hardware page already notes the base image ships with "full stack preinstalled" CUDA, which gets you to a working starting point on day one. From the moment you're in as root, though, the CUDA toolkit version, any userspace ML libraries, Python environment, and inference engine you run (vLLM, llama.cpp, whatever else) are entirely under your control and entirely your responsibility to manage. GPUwerk does not push updates into a running container, does not upgrade your CUDA toolkit for you, and does not touch anything you've installed. If a specific vLLM release needs a newer CUDA toolkit than the base image shipped with, that's an upgrade you make yourself, the same as you would on any server where you hold root.

This cuts both ways. It means nobody overwrites your working setup without warning. It also means nobody is watching for CVEs in whatever you've installed inside the container, or nudging you to update a driver-adjacent library that's fallen behind. That's the tradeoff of root access: full control, and full responsibility for what you do with it.

Why this split, not a fully managed stack

A fully managed CUDA stack that GPUwerk silently updated underneath you would break workloads pinned to a specific toolkit version, exactly the kind of surprise a benchmark, a fine-tuning run, or a production inference server can't tolerate. Root access over your own container is what makes a rented Spark behave like the hardware you'd own yourself, per the "try before you buy... same hardware, root over SSH" framing in GPUwerk's setup guide, rather than a locked-down managed service with someone else's update schedule.

Practical checklist

• Host driver and firmware: GPUwerk's job. You don't manage it, and it isn't exposed for you to change.
• CUDA toolkit inside your container: ships with the base image, yours to upgrade or pin from that point on.
• Inference engine and Python environment: entirely yours; install, pin, and update on your own schedule.
• Anything outside /workspace: gone on a rebuild regardless of who set it up, so treat your CUDA and environment setup as reproducible (a setup script, a Dockerfile) rather than a one-off manual install if you want it to survive.

If you'd rather not own the driver-and-CUDA question at all, GPUwerk's on-premise option includes an optional managed-service tier covering updates and support on hardware in your own office, per the pricing page's FAQ; a rented cloud instance keeps the split described above.