How CPUs and GPUs work together
One AI calculation. Both paths side by side. The same answer.
The simulator could not load. Keep assets/compute-model.js and assets/compute-guide.js alongside this page. The explanation below remains readable.
| Path | State | Cells | Readable | Units |
|---|---|---|---|---|
| CPU | Not started | 0 / 4 | Not yet | 0 |
| GPU | Not started | 0 / 4 | Not yet | 0 |
1 · Prepare the work
The CPU prepares inputs and weights for either path. Choose one shared batch and inspect a multiply-add.
An AI layer multiplies input values by learned weights. Each output cell adds four products. The CPU runs the application that prepares this work—even when arithmetic runs on a GPU. Both alternative paths use the same inputs and weights and produce the same integer answer.
2 · Make the data accessible
CPU work uses system memory. This discrete GPU needs inputs and any missing weights in device memory.
The CPU can use the prepared data in system memory and caches. Our discrete-GPU example has separate device memory: inputs and missing weights must be copied before its calculation runs. Already-resident weights can be reused. Integrated GPUs and coherent or unified memory can change these transfers.
3 · Submit the calculation
Start CPU work or submit a GPU command. Neither path has returned a finished result yet.
The CPU caller starts its work. For GPU execution, CPU code submits a command through a runtime and driver. Returning from submission does not mean the GPU result is ready. The OS manages scheduling and access; arithmetic does not enter the kernel instruction by instruction.
OS, containers & VMs: where they fit
- CPU threads ← OS scheduling
- GPU commands ← runtime + driver
Both examples assume hardware access is configured. An ordinary container shares its hosting kernel and needs permitted device access. A VM has a guest kernel and scheduled vCPUs; GPU work needs an arrangement such as passthrough or a shared vGPU.
This is explanatory only: it never resets or blocks the event sequence. These are access relationships, not a pipeline for every instruction. Explore processes, containers & VMs →
4 · Execute in parallel
CPU cores favor flexible, low-latency work; GPUs favor throughput across many grouped lanes. Compare both buffers as their illustrative waves finish.
CPUs combine sophisticated cores, vector instructions, and multiple threads. GPUs organize many execution lanes into groups for suitable parallel work. The two CPU and eight GPU lanes shown here are teaching choices, not physical core counts. Lanes cooperate on tiles and instructions; there is not one GPU core per neuron.
5 · Finish & use result
Watch CPU return and GPU synchronization/copy. When both results are caller-readable, reveal the application outcome and work-cost comparison.
Calculated values are not necessarily ready for the caller. CPU work must return; this discrete-GPU path synchronizes and copies output to system memory. Once both callers can read their equal matrices, the activations can feed the next AI layer. Submission, device completion, and caller-readable output are different milestones. The final cost comparison includes preparation and transfers, not just arithmetic; neither processor is always faster.
Prepare both paths.
Inspect the selected cell’s calculation
Inspect shared inputs & weights
Configured-value previews—not proof of preparation or transfer. Each path’s memory cards show its current state.
Same answer · next layer ready
From this layer to a full model
This is a tiny projection with an optional toy conditional, not a complete language model. Actual floating-point CPU/GPU implementations may differ slightly in rounding; the integer example is exact.
Illustrative work costs
Cost breakdown & limits
Chosen units expose setup/transfer overhead and parallel work. They are not cycles, milliseconds, benchmarks, or a CPU/GPU speed ratio.
Each event advances one unfinished step on each alternative path. A finished step holds while the other path continues. These are narrative checkpoints—not simultaneous hardware time. No real hardware is used.
Model assumptions & what this leaves out
This local model uses a 1- or 8-row input with four features and a 4 × 4 weight matrix. The optional conditional adds 1 to nonnegative dot products or subtracts 1 from negative ones. It is not ReLU or an implementation recommendation.
The comparison aligns narrative steps within each stage, not physical time. Two illustrative CPU output lanes and eight GPU lanes in groups of four process the same work. If one path has fewer steps, its snapshot and charged work stay fixed while the other continues. This does not introduce a real cross-device synchronization barrier or suggest both alternatives are executed together.
Real CPUs use caches, SIMD, out-of-order execution, and multiple threads. GPUs have compute units, registers, caches, grouped execution, and sometimes specialized matrix hardware. The drawn lanes, wave sizes, and synthetic cost units are not hardware specifications or performance measurements.
Preparation, transfers, submission, arithmetic, and completion have chosen integer costs. Resident weights describe an earlier request’s state. Hardware access is assumed configured; the OS/container/VM explanation does not gate the main journey.
This is one discrete-GPU workflow whose caller needs output in system memory. Integrated GPUs, unified memory, direct device consumers, transfer overlap, streams, and coherent architectures can change or avoid these copies and waits. Synchronization is not universally a host copy.