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.
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.
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
Mixed sizes and lifetimes higher is better
16 processes at once higher is better
Firefox memory during Speedometer lower is better
Security, 33 heap attacks
Attacks detected higher is better
Attacks that succeeded lower is better
Heap address entropy higher is better
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.
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.
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.
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.
| Lazy root, GB10 | Latency |
|---|---|
| First open, 20 B file | 0.5–1.2 ms |
| First open, 4 MiB file | 10.4–12.5 ms |
| Later open and close | 13–104 µs |
Manifest of /usr and /etc, 61,314 entries | 128 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.
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.
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.
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.
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.
| Key | Signs | Checked by |
|---|---|---|
| UEFI db | The boot image | Firmware, every boot |
| TPM policy | The unlock policy inside the boot image | The TPM, every unlock |
| Kernel module | Out-of-tree modules, such as NVIDIA's | The kernel, every module load |
| OpenPGP | Packages | rpm, every install |
| ed25519 | The installer and each generation's checksums | The 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.
| Component | Version | Notes |
|---|---|---|
rpm | 6.0.2 | musl; OpenPGP through rpm-sequoia, no gpgme chain |
libsolv | 0.7.40 | built against librpm, comps enabled |
librepo | 1.21.1 | USE_GPGME=OFF |
dnf5 | 5.4.6.0 | links 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.