跳到主要内容

LLM 推理面试文档审查报告

审查对象：InferenceOptimization.md

目标：判断题目问得好不好、答案是否足够标准，并补齐文档里缺失但高频的 LLM 推理面试问题。

一句话结论​

原文适合作为 “推理优化概念速记”，但如果把它当成 “LLM 推理面试问答文档”，覆盖面还不够完整，少数答案也需要去掉过于绝对的表述。优点是直观、类比好懂；不足是缺少指标视角、追问视角和几道真正高频的系统题。

审查标准​

我按下面四条来判断是否“标准”：

维度标准
题目质量是否真的是高频面试题，能否引出原理、瓶颈和 trade-off
答案准确性定义是否准确，是否有明显错误或过度绝对化
面试可用性是否能在 30-90 秒内清楚说出来
用户可读性是否容易扫读，结构是否统一，重点是否清楚

总体评价​

项目评价说明
题目选择良好现有 6 题都属于面试会问的核心主题，但覆盖面偏窄
答案标准度良好偏上大方向正确，但个别说法过满，缺少条件限定
可读性良好图示直观，适合入门；但缺少统一答题模板
文档结构可用但不够标准原版更像知识笔记，不完全像“面试答案库”

逐题审查​

题目评价主要问题结论
Continuous Batching问得好原答案强调吞吐，但没明确说不一定改善 TTFT保留，答案已修订
PagedAttention问得好原答案里“<4% 浪费”“3-4 倍并发”过于绝对保留，改成更稳妥表述
PD 分离问得好原答案没有明确点出网络传输成本保留，补充架构代价
Speculative Decoding问得好“只适合低 batch”太绝对保留，改成看 acceptance rate 和系统余量
量化策略非常好原答案缺少 INT8 这一工业界常见档位；6.7B 说法过死保留，修订为更标准版本
算子融合问得好原答案中 launch overhead 单位不严谨保留，修正为微秒级并补 profiling 视角

当前文档缺失的高频问题​

下面这些题在 LLM 推理面试里非常常见，但原文没有覆盖，建议补上。

1. 什么是 Prefill，什么是 Decode？两者为什么优化手段不同？​

标准回答：

Prefill 是把整段输入 prompt 一次性送进模型，计算出各层的 KV Cache；Decode 是后续逐 token 生成，每一步只输入最新 token，但要读取历史 KV。两者优化手段不同，是因为 Prefill 往往更偏 compute-bound，适合用更大的 batch、FlashAttention、Tensor Core kernel 去吃满算力；而 Decode 更偏 memory-bound，重点是减小权重和 KV 的访存压力，比如量化、PagedAttention、continuous batching、speculative decoding。

2. TTFT、TPOT 和 Throughput 分别是什么？为什么不能只看 tokens/s？​

标准回答：

TTFT 是请求进来到首 token 出来的时间，TPOT 是后续每个 token 的平均生成时间，Throughput 是系统单位时间处理的请求数或 token 数。不能只看 tokens/s，因为吞吐高不代表单用户体验好；在线服务里，TTFT、TPOT、P95/P99 延迟往往比峰值吞吐更重要。

3. 为什么 KV Cache 是推理优化核心？​

标准回答：

因为自回归生成每出一个新 token，都要依赖前面所有 token 的 K/V。如果不缓存，每一步都要重算整段上下文，计算量会非常大；缓存以后算力压力下降了，但显存容量和带宽成了新瓶颈。所以很多推理优化，本质上都是围绕 KV Cache 的存储、调度和压缩在做文章。

4. Prefix Caching 是什么？它主要优化什么指标？​

标准回答：

Prefix Caching 是多个请求拥有相同前缀时，直接复用已有前缀 KV，而不是每次都重新做 Prefill。它最直接优化的是 TTFT，因为省掉了重复前缀的 Prefill 计算；在系统提示词固定、RAG 模板固定或多轮对话前缀复用高的场景里收益明显。缺点是命中率高度依赖 workload，还要处理 cache 隔离和管理成本。

5. 为什么 GQA / MQA 对推理更友好？​

标准回答：

因为 Decode 的热点通常是读 KV，而不是做大规模矩阵计算。GQA 和 MQA 通过减少 K/V head 数量，直接降低了 KV Cache 的体积和带宽压力，所以对长上下文和高并发推理尤其友好。代价是模型表达能力可能略受影响，需要在效果和系统效率之间平衡。

6. Chunked Prefill 解决什么问题？​

标准回答：

Chunked Prefill 把很长的 prompt 切成多个小块分步执行，而不是让一个超长请求一次性独占 GPU 很久。它的核心价值不是让单个请求绝对更快，而是改善混合流量下的尾延迟和公平性，避免长 prompt 把 decode 阶段卡住。

7. vLLM 和 TensorRT-LLM 该怎么比较？​

标准回答：

vLLM 更适合做通用、高性能、快速迭代的开源 serving，优势是 PagedAttention、continuous batching、生态使用广；TensorRT-LLM 更适合 NVIDIA 生态下追求极致性能和更深硬件绑定的场景，优势是强 kernel、强量化和完整工具链。面试里不要说谁绝对更好，而要说要根据硬件、模型类型、部署复杂度和团队经验做选型。

8. Profiling 时怎么判断瓶颈是算力、带宽还是通信？​

标准回答：

先看时间线和热点算子，再看带宽和 SM 利用率。如果 SM 很忙、算子算得久但带宽没打满，通常更偏 compute-bound；如果 HBM 带宽接近打满而算力利用一般，通常更偏 memory-bound；如果 timeline 上大量时间卡在 NCCL 或等待对端数据，就是 communication-bound。只有先分清瓶颈，优化方向才不会跑偏。

文件结构审查​

当前结构的优点​

  • Docs/ 按主题拆分，入口清楚
  • InferenceOptimization.md 适合做概念理解
  • QuickInterviewAnswers.md 适合做口语背诵

当前结构的问题​

  • 两份文档都包含“面试内容”，但定位边界不够清楚
  • InferenceOptimization.md 原版更像知识讲义，不像标准问答库
  • 缺少一份“审查与补充”视角的文档，用户不容易知道哪些说法更稳妥

更标准的结构建议​

一个更清晰的推理面试文档结构通常是：

  1. 文档定位：这是知识讲义还是面试答案库
  2. 核心指标：TTFT、TPOT、Throughput、Accuracy
  3. 高频问题：每题给 30-90 秒标准回答
  4. 追问点：面试官常见 follow-up
  5. 延伸阅读：指向更细的专题文档

本次已处理的内容​

  • 已修订 InferenceOptimization.md 中不够严谨或过于绝对的表述
  • 已补充该文档缺失的 8 道高频 LLM 推理面试题标准答案
  • 已把这份审查报告加入 Docs/，便于后续继续迭代

如果你希望，我下一步可以继续把这份审查报告里的“新增 8 题”直接并入 QuickInterviewAnswers.md，把整套推理面试题库合并得更完整。