GO TO A SECTION

↑ ↓ to navigate · Enter to openExplore all sections →
FDEInterviews logo
ACL 2024

LLM in a flash: Efficient Large Language Model Inference with Limited Memory

Apple ran 7B models on devices with half the memory they need by keeping weights in flash and loading only the neurons each token will use. OPT-6.7B went from 3.2 s to 0.67 s per token on CPU.

Breakdown by FDE Interviews · 10 min read · Updated

About the original · 2023
AUTHORS
Alizadeh, Mirzadeh, Belenko, Khatamifard, Cho, Del Mundo, Rastegari, Farajtabar
FROM
Apple
PUBLISHED
Dec 2023 · ACL 2024
CITED BY
356Semantic Scholar · Nov 2026
IN THIS BREAKDOWN · 10 SECTIONS

You can read 21% of this breakdown.

01

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.

THE IDEA, VISUALLY
WHERE THE WEIGHTS LIVE (SECTIONS 2-3) DRAM (half the model) attention + embeddings low-rank predictors FFN neurons used in the last k tokens window of recent neurons flash (full model) each neuron stored as [up column | down row] one read fetches both halves per token: predict active FFN neurons (~3% for OPT 6.7B), read only those not already in the window, compute, evict neurons that left the window requires ReLU-style sparse activations (Falcon and Llama 2 used in converted, sparsified form) FLASH READS PER TOKEN, OPT 6.7B (TABLE 2) GB I/O ms naive 13.4 2,196 keep half in DRAM 6.7 1,090 + predictor 0.9 738 + window 0.2 164 + bundling 0.2 87 bundling raises scattered reads from 1.25 to 2.25 GB/s LATENCY PER TOKEN, NAIVE VS ALL (TABLE 3) M1 Max CPU 3,182 ms 669 ms Metal M2 2,270 ms 305 ms RTX 4090 2,218 ms 84 ms 4.8x on CPU, 26x on GPU (37x with speculative decoding); single-sequence generation only arXiv 2312.11514, Apple, ACL 2024
When a model does not fit in DRAM, the naive approach reads it from flash for every token. LLM in a flash keeps attention and recently used feed-forward neurons in DRAM, predicts which neurons the next token will fire, reads only the new ones, and stores each neuron's up and down projection weights side by side so reads are larger.
Research notes: the problem, approach and results
13.4 → 0.2 GB

data read from flash per token for OPT-6.7B with prediction, windowing and bundling (Table 2)

4.8x / 26x

lower per-token latency than naive loading for OPT-6.7B on CPU and GPU (Table 3)

97%

of FFN activations that are zero in OPT-6.7B, the sparsity the method relies on (Section 3.1)

THE PROBLEM

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.

THE IDEA

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.

THE RESULT

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.

02

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.

THE FULL BREAKDOWN

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

Get Premium · ₹2,000 / $25
  • ◇1 architecture diagram
  • </>1 runnable code experiment
  • ▦2 results tables
  • ?5 interview questions with answers
  1. 03Key takeaways

    The flash constraints, the three techniques, the latency budget, results and two misreadings

    Free account
  2. 04How it works

    The flash read model, the predictor, window management in DRAM, bundling and the latency accounting

    Premium
  3. 05The numbers that matter

    The I/O ablation, end-to-end latency by model and backend, and the speculative-decoding result

    Premium
  4. 06Try it yourself

    Recompute the I/O and latency tables, and simulate how window size trades DRAM for flash reads

    Premium
  5. 07Where it breaks

    Dense activations, batch size one, prompt processing, and device dependence

    Premium
  6. 08Using it on a deployment

    When flash offloading fits, what to check about the model, and how to size the window

    Premium
  7. 09Interview angles

    Five questions this paper prepares you for, with answer hints

    Premium
Back to the paper library →