理解 Transformer 的内部计算特征，是所有推理优化的基础

前置知识

建议先阅读 什么是 FDE 了解岗位定位。

核心概念

为什么 FDE 需要理解 Transformer

面试中不会让你手推 Attention 公式，但会问：

• "为什么长上下文的推理延迟会飙升？"
• "GQA 和 MHA 对部署有什么影响？"
• "为什么 decode 阶段是 memory-bound？"

核心原则：理解计算特征，才能找到优化点。

Transformer 架构变体

为什么 LLM 几乎全部采用 Decoder-only？

1. 训练简单 ：只需要 Causal LM Loss（预测下一个 token），不需要额外的对齐任务
2. 推理简单 ：自回归生成，每步只需要 Decoder，不需要 Encoder-Decoder 的 cross attention
3. Scaling Law 最优 ：Chinchilla 论文表明 Decoder-only 在同等参数量下性能最好
4. 上下文灵活 ：可以做 in-context learning，zero-shot/few-shot 能力强

完整数据流：从 Token 到 Logit

Attention 公式详解

各维度：

• Q : 线性投影后 [batch, seq_len, d_model] ，reshape 为 [batch, seq_len, num_heads, head_dim] ，再 transpose 为 [batch, num_heads, seq_len, head_dim]
• K : 同 Q 的变换过程
• V : 同 Q 的变换过程
• QK^T : [batch, num_heads, seq_len, seq_len] — 注意力分数矩阵
• softmax(...) 在最后一个维度（key 维度）上做归一化

为什么除以 sqrt(d_k) ？

如果 Q 和 K 的元素是均值为 0、方差为 1 的随机变量，那么 Q·K^T 每个元素的方差为 d_k 。当 d_k 较大时，点积值会很大，导致 softmax 进入饱和区（梯度接近 0），即 梯度消失 问题。除以 sqrt(d_k) 将方差重新归一化为 1，使 softmax 的输入保持在合适的范围内。

推理的两个阶段

这是 FDE 面试中 最重要 的概念：

Prefill（预填充）

• 输入所有 prompt token， 并行计算
• 复杂度：Attention 部分 O(seq_len^2) ，FFN 部分 O(seq_len)
• 瓶颈：计算密集型（compute-bound） ，GPU 利用率可达 80-95%
• 只执行一次，通常占总推理时间的 5-15%

Decode（解码）

• 逐个生成 token ，每步依赖上一步的结果（自回归）
• 每步的 seq_len = 已生成的 token 数 + 1（逐步增长）
• 每步都要加载全部模型权重到 GPU
• 瓶颈：内存带宽型（memory-bound） ，GPU 利用率通常只有 10-30%
• 执行 output_length 次，占总推理时间的 85-95%

KV Cache（核心优化）

是什么

在 decode 阶段，把前面所有 token 的 Key 和 Value 缓存起来，避免重复计算 Attention 中已有的历史 token 矩阵乘法。

显存计算

考虑 GQA 的情况 ：GQA 模型中 num_kv_heads = num_q_heads / groups ，所以实际 KV Cache 比 MHA 小 G 倍。

示例计算：Llama 3 70B（GQA, 8 KV groups）

KV Cache 通常占推理显存的 60-80%。 这是 FDE 优化的核心战场。

为什么 Decode 是 Memory-Bound 的定量分析

以 Llama 3 70B 为例，单步 decode 的计算量和数据搬运：

对比 prefill（seq_len=4096）：

部署视角

生产环境中的关键数字

常见问题排查

部署优化方向

1. 减少 KV Cache ：GQA/MQA、KV Cache 量化、PagedAttention
2. 提高 Prefill 效率 ：Chunked Prefill（将长 prompt 分段处理，避免 KV Cache 峰值）
3. 提高 Decode 效率 ：Continuous Batching（动态合并不同请求的 decode 步）
4. 权重优化 ：权重量化（INT8/FP8/INT4）、张量并行

面试视角

面试官会怎么问

Q1: "解释一下 Transformer 推理的两个阶段，它们各自的特点是什么？"

满分回答框架：

• Prefill：并行处理所有 prompt token，compute-bound，O(n^2) 复杂度，只执行一次
• Decode：逐个生成 token，memory-bound，每步加载全部权重，执行 output_length 次
• Decode 占总时间 85-95%，是优化重点

Q2: "给你一个 70B 的模型，batch=64，seq_len=32K，FP16，用 GQA（8 groups），估算 KV Cache 大小？"

满分回答框架：

• 写出公式： 2 × num_layers × batch × seq_len × num_kv_heads × head_dim × 2 bytes
• 代入 Llama 3 70B 参数：80 层，num_kv_heads=8，head_dim=128
• 计算： 2 × 80 × 64 × 32768 × 8 × 128 × 2 ≈ 343 GB
• 结论：单卡放不下，需要多卡或减少 batch/seq_len

Q3: "为什么 decode 是 memory-bound 而不是 compute-bound？"

满分回答框架：

• Decode 每步的 FLOPs 约为 2 × params ，但需要加载全部 params × 2 bytes 的权重
• 以 A100 为例：计算只需 0.45ms，权重搬运需 70ms
• GPU 算术单元 99% 时间在等待数据从 HBM 搬运
• 因此优化方向是提高带宽利用率（量化减少数据量、张量并行分担带宽压力）

Q4: "为什么 LLM 都用 Decoder-only 架构？Encoder-Decoder 不好吗？"

满分回答：

• Decoder-only 训练简单（只需要 Causal LM Loss）
• 推理只需 Decoder，无需 cross attention
• Scaling Law 表现最优
• 支持 in-context learning
• Encoder-Decoder 需要 Encoder 预编码 + Decoder 生成 + Cross Attention，部署复杂度高

对比分析

Decoder-only vs Encoder-Decoder 推理开销对比

最佳实践

调参建议

• batch_size ：越大吞吐越高，但 KV Cache 线性增长。70B 模型在 A100 上建议 batch ≤ 32
• max_seq_len ：根据业务需求设置，不要盲目设为模型最大值。KV Cache 随 seq_len 线性增长
• chunked prefill ：prompt 超过 8K 时启用，避免 KV Cache 峰值导致 OOM
• continuous batching ：必开，不同请求的 decode 步动态合并，提升吞吐 2-3x

避坑指南

• 不要用 MHA 模型做长上下文推理（KV Cache 爆炸）
• 不要一次性把所有显存分配给 KV Cache，留 10-20% 给中间激活
• 监控 GPU 利用率：decode 阶段低于 20% 是正常的（memory-bound 特性决定）
• 选择 H100 而非 A100 做推理：HBM3 带宽提升 1.5x，对 decode 有直接收益