Hardware — The Vexor Reference Box¶

Docs-site note (2026-07-11): Part of the Vexor documentation site (Anza-style). This page documents the exact machine the Vexor testnet validator runs on today, why each component was chosen, and how Vexor maps its work onto the hardware. All specs below are read directly from the live box.

At a glance¶

Component	Spec
CPU	AMD EPYC 9374F — 32 cores / 32 threads (SMT off), Zen 4 (`znver4`), up to 4.31 GHz
Caches	L1 32×32 KiB, L2 32 MiB (1 MiB/core), L3 256 MiB across 8 CCX (32 MiB each)
RAM	503 GiB DDR5
Primary NIC	Mellanox ConnectX-6 Dx (MT2892), dual-port 10 GbE — the AF_XDP zero-copy path
Secondary NIC	Broadcom BCM57416 NetXtreme-E, dual-port 10 GbE
Storage	3× Crucial T700 PCIe Gen5 NVMe SSDs (1.8 TB + 3.6 TB + 4 TB)
OS	Debian 12 (bookworm), Linux kernel 6.12

This is a single-socket, high-clock, cache-rich server — deliberately chosen to match a validator's profile: latency-sensitive single-threaded hot paths plus a wide fan-out of pinned worker tiles.

CPU — AMD EPYC 9374F (why this part)¶

The 9374F is AMD's high-frequency EPYC: 32 cores at a 3.85 GHz base / 4.31 GHz boost, versus the 64–96-core parts that trade clock for core count. For a Solana validator that is the right trade:

Replay and PoH verification are latency-bound, not embarrassingly parallel. A higher per-core clock directly shortens the critical path of executing a block and hashing the PoH, which is what keeps the node caught up to the cluster tip.
znver4 unlocks the build target. Vexor compiles with -Dcpu=znver4, so the binary uses AVX-512, SHA-NI, VAES, and the full Zen-4 ISA the CPU advertises (avx512f/dq/bw/vl, sha_ni, vaes, vpclmulqdq are all in the live flag set). SHA/AES/CLMUL acceleration matters for the constant hashing the validator does.
256 MiB L3 across 8 CCX. Each Core-Complex (CCX) of 4 cores shares a 32 MiB L3 slice. Vexor's core-pinning layout (below) is CCX-aware: hot, latency-critical tiles are kept on cache-warm cores, and cold/background work (the ledger tile, build relief) is fenced onto a separate CCX so it never evicts the hot working set.

Memory — 503 GiB¶

Solana's account set is large and Vexor memory-maps the snapshot's account storage rather than copying it into the heap, so most of RAM is page cache backing those mmaps (the live box shows ~433 GiB in buff/cache). 503 GiB gives comfortable headroom for the full account set, the in-memory ledger index, replay working state, and the per-tile buffers — with room to spare for an archival/RPC role.

Network — Mellanox ConnectX-6 Dx (the AF_XDP path)¶

The validator's ingest NIC is a Mellanox ConnectX-6 Dx dual-port 10 GbE adapter. This is the card Vexor's AF_XDP zero-copy datapath runs on: shreds and packets are delivered from the NIC into userspace ring buffers without a per-packet kernel-stack copy, which is essential for keeping up with Turbine's shred firehose at line rate. The ConnectX-6 Dx has mature AF_XDP / XDP driver support (mlx5), hardware queues that map cleanly onto the pinned RX tiles, and RDMA-class offloads.

A second Broadcom BCM57416 dual-10 GbE adapter is present for management/secondary connectivity, keeping the Mellanox card dedicated to the validator datapath.

See Network setup for AF_XDP enablement (VEX_ENABLE_AFXDP=1), queue/IRQ tuning, and the core-pinning layout that pairs RX queues to tiles.

Storage — 3× Crucial T700 Gen5 NVMe¶

Three PCIe Gen5 NVMe drives, each role-separated so the workloads don't contend:

Device	Size	Mount	Role
`nvme0n1`	1.8 TB	`/`	OS + the Vexor build tree
`nvme1n1`	3.6 TB	`/mnt/snapshots`	snapshot archives + the working accounts DB
`nvme2n1`	4.0 TB	`/mnt/ledger`	VexLedger blockstore (`/mnt/ledger/vex-fd-testnet`)

Gen5 NVMe gives the sequential bandwidth VexLedger's append-segment writer wants (it streams shreds sequentially, ~1.15 MB/s steady on testnet, with headroom for mainnet rates) and the random-read IOPS the accounts DB needs. Putting the ledger on its own drive means the blockstore's sequential writes never compete with the accounts DB's random reads or with snapshot I/O — and because VexLedger does no compaction, that drive sees ~1× write amplification instead of an LSM's multi-× churn.

How Vexor maps onto the cores¶

Vexor runs as a set of pinned tiles (dedicated threads on specific cores), Firedancer-style, so latency-critical work never floats or gets preempted. The live testnet layout on the 32-core EPYC is:

recv=5  quic-pump=6  verify=8–15  replay=16  produce=20  gossip=24
txsend=28  sysvar=29  repair=30   |  wave (parallel-exec) workers=25,26
ledger tile (VexLedger consumer)=cold core 4
dynamic relief / build = CCX0 cores 1–3 (kept off the hot tiles)

Key principles: - Consensus-critical tiles (verify, replay, produce, vote/txsend) are on cache-warm cores and never share a core with background work. - The VexLedger consumer runs on a cold core (4), entirely off the consensus path — persistence can never stall replay or voting. - Builds and dynamic relief are fenced onto CCX0 (cores 1–3) so a compile can't evict the hot working set. (Even so, Vexor's deploy discipline is STOP → BUILD → DEPLOY — the node is brought down before a release build; see Build / Deploy.)

See Network setup for the full pinning table and the /proc-based tiling verifier.

Is this hardware required?¶

No — it's the reference box, not a minimum. The architectural choices (high-clock CPU, a NIC with good AF_XDP support, a dedicated NVMe for the ledger, enough RAM to mmap the account set) are the parts that matter; the exact models are what this deployment happens to use. Vexor's tile counts and core assignments are configurable (VEX_TASKSET_CORES, the pinning script), so the layout scales to other core counts.

Status¶

The live testnet validator runs on this box today: voting at ~98.7% of maximum vote credits and producing ~97%+ of its leader slots (empty, cluster-accepted blocks — transaction-bearing block production exists behind a gate and is not yet enabled), with AF_XDP zero-copy ingest on the Mellanox ConnectX-6 Dx, the account set mmap'd from the Gen5 NVMe snapshot drive, and VexLedger writing to its dedicated 4 TB Gen5 NVMe.

Vexor is testnet-only, version 0.9.x pre-production — this box is a single reference deployment, not a mainnet-qualified configuration.