A Survey of Token Compression for Efficient Multimodal Large Language Models

In plain words

Multimodal chatbots that look at images, watch videos or listen to audio turn each piece of input into many small "tokens". A high-resolution picture or a long video can produce far more tokens than the text around it, and the cost of the model grows quickly with the number of tokens. Token compression means shrinking that stream before or inside the model, so there is less to process.

This survey collects the many ways researchers have done this. It sorts them two ways: by the kind of input (still images, video, audio), since each has its own kind of repetition, and by the trick used (resizing the grid, merging similar tokens, dropping tokens the model barely looks at, or asking a question to pick what matters). It also discusses where compression hurts, such as reading small text, keeping track of timing, and multi-turn chats.

TL;DR

The paper is the first structured survey of token compression for multimodal large language models §1. It proposes a modality-based split (image, video, audio) and a mechanism-based split (transformation, similarity, attention, query) §1. It runs no experiments: its result tables are compiled from the cited works and are author-reported tab. 2 tab. 3. It names open problems in cross-modal joint compression, benchmarks and deployment §6 §8.

Problem

Self-attention cost grows quadratically with sequence length, and multimodal inputs produce long sequences: image tokens scale with resolution, audio tokens with duration, and video tokens with both §1. As a worked example, the paper converts a 90-minute video at 10 frames per second and 1000 tokens per frame into about 54 million tokens §1.

The paper defines token compression narrowly. A method counts only if it explicitly reduces the number of tokens passed to later layers or modules §2.4. Frame sampling and key-frame extraction are included as input-level compression §2.4. Attention sparsity that keeps the sequence length the same (N to N) is excluded, because it sparsifies the computation rather than the representation §2.4.

The paper treats three steps as the core of every method: identify important tokens, quantify redundancy, and then merge or prune §1.

Method

This is a survey, so the "method" section maps the taxonomy and the mechanisms it describes. Each mechanism is named by how it changes the token set.

Architecture the survey assumes §2.1: a modality encoder produces patch embeddings, a projector maps them into the LLM's embedding space, and the LLM decodes text from the concatenated sequence. Multimodal tokens are usually most of the sequence in reasoning tasks §2.1. Compression can sit in the encoder, in the projector, or inside the LLM; the paper's pruning-location discussion covers that trade-off §6.

Four mechanisms tab. 1 §3:

1. Transformation-based. Reshape the token grid. The paper distinguishes three operators §3.1:

   • pixel unshuffle, which trades spatial size for channels (height and width divided by r, depth multiplied by r²); r is usually 2, giving 25% of the tokens and a trained MLP to restore the hidden size §3.1;
   • spatial pooling or interpolation, which downsamples without changing the hidden size and needs no weights §3.1;
   • spatial convolution with stride S, which learns the reduction §3.1. The paper notes that pooling and interpolation can run training-free, and that the common ratios are fixed by the 2D downsampling factor §3.1.

2. Similarity-based. Merge or cluster tokens that are alike. The reference method is ToMe, which uses bipartite soft matching between the attention and MLP blocks of a ViT and replaces each matched group with a merged token §3.2. The survey adds methods that keep diverse rather than similar tokens (a max-min diversity selection, DivPrune) and methods that merge inside the LLM (TopV) §3.2. It warns that merging can lose spatial layout and that over-generalised tokens are hard to tell apart §3.2.

3. Attention-based. Keep the tokens that attract the most attention.

   • Encoder side: keep the top-k tokens by attention to the [CLS] token, and optionally merge the rest §3.3. Examples are PruMerge and VisionZip §3.3.
   • Decoder side: keep the top-k visual tokens by the average attention computed over the layer's attention window §3.3. FastV is the early example: after layer two it prunes half the visual tokens, and the survey reports that on LLaVA-1.5 visual tokens received about 0.21% of the attention given to system prompts after that layer §3.3. Other decoder methods vary the pruning across layers (PyramidDrop, FitPrune, ZipVL) or drop all visual tokens after a calibrated layer (VTW) §3.3.
   • Practical cost: explicit attention scores are not exposed by fused kernels such as FlashAttention, so pruning needs an extra attention pass that can cancel the gain for progressive schemes §3.3 §6.

4. Query-based. Use the text prompt to choose what to keep.

   • Token distillation: learned queries (a Q-Former) or register-style tokens compress visual input into a fixed small set. LLaMA-VID uses two tokens per image, LLaVA-Mini one, and VoCo-LLaMA uses the LLM itself §3.4.
   • Cross-modal selection: text tokens pick visual tokens (SparseVLM, AdaFV, TRIM) §3.4. The survey notes these help poorly in multi-turn chats, because a new question may need different tokens and the compression must rerun §3.4 §6.

Video §4 adds temporal redundancy. Current video LLMs often sample at 1 frame per second §4. Temporal pooling matters more than spatial pooling for PLLaVA's results, and LLaMA-VID reduces each frame to one token in long sequences §4. 3D convolution gave VideoLLaMA 2 the best balance in its study §4. Similarity methods first cluster frames (Chat-UniVi, FastVID, PruneVid, HoliTom), and attention methods inside the decoder often use a window over time §4. Token distillation for video uses Q-Former-style adapters, Token Turing Machines and memory banks §4. LongVU keeps more tokens for query-relevant frames §4.

Audio §5 splits representations into continuous (Whisper, Conformer encoders) and discrete (HuBERT, EnCodec codebooks) sequences; the discrete ones already have fewer tokens by design, which the survey leaves aside §5. Compression methods include token stacking (HTS-AT, SLAM-ASR, LLaMA-Omni), pooling with stride 2 (Qwen2-Audio, Qwen2.5-Omni), and temporal convolution that yields an effective 12.5 Hz rate in several models §5. Audio-specific redundancy includes spectral and temporal repetition and silence or noise §5.5.

A pseudocode sketch of the decoder-side attention rule, following the formulas in §3.3 (the paper's wording says "receive", but its formula averages the attention each visual token sends to the window; see Pitfalls):

# Decoder-side visual token pruning  [§3.3]
# Input:  attn (num_tokens, num_tokens) for one layer, averaged over heads
#         visual_idx: positions of visual tokens in the window
#         keep: number of visual tokens to retain
# Output: indices of retained visual tokens

def select_visual_tokens(attn, visual_idx, keep):
    # Average attention for each visual token over all tokens in the
    # window; the survey's formula averages the row for that token  [§3.3]
    scores = attn[visual_idx, :].mean(axis=-1)    # (num_visual,)
    # Keep the k visual tokens with the highest scores  [§3.3]
    order = top_k_indices(scores, keep)
    return visual_idx[order]

Hyperparameters

The survey trains nothing. The values below are the typical settings the paper states for the methods it discusses.

Results

Author-reported. The paper runs no experiments. Its tables reproduce numbers from the cited methods, under each method's own setup tab. 2 tab. 3. The selection below is a subset; read the full tables in the paper before comparing methods.

Image, training-free methods on LLaVA-1.5-7B (baseline row has 576 tokens at 336 px) tab. 2:

Image, models trained with compression tab. 2:

Video, training-free methods on LLaVA-OneVision-7B (baseline = 100% of tokens) tab. 3:

Setup for the image rows: LLaVA-1.5-7B, each method's own setting and retained count as listed. Setup for the video rows: LLaVA-OneVision-7B, each method's own configuration, as the video section and its trade-off figure state §4. The benchmark prompts are listed in the benchmark table in §6.

Paper vs code

No official code. The arXiv comments link a GitHub repository, cokeshao/Awesome-Multimodal-Token-Compression, which is a public paper list kept for "ongoing updates". It is not implementation code, so it was not cloned and is not recorded as code. The check covered the arXiv abstract page and comments, the LaTeX source (no code links), and the paper's text.

Pitfalls

• Survey, not a method. Nothing in this card was run. Every number is copied from another paper, and the setups differ, so the rows cannot be ranked against each other as the paper's own results §6.
• Attention direction in the decoder formula. The text says visual tokens are ranked by the attention they receive from other tokens §3.3. The formula averages the attention from each visual token to the window §3.3. An implementation has to pick one; the code of the cited methods was not part of this survey.
• Table column alignment. In the video table, several training-free rows (VisionZip, PruneVid, FastVID, HoliTom) have one more cell than the column header implies, so the values cannot be assigned to benchmarks with confidence. They are left out above tab. 3.
• Duplicate label. The image table lists "VisionZip++" at 128 and 64 tokens, with the same citation as VisionZip tab. 2. The name is used as printed.
• Not stated. No latency, memory or throughput measurements are given for most rows. The paper itself argues that FLOPs and token counts are poor proxies and that time to first token and per-token decoding latency should be reported §6.
• Attention pass cost. Decoder-side pruning that needs explicit attention scores conflicts with fused attention kernels, and progressive schemes pay for an extra attention pass §3.3 §6.
• Multi-turn chats. Query-based compression must be redone for each new question, so it is poorly suited to conversations §3.4 §6.
• Where to prune. Early pruning (encoder or projector) is cheapest but riskiest; pruning inside the LLM is costlier but keeps more refined features. The paper calls the optimal location open §6.
• Compression is not free for some tasks. OCR and fine-grained temporal reasoning degrade under merging; the paper cites RefCOCO-style grounding and temporal grounding benchmarks as hard cases §6.
• Version. The source is arXiv v5 (updated 2026-02-01); the LaTeX has a TMLR 2026 template. Table and figure numbers above follow the order of the LaTeX source and were not checked against the compiled PDF.

Lineage

• Builds on: token pruning and merging in vision transformers (DynamicViT, EViT, ToMe, TokenLearner) §2.3; text prompt compression (LLMLingua series, AutoCompressor, ICAE) §2.2; KV-cache policies (H2O, StreamingLLM, SnapKV, PyramidKV) §2.2.
• Compared against: model quantization, network pruning, knowledge distillation and low-rank factorisation, which compress weights rather than tokens §6.
• Superseded by: not applicable (survey as of v5).