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

Page 1 of 3:

Nvidia Vera CPU

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.

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:

Swipe to scroll horizontally

Test	Run Time	Rate
706.stockfish_r	324	1370
707.ntest_r	251	830
708.sqlite_r	250	744
710.omnetpp_r	203	842
714.cpython_r	136	1240
721.gcc_r	296	817
723.llvm_r	196	909
727.cppcheck_r	142	890
729.abc_r	196	823
734.vpr_r	199	815
735.gem5_r	131	1300
750.sealcrypto_r	231	816
753.ns3_r	129	1670
777.zstd_r	469	483
Overall base score	Row 15 - Cell 1	925

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.”

Image 1 of 5

Nvidia Vera IPC — (Image credit: Nvidia)

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.

Image 1 of 2

Nvidia Vera Pagerank — (Image credit: Nvidia)

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.

Current page: Nvidia Vera CPU

Next Page Nvidia Vera CPU architecture -— A closer look at the Olympus core

TOPICS

Jake Roach is the Senior CPU Analyst at Tom’s Hardware, writing reviews, news, and features about the latest consumer and workstation processors.

7 Comments Comment from the forums

usertests

Throwing some shade at AMD. I see "Chiplet tax" on one of the slides.

But their comparisons (obviously) are to Turin rather than newly announced Venice.
Reply
bit_user

The article said:
Vera is Nvidia’s first CPU with a core design created in-house, which is the Olympus core.
Only if you're talking about server CPUs. Before that, they made at least two generations of cores for tablet/embedded SoCs (i.e. Denver and Carmel). See: https://en.wikipedia.org/wiki/Project_Denver

The article said:
It uses a SOCAMM2 LPDDR5X memory system with capacity of up to 1.5 TB and speeds up to 9600 MT/s
Ah, but you missed an interesting detail. The way you reach 1.2 TB/s with 9600 MT/s memory is by scaling the memory datapath up to 1024 bits, which is the equivalent of 16x DDR5 DIMMs! Because SOCAMM2 each have a 128-bit data width, you only need 8 of them. I was staring at a photo of the Vera board and wondering how they possibly reached 1.2 TB/s, and that's when it clicked that they actually packed a 128-bit datapath in those little memory modules!

Looking at the block diagram of the core, I'm struck by a few things.
The L1i cache is the same size as Intel's Lion Cove, but surprisingly only 4-way. Intel used 8-way associativity for their I-cache for almost the past 20 years!
At 64 entries, its iTLB is also much smaller than Golden Cove (the last Intel core I could find data for), which has 256 entries.
However, it regains some ground by being fully-associative, whereas the iTLBs of Intel CPUs usually have only 8-way associativity.
The dTLB is more comparable to the size recent Intel CPUs use (112 vs. 128 entries in Lion Cove), but also fully-associative whereas Intel typically uses only 4-way associativity.
At 96k, the L1d is running 2x of Intel's. As with the L1i, its associativity is less (6-way instead of 12-way for Intel).
Its L2 cache is comparable to Raptor Cove's in size, but it's only 8-way associative whereas Raptor had 16-way associativity.
Its STLB is similar in size to the latest Intel core I have data on (3k vs. Golden Cove's 2k).

The article said:
Research on neural branch prediction dates back to the late 90s
AMD said it used a neural network-based branch predictor in the original Zen cores. Jim Keller briefly discuss it, in an interview. They apparently had an open contest for people to submit branch predictor algorithms and the neural one simply beat all of the others. If you search the patent database, you might be able to find some on it. That's probably the best chance of finding out how it actually works.

The article said:
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.
The decoder in Zen 5 is hard-partitioned between threads, limiting each to only 4 instructions per cycle. Even if there's only one thread running on the core (or if you disable SMT in BIOS), it still uses only a single 4-wide decoder.

But. We should consider that x86 instructions can encompass more functionality than an ARM64 instruction. So, maybe a typical ARM instruction stream needs like 5 instructions to do the same work as 4 x86 instructions. Just spitballing, here. It's not a huge difference, since most instructions are fairly simple and operating register-to-register, whereas x86 instructions get a lot of their density advantage by combining memory loads/stores with some arithmetic or logical operation, and supporting more sophisticated address arithmetic.

Looking only at decode-width is a little misleading, because CPUs like Zen 5 have much wider dispatch (8-way) from their micro-op cache. Since these are now micro-ops, they're more equivalent to ARM64 instructions, in terms of how much work each represents.

BTW, there are two other obvious points of comparison:
The Neoverse V2 cores, used in Nvidia's prior Grace CPUs, have a 6-wide decoder* (source: https://chipsandcheese.com/p/hot-chips-2023-arms-neoverse-v2 )
The Cortex-X925 cores, used in Nvidia's RTX Spark, have a 10-wide decoder (source: https://chipsandcheese.com/p/arms-cortex-x925-reaching-desktop )
* Note that Neoverse V2 still has a mOP cache with 8-wide dispatch. So, as with x86 P-cores, the decoder width is a little bit deceptive.

The article said:
Past the front end, the mid-core rename / allocation engine is built to keep instructions moving while waiting on dependencies.
You skipped a pretty big detail: no mOP cache!
Modern x86 P-cores and some 64-bit ARM cores had micro-op caches to avoid having to re-decode the same instructions. Once ARM dropped 32-bit compatibility, they started getting rid of those. Also, Intel either doesn't have them in their E-cores, or perhaps what they did was to put some of that into the I-cache.

So, it's interesting (but not all that surprising) that Nvidia followed ARM's approach of just skipping the mOP cache, entirely.

The article said:
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
It's darkly ironic that SVE's main selling point was to allow CPUs to scale all the way up to 2048 bits per vector, but all mainstream implementations (except for AWS Graviton 3) are just 128-bit.

The article said:
Traditional SMT time-slices execution, giving both threads access to all of the core resources and sharing them as instructions execute in parallel.
Not really. The way AMD describes SMT in Zen 5 is that certain competitively-shared resources have watermarks that limit how much a single thread is able to use, so that it doesn't starve out the other thread. However, when there's only one thread running on a core, more of those constraints go away and only the statically-partitioned resources (e.g. the decoder) remain exclusive.

My read on "Spatial Multithreading" is that it's Nvidia's marking machine trying to spin a weakness to make it sound more like a strength. This being Nvidia's first SMT implementation (AFAIK), it won't have the same sophistication as where Intel and AMD have gotten, over a couple decades of experience implementing and refining theirs.

The article said:
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.
First, Intel has traditionally done the same thing. However, I need to catch up on what they've said about Sierra Forest.

Second, people tend to overestimate the impact of the cross-CCD thing. Unlike Intel CPUs, one AMD CCD won't write data to another's L3 slice. Each is private to that CCD, except for coherency. That said, when you've got multiple threads that are either exchanging or both modifying the same data, and they happen to be scheduled on different CCDs, that is when you feel the impact of the die-to-die communication.

Anyway, AMD's approach has clearly scaled better. I think that's why Sierra Forest looks like it moved in the direction of doing the same thing with segmenting its L3 cache.

The article said:
For I/O, Vera supports PCIe 6.4 with 88 lanes per CPU and bifurcation support down to x2.
I don't know what happened here, but the slide with the annotated die photo shows it supporting PCIe 6 with only 16 lanes.

P.S. As for the benchmarks, the initial Phoronix review was interesting, but now I'm just waiting for some independent analysis. From a CPU microarchitecture standpoint, what I really want to know is the single-threaded performance across the whole SPEC suite, and how the sub-scores compare with other CPUs. MT scaling is mildly interesting, but it really stacked that deck in its favor by having relatively few cores and huge amounts of memory bandwidth. So, I expect it scales well, but not well enough to outright beat Intel or AMD on anything that's not fundamentally bottlenecked by memory bandwidth.
Reply
bit_user

usertests said:
But their comparisons (obviously) are to Turin rather than newly announced Venice.
Announced? Venice is launching in about a week! That's probably why Nvidia is making a bunch of noise about this now!
Reply
Stomx

I like NVIDIAs marketing department scaling results per core. This is the height of aerobatics. Interesting how all would compare per core with the AMD 64core Turin 9575F, their king of single core benchmarks ? And how per core comparison will look for just the 64 core Venice? Huang will leave full of tears on leather jacket
Reply
bit_user

Stomx said:
I like NVIDIAs marketing department scaling results per core. The height of aerobatics. Interesting how all would compare per core with the AMD 64core Turin 9575F, their king of single core benchmarks ?
Good question. Where Vera has a big lead over AMD's Turin is that it has basically 2x the memory bandwidth. Also, ARM uses memory bandwidth a little more efficiently, due to its relaxed memory consistency model.

Where AMD would win biggest is going to be on AVX-512 stuff that's not memory-bound.

Otherwise, it looks to me like Vera might have a slight edge over Zen 5. I mean it's a 10-way dispatch core vs. an 8-way one. Even Zen 6 will remain 8-way, if the rumors are correct. Not to say dispatch width is everything, since Intel's cores are also wider, but it's at least a good starting point. I think Zen 5 does have 3 integer multiply ports vs. Vera's 2.

Stomx said:
And how per core comparison will look for just the 64 core Venice? Huang will leave full of tears on leather jacket
Yeah. With Venice, AMD is going to leap-frog Nvidia's memory bandwidth by approximately 33%, according to what they've said. That's to be accomplished using 16 DIMMs (matching the same data width as Vera of 1024 bits) using MRDDR5-12800. So, on low core-count models, they'd stomp Nvidia on per-core memory bandwidth.
Reply
palladin9479

Performance isn't really important, it's only real job is to manage the workloads for the GPU like devices connected to it. It only needs to be fast enough to not make the GPUs wait around.
Reply
bit_user

palladin9479 said:
Performance isn't really important, it's only real job is to manage the workloads for the GPU like devices connected to it. It only needs to be fast enough to not make the GPUs wait around.
I think that explains why it doesn't have a lot of cores, but it doesn't explain why Nvidia went to the trouble of designing their own cores instead of just licensing the next Neoverse V-series core, like they did in their Grace CPU and like Amazon did since Graviton 3.

Arm's Neoverse V3 seems to be derived from their Cortex-X4, which is also a 10-way core (source: https://www.androidauthority.com/arm-cortex-x4-explained-3328008/ ), though it has only 4x SVE2 pipes. However, I think the X4 and V3 are probably more efficiency-focused and don't clock very high. Graviton 5 uses Neoverse-V3 at 3.3 GHz, for instance.

So, it seems like the main things it seems Nvidia got by making its own core was the ability to achieve higher single-thread perf by hitting higher clock speeds and the ability to add SMT for better utilization.
Reply

Show more comments