Skip to main content
We begin with a puzzle. A model is just a big file, and running it is just loading that file into memory and doing lots of math. So why can’t the perfectly good computer in front of you run one?
To answer that, we need to look inside your computer. Think about any computer you use — laptop or data-center server. Inside there are two parts we care about most:
  • The CPU (processor): the part that does the thinking — the calculations, logic, and orchestration.
  • The RAM (system memory): where the computer keeps the data the CPU is currently working on.
Because data is needed later, these two parts usually sit separately. Take the smallest calculation there is: 6 times 7. Those two numbers land in memory first. The CPU reads them out, does the multiplication, and writes 42 back. Every calculation is the same round trip: compute ↔ memory.
A diagram titled "Compute and Memory" showing a CPU icon on the left and a RAM module on the right. Bidirectional arrows indicate data flow between them, and the RAM block displays the value "42."
Processor here. Memory there. A road running between them. Hold that picture. The CPU is a brilliant generalist: a handful of very powerful cores that work through complicated tasks, one after another, very fast. For almost everything a general-purpose computer does, that’s exactly what you want. What does a model actually do under the hood? At its core, running a model is billions of very simple multiplications. Crucially, most of those multiplications are independent — they could happen at the same time. Hand those operations to a CPU and its few powerful cores must work through those billions of little multiplications mostly in sequence, a few at a time. It gets every one right, but you’ll be waiting a very, very long time. This is the first problem: the work is massively parallel, but the CPU is built for sequences.
A presentation slide titled "The First Problem" with a left-side section labeled "The Work" and a "Massively parallel" badge above a 4x4 grid of pink rounded squares each marked with an X. The slide has a dark teal background and a small "© KodeKloud" credit in the bottom-left.
We need a different kind of processor. Enter the GPU. A GPU is built the opposite way to a CPU: instead of a handful of powerful cores, it has thousands of small, simple cores designed to do the same operation across many data items at once. A modest data-center GPU like the NVIDIA T4 has roughly 2,500 of these small cores. Where a CPU might manage up to billions or a few trillion operations per second on some workloads, a GPU can perform many trillions of operations per second — often one to two orders of magnitude more math throughput for highly parallel workloads. The mountain of multiplications that crawled on the CPU now gets done in a flash. So the GPU solves our compute problem, but it creates a new one. A processor needs memory to feed it. Now we’ve got thousands of hungry cores, and every one of them needs the model’s weights — all those billions of numbers delivered constantly:
Where do the weights live? Leave them in system RAM and we’ve got a bandwidth problem. System RAM is outside the GPU; the GPU must fetch data from it over interconnects (PCIe or NVLink). Typical CPU–GPU interconnects provide bandwidth in the tens of gigabytes per second, much lower than the GPU’s on-board memory bandwidth which is in the hundreds of gigabytes per second. For thousands of cores all demanding data at once, that off-board memory often can’t deliver fast enough — the cores sit idle, waiting for numbers that arrive too slowly, and all that parallel power is starved.
An infographic titled "Where Do the Weights Live?" showing a GPU (grid of small squares) on the left connected to System RAM on the right by a 64 GB/s link. Labels note this is a problem because system RAM "sits off the card" and is "50x slower than the cores can eat."
How do we feed thousands of cores fast enough? The answer is to give the GPU its own memory, built onto the same card right next to its cores. This is VRAM.
A stylized diagram of a GPU and its VRAM, showing a rectangular chip filled with a grid of bright blue square memory blocks and labeled "VRAM" at the top and "GPU" at the bottom.
Now the model’s weights can live right beside the math, and the cores can be fed over a much wider pipe. VRAM bandwidth is measured in hundreds of gigabytes to terabytes per second depending on the card — orders of magnitude more than system RAM bandwidth.
A presentation slide titled "A Wider Pipe" showing two horizontal bars — a thin blue line and a much wider rounded teal bar labeled "VRAM" — on a dark background. There's a small "© Copyright KodeKloud" note in the bottom left.
But VRAM has a trade-off: it’s fast but limited in capacity. A card like the T4 has 16 GB of VRAM. For example, a large, 70 billion parameter model can need roughly 140 GB just to hold its weights in memory (assuming about 2 bytes per parameter). That’s far larger than what’s available on a single 16 GB card.
Space in VRAM is precious. Remember this because it becomes a big deal later. Put these observations together and you get three numbers that size every AI workload: Every accelerator is described by those three numbers. The card you pick decides which models fit and how fast they will run. Bandwidth in particular is important: when we later watch a model actually generate text, that reading speed will determine a lot of the runtime behavior.
Three things to remember about any GPU for models: compute, bandwidth, and capacity. A fast GPU with too little VRAM still can’t hold a large model; plenty of VRAM with low bandwidth still starves the cores.
So let’s take stock. We’ve got a GPU with thousands of cores and its own memory sitting right beside them. The hardware looks ready — at least it looks ready — because as we’ll see, there are more complications that affect how models actually run efficiently.
The image shows a stylized GPU diagram under the heading "Is the Hardware Ready?". A grid of green squares represents many active cores beside a blue module with a green check mark.
Further reading and references

Watch Video