IN THIS BREAKDOWN · 10 SECTIONS
You can read 21% of this breakdown.
The paper in one minute
A 7-billion-parameter model at 16 bits is about 14 GB of weights. Phones and many laptops cannot hold that in DRAM, but they do have far more flash storage. Reading the whole model from flash for each generated token is the naive fix, and it takes two seconds or more per token, because flash bandwidth is an order of magnitude below DRAM's and much worse still for small, scattered reads.
Apple's insight is that most of the model is not needed for any one token. In models with ReLU activations, the feed-forward layers' hidden neurons are overwhelmingly zero: about 97% for OPT-6.7B. If you knew in advance which neurons a token would activate, you would only need those neurons' weights. Feed-forward layers hold about two-thirds of a model's parameters, so that is most of the model.
The paper builds three techniques on top of that. A low-rank predictor per layer takes the attention output and guesses which feed-forward neurons will fire, with negligible effect on accuracy. A sliding window keeps in DRAM the neurons used by the last few tokens, since consecutive tokens activate overlapping sets, so each new token only loads neurons it has not needed recently. Row-column bundling stores each neuron's up-projection column next to its down-projection row in flash, so one read fetches both and reads are twice as large, which flash handles far more efficiently. Attention layers and embeddings stay in DRAM.
With DRAM for only half of OPT-6.7B, flash reads fell from 13.4 GB to about 0.2 GB per token, and latency fell from 3.2 seconds to 0.67 seconds on an M1 Max CPU and from 2.2 seconds to 84 milliseconds on a GPU.
Research notes: the problem, approach and results
data read from flash per token for OPT-6.7B with prediction, windowing and bundling (Table 2)
lower per-token latency than naive loading for OPT-6.7B on CPU and GPU (Table 3)
of FFN activations that are zero in OPT-6.7B, the sparsity the method relies on (Section 3.1)
A 7B model in 16-bit needs about 14 GB, more DRAM than most phones and many laptops have. Loading weights from flash storage for every token takes seconds, because flash is much slower than DRAM and especially slow for small scattered reads.
Exploit sparsity in feed-forward layers: with ReLU activations, over 90% of neurons output zero for a given token. Keep attention weights and a sliding window of recently active neurons in DRAM, use a small low-rank predictor to guess which neurons will fire, read only the missing ones from flash, and bundle each neuron's up- and down-projection rows so each read is twice as large.
With DRAM for half the model, OPT-6.7B's per-token latency dropped from 3,182 ms to 669 ms on CPU and from 2,218 ms to 84 ms on GPU; flash reads fell from 13.4 GB to 0.2 GB per token. The paper reports models up to twice the size of available DRAM running with little accuracy loss from the predictors.
Why it matters to an FDE
Most deployment advice assumes the model fits in memory. This paper is about what to do when it does not, and it explains how on-device assistants can run models larger than RAM.
It needs sparse activations. The method works because ReLU-family models leave most neurons at zero. Most modern models use SwiGLU or GELU, which are not sparse in this way; the paper uses ReLU-converted versions of Falcon and Llama 2. Before promising this approach, check the customer's model architecture.
It is a single-request technique. Results are for one sequence at a time on one device; the authors list batched inference and prompt processing as future work. For server deployments, quantization and more GPUs are still the answer.
Storage layout is part of the design. Flash is fastest for large contiguous reads. Bundling the weights a token needs together roughly doubled read throughput. The broader lesson for edge deployments is that how weights are laid out on disk can matter as much as how many there are.
Understand the mechanism. Try it on a real problem.
Unlock this breakdown and 290 more papers.
Premium opens every paper in full, plus every answer, concept, course and guide on the site. One payment for six months of access.
6 months · One payment · No auto-renewal
- ◇1 architecture diagram
- </>1 runnable code experiment
- ▦2 results tables
- ?5 interview questions with answers
- 03Key takeaways
The flash constraints, the three techniques, the latency budget, results and two misreadings
Free account - 04How it works
The flash read model, the predictor, window management in DRAM, bundling and the latency accounting
Premium - 05The numbers that matter
The I/O ablation, end-to-end latency by model and backend, and the speculative-decoding result
Premium - 06Try it yourself
Recompute the I/O and latency tables, and simulate how window size trades DRAM for flash reads
Premium - 07Where it breaks
Dense activations, batch size one, prompt processing, and device dependence
Premium - 08Using it on a deployment
When flash offloading fits, what to check about the model, and how to size the window
Premium - 09Interview angles
Five questions this paper prepares you for, with answer hints
Premium - 10Read next
Where to go from here on this site
Premium
