Skip to content
mlmentorship

Grouped-query and multi-query attention (GQA, MQA)

Share K and V heads across query heads to shrink the KV cache 4-8x with negligible quality loss. Standard in modern decoder LLMs.

Published · 7 min read ·Core ·Intermediate

Summary

GQA and MQA reduce the number of distinct K/V projection heads while keeping the full set of Q heads, so multiple query heads share the same key and value tensors. MQA is the extreme case: one K/V head total. GQA picks an intermediate number of K/V groups.

The KV cache dominates LLM serving memory at long contexts (see KV cache). Cutting the number of K/V heads cuts cache size proportionally:

  • MHA (standard, e.g. GPT-3): K and V have the same number of heads as Q.
  • MQA (Shazeer, 2019): 1 K and 1 V head shared across all Q heads. ~num_heads× smaller cache.
  • GQA (Ainslie et al., 2023): G groups, each shared across num_heads / G Q heads. Tunable midpoint.

Llama 2 70B uses GQA with 8 K/V groups for 64 query heads (8× cache reduction). Llama 3, Mistral, Qwen, and most modern decoders default to GQA.

The mechanism

In standard multi-head attention, for each head :

with and .

In GQA with groups, the query heads are partitioned into contiguous groups of size . All query heads in the same group attend to the same shared . MQA is GQA with .

Implementation: project K and V to dimension instead of , then broadcast (repeat) across the matching Q heads before the matmul.

Share key/value pairs without merging the eight query outputs

Eight queries share two KV groups, not two outputsEach query still produces its own result. Sharing key/value projections changes cache storage, not the number of query outputs.Share the store, preserve every queryoutputKV 1Q1O1Q2O2Q3O3Q4O4KV 2Q5O5Q6O6Q7O7Q8O8Two stores; eight independentlycomputed outputs.
Derivation
Share two K/V pairs without merging eight query headsEight query heads each retain their own output. A dashed bracket associates Q1 through Q4 with K1 and V1, and Q5 through Q8 with K2 and V2. Proportional head-dependent cache bars compare eight, two, and one KV heads for MHA, GQA, and MQA at fixed sequence length and head dimension.Brackets denote sharing; arrows preserve headidentityK1 + V1 reusedK2 + V2 reusedQ1O1Q2O2Q3O3Q4O4Q5O5Q6O6Q7O7Q8O8Eight distinct queries -> eight outputheadsHead-dependent KV cache; fixed length and headsizeMHA8/8GQA2/8MQA1/8GQA: one-quarter cache, not one-quarter of allcompute.
Follow each Q-to-O arrow separately. Brackets mean K/V reuse, not merged queries. Two cached pairs instead of eight use one-quarter of head-dependent cache, not one-quarter of all computation.
Check: Which keys and values do Q3 and Q6 use? Why are there still eight query outputs?
Read it this way: Each query still produces its own result. Sharing key/value projections changes cache storage, not the number of query outputs.
Does sharing two KV groups reduce eight query outputs to two?

Tradeoffs

VariantKV headsCache sizeQualityUsed by
MHA1×baselineGPT-3, original Llama
GQA-88×~baselineLlama 2/3 70B, Mistral
MQA1×small dropPaLM, Falcon

GQA recovers nearly all MHA quality while keeping most of MQA’s cache savings. The dominant choice in 2026.

Common pitfalls

  • Confusing K/V heads with Q heads. GQA shrinks K/V only; Q stays full-rank.
  • Assuming the speedup is in compute. GQA mostly saves memory (cache + bandwidth), not FLOPs. The matmul cost barely changes.
  • Re-training cost. You generally cannot convert MHA → GQA post-hoc; the K/V projections were trained per-head. Distillation or partial re-training is required.