AMD EPYC Venice SP7 Review: 256 cores per socket en de bandbreedte om ze te voeden

AMD’s 6th Gen EPYC server CPU family, codenamed Venice, brings Zen 6 and Zen 6c cores to a lineup built to take on every corner of the server market. AMD is pushing core counts and clock speeds higher and giving those cores considerably more bandwidth to work with, through a larger memory subsystem and the move to PCIe Gen6. The breadth of the family gives AMD room to chase maximum compute density while also building parts around the demands of enterprise servers and AI hosts.

This review focuses on Venice SP7, AMD’s larger data center socket, which supports sixteen memory channels and processors up to 600W. The enterprise-focused Venice SP8 platform and the LPDDR-based Verano, AMD’s answer to NVIDIA Vera, are slated to arrive next year, in 2027. Our test data comes from the 256-core EPYC 9996 in Dell’s PowerEdge R9825 and from AMD’s Nigeria reference platform, which also gave us a look at the 96-core, 5.3GHz EPYC 9686F and at what MRDIMM-12800 memory adds to the same silicon.

Key Takeaways

• The fastest server processor we have tested. Two 256-core EPYC 9996 in Dell’s PowerEdge R9825 ran GROMACS benchPEP 1.8x faster than the 384-core EPYC 9965 server, solved the large OpenFOAM mesh 2.6x faster, and encrypted AES-256-GCM 1.7x faster at 6.8TB/s. One socket served 76.5M Valkey GET requests per second.
• Venice beats Vera and Xeon on most compute work. Against Vera, the R9825 ran benchPEP 4.7x faster, encrypted 5.4x faster, compressed 2.1x faster in 7-Zip, solved the large OpenFOAM mesh 1.8x faster, and served 3.4x the Valkey requests from one socket, while cutting HammerDB tail latency by 30% to 51% at matched load. Against the Xeon 6978P, it led by 2.6x on benchPEP and 2.7x on AES.
• Per-core speed is back on the x86 side. On a matched 16 cores, Zen 6c ran GROMACS benchMEM 67% faster than Zen 5c and 2.5x faster than Olympus. A single pinned Zen 6c thread compressed 16% faster than Olympus in 7-Zip and encrypted 2.9x faster, and the 5.3GHz EPYC 9686F beat Vera on all three Python tests with 10% to 38% shorter run times.
• Memory matters as much as core count. Moving the same two 9996 processors from DDR5-8000 to MRDIMM-12800 raised STREAM Triad bandwidth by 58% and cut the large OpenFOAM solve by 21%. The 96-core 9686F on MRDIMMs reached nearly 2TB/s and finished that mesh within 13% of the 512-core R9825 on DDR5-8000.
• Vera keeps the edge in raw bandwidth and interconnect. On raw STREAM Triad, Venice trails Vera’s 2,073GB/s by 42% on DDR5-8000 and 8% on MRDIMMs, though the MRDIMM configuration moves more data than Vera once the reads STREAM doesn’t count are added back. Vera’s NVLink-C2C delivers 4.6x the remote-socket bandwidth of AMD’s xGMI, and the same link gives Vera a CPU-to-GPU connection whose bandwidth no x86 platform matches.
• Databases split between the two. In HammerDB’s November round, one 256-core EPYC 9996 socket beat Vera’s 88-core socket by 14% on MySQL and tied on VillageSQL, while Vera led MariaDB and PostgreSQL by 11% to 12%. Venice cut PAYMENT p99 latency by 30% to 51% at matched load, and one 96-core 9686F socket posted the round’s highest PostgreSQL result at 3.03M NOPM.

The SP7 Lineup

The SP7 lineup sets the frame for the architecture discussion that follows. The flagship of the Venice lineup is the EPYC 9996 with 256 cores, a 33.3% increase over Turin’s 192-core EPYC 9965. AMD is making an even larger jump with its high-frequency parts, moving from a maximum of 64 cores with Turin’s 9575F to 96 cores with the 9686F, a 50% increase in core count, and the 9686F also reaches a maximum boost of 5.3GHz. AMD published the full 31-part EPYC 9006 list in October; the SP7 parts we reference in this review are below.

Gegevensverwerker	Cores / threads	Base / max boost	L3 cache	Default CPU power
EPYC 9996	256 / 512	2.55 / 4.1 GHz	1,024MB	600W
EPYC 9966	192 / 384	2.9 / 4.0 GHz	768MB	600W
EPYC 9846	168 / 336	2.85 / 3.7 GHz	768MB	500W
EPYC 9756	128 / 256	3.15 / 4.0 GHz	512MB	500W
EPYC9686F	96 / 192	4.05 / 5.3 GHz	384MB	600W
EPYC 9G76	96 / 192	3.4 / 4.8 GHz	384MB	500W
EPYC 9656	96 / 192	3.05 / 3.7 GHz	512MB	400W
EPYC9586F	64 / 128	3.75 / 5.0 GHz	384MB	500W
EPYC 9556	64 / 128	2.75 / 4.3 GHz	384MB	300W

 

AMD declared the SP7 parts generally available on November 10, with OEM systems shipping and Azure and OCI instances to follow, and its launch claims set the bar our testing checks against. Against 5th Gen EPYC, AMD puts Venice at 2.0x on SPECint 2026, 2.4x on SPECfp 2026, 2.7x on STREAM, 1.4x on HPL, and 1.3x on DGEMM.

Those are AMD’s figures from AMD’s testing, and we cover its IPC claims with the core design below; our STREAM Triad result, shown below, lands at 1.9x the Turin flagship on DDR5-8000 and 3.0x on MRDIMM-12800.

Against NVIDIA Vera, AMD claims 1.2x per core on SPECrate 2026 integer for its 96-core frequency part and 2.2x per platform for the 9996, and at launch it added 3.7x on SPECrate 2017 for a two-socket 9996, a published 5,470 against an AMD estimate of 1,459 for Vera. The per-core figure matches our pinned 7-Zip result, where the 9686F compressed 16% faster than an Olympus core, and the platform figures bracket our suite, where the 9996’s margin over Vera runs from parity on OLTP to up to 5.4x on crypto code. The same published score is 1.68x the 3,260 of a two-socket EPYC 9965.

AMD also describes three operating points for the lineup. A 256-core part at 400W is pitched at bulk agentic hosting, where utilization runs 50% to 100% and power works out to 1.2W to 2.0W per core; the same 256 cores at 600W target cloud and mainstream data center throughput at 1.7W to 3.5W per core; and the 96-core parts at 500W and 600W serve HPC head nodes and latency-sensitive work at 5W to 10W per core with the headroom to reach 5.3GHz. The 9996 and 9686F we tested sit at the second and third of those points.

Venice also brings three platform-level power controls, starting with Unified Power Provisioning, which sets one budget across the SoC and its DIMMs so a rack can reclaim stranded capacity; AMD says 15% to 25% of rack capacity typically goes unused. AMD’s launch model puts 16 two-socket 9996 servers in a 35kW rack at the default 830W budget for each SoC and its DIMMs, and nearly 19 with that budget set 15% lower at 706W, for a 1% average performance cost.

Utilization-Based Power Scaling lets socket power track the active core count, holding full power in reserve for bursts, and Frequency Adaptive Spectrum Technology sets a floor frequency per core group so one physical part can be sold in several performance tiers. None of the three affected our testing at default power, and we will look at how OEMs expose them as firmware matures.

Inside the Core: Zen 6 and Zen 6c

The Venice lineup is powered by AMD’s Zen 6 and Zen 6c core chiplets, both built on TSMC’s N2 process. Compared with the Zen 5 and Zen 5c designs in Turin, these new core complex dies, or CCDs, offer higher core counts and larger caches.

It helps to know up front that Zen 6 and Zen 6c are not two different designs in the way Intel’s P-cores and E-cores are. AMD builds both on the same microarchitecture, with every feature and every data path shared between the two. Zen 6c is a physically compacted implementation that trades clock speed for area and power, so it can pack far more cores onto a die. AMD lists a maximum frequency of 5.3GHz for Zen 6, up from 5.0GHz on Zen 5, and 4.1GHz for Zen 6c, up from 3.7GHz on Zen 5c.

The standard Zen 6 CCD grows from Turin’s eight Zen 5 cores to twelve. Each core keeps 1MB of private L2, giving the CCD 12MB of aggregate L2, while the shared L3 that all twelve cores draw from rises from 32MB to 48MB. That keeps the ratio at 4MB of L3 per core, the same as Zen 5, so the larger die adds capacity without diluting the cache available to each core.

Zen 6c makes the larger jump, doubling the sixteen cores in Turin’s Zen 5c CCD to 32 and quadrupling shared L3 from 32MB to 128MB, which also doubles the L3 per core from 2MB to 4MB. Each core retains its 1MB L2, bringing the CCD’s aggregate L2 capacity to 32MB. Eight of these CCDs give the 9996 its 256 cores and 512 threads, along with 256MB of total L2 and 1,024MB of L3.

That structure matters for how AMD frames its performance claims. AMD’s headline figure is a geomean IPC uplift of about 27% for Zen 6c over Zen 5 across AI and server workloads. IPC, or instructions per cycle, describes how much work a core completes in each clock tick, independent of frequency. AMD splits that result into two geomeans: about 20% for enterprise and cloud server workloads and about 31% for AI workloads. AMD highlights that these were measured at a fixed frequency, comparing 16 Zen 5 cores spread across two CCDs with 16 Zen 6c cores in a single CCD.

Coming back closer to the execution units, each Zen 6c core has a 32KB, 8-way L1 instruction cache and a 48KB, 12-way L1 data cache. Associativity describes how many locations within the cache a given memory address is allowed to occupy; higher associativity reduces the chance that two frequently used pieces of data keep evicting each other. The only current-generation competitor, NVIDIA’s Vera with its Olympus core, carries 64KB of instruction cache, 96KB of data cache, and 2MB of private L2 per core.

Core resource	AMD Zen 6c	NVIDIA Olympus
Taken-branch prediction	Up to two per cycle; up to three prediction windows per cycle	Up to two per cycle
Return-address stack	64 inzendingen	Niet bekendgemaakt
L1 instruction fetch	Two 32-byte streams (64 bytes per cycle)	128 bytes per cyclus
Decode width	Two four-wide decoders	Ten-wide
Decoded-operation cache	6.75K operations; up to 18 operations per cycle to the queue	No equivalent x86-style operation-cache path described
Dispatch / retirement	Eight-wide / eight-wide	Ten-wide allocation / commit
Herorde buffer	640 inzendingen	Capacity not disclosed
Integer schedulers	Split: 96 shared ALU/AGU entries plus 48 dedicated ALU entries	Niet bekendgemaakt
Integer physical registers	352	Niet bekendgemaakt
Integer execution	Six ALUs, two multipliers	Eight simple ALUs, two complex ALUs, two CRC units
Branch execution units	Drie	Vier
Vector execution	512-bit datapath; two multiply/FMA and two add pipelines; four VNNI INT8 pipelines	Six 128-bit SVE2 pipelines, two with crypto
Load / store pipelines	Four load/store pipes; up to four loads and two stores per cycle	Four load, two store
Load / store queues	80 / 128 vermeldingen	Niet bekendgemaakt
Data TLB (L1 / L2)	96 entries / 4K entries	Niet bekendgemaakt
L1 instruction cache	32KB, 8-way	64KB, 4-way
L1 data cache	48KB, 12-way, four-cycle load latency	96KB, 6-way
Privé L2	1MB, 16-way	2MB, 8-way
Shared last-level cache	128MB, 16-way, per 32-core CCD	164MB system-level cache across 88 cores

 

The Front End: Prediction, Fetch, and Decode

The front end is the part of the core responsible for keeping the execution engine supplied with instructions. It predicts where the program will go next, fetches the instruction bytes from that location, and decodes them into internal operations the core can schedule. Interpreters, database engines, and large server applications make this demanding work, because their short blocks of code frequently end in branches that change the next fetch address. A taken branch sends execution to its target, while a not-taken branch continues through the sequential instructions that follow it. Every time the front end guesses wrong, the work fetched down the wrong path has to be thrown away.

To guess well, Zen 6c uses a TAGE predictor, and AMD says its prediction tables have been tuned for Zen 6 and the branch prediction queues enlarged. The predictor can produce two taken predictions per cycle and up to three prediction windows per cycle. A 64-entry return-address stack, up from 52 on Zen 5c, tracks where function calls should return.

The core follows the predicted route and recovers when a prediction proves wrong, and AMD says Zen 6 shortens that recovery by reducing branch misprediction latency. Vera matches the two-taken-branches-per-cycle ceiling with a neural predictor and specialized prediction mechanisms. Both designs can therefore look ahead through more than one predicted redirect per cycle, which helps instruction delivery keep pace with code that frequently changes direction.

Once the path is predicted, the instruction bytes have to arrive. Zen 6c feeds two 32-byte fetch streams, 64 bytes per cycle in total, from its 32KB L1 instruction cache into paired four-wide decoders. Olympus fetches 128 bytes per cycle and uses a ten-wide decoder, giving Vera the wider fetch and decode path. The two instruction sets encode work differently: x86 instructions vary in length and can carry more work per instruction, while Arm instructions are fixed-length. Those widths therefore describe instruction supply and do not fix a relationship between application throughput on the two cores.

AMD also gives Zen 6c a 6.75K-operation cache, up from 6K on Zen 5c, that holds previously decoded work. Decoding x86 is one of the more power-hungry jobs in the core, so skipping it is valuable. An op cache hit supplies the operation queue directly, taking repeated decoding out of the path.

The cache can deliver up to 18 operations per cycle to that queue, up from 12, comfortably ahead of the eight-wide dispatch stage. Hot loops can keep reusing those operations, which frees the decoders from rebuilding the same work on every pass. AMD also increased op fusion in Zen 6, combining certain pairs of operations into one so they consume less space in the queues downstream.

Scheduling and Integer Execution

After the front end, the core has a stream of operations in program order, but there is no rule that they must execute in that order. Out-of-order execution lets the core run any operation whose inputs are ready, even if older instructions are still waiting. To make that safe, the core first performs register renaming. Programs reuse a small set of architectural register names over and over; renaming maps each new value onto one of a much larger pool of physical registers, so independent instructions that happen to reuse the same name do not have to wait on each other.

Zen 6c’s eight-wide rename and dispatch stage feeds 352 integer physical registers, up from 240 on Zen 5c. A 640-entry reorder buffer, up from 448, tracks every operation in flight. The reorder buffer is the bookkeeping structure that lets operations finish out of order while the core still commits results in the original program order. Its size sets how far ahead of a stalled instruction the core can search for independent work.

Between dispatch and the execution units sit the schedulers, which hold operations until their inputs are ready. Here AMD made a structural change: Zen 5 used a unified integer scheduler, and Zen 6 splits it, with 96 entries shared between arithmetic (ALU) and address-generation (AGU) work plus 48 entries dedicated to ALU operations. Zen 5c had 88 ALU entries and 56 AGU entries. AMD also enlarged the floating-point schedulers, and the result is more total scheduling capacity, so more operations can wait for their inputs without stalling dispatch.

That scheduling window lets a database worker overlap independent lookups, for example, or continue arithmetic while an earlier load waits for data. Olympus uses ten-wide allocation to supply its execution machinery and adds value prediction and memory renaming to help advance through dependencies.

Zen 6c’s integer engine includes six ALUs, two integer multipliers, and three branch execution units. Those branch units resolve the actual outcome of each branch after the front end has already predicted the path. Olympus has four branch execution units alongside its wider allocation and commit machinery. The resources address different parts of instruction processing, because predicting a branch early and resolving it during execution are separate jobs.

Vector Execution

Vector, or SIMD, instructions apply one operation to many data elements at once, which makes them central to numerical work, compression, media, and increasingly AI inference. AMD’s native 512-bit vector engine returns in both Zen 6 and Zen 6c, meaning a single AVX-512 instruction operates on the full 512-bit register in one pass, with no split into two halves. The execution hardware includes two multiply/FMA pipelines, two add pipelines, and four VNNI INT8 pipelines, double the two on Zen 5.

The biggest change is full AVX-512 FP16 arithmetic: Zen 5 could only convert half-precision values, and Zen 6 computes on them directly. For software that can use half-precision arithmetic, a 512-bit vector holds 32 FP16 values against sixteen FP32 values.

Zen 6 adds several other instruction-set extensions aimed at the same workloads: AVX-512 BMM, a new set of bit matrix multiply instructions; AVX-VNNI-INT8, more INT8 dot-product instructions in the VEX encoding; AVX-NE-CONVERT, for converting BF16 and FP16 values to FP32; and AVX-IFMA, integer fused multiply-add promoted to the VEX encoding. Existing AVX-512 support, including BF16 and VNNI-INT16, carries over from Zen 5. Software needs compiler and library support to use these extensions.

Vera takes a different approach, with six 128-bit SVE2 execution units and FP8 support. Venice has the wider native vectors, while Vera has six narrower units available to process SIMD instructions. The useful comparison depends on the arithmetic a workload needs: FP16 calculations, INT8 dot products, and FP8 operations use different instructions and place different demands on the execution hardware.

Both designs specify a two-cycle latency for floating-point addition. That matters when each addition needs the result of the one before it, since a wide vector engine still has to wait for those dependencies. Vector search and numerical workloads can benefit from Venice’s width when their code exposes enough parallel work and uses data types that fit the available pipelines, and our GROMACS results below show what that looks like in practice.

Loads, Stores, and Keeping Data Moving

A 512-bit vector engine is only as fast as the data feeding it, and that job falls to the load/store unit. Zen 6c has four load/store pipelines that can handle a mix of up to four loads and two stores per cycle. For vector code, that works out to two 512-bit or four 256-bit loads per cycle, where Zen 5 managed two loads of any size, along with one 512-bit or two 256-bit stores, subject to the instruction mix.

An 80-entry load queue and a 128-entry store queue, up from 64 and 96 on Zen 5c, keep requests in flight, alongside a scalable load-ordering queue. A load that hits in the L1 data cache has a specified four-cycle latency, and the L1 exchanges data with the L2 over a 64-byte-per-cycle fill and victim path.

Every load also needs its virtual address translated to a physical one, and the translation lookaside buffers, or TLBs, cache those translations so the core does not have to walk the page tables on every access. Zen 6 has a 96-entry L1 data TLB backed by a 4K-entry L2 data TLB that covers every page size except 1GB pages. Large in-memory databases and analytics engines with scattered access patterns lean heavily on TLB reach.

Those queues give the core room to overlap independent memory accesses. Following a chain of pointers is more difficult, because one load has to return before the next address is known. Vera’s Olympus core tackles some of that work with a graph prefetcher that recognizes patterns such as A[B[i]], where an index fetched from one array identifies the element needed from another, giving the hardware a chance to fetch that second value ahead of demand.

A miss in L1 sends the request further through the cache hierarchy. The core’s 16-way private L2 and its CCD’s shared L3 provide the next opportunities to find the data, with requests traveling through the I/O die when they need to reach memory. This is where Venice’s chiplet layout starts to affect how long a core waits for its operands. Meanwhile, the core keeps executing independent operations out of order to keep its units busy. Completed instructions then retire in program order so the software sees the expected sequence of results; Zen 6c has eight-wide retirement against Olympus’s ten-wide commit stage.

Two I/O Dies and Sixteen Memory Channels

Moving beyond the CCDs, the cores need a way to reach memory, devices, and each other. In every EPYC since Rome, that job has belonged to a separate I/O die, or IOD, and Venice splits it across two. Each IOD carries eight DDR5 memory channels, 48 lanes of 64Gb/s SerDes, and eight lanes of slower 16Gb/s SerDes for auxiliary I/O. A SerDes, short for serializer/deserializer, is the high-speed transceiver that carries PCIe, CXL, and socket-to-socket traffic.

In the full eight-CCD package, four CCDs attach to each IOD, and the two IODs are identical dies rotated 180 degrees relative to each other. They sit on a 6nm-class process, while the CCDs moved to 2nm, because analog I/O circuitry gains little from the newest nodes.

How the chiplets talk to each other has also changed. AMD uses Elevated Fanout Bridges, or EFB, for communication between dies, aiming to lower the energy and latency of those transfers. Previous EPYC generations ran die-to-die links through serial connections across the organic package substrate. EFB places a small, dense bridge under the die edges, allowing many more short, wide connections. AMD says this cuts the energy per bit and frees power for the cores. The links run AMD’s fifth-generation Infinity Fabric, which also adds faster fabric power-state changes so the interconnect can drop to lower power when traffic is light.

That gives each half of the processor dedicated memory controllers, I/O, security, and fabric resources. A CCD reaches its local memory controllers through the IOD it connects to, and accessing controllers on the other IOD adds another hop over Infinity Fabric and the latency that comes with it. The NPS settings let software use this division when placing threads and their memory.

Together, the two IODs give SP7 sixteen memory channels at one DIMM per channel. DDR5 RDIMMs run at up to 8,000MT/s, producing a theoretical 1.024TB/s of bandwidth. MRDIMMs take the interface to 12,800MT/s and lift that ceiling to 1.6384TB/s, the basis for AMD’s headline 1.6TB/s figure.

An MRDIMM, or multiplexed-rank DIMM, gets its speed from buffers on the module that combine traffic from multiple ranks onto the faster host interface, increasing the amount of data the channels can carry. Random-access latency still depends on the memory timings and the route taken to reach it. SP7 also has room for up to 8TB of memory using sixteen 512GB 3DS RDIMMs.

Against the competition, Vera’s replaceable LPDDR5X SOCAMM2 modules support up to 1.5TB of memory and up to 1.2TB/s of bandwidth, placing it between Venice’s RDIMM and MRDIMM bandwidth ceilings. How far that bandwidth goes also depends on the core count. Dividing the headline figures gives about 6.4GB/s per core for a 256-core Venice with MRDIMMs, 17.1GB/s for a 96-core Venice at the same memory rate, and 13.6GB/s for 88-core Vera. The memory channels are shared, so individual cores do not receive a fixed allocation, but the calculation does help explain why the 9996 and 9686F can have very different demands on the same SP7 memory subsystem.

When sixteen channels of DRAM are not enough, capacity can grow over CXL. SP7 also carries CXL 3.1 on up to 96 of its PCIe Gen6 lanes per socket, and AMD rates each x16 link at about 128GB/s of raw bandwidth at one NUMA hop of latency, which is the path to memory beyond the sixteen channels when capacity matters more than speed.

The same 64Gb/s lanes serve PCIe Gen6: a single-socket SP7 system gets 96 Gen6 lanes plus eight bonus PCIe Gen4 lanes, and a two-socket system gets up to 128 Gen6 lanes plus 16 Gen4 lanes. Links can bifurcate down to x16, x8, x4, or x2. The IODs also support Smart Data Cache Injection, which can steer incoming device data directly into cache, and the Smart Data Accelerator Interface for offloading memory copies.

LPDDR5X on SOCAMM2 arrives with Verano, where AMD lists up to 1.5TB per socket at about 0.8TB/s and 30% to 40% lower memory power than DDR5 RDIMMs or MRDIMMs at the same bandwidth, so the Vera comparison in this review will have a direct AMD counterpart next year.

Coherence and Cache Locality

With 1GB of L3 on the top part, where that cache lives starts to matter as much as how much there is. Venice’s large L3 capacity is spread across its CCDs, making the location of shared data part of the performance equation. Coherence is the hardware guarantee that every core sees a consistent value for a given memory address, even when copies of it sit in several caches.

Threads on one CCD can reuse its local L3. As with Turin, passing data to a thread on another CCD adds a hop through the fabric. Venice adds a further hop over Infinity Fabric to the other IOD and then to the target CCD when that CCD is attached to the other I/O die.

AMD describes Zen 6c’s 16-way L3 as a mostly exclusive victim cache, meaning it primarily holds lines evicted from L2 and does not duplicate what the L2 already contains, which stretches the effective capacity of the two levels combined. Duplicated L2 tags in the L3 help the coherence hardware locate cached data and filter probes, reducing unnecessary requests to the private caches and speeding cache-to-cache transfers. The hierarchy can track 127 outstanding L2-to-L3 misses per core and 1,280 L3-to-memory misses per complex, allowing many requests to progress while earlier accesses are still waiting on data.

Vera’s 164MB system-level cache is shared across all 88 cores on a single compute die, connected by its on-die coherent fabric. Venice has substantially more aggregate last-level cache at the top of the lineup, divided among its chiplets, so software that repeatedly passes shared data between workers has to account for those separate cache domains.

For a storage application, keeping a queue, its metadata, and the workers servicing it on the same CCD encourages reuse of the local cache. Spreading those workers across the socket can increase traffic between CCDs as they access the same structures, and memory placement adds another layer, since a thread’s DRAM may sit behind either of the two I/O dies.

NPS Modes and Memory Placement

That physical layout is exposed to software through NUMA, or non-uniform memory access: the operating system is told which cores sit closest to which memory so it can place work accordingly. NPS, short for NUMA nodes per socket, determines how Venice presents its memory domains to the operating system. AMD emphasizes NPS2 for SP7 performance, with NPS1 and processor-specific NPS4 support providing other ways to organize the socket, and every Venice result in this review was collected in NPS2.

Mode	Memory domains per socket	Channels per domain	Associated CCDs in an eight-CCD package
NPS1	1	16	8
NPS2	2	8	4
NPS4	4, where supported	4	2

 

CCD counts in the table describe the full eight-CCD layout; enabled cores and supported modes vary by processor. NPS1 gives the operating system one memory domain and interleaves memory across all sixteen channels, which is the simplest view for software, although an access still has to follow the physical connections between its CCD and the IOD serving the address.

NPS2 follows the two halves of the package. Each domain brings together one IOD’s eight memory controllers and its four associated CCDs. In the fully enabled processors covered here, that works out to 128 cores per domain on the 9996 and 48 on the 9686F. Placing a thread and its memory in the same domain keeps its DRAM accesses on that side of the processor.

NPS4 divides each IOD’s resources again, giving each domain four memory channels and two associated CCDs. That produces 64-core domains in the 256-core example, or 24-core domains in the 96-core example where the processor supports the mode. Software gets finer control over placement, with fewer channels available inside each domain.

These settings change memory interleaving and the locality information exposed to software, while the physical cache boundaries remain in place: four CCDs in an NPS2 domain still have four separate L3 caches, and traffic between them still uses the fabric. Thread affinity and memory allocation therefore need to agree, because pinning a worker to one domain while leaving its pages in another keeps those accesses on the longer path. VM sizing and first-touch allocation, where Linux places a page on the node of the thread that first writes it, deserve the same attention.

Vera simplifies this by presenting only one NUMA domain per socket, or two in a dual-socket system. Its coherent fabric handles communication within the compute die, and NVLink-C2C carries traffic to the other CPU, which gives software fewer NUMA boundaries to manage within a socket.

xGMI and Vera CPU-to-CPU Connectivity

Stepping beyond a single socket brings Venice’s xGMI links into the picture. xGMI is AMD’s coherent socket-to-socket version of Infinity Fabric, and it shares physical lanes with PCIe. AMD supports up to three x16 connections running at 64Gb/s per lane, drawing from the same high-speed connectivity resources used for PCIe. With two x16 xGMI links between the processors, AMD’s general-compute layout leaves 128 PCIe Gen6 lanes available across the dual-socket server, and moving to three xGMI links brings that system-wide PCIe total down to 96 lanes.

Each x16 xGMI link works out to a raw 128GB/s in each direction, before protocol overhead. Two links provide 256GB/s each way, while three raise that to 384GB/s, so adding the third link buys 50 percent more bandwidth between the processors at the cost of 32 PCIe lanes across the server.

NVIDIA goes considerably wider with second-generation NVLink-C2C: Vera’s CPU-to-CPU connection is rated at 1.8TB/s bidirectional, or 900GB/s in each direction, and the same interconnect technology serves NVIDIA’s tightly integrated CPU-to-GPU connection.

CPU link configuration	Bandwidth per direction	Sum of both directions
Venice, two x16 xGMI links	256GB/s raw, calculated	512GB/s raw, calculated
Venice, three x16 xGMI links	384GB/s raw, calculated	768GB/s raw, calculated
Vera, NVLink-C2C	900GB/s, vendor specified	1,800GB/s, vendor specified

 

The xGMI links carry more than CPU traffic; they also carry traffic generated by PCIe devices. A NIC or NVMe drive attached to one CPU may read or write buffers in memory attached to the other, sending those DMA transfers across the socket link. Keeping the buffers local to the device still requires a crossing if a worker on the other CPU consumes the data. Accelerator transfers involving remote host memory create the same demand, and all of it shares xGMI with remote CPU memory accesses, cache-line transfers, and coherence messages. Our STREAM remote-socket results below put a measured number on that link.

Venice as an AI Host

Venice also has a key role in AMD’s Helios racks, where a 96-core EPYC 9G76 hosts four Instinct MI455X GPUs per compute tray. In this role, the CPU is the traffic controller: it stages data, runs the software that keeps the GPUs busy, and handles networking and storage. AMD’s detailed disclosure confirms the layout we discussed in our Advancing AI coverage: four x16 connections, one to each GPU.

At 64Gb/s per lane, each link is rated for 128GB/s in each direction, or 256GB/s bidirectional, doubling the host bandwidth of MI355X’s PCIe Gen5 x16 connection. Across all four GPUs, that adds up to 512GB/s in each direction, or 1.024TB/s bidirectional, and the CPU retains two x16 PCIe Gen6 groups for networking and storage.

Those host links run coherent Infinity Fabric in place of plain PCIe, giving Venice cached access to GPU memory, so the CPU and GPU can share data structures without explicit copies. NVIDIA’s NVLink-C2C still offers higher CPU-to-GPU bandwidth, and we will need Helios and NVL72 systems in the lab to measure how much that difference matters in training and inference. We suspect inference is the primary focus for Helios, which in theory should feel less impact from the slower CPU-to-GPU links.

Prestaties en benchmarks

The benchmarks examine how Venice’s design translates into performance, from a single pinned thread to workloads that load every core in a two-socket server. Our tests cover memory bandwidth and latency, scientific computing, analytics, general-purpose software, and databases, showing how Venice’s cores and the SP7 memory system handle different demands.

Testsystemen

Systeem	Dell PowerEdge R9825	AMD Nigeria Reference Platform	AMD Nigeria Reference Platform	NVIDIA MGX Vera C2	Dell PowerEdge R7725	Dell PowerEdge R770AP
Processoren
CPU	AMD EPYC 9996		AMD EPYC9686F	NVIDIA Vera	AMD EPYC 9965	Intel Xeon 6978P
Sockets	2
Kernen / Threads per CPU	256 / 512		96 / 192	88 / 176	192 / 384	120 / 240
Basis klok	2.55 GHz		4.05 GHz		2.25 GHz	2.1 GHz
Max Clock	4.1 GHz		5.3 GHz	3.4 GHz	3.7 GHz	3.9 GHz
Geheugen
Configuratie	32x 64GB			16x 96GB Micron SOCAMM2	24x 128GB	24x 64GB
Type / Snelheid	DDR5-8000	MRDIMM-12800		LPDDR5X-9600	DDR5-6400
Totale capaciteit	2TB			1.5TB	3TB	1.5TB
Opslag
SSD	Solidigm D7-PS1030 12.8 TB	Micron 9650 PRO 7.68 TB		Solidigm D7-PS1010 7.68 TB	Solidigm D7-PS1030 12.8 TB	Solidigm D7-PS1010 7.68 TB
SSD-link	PCIe Gen5 x4	PCIe Gen6 x4		PCIe Gen5 x4	PCIe Gen5 x2	PCIe Gen5 x4
firmware
Systeem-BIOS	1.0.4	RNIV1001H		NV_SBIOS 06.07.01.06	1.5.3	1.2.1
BIOS-profiel	Prestaties	Standaard	Standaard	Standaard	Prestaties
Software-stack
OS	Ubuntu LTS 26.04.1	Ubuntu LTS 26.04		Ubuntu LTS 26.04.1	Ubuntu LTS 24.04.5
pit	7.0.0-42-generic	7.2.0-rc5	7.2.0-rc5	7.0.0-2022-nvidia-bos	6.8.0 142 / 6.8.0 146	6.8.0-138
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 Venice against three systems tested with the same suite: NVIDIA’s Vera, the Turin-based EPYC 9965 in Dell’s PowerEdge R7725, and the Xeon 6978P in Dell’s PowerEdge R770AP. AMD provided remote access to Nigeria, its two-socket SP7 reference server, for the MRDIMM and EPYC 9686F results, which are the only results in this review not collected in our lab.

Venice and Vera ran a newer software stack than the Turin and Xeon systems, as listed above, so the older GCC gives the Turin and Xeon systems a small handicap. Benchmark versions, inputs, and build flags were otherwise identical across all systems. Every Venice system ran in NPS2, AMD’s recommended setting for SP7, and results are with SMT off unless noted.

Geheugenbandbreedte

Memory is where SP7’s sixteen channels per socket should show, 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 across both sockets, and we then repeat it pinned to one socket, reading first its local memory and then the remote socket’s memory. The chart below shows the whole-system and per-socket Triad results with SMT off.

The R9825 sustained 1,201GB/s on DDR5-8000, 59% of the 2,048GB/s that its 32 channels at 8,000MT/s can carry on paper. That is 1.9x the 634GB/s of the EPYC 9965 system on 24 channels of DDR5-6400 and 1.3x the Xeon 6978P’s 914GB/s, but it still trails Vera’s 2,073GB/s by 42%.

Memory speed is the limiting factor on the R9825, because the same two processors on MRDIMM-12800 in AMD’s reference platform reached 1,901GB/s, a 58% gain from the memory alone. The 96-core 9686F on the same MRDIMMs went slightly higher at 1,961GB/s with fewer than half as many cores pulling on the channels. On MRDIMMs, Venice lands 8% short of Vera on the raw STREAM figure.

Per core, the arithmetic still favors the smaller parts. Spread across 512 cores, 1,901GB/s is 3.7GB/s per core on the 9996, against 10.2GB/s on the 192-core 9686F and 11.8GB/s on 176-core Vera, which is the trade a buyer makes for 256 cores in a socket and the reason the 9686F exists.

Part of the gap to Vera 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 about 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.

Adjusted for the uncounted reads, the R9825 moved about 78% of its theoretical peak. The same correction lifts the MRDIMM 9996 configuration’s bytes moved above Vera’s 2,073GB/s, so the raw 8% gap reverses once both systems are measured by the traffic their memory carried. Vera’s figure sits closer to its real traffic, which makes the Venice and Turin bandwidth figures in this review conservative against it.

Read the 1.9x generational figure, and the 3.0x the MRDIMM configuration posts against the same server, with that in mind. Both rest on the EPYC 9965’s 634GB/s Triad result, which our Vera review found runs low partly because of these uncounted reads. Venice pays the same reads, so they do not by themselves inflate the ratio, but the harness’s STREAM Copy test shows a narrower generational gap, with 1,158GB/s on the R9825 against 832GB/s on the 9965.

That Copy test is a separate Phoronix Test Suite build of STREAM with different thread placement, and it also reorders the top of the chart. With SMT off, the two MRDIMM configurations reached 1,827GB/s and 1,760GB/s, ahead of Vera at 1,483GB/s, while the Xeon 6978P landed at 869GB/s.

Splitting the test by socket shows how the fabric handles data that isn’t local to the cores. One socket of the R9825 reading its local memory sustained 602GB/s, and the same cores reading across xGMI to the other socket’s memory sustained 148GB/s, a remote-to-local ratio of 25%. The MRDIMM platform lifted the local figure to 957GB/s on the 9996 and 988GB/s on the 9686F, while remote bandwidth stayed at 150GB/s and 140GB/s. Faster memory therefore widens the gap, and a thread that lands on the wrong socket gets a quarter of its local bandwidth at 8,000MT/s and about a sixth at 12,800MT/s.

That ratio is the measured cost of the two x16 xGMI links described earlier, and it is the clearest architectural difference from Vera in the whole data set. Vera’s socket reads 1,055GB/s locally and 677GB/s remotely over NVLink-C2C, a 64% ratio, and the Xeon 6978P manages 59% over UPI. Turin’s R7725 posted nearly the same remote figure as Venice, so this is an Infinity Fabric characteristic carried forward, and NPS2 placement and NUMA-aware software matter more on Venice than on either competitor.

Wachttijd

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, and compare the Venice systems with Vera.

When reading local memory, the 9996 is faster than Vera. With 2MB pages, a local read took 87.6ns on the R9825 and 89.5ns on the MRDIMM platform, against 99.2ns on Vera. Remote reads cost 200.8ns on the R9825 and 212.3ns on the MRDIMM platform, against Vera’s 212.7ns, so a cross-socket access on Venice is 2.3x to 2.4x a local one where Vera’s is 2.1x.

Venice is also less sensitive to page size. With 4KB pages, where missed address translations add to every read, the R9825 read at 106.9ns local and 225.9ns remote, against Vera’s 135.8ns and 308.4ns. Zen 6c’s two-level TLB absorbs the small-page penalty better than Olympus does.

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 the CPU.

GROMACS, a molecular dynamics code, spends most of its time in vector arithmetic, with hot loops hand-written for each SIMD width. OpenFOAM, a computational fluid dynamics solver, works through large sparse matrices and spends much of its time waiting on memory. The two pull in opposite directions on most processors, and Venice is the first platform in our set that leads on both.

GROMACS

We tested GROMACS 2025.3 with benchPEP, a 12-million-atom case run across every physical core in the server. The build used AVX-512 on every x86 system and ARM_SVE on Vera, and the suite’s pinned inputs and disabled PME tuning mean every platform ran the same work.

With SMT off, the R9825 finished benchPEP at 9.72 ns/day, 1.8x the EPYC 9965 server’s 5.36 ns/day on 384 cores and 2.6x the Xeon 6978P’s 3.79 on 240 cores. The MRDIMM platform added 3% at 10.01 ns/day, so this test is compute-bound at 512 cores. The 192-core 9686F reached 5.97 ns/day, ahead of the 384-core Turin flagship on half the cores, while Vera’s best result of 2.07 ns/day, with SMT on, is about a fifth of the R9825’s figure.

Normalizing by core count shows how much of that gap is architecture. The R9825 works out to 0.0190 ns/day per core, against 0.0140 for the EPYC 9965 and 0.0158 for the Xeon 6978P, a 36% per-core gain over Zen 5c that comes from the faster Zen 6c core, the larger L3, and the extra memory channels together. The 9686F’s 0.0311 per core shows what 5.3GHz and 384MB of L3 across 96 cores buy on this code.

SMT changed little on Venice, as the two 9996 runs landed within 1.5% of their SMT-off results with it on, and the 9686F gained 5% using a 192×2 rank layout.

De benchMEM-test isoleert het verschil per core door het systeem met 82,000 atomen te laten draaien op 16 fysieke cores van socket 0 op elk platform. Hierdoor speelt het aantal cores geen rol meer en weerspiegelt het resultaat de vectordoorvoer, cache en lokaal geheugen.

Here, 16 Zen 6c cores on the R9825 posted 110.8 ns/day, with the MRDIMM 9996 at 109.4 and the 9686F at 115.6. Sixteen Zen 5c cores on the EPYC 9965 reached 66.3, ahead of the Xeon 6978P at 54.5 and Vera at 44.1. That is a 67% per-core gain over Turin’s dense core on a workload the two share instruction sets for, and a 2.5x margin over Olympus’s six 128-bit SVE2 pipes.

The 82,000-atom working set fits in a Zen 6c CCD’s 128MB L3 with room to spare, which is why the three Venice configurations sit within 6% of each other, a far smaller spread than the gap between any of them and the rest of the field.

OpenFOAM

OpenFOAM moves the pressure from the vector units to the memory system, and here the memory system and the core count both get a vote. We run OpenFOAM 13 on the drivaerFastback 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 42.7 seconds on the R9825 and 42.8 seconds on the MRDIMM platform, 2.2x faster than the EPYC 9965’s 95.0 seconds and 2.5x faster than Vera’s 106.0. The matching result on both memory types says the small problem is bound by core count and cache at 512 ranks. The 9686F’s 59.9 seconds on 192 cores confirms it, as the 96-core part took 40% longer than the 9996 systems while still finishing 1.6x faster than Turin.

The large mesh is where the memory type shows up. The R9825 solved it in 1,036 seconds, 2.6x faster than the EPYC 9965’s 2,678 and 1.8x faster than Vera’s 1,854, and the same processors on MRDIMM-12800 finished in 815 seconds, 21% sooner.

The 9686F’s 1,166 seconds on 192 cores is within 13% of the 512-core R9825, which shows the bandwidth ceiling at work. At this mesh size, the 8,000MT/s system feeds 256 cores per socket with less total bandwidth than the MRDIMM system gives 96. On the same MRDIMMs, going from 96 to 256 cores per socket cuts the solve by 30%, and MRDIMMs on the same 256 cores cut it by 21%, so for CFD, weather, and other memory-bound solvers at production mesh sizes, the memory choice matters about as much as the core count.

Analyse en in-memory data

The HPC results showed what Venice’s cores and memory do for scientific solvers. Data services put the same hardware 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 a thread pool sized to the system. Valkey, the open-source Redis fork, serves small key-value requests and separates per-core latency from aggregate throughput.

KlikBench

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, is the best single measure in our suite of how a CPU and its memory handle columnar scans and aggregations. The cold sum adds server restarts and SSD reads before each query’s first execution.

With SMT off, the R9825’s median hot sum across three runs was 2.69 seconds, tied with the EPYC 9965’s 2.70 inside the 7% threshold, and the MRDIMM platform’s 2.58 seconds also falls inside that band. The 9686F ran the suite in 2.07 seconds, level with Vera’s 2.09 and the fastest x86 result we have recorded. At 512 threads per system, ClickHouse’s scheduling and merge overhead eats the extra cores, while 96 cores at 5.3GHz with 384MB of L3 clear the 43 queries faster than 256 at 4.1GHz.

The cold sum leans more on storage, and the drives differ between our lab and AMD’s platform. The R9825 finished cold in 5.75 seconds, against Vera’s 5.70 and the 9965’s 9.61, and the 9686F kept pace at 5.81. The MRDIMM 9996 configuration took 8.28 seconds on AMD’s platform, which ran a different drive and AMD’s pre-release Linux 7.2.0-rc5 kernel. The test restarts the server before every query, so we do not rank that result.

The R9825 loaded the 15GB Parquet dataset in 5.0 seconds, against 3.9 and 4.2 seconds on the two reference-platform runs, 6.4 on Vera, and 7.3 on the 9965. The Xeon 6978P system’s 9.75-second hot sum and 25.47-second cold sum remain unreconciled from our earlier testing, so we show them without ranking.

Turning on SMT moved the R9825’s hot sum to 2.67 seconds, and its cold sum to 6.53, so the extra 512 threads changed nothing on the hot path and added time on the cold one. Vera lost 10% of its hot-sum performance with its threads doubled, which reflects how Zen 6c’s competitive SMT and NVIDIA’s partitioned Spatial Multithreading handle a thread pool sized to logical CPUs.

Valkey

Valkey executes commands on a single-threaded loop per instance, so we look at it two ways: what one server delivers on matched cores, and what a socket delivers when it is packed with instances.

The harness profile gives one Valkey server nine physical cores on every platform and sweeps pipeline depth and working-set size, so it shows per-core behavior at matched core counts. The chart also carries the socket-mode result with requests sent one at a time, which we cover with the other socket figures below.

Sent one at a time, cache GET requests ran at 799,000 per second on the R9825 with a p99 of 0.84ms, against 692,000 and 1.08ms on the 9965, 385,000 and 1.76ms on Vera, and 332,000 on the Xeon 6978P, while the 9686F led at 821,000. In batches of 10, the R9825 reached 2.88M against 2.16M for the 9965 and 2.45M for Vera, a 33% generational gain on AMD’s side and an 18% lead over Olympus.

The 256GB working set outruns every cache, so its result tracks memory latency and bandwidth together, and here Venice and Vera were effectively tied, between 1.55M and 1.64M GET requests per second. The R9825 served 1.58M, the MRDIMM 9996 1.55M, the 9686F 1.64M, and Vera 1.59M, with the 9965 at 1.19M and the Xeon at 0.53M. Vera’s 1.76M with SMT on is the best single figure on this test and the one result in the Valkey set where Olympus’s memory system shows an edge over Zen 6c.

Socket mode pins server instances to socket 0, one per four or eight cores, and drives them from clients on socket 1 over loopback, so the result is one socket’s key-value throughput with no NIC in the path.

With batches of 16, one 256-core socket of the R9825 delivered 76.5M GET and 74.2M SET requests per second with the 8-core, 4-I/O-thread instance layout. That is 27% and 65% ahead of the 192-core EPYC 9965 socket’s 60.3M and 45.1M, and 3.4x Vera’s 22.8M and 21.9M. The MRDIMM platform landed within 6% of the R9825 on both commands, so socket-mode throughput is not memory-bound.

Per core, the 96-core 9686F led, reaching 32.1M GET and 33.0M SET requests per second, or 334,000 GET requests per second per core, against 299,000 on the 9996, 314,000 on the 9965, and 259,000 on Vera.

In socket mode, requests sent one at a time, shown in the profile chart above, are the one place Turin’s socket wins. The R9825 socket posted 5.96M GET requests per second against 7.78M for the EPYC 9965, 3.47M for the 9686F, 2.55M for the Xeon 6978P, and 2.08M for Vera. Per core, that is 23,300 on the 9996, 40,500 on the 9965, 36,200 on the 9686F, and 23,700 on Vera, so the dense Zen 6c socket in NPS2 clears a single command loop at about the rate Olympus does and well below Zen 5c.

Instance layout matters on a socket this dense, and we have not run enough configurations yet to say whether the 128-core NUMA domain or the 32-core CCD boundary is the variable that decides the best layout. Placement is on our list for a follow-up.

Single-thread en doorvoer

Valkey and ClickBench leaned on the memory system as much as on the cores, and this section turns to the cores themselves. NVIDIA’s pitch for Vera is maximum single-thread performance at scale, and AMD’s answer in this generation is a 4.1GHz boost on the 256-core part and 5.3GHz on the 96-core 9686F. 7-Zip, OpenSSL, and Python each run as a single pinned thread, and 7-Zip and OpenSSL then run again across every thread in the system.

The harness runs each pinned test on the lowest-numbered CPU of socket 0’s NUMA node that is not on core 0. The R9825’s pinned core reported a 4,115MHz ceiling, the 9686F’s 5,323MHz, Vera’s 3,375MHz, and the EPYC 9965’s 3.7GHz. Clock is only part of the story, and the two 7-Zip results below show how.

7-Zip

7-Zip’s LZMA compression and decompression are branch-heavy integer code, and the two halves of the test respond differently to clock speed.

On a single thread, the R9825’s Zen 6c core compressed at 11,068 MIPS, 16% ahead of Olympus at 9,537, 56% ahead of Zen 5c at 7,077, and 2.2x the Xeon 6978P’s 5,043. The 9686F at 5.3GHz compressed at 11,091 MIPS, the same figure as the 4.1GHz 9996, so LZMA compression on Zen 6c is bound by memory latency and branch behavior and not by clock.

Decompression went the other way, as the 9996 managed 5,334 MIPS, below Vera’s 6,016, while the 9686F’s 6,816 scaled with its 29% clock advantage over the 9996 and took the lead. Per clock, Olympus at 3.4GHz still has the best decompression result in the set.

Running across every thread shows what 1,024 threads do with that per-core speed.

With SMT on, the R9825 compressed at 2,034 GIPS and decompressed at 3,400 GIPS, 33% and 63% ahead of the 768-thread EPYC 9965 server at 1,527 and 2,081, and 2.1x and 2.3x Vera’s 957 and 1,496. The MRDIMM platform matched it within 12% on compression and 1% on decompression.

Measured per physical core, compression is level with Turin at about 4.0 GIPS, so the all-thread gain comes from core count, while decompression’s 6.6 GIPS per core clears Zen 5c’s 5.4 by 23%. The 9686F’s 1,397 and 1,900 GIPS on 192 cores work out to 7.3 and 9.9 GIPS per core, the highest per-core throughput figures in this review.

OpenSSL

OpenSSL’s AES-256-GCM test is where instruction-set width matters most. The x86 parts run AES on 512-bit registers with VAES, while Olympus has two 128-bit crypto pipes.

The gap is clearest on a single thread. One Zen 6c thread encrypted 18.1GB/s on the R9825, 2.9x Olympus’s 6.2GB/s and 24% ahead of Zen 5c’s 14.6GB/s, and the 9686F’s 22.5GB/s is the fastest single-thread figure we have recorded.

Across every thread, Venice’s core count multiplies that per-core advantage.

With SMT on, the R9825 reached 6.8TB/s, 1.7x the EPYC 9965’s 3.96TB/s, 2.7x the Xeon 6978P’s 2.57TB/s, and 5.4x Vera’s 1.26TB/s. VAES on 512-bit registers across 512 cores is a different class of bulk crypto throughput from two 128-bit crypto pipes on 176 cores, and for TLS termination or at-rest encryption done in software, the x86 side of this comparison is not close.

Python

Python is the workload NVIDIA cites most often for agent sandboxes, and pyperformance gives us three pinned single-thread tests of it: go, an object-heavy game-tree search; regex_compile, a regular-expression compiler; and nbody, a floating-point n-body loop. One software difference applies here: Venice and Vera ran Python 3.14.4 from Ubuntu 26.04, while the Turin and Xeon comparisons ran 3.12.3, which flatters Venice and Vera by a few percent against those two.

The 9996 splits the Python set with Vera, and the 9686F sweeps it. On go, the R9825 ran 60.4ms against Vera’s 58.1ms, a 4% Vera lead that sits inside run-to-run noise, and the 9686F’s 47.5ms took 18% less time than Olympus. On regex_compile, Vera’s 53.1ms took 14% less time than the 9996’s 61.5ms, and the 9686F’s 48.0ms took 10% less than Vera. On nbody, the floating-point loop, the 9996’s 45.3ms took 23% less time than Vera’s 58.8ms, and the 9686F’s 36.3ms took 38% less.

Against Turin, the 9996 cut run time by 33% on go, 20% on nbody, and 32% on regex_compile at a boost clock 400MHz higher, so most of that gain comes from the core. Because Venice also had the newer Python, read those Turin margins as upper bounds.

The Python results follow a consistent pattern across all three tests. Where a test is bound by memory latency on a working set past L2, as go and regex_compile are, Olympus’s 2MB L2 and graph prefetcher keep it level with or ahead of a 4.1GHz Zen 6c core. Where the test is bound by compute or clock, as nbody is, Zen 6c leads, and the 5.3GHz 9686F led all three.

Latentie van webserver, JVM en scheduler

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. Several of these results depend as much on how many threads each system runs as on how fast each core is, so they say less about Zen 6c itself than the earlier sections do.

NGINX

NGINX serves HTTPS requests to the wrk load generator running on the same machine, so client and server compete for the same cores. The result reflects the TLS and HTTP stack more than core count, and it plateaus around 300,000 to 400,000 requests per second on every 2026 server we have run.

With SMT off, the R9825 handled 374,000 requests per second at 1,000 connections and 317,000 at 4,000, against 381,000 and 360,000 for the EPYC 9965, 330,000 and 315,000 for Vera, and 321,000 and 337,000 for the 9686F. All of those sit in the plateau, and the Xeon 6978P’s 136,000 and 133,000 are the outliers. The test confirms that the Venice network stack behaves like every other x86 server’s, but it tells us nothing about core count.

Renaissance

Renaissance runs Java workloads on OpenJDK 11: its Finagle HTTP test exercises a Scala networking stack, its Akka test an actor-model concurrency framework, and a third test a genetic algorithm. The JVM schedules work across every logical CPU it sees, which puts a 512-core system like the R9825 at a structural disadvantage, so we list these results for completeness and do not rank them.

Test	Dell R9825 (2x 9996)	AMD ref (2x 9996, MRDIMM)	AMD ref (2x 9686F)	NVIDIA Vera (2x 88c)	EPYC 9965 (2x 192c)	Xeon 6978P (2x 120c)
Renaissance 0.16 on OpenJDK 11, milliseconds, SMT off (lower is better)
Finagle HTTP Requests	13,949	14,423	5,135	4,298	8,218	54,612
Akka Unbalanced Cobwebbed Tree	150,034	146,208	32,396	44,557	56,163	103,649
Genetic Algorithm (Jenetics + Futures)	1,836	2,596	2,234	2,170	2,250	10,767

 

The two 9996 configurations post the slowest Finagle and Akka times of the AMD systems, because the actor-model and Scala networking tests serialize on synchronization that grows with 512 threads. The 9686F, with 192 threads at 5.3GHz, posts the best Akka time in the set and trails only Vera on Finagle, while the R9825 leads the genetic algorithm at 1,836ms.

schbank

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, and we leave them unranked.

Test	Dell R9825 (2x 9996)	AMD ref (2x 9996, MRDIMM)	AMD ref (2x 9686F)	NVIDIA Vera (2x 88c)	EPYC 9965 (2x 192c)	Xeon 6978P (2x 120c)
schbench, 4 message threads, microseconds, SMT off (lower is better)
p50	142	155	64	177	87	423
p90	251	266	100	235	153	589
p99.9	3,804	1,245	1,335	339	3,104	3,721
schbench, 32 message threads (oversubscribed), microseconds, SMT off (lower is better)
p50	6,019	4,125	3,776	3,996	5,714	4,384
p99.9	44,821	29,003	28,368	32,320	44,565	37,935

 

The p99.9 at four message threads needs a further note. The R9825’s 3,804µs compares with 1,245µs on the identical processors in AMD’s platform, a tail-latency difference between the two firmware and board combinations that we have not isolated, although the four-thread medians match within 10%.

Linux-kernel bouwen

The Linux kernel allmodconfig build is comparable across the x86 systems, but Vera compiles the arm64 kernel tree, which includes a different set of modules and drivers from the x86-64 tree, so we leave it out of the chart and do not rank it.

With SMT off, the R9825 built the kernel in 99.4 seconds, 32% less time than the EPYC 9965’s 146.2 seconds and 2.6x faster than the Xeon 6978P’s 255.9. The MRDIMM 9996 configuration finished in 93.9 seconds, and the 9686F in 109.5. Turning SMT on slowed the R9825 to 103.1 seconds, and the MRDIMM 9996 to 101.3, so the extra threads did not help either 9996 build, while the 9686F improved to 100.8 seconds and the EPYC 9965 and Xeon 6978P slowed to 181.0 and 288.9. Vera, building its arm64 tree, took 180.7 seconds with SMT off and 196.4 with SMT on.

HamerDB

For the database tests, we again brought in Steve Shaw, HammerDB’s creator and maintainer. In November, Shaw ran HammerDB 6.1.1’s TPROC-C workload, an OLTP benchmark derived from TPC-C but not comparable to published TPC results, on four systems: the Dell PowerEdge R9825, the Vera server, a Dell PowerEdge R7725 with two 16-core EPYC 9175F, and AMD’s Nigeria reference platform with the 96-core EPYC 9686F. He tested four open-source engines on each: MariaDB 13.0.2, MySQL 26.10.0, VillageSQL 0.0.7, and PostgreSQL 18.6. The database size scaled at eight warehouses per online logical CPU.

Shaw ran the R9825 as a single EPYC 9996 socket with all 256 cores online and SMT off at 2,048 warehouses, Vera as its 88-core socket with SMT on at 1,408 warehouses, and the 9175F system as a 32-core two-socket server at 512 warehouses. He builds the single-socket profiles by taking the second socket’s CPUs offline through the Linux CPU hotplug interface, with no BIOS change, because none of the open-source engines scale across two sockets. A two-socket run shows heavy mutex contention and a lower peak, a limitation Oracle, SQL Server, and Db2 have already engineered around.

Because warehouse counts differ between the four systems, each engine’s peak is reported at the virtual-user count and database size that produced it, as in the October round. The October results for the 192-core EPYC 9965 socket, run on HammerDB 6.1 a month earlier, are in our Vera review. We reference them here only where the direction is unambiguous, because the client moved to 6.1.1 and MySQL moved from 26.7 to 26.10 between rounds, and Vera’s peaks on the same hardware shifted between a 12% drop and a 4% gain over the same interval.

On one socket, the 256 Zen 6c cores and the 88 Olympus cores split the four engines. The R9825 socket peaked at 2.39M new orders per minute (NOPM) on MySQL 26.10 against 2.10M for Vera, a 14% lead, and the two tied on VillageSQL at 2.60M and 2.59M. Vera kept MariaDB 13.0.2 at 2.53M against 2.26M, a 12% margin, and PostgreSQL 18.6 at 2.90M against 2.61M, an 11% margin. The two 9175F processors reached 1.21M, 0.68M, 0.94M, and 1.84M on MariaDB, MySQL, VillageSQL, and PostgreSQL, and that 1.84M on 32 cores at 5.0GHz is the best per-core result of the round.

CPU utilization at those peaks is the more telling number. The R9825 hit its PostgreSQL peak at 144 virtual users with the socket 18% busy, its MariaDB peak at 51%, and its MySQL and VillageSQL peaks at 74% and 75%. Vera’s peaks arrived at 35% to 74% busy, and the 32-core 9175F ran at 85% to 90% on three of the four engines.

None of the four engines could put 256 cores to work, which is the scalability ceiling Shaw has documented across every round of this campaign. The open-source engines top out well before the socket is used; lock handoff inside the engine sets the peak, and the processor waits. The R9825 database figures therefore measure how far each engine scales on one socket, and they understate what 512 cores can do with sharded or multi-instance deployments.

Tail latency at a matched load of 144 virtual users goes to Venice on every engine. PAYMENT p99 latency on the R9825 ran 2.87ms on MariaDB, 1.91ms on MySQL, 1.37ms on VillageSQL, and 1.48ms on PostgreSQL, against 4.11, 3.16, 2.82, and 2.34ms on Vera, so Venice’s tails were 30% to 51% lower. The EPYC 9965 also posted lower tails than Vera on most engines in October. The 9175F at 32 users posted 0.85, 1.35, 1.18, and 0.38ms, which is what a 5.0GHz core with 32MB of L3 per core does for an OLTP tail.

Shaw also ran the 96-core EPYC 9686F on AMD’s Nigeria platform as one socket, with its 96 cores online and SMT off at 768 warehouses. In the CPU-focused profile that matches the other systems, PostgreSQL peaked at 3.03M NOPM at 56 users with the socket 38% busy, the highest PostgreSQL result in the November round, ahead of Vera’s 2.90M and the 9996 socket’s 2.61M. MariaDB reached 2.28M, VillageSQL 2.10M, and MySQL 1.84M at 79% to 89% busy.

Shaw’s read is that the 5.3GHz part landed below his expectation, and that running with SMT off, his recommendation for the 256-core socket may be costing the 96-core one on the three MySQL-family engines. He also ran the 9686F socket with full durability, with binary logging on and WAL and fsync enabled, which is the configuration a production OLTP system runs and the one that puts the storage in the loop.

MariaDB 13.0.2 led that profile at 1.43M NOPM, ahead of VillageSQL at 1.39M, PostgreSQL at 1.30M, and MySQL at 1.09M, with PostgreSQL pushing 5.5GB/s to the Micron 9650 to get there. Bringing the second socket online at 1,536 warehouses lowered every engine’s peak to between 1.43M and 1.80M, which is the cross-socket contention Shaw describes above and the reason this section compares single sockets.

Vera’s November figures on NVIDIA’s updated firmware sit 5% below October on MariaDB and 12% below on PostgreSQL at peak, while gaining 23% to 24% at 16 users, which points to a shift in the scaling curve. Shaw’s October assessment that Arm has arrived as a competitive database server stands on this data. The November round adds that a 256-core Venice socket keeps pace with Vera’s 88-core socket on throughput and leads it on tail latency, with the engines, not the silicon, setting the ceiling on both.

Conclusie

AMD’s 6th Gen EPYC lands as the broadest server processor family on the market, and the SP7 flagship we tested resets the throughput ceiling for a two-socket x86 server. Two EPYC 9996 in Dell’s PowerEdge R9825 ran GROMACS benchPEP 1.8x faster than the 384-core Turin system, solved the large OpenFOAM mesh 2.6x faster, and encrypted at 6.8TB/s.

Those gains run well past the 33% increase in cores, because the Zen 6c core itself is faster per clock, carries four times the L3 per CCD, and now has sixteen channels behind it. Valkey is the exception among the headline results: one socket pushed 76.5M GET requests per second, 27% more than Zen 5c and short of the core-count increase, while SET throughput rose 65%.

Against NVIDIA Vera, Venice wins most of our compute tests: the 9996 leads by 2.5x per core on vector math, 5x in aggregate on software crypto, and 2x on all-thread integer throughput, and the 5.3GHz EPYC 9686F beats Olympus on every pinned single-thread test in the harness, including the latency-bound Python tests where Vera edges the 9996.

Vera still leads on raw memory bandwidth: against its 2,073GB/s on STREAM Triad, Venice trails by 42% on the R9825’s DDR5-8000 and by 8% on MRDIMMs, a gap that reverses on MRDIMMs once the reads STREAM doesn’t count are added back. It also holds a sizeable lead between sockets, where NVLink-C2C delivers 4.6x the remote-socket bandwidth of xGMI. The same NVLink-C2C link connects Vera directly to NVIDIA’s GPUs, and on CPU-to-GPU bandwidth, Vera is unmatched.

In the current market, memory is going to be the biggest pain point for buyers. On the DDR5-8000 our R9825 ran, the 9996 delivers 1,201GB/s and is so bandwidth-bound on the large OpenFOAM mesh that a 96-core 9686F on MRDIMMs finishes within 13% of it. MRDIMM-12800 lifts the same processors to 1,901GB/s and cuts that solve by 21%, against the 30% that 256 cores gain over 96 on the same MRDIMMs, so for memory-bound HPC the memory choice matters about as much as the core count. ClickBench stayed inside its 7% threshold on the faster memory, and the 256GB Valkey working set did not improve.

The weaknesses are specific to the densest part: a 512-thread system is slower than a 192-thread one on JVM workloads that synchronize across every logical CPU, ClickBench’s hot sum does not improve past 192 cores, and Valkey’s single-request path per core sits at Olympus’s level and below Zen 5c’s. Those are scaling and placement limits at 256 cores per socket, and buyers whose workloads look like that should look at the 96-core 9686F and the 128-core 9756, which is the catalog breadth AMD is selling against a single-SKU competitor.

On HammerDB, one EPYC 9996 socket traded engines with Vera’s socket, winning MySQL by 14%, tying VillageSQL, and trailing by 11% to 12% on MariaDB and PostgreSQL, while cutting PAYMENT tail latency by 30% to 51% at matched load. One 96-core 9686F socket posted the round’s highest PostgreSQL result at 3.03M NOPM. With no engine able to use more than three quarters of the 9996 socket’s 256 cores, the OLTP results say more about database scaling than about the processor.

The Dell server that hosted our primary EPYC 9996 testing earned the Best Overall Server award in our PowerEdge R9825 recensie, and HPE’s ProLiant Gen13 Venice systems are shipping alongside it, with the rest of the OEM lineup and the SP8 and Verano platforms following in 2027. For the data center buyer choosing a two-socket server today, the EPYC 9996 is the fastest general-purpose processor we have tested, and the 9686F is the one to pick when the workload wants clocks over cores. And next up is an intensive look at agentic performance, the one workload that next-gen buyers want a solution for.

Scorebord: The EPYC 9996 powers the Dell PowerEdge R9825, which holds Best Overall Server on our Beste servers leaderboard, where the EPYC 9996 and 9686F also appear in our measured server processor table.

Productpagina van de AMD EPYC 9006-serie