从模型架构到资源需求：注意力、KV 与 MoE 的量化影响

1. 场景：架构决定系统账本

同样的参数量，不同的模型架构对应完全不同的显存、带宽与算力需求。本文承接第 1 篇的三本账（显存/算力/带宽），把注意力、KV 复用、GQA 与 MoE 稀疏激活的影响逐项量化，让你在选型时能直接算出"这个架构要吃多少资源"。

2. 注意力：计算量随序列长度增长

标准多头注意力（MHA）对每个 token 与全部历史 token 做注意力计算，prefill 阶段的计算量随序列长度呈二次增长：

$$FLOPs_{attn} \propto S^2 \times H$$

• S=序列长度、H=注意力头数。输入从 4K 涨到 32K（8 倍），注意力部分算力需求涨约 64 倍。
• decode 阶段每个新 token 只与已有 KV 做注意力（$S$ 次），计算量线性——这也是为什么长上下文下 prefill 变重、TTFT 变长。
• 工程后果：FlashAttention 把 KV 按块重排、避免把整段 KV 搬进片上存储，直接砍掉的是搬移量而非数学复杂度（细节见 11 章 llm-lab-07-flash-attention）。

3. KV 缓存：随上下文线性增长，GQA 是开关

第 1 篇已给公式：每 token 的 KV 占用 = 2 × L × K × H × bytes。这里看架构如何改变 K：

架构	KV heads（K）	与 Q heads 关系	32K 上下文 KV（70B 级，BF16）
MHA	= Q heads（如 64）	每 query head 一份 KV	~42 GB
GQA	8	8 个 query head 共享 1 份 KV	~5.2 GB
MQA	1	全部 query head 共享 1 份 KV	~0.65 GB

同样的上下文，MHA→GQA 能把 KV 缓存降约 8 倍。这就是主流开源模型（Qwen、Llama 3 系）全面转向 GQA 的系统层原因：省的是显存与带宽，而不是模型质量主指标。量化上可验证：KV 缓存不随 batch 变化（共享），随并发上下文总量线性增长——部署规划先算"并发 × 平均上下文 × KV/token"。

4. MoE：稀疏激活改写带宽账

MoE（混合专家）的关键在于：权重总量大，但每个 token 只激活部分专家。

$$B\_needed = N_{active} \times bytes \quad (bytes/token)$$

模型	总参数	激活参数	FP16 权重读取/token	等效 7B 带宽代价
Dense 7B	7B	7B	14 GB	1×
Dense 70B	70B	70B	140 GB	10×
MoE 70B-A3B	~70B	~3B	~6 GB	0.43×

上表说明 MoE 的算账逻辑：显存按总参数买，带宽按激活参数付。同卡数下，70B MoE（激活 3B）的 decode 带宽代价只相当于 7B dense 的 43%，吞吐/成本优势由此而来；代价是路由通信（All-to-All）与专家负载不均，需要 03 章网络账与调度配合（见第 4 篇训练账中的通信项）。

5. 架构选型决策清单

• [ ] 长上下文为主 → 先算 KV 账，优先 GQA/MQA 与 KV 量化；MHA 在 32K 以上几乎不可用
• [ ] decode 密集（对话/流式）→ 看激活参数带宽账，MoE 显著占优；prefill 密集（批处理离线）→ 看算力账
• [ ] 显存紧张 → 权重量化（INT4 减权重账）+ KV 量化（减缓存账）双管齐下，先算清各自省多少
• [ ] 多卡部署 → 确认 GQA/MoE 的通信模式：KV 分片 vs 专家 All-to-All，网络账不同（见 03 章与 11 章）
• [ ] 换模型必重算：同参数量的 Dense/MoE/GQA 组合，资源画像可能差一个数量级，不要凭参数量选型

方法参考：数量级估算与"数据搬移五问"框架参考开源书稿《深入理解 AI Infra：量化分析与系统设计》（李博杰，Apache-2.0，bojieli.github.io/ai-infra-book）；本文算例与推导为本站自行整理，具体模型配置以官方 config 为准。