详细解释
分组查询注意力（Grouped Query Attention，缩写 GQA） 是 2023 年 Llama 2 系列提出后迅速成为事实标准的 Attention 变体。它解决的核心痛点是：在长上下文 + 高并发场景下，KV Cache 的显存占用会把推理卡撑爆。
原始 MHA（Multi-Head Attention，多头） 是 Q 头数 = K 头数 = V 头数 = H，每个 Q 头各算各的 K、V——精度最高但 KV Cache 也是 H 份。后来 Google 提出 MQA（Multi-Query Attention，多查询）：所有 Q 头共享同一对 KV——KV Cache 直接砍到 1/H，但输出质量会明显下降（尤其是长文本总结、代码生成类任务）。
GQA 的折衷方案是：把 H 个 Q 头分成 G 组，每组内的 (H/G) 个 Q 头共享同一对 K/V。例如 Llama 3.1 405B 用 H=128 Q 头，G=8 组，相当于每组 16 个 Q 头共用 KV——KV Cache 体积砍到原来的 G/H = 1/16 ≈ 6.25%，而输出质量相比 MHA 几乎无感知下降。
参考：GQA 原文 及 Llama 3.1 模型卡。
三种 Attention 显存与质量对比（单序列 32K context，32 H，H_dim=128，FP16）
| 类型 | Q 头数 | K 头数 | KV Cache 大小（2 层为例） | 输出质量 | 典型厂商 |
|---|---|---|---|---|---|
| MHA | 32 | 32 | 32 × 128 × 32K × 2 × 2B ≈ 512 MB | 最高 | GPT-3.5 早期、开源小模型 |
| GQA（G=8） | 32 | 8 | 8 × 128 × 32K × 2 × 2B ≈ 128 MB | 接近 MHA | Llama 3.x、Qwen3、DeepSeek-V2 |
| MQA | 32 | 1 | 1 × 128 × 32K × 2 × 2B ≈ 16 MB | 下降明显 | PaLM、Falcon |
对计费和速率的影响
- 对 TPM / RPM 没直接影响：GQA 是模型内部实现，对外 API 接口和 每百万 Token 价格不改变。
- 间接降低成本：厂商每张卡能扛的 并发请求数 更高（因为 KV 小了），所以供应充足 → 价格下降。
- TTFT 更快：Decode 阶段每步读 KV 的带宽开销降低，端到端 TPS 通常提升 1.5×–2×。
- 长 Context Window 更稳：128K 以上场景，GQA 相比 MHA 更不容易出现 OOM，唯元智创 上 GQA 模型长序列请求成功率平均高 8%–12%。
常见问题
GQA + MoE 一起用是最优解吗？
自己部署时能把 MHA 模型转 GQA 吗？
不行，GQA 是训练时就决定的权重结构（K/V 投影矩阵的形状已经是 G 组了），后处理只能”硬合并 KV 头”但质量退化和 MQA 差不多。直接选原厂 GQA 模型即可。
GQA 分组数 G 一般取多少？
开源社区经验值 G ∈ [4, 8]，且让 H 能被 G 整除。Llama 3.1 (70B/405B) 选 G=8，Qwen3 选 G=4，DeepSeek-V2 用了 64 Q × 8 KV（G=8 变种）。G 越小越接近 MQA（省显存但掉质量），G 越大越接近 MHA。