Platforms
Nerv officially targets NVIDIA GB-series unified-memory parts and nothing else. That is a design premise rather than a limitation: almost everything on this site is paid for by knowing what the machine is.
| Target | Arch | Machines | Memory |
|---|---|---|---|
GB10 | aarch64 | NVIDIA DGX Spark and GB10 workstations | unified |
GB20 | aarch64 | GB20-class laptops, as they ship | unified |
GB300 | aarch64 | GB300-class systems, as they ship | unified |
What unified memory changes
When the CPU and the GPU share one pool, device memory stops being a separate budget and starts being zero-sum against the page cache. That makes two ordinary situations into operating-system problems rather than application problems.
Reservation has to happen early. The GPU arena is taken on the kernel command line, before anything has had a chance to fragment memory. Its size is the one parameter that cannot be derived from first principles, so it ships with a measured default and an override.
A resident GPU process is what stops the next one starting. Order-9 allocations were observed going 0 → 248 → 0 across stopping and restarting a single server. Under axon application processes never create driver contexts at all, so the failure mode has nowhere to occur.
One source tree
The three targets differ in kernel configuration and CPU tuning and share everything else. Each is built from the same tree with a platform layer selected at build time.
Development happens on a separate build machine, never on the target. Other hardware — the x86_64 workstation Nerv is currently built and validated on, and WSL2 — is used during development and is not an official target. Nothing on this site should be read as a support claim for hardware that is not GB-series.