System

Nerv is a Linux distribution built from scratch on musl with LLVM. Every layer, from the C library and allocator to the kernel and the GPU driver, is built by Nerv for NVIDIA Grace Blackwell machines.

Your programs unmodified: games, terminals, compilers, models Nerv's tools axon · S2 · plexus · MAGI · seele · cage · geofront · nerv-install Userland, all musl systemd · fish · rpm and dnf5 · Mesa Zink · Wayland desktop musl the C library for everything Nerv ships umalloc its hardened malloc Linux, newest release with Nerv's energy model and memory patches NVIDIA open modules patched and signed Signed boot image per generation Secure Boot · TPM unlock · rollback GB10 · GB300 Arm CPU cores · Blackwell GPU · CPU and GPU sharing one memory glibc runtime shared libraries only, for software you install: CUDA toolkits pip wheels Fedora packages vendor binaries never a dependency of anything Nerv ships NVIDIA libraries glibc, held by one axon daemon and no other process

Two C libraries, one boundary

The base is musl 1.2.6: libc, init, the shell, the system tools, the editors, the package manager and the compiler. A second, glibc runtime sits beside it as shared libraries only, for software you install yourself: CUDA, vendor binaries, pip wheels, Fedora packages.

No container or chroot separates them. Every ELF names its own interpreter in PT_INTERP, and the kernel loads the right one, so the boundary is a linking boundary: a musl program can exec a glibc one and the other way round. The rule runs in one direction and CI enforces it. Nothing Nerv ships links glibc, and the glibc runtime is never a dependency of a Nerv package.

everything Nerv ships PT_INTERP /lib/ld-musl-aarch64.so.1 software you install PT_INTERP /lib/ld-linux-aarch64.so.1 kernel execve reads PT_INTERP, starts that loader musl the base umalloc its malloc glibc runtime shared libraries only, optional exec either way

umalloc, the allocator

Nerv ships with umalloc, a forked version of mimalloc in its most hardened mode and with a number of additional modifications, all built into the C library rather than linked by programs that opt in. Normally this sort of security hardening costs performance, but on Nerv it's practically free. Programs get guard pages and randomised placement, CPU-accelerated pointer authentication (PAC) keyed on each slot's own address, and more.

Measured against glibc 2.39 and mozjemalloc, the allocator Firefox ships with everywhere else:

Performance

Firefox JetStream 3 higher is better

umalloc183.7
glibc 2.39186.1
mozjemalloc186.1

Mixed sizes and lifetimes higher is better

umalloc30 M ops/s
glibc 2.3920.0 M ops/s
mozjemalloc5.9 M ops/s

16 processes at once higher is better

umalloc258 M ops/s
glibc 2.39125 M ops/s
mozjemalloc190 M ops/s

Firefox memory during Speedometer lower is better

umalloc1553 MiB
glibc 2.391910 MiB
mozjemalloc1609 MiB

Security, 33 heap attacks

Attacks detected higher is better

umalloc17
glibc 2.3913
mozjemalloc10

Attacks that succeeded lower is better

umalloc1
glibc 2.398
mozjemalloc3

Heap address entropy higher is better

umalloc33 bits
glibc 2.3935 bits
mozjemalloc30 bits

S2, the inference engine

S2 talks to the CUDA driver API and nothing above it: no cudart, no cuBLAS, no nvcc. Its kernels come from its own PTX generator, written in Rust. A model is two files: the weights, stored in the order the kernels read them, and a plan holding every allocation, every kernel as a cubin and every step's launches. At load, S2 captures each step as a CUDA graph, which takes under a second for all 128 steps. A model is serving 10 seconds after S2 starts, where vLLM takes 7 minutes.

The KV cache is paged from one pool, 64 positions to a page, out to a 262,144-token context. Finished sessions are kept as snapshots a new request can resume from. Speculative decoding uses block drafters, with acceptance decided on the GPU. At 64 concurrent sessions S2 serves 566 tokens per second, 1.7× vLLM and 7× llama.cpp. A single user gets 57, twice what Atlas and vLLM reach with MTP speculative decoding.

Prefill, tokens per second 8k prompt S2 S2, 8k prompt: 2,840 tok/s 2,840 vLLM NVFP4 vLLM NVFP4, 8k prompt: 2,293 tok/s 2,293 Atlas Atlas, 8k prompt: 877 tok/s 877 llama.cpp llama.cpp, 8k prompt: 791 tok/s 791 32k prompt S2 S2, 32k prompt: 2,412 tok/s 2,412 vLLM NVFP4 vLLM NVFP4, 32k prompt: 1,981 tok/s 1,981 Atlas Atlas, 32k prompt: 766 tok/s 766 llama.cpp llama.cpp, 32k prompt: 756 tok/s 756 131k prompt S2 S2, 131k prompt: 1,390 tok/s 1,390 vLLM NVFP4 vLLM NVFP4, 131k prompt: 1,190 tok/s 1,190 Atlas no result llama.cpp no result Decode, tokens per second 1 session S2 S2, 1 session: 57 tok/s 57 vLLM NVFP4 vLLM NVFP4 with MTP, 1 session: 26 tok/s 26 Atlas Atlas with MTP, 1 session: 31 tok/s 31 llama.cpp llama.cpp, 1 session: 11.7 tok/s 11.7 4 sessions S2 S2, 4 sessions: 196 tok/s 196 vLLM NVFP4 vLLM NVFP4, 4 sessions: 42.3 tok/s 42.3 Atlas Atlas, 4 sessions: 51.9 tok/s 51.9 llama.cpp llama.cpp, 4 sessions: 37.9 tok/s 37.9 16 sessions S2 S2, 16 sessions: 451 tok/s 451 vLLM NVFP4 vLLM NVFP4, 16 sessions: 141.4 tok/s 141.4 Atlas Atlas, 16 sessions: 136.4 tok/s 136.4 llama.cpp llama.cpp, 16 sessions: 55.6 tok/s 55.6 64 sessions S2 S2, 64 sessions: 566 tok/s 566 vLLM NVFP4 vLLM NVFP4, 64 sessions: 329.0 tok/s 329.0 Atlas did not run llama.cpp llama.cpp, 64 sessions: 79.9 tok/s 79.9 Time to load the model S2 S2: 10 s 10 s vLLM NVFP4 vLLM NVFP4: 7 min 7 min Atlas Atlas: 38 s 38 s llama.cpp llama.cpp: 1 min 13 s 1 min 13 s
Qwen3.8-27B on one GB10, thinking off. At 1 session, vLLM and Atlas run with MTP. Each panel has its own scale.

S2 is also the only engine we tested that loads NVIDIA's own NVFP4 checkpoint of Qwen 3.8 Flash-Next on one GB10, because it keeps the model's n-gram table on disk. Stock vLLM and Atlas ran out of memory or refused to load it.

The GPU boundary

NVIDIA's userspace libraries are glibc-only, so on Nerv they live in one daemon and nowhere else. Programs load Nerv's own libvulkan.so.1, libcuda.so.1 and libnvidia-ml.so.1, which carry their calls to that daemon over a shared-memory ring locally, or over the network to a GPU in another machine. OpenGL reaches it through Mesa's Zink, which translates OpenGL into Vulkan, so no OpenGL call is intercepted directly. Each client gets its own worker process and its own GPU context, so a crashing program takes down its own connection, not the compositor.

Vulkan command buffers are recorded in the client and submitted in one crossing: one frame and a hundred frames cost the same 462 crossings. An unmodified CUDA binary runs with its GPU on another machine, and graph replay over the network runs 4.6–6.3× faster than issuing the same calls one by one. A container gets a GPU by holding one socket and one library, never a device node or the host's driver libraries, so a driver upgrade does not break images.

this machine another machine vkQuakeVulkan PyTorchCUDA ghosttyOpenGL btopNVML Mesa ZinkOpenGL to Vulkan Nerv's libvulkan.so.1 · libcuda.so.1 · libnvidia-ml.so.1 musl, loaded by every program like the real thing axon daemon one worker and GPU context per client NVIDIA librariesglibc, in this process only GB10 or GB300 GPU axon daemon vendor driver GB300, RTX, Radeon shared-memory ring network or RDMA

GPUs across machines

The GB10 has no GPUDirect RDMA: its NIC cannot register GPU memory. So axon turns the problem around and keeps transfer buffers in pinned host memory the NIC can already reach, which on unified memory streams at 96% of device-memory bandwidth. A kernel signals a proxy thread, the proxy posts an RDMA write followed by an 8-byte flag, and the receiving kernel spins on that flag.

On that path axon ships its own libnccl.so.2, covering all of NCCL 2.32.3's API, so unmodified multi-GPU programs run collectives across two GB10s. Reductions run in rank order, so every rank gets a bit-identical result: all 84 type and operator combinations match on every rank. If a peer dies, the survivor gets ncclRemoteError instead of hanging.

Between two GB10s on one cable, median latency RDMA write, 8 bytes, one way RDMA write, 8 bytes, one way: 2.7–3.4 µs 2.7–3.4 µs axon call, round trip axon call, round trip: 13.5 µs 13.5 µs ncclAllReduce, 20 KiB ncclAllReduce, 20 KiB: 13.4–15.8 µs 13.4–15.8 µs ncclAllReduce, 320 KiB ncclAllReduce, 320 KiB: 52–59 µs 52–59 µs

9P2000.L and remote execution

Nerv places a program on another machine's cores once, at execve, and never migrates running threads. The program runs on the origin machine's own system: its /usr and /etc arrive as a lazy root, an overlayfs over axon's content store with fs-verity required, where each file is fetched the first time it is opened. Your home directory is served back from the origin over 9P2000.L to the kernel's own v9fs client.

The 9P server runs as you and is confined by the kernel, not by string checks: every lookup is openat2 with RESOLVE_BENEATH, no symlinks and no magic links, and every name from the wire is a single path component. Before a program is placed, the CPU features it was built for are checked against the target's AT_HWCAP words, so an incompatible machine is never a candidate.

your laptop ~/project ❯ cargo build --release output streams here your files stay on your disk another Nerv machine 20 cores, busy with your build runs on its cores 9P2000.L files served on demand
Lazy root, GB10Latency
First open, 20 B file0.5–1.2 ms
First open, 4 MiB file10.4–12.5 ms
Later open and close13–104 µs
Manifest of /usr and /etc, 61,314 entries128 ms from cache

Plexus, remote access

Plexus connects your Nerv machines to each other and to you, wherever they are. Every device has an identity that is separate from its network address, so a machine that changes networks, sleeps or roams is still the same peer. Peers find each other through private discovery and connect directly over WireGuard, punching through NAT on both ends. When no direct path exists, traffic goes through an approved relay that forwards only ciphertext: it admits a short-lived token issued by your own authority, carrying a blinded session identifier, so the relay never learns which organisation, devices or keys it is carrying.

Access is a grant, not a network location. Grants expire, and revoking one ends active sessions. Each fleet chooses its connection policy, direct with relay fallback or approved relays only, and Plexus never relaxes it on its own: a path failure, a stale policy or a roaming laptop fails visibly instead of quietly falling back to something weaker. A central management layer for GPU provisioning, enrolment and fleet policy comes next.

hotel your laptop behind hotel NAT home DGX Spark GB10 DGX Spark GB10 desktop PC RTX GPU linked together, one pool of GPUs datacenter GB300 · 1 GB300 · 2 GB300 · 3 GB300 · 4 GB300 · 5 GB300 · 6 Plexus WireGuard, direct Plexus revocable grant Plexus

A scheduler that knows what a watt costs

The GB10 has ten Cortex-X925 performance cores at up to 3.9 GHz and ten Cortex-A725 efficiency cores at up to 2.8 GHz. On stock kernels, energy-aware scheduling is off on this chip: the firmware reports slightly different capacities for cores that are identical, the kernel refuses to build an energy model, and the one cluster it does model gets a made-up power curve.

Nerv measured each cluster at the wall and ships that table as the kernel's energy model. An X925 core draws 10.3× the power for 2.83× the clock; the stock curve said 1.13×. With a real model, the scheduler keeps light, periodic work on the efficiency cores, for 3.6× lower CPU energy than DGX OS on the same workload. A saturating benchmark took 9.28 s on Nerv and 9.31 s on DGX OS.

0 W12345 W 01 GHz2 GHz3 GHz4 GHz power per core, measured at the wall stock kernel 1.13× A725, measured X925, measured 10.3× the power for 2.83× the clock

Generations

Every change to the system is a new generation: a btrfs subvolume beside the running one, sealed into its own signed boot image. There is no fixed A/B pair; a machine keeps as many generations as it has reason to. A new generation boots on trial with a counter. If it fails to complete a boot three times, the machine falls back to the generation that worked, with nobody present. Only a generation that has booted becomes the default.

Before anything goes to hardware, the new generation is booted in a VM from its own boot image and driven through a real login. The mechanism is cage.

generation 41 proven, the default generation 42 new btrfs subvolume VM login gate boots its own image boot on trial counter 3 · 2 · 1 completes a boot 42 becomes the default fails three times machine boots 41, unattended update fall back to the generation that worked

Boot

Each slot boots from one Unified Kernel Image: kernel, initrd and command line in a single file that the firmware verifies as a unit, signed under Nerv's own Secure Boot key hierarchy rather than Microsoft's. There is no bootloader configuration to drift and nothing to edit.

The disk is encrypted and unlocks itself from the TPM against a policy signed for that exact boot image, so no passphrase is typed and no key is on disk. The passphrase remains as a fallback. The GPU's firmware loads while the disk is unlocking, not after, so the GPU is ready when userspace is.

0 s12345678910 s boot loader 2.17 s kernel 1.49 s initrd 2.62 s userspace 3.17 s TPM unlocks the disk GPU firmware loads login prompt ~6.9 s from firmware hand-off

The full system target follows shortly after, because it waits for the GPU on purpose.

Keys

Five keys sign or unlock different things, and each machine generates its own rather than being issued a fleet's. A machine's private keys never leave it, and its signing key doubles as its identity, so there is no central secret whose loss compromises every machine at once.

KeySignsChecked by
UEFI dbThe boot imageFirmware, every boot
TPM policyThe unlock policy inside the boot imageThe TPM, every unlock
Kernel moduleOut-of-tree modules, such as NVIDIA'sThe kernel, every module load
OpenPGPPackagesrpm, every install
ed25519The installer and each generation's checksumsThe bootstrap script and the installer

Kernel and driver

Nerv runs the newest released kernel and takes a stable update within days. The NVIDIA driver is the latest release, built from NVIDIA's open kernel modules with Nerv's patches, and signed with a key that never enters the build chroot. Unsigned modules do not load.

One of those patches charges GPU memory to the cgroup of the process that allocated it. On a unified-memory machine that matters: a container or service with a memory limit gets CUDA_ERROR_OUT_OF_MEMORY at its limit, and nothing is killed. A runaway GPU allocation cannot take the machine down.

One compiler, hardening nobody can turn off

Every package Nerv compiles is built with LLVM 22 and linked with lld, for the GB10's Cortex-X925. Programs get LTO, -O3, ARM branch protection (PAC and BTI), full RELRO, _FORTIFY_SOURCE=3, a stack protector and a non-executable stack by default.

musl implements no fortified functions, so _FORTIFY_SOURCE is silently inert on other musl systems. Nerv ships fortify headers in every build root, so every package is fortified apart from the listed exemptions.

Builds run in a pure-musl chroot composed from Nerv's own repository, never a glibc build root, because a musl binary built inside a glibc environment picks up glibc-shaped answers that surface as bugs much later.

Packaging

rpm, libsolv, librepo and dnf5 are built against musl and run with no glibc anywhere in their dependency trees. That means two things: the system can rebuild itself, and dnf install still reaches the Fedora package ecosystem when you need something Nerv does not build. Packages are signed, and the machine refuses unsigned ones.

ComponentVersionNotes
rpm6.0.2musl; OpenPGP through rpm-sequoia, no gpgme chain
libsolv0.7.40built against librpm, comps enabled
librepo1.21.1USE_GPGME=OFF
dnf55.4.6.0links libdnf5, librpm, libc++, libunwind and musl, no glibc

Containers

Small by construction. Nerv's base image, nerv-minimal, is 87 MB with a shell, coreutils and dnf, 40% smaller than fedora-minimal's 146 MB. It is built from the same signed packages as the machine, and every container you build on it starts from fewer than 1,400 files. For a single program, nerv-static is 1.8 MB: musl, the CA certificates and time zones, with no shell, no package manager and nothing to exploit. It's smaller than Google's distroless/static and still runs any program built on Nerv.