Zhu, Li, Liu, Ma & Wang (Chinese Academy of Sciences), 2024

Shrinking the Giant:
Model Compression for LLMs

GPT-175B needs 350 GB and five A100s just to answer one question. This survey maps the four families of techniques — quantization, pruning, distillation, low-rank factorization — that crush a billion-parameter model down to something you can actually deploy, and shows exactly what each one costs you.

Prerequisites: Transformers / LLM basics + Matrix multiplication
11
Chapters
8
Simulations

Chapter 0: The Problem

You have trained — or downloaded — a large language model. It is brilliant. It also will not fit on anything you own. Let's make that concrete with the survey's opening number.

GPT-175B has 175 billion parameters. Each parameter, stored in half precision (FP16), takes 2 bytes. So just holding the weights in memory costs:

175 × 109 params × 2 bytes = 350 × 109 bytes = 350 GB

An NVIDIA A100 has 80 GB of memory. 350 GB does not fit. You need at least five A100s wired together just to load the model — before you have served a single token, before you have paid for the electricity, before the KV cache for a long prompt eats even more.

The core question of this survey: Can we transform a large, resource-hungry model into a compact version — one that fits on a phone, an edge device, or a single GPU — without destroying the capability that made it worth training? And if performance must drop, how much, and which technique gives the best trade?

Why this is not free

Every byte you remove is a byte the model was using to store knowledge. The survey is honest about this: compressed LLMs "continue to exhibit a significant performance gap when compared to their uncompressed counterparts." Compression is a negotiation, not a magic shrink-ray. The whole field is the study of which bytes are safe to remove.

The three things compression buys you

WinWhat it meansWhy you care
Smaller memory footprintFewer GB to store the weights / KV cacheFits on cheaper / fewer GPUs, or on a phone
Faster inference (speedup)Each token generated in less wall-clock timeLower latency for users; higher throughput
Lower energy / cost per queryLess compute and memory traffic per tokenSustainable, affordable deployment at scale

Notice these can conflict. We will see in Chapter 3 that one popular technique shrinks memory beautifully but actually adds compute. That tension is the texture of the whole field.

The Memory Wall — Drag model size & bit-width

Drag the sliders. The orange bar is the model's memory in GB; the dashed line is one A100 (80 GB). Watch how dropping from 16 bits to 4 bits is the difference between "needs a server rack" and "fits on one card." Quantization (Chapter 2) is exactly this lever.

Why does GPT-175B need at least five A100 GPUs just to load?

Chapter 1: The Taxonomy

Faced with "make the model smaller," there are only a handful of fundamentally different things you can do to a weight matrix. The survey organizes the entire field into four families. The trick to remembering them is to ask: what am I attacking?

The mental model: A weight is a number stored in a matrix. You can (1) store each number in fewer bitsquantization. (2) Delete some numbers entirely (set to zero) → pruning. (3) Train a smaller model to imitate the big one → knowledge distillation. (4) Replace one big matrix with the product of two skinny matrices → low-rank factorization. That's the whole map.
Quantization (§3)
Fewer bits per weight/activation. FP16 → INT8 → INT4 → 2-bit. Same number of weights, lower precision.
Pruning (§4)
Set unimportant weights to zero. Unstructured (any weight), structured (whole neurons/heads), or semi-structured (N:M patterns).
Knowledge Distillation (§5)
Train a small student model to copy a large teacher's outputs or internal distribution.
Low-Rank Factorization (§6)
Approximate W ≈ U·V with U, V much skinnier. Fewer stored numbers, fewer multiplies.

One cross-cutting distinction: do you have to retrain?

This is the question that decides whether a technique is practical for a 70-billion-parameter model. The survey splits the four families along a second axis: task-agnostic (apply once, works for everything) vs task-based (needs retraining, often per-task).

TechniqueNeeds retraining?Practicality on huge LLMs
Post-Training Quantization (PTQ)No (just a calibration pass)Very high — minutes to hours, no gradients
Quantization-Aware Training (QAT)Yes (full fine-tune)Expensive — gradients over billions of params
Unstructured pruning (SparseGPT)Often no (one-shot)High
Structured pruningUsually a recovery fine-tuneMedium (LoRA recovery makes it feasible)
Knowledge distillationYes (train the student)Medium — student training cost
Low-rank factorizationSometimes a fine-tuneMedium
Why "no retraining" is the killer feature for LLMs: A single backward pass over a 175B-parameter model needs the optimizer states, activations, and gradients all in memory — often 3-4× the inference footprint. For the largest models, retraining is simply off the table for most practitioners. That is why Post-Training Quantization and one-shot pruning dominate practical LLM deployment: they touch the weights with little or no gradient descent.
Which two compression families work by changing the numbers already in the weight matrix (vs. training a new model)?

Chapter 2: Quantization — Fewer Bits Per Weight

Start with the simplest, most-used idea. Quantization reduces the number of bits used to represent each parameter. A weight stored as a 16-bit float becomes an 8-bit, 4-bit, or even 2-bit integer. The survey's one-line definition: "reducing the number of bits (i.e., precision) in the parameters of the model with minimal loss in inference performance."

The mechanics: float → integer

You can't just truncate a float. You map a range of real values onto a small set of integer levels. For symmetric INT-b quantization of a weight block with maximum absolute value max|w|:

scale = max|w| / (2b−1 − 1)     wq = round(w / scale)

Symbol by symbol, with intuition:

Why a shared scale per block, not per weight: If every weight had its own scale you'd save nothing. The win comes from sharing one tiny FP16 scale across a whole group (e.g. 128 weights), so the per-weight cost is just b bits. The price: every weight in the group is forced onto the same grid, so a single huge "outlier" weight stretches max|w| and makes the ticks coarse for everyone — the central villain of Chapter 3.

A fully worked numerical example

Quantize the weight block [0.10, −0.40, 0.95, 0.02] to INT4 (symmetric, so levels run −7…+7, i.e. 23−1=7).

max|w| = 0.95   →   scale = 0.95 / 7 = 0.1357
ww / scaleround → wqdequant wq·scaleerror
0.100.73710.1357+0.036
−0.40−2.948−3−0.4071−0.007
0.957.00070.95000.000
0.020.14700.0000−0.020

Two lessons jump out. The outlier 0.95 is preserved exactly (it defined the scale). But the small weight 0.02 got rounded to zero — it had no level to land on. INT4 gave us a 4× memory cut (16 bits → 4 bits) at the cost of erasing the smallest weights. That is the trade in miniature.

Quantization Grid — Drag bit-width, watch the rounding

Blue dots are the true weights; the horizontal grid lines are the quantization levels; orange dots show where each weight snaps after rounding. Lower the bits to watch the grid coarsen. Hit Add an outlier and see how one extreme weight stretches the grid and ruins resolution for all the small weights — the motivation for Chapter 3.

QAT vs PTQ — the retraining axis

The survey's first split inside quantization:

In the worked INT4 example, why did the weight 0.02 round to exactly zero?

Chapter 3: PTQ Variants & the Outlier Problem

Chapter 2 ended on a villain: a single outlier weight stretches the scale and crushes resolution for everyone else. In LLMs this is not rare — it is the defining challenge of low-bit quantization, and the survey organizes PTQ around three targets and the outlier fight.

Three things you can quantize

Weight-only
Quantize only the weights; keep activations in FP16. Most common. Reaches lowest bit-widths (2-3 bit) but must dequantize before each matmul, adding compute.
Weight-Activation
Quantize weights AND activations to low precision (e.g. INT8). Enables fast low-bit hardware matmuls — but activations have nasty outliers.
KV Cache
Quantize the stored keys/values of attention. The KV cache dominates memory for long contexts — quantizing it (KIVI to 2-bit) unlocks much longer sequences.
The activation-outlier discovery (LLM.int8()): Researchers found that in large transformers, a tiny number of feature dimensions carry enormous-magnitude activations — and these outlier dimensions are critical to the model. Naively quantizing them to INT8 wrecks the model. The fix that defined the field: keep the <1% outlier dimensions in high precision (FP16) and quantize everything else to INT8. "Mixed-precision decomposition." Accuracy: zero degradation at INT8.

The clever weight-only tricks

MethodKey ideaWhat it achieves
GPTQLayer-wise quantize, correcting remaining weights with inverse-Hessian info (which weights matter most)3-4 bit with minimal loss
AWQKeep the top ~1% activation-salient weights protected; per-channel scalingActivation-aware low-bit weights
SpQR / SqueezeLLMStore the few sensitive weights (by L2 / Hessian) in high precision, rest in sparse low-bitNear-lossless 3-bit, >2× speedup
QuIPIncoherence processing (random orthogonal rotations) so no weight is an outlierPushes to 2-bit

SmoothQuant: move the difficulty where it's easy

Here is the most elegant idea in the chapter. Activations have brutal outliers; weights are smooth and easy to quantize. SmoothQuant's insight: a linear layer computes Y = X W, and you can rescale by any diagonal s without changing the math:

Y = X W = (X · diag(s)−1)(diag(s) · W) = X̂ · Ŵ

Choose s to shrink the activation outliers (dividing X by s) while only mildly growing the weights (multiplying W by s). You have migrated the quantization difficulty from activations to weights — where it is much more tolerable. Same output, easier-to-quantize tensors.

SmoothQuant — Migrate outliers from activations to weights

Left column: activation channel magnitudes (note the giant outlier). Right column: weight channel magnitudes (smooth). Drag α to migrate difficulty: the activation outlier shrinks while the weights grow a little. Watch the "max range" readouts — at the right α both are comfortably quantizable, and the product X·W is unchanged.

Concept + Realization: the weight-only compute penalty

The subtlety practitioners miss: weight-only quantization reaches lower bit-widths than weight-activation, so it looks strictly better for memory. But there is a hidden cost. Because activations stay FP16, the INT4 weights must be dequantized back to FP16 before every matmul. So you save memory and memory-bandwidth (great for memory-bound LLM decoding) but you do NOT get to run the fast native INT4/INT8 hardware matmul — and you pay extra dequant ops. Weight-activation quantization is the opposite: harder to do (activation outliers) but unlocks true low-bit hardware acceleration. The survey states it plainly: weight-only "inevitably introduces additional computational overhead during inference."
What is SmoothQuant's core trick?

Chapter 4: Pruning — Deleting Weights

Quantization keeps every weight but stores it cheaply. Pruning takes the opposite tack: identify weights that don't matter and set them to zero, so you can skip them entirely. The catch is in the word "matter" — and in what shape the surviving weights form, because hardware only goes fast on certain shapes.

Three granularities — the central spectrum

Unstructured
Zero out ANY individual weight. Highest accuracy at a given sparsity — but the leftover pattern is irregular, so you need special kernels to actually go fast.
Semi-structured (N:M)
In every group of M weights, keep N (e.g. 2:4 — keep 2 of every 4). Hits a sweet spot: fine-grained AND hardware-friendly (NVIDIA Ampere accelerates 2:4 natively).
Structured
Remove ENTIRE neurons, attention heads, or transformer blocks. The model just gets smaller — runs fast on any hardware — but you cut coarse chunks, so accuracy usually needs a recovery fine-tune.
The deep tension: finer pruning (unstructured) preserves more accuracy but produces an irregular sparse matrix your GPU can't accelerate without bespoke kernels. Coarser pruning (structured) gives a smaller dense matrix that runs fast everywhere — but removing whole heads/neurons cuts more capability. 2:4 semi-structured is the famous compromise: regular enough that the Ampere Tensor Core has dedicated hardware for it, fine enough to keep most of the accuracy.

How do you decide which weight is "unimportant"?

Naive answer: prune the smallest-magnitude weights (a small number contributes little). But the breakthrough method, Wanda, found magnitude alone is wrong for LLMs. Its importance score multiplies weight magnitude by the norm of the corresponding input activation:

score(wij) = |wij| · ‖Xj2

Decode it: |wij| is how big the weight is; ‖Xj2 is how large the activations flowing into that weight typically are. A small weight that always multiplies a huge activation still matters a lot; a large weight that only ever sees tiny activations doesn't. Importance = weight × how-much-it's-used. No retraining, no weight updates — and it matches the far more expensive SparseGPT.

A worked example: 2:4 pruning with Wanda

Take a group of 4 weights with their input-activation norms. Keep the 2 highest scores, zero the rest.

weight w|w|act norm ‖X‖score = |w|·‖X‖keep?
0.80.80.50.40kept (2nd)
0.10.19.00.90kept (1st)
0.60.60.30.18pruned
0.30.30.40.12pruned

Look at the second row: the smallest weight (0.1) gets the highest score and survives, because it consistently multiplies a giant activation. A pure-magnitude scheme would have deleted it and kept the larger-but-rarely-used 0.6. That activation term is why Wanda works on LLMs where plain magnitude pruning collapses.

2:4 Structured Sparsity — Wanda vs magnitude pruning

A weight matrix split into 2:4 groups (every 4 weights keeps 2). Brightness encodes the activation norm of each weight's input. Toggle the metric: under magnitude only, big weights survive; under Wanda, small weights that see large activations (bright) survive instead. The kept set differs — and Wanda's keeps more of what the model actually uses.

The big result

SparseGPT's headline: it can prune the largest models (OPT-175B, BLOOM-176B) to 50% sparsity in one shot — no retraining — with almost no increase in perplexity. It frames pruning as a giant sparse-regression problem and solves it layer-by-layer. This is the pruning analog of PTQ: the "one-shot, gradient-free" property is exactly what makes it viable on models too big to fine-tune.
Why is 2:4 semi-structured pruning so popular despite being less flexible than unstructured pruning?

Chapter 5: Knowledge Distillation

The previous two families shrink an existing model in place. Knowledge distillation (KD) does something different: it trains a brand-new, smaller model — the student — to imitate a large, capable model — the teacher. The student ends up small and fast, but punches above its weight because it learned from the giant.

Why imitating beats training from scratch: A teacher's soft outputs (the full probability distribution over next tokens) carry far more information than a one-hot label. "The next word is 70% 'cat', 25% 'dog', 5% 'animal'" tells the student about similarity structure between words — "dark knowledge" — that a single hard label ("cat") throws away. The student learns the teacher's reasoning shape, not just its final answers.

The two regimes: can you see inside the teacher?

Black-box KD
You only see the teacher's text OUTPUTS (e.g. GPT-4 via an API). Prompt it to generate a training set, fine-tune the student on it. Used to distill emergent abilities: Chain-of-Thought, in-context learning, instruction following.
White-box KD
You have the teacher's weights / output distribution (open-source LLM). The student can match the full probability distribution and even internal layer activations — deeper, richer transfer.

Black-box: distilling emergent abilities

The clever black-box methods don't just copy answers — they copy capabilities that only emerge at scale:

White-box: the reverse-KL insight (MINILLM)

The standard distillation loss is forward KL, KL(pteacher ∥ pstudent). MINILLM showed this is wrong for generative LLMs and uses reverse KL instead, KL(pstudent ∥ pteacher). The difference is everything:

ObjectiveBehaviourEffect on a small student
Forward KL (p‖q)Mean-seeking: student must cover ALL modes the teacher has mass onTries to mimic everything, including low-probability junk it can't represent → spreads thin, hallucinates
Reverse KL (q‖p)Mode-seeking: student focuses mass where the teacher is confidentConcentrates on the major, correct modes → more reliable generation
Why this matters — overestimating the void: A small student literally lacks the capacity to reproduce every nuance of a huge teacher. Forward KL punishes the student for not covering the teacher's low-probability tails, so the student wastes capacity putting probability on rare/garbage continuations — "overestimating low-probability regions." Reverse KL lets the student say "I'll model the parts I can model well and ignore the long tail," which is exactly the right strategy when you're outgunned. This is the whole reason MINILLM works on generative LMs where standard KD struggled.
Forward vs Reverse KL — how a small student fits a teacher

The teacher (gray) is a two-bump distribution. The student (teal) is a single bump with limited capacity — it cannot cover both modes. Under forward KL it splays out to cover both and lands in the empty valley (bad samples). Under reverse KL it commits to the dominant mode (reliable samples). This is the core MINILLM argument made visual.

Why does MINILLM use reverse KL instead of standard forward KL for distilling generative LLMs?

Chapter 6: Low-Rank Factorization

The fourth family attacks the matrix's shape. A weight matrix W is m × n. If it has redundant structure — and trained weight matrices usually do — you can approximate it as the product of two much skinnier matrices:

W ≈ U V,    U is m×k,   V is k×n,   with k ≪ min(m, n)

Define the symbols:

The compression math, worked

Take a 4096 × 4096 weight matrix and approximate it with rank k = 256:

original = 4096 × 4096 = 16,777,216 numbers
factored = 256 × (4096 + 4096) = 2,097,152 numbers
compression = 16.78M / 2.10M = 8.0×

An 8× reduction — if rank 256 captures enough of W. And the win is double: you also do fewer multiplies at inference, because Wx becomes U(Vx) — two cheap skinny matmuls instead of one fat one.

How do you find U and V? The SVD. The Singular Value Decomposition writes W = Σ σi ui viT, ranking every "ingredient" by its singular value σi (its importance). The Eckart–Young theorem says: the best rank-k approximation is to keep the top-k singular values and discard the rest. The discarded "tail" of small singular values is the redundancy you can afford to lose.

The LLM-specific twist: activation-aware (ASVD)

Plain SVD minimizes the error in W itself. But the survey notes ASVD's key finding: what matters is the error in the output Wx, and the activation distribution x is wildly uneven across channels. ASVD scales W by a diagonal matrix reflecting activation magnitudes before the SVD — so the decomposition spends its precious rank on the directions the activations actually probe. Same pattern as AWQ and SmoothQuant: let the data, not the weights alone, decide what to protect.

Low-Rank Approximation — Drag the rank k

Left: a 64×64 weight image. Right: its rank-k reconstruction using the top-k singular values. The bar strip shows the singular-value spectrum (which "ingredients" you're keeping in teal vs discarding in gray). Drag k: at low rank you keep only the dominant structure (high compression, blurry); raise it and the reconstruction sharpens while compression drops. The fast decay of the spectrum is why low-rank works.

Approximating a 4096×4096 matrix with rank k=256 gives roughly what compression?

Chapter 7: The Trade-off — Compare Them Side by Side (the showcase)

You now know all four families. The real engineering question is never "which one is best?" — it's "given my constraint (a memory budget, a latency target, a hardware platform), which technique gets me there with the least accuracy lost?" This chapter is the survey's comparison tables made interactive.

The single most important plot in the field: compression ratio on one axis, perplexity increase (accuracy loss) on the other. Every method is a point in this plane. The goal is the bottom-right: high compression, near-zero quality loss. The numbers below are drawn from the survey's Tables 1 and 2 (real published results on LLaMA / OPT models).
Compression vs Quality — the technique trade-off space

Each dot is a real method (hover-free: labels shown when space allows). X-axis = compression ratio (right = smaller model); Y-axis = perplexity increase (down = better, lower quality loss). Toggle families on/off. Drag the budget line: everything below it meets your quality bar — among those, the rightmost dot is your best compression. This is how you actually pick a method.

Reading the landscape — the rules of thumb

If you need…Reach for…Why
Max memory cut, no retraining, any modelWeight-only PTQ (GPTQ / AWQ / SpQR)3-4 bit ≈ 4-5× smaller, near-zero Δppl, one calibration pass
Actual hardware speedup on INT8Weight-activation quant (SmoothQuant / LLM.int8())Native low-bit matmuls — but handle activation outliers
Speedup on standard GPUs via sparsity2:4 pruning (SparseGPT / Wanda)Ampere accelerates 2:4; one-shot, ~50% sparse
A genuinely smaller, portable modelStructured pruning + LoRA recovery, or distillationFewer params/layers → runs fast anywhere, no special kernels
A small model with big-model behaviorKnowledge distillationStudent inherits emergent abilities (CoT, instruction following)
They compose. The biggest practical wins stack techniques: QLoRA = 4-bit quantization + low-rank adapters for fine-tuning. Structured pruning is routinely followed by distillation recovery (the survey's Remark 2). 2:4 sparsity + INT8 quantization together. These four families are not rivals — they are a toolbox, and senior practitioners reach for several at once.
You need the smallest model possible on a phone with no special sparse kernels, and you can afford a short recovery fine-tune. Best primary choice?

Chapter 8: Metrics & Benchmarks

You cannot pick the rightmost dot in Chapter 7 unless you agree on how to measure both axes. The survey devotes a section to this — and getting the measurement right is where a lot of compression "wins" quietly fall apart.

The efficiency metrics — what "smaller/faster" actually means

MetricDefinitionGotcha
Model sizeTotal number of parameters (× bits)Params alone ignore precision; report bits too
FLOPsFloating-point ops per inferenceTheoretical compute, not real speed
MFUActual FLOPS ÷ device's peak FLOPSWhere the FLOPs/speed gap hides — low MFU means you're memory-bound, not compute-bound
Inference latencyWall-clock time per responseWhat users actually feel
Speedup ratiolatency(original) / latency(compressed)Hardware-dependent — unstructured sparsity may give 0× speedup without custom kernels!
Compression ratiosize(original) / size(compressed)Memory win ≠ speed win (weight-only quant)
FLOPs vs MFU — the trap that fools everyone: A method can cut FLOPs in half and deliver zero speedup. Why? LLM decoding is memory-bandwidth-bound, not compute-bound — you spend your time shuttling weights from HBM to the cores, not multiplying. MFU exposes this: if your MFU is 10%, the chip is starved for data, and reducing FLOPs doesn't help — reducing memory traffic (quantization) does. This is precisely why weight-only quantization speeds up LLMs even though it adds dequant FLOPs: it slashes the bandwidth bottleneck.

The quality benchmarks — what "still good" means

FLOPs vs MFU — why cutting FLOPs ≠ speedup

A simplified roofline. The diagonal is the memory-bandwidth ceiling; the flat top is the compute ceiling. The dot is your workload's arithmetic intensity. When it sits on the diagonal (low intensity, as in LLM decoding) you are bandwidth-bound — cutting FLOPs slides you left along the roof but achievable performance doesn't rise. Lower the bandwidth limit to see the dot drop: that's why reducing memory traffic, not FLOPs, is what speeds up LLMs.

Why can a compression method cut FLOPs in half yet give no real speedup on LLM decoding?

Chapter 9: The Frontier — Open Problems

The survey closes by admitting the field "is still in its early stages." The honest open problems are as instructive as the methods — they tell you where the next breakthroughs (and the current failure modes) live.

The scaling-law tension
Scaling laws say performance follows size. Compression deliberately removes size. There is a fundamental trade-off no clever trick fully escapes — understanding its theory is the deepest open question.
Port classic tricks to LLMs
Lottery-ticket hypothesis, parameter sharing — workhorses on small nets, barely explored at LLM scale.
AutoML for compression
Today's methods are hand-designed (student architectures, bit allocations). NAS / meta-learning could auto-select per-layer compression.
Explainability
CoT distillation works — but WHY does reasoning transfer? We can't yet explain what compression keeps vs destroys.
Deployment-aware eval
Use the Roofline model + arithmetic intensity to judge methods on real hardware, not just FLOPs on paper.
The deepest tension, stated cleanly: The scaling law (Kaplan et al.) is empirical evidence that capability is bought with parameters, data, and compute. Compression is the project of buying capability back after removing parameters. These two facts are in direct conflict. Every compression method is, in effect, a bet that the trained model is over-parameterized — that it stored its knowledge with slack you can squeeze out. Where that slack runs out is exactly where compression stops being free, and nobody yet has the theory to predict that point.

Calibration data: the quiet make-or-break

An easily-missed practical lesson (Remark 4): PTQ and one-shot pruning both rely on a small calibration dataset to choose scales / importance. The survey flags an empirical study finding that downstream performance "can vary significantly depending on the calibration data selected." A method that looks great on WikiText calibration can underperform on your real distribution. The unglamorous truth: your choice of a few hundred calibration samples can matter as much as the algorithm.
What fundamental tension does the scaling law create for model compression?

Chapter 10: Connections & Cheat Sheet

This survey is a map of an entire subfield. The deeper you go into any one box, the more you find a dedicated lesson. Here's the whole picture and where to go next.

Pre-2020
Classic NN compression — pruning (LeCun '89), distillation (Hinton '15), quantization, low-rank — developed on small CNNs/RNNs
2022
LLM.int8(), ZeroQuant, GPTQ — outlier-aware quantization makes billion-param models deployable
2023
SmoothQuant, AWQ, SparseGPT, Wanda, QLoRA, MINILLM — the modern LLM toolbox crystallizes
2024 (this survey)
The four-family taxonomy, unified metrics, the open-problem map — a field self-aware enough to write its own atlas

The cheat sheet — every key idea in one table

FamilyCore ruleKey methods · best use
Quantizationscale = max|w|/(2b−1−1); wq=round(w/scale)GPTQ, AWQ, SpQR (weight-only); SmoothQuant, LLM.int8() (weight-act); KIVI (KV cache)
Pruningzero low-importance weights; Wanda score = |w|·‖X‖SparseGPT, Wanda (unstruct / 2:4); LLM-Pruner, SliceGPT (structured)
Distillationtrain small student to match teacher; reverse-KL for generativeCoT/ICL/IF distill (black-box); MINILLM, GKD (white-box)
Low-rankW ≈ UV via top-k SVD; compress = mn / k(m+n)ASVD (activation-aware), LASER (layer-selective)
PTQ vs QATPTQ = no retraining (calibrate only); QAT = retrainPTQ for huge LLMs; QAT+PEFT to push sub-4-bit
Metricscompression ratio & speedup vs Δperplexity; watch MFUFLOPs ≠ speed; memory-bandwidth is the real LLM bottleneck

The core algorithm as runnable code

python
# The three weight-touching techniques in one place
import torch

def quantize(W, bits=4):
    """Symmetric per-tensor INT quantization."""
    qmax = 2**(bits-1) - 1
    scale = W.abs().max() / qmax
    Wq = torch.round(W / scale).clamp(-qmax, qmax)
    return Wq * scale            # dequantized (sim'd low-bit)

def wanda_prune_2of4(W, X):
    """2:4 sparsity, Wanda importance = |w| * ||x||."""
    act_norm = X.norm(dim=0)               # per-input-channel
    score = W.abs() * act_norm[None, :]   # [out, in]
    score = score.reshape(W.shape[0], -1, 4)
    keep = score.argsort(dim=-1)[..., 2:]    # top-2 of every 4
    mask = torch.zeros_like(score, dtype=torch.bool).scatter_(-1, keep, True)
    return (W.reshape(W.shape[0], -1, 4) * mask).reshape(W.shape)

def low_rank(W, k=256):
    """Best rank-k via SVD (Eckart-Young)."""
    U, S, Vh = torch.linalg.svd(W, full_matrices=False)
    return (U[:, :k] * S[:k]) @ Vh[:k]   # == U' V', stores k(m+n) numbers

The one-paragraph summary you could give on a whiteboard

An LLM is too big to deploy because its weights eat memory (175B params × 2 bytes = 350 GB). Four families fix this. Quantization stores each weight in fewer bits (16→4), bottlenecked by outlier weights/activations — solved by mixed precision (LLM.int8()), salient-weight protection (AWQ), or difficulty-migration (SmoothQuant). Pruning zeros unimportant weights — importance = |w|·‖activation‖ (Wanda), shaped as unstructured/2:4/structured to trade accuracy against hardware speed (SparseGPT prunes 50% one-shot). Distillation trains a small student to copy a big teacher, using reverse-KL so the capacity-limited student commits to confident modes (MINILLM). Low-rank factorization replaces W with U·V via top-k SVD (8× at rank 256), activation-aware (ASVD). You pick among them by plotting compression vs perplexity-loss under your hardware constraint — and the biggest wins stack several together (QLoRA = quant + low-rank).

"Model compression involves transforming a large, resource-intensive model into a compact version suitable for deployment on resource-constrained devices."
— Zhu et al., A Survey on Model Compression for LLMs (2024)