大模型核心八股文 - 面试高频问答¶

详细步骤:
  1. 输入X ∈ R^{n×d} 通过三个权重矩阵:
     Q = XW_Q, K = XW_K, V = XW_V  (W ∈ R^{d×d_k})
  2. 注意力分数: S = QK^T / sqrt(d_k)  → S ∈ R^{n×n}
  3. 归一化: A = softmax(S)  (按行softmax)
  4. 加权求和: Output = AV  → R^{n×d_v}

为什么除以sqrt(d_k)?
  - Q和K的点积期望值随维度增大而增大: E[q·k] = d_k × E[q_i × k_i]
  - 点积过大 → softmax梯度趋近0(梯度消失)
  - 除以sqrt(d_k)使方差归一化为1

瓶颈: n^2的注意力矩阵
  序列8K: 8192^2 × 2B(FP16) = 128MB → 可接受
  序列128K: 131072^2 × 2B = 32GB → 一块GPU的显存全占满!
  → 这就是FlashAttention等优化的动机

实现:
  将d维空间切分为h个子空间(head_dim = d/h)
  每个头独立计算Attention，最后concat + 线性投影

  MultiHead(Q,K,V) = Concat(head_1, ..., head_h) × W_O
  head_i = Attention(QW_Q^i, KW_K^i, VW_V^i)

计算量: 与单头几乎相同(参数量完全相同)
  单头: d × d × 3 (QKV) + d × d (输出) = 4d^2
  多头: d/h × d × 3 × h + d × d = 4d^2  ← 完全一样!

优势:
  不同头可以学到: 语法关系、语义关系、位置关系、指代关系等
  实际可视化发现: 有些头关注局部, 有些关注全局, 有些关注特定语法结构

对比:
  MHA (Multi-Head Attention): Q=32头, K=32头, V=32头
    KV Cache大小: 2 × 32 × seq_len × head_dim × precision

  MQA (Multi-Query Attention): Q=32头, K=1头, V=1头
    KV Cache减少32倍! 但质量有损

  GQA (Grouped Query Attention): Q=32头, K=8头, V=8头
    KV Cache减少4倍, 质量接近MHA

使用情况:
  许多 70B 级别模型会使用 GQA（例如 8 KV 头对应更多 Q 头）
  Qwen、Mistral 等系列也常见 GQA 设计
  → 按近年公开模型样本看，很多 LLM 在推理侧采用了 GQA 或相近思路

核心问题:
  标准Attention: 需要将n×n的注意力矩阵写入HBM再读回来
  GPU HBM带宽: ~2TB/s (A100)
  GPU SRAM带宽: ~19TB/s → 10倍差距!

FlashAttention做法:
  将Q、K、V分成小块(tile)，每块能放入SRAM
  在SRAM中计算完整个tile的softmax贡献
  使用"在线softmax"技巧: 不需要看到所有K就能正确计算softmax
    - 关键: 维护running max和running sum
    - 每处理一个K块，更新max和sum，调整之前的结果

效果:
  - 显存: O(n^2) → O(n)（不存储n×n矩阵）
  - 速度: 2-4x加速（减少HBM读写次数）
  - 长序列: 使128K+的上下文窗口变得可行

FlashAttention-2改进:
  - 更好的并行化(沿序列维度并行)
  - 减少非矩阵乘法操作(充分利用Tensor Core)
  - 比FlashAttention-1再快2x

RoPE核心思想:
  对Q和K的每对连续维度(q_{2i}, q_{2i+1})应用旋转变换:
  [q'_{2i}  ]   [cos(mθ_i)  -sin(mθ_i)] [q_{2i}  ]
  [q'_{2i+1}] = [sin(mθ_i)   cos(mθ_i)] [q_{2i+1}]

  m是位置索引, θ_i = 10000^{-2i/d}

RoPE的关键性质:
  q_m · k_n 仅依赖于(m-n), 而非m和n的绝对值
  → 天然具有相对位置编码特性
  → 注意力分数只取决于两个token的相对距离

为什么常被采用:
  1. 相对位置 → 更好的泛化
  2. 无需额外参数
  3. 可通过调整θ基数实现长度外推:
     原始base=10000 → 调大base=500000(NTK-aware) → 支持更长上下文
  4. 许多近年的公开 LLM 采用或借鉴了这一路线

无KV Cache:
  生成第N个token时，需要重新计算前N-1个token的K、V
  总计算量: 1 + 2 + 3 + ... + N = O(N^2)

有KV Cache:
  首次(Prefill): 计算所有prompt token的K、V，存入缓存
  后续(Decode): 每步只计算新token的Q, 用缓存的K、V计算注意力
  总计算量: N + N + N + ... = O(N) per token

显存占用:
  KV Cache = 2(K和V) × layers × kv_heads × head_dim × seq_len × batch × precision

  Llama-3-70B (80层, 8 KV头, 128维, FP16):
  每个token的KV: 2 × 80 × 8 × 128 × 2B = 327KB
  4096 tokens: 327K × 4096 = 1.3GB
  batch=50: 1.3GB × 50 = 65GB  ← 接近一张A100的显存!

→ KV Cache的显存管理是LLM推理的核心工程挑战
→ PagedAttention/GQA/KV量化都是为了解决这个问题

Prefill阶段:
  输入: 完整的prompt (如1000 tokens)
  计算: 所有token并行计算QKV和注意力 → 填充KV Cache
  特点: 计算密集, GPU利用率高(矩阵乘法大)
  延迟: TTFT(Time To First Token) = Prefill时间

Decode阶段:
  输入: 上一步生成的1个token
  计算: 1个Q与所有K做注意力 → 生成1个token
  特点: 访存密集(读KV Cache大, 计算小)
  延迟: 每token约20-50ms(7B) ~ 100-200ms(70B)

优化方向不同:
  Prefill: Tensor并行、矩阵分块 → 充分利用算力
  Decode:  KV Cache优化、投机解码、批处理 → 提高吞吐量

分离部署(Disaggregated Serving, 前沿趋势):
  Prefill集群(高算力GPU) + Decode集群(高显存/带宽GPU)
  → 各自优化，资源利用率最大化

Post-Norm: output = LayerNorm(x + SubLayer(x))
  - 原始Transformer使用
  - 需要warmup，学习率敏感
  - 最终效果可能稍好(充分训练后)

Pre-Norm:  output = x + SubLayer(LayerNorm(x))
  - 梯度直接通过残差路径传递(不经过LayerNorm)
  - 训练更稳定，不需要warmup
  - 当前多数公开LLM使用这一思路(GPT/Llama/Qwen/Mistral 等)

RMSNorm(更进一步):
  RMSNorm(x) = x / sqrt(mean(x^2) + ε) × γ
  - 去掉了均值中心化，只做缩放
  - 计算量减少，速度更快
  - Llama、Qwen、Mistral、DeepSeek 等公开系列中常能看到 RMSNorm

动机: 预训练权重的变化量(ΔW)通常是低秩的
  - 实验发现: 微调前后权重差ΔW的有效秩远小于维度d
  - 假设: ΔW ≈ BA, 其中B ∈ R^{d×r}, A ∈ R^{r×d}

实现:
  原始: h = Wx
  LoRA: h = Wx + (α/r) × BAx  (α是缩放因子)

  训练时: W冻结, 只训练A和B
  推理时: W' = W + (α/r)BA → 合并后无额外延迟!

参数量对比(Llama-7B, d=4096):
  全参数: 4096 × 4096 = 16.7M (每个线性层)
  LoRA r=16: 4096 × 16 + 16 × 4096 = 131K → 减少128倍!
  全模型: 7B → LoRA约10-50M可训练参数

QLoRA:
  在LoRA基础上:
  1. 基础模型4-bit量化(NF4数据类型)
  2. 双重量化(quantize the quantization constants)
  3. Paged Optimizers(优化器状态offload到CPU)
  → 70B模型在单张A100上微调!

RLHF三阶段:
  Stage 1: SFT(监督微调) → 用高质量数据微调基座模型
  Stage 2: 训练Reward Model
    - 数据: 同一Query下，人工标注哪个回答更好(喜好对)
    - 模型: 输入(Query, Answer) → 输出标量reward分数
  Stage 3: PPO强化学习
    - 策略模型生成回答 → RM打分 → PPO更新策略
    - 同时用KL散度约束，防止偏离SFT模型太远

DPO(Direct Preference Optimization):
  核心洞察: 可以将RM+PPO的目标函数改写为直接对策略的优化

  Loss = -log σ(β × (log π(y_w|x)/π_ref(y_w|x) - log π(y_l|x)/π_ref(y_l|x)))

  y_w: 偏好数据中human preferred的回答
  y_l: 偏好数据中rejected的回答
  π_ref: 参考模型(SFT后的模型)

DPO优势:
  - 不需要训练独立的Reward Model(省一个模型)
  - 不需要PPO采样循环(训练更稳定)
  - 显存需求更低(不需同时加载4个模型)
  - 超参更少，更容易调
  - 近年很多团队会优先评估 DPO 或其变体（ SimPO / ORPO / KTO ），但是否采用仍取决于数据形态和训练目标

假设4个GPU, 每个有数据 [a_i]:

AllReduce (所有人归约，所有人拿完整结果):
  GPU0: [a0] ──┐                   ┌→ [a0+a1+a2+a3]
  GPU1: [a1] ──┤ AllReduce(sum)    ├→ [a0+a1+a2+a3]
  GPU2: [a2] ──┤                   ├→ [a0+a1+a2+a3]
  GPU3: [a3] ──┘                   └→ [a0+a1+a2+a3]
  用途: 数据并行的梯度同步

AllGather (收集所有人的数据):
  GPU0: [a0] ──┐                   ┌→ [a0, a1, a2, a3]
  GPU1: [a1] ──┤ AllGather         ├→ [a0, a1, a2, a3]
  GPU2: [a2] ──┤                   ├→ [a0, a1, a2, a3]
  GPU3: [a3] ──┘                   └→ [a0, a1, a2, a3]
  用途: ZeRO-3前向时收集参数

ReduceScatter (归约后分片):
  GPU0: [a0,b0,c0,d0] ──┐                   ┌→ [Σa] (只拿第1片)
  GPU1: [a1,b1,c1,d1] ──┤ ReduceScatter     ├→ [Σb] (只拿第2片)
  GPU2: [a2,b2,c2,d2] ──┤                   ├→ [Σc] (只拿第3片)
  GPU3: [a3,b3,c3,d3] ──┘                   └→ [Σd] (只拿第4片)
  用途: ZeRO梯度分片

关系: AllReduce = ReduceScatter + AllGather

场景: 想要batch_size=256, 但GPU只能放batch_size=8

做法:
  for i in range(32):  # accumulation_steps = 256/8 = 32
      loss = model(batch_i) / 32  # 缩放loss
      loss.backward()  # 梯度累积到.grad
  optimizer.step()  # 用累积的梯度更新
  optimizer.zero_grad()

注意事项:
  - Loss除以accumulation_steps(平均梯度)
  - 与DDP结合: 只在最后一步做AllReduce(节省通信)
  - BatchNorm需要特殊处理(统计量不准确) → LLM用LayerNorm无此问题
  - 学习率调度: 以"有效batch"计算warmup步数

后训练量化(PTQ) vs 量化感知训练(QAT):
  PTQ: 模型训练好后直接量化, 无需重训, 方便
  QAT: 训练过程中考虑量化误差, 精度更好, 成本高

GPTQ(GPT Quantization):
  - 基于OBQ(Optimal Brain Quantizer)思想
  - 逐层量化: 用一小批校准数据估计Hessian矩阵
  - 量化一个权重后, 调整同层其他权重补偿误差
  - 3-4bit精度与FP16几乎无损
  - 速度: 量化过程较慢(需校准数据), 推理快

AWQ(Activation-aware Weight Quantization):
  - 核心观察: 只有约1%的"显著"权重通道对精度影响大
  - 通过观察激活值, 找到重要通道, 给予更高精度
  - 对重要通道的权重做per-channel scaling后再量化
  - 速度: 量化过程更快, 推理效率高
  - 比GPTQ更适合大规模部署

选择:
  精度优先 → GPTQ (比如用于生成高质量文本)
  速度/易用优先 → AWQ (比如用于高吞吐在线服务)
  极致压缩 → GGUF/GGML (llama.cpp生态, CPU推理)

vLLM关键优化:

1. PagedAttention:
   KV Cache按Block分配(不预分配连续内存)
   → 显存利用率常有明显提升
   → 在合适负载下，并发能力可能提升数倍

2. Continuous Batching:
   短请求完成后空位立即被新请求填入
   → 相比Static Batching, 吞吐提升2-3倍

3. Prefix Caching:
   多个请求共享相同前缀(System Prompt)的KV Cache
   → 长System Prompt场景下常能明显减少重复 Prefill 开销

4. Tensor Parallelism:
   模型切分到多张GPU, 支持大模型推理
   单机8卡推理70B模型

5. Speculative Decoding(投机解码):
   小模型草拟 + 大模型验证
   → 2-3x加速

6. Chunked Prefill:
   长Prompt分块Prefill, 中间插入Decode步骤
   → 避免长Prompt阻塞其他请求

使用:
  pip install vllm
  vllm serve meta-llama/Llama-3-8B --dtype auto --max-model-len 8192

原理（以 vLLM Automatic Prefix Caching 为例）：

  内部数据结构：Radix Tree（基数树）
  每个节点 = 一个 Block（16 个连续 token 的 KV Cache）
  节点 ID = SHA256(token_ids in block)

  请求来临时：
  1. 将 prompt 按 Block 大小切分
  2. 从树根开始，逐 Block 匹配（Hash 精确匹配）
  3. 命中的 Block → 直接从显存读取，无需重新计算
  4. 未命中的 Block → 正常 Prefill，计算后存入 Radix Tree
  5. 淘汰策略：LRU（最近最少使用）

  粒度约束：
  最后一个不满 Block 的 token 无法命中
  例如 Block Size=16，Prefix=1537 tokens → 实际命中 1536 tokens

缓存命中率公式：
  Token 命中率 = 命中 token 数 / 总 Prefill token 数
  TTFT 降低比 ≈ 命中率 × (System Prompt 占 Prompt 的比例)

示意性收益（高命中场景）：
  如果固定前缀占 Prompt 的绝大部分，那么命中缓存后，
  TTFT 和 Prefill 算力消耗都可能显著下降；
  但真实收益会受模型、框架版本、块大小、并发和前缀稳定度共同影响。

最大化命中率的工程策略：

  ① 结构布局：固定内容前置
     ✅ [System Prompt（固定）][Few-shot（固定）][用户输入（变化）]
     ❌ [时间戳][用户输入][System Prompt]  ← 前缀每次变化，命中率=0

  ② 格式规范化
     - 统一空白符、标点、大小写
     - 禁止在 System Prompt 中插入 request_id / trace_id / 时间戳
     - 个性化内容放到用户输入侧，不放 System Prompt

  ③ 缓存预热（如 FastAPI/vLLM 启动钩子）
     @app.on_event("startup")
     async def warm_up():
         llm.generate([build_warmup_prompt()], SamplingParams(max_tokens=1))
     → 第一批真实请求直接命中，消除冷启动延迟

  ④ 多轮对话：历史仅追加，不修改
     - 正确：每轮在末尾 append 新消息
     - 错误：每轮重排/摘要历史（导致所有 Block Hash 失效）

  ⑤ RAG 场景优化
     两段式布局：[固定 System Prompt][Query][检索结果]
     → System Prompt 这部分仍有机会命中
     同文档批量问答：[System Prompt][文档内容][Problem 1/2/3...]
     → 文档 Block 全部命中

API 侧（调用商业 API 时的缓存命中）：
  不同商业 API 可能提供显式或隐式的前缀缓存/上下文缓存能力；
  计费、命中规则和是否开放控制接口都可能变化，
  因此需要以对应厂商官方文档为准。
  → 核心原则相同：尽量保持 Prompt 前缀稳定不变

监控指标与告警阈值：
  指标名                  | 告警阈值（按场景）
  ─────────────────────────────────────────
  Token 级命中率          | 固定 System Prompt < 70% 告警
  请求级命中率            | 多轮对话 < 50% 告警
  TTFT P95               | 超过无缓存基线 80% 告警
  缓存 Block 淘汰频率     | 过高 → 考虑增大显存或缩短 Prompt

常见踩坑：
  Q：为何开启 APC 后命中率仍接近 0？
  A1：System Prompt 中含随机 UUID / 时间戳 → 移除
  A2：Prompt 模板格式不一致（多处拼接代码格式化差异）→ 统一格式化函数
  A3：Block Size 对齐问题（Prefix 恰好是奇数 token）→ 在 System Prompt 末尾填充空白至 Block 倍数

架构:
  标准Transformer FFN: 所有token经过同一个FFN(全部参数激活)
  MoE Transformer: FFN替换为N个Expert + Gate

  Gate(x) → 选择Top-K个Expert → 加权求和Expert输出

  例: 某些公开 MoE 模型会配置数百个 Expert，并在每次前向时只激活其中少数几个
  总参数远大于单次激活参数

优势:
  - 推理时只激活部分参数 → 推理成本接近37B模型
  - 但模型容量等效671B → 效果接近超大密集模型
  - 训练效率也更高(MoE可以更好地利用数据并行)

挑战:
  - 负载均衡: 某些Expert被选中太多, 其他空闲
    → 辅助Loss鼓励均匀分配
  - 通信开销: Expert分布在不同GPU, token需跨卡路由
    → 专家并行(EP)策略
  - 显存: 总参数大(所有Expert都需加载)
    → 往往需要集群部署, 端侧部署难度较高

ReAct (Prompt方式):
  优点: 通用, 任何LLM都能用, 推理过程透明(有Thought)
  缺点: 依赖Prompt格式, 解析不稳定, 容易格式错误

Function Calling (模型原生):
  优点: 模型经过对齐训练, 输出结构化JSON, 可靠
  缺点: 不是所有模型支持, 不同模型格式不同

MCP (Model Context Protocol):
  优点: 标准化协议, 工具生态互通, 一次接入到处可用
  缺点: 协议开销, 需要MCP Server

实践选择:
  - 原型阶段: ReAct(快速验证)
  - 工程上常见选择: Function Calling(结构更稳) + MCP(便于生态接入)
  - 复杂系统: 多Agent框架(LangGraph/AutoGen)

Prompt Engineering(2023-2025重点):
  - 编写更好的指令(few-shot, CoT, 角色设定)
  - 关注"怎么说"

Context Engineering（近年工程实践中的重点）:
  - 管理整个上下文窗口的信息流
  - 关注"该让模型看到什么"

  核心技能:
  1. 信息选择: 从海量信息中筛选最相关的放入上下文
  2. 信息排序: 利用LLM对位置的敏感性(重要信息放开头/结尾)
  3. Token预算管理: 上下文窗口有限, 如何分配给指令/检索结果/对话历史
  4. 动态上下文: 根据对话进展动态更新上下文(加入新检索/工具结果)
  5. 跨轮上下文: 长对话中如何压缩/摘要历史保留关键信息

面试考法:
  "你的Agent系统上下文窗口8K, 单次要放系统Prompt(2K)+检索结果(3K)+对话历史(2K)+用户输入(1K), 但检索结果经常超出3K该怎么办?"
  回答要点: 检索结果压缩/摘要, 对话历史滑动窗口+关键信息提取, Token预算动态分配

问题:
  256个Expert分布在64张GPU上(每卡4个Expert)
  每个token路由到8个Expert → 高概率需要跨卡通信

  All-to-All通信: 每张卡把token发给需要的目标卡, 并接收其他卡的token
  通信量 ∝ batch_size × hidden_dim × 跨卡Expert占比

优化:
  1. 细粒度Expert并行: Expert分布考虑负载均衡
  2. DeepSeek-MoE: 部分shared Expert保证基础能力, 减少路由通信
  3. Expert冗余: 热门Expert在多卡上复制
  4. 混合并行: TP(机内) + EP(跨机)

SSM核心:
  将序列建模为连续状态空间方程的离散化:
  h_t = Ah_{t-1} + Bx_t    (状态更新)
  y_t = Ch_t               (输出)

  关键: A、B可以卷积化 → O(n log n)训练

Mamba改进:
  让B、C、Δ依赖于输入(input-dependent) → 选择性SSM
  → 能根据内容选择性地记忆或忘记信息

Transformer vs Mamba:
  Transformer:  训练O(n^2), 推理O(n)per step(有KV Cache)
  Mamba:        训练O(n),   推理O(1)per step(固定状态)

  Mamba推理时不需要KV Cache! → 显存固定, 超长序列更友好

按 2026-04 的公开样本观察：
  Mamba-2、Jamba 等混合架构会把 Transformer 层和 SSM 层结合起来
  纯 Mamba 在部分需要精确回溯的任务上仍可能弱于 Transformer
  可以把混合架构理解为值得持续关注的候选方向，而不是已经确定的唯一未来路线