Nvidia deep dives Vera CPU for AI data centers — SPEC CPU 2026 benchmarks revealed, Olympus architecture specifics, and more

Nvidia’s Vera CPU is its first bid to become a key player in the data center CPU market. Although Grace has seen some success (most notably with Grace standalone deployments at Meta), Vera is Nvidia’s first CPU with a custom core design. It’s arriving at an ideal time, as well, with the server CPU market exploding in the last few months on the back of agentic AI demand.

Vera isn’t a chip built to chip away at the market share of AMD and Intel in the cloud. It’s built to grab market share in an expanding market, as hyperscalers look to widen AI infrastructure beyond legacy clouds. As such, it’s designed in a much different way than Nvidia’s x86 competitors, and it even holds some unique architectural design points compared to the swath of Arm-based designs.

Nvidia has slowly revealed more details about Vera as it ramps into general availability, which is on track for the back half of this year. Now, we have a full picture of the chip. Nvidia shared its Vera white paper, along with unofficial SPEC CPU 2026 results comparing Vera to AMD’s Turin-based Epyc 9755.

We’re going to break down the white paper here, including all of the details about the Olympus core and a look at the benchmarks Nvidia ran. At the end of this piece, we’ll also take a brief look at the larger context of Vera and how it fits into Nvidia’s wider AI ecosystem compared to standalone deployments.

But plenty of ink has been spilled about Vera’s technical capabilities and Nvidia’s next-gen AI infrastructure vision. Let’s start with the important thing: the benchmarks.

Nvidia Vera CPU benchmarks

We’ve seen Vera in action before, though only through a series of selected benchmarks ran at Nvidia HQ by Phoronix. In the Vera white paper, Nvidia shared benchmarks for SPEC CPU 2026, specifically the integer suite from SPECrate, against AMD’s Epyc 9755, with both chips running in a dual-socket configuration. Before getting into the results, there are some important notes about how SPEC runs work, and the reporting criteria for them.

Nvidia’s run here isn’t official, as Vera was tested in a reference system due to the fact that it’s not broadly available yet. It’s ramping for general availability in the second half of the year. Due to that, Nvidia is unable to report its results. That’s why you see “estimated” in some of the charts below. Nvidia ran SPEC CPU 2026; it’s not extrapolating expected performance like we’ve seen from AMD so far with its upcoming Venice chips.

SPEC CPU 2026 is split into four suites, but Nvidia tested the SPECrate integer suite, which is focused on system throughput with integer-based workloads. The “rate” result is looking at how much work is completed within a certain amount of time. Here, each thread in the system has a copy of the workload. The score is how much time it takes for those workloads to complete, regardless of thread count, naturally giving chips with more cores an advantage.

If you want more detail on the benchmarks included in the suite, make sure to read our original coverage of SPEC CPU 2026. Here are the overall results:

Nvidia didn’t share the exact results for the 9755 it tested, short of the overall score of 898. Taking that overall score into account, Vera is 3% ahead of the 9755. It’s worth noting that Vera is ahead here despite a large thread disadvantage. An overall score of 898 for a dual-socket Epyc 9755 system isn’t unreasonable compared to publicly-submitted SPEC CPU 2026 runs, though higher results have been published. SPEC CPU ships as source code, which the tester must compile with their compiler of choice, and that can heavily influence results (particularly with vendor-specific compilers). Nvidia used GNU 15.2 with both systems.

Above, you can see Vera’s results stacked up against the 9755, but these aren’t comparing the numbers directly. Nvidia has normalized the per-core performance, which isn’t how SPECrate results are normally shared. According to the overall numbers, Vera is still completing more work within the same amount of time, despite a thread disadvantage, but the margins aren’t in the range of a 70% or 80% advantage as the above chart suggests.

We asked Nvidia about the results given that they’re obfuscated by comparison; we could not reverse-engineer the Epyc 9755’s scores with the information Nvidia has provided. Here’s the response it gave: “Per-core performance under a fully loaded socket is important because agentic AI and RL run many sandboxes concurrently, while each agent step remains sequential and latency-sensitive. It measures how much performance each core sustains amid contention for shared power, memory, cache, and fabric. We therefore normalize by physical core, with SMT enabled on both systems.”

The “agentic” workloads Nvidia has highlighted here are code compilation and interpretation workloads, which is something an agent is often doing, querying repos for dependencies and building source code. Below are data science workloads (or Exploratory Data Analysis), and below that are data processing workloads like SQLite database management. The results here align with Nvidia’s overall messaging of Vera, that it’s highly competent at data-rich, backend operations.

Although Nvidia is sharing per-thread results, it argues that SPECrate is still the correct benchmark to run. The per-thread results here are in the context of a fully-loaded socket. Here’s the justification from the white paper: “This metric is non-trivial for agentic AI and RL systems, where many sandboxes, tools, and environments run concurrently rather than as isolated single-thread tests. Fully loaded per-core performance captures how well each core sustains throughput while sharing socket-level power, memory bandwidth, cache, and fabric resources.”

In addition to running the workloads, Nvidia analyzed the code execution for architectural benchmarks, which you can see in the gallery above. Nvidia claims an overall IPC gain of up to 1.9x compared to Turin, up to 2.3x more branch predictions and 3.5x taken branches per cycle, and up to 2.4x higher instruction fetch operations per cycle.

Outside of SPEC, Nvidia shared a few benchmarks highlighting the capabilities of the Olympus core. First up is PageRank, an algorithm developed by Google to originally rank web pages, which highlights Olympus’ prefetch engine. Nvidia scaled this workload to higher core counts, showing Vera maintaining much of its single-core performance up to 32 cores, while the Turin chip hits a wall around 20 cores.

In addition to the above results, Nvidia shared some tests of the Vera memory system compared to Turin. These microbenchmarks are good for validating Nvidia’s specifications, but they’re looking at architectural performance, not application performance. An architectural advantage translates into a performance advantage, but not always in a linear, expected fashion.

Nvidia used internally-developed tools for the memory tests, though they’re available on GitHub for anyone to run.

First is loaded memory latency, stressing the memory subsystem as bandwidth usage increases. Vera has much higher bandwidth overall, but you can see the Turin chip hit a latency wall below its maximum, which Nvidia attributes to Non-Uniform Memory Access (NUMA) domain traversal and CCD-to-CCD latency.

Looking at per-core bandwidth, Nvidia claims Vera provides more than four times the bandwidth of AMD’s 9755. The suggestion here is that “real-world” per-core bandwidth is even better than Nvidia’s specs lead on (or perhaps worse than AMD’s).

Maybe the most consequential of these tests is the one you can see above, looking at core-to-core latency. It’s no secret that crossing the CCD on AMD’s chiplet-based architecture incurs a big latency penalty. You can see that in action even in our Ryzen 9 9950X3D2 review, and the penalties compound as you scale up the number of CCDs.

In fairness to AMD here, chiplet-based designs aren’t built for this type of cross-CCD traversal, preferring to keep workloads localized and optimizing for core density. Vera’s design goal is clearly to keep latencies consistent across the entire die and sacrificing core density in the process. Nvidia’s Ian Buck told us that this design trade-off “will come at the cost of the legacy workload,” when we recently visited Nvidia HQ.

That’s important context. Nvidia isn’t gunning to steal existing market share from AMD and Intel as much as it’s trying to grab market share in an expanding market before AMD and Intel can. Some financial institutions (including Morgan Stanley and Bank of America) suggest the server CPU market could double in size (or grow even larger) by 2030. That context is important because there will be a continuing demand for CPUs that can handle workloads Vera is not optimized for, and it’ll be interesting to see how AMD and Intel tackle that dynamic with future products, trying to keep a legacy base of customers while pushing ahead into the expanded market.

Nvidia clearly has a vision of how that expanded market looks, and to that end, hasn’t shared SPEC CPU floating point results. Presumably, this is due to the fact that SPEC’s vectorized suite is focused primarily on HPC workloads, whereas Nvidia focused on what it believes are critical agentic workloads that are integer-based. Vera has a vector engine complete with SVE, but that doesn’t seem like Nvidia’s focus.

In an end-to-end Nvidia system, those vectorized workloads would be offloaded to a Rubin GPU. Still, we don’t have any vector results for Vera yet. Up to this point, we’ve only seen integer results, which is strange given the memory system at play in Vera.

Vera is Nvidia’s first CPU with a core design created in-house, which is the Olympus core. It’s built on Arm v9.2-A, but the design was created by Nvidia, unlike Grace, which leveraged a stock Arm design. Each Vera CPU has 88 Olympus cores on a monolithic die, breaking from the chiplet-based designs available from Nvidia’s x86 competitors.

Nvidia says Vera comes with a 1.5x increase in instructions per cycle (IPC) throughput compared to Grace, and 50% higher performance compared to x86 competitors (it seems that number is per-thread performance with a fully-loaded socket). Nvidia has a single 88-core design with Vera that supports spatial multithreading for 176 threads.

The CPU has a configurable TDP range of 250W to 450W. It uses a SOCAMM2 LPDDR5X memory system with capacity of up to 1.5 TB and speeds up to 9600 MT/s, and comes with 164 MB of L3 cache and 2 MB of L2 per core. Vera includes significantly less L3 than Intel’s highest-specced Xeon 6 and AMD’s Zen 5 chips. It actually has more L2 than L3 overall. This, presumably, is due to Nvidia’s fabric, which distributes the L3 in a mesh across the monolithic die.

Below, you can see a layout of the Olympus microarchitecture. Nvidia has disclosed some of the highlights of the architecture previously, such as the 10-wide instruction decode and neural branch predictor, but we now have a full view of the architecture courtesy of Nvidia’s Vera white paper.

The front end starts with Nvidia’s neural branch predictor that can run two branches per cycle “with zero penalties,” according to Nvidia. Research on neural branch prediction dates back to the late 90s, but Nvidia says it has a “novel” neural branch predictor, perhaps building on previous research such as BranchNet.

The BPU feeds into the Instruction Fetch Unit, which holds 64 KB of L1 instruction cache, and loads into a decode queue that supports 48 instructions (we’ll go into the memory/cache layout later). At the last stage of the front end is that 10-wide decode, feeding more instructions into the execution engine per cycle than the 8-wide decode in AMD’s Zen 5 microarchitecture.

Past the front end, the mid-core rename / allocation engine is built to keep instructions moving while waiting on dependencies. In addition to renaming and allocation, instructions work through value prediction, which can speculatively execute the instruction, and memory renaming, where the instruction can move forward while a load is happening if the data relationship can be determined.

Inside the execution engine, Nvidia includes eight simple Arithmetic Logic Units (ALUs), two complex ALUs, and four branch units for resolution. For SIMD instructions, the execution engine includes a vector cluster for Arm’s Scalable Vector Extension (SVE), including six vector units that support 128-bit SVE instructions at FP8 precision, along with two crypto-enabled vector units that can handle AES, SHA, and SM3, among other prominent algorithms. Keeping data moving through the engine are four load units and two store units.

The cores support spatial multithreading, giving a Vera CPU with 88 cores access to 176 threads. Traditional SMT time-slices execution, giving both threads access to all of the core resources and sharing them as instructions execute in parallel. With spatial multithreading, each thread of an Olympus core has access to dedicated resources, allowing one of the threads to execute with high-throughput while the other thread handles simple tasks, or to operate as two independent execution environments.

The execution resources are partitioned, explaining the wide decode front end. It’s not clear, however, if the SMT implementation can also opportunistically grab resources, particularly in the scenario Nvidia describes where one of the threads is maximizing throughput while the other handles smaller tasks.

There’s a lot going on in Vera between the 10-wide decode, neural branch predictor, and spatial multithreading, but perhaps the most significant architectural design point is Nvidia’s second-generation Scalable Coherency Fabric (SCF). It underpins Nvidia’s approach of using a monolithic die as opposed to a chiplet-based design, distributing last level cache in a mesh across the die and avoiding the cross-CCD latency penalty with localized L3.

The mesh distributes data through a series of Coherency Switch Nodes (CSNs) that serve as routing points between cores and the 164 MB of distributed L3. These routing points further connect the cores and L3 to the memory system, I/O, and NVLink C2C for cache-coherent communication between chips. Nvidia’s benchmarks comparing Vera to AMD’s Epyc 9755 show that AMD can achieve slightly lower core-to-core latencies within a cluster, but Vera maintains significantly better core-to-core latency across the die, as expected.

Nvidia says SCF inside Vera has 3.4 TB/s of bandwidth, enabling faster core-to-core communication, especially when traversing the die. However, Vera also supports Memory System Resource Partitioning and Monitoring (MPAM), allowing portions of L3 to be partitioned in multi-tenant environments.

Vera uses SOCAMM2 LPDDR5X, which is a relatively new advancement that Nvidia’s competitors haven’t had the chance to benefit from. With the use of SOCAMM2, LPDDR5X provides similar modularity and capacity as traditional RDIMMs, but at significantly lower power draw.

The memory can run at up to 9600 MT/s, with aggregate bandwidth of 1.2 TB/s and per-core bandwidth of 14 GB/s, doubling the bandwidth of Grace. The Vera board supports eight SOCAMM2, offering capacity ranging from 256 GB to 1.5 TB. Nvidia claims a “fully populated” memory subsystem consumes between 30W and 40W depending on capacity.

For I/O, Vera supports PCIe 6.4 with 88 lanes per CPU and bifurcation support down to x2. It also supports CXL 3.1.

Unlike Grace, Vera includes Arm’s Confidential Computing Architecture (CCA) and Realm Management Extension (RME), including Device Assignment and Coherent Device Assignment, offering a boon to multi-tenant environments where VM isolation is key. Nvidia also implements TDISP for coherent devices, allowing for encrypted communication between GPUs and PCIe devices.

Nvidia is already sampling Vera as a standalone chip to partners, and it says it will continue to do so, but the vision is an end-to-end solution built on Nvidia’s CPUs, GPUs, switches, NICs, and even rack specifications. Nvidia doesn’t make all of these individually, at least not at scale — just like with desktop graphics cards, Nvidia provides its MGX reference design, which customers can purchase, but partners also offer their own racks, some built solely to Nvidia’s specifications and others with more speciality.

Each tray comes with two Vera Rubin superchips, each of which contain a single Vera CPU to two Rubin GPUs, giving you two CPUs and four GPUs per tray. At the front, Nvidia partitions off three spaces, with the MGX design carrying two NVIDIA ConnectX-9 SuperNIC on either side and a Bluefield 4 DPU in the middle. Critically, this design doesn’t include any hoses or fans. It’s entirely liquid cooled, and it contains just two cables throughout the entire tray.

Nvidia demonstrated this cable-less design, showing the Vera Rubin Superchip sliding in and out of the track with a retention mechanism in a matter of seconds. The company says assembling the rack takes less than a few minutes and is handled entirely by robots, which is a far cry from GB200 and GB300 trays.

GB200 and GB300 trays are dense designs, but they’re also cluttered with cables and hoses. Nvidia says this massively slowed down production time, eventually leading to production issues that delayed Nvidia’s rollout. The company says that won’t happen with Vera Rubin and its largely cable-less design. Whereas a Grace Blackwell tray took around two and a half hours to assemble by a human, the company says a Vera Rubin tray is assembled within five minutes and entirely automated by robots.

Each tray needs to dissipate several kilowatts of heat, which Nvidia says it’s able to do using dry cooling. Liquid cooling is nothing new in the data center, either through an external chiller (essentially an A/C unit) or evaporation, where a fan evaporates water over a mesh and cools without the need for a compressor. With Vera Rubin, Nvidia uses “dry cooling,” with a maximum inlet temperature of 45 degrees Celsius.

Nvidia says it’s able to get the full performance out of a tray given an inlet temperature of 45 °C, allowing trays to operate without an additional water consumption in environments up to 100 degrees Fahrenheit. The tray essentially uses a large closed-loop similar to what you find from a consumer AIO, just scaled up. Water moves out of the tray and outside the data center, and it passes through a radiator where fans dissipate the heat. There’s some extra power consumption from water pumps and fans, but not nearly on the scale of evaporation methods or chillers.

The result is a tray completely free of fans, essentially noise-less in operation, and doesn’t strain local water infrastructure. That’s what Nvidia says, at least. In many locations around the U.S. where data centers are located (Texas and Virginia chief among them), temperatures easily climb above 100 °F during the Summer, prompting some sort of backup method of cooling. Nvidia says the external temperature ceiling can go higher depending on different factors — running at lower power, for example, and using more efficient heat exchangers — but under normal conditions, 100 °F is the ceiling.

It’s worth noting that nothing about a Vera Rubin tray explicitly requires this method of dry cooling; the hardware is just capable of offering full performance with an inlet temperature of 45 °C.

In addition to an NVL72 design, Nvidia has a Vera standalone deployment that compacts each tray into a series of SOCAMM2 slots and Vera chips. In Nvidia’s 48U MGX design, a standalone Vera deployment can include up to 256 CPUs in a rack.

Underpinning scale-up communication is Nvidia’s sixth-generation NVLink, which is deployed as switches in the rack and connected to compute trays using Nvidia’s NVLink spine. You can see the spine on its own in the image above, which features over two miles of thin copper wire to allow every tray in the rack to communicate with each other.

Localizing storage, networking, security, and telemetry operations is Nvidia’s BlueField-4 DPU. A Vera Rubin NVL72 compute tray includes a single DPU and two ConnectX-9 NICs to maximize CPU/GPU utilization. You can read more about Bluefield 4 in our original coverage from GTC.