AI Knowledge

外观

LLM 推理与服务优化专项面试题 ​

目录 ​

1. 使用说明 ​

  • 对应知识主题：LLM 推理与服务优化；
  • 角色：资深面试官从自回归生成追问到多租户服务，高级技术应聘者负责连接张量、显存、调度与质量；
  • 回答顺序：先给 1～3 句专业短答，再用生活化解释；性能结论必须限定模型、硬件、长度、并发和精度；

事实红线｜ KV Cache 不会让每步 Attention 变成 O(1)，量化和批处理也没有脱离硬件与负载的固定加速倍数；

  • 题目数量：7 题，严格覆盖 L1～L7。

阅读图例｜ L1～L2 概念与边界 · L3～L4 原理与实现 · L5 工程 · L6 架构 · L7 项目复盘

答案层级｜ 必答结论 · 小白解释 · 加分项 · 高频误区 · 下一问

2. 递进路线 ​

图：LLM 推理与服务优化 L1～L7 递进路线

替代文本： L1 自回归推理与服务指标 → L2 解码策略 → L3 Prefill/Decode 与 KV 张量 → L4 KV 显存和复杂度 → L5 Continuous Batching/Paged KV → L6 量化、准入和降级 → L7 示例网关复盘。

图表加载中…

读图结论： 蓝色阶段建立概念与边界，紫色阶段进入原理与实现，橙色和青色阶段验证工程与架构能力，绿色阶段用项目证据完成复盘。

题链先把一次生成拆成阶段，再分析采样和缓存，随后进入动态调度、内存管理、质量回归和故障恢复，最终形成生产服务方案。

图：Prefill、KV Cache、循环 Decode 与连续批处理的协作关系

替代文本： 新请求和活跃请求在每个迭代边界由连续批调度器动态加入或移除；新 Prompt 先经过 Prefill 并行计算并写入各层 KV Cache，活跃序列随后每轮 Decode 一个 Token，读取全部历史缓存并追加新 K/V，直到 EOS、长度、取消或超时后释放缓存。

图表加载中…

读图结论： Prefill 为 Prompt 建立缓存，Decode 逐步复用并扩展缓存；连续批处理通过迭代级动态组批提高利用率，但每个新 Query 仍需读取历史 K/V，缓存成本会随长度和并发增长。

这张图把“模型阶段”和“服务调度”放在同一条链上：TTFT 主要受排队与 Prefill 等首 Token 前阶段影响，ITL 则更直接反映 Decode、调度和流式链路。连续批处理并不消除显存或公平性约束，因此新请求准入、长短请求混排、取消释放和 Token/KV 预算仍需单独治理。

3. 一问一答 ​

第 1 题｜L1 概念｜LLM 推理为什么要区分 Prefill、Decode 和流式返回？ ​

核心考察点｜自回归阶段和用户可感知指标

面试官提问

请从请求进入到结束说明完整链路，并定义 TTFT 与 ITL。

30 秒专业短答

文本先 Tokenize，Prefill 并行处理完整 Prompt 并建立各层 KV Cache，Decode 再逐 Token 生成并追加缓存，Detokenize/Stream 将新 Token 增量返回。首个可见 Token 前的时间是 TTFT，后续相邻 Token 的延迟常用 ITL/TPOT 描述，端到端时间还受输出长度和停止条件影响。

小白解释

餐厅先一次读完整张菜单和备注并备好食材，这是 Prefill；之后一道一道出菜是 Decode；第一道菜等多久像 TTFT，后续每道菜间隔多久像 ITL，整桌吃完时间还取决于总菜数。

  • 合格线｜ Tokenization、Prefill、Decode、Stream 及 TTFT/ITL 区分正确；
  • 加分项｜ 指出 TTFT 包含排队、Tokenize、Prefill、首步采样与网络，并应看 P50/P95/P99 和长度切片；
  • 高频误区｜ 认为模型一次前向就产生完整文本，或把流式输出等同总耗时下降；
  • 下一问｜ 阶段清楚后，继续看每个 Decode 步如何从概率分布选择下一个 Token。

第 2 题｜L2 边界｜Greedy、Temperature、Top-k 和 Top-p 怎样影响生成？ ​

核心考察点｜解码策略、概率过滤与事实边界

面试官提问

它们能否提高事实正确性？为什么 temperature=0 需要特殊处理？

30 秒专业短答

Greedy 每步选择最大 Logit；Temperature 用 softmax(z/T) 调整分布尖锐度；Top-k 只保留最高的 k 个候选，Top-p 取累计概率达到阈值的最小候选前缀后重归一化。采样只改变已有分布，不能补充缺失事实；工程 API 常把零温实现为 Greedy 特例，不能直接除以 0。

小白解释

Greedy 每次选当前评分最高的词，Temperature 调整“敢不敢选次优”，Top-k 只看前几名，Top-p 根据当次概率决定保留多少候选；它们改变选择风格，不会凭空给厨师增加没见过的菜谱。

  • 合格线｜ 四种策略作用正确，说明重归一化与零温分支；
  • 加分项｜ 指出 Beam Search、重复惩罚和停止序列有不同目标，参数组合语义依框架版本需测试；
  • 高频误区｜ 认为 Temperature 越低越准确，或固定 Seed 可跨硬件/内核绝对复现；
  • 下一问｜ 采样发生在每个 Decode 步，下一步分析 Prefill 与 Decode 的 Q/K/V 和 Cache 形状。

第 3 题｜L3 原理｜Prefill 与 Decode 的计算和 KV 张量有何不同？ ​

核心考察点｜推理阶段、张量形状和 KV 头共享

面试官提问

给出第 t 步 Query 与缓存 K/V 的典型形状，并说明 MHA、GQA、MQA 的差异。

30 秒专业短答

Prefill 对完整 Prompt 做并行前向并写入各层 K/V；Decode 第 t 步只输入新 Token，Query 形如 [B,h_q,1,d_h]，缓存 K/V 各为 [B,h_kv,t,d_h]，新 K/V 再追加一个位置。MHA 通常 h_kv=h_q，GQA 让一组 Query 头共享 K/V，MQA 常令 h_kv=1，因此后二者能减少 Cache 和带宽。

小白解释

Prefill 像第一次把整本资料读完并做索引卡，之后每写一个新词只新增一张卡，但仍要翻看历史卡片；GQA/MQA 像多个读者共享一部分或一套索引卡，减少重复存储。

  • 合格线｜ Prefill 全 Prompt、Decode 单 Token、Cache 追加和三类头关系正确；
  • 加分项｜ 说明 KV 头数是模型训练/架构属性，不能在服务侧任意把已有 MHA 权重改成 MQA；
  • 高频误区｜ 认为 Decode 不再读取历史，或把 Q 当作主要历史 Cache；
  • 下一问｜ 形状明确后，继续计算 KV 显存并解释 Cache 为什么省计算但不免费。

第 4 题｜L4 实现｜KV Cache 显存如何估算，它改变了什么复杂度？ ​

核心考察点｜显存容量、复杂度边界和缓存收益

面试官提问

请给出理论字节公式，并反驳“KV Cache 让每步 O(1)”这一说法。

30 秒专业短答

忽略元数据、对齐和碎片，KV 理论字节约为 2×L×B×h_kv×t×d_h×s，其中 2 表示 K/V，s 是每元素字节数。KV Cache 保存每层历史 K/V，使后续步骤无需把全部历史 Token 重新跑过各层的 Attention、投影和 FFN；但当前新 Token 仍要执行自身的投影与 FFN，并用新 Query 读取全部历史 K/V。初始 Prompt 长度为 P、生成 T 个 Token 时，单层 Decode Attention 累计约为 O((PT+T²)d)，全部 L 层为 O(L(PT+T²)d)；稠密投影与 FFN 还包含约 O(LT(d²+d·d_ff)) 的新 Token 计算。因此 Cache 用显存换掉历史前缀重算，但每步并非 O(1)。

小白解释

把过去的笔记保存下来确实不用每次重新抄，但写新结论时仍要翻阅越来越长的历史笔记；时间省在“不重抄”，代价是笔记越积越多、每次查阅范围也在增长。

  • 合格线｜ 公式变量完整，说明 Cache 省历史 Token 的整段前向重算，但不省当前 Token 计算和持续增长的历史 K/V 读取；
  • 加分项｜ 补充 Prefill 的上下文平方项、权重/激活/工作区、分配器碎片以及并发水位；
  • 高频误区｜ 只按参数量估算服务显存，或声称 KV Cache 使 Attention 成为 O(1)；
  • 下一问｜ 动态长度和并发会让连续预留浪费，因此下一步进入 Paged KV 与连续批处理。

第 5 题｜L5 工程｜Continuous Batching 与 Paged KV 分别解决什么问题？ ​

核心考察点｜动态调度、内存管理、吞吐与尾延迟

面试官提问

为什么它们能提高利用率，却可能让 P99 或公平性变差？

30 秒专业短答

Continuous Batching 在迭代边界移除完成请求、加入新请求，以动态批次摊薄权重读取并提高设备利用率；Paged KV 把逻辑连续 Cache 映射到固定大小物理块，减少连续预留与碎片。调度等待、大 Prompt 阻塞 Decode、块管理、抢占和租户公平都会影响 TTFT/ITL 尾延迟，因此吞吐提升不等于单请求更快。

小白解释

连续批处理像公交每站上下乘客，不必等整车人都到终点；分页存储像把行李放进可分配的小柜子。但大件行李和插队规则仍可能让短途乘客等更久，柜子调度也有管理成本。

  • 合格线｜ 两者职责分开，说明吞吐、排队、长短请求和碎片；
  • 加分项｜ 提出 Prefill/Decode 隔离或分块、长度感知、公平队列、取消释放和按长度/租户切片的 P99；
  • 高频误区｜ 把 Paged KV 当数学近似 Attention，或只看 GPU 利用率判断用户体验；
  • 下一问｜ 调度和内存解决后，还要管理量化质量、准入预算、过载和失败恢复。

第 6 题｜L6 架构｜如何设计量化、准入和降级一体化的推理服务？ ​

核心考察点｜性能—质量联合决策、容量保护和可靠性

面试官提问

量化为什么不保证固定倍数加速？服务又应怎样避免 OOM、重试风暴和跨版本 Cache 污染？

30 秒专业短答

权重、激活或 KV 量化能降低位宽与部分容量/带宽，但实际速度取决于硬件内核、反量化、batch 和瓶颈位置，必须用固定质量集与目标硬件实测。入口按实际 Token、最大输出、模型/Adapter 和 KV 水位准入，过载时有界排队、限流或降级；断连传播取消，流式后重试使用幂等与明确状态。请求内 Paged KV 由 Run/Sequence ID、块表和生命周期管理，不依赖内容语义命中；只有跨请求复用的 Prefix Cache 才需要严格 Cache Key，至少绑定租户或安全域、模型权重、Adapter、Tokenizer、模板、精确 Token ID、位置/RoPE 语义、KV dtype/layout 和 Cache 配置，任一影响 Logit 的字段变化都必须失效。

小白解释

把货物压缩得更小不代表运输一定快四倍，因为还要看车辆是否支持这种包装、拆包成本和道路瓶颈；仓库也要先估算空间，满了就限流或换小货车，不能让所有订单挤爆系统。

  • 合格线｜ 量化收益依硬件与负载；Token/KV 准入；有界队列、取消、版本 Cache 和回滚；
  • 加分项｜ 区分 Weight-only、Activation、KV 量化，按事实/格式/安全/长上下文切片回归，并记录 degraded 结果；
  • 高频误区｜ 声称 INT4 固定快四倍，流断后无条件重试，或 Cache Key 漏掉 Adapter/模板/位置语义；
  • 下一问｜ 最后将这些机制放进源文档中的多租户 LLM Gateway 示例。

第 7 题｜L7 项目复盘｜如何设计多租户企业 LLM Gateway？ ​

核心考察点｜服务分层、调度、资源生命周期、观测和证据纪律

面试官提问

请讲清交互与离线流量、KV 生命周期、计费幂等、监控和未验证边界。

30 秒专业短答

这是源文档中的示例项目：网关负责鉴权、租户限流、请求幂等键和 Token/KV 预算，调度器区分交互与离线负载并执行 Continuous Batching，Worker 绑定模型、量化、Adapter 和 Tokenizer 制品。每个 Run 记录 queued → prefill → streaming → completed/failed/cancelled → billed 状态与流式事件序号；首个片段发出后不盲目重跑，而是按 Run ID 查询状态、返回已持久化结果，或在协议支持时从事件序号续传。计费账本以租户、业务幂等键和计费类型建立唯一约束，取消和异常退出必须释放并对账 KV 块；Trace 记录队列、TTFT、ITL、Token、显存、事件序号与结束原因。仓库没有运行服务或压测，不能声称吞吐、延迟、成本或加速倍数。

小白解释

像共享物流中心：先检查客户额度和包裹体积，急件与批量件分流，仓库动态分配货位，客户取消就及时腾空；每件货的路线、等待和费用都可追踪，但没有真实运营数据就不能报处理能力。

  • 合格线｜ 准入、队列、调度、Worker 制品、取消、KV、Trace 与租户隔离；
  • 加分项｜ 故障注入 OOM/断连/限流/流式后响应丢失，量化独立灰度与质量回滚；
  • 高频误区｜ 只画模型 Worker，忽略网关、调度和取消，或编造容量数据；
  • 下一问｜ 本组题结束；后续应完成长度×输出×并发×精度的压测矩阵设计。

4. 自测与评分 ​

  • [ ] 画出 Tokenize → Prefill → Decode → Stream，并标注 TTFT/ITL；
  • [ ] 给定层数、KV 头、头维、长度、并发和 dtype 计算理论 Cache；
  • [ ] 用固定 Logits 比较 Greedy、Temperature、Top-k 和 Top-p；
  • [ ] 设计断连、OOM、流式后重试和跨版本 Cache 的故障测试；
  • [ ] 按准确性、原理深度、工程意识、项目表达、沟通结构各 0～5 分评分；
  • [ ] 若声称 Cache 每步 O(1) 或量化固定倍数加速，准确性不得判为优秀。

5. 事实边界与参考资料 ​

  • 单一事实源：LLM 推理与服务优化；
  • 源文档依据包括 Hugging Face Generation/Cache、PagedAttention/vLLM、GPTQ、AWQ、Speculative Decoding 和 FlashAttention-2 一手资料；
  • 后端、量化格式、内核、Cache 类型和性能随框架、硬件和版本变化，必须在固定配置上实测；

当前无法确认｜ 示例 Gateway 的真实模型、硬件、流量、TTFT、ITL、吞吐、显存、成本和业务效果。

6. 总结 ​

一句话记忆： Prefill 建 Cache，Decode 逐 Token 读 Cache；生产优化是在质量门槛下联合管理延迟、吞吐、显存和故障。

  • TTFT 与 ITL 对应不同阶段，必须按长度和分位数观察；
  • KV Cache 避免历史 Token 的整段前向重算，但当前 Token 仍需计算并读取持续增长的历史 K/V，显存也随长度和并发增加；
  • Continuous Batching 优化利用率，Paged KV 优化动态内存管理；
  • 量化没有固定加速倍数，必须做目标硬件上的性能—质量联合评测；
  • 准入、取消、幂等、版本 Cache、降级和回滚共同决定服务可靠性。