For most of its time in the data center, NVIDIA treated the CPU as little more than the chip that fed the GPU. Grace, its first server processor, fit that mold. It used Arm’s off-the-shelf Neoverse V2 cores and shipped mostly as the CPU half of the Grace Hopper and Grace Blackwell superchips. Those superchips did introduce one lasting piece of the platform: NVLink-C2C, a link that gives the CPU and GPU coherent access to each other’s memory at far higher bandwidth than PCIe.
Its successor, Vera, is far more ambitious. It is a clean-sheet design built around Olympus, NVIDIA’s custom Arm core. Olympus implements Armv9.2, and each Vera CPU features 88 cores and 176 threads. Alongside the new cores, the memory subsystem is the other highlight. Each CPU supports up to 1.5TB of LPDDR5X on SOCAMM modules, with an advertised peak bandwidth of 1.2TB/s, which gives Vera the power efficiency of mobile-class DRAM while keeping the memory field-replaceable.
That ambition extends to where Vera is deployed. It still ships as part of the superchip in Vera Rubin systems, but NVIDIA has also expanded it to its BlueField-4 STX storage platform and to standalone CPU servers for agentic sandboxes. Vera is also gaining broad support from OEMs, hyperscalers, and NCPs: Dell, HPE, and Supermicro have added Vera servers to their lineups, and hyperscalers and NCPs are poised to make it a mainstream offering. That broad availability matters because, as our results will show, Vera is a serious contender against its x86 counterparts, and it gives organizations a third CPU vendor to help diversify their supply chains.
Key Takeaways
- Memory bandwidth more than doubles every x86 system. Two Vera sockets sustained over 2TB/s on STREAM Triad, 2.3x the best DDR5 server we tested. Even when reading the other socket’s memory over NVLink-C2C, Vera’s cores pulled more bandwidth than any x86 socket gets from local memory, and local latency with hugepages was 13% lower than on the EPYC 9175F.
- A well-balanced chip for the broad middle of the market. One 3.4GHz Olympus core compressed 12% faster on 7-Zip than the 5.0GHz EPYC 9175F and won two of three single-thread Python tests against it. At full load, Vera reached 63% to 72% of the EPYC 9965’s 7-Zip throughput with fewer than half the cores, staying close to AMD’s per-core specialist on one thread and to its throughput specialist across the whole system.
- Vector and crypto work is the clear weakness. Six 128-bit SVE2 pipes can’t match 512-bit AVX-512 on code written for it. On a matched 16 cores, Vera ran GROMACS benchMEM at half the EPYC 9175F’s rate and two-thirds of the EPYC 9965’s, and a single core encrypted AES-256-GCM at about a third of the 9175F’s speed. Across the full system, the 384-core EPYC 9965 led by roughly 3x on both GROMACS benchPEP and AES.
- Memory-bound HPC turns bandwidth into speed. On the large OpenFOAM mesh, Vera finished 1.44x faster than the 384-core EPYC 9965 and 1.20x faster than the 240-core Xeon 6978P. On the smaller mesh, where larger x86 L3 caches hold more of the problem, Vera came in second, within 12% of the 9965.
- Databases and analytics are already competitive. In HammerDB TPROC-C on one socket, 88 Vera cores beat a 192-core EPYC 9965 socket by 26% on PostgreSQL and 8% on MariaDB, while trailing by 19% on MySQL and 15% on VillageSQL; the Xeon 6787P trailed Vera on all five engines. Vera also completed the ClickBench hot run in 23% less time than the EPYC 9965 and served 34% more requests on a 256GB Valkey working set.
TECHNICKÉ ÚDAJE
| Specifikace | Procesor NVIDIA Vera |
|---|---|
| Compute and Power | |
| Jádro | NVIDIA Olympus, Armv9.2 with SVE2 and FP8 |
| Cores and threads per socket | 88 cores, 176 threads (NVIDIA Spatial Multithreading) |
| Clock Speed (Measured) | 3.41GHz |
| TDP | 250W to 450W configurable |
| Chlazení | Vzduch nebo kapalina |
| Cache | |
| L1 instruction | 64 kB na jádro |
| L1 data | 96KB per core, 6-way |
| L2 | 2MB per core, private |
| System-level cache (L3) | 164MB per socket, Arm MPAM partitioning |
| Tkanina | 2nd-generation Scalable Coherency Fabric, 3.4TB/s bisection |
| Memory | |
| Typ | LPDDR5X on 8x SOCAMM2 modules per socket |
| řadiče | 8x 128-bit (1,024-bit aggregate) |
| Rychlost | Až 9,600 MT/s |
| Šířka pásma | Up to 1.2TB/s per socket (vendor rating) |
| Kapacita | 256GB to 1.5TB per socket |
| Vstup / výstup | |
| PCIe | Gen6, 88 lanes per socket (CPU-only platform) x16, x8, x4, x2 bifurcation |
| CXL | 3.1, Type 3 memory expansion and pooling |
| NVLink-C2C | 2nd generation, 1.8TB/s bidirectional, coherent, authenticated encryption |
| Bezpečnost | |
| Důvěrné výpočty | Arm CCA realms, RME-DA and RME-CDA, TDISP, per-VM keys |
Why NVIDIA Wants Into the CPU Business
To understand why Vera matters to NVIDIA, look at how the company has grown. NVIDIA built its data center position around the GPU, then expanded into the infrastructure needed to keep those GPUs running. On the hardware side, the 2020 Mellanox acquisition brought the networking technology that connects servers and moves data between them. On the software side, CUDA, DOCA, and the wider software stack extended NVIDIA’s reach into how that hardware is programmed and operated. Together, those pieces gave the company control over much of the accelerated computing platform.
But the platform still needed a general-purpose CPU. Something had to run the operating system, prepare data, manage applications, and coordinate the work sent to the accelerators. During much of NVIDIA’s expansion, Intel and AMD filled that role. That left NVIDIA in an awkward position: it could supply the GPUs, the network, and much of the software while still depending on another company’s processor at the center of the server.
Grace was the first major step toward changing that. Built around Arm Neoverse V2 cores, it gave NVIDIA a data center CPU and a way to connect that CPU more closely to its GPUs through NVLink-C2C. Grace nevertheless left a performance gap to close. Its memory bandwidth and efficiency made it competitive as an AI host CPU, but leading x86 processors retained substantial advantages in most other workloads. That uneven performance limited the argument for choosing Grace as a general-purpose replacement for an EPYC or Xeon server.
Vera closes much of that gap by replacing Grace’s Neoverse V2 cores with NVIDIA’s custom Olympus design and substantially increasing memory bandwidth and capacity. By supplying a competitive CPU alongside its GPUs, DPUs, and networking, NVIDIA can capture a larger share of spending on each server. It also gives the company greater control over its ecosystem and how the components work together: the CPU cores, memory subsystem, interconnect, and GPU can be designed around the same requirements. Vera’s coherent CPU-to-GPU link, now rated at up to 1.8TB/s, is a concrete example of that integration.
Capturing more of each system’s spend is only part of the picture. Reinforcement learning (RL) and agentic AI give NVIDIA another reason to offer a standalone CPU system. An agent does more than generate a response. It calls tools, retrieves information, runs code, and checks the results before deciding what to do next. Much of that execution happens on CPUs, and when the next model step depends on a CPU task’s result, slow execution delays the whole sequence. Per-core performance, memory latency, and predictable behavior under load therefore become important to the responsiveness of the agent.
The Olympus Core
Those requirements align closely with the design of Vera’s 88 Olympus cores, which are built around a clear priority: strong performance from each core, sustained when the entire socket is busy. Olympus is NVIDIA’s implementation of the Armv9.2 instruction set, replacing the Neoverse V2 cores used in Grace. That distinction matters: Arm defines the instructions the processor runs, while NVIDIA designed the machinery that fetches, schedules, and executes them. That control lets NVIDIA tune the core for its goal: finishing individual tasks quickly while running many at once.
The first half of that goal starts with instructions per cycle, or IPC: how many instructions a core completes, on average, in each clock cycle. Clock speed determines how often those cycles occur; the microarchitecture determines how much useful work can fit into them. NVIDIA claims a 1.5x IPC improvement over its previous generation. The highest clock we observed was 3.41GHz, but Vera’s architecture emphasizes extracting more work per cycle and maintaining that progress under load. That emphasis matters because, for a compiler, interpreter, or database operation with a long sequence of dependent steps, additional cores alone cannot make that sequence finish faster.
Achieving that IPC begins with a steady supply of useful instructions. Olympus’s front end, the part of the core that fetches and decodes program instructions, can decode up to ten instructions per cycle. That width matters only if it stays fed, which becomes difficult when software frequently branches between code paths. Olympus therefore combines a neural branch predictor with other specialized predictors and supports up to two taken branches per cycle. Better prediction helps the core fetch the instructions it will need, reducing time spent executing the wrong path and restarting after a mistake.
Once those instructions are fetched and decoded, Olympus uses out-of-order execution to find work that can proceed while earlier instructions wait. For example, if one operation is waiting for memory, an independent calculation can execute ahead of it. A large instruction window gives the processor more opportunities to find that independent work.
Even so, some sequences, like the dependent chains described above, resist this approach because each step needs the previous step’s result. For those, Olympus also uses value prediction to let dependent operations begin with a predicted value, then checks that value when the actual result becomes available. Correct predictions can reduce the effective wait along these dependency chains; incorrect predictions require the speculative work to be corrected and recomputed.
The execution engine then needs enough capacity to turn that instruction supply into completed work. Olympus combines broad integer execution resources with dedicated branch units, four load pipelines, and two store pipelines. These resources meet different demands: integer units handle arithmetic, comparisons, and logic; branch units resolve control flow; and load/store pipelines move data between the core and its caches. The balance matters because a wider decoder would offer little benefit if instructions simply backed up behind an execution or memory bottleneck.
Alongside those scalar resources, Olympus has six 128-bit vector pipelines supporting SVE2, with FP8 support and cryptographic capabilities in two pipelines. Vector instructions apply an operation to multiple data elements, making them useful for numerical work, compression, and data processing.
This is one area where Olympus makes a clear trade-off: its 128-bit vector width is smaller than the 512-bit width available through AVX-512 on competing x86 processors. The difference matters for optimized numerical kernels and even tokenizers, although application performance also depends on the throughput of the particular instructions, the generated code, and the supply of data. Scientific applications such as GROMACS therefore remain a separate test of the design’s strengths.
Each of these execution resources, scalar or vector, depends on data arriving on time, so keeping frequently used data close to the execution engine matters just as much. Each core has a 64KB instruction cache, a 96KB data cache, and a private 2MB L2 cache. The small first-level caches provide quick access to the most immediately useful instructions and data; the larger L2 retains more of the core’s working set before an access has to travel farther through the processor. Giving every core a substantial private L2 supports the same per-core objective: more work can be serviced locally, reducing pressure on shared cache and main memory.
Prefetching complements those caches by bringing data in before an instruction requests it. Alongside prefetchers for regular access patterns, Olympus includes a graph prefetcher for indirect accesses such as A[B[i]], where one lookup supplies the index for another. After learning that relationship, the hardware can start fetching the second piece of data before the program demands it. This helps address a common problem in graph processing and other irregular workloads: the processor has ample execution capacity, but progress depends on finding the next piece of data.
The final piece of Olympus addresses the other half of its goal: running many tasks at once. Each core supports two hardware threads, giving Vera 176 threads per socket. NVIDIA calls its scheme Spatial Multithreading. The core can devote its resources to one active thread or divide resources between two active threads, providing a choice between concentrating execution capacity on one instruction stream and supporting more concurrent work.
NVIDIA’s stated objective is to reduce interference between the two threads, making performance more predictable when both are busy, which is the same predictability agentic workloads depend on under load. The two threads still share a physical core and the wider memory system, so partitioning resources does not guarantee a fixed application latency.
Fabric, Memory, and I/O
Beyond the individual core, keeping 88 wide cores productive requires more than a fast connection to DRAM. The cores also need to exchange data, access shared cache, and communicate with attached devices. Vera connects these resources through the second generation of NVIDIA’s Scalable Coherency Fabric, an internal mesh that also keeps cached copies of shared data coherent. The cores, fabric, and 164MB system-level cache sit on one compute die, with memory controllers and I/O on adjacent chiplets. NVIDIA rates the fabric at 3.4TB/s of bisection bandwidth, a measure of traffic capacity across the mesh, separate from main memory bandwidth.
That single-die layout avoids transfers between separate compute dies when cores communicate or access shared cache. For software, Vera also presents one NUMA node per socket: the operating system sees each socket as one group of cores and locally attached memory. This simplifies placement within the socket, although it does not mean every path through the mesh has identical latency. A two-socket server still has two NUMA nodes, and accessing the other socket’s memory remains different from accessing local memory.
Within each socket, the shared system-level cache, or L3, sits one level beyond the private L2 caches described earlier. It gives the cores another chance to reuse data without going to DRAM and provides shared capacity accessible across the socket. Its 164MB is substantial, but some competing processors offer considerably more L3. That matters when a repeatedly accessed working set is too large for a core’s L2 but fits in a larger shared cache. High DRAM bandwidth helps when data must come from memory; it does not remove the benefit of avoiding that access in the first place.
Because that capacity is shared, Vera also supports Arm MPAM, allowing system software to partition shared cache capacity and manage memory-bandwidth allocations between workloads.
When accesses do reach main memory, Vera has considerable bandwidth available. Eight 128-bit LPDDR5X controllers provide a 1,024-bit aggregate interface, with memory running at up to 9,600MT/s for a rated 1.2TB/s per socket. The memory sits on eight removable SOCAMM2 modules, combining LPDDR5X with field-replaceable modules. This gives Vera a broad, fast memory interface without requiring soldered-down memory.
Raw bandwidth is only part of the picture, though. The more useful relationship is between that bandwidth and the number of cores sharing it. Dividing the rated 1.2TB/s by 88 cores gives about 13.6GB/s per physical core. This is a way to describe the processor’s balance, not a dedicated allocation or a guarantee of what each thread receives. Increasing core count without a matching increase in memory bandwidth would reduce that ratio.
Dividing our measured STREAM bandwidth by the number of physical cores gives 11.8GB/s per core on Vera, compared with 3.8GB/s on the 240-core Xeon 6978P system. That is a concrete example of Vera supplying substantial memory throughput relative to its compute resources.
Power efficiency is part of the same design choice. NVIDIA estimates roughly 30W to 40W for a fully populated LPDDR5X memory subsystem, depending on capacity. The appeal of LPDDR5X is to supply this bandwidth while keeping memory’s contribution to total server power low, leaving more of the system’s power and cooling budget available for computation.
Bandwidth and efficiency still say nothing about how much data fits, and capacity remains a separate consideration. NVIDIA specifies up to 1.5TB of directly attached LPDDR5X per socket, or 3TB across two sockets. For workloads that need their working set resident in memory, higher transfer rates cannot compensate for insufficient capacity.
Where that directly attached capacity is not enough, Vera’s I/O provides a path to more, along with connections for devices. The standalone CPU platform provides 88 PCIe Gen6 lanes per socket for networking, storage, and accelerators, while the Vera Rubin configuration exposes 96. On the memory side, CXL 3.1 support includes Type 3 memory devices and memory pooling, allowing capacity to extend beyond the SOCAMM2 modules. That expanded memory uses a different access path from the directly attached LPDDR5X, so its performance must be evaluated separately.
Finally, for communication between processors, Vera uses second-generation NVLink-C2C, the successor to the link introduced with Grace’s superchips. It connects two Vera CPUs in a dual-socket server or links Vera to Rubin GPUs in a superchip. The link provides up to 1.8TB/s of aggregate bidirectional bandwidth, or 900GB/s in each direction, and it reflects the same tight CPU-GPU integration that drives NVIDIA’s push into the CPU business in the first place.
Inside the MGX Vera C2 Reference Server
Our review unit is NVIDIA’s MGX Vera C2, a dual-socket, air-cooled 2U reference server that NVIDIA’s partners are using as the basis for their first Vera systems. Eight E1.S bays run across the top of the front panel next to four hot-swap Delta power supplies, with honeycomb intake filling the rest of the face. Because the power supplies load from the front, the rear stays clear for I/O cabling in a rack and is given over to the PCIe risers and management I/O.
Inside, the two Vera CPUs sit side by side under passive heatsinks, with SOCAMM2 modules along their flanks. A wall of six fan modules in the center of the chassis, just behind the drive bays, pulls air across both sockets, and foam blocks between each pair of fans direct the airflow. From a cooling standpoint, the layout is well thought out.
Both processors are mounted directly to the PCB with no socket, the same way NVIDIA ships Vera in its superchips. The 16 SOCAMM2 slots surround the two packages, so the memory remains field-replaceable even though the processors are not; replacing a CPU means swapping the board. Over the summer, we also looked at the liquid-cooled version of the same board, which runs quick-disconnect coolant lines across the top of the board to the processor cold plates while leaving the SOCAMM2 modules air-cooled.
The middle riser holds an NVIDIA ConnectX-8 adapter for up to 800G networking, and the rear panel carries USB, DisplayPort, and a dedicated network port for out-of-band management.
The platform is highly modular and supports a range of storage and rear PCIe configurations, but that flexibility comes at the cost of service time. Its three FHFL PCIe risers look easy to service at first glance. In a typical server, swapping a card means releasing the riser, flipping out a support tab or removing a screw, and sliding the card out.
On the Vera server, you first pop off the fan cover, remove one or more of the foam blocks, and disconnect and lift out the riser’s power and PCIe cables. Only then can the entire riser assembly slide out through the rear of the chassis. Once the sled is free, it has to be disassembled to reach the card and then reassembled after the swap. A job that takes a few seconds on a conventional server takes 5 to 10 minutes per sled here.
In practice, in-rack servicing is off the table unless you are prepared to shuffle back and forth, so most component swaps require moving the server to a bench to service.
Výkon a benchmarky
The benchmarks examine how Vera’s design translates into performance, from individual threads to workloads using the full system. Our tests cover memory bandwidth and latency, scientific computing, general-purpose software, and databases, showing how the processor handles different demands on its cores and memory system.
Testovací systémy
| Systém | NVIDIA MGX Vera C2 | Dell PowerEdge R7725 | Dell PowerEdge R7725 | Dell PowerEdge R770AP | Dell PowerEdge R770 | Dell PowerEdge R760 |
|---|---|---|---|---|---|---|
| Procesory | ||||||
| Procesor (CPU) | NVIDIA Vera | AMD EPYC 9965 | AMD EPYC 9175F | Intel Xeon 6978P | Intel Xeon 6787P | Intel Xeon Platinum 8592+ |
| Zásuvky | 2 | |||||
| Cores / Threads per CPU | 88 / 176 | 192 / 384 | 16 / 32 | 120 / 240 | 86 / 172 | 64 / 128 |
| Základní hodiny | 3.4 GHz | 2.25 GHz | 4.2 GHz | 2.1 GHz | 2.0 GHz | 1.9 GHz |
| Max Clock | 3.4 GHz | 3.7 GHz | 5.0 GHz | 3.9 GHz | 3.8 GHz | 3.9 GHz |
| Memory | ||||||
| Konfigurace | 16x 96GB Micron SOCAMM2 | 24x 128GB | 24x 64GB | 32x 64GB | 16x 64GB | |
| Type / Speed | LPDDR5X-9600 | DDR5-6400 | DDR5-5200 | DDR5-4800 | ||
| Celková kapacita | 1.5TB | 3TB | 1.5TB | 2TB | 1TB | |
| Skladování | ||||||
| SSD | Solidigm D7-PS1010 7.68TB | Solidigm D7-PS1030 12.8TB | Micron 9550 PRO 7.68TB | Solidigm D7-PS1010 7.68TB | Samsung PM1745 6.4 TB | Solidigm D7-P5520 3.84 TB |
| SSD Link | PCIe Gen5 x4 | PCIe Gen5 x2 | PCIe Gen5 x4 | PCIe Gen4 x4 | ||
| firmware | ||||||
| Systém BIOS | NV_SBIOS 06.07.01.06 | 1.5.3 | 1.2.1 | 1.8.5 | 2.8.2 | |
| BIOS Profile | Automaticky | Výkon | ||||
| Zásobník softwaru | ||||||
| OS | Ubuntu LTS 26.04.1 | Ubuntu LTS 24.04.5 | ||||
| Jádro | 7.0.0-2022-nvidia-bos | 6.8.0-142 / 6.8.0-146 | 6.8.0-147 | 6.8.0-138 | 6.8.0-142 / 6.8.0-146 | 6.8.0-142 / 6.8.0-146 |
| GCC | 15.2.0 | 13.3.0 | ||||
| glibc | 2.43 | 2.39 | ||||
| Open MPI | 5.0.10 | 4.1.6 | ||||
| OpenJDK | 11.0.32 | |||||
We compared Vera against five Dell PowerEdge configurations with ideal memory configuration and tested them with the same suite, covering AMD’s highest-core-count and frequency-optimized EPYC parts along with current- and previous-generation Xeons.
Because Olympus support first arrived in GCC 15, Vera ran a newer software stack than the x86 systems, as listed above. Benchmark versions, inputs, and build flags were otherwise identical across all systems.
Paměťová šířka pásma
Memory is where Vera departs most from x86, so we start our testing there. We tested STREAM Triad, run with one OpenMP thread per physical core on 16GiB arrays. The headline run uses every core in the system, with each thread’s data placed on the same socket. We then repeat it with socket 0’s cores reading first their local memory and then the remote socket’s memory, and with every core reading pages interleaved across both sockets. The chart below shows whole-system Triad results for each server with SMT off.
Vera sustained 2,073GB/s, 86% of its 2.4TB/s two-socket rating. The closest x86 system was the Xeon 6978P, whose 24 channels of DDR5-6400 delivered 914GB/s, 74% of its 1,229GB/s theoretical peak, for a 2.3x Vera lead. The two EPYC systems run the same 24 channels of DDR5-6400 yet landed well below that: 651GB/s for the 32-core 9175F and 634GB/s for the 384-core 9965, just 52% of peak and a 3.3x Vera lead. Finally, the Xeon 6787P and 8592+ trail the pack running on slower DDR5-5200 and DDR5-4800, reaching 479GB/s and 482GB/s.
Part of the EPYC shortfall comes from how STREAM counts traffic. The suite builds STREAM with plain GCC, which doesn’t emit streaming stores, so a store that misses cache first reads its destination line from memory. STREAM doesn’t count that read, which means Triad understates the traffic moved by a quarter wherever it happens. AMD’s Zen cores pay it on every store. Arm cores such as NVIDIA’s earlier Grace detect full-line writes and skip the read, and Intel’s recent Xeons can skip most of it when memory is heavily loaded.
The separate Phoronix Test Suite build of STREAM points the same way. With SMT off, its Copy result reached 832GB/s on the 9965 and 873GB/s on the 9175F, about 1.5x the suite build’s 551GB/s and 570GB/s, and in line with the gain Copy should see once the extra read is gone; on the Xeons, the two builds landed within 9% of each other.
Adjusted for the uncounted reads, the 9965 moved about 845GB/s, roughly 69% of peak, and Vera’s lead in bytes moved narrows to about 2.5x. The 6978P needs far less correction, which makes its 2.3x the most conservative comparison in the set.
Splitting the test by socket shows how the fabric handles data that isn’t local to the cores. Socket 0’s cores reading local memory hit 1,055GB/s, 88% of the 1.2TB/s per-socket rating and more than any whole x86 server in the set. Reading the other socket’s memory over NVLink-C2C, the same cores sustained 677GB/s, 64% of the local figure, against 59% on the Xeon 6978P and 45% on the EPYC 9175F (148GB/s remote against 327GB/s local). Even a workload placed on the wrong socket therefore gets more bandwidth than any x86 socket reads from local memory, which tops out at 460GB/s on the 6978P.
As a final test for Vera, we tested with STREAM Triad interleaved pages across both sockets, the case a non-NUMA-aware application sees, which gave Vera 1,372GB/s, 1.5x the 6978P’s whole-system result.
Latence
Bandwidth is only half of the memory story. Latency decides how long a core waits each time it misses in cache, and it matters most for code that chases pointers through memory. We measure it with tinymembench, which times random reads across a 1GiB buffer from a single thread on socket 0. The EPYC 9175F is the only x86 system in our set with results from this test, so it is the comparison here.
When reading local memory, Vera is faster than the EPYC. With 2MB hugepages, a local read took 99.2ns on Vera vs 114.3ns on the 9175F, 13% faster; with standard 4KB pages, they were level at about 135ns. Reaching across to the other socket is where NVLink-C2C shows its cost. A remote read took 212.7ns on Vera, about 2.1x its local time, while the EPYC’s 199.9ns was only 1.75x its local time.
Vera is also more sensitive to page size. With 4KB pages, where missed address translations add to every read, its local latency rose 37%, and its remote latency reached 308.4ns, against an 18% rise and 228.6ns on the EPYC. On Vera, we would run hugepages.
HPC
Bandwidth and latency describe the memory system in isolation. Scientific applications show what happens when that memory system and the cores have to work together, and our two HPC tests lean on very different parts of CPU design.
GROMACS, a molecular dynamics code, spends most of its time in vector arithmetic, with hot loops hand-written for each SIMD width. That makes it the most direct test of the trade-off described in the Olympus section: six 128-bit SVE2 pipes against the 512-bit AVX-512 units on the x86 parts. OpenFOAM, a computational fluid dynamics solver, works through large sparse matrices and spends much of its time waiting on memory, so it shows whether the bandwidth measured above carries over to a real application.
GROMACS
We tested GROMACS 2025.3 with benchPEP, a 12-million-atom case run across every physical core in the server. The build used ARM_SVE on Vera and AVX-512 on every x86 system, and the suite’s pinned inputs and disabled PME tuning mean every platform ran the same work.
With SMT off, Vera finished benchPEP at 1.77 ns/day. The 384-core EPYC 9965 led at 5.36 ns/day, 3.0x Vera, followed by the 240-core Xeon 6978P at 3.79 (2.1x) and the 172-core Xeon 6787P at 2.24 (1.27x). The 128-core Xeon 8592+ also finished ahead at 1.87, leaving only the 32-core EPYC 9175F, at 1.10, behind Vera. Normalizing by core count shows how much of that gap is architecture. Vera works out to 0.0100 ns/day per core, against 0.0130 on the 6787P, 0.0140 on the 9965, 0.0146 on the 8592+, and 0.0158 on the 6978P, so the deficit to the big x86 parts is partly core count and partly per-core throughput.
Spatial Multithreading recovers some of that ground, as enabling it lifted Vera’s result 17% to 2.07 ns/day, with the best layout running all 352 hardware threads as thread-MPI ranks. That is a larger gain than SMT gave the Xeon 6978P (3%) or the 8592+ (11%) in our earlier runs, and the EPYC 9965 lost 3.5% with it on. With resources partitioned between the two threads, each rank gets a slice of the core, and the solver’s mix of vector math and memory stalls seems to fill those slices better than a single rank.
The benchMEM case isolates the per-core gap by running the 82,000-atom system on 16 physical cores of socket 0 on every platform, so core count is out of the equation, and the result reflects vector throughput, cache, and local memory.
Here Vera posted 44.1 ns/day. The 5.0GHz EPYC 9175F doubled that at 87.8, and the EPYC 9965 reached 66.3, 1.5x Vera, ahead of the Xeon 6787P at 57.6, the 6978P at 54.5, and the 8592+ at 51.5.
A 16-core slice of Vera therefore does about two-thirds the work of a 16-core slice of a Zen 5c part, even though those 16 Zen 5c cores share a single 32MB L3 while Vera’s can draw on its 164MB system-level cache. That makes this the clearest measurement we have of what 128-bit vectors cost on code written for 512-bit ones. The 9175F’s further lead over the 9965 is roughly in line with its clock advantage, 5.0GHz against 3.7GHz.
OpenFOAM
OpenFOAM moves the pressure from the vector units to the memory system. We run OpenFOAM 13 on the driverFastback automotive aerodynamics case, with one MPI rank per physical core, at two mesh sizes: a 2.98-million-cell medium mesh and a 22.6-million-cell large one.
The medium mesh solved in 106.0 seconds on Vera, against 95.0 on the EPYC 9965, 112.7 on the Xeon 6978P, 139.0 on the 6787P, 173.3 on the 8592+, and 220.6 on the 32-core 9175F. At this size, the 9965’s 384 cores win, and Vera takes 12% longer but finishes second, 6% ahead of the 240-core Xeon. With only 3 million cells, the x86 parts’ larger L3 caches likely hold more of the problem, which keeps core count in charge.
The large mesh reverses the order, with Vera solving it in 1,854 seconds, against 2,227 for the Xeon 6978P, 2,678 for the EPYC 9965, 3,920 for the 6787P, 4,250 for the 8592+, and 4,788 for the 9175F, making it 1.44x faster than the 384-core AMD server and 1.20x faster than the 240-core Intel one. Vera also stays within a rated maximum of 450W per socket, compared with the 9965’s 500W.
Analytics and In-Memory Data
The HPC results showed what Vera’s bandwidth does for a scientific solver. Data services put the same memory system to work differently, and our two tests pull on it from opposite ends. ClickBench runs analytical queries that scan and aggregate large columns of data, spreading each query across every core, so it rewards a system that pairs many cores with the bandwidth to feed them. Valkey, an in-memory key-value store, handles millions of small requests, each reading or writing a single value, so it depends more on how quickly an individual core turns a request around and, once the data outgrows cache, on memory latency and bandwidth.
ClickBench
We tested ClickBench with 43 queries against a 100-million-row web analytics table on ClickHouse 26.8. Its hot sum, where every query reads from page cache, measures how many cores a system can bring to columnar scans and aggregations and how well its memory keeps them fed. The cold sum adds a server restart and SSD reads before each query’s first execution.
With SMT off, Vera completed the hot run in 2.09 seconds, the fastest result in our set. The EPYC 9965 came next at 2.70 seconds, taking 1.29x as long, while the Xeon 6787P, EPYC 9175F, and Xeon 8592+ were effectively tied between 2.93 and 3.04 seconds. The spread reflects the balance between cores and bandwidth. The 384-core 9965 has cores to spare but little bandwidth per core; the 32-core 9175F has the reverse; and Vera pairs 176 cores with more than three times the bandwidth of either.
Vera also led the cold run at 5.70 seconds, ahead of the 9175F at 7.12, the 6787P at 7.86, the 8592+ at 8.68, and the 9965 at 9.61. The cold sum leans more on storage, and the drive links differ: Gen5 x4 on Vera and the 6787P, x2 on both EPYC systems, and Gen4 on the 8592+.
Vera also loaded the 15GB dataset fastest, in 6.4 seconds, compared with 7.3 on the 9965 and 10.2 to 16.4 seconds on the rest. The Xeon 6978P, at 9.75 seconds hot and 25.47 seconds cold, fell far outside the other Xeons for reasons we have not identified, so we leave it out of the rankings.
Turning on Spatial Multithreading slowed Vera down to 2.31 seconds hot and 6.09 seconds cold, a 10% penalty on the hot sum. Splitting each core’s resources between two threads cost ClickHouse’s scans more than it gained.
Valkey
Valkey executes commands on a single main thread, with I/O threads helping only up to a point, so deployments grow by adding shards, since giving one instance more cores does little. We therefore look at Valkey two ways: what a single shard delivers on matched cores, and what each shard delivers when a socket is packed with them. In both tests, the clients run on the other socket of the same machine, so no network card is involved.
The single-shard test gives one Valkey server nine physical cores on every platform. It serves a 3-million-key data set with requests sent one at a time, then in batches of 10, and then serves a 256GB data set, too large for any cache, in batches of 16. Sent one at a time, each request has to complete its round trip before the next one goes out, and this is where Vera is weakest. Its shard served 385,000 GET requests per second, ahead of only the Xeon 6978P, while the EPYC 9965 led at 692,000. Vera’s p99 latency was also higher, at 1.76ms against 1.08ms on the 9965.
Batching removes most of that round-trip cost, and Vera moves to the front. With batches of 10, its shard handled 2.45M GET requests per second, 13% more than the 9965 and well ahead of every Xeon. The 256GB data set widened the gap further. With nearly every request going to memory, Vera served 1.59M GET requests per second, 34% more than the 9965, while the rest of the field ranged from 0.53M to 0.92M. SET results followed the same pattern in both tests.
Socket mode packs socket 0 with identical shards of four or eight cores, all serving traffic at once, which is closer to how a dedicated Valkey host runs. With 8-core shards and batches of 16, each Vera shard delivered 2.07M GET requests per second, ahead of the 9965’s 1.92M and about 1.6x the Xeon 6787P and 8592+, although its p99 latency rose to 2.2ms against about 0.5ms on the 9965.
With smaller 4-core shards, AMD came out ahead: the 9965 at 1.26M GET per shard against Vera’s 0.95M, though Vera still led every Xeon. With requests sent one at a time, the 9965’s shards were 1.5x to 1.7x faster than Vera’s at either size, and the 6787P and 8592+ also pulled ahead on 8-core shards.
Density decides the socket total: a Vera socket holds 11 eight-core shards and served 22.8M GET requests per second, while the 9965’s 192 cores hold 48 four-core shards and served 60.3M. Vera delivers the fastest shards in our set once each shard has eight or more cores and requests are batched, but the 9965 fits more than twice as many shards into a socket.
Single-Thread and Throughput
Valkey and ClickBench leaned on the memory system as much as on the cores. This section turns to the cores themselves and to the two goals behind Olympus described earlier: finishing individual tasks quickly, and holding that speed when the entire socket is busy. 7-Zip, OpenSSL, and Python each run as a single thread pinned to one core, showing what an Olympus core can do on its own. 7-Zip and OpenSSL then run again across every thread in the system, showing how much of that per-core speed survives once every core is competing for the same caches and memory.
7-Zip
7-Zip’s LZMA compression is branch-heavy integer code with unpredictable memory access, the kind of work Olympus’s 10-wide front end and graph prefetcher are designed for.
On a single thread, Olympus was the fastest compressor in our set. It reached 9,537 MIPS, 12% ahead of the 5.0GHz EPYC 9175F, the fastest x86 core here, and well clear of the EPYC 9965 and every Xeon. Decompression was a dead heat between the two: 6,016 MIPS for Vera and 6,000 for the 9175F, with no other system within 20%.
Running across every thread shows how much of that lead survives when the whole system is busy.
With every thread busy, the EPYC 9965’s 768 threads took the top spot at 1,527 GIPS compressing and 2,081 GIPS decompressing. Vera’s 352 threads came second at 957 and 1,496 GIPS, ahead of every Xeon, with the 6787P closest at 907 and 931. Measured per physical core, Vera holds up well. Its 5.4 GIPS of compression per core matches the 6787P and 8592+ and beats the 9965’s 4.0, and its 8.5 GIPS of decompression per core is 57% higher than the 9965 and beats every Xeon. Only the 32-core 9175F, with far fewer cores sharing each socket’s caches and memory, did more per core on both.
OpenSSL
OpenSSL’s AES-256-GCM test is where Vera gives up the most ground. Only two of Olympus’s six 128-bit SVE2 pipes can execute crypto instructions, while the x86 parts can run AES on 512-bit registers with VAES.
The gap is clearest on a single thread. One Olympus core encrypted at 6.2GB/s, about a third of the 19.3GB/s on the EPYC 9175F, and well behind the EPYC 9965 at 14.6GB/s and the Xeon 6978P at 13.5GB/s.
Across every thread, the x86 systems line up by core count, which shows where that per-core deficit leaves Vera.
With all 352 threads busy, Vera reached 1.26TB/s, level with the 128-core Xeon 8592+ at 1.28TB/s and ahead of only the 32-core EPYC 9175F. The EPYC 9965 led at 3.96TB/s, about three times Vera’s result, followed by the Xeon 6978P at 2.57TB/s and the 6787P at 1.86TB/s.
PYTHON
Python is central to the agent sandboxes NVIDIA is targeting with Vera, and pyperformance gives us three pinned single-thread tests of it: go, an object-heavy game-tree search; regex_compile, which compiles regular expressions; and nbody, a floating-point physics simulation. One software difference applies here: Vera ran Python 3.14.4 from Ubuntu 26.04, while the x86 systems ran 3.12.3 from Ubuntu 24.04, and the newer release brings interpreter speedups.
Vera won the two tests built on branchy, object-heavy code. go finished in 58.1ms, 15% faster than the EPYC 9175F, the fastest x86 core here, and 1.6x to 2.1x faster than the rest of the field. regex_compile showed a wider margin, finishing in 53.1ms, 25% ahead of the 9175F and 1.7x ahead of the EPYC 9965. Because Vera also had the newer Python, read both margins as upper bounds.
nbody went the other way, since its short floating-point loop and tiny working set tend to favor high clocks, and the 5.0GHz 9175F won at 42.2ms, 39% faster than Vera’s 58.8ms. The Xeon 6978P and EPYC 9965 also finished ahead of Vera, at 54.3ms and 56.7ms, even with Vera’s newer Python.
Web Serving, JVM, and Scheduler Latency
The last group of harness tests covers the software that surrounds an application: the web stack, the Java virtual machine, the Linux scheduler, and the compiler toolchain. These results depend as much on how many threads each system runs as on how fast each core is, so they say less about Olympus itself than the earlier sections do, but they show how a Vera server behaves under everyday server software.
Nginx
NGINX serves HTTPS requests to the wrk load generator running on the same machine, so client and server compete for the same cores, and the result reflects the TLS and HTTP stack more than raw core count.
With SMT on, Vera handled 306,000 requests per second at 1,000 connections and 292,000 at 4,000, in the middle of a field that ran from 263,000 on the Xeon 6978P to 402,000 on the Xeon 8592+. The EPYC 9965 reached 354,000, and the Xeon 6787P 337,000, and turning SMT off lifted Vera to 330,000. Vera’s network stack sits comfortably alongside the x86 systems.
Renesance
Renaissance runs Java workloads on OpenJDK 11. Its Finagle HTTP test exercises a Scala networking stack, and its Akka test an actor-model concurrency framework. Both spread work across every logical CPU the JVM can see, so we ran them with SMT on and off.
Finagle runs faster with fewer threads. Turning SMT off, which halves the thread count, cut Vera’s time from 9.8 to 4.3 seconds, and the larger x86 systems improved by a similar 2.3x to 2.5x. The 32-core EPYC 9175F, with few threads to begin with, led either way at about 3 seconds.
Akka favored the Xeon 8592+, which finished in about 18 seconds with SMT on or off, while Vera took 40.5 seconds with SMT on, and the two largest systems, the EPYC 9965 and Xeon 6978P, were slowest at 101.7 and 119.8 seconds. The third Renaissance test, a genetic algorithm, finished in 1.6 to 2.6 seconds with SMT on across every system except the 6978P, with Vera at 2.6.
schbench
schbench measures how quickly the Linux scheduler wakes worker threads, running about one worker per logical CPU with 4 message threads and about eight per CPU with 32. Because the worker count grows with the system, larger servers do more work, so these results describe latency under full load on each machine and are not a like-for-like comparison.
With 4 message threads, Vera’s median wakeup latency was 221µs and its p90 396µs, higher than every system except the Xeon 6978P at 536µs and 878µs. The smallest machines woke their threads fastest, with the 32-core EPYC 9175F at 19µs and the 128-core Xeon 8592+ at 61µs.
Oversubscribed with 32 message threads, Vera moved to the middle of the pack. Its 5.0ms median and 16.1ms p90 were level with the Xeon 6787P and 8592+ and ahead of both the Xeon 6978P and the EPYC 9965, which reached 27.5ms at p90. Only the 9175F was clearly faster, at 3.0ms and 9.7ms.
Linux Kernel Build
The Linux kernel allmodconfig build is the one result in this section we do not rank. Vera compiles the arm64 kernel tree, which includes a different set of modules and drivers from the x86-64 tree the other systems build, and we did not attempt a cross-compile.
Vera built its tree in 180.7 seconds with SMT off and 196.4 seconds with SMT on, so the extra threads slowed the build. Across the x86 systems, each building a native tree, times ranged from 146.2 seconds on the EPYC 9965 with SMT off to 382.2 seconds on the 32-core EPYC 9175F.
HammerDB
For the database tests, we brought in Steve Shaw, HammerDB’s creator and maintainer. Shaw ran HammerDB’s TPROC-C workload, an OLTP benchmark derived from TPC-C but not comparable to published TPC results, on the Vera server, the Dell PowerEdge R7725 with EPYC 9965, and the PowerEdge R770 with Xeon 6787P. He tested five open-source engines on each: MariaDB 12.3.3 and 13.0.2, MySQL 26.7.0, VillageSQL 0.0.7, and PostgreSQL 18.6. The database size scaled with core count at 16 warehouses per physical core, or 1,408 for a single Vera socket.
Each engine ran on one socket and on two, with the second socket’s CPUs taken offline for the single-socket runs, and every system did better on one, typical for database performance. Across all 15 pairs, adding the second socket cut peak throughput by 23% to 47%, and by 29% to 45% on Vera. Shaw has long found that open-source databases hit a scaling ceiling before they run out of cores. Beyond that point, keeping caches coherent across two sockets costs more than the extra cores add. We therefore focus on the single-socket results, shown in the chart below.
On one socket, 88 Vera cores led on three of the five engines. PostgreSQL 18.6 gave Vera its widest margin, at 3.31M new orders per minute (NOPM) with 128 virtual users, compared with 2.62M on the 192-core EPYC 9965 socket and 2.45M on the 86-core Xeon 6787P. Both MariaDB releases also went to Vera, at 2.68M and 2.67M, compared with 2.48M and 2.47M on the EPYC. AMD kept MySQL 26.7.0 at 2.51M against 2.03M for Vera, and VillageSQL at 3.00M against 2.54M. The Xeon trailed on all five engines by 1.21M to 2.45M, and its MariaDB results were less than half of Vera’s.
The split likely follows how each engine scales. PostgreSQL’s process-per-connection model and MariaDB’s InnoDB both spread work across many cores with heavy shared-memory traffic, which plays to the more than 1TB/s of local bandwidth each Vera socket sustained in STREAM. MySQL and VillageSQL hit internal lock contention sooner, so their results depend more on how quickly each core clears a critical section, and that’s where the 9965 comes out ahead. After the October round, Shaw judged Arm the fastest platform overall, saying Arm “has definitely arrived as a competitive database server,” though he added that a single-socket 96-core EPYC he had tested earlier might edge it.
Tail latency at a matched load of 144 virtual users shows the same split. Vera’s PAYMENT p99 latency ranged from 1.92ms on PostgreSQL to 2.98ms on MySQL. The EPYC 9965 held MySQL, VillageSQL, and PostgreSQL between 1.33ms and 1.40ms, 29% to 53% lower than Vera, but its 3.13ms on MariaDB 13.0.2 trailed Vera’s 2.92ms. The Xeon 6787P’s MariaDB tails, at 14.4ms and 17.1ms, were several times higher than either, in line with its much lower throughput at the same load. Lock handoff inside the engines likely drives Vera’s higher tails, echoing the Valkey results, where requests sent one at a time also favored AMD.
The November round put Shaw’s hunch to the test. He ran the same workload on one socket of AMD’s new 256-core EPYC 9996 and on a 96-core EPYC 9686F, with Vera’s socket in the comparison. The 9996 and Vera traded engines, with Vera keeping PostgreSQL and MariaDB and the EPYC leading on tail latency, and the 96-core part edged Vera on PostgreSQL. The full results are in our AMD EPYC Venice review.
“I was genuinely impressed by the performance of open-source databases on NVIDIA Vera. It’s great to see Arm competing at the top end of database performance and bringing a compelling alternative to the enterprise market,” said Steve Shaw, the creator and maintainer of HammerDB, after the round.
Závěr
Vera isn’t the fastest processor in every category because AMD answers each end of the market with a dedicated part. The frequency-optimized EPYC 9175F is built for per-core speed and still wins workloads that reward a fast clock, from Python’s nbody and single-thread AES to one-at-a-time Valkey requests. The EPYC 9965 is built for throughput and wins the work that scales with core count, including GROMACS, all-thread 7-Zip and AES, and the number of Valkey shards that fit in a socket.
Where Vera stands apart is in the middle, and in how close it comes to each of those specialists on their home ground. On a single thread, it matched or beat the 9175F on integer work and two of the three Python tests, compressing 12% faster on 7-Zip and running go and regex_compile 15% and 25% faster, while trailing on floating-point and crypto.
Across the whole system, it reached 63% to 72% of the 9965’s all-thread 7-Zip rates and finished the medium OpenFOAM mesh within 12% of it, then moved ahead once memory took over, on the large mesh and on ClickBench. Staying that close to the per-core leader on one thread and to the throughput leader across the whole system is what makes Vera such a strong general-purpose processor. For buyers who want one platform for the broad middle of the market without giving up much at either end, it’s an extremely strong offering.
Vera delivers far more memory bandwidth than any x86 system we tested. Two Vera sockets sustained 2,073GB/s on STREAM Triad, 2.3x the best DDR5 server here, and NVLink-C2C keeps that bandwidth within reach across sockets: Vera’s cores read the other socket’s memory at 677GB/s, more than any x86 socket reads from local memory.
Memory-bound workloads followed: the large OpenFOAM mesh solved 1.44x faster than on the EPYC 9965, ClickBench’s hot run finished in 2.09 seconds against 2.70, the 256GB Valkey working set ran 34% faster, and on one socket Vera led HammerDB on PostgreSQL and both MariaDB releases. The link cost is latency: a remote read takes about 2.1x as long as a local one, against 1.75x on the EPYC 9175F, so NUMA-aware placement and hugepages still matter on Vera.
The weaknesses are surprisingly thin and trace directly to the design. Six 128-bit SVE2 pipes do not match 512-bit AVX-512 units on code written for them, so a 16-core slice of Vera ran GROMACS benchMEM at half the rate of the 9175F and two-thirds the rate of the 9965. With only two of those pipes handling crypto, a single Olympus core encrypted AES-256-GCM at about a third of the 9175F’s rate.
How Vera shapes up will largely be down to the OEM partners. Dell’s PowerEdge R8822 began shipping in October with the M9882 Vera CPU Rack due in the first quarter of 2027, HPE’s ProLiant Compute DL394 Gen12 arrives this fall, Supermicro has its 256-CPU Vera rack available to quote with air-cooled 1U and 2U Vera systems in the lineup, and ASUS, ASRock Rack, QCT, GIGABYTE, MSI, Compal, Foxconn, Pegatron, Wistron, and Lenovo have all shown Vera designs. Oracle Cloud has Vera instances generally available, with CoreWeave, Nebius, Lambda, and others following.
Vera is the first Arm server processor we have tested that belongs in the same conversation as the x86 flagships on general-purpose work, and the first processor from any vendor to put 2TB/s of memory bandwidth in an air-cooled two-socket box. For the broad middle of the market, it’s a credible option today, and NVIDIA enters the CPU market with a memory subsystem nobody else ships. For vector-heavy HPC and crypto-bound services, the x86 specialists keep their lead. We will put the OEM systems through the same suite as they reach the lab, starting with the agentic-sandbox role NVIDIA built this processor to fill.
Žebříček: NVIDIA Vera holds Best Arm Implementation on our Nejlepší servery výsledková tabulka.
Amazon