Apple unified memory vs GPU VRAM

What to take away

• Apple silicon's CPU and GPU share a physical memory pool, which can avoid transfers between separate CPU and GPU memory.
• Shared memory still requires correctly ordered access and suitable resource layouts; it does not remove every copy or synchronization cost.
• Capacity, bandwidth, latency, and compute throughput answer different questions. More memory does not establish faster execution.
• Compare both work that stays on the GPU and pipelines that repeatedly exchange data with the CPU.
• A Mac's unified memory is a shared system budget, so installed capacity is not the same as freely available dedicated VRAM.

Start with the memory topology

Apple silicon already includes a GPU. The useful comparison is between a GPU sharing the computer's memory and a discrete GPU with its own memory. RAM stores working data; a GPU performs parallel computation; VRAM is memory attached to a graphics processor.

On an Apple silicon Mac, the CPU and GPU access the same physical memory pool. An application can give both processors access to a resource without keeping a separate CPU copy and GPU copy. Apple's architecture explanation uses textures, images, and geometry as examples of resources that can be shared without copying across PCIe, the interface conventionally connecting a discrete graphics card to the host. Apple's architecture explanation

A conventional discrete GPU has local device memory separate from the CPU's RAM. Data can be transferred between the pools, or accessed through mechanisms supported by the platform. NVIDIA documents that performance is best when data resides in the memory of the processor using it. A computer with 64 GB of system RAM and a 32 GB graphics card therefore does not automatically behave like a GPU with 96 GB of local VRAM. CUDA memory architecture

The architectural question is where the working data resides and how often it must move. That is different from asking how many arithmetic units the GPU has or how quickly its memory interface operates.

Physical sharing, virtual addresses, and synchronization

Three concepts need separate definitions. Physical memory topology describes where data is stored. Virtual addressing describes how processors name memory locations. Coherence and synchronization govern how memory updates become visible and how dependent operations are ordered.

Sharing a physical memory pool does not mean sharing one undifferentiated cache. A cache is smaller, faster storage holding recently used data. Nor does sharing establish identical CPU and GPU access latency or throughput. An article diagram can show both processors reaching the same pool without pretending to specify every cache or connection inside a particular chip.

Programs still need to coordinate access. The CPU must not overwrite an input while a GPU operation still needs it, or consume a result before the GPU finishes producing it. Apple's Metal compute discussion describes shared resources and synchronization as central to using unified memory. Metal provides barriers, fences, and events for resource dependencies at the appropriate scope. Sharing the allocation removes a particular transfer requirement; it does not make arbitrary simultaneous reads and writes safe. Apple's Metal compute discussion, Metal resource synchronization

NVIDIA's term CUDA Unified Memory needs another distinction. On conventional discrete-GPU systems, this facility can manage migration between physically separate CPU and GPU memory. Its behavior depends on the hardware and operating system. A unified address space does not establish a single physical pool or uniform access performance. NVIDIA also documents hardware-coherent systems such as Grace Hopper and Grace Blackwell. CUDA Unified Memory paradigms

Physical sharing is not exclusive to Apple. NVIDIA's DGX Spark integrates a CPU and GPU sharing 128 GB of LPDDR5x memory. The comparison in this article concerns shared versus dedicated memory designs, rather than an architectural rule separating all Apple and NVIDIA products. DGX Spark system overview

Why unified memory can still involve copies

The memory pool and a resource's access permissions are separate concepts. In Metal, a resource using shared storage is accessible to CPU and GPU, while private storage permits GPU access and offers optimization opportunities. A private resource on a unified-memory device does not imply a separate bank of dedicated VRAM. Metal resource fundamentals

A GPU-oriented resource layout can still be worthwhile. Apple's GPU-counter tutorial gives an example in which changing a texture to private storage enables compression that reduces memory-bandwidth demand. Preparing that resource can involve a copy even though the underlying system uses shared physical memory. The relevant question is whether the preparation cost is repaid by subsequent use. Apple's GPU-counter example

MLX, Apple's machine-learning array framework, offers a concrete shared-memory example: CPU and GPU operations can use the same arrays without relocating them between separate memory pools. That illustrates a capability of the hardware and framework, rather than a guarantee that every application avoids copies, conversion, or temporary allocations. MLX unified-memory documentation

Four quantities that should not be confused

Arithmetic intensity connects memory traffic with compute: it is the amount of work performed per byte transferred at the memory level being examined. NVIDIA's profiler documents the roofline model, which combines arithmetic intensity with bandwidth and compute limits. A simplified performance ceiling is the smaller of the compute ceiling and bandwidth multiplied by arithmetic intensity. This is a ceiling, not a prediction of achieved speed. Nsight Compute profiling guide

Consider an invented processor with 20 trillion floating-point operations per second of compute capacity, or 20 TFLOP/s, and 500 billion bytes per second of memory bandwidth. An operation doing two floating-point operations per byte transferred has a bandwidth ceiling of 1 TFLOP/s. At 100 operations per byte, the memory term reaches 50 TFLOP/s, so the 20 TFLOP/s compute ceiling is lower.

These are explanatory calculations, not specifications or benchmarks for an Apple or NVIDIA product. They show why a streaming operation and a matrix multiplication with substantial data reuse can respond differently to the same memory system. Cache-resident work also needs analysis at the relevant cache level. Instruction mix, dependencies, scheduling, and resource usage can impose further limits.

What current specifications illustrate

The following vendor specifications were checked on September 26, 2026. The examples span different product classes and are not price-matched systems or measured application results.

Sources: Mac Studio specifications, Apple's M5 Ultra announcement, RTX 5090 specifications, NVIDIA RTX Blackwell memory-bandwidth specification, H200 specifications, DGX Spark hardware guide.

Configuration matters. The 32-core M5 Max is specified at 460 GB/s; 614 GB/s applies to the 40-core version. Apple lists the 512 GB M5 Ultra option with the 36-core CPU and 80-core GPU. Peak bandwidth does not establish achieved bandwidth, and Apple's shared-system figure should not be assigned independently in full to both CPU and GPU during concurrent work. Mac Studio configuration details

The table illustrates why capacity and bandwidth need separate treatment. A shared system can offer a larger pool than a consumer graphics card while a dedicated accelerator offers higher local bandwidth. Neither observation establishes a universal application winner.

Transfers matter when they delay the application

A pipeline that repeatedly passes data between CPU and GPU may benefit from shared resources. A pipeline that uploads data once and performs many GPU operations can amortize its initial transfer. Discrete-GPU software can also overlap transfers with computation when its dependencies and hardware allow it. Inspect the timeline instead of adding nominal transfer times to the kernel runtime indiscriminately. CUDA transfer and overlap guidance

A calculated example makes the limit clear. If avoidable copies account for 20% of an application's measured runtime, removing them completely while leaving everything else unchanged gives a maximum speedup of 1 / (1 - 0.20), or 1.25 times. This is an illustrative upper bound, not a forecast for unified memory. Eliminating a transfer does not eliminate reading the input, writing the output, or doing the computation.

Sharing also creates a contention question: CPU, GPU, and other clients use a common memory system. Repeat memory-heavy GPU work with and without simultaneous CPU memory traffic to investigate the effect. Do not assume that two processors can each sustain the entire advertised shared bandwidth. The amount of contention is a measurement question, not a fixed penalty asserted here.

Tile memory is another part of the hierarchy

Apple's GPUs use tile-based deferred rendering. They process regions of a render target using fast, temporary tile memory on the GPU, reducing some traffic to device memory. This storage is different from the large unified DRAM pool. Apple's tile-based rendering documentation

This is an example of improving performance by reducing bytes transferred rather than only increasing the DRAM interface's peak bandwidth. The benefit depends on the rendering algorithm and its use of the GPU's features. It cannot be translated into a universal speedup for machine learning, scientific compute, or every game.

An AI example: capacity changes what can remain resident

For a hypothetical dense model with exactly 70 billion parameters, ideally packed four-bit weights require 35 billion bytes: 70 billion × 4 / 8. That is 35 GB, or about 32.60 GiB. GB means one billion bytes; GiB means 2 to the power of 30 bytes.

This weights-only calculation already exceeds a 32 GiB local budget. A larger shared pool can remove that particular obstacle. Actual quantized checkpoints also need metadata and may retain some tensors at higher precision; quantization can affect output quality. Hugging Face quantization concepts

The working set includes more than weights. Language-model inference also uses an attention key/value cache for earlier tokens and temporary runtime allocations. Longer context can make the cache substantial. Cache offloading and cache quantization have their own performance tradeoffs. Hugging Face cache strategies

On a Mac, the operating system, applications, CPU allocations, and GPU work share the physical budget. PyTorch's MPS allocation controls use Metal's recommended maximum working-set size, rather than promising that every installed byte is freely available to the GPU. Avoid applying one universal usable-memory percentage to every Mac. PyTorch MPS allocation guidance

A 2025 preprint comparing M2 Max, M2 Ultra, and M4 Pro with single and dual RTX A6000 setups illustrates workload-dependent tradeoffs. Its tested fit-in-memory cases favor NVIDIA on latency, while larger Apple pools permit larger models. It also finds that fewer bits per weight do not invariably mean faster inference. Those results are limited to the tested hardware and software; they are not M5-versus-RTX-5090 measurements. Research paper and version history

For AI, separate prompt processing, called prefill, from token generation, called decode. Their data reuse and compute behavior differ. Also verify the actual execution path: PyTorch's MPS backend can be configured to fall back to CPU for unsupported operations. A nominal GPU backend does not prove every operation ran there. Stage-level research analysis, PyTorch MPS fallback documentation

Compare systems with a workload, then explain the result

Use three kinds of measurements to distinguish architectural effects:

1. CPU/GPU handoffs: time CPU preparation, GPU execution, and CPU consumption of results. Identify copies and synchronization on the critical path.
2. GPU-resident work: compare streaming/vector operations and matrix multiplication across working-set sizes and levels of data reuse. Record actual traffic and counters.
3. Concurrent activity: repeat memory-heavy GPU work while the CPU also accesses memory. Look for changes in throughput, latency, and memory pressure.

These are proposed experiments, not tests conducted for this article. Use Metal counters and timelines on Apple systems and Nsight tools on NVIDIA. Counter definitions can differ between vendors, so establish compatible meanings before comparing them. Apple GPU profiling, Nsight Compute profiling

For a complete application, pin the workload, software versions, precision, and settings. Separate cold loading from warm execution. Include peak memory, failures, and the latency distribution alongside throughput. If comparing energy, measure the complete system performing the same work; board power and wall energy are different quantities.

For language-model serving, also specify the checkpoint revision, weight and cache formats, input/output lengths, concurrency, and cache-reuse policy. Measure first-token latency separately from output speed. The companion guides explain model memory budgeting and a controlled inference benchmark.

Hold the workload constant when investigating architectural differences. If the question is the best practical deployment, allow each platform's supported optimizations while controlling quality, and label that comparison accordingly. The useful conclusion is which constraint limits the application and whether a different design removes it.

Research and calculation note

Research date: September 26, 2026. Hardware values are vendor specifications. The roofline, copy-removal, and model-weight examples are calculated illustrations. No original hardware benchmarks, energy measurements, or model-fit tests were performed for this article. Sources and configurations should be rechecked when using these figures for a later comparison.