AMD EPYC Venice Brings Zen 6 With 27% Average IPC Gain Over Zen 5

AMD's EPYC 'Venice' is the first chip family to ship Zen 6, and it's the reason to pay attention to this generation. We spent several weeks testing two of these processors against Nvidia's Vera and asking a simpler question too: how far has Zen 6 moved from Zen 5? The answer is further than a typical generational refresh, though not as far as a clean-sheet redesign. Consumer-focused Olympic Ridge chips are expected next year, so the data-center results here will likely shape what desktop buyers see later. Zen 5 was a ground-up rebuild of AMD's core. Zen 6 keeps that foundation and widens it in almost every direction. The result is more of a sustained push than a new architecture, and it holds up in the benchmarks.

What changed inside the Zen 6 core

Zen 6 is built on TSMC's N2P node, but the more interesting changes are inside the core. The vector engine has been redesigned to push SIMD throughput higher, and it now handles half-precision FP16 instructions natively instead of converting them, alongside standard 32-bit precision. AMD has also split the integer schedulers in the execution engine, which lets more instructions be in flight at once. Zen 6 is neither a minor tweak to Zen 5 nor a full architectural reset. It's the same basic design with most of the dials turned up, and that's visible in the performance numbers.

The headline figure is a 27% average IPC uplift over Zen 5 across enterprise, cloud, and AI workloads. Read that number carefully. The debut is aimed squarely at the data center, so it doesn't automatically carry over to desktop or other workloads. AMD also measured it by comparing Zen 5 and Zen 6c at fixed frequency, with the Zen 6c part at 16 cores. That's a fair comparison for density, but it's not the same as a clock-for-clock test of two full-size cores. The process node underpins some of this. N2P is an optimized version of N2 that adds about 5% performance on top. Measured against N3E, which Zen 5 didn't use (it ran on N4P), N2P delivers an 18% speed gain at equal power, or a 36% power reduction at equal speed. Density improves about 15%.

	Speed Improvement (v. N3E)	Power Improvement (v. N3E)	Density (v. N3E)
TSMC N2P	+18% (iso-power)	-36% (iso-speed)	+15%

AMD described Zen 5 as a ground-up redesign when it debuted in mid-2024. It featured a wider execution engine that could dispatch and retire eight instructions per cycle, a wider frontend to feed it, full AVX-512 support, and doubled bandwidth between L2 and L1 cache. Zen 6 keeps many of those characteristics and the same general topology. The changes are refinements, not replacements. One detail is easy to miss. Zen 6 and Zen 6c share the same microarchitecture. Zen 6c is a space-optimized version that uses less power, runs at lower clocks, and takes up less die area. That matters because Intel's E-cores use a different design from its P-cores, while AMD keeps a single core design across both variants.

The frontend is mostly unchanged from Zen 5, but the handful of improvements are useful. It keeps the dual 4-wide decode pipes and 8-wide dispatch, while the branch prediction unit and op cache get attention. The return address stack grows to 64 entries from 52. The op cache returns to 6.75K entries, up from 6K on Zen 5, which matches Zen 4's size. More importantly, it can now serve 18 micro-ops per cycle, up from 12.

The backend changes are more substantial. Zen 5 used a unified integer scheduler. Zen 6 splits it, offering 96 shared ALU/AGU entries and 48 dedicated ALU entries, compared with Zen 5's 88/56 ALU/AGU split. The general-purpose physical register file grows to 352 entries from 240. Those are the kinds of changes that let a core keep more work moving without stalling, and they're where a 27% IPC claim starts to look plausible.

The vector side builds on Zen 5's true 512-bit datapath and extends it. The big addition is native AVX-512 FP16 support, which Zen 5 had to handle through conversion. Load and store bandwidth also shifts. Zen 5 could do two loads of any size, while Zen 6 can do either two 512-bit loads or four 256-bit loads. Stores stay the same, at one 512-bit or two 256-bit per cycle.

Cache hierarchy is largely the same. Zen 6 keeps the 48 KB 12-way L1 data cache and the 1 MB 16-way private L2 per core. The shared L3 remains a victim cache for L2, as on Zen 5. The main change is a larger in-flight window, with an 80-entry load queue and a 128-entry store queue.

The CCD and platform: more cores, more memory, more I/O

The biggest structural change is the Core Complex Die. Zen 6 CCDs scale to 12 cores, up from 8 on Zen 5. Zen 6c CCDs reach 32 cores, double the 16 of Zen 5c. Most other CCD specs either hold steady or improve.

Standard Zen 6 keeps 4 MB of L3 per core, so a 12-core CCD carries 48 MB. Peak frequency rises to 5.3 GHz from Zen 5's 5 GHz. Those figures come from Venice parts, and AMD's consumer chips should clock higher. Zen 6c gets more change. L3 per core doubles from 2 MB to 4 MB, matching the standard CCD. With twice the cores and twice the cache per core, a Zen 6c CCD carries 128 MB of L3, four times what a Zen 5c CCD holds. Peak frequency climbs to 4.1 GHz from 3.7 GHz. AMD also claims a "large core IPC uplift" and better power and SMT efficiency across both core types. It hasn't published a single overall IPC number for the CCDs, but the 27% figure above puts Venice roughly 27% ahead of Turin in enterprise, cloud, and AI work.

On the SP7 platform, Venice can fit up to eight CCDs. That's 256 cores with Zen 6c and 96 cores with standard Zen 6. SP7 is also a physically larger socket than the SP5 used for Genoa and Turin, measuring 76 x 80 mm against SP5's roughly 72 x 75 mm.

The most significant I/O change is the split I/O die. Earlier EPYC generations used one IOD. Venice uses two, placed in the middle of the package and flanked by Zen 6 CCDs. The second IOD is what lets SP7 talk to 16 memory channels per socket, eight per die. With MRDIMMs in a 1DPC layout, that supports up to 12,800 MT/s. With standard RDIMMs, the ceiling is 8,000 MT/s. Platforms can reach 8 TB of memory per socket, and AMD claims up to 1.6 TB/s of bandwidth per socket with MRDIMMs, dropping to 1 TB/s with RDIMMs. The IOD also carries the hardware root of trust and AMD's confidential computing extensions, covering execution encryption, memory integrity, and trusted I/O. PCIe 6.0 is new, running at up to 64 Gbps per lane. A 1P SP7 system gets 96 PCIe 6.0 lanes, and a 2P system gets up to 128. Each configuration also includes "bonus" PCIe 4.0 lanes: eight for 1P and 16 for 2P.

Here's the catch. The 2P lane count comes with an asterisk. Two 64G SerDes interfaces bring PCIe into each IOD, and one of them links the two sockets in a 2P setup. The second interface can carry an extra 12 PCIe 6.0 lanes, which is where the "up to" 128 figure comes from. The bonus lanes run over a separate, smaller 16G SerDes. SP8 makes the opposite trade. It's a smaller 62.5 x 80 mm socket that drops to eight memory channels, though it keeps the same 12,800 MT/s MRDIMM support. Peak bandwidth falls to 819 GB/s with MRDIMMs and 512 GB/s with RDIMMs.

In exchange, SP8 gets 64 PCIe 6.0 lanes per IOD, or 128 per socket, plus eight PCIe 4.0 bonus lanes. In 2P SP8 servers, some lanes are shared between sockets, bringing the total to 192 PCIe 6.0 lanes with 16 additional PCIe 4.0 lanes. Both platforms support CXL 3.1. If you're building I/O-heavy accelerator or storage nodes, SP8 is probably the more interesting option. If you need memory capacity, SP7 is the answer. AMD also outlined Verano, its upcoming platform built on Zen 6 but paired with LPDDR5X memory and replaceable SOCAMM2 modules. That's a different memory story, and we'll get to [Verano next year](https://www.tomshardware.com/pc-components/cpus/amds-epyc-verano-ai-host-cpu-will-reportedly-use-a-special-sb1-socket-zen-6-chip-pairs-72-cores-with-a-24-channel-lpddr5x-memory-subsystem).

UPP, UBPS, and FAST: platform power features

Venice also adds several operational features that matter once the hardware is racked. None of them will make headlines, but they'll decide how much power a rack actually draws.

The first is UPP, Unified Power Provisioning. It looks at total platform power and allocates it to components according to the workload. AMD says this lets a rack run 18 servers at 706W where it previously needed 830W for 16, a 15% cut in provisioned power that also fits more servers per rack. Those are AMD's numbers, and the real test is whether operators see the same headroom in their own racks. UBPS, Utilization Based Power Scaling, is a dynamic feature that adjusts power to match the running workload. AMD says it "helps close the gap between provisioned and consumed power." Like UPP, it works at the platform level rather than only at the CPU.

FAST, Frequency Adaptive Spectrum Technology, is the most interesting of the three. It reads platform telemetry and firmware policies, then adjusts frequency within set power and thermal limits. It's more involved than a simple Precision Boost Overdrive for servers, and that's the point. AMD described FAST to us as a way to create two performance tiers inside one socket. Using a 96-core Venice part as the example, 32 cores run in a "premium" tier with a 3.65 GHz base and 5 GHz max clock. The other 64 cores form a "batch" tier at 2 GHz base and 2.4 GHz max. AMD's framing is that one socket can behave like several commercial SKUs. For operators running mixed workloads, that's a useful idea. Whether it works in practice depends on how well the scheduler and firmware policies match real jobs.

MEXT: flash as memory, with caveats

Venice is also the first EPYC generation where AMD will offer MEXT. AMD acquired the technology earlier this year and has been using it internally. With HPE, AMD is rolling out "MEXT ready" platforms that will be eligible for MEXT licenses later. Given how tight memory supply is right now, the pitch is easy to understand.

The core idea is using flash as if it were DRAM. Even the fastest flash is orders of magnitude slower than memory, so MEXT tries to exploit DRAM access patterns to expose more capacity to the system than is physically installed. Pages that haven't been touched in several minutes get pushed to flash. An AI model predicts which pages will be needed next, and those pages are pulled back into memory before they're used.

On paper, that sounds almost too good to be true. AMD's answer is that MEXT uses a transformer-based model, and LLMs are essentially predicting the next token. Here, the bar is lower than you'd think. As long as the model streams the right pages in fast enough to hide flash latency, the exact order doesn't matter. That's a plausible argument, but it also means the prediction quality has to hold up across very different workloads. MEXT ships as a Linux kernel module. AMD has deployed it on 145 internal servers and plans to grow that to more than 2,000 next year. Its first targets are critical EDA workflows, including Synopsys PrimeTime. AMD says PrimeTime keeps 95% of its performance on Venice with half the system DRAM. Drop to 25% of DRAM, and AMD claims the application still holds 80% of its performance.

Those are vendor numbers on a single application, and AMD was clear that MEXT only applies to certain workloads today. It's exclusive to EPYC. Plenty of workloads won't tolerate a 50% DRAM cut, and some will need a far more conservative reduction, 25% or less. Treat MEXT as a targeted tool for now, not a general way to stretch memory.

How we tested Venice

AMD gave us access to two Zen 6 Venice systems, both dual-socket servers. The first ran the dense EPYC 9996, a 256-core, 512-thread part per socket. That makes 512 cores and 1,024 threads across the 2P system. It's built for peak throughput under heavy concurrency. The second system used the EPYC 9686F, a 96-core, 192-thread CPU, for 192 cores and 384 threads in 2P form. The "F" suffix marks a high-frequency SKU meant for demanding single-threaded and per-core-heavy work, in contrast to the dense 9996 aimed at throughput. Those two chips represent AMD's two sides of Venice: maximum core count and maximum per-core speed.

Chip

Cores / Threads

Base / Boost Clock (GHz)

Spec sheets set expectations, but they don't settle anything. Here's how the two Venice chips in this comparison line up against the rest of the SP7 lineup, with the clock and cache figures that matter most for throughput.

Model	Cores / Threads	Base / Boost (GHz)	L3 Cache	TDP
EPYC 9996	256 / 512	2.55 / 4.1	1024 MB	600W
EPYC 9966	192 / 384	2.9 / 4	768 MB	600W
EPYC 9846	168 / 336	2.85 / 3.7	768 MB	500W
EPYC 9756	128 / 256	3.15 / 4	512 MB	500W
EPYC 9656	96 / 192	3.05 / 3.7	512 MB	400W
EPYC 9686F	96 / 192	3.4 / 5	384 MB	500W
EPYC 9556	64 / 128	2.75 / 4.3	384 MB	300W
EPYC 9586F	64 / 128	3.75 / 5	384 MB	500W

Both chips use AMD's SP7 socket, the platform built for data centers and the higher core count SKUs. The upcoming SP8 socket goes after enterprise buyers instead, with fewer cores and fewer memory channels. That split tells you where AMD expects the volume to be.

EPYC 9996: density over clocks

The 9996 is a dense design built on Zen 6c cores, and its numbers reflect that. The 4.1 GHz boost clock is respectable, but the 2.55 GHz base is the figure to watch. Expect it to spend much of its time near that base in real deployments, not at the boost headline.

What you do get is a massive 1,024 MB pool of L3 cache and a 600W rated TDP. That TDP can be manually adjusted anywhere between 400W and 600W, which gives operators a real knob to trade power for performance.

EPYC 9686F: the one to watch

The 9686F is where AMD's Venice claims get tested. It's one of only two chips in the SP7 lineup that boosts to 5 GHz, and it does it with 96 cores and a 500W TDP. Like the 9996, it can run between 400W and 600W.

This is the SKU AMD has leaned on hardest, pitching it as a published Venice benchmarks entry labeled as a "96-core HF" model. And that's a deliberate choice. Honestly, the 9686F is the more interesting chip of the two, and not just because of the clock speed.

It's squarely aimed at Nvidia's Vera CPU, and not only on core count. The two trade wins across several benchmarks. AMD is positioning the 9686F as its "agentic CPU" in the Venice lineup, which mirrors how Nvidia has pitched Vera. If you're evaluating hardware for agent workloads, this is the matchup that matters.

Test platforms and the memory story

Test Platform	Memory	Tested Processors
2P AMD Nigeria reference platform	32 x 64 GB (2 TB) SK hynix DDR5-12800 ECC MRDIMM	AMD EPYC 9996, EPYC 9686F
2P AMD Volcano reference platform	24 x 64 GB (1.5 TB) SK hynix DDR5-6000 ECC RDIMM	AMD EPYC 9965, EPYC 9755
2P Supermicro SYS-222HA	24 x 64 GB (1.5 TB) Micron DDR5-8800 ECC MRDIMM	Intel Xeon 6980P
2P Nvidia MGX Vera reference platform	16 x 96 GB (1.5 TB) Samsung LPDDR5-9600 ECC SOCAMM2	Nvidia Vera

The Nigeria platform is the one that carried the Zen 6 results. It ran top-end DDR5-12800 MRDIMMs, with 32 sticks arranged to fully saturate the 16 memory channels. That's a big step up in memory support, and it's central to Venice. It matters most for the 9686F, because that's the chip going head-to-head with Vera.

Vera takes a different route. Its LPDDR5 SOCAMM2 modules hit higher transfer rates than standard RDIMMs while staying field-replaceable. But it does this across a fairly modest eight-channel setup. Nvidia's bet is that Vera's topology moves data across the chip well enough that it doesn't need more channels.

AMD's design goes the other way. Its distributed architecture needs more memory bandwidth to feed the cores, so it doubles the channels and pushes higher transfer rates through MRDIMMs. Which raises the question of cost and power at the platform level, and that's a question the numbers here don't answer.

SPEC CPU 2026 estimates

SPEC CPU 2026 is the de facto industry benchmark for server CPUs, so it's where we start. The numbers below are estimates. They come from real SPEC runs, but they haven't been submitted to the SPEC committee, which is why they carry that label.

For the throughput suites, intrate and fprate, we ran as many copies of each application as the chip had threads. Everything ran on Ubuntu Server 26.04 with Linux kernel 7.0. We used GCC 15.2 for every system except the Venice chips, which got GCC 16, because that's the release with official Zen 6 support.

That mismatch would normally be a problem, so we checked it. Regression testing against GCC 15 showed only minor differences, nothing that changes the standings. Using GCC 16 also kept the optimization flags consistent across the Venice parts. We used common GCC flags, fast link-time optimization, and march/mcpu settings to expose the right instruction support, and jemalloc as the memory allocator on every system.

The intrate results set the tone, especially for the 9996. In a 2P configuration it exposes 1,024 threads, and that multiplies Zen 6's per-core gains across a much larger pool. Against last-gen's top-end EPYC 9965, the 9996 scores 93% higher. That's a big number, but it needs context.

Throughput benchmarks reward how much work gets done and how fast. The 9996 gets the thread-count boost on top of the core-level improvements, so the gain compounds. But it isn't uniform. The 93% lead shows up in this test, not across the board.

The 9686F tells a more nuanced story. It doesn't double the previous generation, and that's fine for AMD, though it's not the headline. We didn't have a 9575F to make a clean gen-on-gen comparison. The closest proxy was the EPYC 9755, with 128 cores and a 4.1 GHz boost. Against that chip, the 2P 9686F comes out 19% ahead, despite having 32 fewer cores per socket.

The more pointed result is against Nvidia. The 9686F is 17% ahead of Vera in intrate. Vera holds its own against the x86 field, though, as its matchup against the 9755 and Intel's flagship Granite Rapids-AP 6980P shows.

fprate results

Floating point is where AMD's vector engine work shows. The gap between the 9996 and 9686F is smaller here, and neither chip is held back. The 9686F pushes close to the 9996's numbers, and both Zen 6 parts pull well clear of the field.

Compared with Zen 5, AMD more than doubled the fprate score. That's a serious generational jump. Against Vera, the 9686F leads by 40% in fprate, even though Vera's core count is 88 and the 9686F's is 96. That's a small core-count gap doing a lot of work. Intel's Granite Rapids-AP isn't really in the conversation on raw performance, but Intel has increased production of its server parts anyway, a sign of how tight CPU supply has become.

Throughput is the more honest test of how these chips get deployed, with many application copies running at high concurrency. SPEC's speed suite asks a different question: how fast one application runs when it has the whole chip. That's closer to how a client CPU gets judged.

Here the 9686F's 5 GHz clock does what you'd expect. In the integer speed suite, the frequency-optimized part is 21% ahead of Vera in a 2P configuration. The 9996 holds up well too, falling short of the 9686F despite having much more inter-CCD communication to manage. That's a meaningful result for a chip built around density.

Zen 6's gains stack. The new microarchitecture brings an optimized vector path. There are more cores per CCD. Memory speeds go up, and so do channel counts. Each of those is a solid but unremarkable improvement on its own. Put them together on a workload that can use all of them, and the generational jump looks a lot bigger.

Python and memory bandwidth in agentic workloads

Two performance vectors matter most for agentic workloads right now: memory performance and Python performance. Most agent frameworks are built in Python, with LangGraph and CrewAI as prominent examples. Alternatives written in TypeScript and Rust are starting to show up, but Python still carries the weight. If you're buying CPUs for agents today, Python throughput isn't optional.

Memory bandwidth matters too, particularly for agents that query large databases. That holds whether the data lives in a traditional SQL relational database or a non-relational one. It's the reason the platform-level memory configuration above isn't a footnote.

Start with STREAM, the memory bandwidth benchmark that nearly everyone in data center work still uses as a baseline. Here AMD's Venice parts beat Nvidia's Vera by somewhere between 11% and 19%, depending on the test. That's a real gap, but the number depends heavily on how you pin the threads. Under the OpenMP "true" process binding policy, each process is locked to the thread it started on, which keeps the scheduler from shuffling work around and muddying the results. Vera holds its own under that setting. The interesting part comes when you change the policy.

The "spread" policy also binds processes, but it scatters them across the chip, placing them as far from one another as possible. AMD's chips gain nothing from this. Intel's Granite Rapids-AP actually slips slightly. Vera is the outlier: its mesh cache and monolithic die let it convert spread placement into a large performance jump, and it finishes well ahead of the field. If your workload resembles that pattern, the Vera result matters more than the headline AMD lead suggests.

Memory bandwidth and the MBW results

The MBW results tell a more split story. At a small 128 MB array size, the pair of EPYC 9996s edges out Vera. Push the array larger and Vera takes first place. AMD has clearly closed the gap on the memory side, with 16 memory channels and support for 12,800 MT/s MRDIMMs. Still, Vera's topology and an already strong memory subsystem keep it on top where it counts. Credit AMD for narrowing the gap; it hasn't closed it.

Python: where AMD pulls away

The memory differences fade once you move to Python, which is a far more contested field. PyBench gives the broad picture. Across the suite, the EPYC 9686F is 32% faster than Vera, while the EPYC 9996 settles for a 14% lead, held back by its lower boost clocks. Gen-on-gen, the 9996 is 24% ahead of the EPYC 9965. The 9686F lands 35% ahead of the 9755, but a good chunk of that comes from its boost clock running 900 MHz higher. That's a frequency story as much as an architecture one.

PyPerformance drills into individual Python applications and functions, and the same pattern holds. Other CPUs shuffle around the rankings, but the EPYC 9686F leads by a clear margin across most of the tests. That's not surprising. Python leans heavily on a single thread at stock settings, and the 9686F's clock advantage pays off directly there.

The exception worth your attention is the networkx benchmark, where the throughput-oriented 9996 takes the top spot and matches Nvidia's Vera. Vera is an impressive chip, especially given Nvidia's short history in data center CPUs and a spec sheet that doesn't look aggressive on paper. But Venice makes a strong case that the CPU market is AMD's to win, or to lose.

Compression and rendering: AMD's home turf

Stepping outside the agentic AI conversation for a moment, AMD keeps proving itself as the leader in general-purpose data center work, and Venice continues that run. Some of these workloads touch agentic AI depending on how an agent is built. Database speed matters, for instance, if an agent spends its time querying a database. We're keeping the analysis broad, though, because EPYC chips will run a wide mix of jobs, and much of that mix has nothing to do with agents.

On compression, AMD generally owns the top of the charts for both compression and decompression throughput, and zstd and 7-Zip follow that pattern. Vera grabs an early lead in zstd at the lowest compression level. That advantage evaporates quickly, though. Its weak decompression shows up even at level 3, and at level 19 AMD wins outright while Vera drops further back on decompression.

Long mode is where things get uncomfortable for Vera. The rankings hold steady, but Vera's results decline under sustained compression, while AMD keeps far more of its speed. At level 3, Vera and the EPYC 9686F are within measurement noise of each other. On decompression, Vera lands at the bottom of the pack.

7-Zip has been AMD's stronger suit for years, and these charts make the point bluntly. The gaps against Vera are multiplicative, not incremental, and Intel's Granite Rapids-AP barely registers as competition. What makes this more striking is that Zen 6 already posts high baseline numbers across a wide range of workloads, and compression is compounding on top of that.

Blender shows the biggest generational jump. The EPYC 9996 beats the EPYC 9965 by somewhere between 30% and 40%, depending on the scene. The gains hold even in demanding scenes like Barbershop, where render times are measured in minutes rather than seconds on many chips. There, the 9996 finishes 35% faster than the 9965. The 9686F matches the 9965 despite having half the cores, which says more about per-core efficiency than the core count suggests. Vera doesn't appear in the Blender results because no native Arm build exists.

C-Ray is a different story. Vera keeps the top spot at both 4K and 1080p, though a dual EPYC 9996 configuration sits close behind. OSPRay flips the result. AMD posts clear leads in real-time ambient occlusion, scientific visualization, and path tracing. The 9996 nearly triples the performance of the Xeon 6980P and Vera in ambient occlusion and scientific visualization, which are the kind of margins that stop being a rounding error.

The reworked vector engine in Venice becomes most visible in the dim_512 tests. Those workloads hammer both the vector units and memory bandwidth at once, so they expose whether a chip's gains hold up under real pressure.

Java and database workloads

Java is the language you'll find underneath everything from scientific computing to database engines, so we ran three Java suites. Java SciMark puts the EPYC 9686F well ahead, with a 92% composite lead over Vera. On a like-for-like generational basis, the EPYC 9996 delivers a solid 24% gain over the EPYC 9965.