Ryzen 9 L3 Cache and Minecraft Servers: What X3D Chips Change

Most talk about CPUs for Minecraft is about clock speed, and for good reason. Cache gets less attention, even though it has a lot to do with how often a core sits idle waiting for memory. This post covers the cache side: what L3 cache is, why a Minecraft tick is sensitive to it, and what the jump from 64 MB to 128 MB on an X3D chip does and does not tell you.

Clock speed has its own post: Ryzen 9 9950X and clock speed for Minecraft servers.

What L3 cache is

A CPU keeps small, very fast memory on the chip itself so it doesn't have to go out to RAM for every piece of data. L1 and L2 are the smallest and closest to each core. L3 is the last and largest level before main memory.

When the data a core needs is already in cache, it gets it almost straight away. When it isn't, the core waits for RAM, which takes many times longer. A bigger L3 means more of your server's working data can stay on the chip.

Why a Minecraft tick leans on cache

On vanilla, Paper and Purpur, the world tick runs on one main thread. Every tick it works through the entities, block entities like hoppers and furnaces, redstone and scheduled block updates in every chunk within simulation distance of a player, plus whatever plugins schedule. To keep 20 ticks per second, each tick has to finish in 50 milliseconds or less (spark docs).

That data is spread across a lot of memory. Every mob, item frame, hopper and chunk section is its own object somewhere in the Java heap. The more of that working set fits in L3, the less time the main thread spends waiting on RAM.

Folia works differently. It splits the world into regions that tick in parallel on several threads, so there is no single main thread. See Folia vs Paper for how that works.

How much cache the Space-Node CPUs have

These are AMD's published figures for the five CPUs behind our Minecraft plans.

Sources: AMD product pages for the 7950X3D, 9950X, 7950X, 5950X and 3900X. Because of hardware shortages, the plan selector notes that the exact CPU in any region can vary between similar Ryzen models, with similar or higher single-thread performance than the one listed.

Four of the five have the same 64 MB of L3. The odd one out is the 7950X3D, which is the chip in our USA region.

What X3D means

X3D chips carry AMD 3D V-Cache, an extra layer of cache stacked onto the processor. On the 7950X3D that brings the L3 total to 128 MB, double the 9950X.

The extra cache is not spread over the whole chip. The 7950X3D has two compute chiplets, and in April 2026 AMD called the Ryzen 9 9950X3D2 its first desktop processor with 3D V-Cache on both of them (AMD press release). On the 7950X3D, the stacked cache sits on one of the two.

X3D is not a free upgrade on every other spec either. AMD lists the 7950X3D with a 4.2 GHz base clock and a 120W TDP, against 4.3 GHz and 170W for the 9950X. Both have a 5.7 GHz max boost. The 7950X3D is also a Zen 4 chip, while the 9950X uses the newer Zen 5 core. For the clock and core side of that trade, read the clock speed post. The 7950X3D post goes into that chip on its own.

When a bigger cache is likely to help

A larger L3 pays off when the tick touches more data than fits in a smaller one. That tends to be the case on worlds with:

• lots of ticking chunks at once, because players are spread out or simulation distance is high
• big mob farms, villager halls and item sorters
• heavy tech modpacks full of machines, pipes and cables
• many block entities in a small area, such as large storage rooms

How much it helps depends on the world, the version and the plugins or mods. We don't publish a percentage because we don't have a test we can share that backs one up.

When cache size won't fix your lag

Plenty of lag has nothing to do with cache:

• One plugin or mod eating most of the tick. Fix or replace it and you gain more than any CPU swap would give you.
• Chunk generation while players explore. Pre-generating the world with a tool like Chunky helps far more.
• Garbage collection pauses from too little or too much heap, or poor JVM flags.
• Network latency. If players are far from the server, every action feels late, whatever the CPU.

A small vanilla world with a few friends gives the tick far less data to work through, so an X3D chip is unlikely to make a noticeable difference there.

Measuring your own server

The only numbers that matter are the ones from your own world. spark is the easiest way to get them. Paper has shipped with spark built in since 1.21 (PaperMC docs). On Fabric, Forge or NeoForge you add the spark mod (spark downloads).

1. Run /spark tps at a busy moment. It shows TPS and MSPT (milliseconds per tick).
2. Look at MSPT first. TPS stops at 20, so it only drops once you are already out of time. MSPT shows how much of the 50 ms budget each tick uses, including the median and the 95th percentile (spark: TPS and MSPT).
3. If MSPT is high, run /spark profiler start --timeout 300 while the lag is happening, then open the report. It shows which plugins, mods, entities or tasks use the tick time (spark commands).

Write down the setup next to the numbers, or they mean very little later:

• server software and version (Paper, Purpur, Fabric, NeoForge) and the Minecraft version
• the world: its size, whether it is pre-generated, and any big farms
• how many players were online
• the plugin or mod list
• view distance and simulation distance
• RAM given to the server and the JVM flags
• the plan, region and CPU it ran on

We only publish performance numbers from our own hardware when we can share the full setup behind them, so anyone can repeat the test. Until then, this page sticks to AMD's published specs. Our MSPT guide goes deeper into reading the numbers.

Checking which CPU you are on

On a VPS or dedicated server with shell access, this shows the CPU model and its cache sizes:

lscpu | grep -E 'Model name|MHz|cache'

On a hosted game server without shell access, check the plan page or ask your host. At Space-Node the CPU per region is listed on the Minecraft hosting page.