CPU vs GPU, a plain-English guide to how chips do math

May 22, 202616 min read#hardware#cpu#gpu#explainer

CPU vs GPU, a plain-English guide to how chips do math

If you've ever shopped for a server, you've probably been told that GPUs are "faster" than CPUs. And if you've ever tried to figure out why, you've probably hit a wall of jargon: TFLOPS, tensor cores, VNNI, FP4, INT8, sparsity, HBM3e. It's a lot.

We spend our days helping customers pick the right hardware for the job, so we decided to write the explainer we wish we could just hand people. No marketing speak, no glossing over the tricky parts, just a walk through what modern chips actually do when they "do math," why the differences matter, and how to think about picking the right one for your workload.

We'll compare six chips that span the whole landscape: the AMD Ryzen 9950X (consumer desktop CPU), AMD EPYC 9965 (top-tier server CPU), Nvidia RTX 3090 (last-gen consumer GPU), Nvidia RTX 5090 (current consumer GPU), Nvidia B200 (datacenter AI flagship), and Nvidia B300 / Blackwell Ultra (the new king as of January 2026).

Buckle up. This one's going to be fun.

The fundamental split: sequential vs parallel

Before we get into specs, let's nail down the core philosophy. CPUs and GPUs aren't really competing, they're optimized for different shapes of problems.

A CPU like the 9950X has 16 cores, each running at around 5 GHz. Each core is incredibly sophisticated: it can branch, predict the future, reorder instructions on the fly, and handle pretty much any kind of math you throw at it. But there are only 16 of them.

A GPU like the 3090 has 10,496 "CUDA cores" running at around 1.7 GHz. Each individual core is much simpler than a CPU core: they have to do roughly the same operation in lockstep with thousands of their neighbors. But there are a lot of them.

No. Work is branchy,
sequential, full of decisions

Yes. Identical math,
enormous data set

GPU: thousands of simple cores

Roughly 10,000+ cores at about 1.7 GHz

Each core is simple and runs in
lockstep with thousands of neighbors

Plus tensor cores: dedicated
matrix-multiply specialists

CPU: a few brilliant cores

Roughly 16 cores at about 5 GHz

Every core can branch, predict,
reorder, and run any kind of math

Does the same math need to run
on millions of data points at once?

This gives us our first rule of thumb: CPUs win when work is sequential, irregular, or branchy. GPUs win when the same operation needs to happen to millions of data points at once.

A single math operation? Faster on the CPU. A million math operations on a million numbers? Faster on the GPU. By a lot.

The math types each chip actually supports

Here's where it gets interesting. Both CPUs and GPUs can technically do any math operation, but they have specialized hardware that makes certain operations dramatically faster. Let's look at what's actually inside each chip.

What the 9950X (and EPYC 9965) has

These are AMD's Zen 5 CPUs. Each core contains:

  • Scalar integer ALUs for regular operations like a + b on whole numbers
  • Scalar FPUs for regular floating-point math
  • AVX-512 SIMD units that operate on 512-bit vectors at once, meaning a single instruction can crunch 16 FP32 numbers or 8 FP64 numbers simultaneously
  • VNNI instructions specifically designed for the dot products that neural networks need
  • Hardware accelerators for AES encryption, SHA hashing, and CRC checksums

The EPYC 9965 is essentially the same architecture, just scaled to 192 cores per socket with 12-channel DDR5 memory (giving it ~576 GB/s of bandwidth, six times what a 9950X gets).

What the Nvidia GPUs have

Nvidia GPUs have three completely separate math pipelines on the same chip:

  • CUDA cores for general-purpose FP32 and INT32 work
  • Tensor cores that do matrix multiplications in various precisions (FP16, BF16, FP8, FP4, etc.)
  • RT cores dedicated to ray-tracing math (only relevant for graphics)
  • FP64 units, and here's the kicker: these are deliberately weak on consumer cards. A 3090 does FP64 at 1/64th the speed of FP32. Nvidia reserves strong FP64 for datacenter cards like the B200 and B300.

The B200 and B300 throw out the RT cores and display engines entirely. Every transistor goes to tensor cores, memory controllers, and inter-GPU links. They're not really GPUs in the traditional sense anymore. They're AI math accelerators that happen to share heritage with gaming chips.

The big throughput comparison

Now we can actually compare apples to apples (and apples to oranges, and oranges to particle accelerators). Here's what each chip can theoretically do at peak in trillions of floating-point operations per second:

Chip FP64 FP32 FP16 (tensor) FP8 (tensor) FP4 (tensor) Memory BW
Ryzen 9950X 1.3 TF 2.6 TF 5.3 TF 10.5 TF n/a 96 GB/s
EPYC 9965 13.8 TF 27.6 TF 55 TF 110 TF n/a 576 GB/s
RTX 3090 0.56 TF 35.6 TF 142 TF n/a n/a 936 GB/s
RTX 5090 1.6 TF 105 TF 419 TF 838 TF 1,676 TF 1,792 GB/s
B200 SXM 40 TF 80 TF 4,500 TF 9,000 TF 18,000 TF 8,000 GB/s
B300 SXM 60 TF 120 TF 6,750 TF 13,500 TF 27,000 TF 8,000 GB/s

Some observations that jump out:

The 9950X actually beats the RTX 3090 at FP64. This is one of those facts that surprises people. Double-precision math is intentionally crippled on consumer GPUs because Nvidia wants HPC customers buying the expensive datacenter cards. If your scientific code needs full FP64 precision, a dual-socket EPYC system can outperform a 5090.

The B300 is on a different planet for AI math. Its FP4 throughput (27 PFLOPS dense) is roughly 250 times what an RTX 5090 can do, and the 5090 is itself massively more powerful than the 3090 was.

Memory bandwidth scales with the same logic. The 9950X moves data at 96 GB/s. The B300 moves it at 8 TB/s, eighty-three times faster. This matters enormously because most real-world workloads are memory-bound, not compute-bound.

"Wait, the 5090 has more cores than the B200?"

This is one of the most common things customers ask us, and it's a great question. The RTX 5090 has 21,760 CUDA cores. The B200 has around 16,896. So why is the B200 dramatically more powerful for AI?

The answer is that "core" means something completely different depending on which unit you're counting.

A CUDA core is a scalar fused multiply-add unit. It does one operation per clock: a × b + c = d. That's it. One number in, one number out.

A tensor core is an entire matrix-multiplication unit. It does a full 4×4 (or larger) matrix multiply-accumulate per clock, meaning hundreds of multiply-adds in a single instruction. The RTX 5090 has 680 tensor cores; the B200 has about 640 tensor cores, but each one is much wider and runs on silicon that's dedicated almost entirely to AI math.

Three other things make the B200 win:

The 5090 spends a lot of silicon on graphics it'll never use for AI. RT cores, ROPs, texture units, display engines, video encoders: all great for gaming, all dead weight for serving language models. The B200 throws all of it out and uses that silicon for more tensor cores and HBM controllers.

The B200 is two chips bonded together. What presents as one B200 is actually two reticle-limit dies connected by a 10 TB/s on-package link. Nvidia just doesn't market the CUDA core count as aggressively because the marketing emphasis is petaFLOPS.

The clock speeds differ wildly. The 5090 boosts to 2.4 GHz. The B200 runs around 1.0-1.1 GHz. Datacenter chips prioritize throughput-per-watt over peak clocks because they're running 24/7 in dense racks.

The lesson: never trust "core count" as a comparison metric across chip families. It's apples to space stations.

Native vs VNNI vs Tensor: three ways to do math

These three terms get thrown around a lot, especially in spec sheets. They're three different hardware approaches to executing arithmetic, and the differences really matter.

less flexible, far more throughput

less flexible, far more throughput

Native scalar unit
1 operation per clock
Runs literally anything

VNNI on the CPU
1 small dot product per clock
Roughly 16-64x faster than scalar
Integers and fixed layouts only

Tensor core on the GPU
1 full matrix multiply per clock
Hundreds to thousands of multiply-adds
Matrix multiply and nothing else

Native (scalar)

This is what general-purpose ALUs do. One operation at a time, perfectly flexible, handles any data type and any branching logic. If you write result = a * b + c in any programming language, that's a native scalar operation.

The advantage is flexibility. Native scalar units can do anything: conditionals, function calls, pointer chasing, recursion. The disadvantage is throughput. One operation per clock per unit means scalar code doesn't scale to thousands of cores.

You'll find native scalar units on every CPU and GPU ever made.

VNNI (Vector Neural Network Instructions)

VNNI is a CPU's clever trick for doing neural network math fast without a tensor core. Intel introduced it; AMD adopted it. The idea is to add specific instructions that do an entire small dot product, multiply 16 pairs of 8-bit integers and sum them, in one clock cycle.

This gives the CPU a ~16x to 64x speedup over scalar code for the specific pattern of "multiply many small numbers, add them up." That's exactly what neural networks need.

The catch: VNNI only works for specific operations on specific data layouts, and primarily on integer types. You can't use it to compute a square root or run a conditional. It's a focused accelerator for one use case.

Found on: modern Intel Xeon CPUs, AMD EPYC and Ryzen CPUs with AVX-512 support.

Tensor cores

These are a completely separate hardware unit on Nvidia GPUs since the Volta generation (2017). They don't share execution resources with the regular CUDA cores. A tensor core does an entire matrix multiplication per clock, hundreds to thousands of multiply-adds in one instruction.

The constraint is even tighter than VNNI: tensor cores only do matrix multiply-accumulate. They can't add. They can't subtract. They can't take a square root. They are specialists in the most extreme sense, and that specialization is what lets Nvidia put petaFLOPS of throughput on a single chip.

The ratio on a B200 tells the story: 80 TFLOPS for regular FP32 work, 9,000 TFLOPS for FP8 matrix math on the tensor cores. Same chip, same clock, but matrix-multiply-only operations run 112 times faster than general-purpose math.

The reason chip designers keep all three unit types around is that neural networks are almost entirely matrix multiplications during training and inference, but the surrounding 5-10% of work (activations, normalization, attention softmax, embedding lookups) still needs the flexible units. You need both.

INT vs FP at the same bit width

This is another question we get a lot: if INT8 and FP8 both use 8 bits, aren't they basically the same thing?

They are not. They represent numbers in fundamentally different ways, and they're good at different jobs.

INT8: uniform spacing, narrow range

An 8-bit integer is exactly what it sounds like: 1 sign bit and 7 value bits, representing whole numbers from -128 to +127. Every value is exactly 1 unit apart. There are 256 possible values, perfectly evenly spaced.

The advantage: you can represent integers in this range with perfect precision. The disadvantage: you can't represent anything outside that range, and you can't represent fractions like 0.5 or 1.7.

FP8: non-uniform spacing, wide range

An 8-bit floating-point number splits its 8 bits differently. The most common format (E4M3) uses 1 sign bit, 4 exponent bits, and 3 mantissa bits. Instead of a uniform number line, you get a logarithmic one. Values are densely packed near zero and spread further apart as numbers get bigger.

So FP8 can represent values from about -448 to +448, but the precision varies dramatically. Near zero, you can distinguish 0.001 from 0.002. Near 100, the nearest representable values might be 96 and 112, with a gap of 16 between them.

Why this matters for neural networks

INT8 is great for inference. Once you have a trained model, you can analyze it to figure out the range each layer's outputs fall into. Then you scale those outputs to fit INT8's range. This is called quantization, and it requires a calibration step. The model already exists, and you're squeezing it into a more efficient representation.

FP8 is needed for training. When training a neural network, gradients can be tiny in one layer (0.000001) and large in another (50.0), sometimes within the same step. INT8 can't represent both. You'd have to choose precision near zero or precision far from zero, but not both. FP8's exponent bits naturally handle this huge dynamic range.

Nvidia's "Transformer Engine" inside Blackwell tensor cores actually uses two FP8 formats and switches between them automatically:

  • E4M3 (4 exponent, 3 mantissa): more precision, narrower range (±448). Used for weights and forward-pass activations.
  • E5M2 (5 exponent, 2 mantissa): less precision, wider range (±57,344). Used for gradients during backpropagation.

This dual-format trick is what makes FP8 training actually work in practice.

What about FP4?

FP4 uses 1 sign bit, 2 exponent bits, and 1 mantissa bit. That's only about 16 distinct representable values. It sounds impossibly coarse, but it works for trained model weights because most weights cluster near small values, and neural networks have enough redundancy to absorb the noise.

FP4 is essentially inference-only: you can't train in it. But for serving large language models, it's transformative. A model that needs 140 GB at FP16 fits in 35 GB at FP4. That's why chips like the B300, with native FP4 hardware, can serve enormous models on a single GPU that would have required eight GPUs a generation ago.

INT4 exists too, but it's much rarer in practice because the dynamic range problem gets even worse at 4 bits. INT4 can only hold values from -8 to +7, which is nearly useless for most neural network layers without aggressive per-tensor scaling tricks.

When to actually pick each chip

Now for the practical part. Which one do you actually want?

No. Branchy, sequential,
lots of decisions

Yes. Massively parallel

Workstation, dev box,
games, small services

Databases, virtualization, big RAM,
FP64 and HPC work

On a budget, FP32 work,
smaller models

Best you can run locally,
quantized 30B+ models

Inference or training
at hyperscale

Does the same math run on a
huge data set all at once?

How heavy, and how much memory?

At what scale?

Consumer desktop CPU

Server CPU

Last-gen consumer GPU

Current consumer GPU

Datacenter AI accelerator

Pick a Ryzen 9950X (or similar consumer CPU) when

You're building a workstation for general-purpose computing: development, compilation, gaming, light video editing, running small databases, hosting services that don't need extreme parallelism. The 9950X is fast, flexible, and doesn't break the bank. It also handily beats the RTX 3090 at FP64 work if you're doing engineering simulations that need double precision.

Pick an EPYC 9965 (or similar server CPU) when

You're running a database, a virtualization host, a CDN edge node, a big in-memory analytics workload, or anything else where you need lots of cores doing complex, branching work with massive amounts of memory. The 12-channel DDR5 setup gives you 6 TB of RAM addressability and ~576 GB/s of bandwidth, which is enough to make many workloads CPU-friendly that would otherwise need GPUs.

EPYC also wins for high-throughput web serving, video transcoding farms, code compilation servers, and FP64-heavy HPC work where you'd otherwise need expensive datacenter GPUs.

Pick an RTX 3090 (or similar older consumer GPU) when

You're on a budget and need GPU acceleration for development work, model fine-tuning on smaller models, video rendering, or scientific computing that uses FP32. The 3090 still has 24 GB of VRAM and is a great workhorse for many AI inference tasks at the consumer level.

Pick an RTX 5090 when

You need the best consumer-grade GPU money can buy. With 32 GB of GDDR7 and native FP4/FP8 tensor cores, the 5090 can serve quantized 30B+ parameter models locally, do serious AI-assisted creative work, and tackle real-time path tracing. For prosumer AI use cases, it's the sweet spot. It's not a datacenter card, but it's roughly 30% of an H100 for about 5% of the cost.

Pick a B200 when

You're running serious inference at scale or training models in the 70B-200B parameter range. A single B200 holds Llama 3.1 70B in FP16 with room for KV cache. Eight of them in an HGX baseboard can train multi-hundred-billion-parameter models. The economics only make sense at hyperscale, but at that scale the B200 is roughly 4x faster than the H100 it replaced.

Pick a B300 (Blackwell Ultra) when

You're serving reasoning models at scale or training frontier models. The B300 is specifically tuned for inference on models that do long chain-of-thought reasoning (think OpenAI's o1, DeepSeek R1, or Claude with extended thinking). With 288 GB of HBM3e per chip and 15 PFLOPS of dense FP4, a single B300 holds models that needed sharding across multiple B200s. The GB300 NVL72 rack, with 72 of these chips liquid-cooled together, delivers 1.1 exaflops in a single rack, roughly equivalent to the entire Frontier supercomputer.

The catch is infrastructure: each B300 draws 1,400W, and a full rack needs about 120 kW of power and dedicated liquid cooling. Not every datacenter can host these.

Three principles to remember

If we had to summarize everything we've covered into three takeaways, they'd be these:

Latency versus throughput. CPUs optimize for "finish this one thing as fast as possible." GPUs optimize for "finish a million things in a reasonable time." A single divide is faster on a CPU. A million divides are faster on a GPU. Pick the one whose shape matches your workload.

Memory bandwidth is destiny. Most real-world workloads are bottlenecked by how fast data can get to the compute units, not by the compute itself. The B300's 8 TB/s of HBM3e is what makes its 27 PFLOPS of FP4 actually usable. Without that bandwidth, the tensor cores would starve. When comparing chips, always look at memory bandwidth alongside compute throughput.

Specialization wins at scale. Modern AI chips dedicate huge fractions of their silicon to specific math patterns (matrix multiply, low-precision arithmetic) because that specialization unlocks order-of-magnitude speedups. The flip side is that general-purpose hardware is becoming relatively less competitive for narrow workloads. If you're running one specific workload at scale, custom or specialized hardware pays off enormously.

Where this lands for game hosting

If you host game servers, the half of this article that matters most is the CPU half, and one idea from it in particular: latency beats throughput when the work is sequential.

A game server's main loop is about as sequential as software gets. It runs one tick after another, on a single core, and every connected player is waiting on it to finish. The GPU philosophy of "throw thousands of cores at it" simply does not apply, because there is only one tick loop and it cannot be split across idle cores. The thing that buys you a smoother server is a faster individual core, not more of them.

That is why AndroHost runs its paid game nodes on current-generation, high-clock cores rather than dense, many-core silicon built for parallel throughput. It is the same reasoning the chip designers use, just pointed at a different workload. If you want the long version, CPU cores vs clock speed for game servers walks through exactly why the boring number, single-thread speed, is the one that decides whether your server feels smooth under load.

Curious which plan fits your game and your player count? Get in touch. We genuinely enjoy this stuff and we're always happy to dig into the specifics with you.


This guide reflects publicly available specifications as of May 2026. Peak TFLOPS figures are theoretical maximums from manufacturer datasheets; real-world performance depends heavily on workload, software, and system configuration.


Hosting your game server with AndroHost means we handle most of what's in this post for you automatically: tier sizing, SRV records, off-site backups, DDoS protection.

Browse plans·More posts·Discord