响应速度与推理精度的 tradeoff

1️⃣ 考察意图

面试官想考察你是否真正理解 LLM 推理的工程本质——不是背论文，而是能在延迟和准确率之间做量化决策。这是典型的系统设计 + 工程取舍题，刁钻点在于：候选人容易空谈“平衡”，但说不出具体在哪一层、用什么方法、牺牲多少精度换多少速度。答好了能展示你对推理整条链路（Prefill/Decode、KV Cache、量化、投机解码）的掌控力，以及面对业务指标（如 P99 延迟 vs. BLEU 分数）时的决策框架。

2️⃣ 标准答

核心原则：没有免费的午餐，每个加速手段都对应精度损失或工程复杂度增加。下面按推理阶段拆解取舍点。

Prefill 阶段（计算密集型）
FlashAttention：用 tiling 和 online softmax 把显存带宽瓶颈转为计算瓶颈，精度无损（FP16 下等价于标准 Attention）。取舍：需要 CUDA 编程支持，对长序列（>8K）收益显著，短序列（<512）收益有限。
稀疏 Attention（如 Longformer/BigBird）：用滑动窗口 + 全局 token 替代全连接，速度提升 2-5 倍，但长程依赖建模能力下降。坑：在文档级 QA 任务中，召回率可能掉 10-15%，必须用下游 reranker 兜底。
Decode 阶段（内存带宽密集型）
KV Cache 量化：从 FP16 到 INT8 或 NF4，显存占用减半，带宽压力降低 40%。取舍：INT8 量化后，长序列（>4K）的 PPL 可能上升 0.3-0.5，但通过 per-token 动态缩放（如 SmoothQuant）可控制在 0.1 以内。实际落地：在 7B 模型上，KV Cache INT8 让 batch size 翻倍，吞吐提升 1.8x，但需要校准集避免 outlier 导致精度崩盘。
投机解码（Speculative Decoding）：用小模型（如 125M）草稿 + 大模型（7B）验证，加速比 2-3x。取舍：草稿模型精度不够时，拒绝率升高，实际加速比退化到 1.2x。解法：用目标模型的 logits 蒸馏训练草稿模型，或使用 Medusa 多头预测（无需额外训练）。坑：在代码生成任务中，草稿模型容易生成语法错误，导致验证阶段频繁回退，反而增加延迟。
模型结构层面
MoE（Mixture of Experts）：如 Mixtral 8x7B，每次只激活 2 个 expert，推理速度接近 7B 但精度接近 70B。取舍：显存占用大（需加载全部 expert），且 expert 负载不均衡时，部分 token 等待时间长。解法：用 expert 路由的 top-2 概率做负载均衡 loss，训练时加入辅助 loss。
量化（Weight-only）：GPTQ（4-bit）或 AWQ（4-bit），模型体积缩小 4x，推理速度提升 2-3x。取舍：4-bit 量化后，在数学推理（GSM8K）上准确率可能掉 2-5%，但通过 group-size=128 和 per-channel 缩放可恢复大部分。实际坑：某些算子（如 SiLU）在 INT4 下没有高效实现，需要 fallback 到 FP16，导致加速比打折。
系统级优化
Continuous Batching：vLLM 或 TensorRT-LLM 的核心，把请求动态拼接到一个 batch，GPU 利用率从 30% 提升到 90%。取舍：需要管理 pending queue 和 preemption，内存碎片化严重时，P99 延迟抖动大。解法：用 PagedAttention 管理 KV Cache 块，避免碎片。
Prompt 压缩：如 LLMLingua 或 Selective Context，把长 prompt 压缩到 20% 长度，速度提升 5x。取舍：压缩后关键信息丢失，在 RAG 场景中，答案准确率可能掉 10%。解法：只压缩无关段落，保留 query 和 top-3 检索结果原文。

总结：在业务中，先确定延迟 SLA（如 P99 < 500ms），然后从最便宜的优化开始：Continuous Batching → KV Cache INT8 → Weight INT4 → Speculative Decoding。每步都做 A/B 测试，量化精度损失，如果超过阈值（如准确率掉 > 3%），则回退或加 reranker 补偿。

3️⃣ 答题模板（30 秒电梯版）

“这个问题我从三个层面回答：第一，Prefill 阶段用 FlashAttention 和稀疏 Attention，速度提升但长程依赖有损；第二，Decode 阶段用 KV Cache 量化和投机解码，显存换吞吐，但需要校准集和草稿模型；第三，模型结构上 MoE 和量化是性价比最高的方案，但要注意负载均衡和算子兼容。总结一句：没有银弹，必须根据延迟 SLA 和精度阈值，从 Continuous Batching 开始逐层优化，每步做 A/B 测试。”

4️⃣ 高频追问 & 应对

追问 1：你说投机解码能加速 2-3x，那如果草稿模型和目标模型分布差异很大怎么办？

这是常见坑。差异大时拒绝率高，加速比可能降到 1.2x 甚至负收益。解法：一是用目标模型的 logits 做蒸馏训练草稿模型，让分布对齐；二是用 Medusa 的树状解码，同时预测多个候选 token，减少验证次数。实践中，在代码生成任务里，草稿模型用 125M 的 CodeGen，目标用 7B 的 StarCoder，加速比稳定在 2x 左右。

追问 2：量化到 INT4 后，模型在数学推理上掉点，你怎么恢复？

用 group-size=128 的 per-channel 量化，比 per-tensor 量化精度高 1-2%。另外，在推理时用动态激活量化（如 SmoothQuant 的 per-token 缩放），把 outlier 的 FP16 部分保留。如果还掉点，就只量化 attention 层，保留 FFN 层为 FP16，牺牲 20% 的加速比换回精度。最后，在 GSM8K 上做校准集微调，把量化误差纳入训练。

追问 3：Continuous Batching 里，如果请求长度差异很大（比如 100 token 和 10K token），怎么避免长请求拖慢短请求？

用 vLLM 的 PagedAttention 和 preemption 机制：长请求的 KV Cache 分块管理，当 GPU 内存不足时，把长请求的块 swap 到 CPU，优先处理短请求。但 swap 本身有延迟，所以需要设置 max_num_seqs 限制并发数。更激进的做法是：把长请求拆成多个子请求，用并行解码，但需要保证上下文连续性。

5️⃣ 避坑 · 常见错误答法

❌ “响应速度和精度是矛盾的，只能二选一。” → ✅ “每个加速手段都有具体 trade-off，比如 KV Cache INT8 损失 0.1 PPL 但吞吐翻倍，可以通过校准集和 per-token 缩放控制损失。”
❌ “用更小的模型（如 7B 代替 70B）就能解决。” → ✅ “模型大小只是维度之一，更关键的是推理阶段优化：Prefill 用 FlashAttention，Decode 用投机解码，系统用 Continuous Batching，这些组合起来能比单纯换小模型效果好 3-5 倍。”
❌ “量化会损失精度，所以不用。” → ✅ “量化是性价比最高的加速手段，4-bit 量化在大多数任务上损失 < 2%，但速度提升 3-4x。关键是用 group-size 和动态缩放控制 outlier，而不是一刀切。”

6️⃣ 简历呼应

如果你有 LLM 推理部署项目：从实际延迟指标切入，比如“我在部署 13B 模型时，P99 延迟从 2s 降到 500ms，用了 KV Cache INT8 + Continuous Batching，精度损失 0.3%”。
如果你只做过传统 ML 推理：用类比迁移，比如“传统模型用 ONNX 量化，LLM 类似但多了 KV Cache 和 Attention 的复杂度，我理解 FlashAttention 本质是 tiling 优化”。
如果你是校招无项目：聚焦论文复现，比如“我复现了 Medusa 投机解码，在 7B 模型上加速 2.5x，并分析了草稿模型大小对拒绝率的影响”。

7️⃣ 延伸阅读

FlashAttention: Fast and Memory-Efficient Exact Attention with IO-Awareness (Dao et al., 2022)
SmoothQuant: Accurate and Efficient Post-Training Quantization for Large Language Models (Xiao et al., 2023)
Medusa: Simple LLM Inference Acceleration Framework with Multiple Decoding Heads (Cai et al., 2024)
vLLM: Efficient Memory Management for Large Language Model Serving with PagedAttention (Kwon et al., 2023)
Speculative Decoding: Fast Inference from Autoregressive Models (Leviathan et al., 2023)

—— 本场面试完 ——