Frontier

Apple silicon and unified memory

Unified memory removes the PCIe capacity boundary; dividing 800 GB/s by the pinned 17.1 GB artifact gives a roughly 47 tok/s artifact-size heuristic, not a hard decode bound.

Updated

01 · Concept

Concept

Lesson 7.12 left a loose end. It sized a 4-bit Qwen3.8-27B build at roughly 17.1 GB and observed that unified-memory machines “punch above their apparent class” — but did not say why, or how far. That is this lesson, and the answer splits cleanly into two questions that beginners routinely fuse into one: can the model load, and how fast will it run.

The loading question is architectural. On a conventional workstation the model file is read into host RAM, then copied across a PCIe boundary into the discrete GPU’s own VRAM, and it is that VRAM — not the machine’s memory — that must hold the resident weights. A machine with 128 GB of RAM and a 24 GB card is, for this purpose, a 24 GB machine. Apple silicon removes the boundary: the CPU, the GPU and the neural engine address one physical pool, and a tensor produced by one is visible to the others without a copy. Apple documents this as the unified memory architecture underlying Metal, and MLX is built directly on the property — arrays live in shared memory, and an operation is dispatched to a device rather than a buffer being shipped to one. So a 17.1 GB artifact on a machine with 64 GB of unified memory is simply resident. Nothing is staged, nothing is duplicated, and the KV cache from lesson 7.2 draws on the same pool rather than competing for a smaller private one.

The speed question is the roofline of lesson 9.1, unchanged. Batch-one decode is memory-bound: producing one token streams the active language-model tensors, so a hard roofline is bandwidth divided by actual active bytes per token. Apple reports a memory bandwidth of roughly 800 GB/s for its Ultra-class desktop parts. Take that vendor figure and the pinned artifact size as a planning proxy:

800 GB/s17.1 GB artifact46.8 tokens per second.\frac{800\ \text{GB/s}}{17.1\ \text{GB artifact}} \approx 46.8\ \text{tokens per second}.

About 47 tokens per second as an artifact-size heuristic. It assumes every file byte is active weight traffic and perfect bandwidth use, yet the GGUF also contains metadata and mixed tensors while cache, state, kernels, and thermals add other traffic. Because those effects move in opposite directions, this quotient is not a hard upper bound; profile active bytes and measured throughput.

Here is the classic wrong turn, and it is a purchase-sized mistake. A buyer reads that an Ultra-class machine can be configured with 192 GB of unified memory, notes that lesson 7.12 put bf16 weights at 54 GB, and concludes: excellent, I will skip quantization entirely and run the model at full precision on my desk. The capacity claim is correct — 54 GB fits in 192 GB with room for a long context. The speed conclusion does not follow, but the checkpoint-size quotient is only a planning comparison:

800 GB/s54 GB per token14.8 tokens per second.\frac{800\ \text{GB/s}}{54\ \text{GB per token}} \approx 14.8\ \text{tokens per second}.

About 14.8 tok/s as a checkpoint-size heuristic. Capacity bought the ability to load bf16; it did not establish speed. Quantization can reduce active bytes, but the gain depends on the actual runtime representation rather than scaling mechanically with file size.

Two second-order effects deserve naming. First, the cache is not free of the same pool: at lesson 7.2’s 64 KiB per token, a 32,768-token conversation adds 2 GiB of resident KV state, and every byte of it is also read during decode, so long contexts erode the ceiling as well as the capacity. Second, the roughly 144 MiB of reference float32 Gated DeltaNet recurrent state is constant in sequence length, which makes the hybrid architecture unusually well-suited to a fixed-size memory budget — the cache still grows linearly with context — 8,000 tokens to 32,000 still quadruples it — but it grows from a base four times smaller than a same-size pure-attention model’s, because only 16 of the 64 layers cache at all, and the recurrent state beside it never grows.

The durable point is that Apple silicon did not repeal the bandwidth wall of lesson 9.1; it removed a different wall. The PCIe staging boundary that makes discrete-GPU capacity a hard cliff is gone, so the question “does it fit” gets a generous answer on consumer hardware. The question “how fast” is answered by exactly the same division as every other chip in this track, and lesson 9.10 will turn both answers into a monthly bill.

02 · Analogy

Analogy

A restaurant with a separate storeroom sends a runner to fetch every crate, and the corridor between storeroom and kitchen sets the pace no matter how fast the chefs work. A restaurant built with the pantry inside the kitchen has no corridor at all — the cooks simply reach. Unified memory is the second building: the model's weights are not copied to the accelerator, they are already where the accelerator reads. But the pantry still has shelves of finite depth, and each cook can still only carry so much per trip, which is why capacity and reach speed remain two separate questions.

03 · Teach it back

Teach it back

Explain what unified memory removes, then use the pinned artifact size and vendor bandwidth to compute a planning heuristic for single-stream decode, and explain why exact active bytes are still required for a hard roofline.

Minimum: 80 characters and 15 words. Your writing stays only in this browser.

Waiting for your explanation.

Compare with a model answer

On a discrete GPU, usable accelerator capacity is device VRAM behind PCIe; Apple silicon exposes one physical pool to CPU and GPU. The pinned Q4_K_M text artifact is 17.1 GB (15.93 GiB), so it can reside in a 64 GB unified pool. Dividing an Ultra-class vendor figure of 800 GB/s by 17.1 GB gives about 46.8 tok/s, but this is only an artifact-size heuristic: the file includes metadata and tensors not necessarily read every text-decode step, while cache, state, kernels, thermal behaviour, and unattained bandwidth add cost. A hard roofline requires actual active bytes per token.

04 · Check your understanding

Check your understanding

01Applying lesson 9.1's roofline reasoning, what does a large unified-memory capacity by itself guarantee about generation speed?
Answer and explanation

Nothing — capacity decides whether the model loads, bandwidth divided by bytes-read-per-token decides the speed ceiling — Lesson 9.1 separated the two axes: bytes moved per token divided into bandwidth gives the batch-1 ceiling, and installed capacity appears nowhere in that quotient.

02Why can a 64 GB Apple silicon machine hold a model that a 24 GB discrete GPU cannot, even when both machines have 64 GB of RAM installed?
Answer and explanation

The GPU's usable pool is its own VRAM behind a PCIe boundary; on unified memory the GPU addresses the same physical pool as the CPU — The constraint on the discrete card is not the machine's RAM but the memory attached to the accelerator; unified memory deletes that distinction, which is the whole architectural point of this lesson.

Complete the teach-back and answer the quiz correctly to finish this lesson.

◎ · Evidence marker

Sources

  1. Apple Inc. (2026). Metal — Apple Developer.
  2. Apple Machine Learning Research (2026). MLX Documentation.
  3. Qwen Team (2026). Qwen3.8-27B Model Card.