本文是AI Infra 面试题系列的 Level 4，覆盖 Q41-Q54。重点是KV Cache、PagedAttention、调度、SLO、P/D 分离、投机解码与量化。
上一篇：TP、SP、CP、PP 与 EP · 系列总索引 · 下一篇：Kernel、编译与性能工程
5. Level 4：LLM 推理引擎与在线服务
Q41. prefill 和 decode 的瓶颈为什么不同？
高分回答要点
- Prefill 并行处理输入序列，GEMM 较大、算术强度高，通常更容易 compute-bound；同时创建每层 K/V。
- Decode 每步只为每个请求生成少量 token，但要读取权重和已有 KV，矩阵较小且逐 token 有依赖，常偏 memory-bandwidth/launch-bound。
- batching 可以复用权重读取、增大 GEMM，但 decode batch 受请求到达、长度差异和 SLO 限制。
- 不能把两个阶段用一个平均 tokens/s 概括；应分别看 TTFT、TPOT、prefill tokens/s 和 decode batch efficiency。
Q42. 如何估算 KV cache 显存？
高分回答要点
- 对每请求长度
S、层数L、KV head 数H_kv、head dimD、每元素bbytes，KV 约为2 * L * S * H_kv * D * b；2 来自 K 和 V。 - MHA 中
H_kv等于 query head 数；GQA/MQA 显著减少 KV，但不同比例取决于架构。 - 多请求按实际 token 总数求和，再加 block metadata、对齐、碎片、prefix 引用和临时 workspace。
- TP 后每 rank KV 是否按 head 分片取决于实现；容量不能简单按 GPU 数倍增，需检查复制项与 block manager。
追问：给出一个 70B 模型配置和 128k context，现场计算单请求 KV；候选人应先向面试官索要 L/H_kv/D/dtype。
Q43. PagedAttention 解决了什么问题？
高分回答要点
- 把逻辑连续的 KV 序列映射到固定大小物理 block，避免为最大长度预留连续大块显存，降低外部碎片并支持动态增长。
- block table 让 attention kernel 按映射读取 KV；copy-on-write/reference counting 可支持共享 prefix。
- block 太大产生内部碎片，太小增加 metadata、寻址和 kernel overhead；block size 是容量与效率权衡。
- 它改善内存管理和可批处理性，但不会消除 KV 本身的线性容量，也不会自动解决调度和尾延迟。
Q44. continuous batching 与静态 batching 有什么区别？
高分回答要点
- 静态 batch 等整批请求完成，短请求会等待长请求，设备可能在 batch 边界空闲。
- continuous batching 在迭代/token 边界加入新请求、移除完成请求，保持活跃 token batch，提高利用率并减少 head-of-line blocking。
- scheduler 要在 prefill 与 decode、最大 batched tokens、序列数、KV 容量和优先级之间决策。
- 高吞吐策略可能延迟新请求 prefill 或已有请求 decode，因此必须用 TTFT/TPOT SLO 约束，不只是最大化 tokens/s。
实验锚点：本项目 eager 模式并发 1→32 时 output throughput 约 34.8→686.6 tok/s，体现 batching 对权重复用和 GPU 占用的价值。
Q45. 推理 scheduler 在 KV 不足时有哪些选择？
高分回答要点
- admission control：在进入 GPU 前拒绝、排队或降级，避免过载后所有请求一起违约。
- preemption：暂停低优先级序列；可丢弃并重算 KV，或 swap 到 CPU/远端，两者分别付计算或传输代价。
- chunked prefill：把长 prompt 分块，限制单轮 token budget，避免长 prefill 长时间阻塞 decode。
- 公平性策略可按请求、token、租户或 deadline；必须防止长请求饥饿和单租户占满 cache。
- 观测 queue time、preemption/recompute、KV occupancy、eviction、每轮 prefill/decode token 和 SLO miss 原因。
Q46. chunked prefill 为什么可能改善尾延迟，也可能降低效率？
高分回答要点
- 把长 prefill 分成多个调度 quantum，可在块之间插入 decode，降低已有请求的 TPOT 抖动和新请求 head-of-line blocking。
- 块过小会增加调度、kernel launch、状态管理并让 GEMM 变小；块过大又失去抢占效果。
- 某些实现可把 compute-heavy prefill 与 memory-heavy decode 混在一轮以提高资源互补，但 kernel/内存竞争也可能抵消收益。
- 应扫描 chunk size 与 token budget，分别观察 TTFT、TPOT p99、throughput、batch composition 和 GPU counters。
Q47. prefix caching 的正确收益边界是什么？
高分回答要点
- 命中后复用已有 prefix KV，直接跳过对应 prefill 计算，因此主要改善共享长 prompt 请求的 TTFT 和 prefill 吞吐。
- 它不减少新 output token 的自回归 decode 计算；TPOT 若改善，通常来自队列和资源竞争下降，是间接效果。
- 无共享 prefix、prefix 很短、cache 容量不足或频繁 eviction 时收益小；hash lookup 和 block 管理也有成本。
- benchmark 要区分 cold、warm、cache-off，固定 prompt/output，并验证真正命中 token 数。
实验锚点：高复用场景命中约 93.7%，warm-cache 相对关闭约 4.32x 吞吐、TTFT 降约 84.8%；这不能外推到随机 prompt。
Q48. prefix cache 如何保证正确性和租户隔离？
高分回答要点
- cache key 不能只含 token ids；还应覆盖模型/adapter、position、相关 sampling/attention 配置，以及会改变 KV 的多模态或模板输入。
- block hash collision 必须可接受地检测/规避；引用计数保证共享 block 不被提前回收，copy-on-write 防止后续 token 修改共享状态。
- 多租户需在 key 中加入隔离域或显式禁止跨租户复用，避免 timing/存在性侧信道和数据泄露。
- 模型热更新、LoRA 切换和 tokenizer/template 变更要使旧 cache 失效；指标应能按租户查看命中与 eviction，但不能泄漏 prefix 内容。
Q49. 推理部署时如何选择 TP 还是 DP replicas？
高分回答要点
- 模型单卡可放下时，DP replica 没有层内 collective，通常 aggregate throughput 和故障隔离更好；TP 可能降低单 rank 参数/KV 压力，但增加每层通信。
- 模型放不下或单请求延迟需要聚合算力时使用 TP；前提是互连足够快且本地 GEMM 不被切得过小。
- DP 需要路由与负载均衡；cache-aware routing、请求长度不均和 replica warm state 会让简单 round-robin 失效。
- 应比较相同 GPU 总数下 capacity、单请求 latency、aggregate goodput、每 GPU tokens/s 和故障域。
实验锚点：本机 TP 在 PCIe 上主要换容量；而 4 个 DP replica 在高负载下相对单 replica 只提高约 46%，说明副本扩展还受客户端、路由、CPU、到达分布和每副本 batch 破碎影响。
Q50. torch.compile、CUDA Graph 和 eager 各有什么取舍？
高分回答要点
- eager 灵活、冷启动低、调试容易，但 Python dispatch、launch 和未融合算子开销更大。
- 图编译可做 fusion、layout/constant 优化和生成专用 kernel，但有 compile time、graph break、shape specialization、缓存与额外内存成本。
- CUDA Graph 通过 capture/replay 降低 launch overhead，但要求地址和控制流较稳定，动态 batch/sequence 需 padding、分桶或多图管理。
- 必须分别测首次启动、首次请求、warm steady state、不同 shape 命中率和峰值显存；只报 warm throughput 会掩盖生产代价。
实验锚点：本项目 compile 配置显示启动与显存代价；在 V100 上还受到 backend/架构支持边界影响，不能把新卡结论直接复制过来。
Q51. open-loop、closed-loop 与 SLO goodput 如何设计？
高分回答要点
- closed-loop 固定并发，前一个请求结束后才发下一个；它容易形成自节流，适合容量扫描但掩盖真实排队。
- open-loop 按外生到达过程发请求；Poisson workload 的 inter-arrival time 服从指数分布，更适合观察过载和排队拐点。
- completed throughput 是单位时间完成数；goodput 只统计满足 TTFT、TPOT、E2E 等 SLO 的请求。
- 对每个 arrival rate 保持足够时长和独立 seed，报告 queue length、p99、错误、未完成请求，并确认 client 不是瓶颈。
实验锚点：本机在设定 TTFT<250 ms、TPOT<40 ms 时稳定区约为 5 QPS；超过拐点后 completed throughput 可继续升，goodput 却崩溃。
Q52. 怎样用排队论解释推理尾延迟？
高分回答要点
- 基础关系
L = lambda W可检查平均在途请求、到达率和响应时间是否自洽；但 LLM service time 由输入/输出长度和 batching 决定，不满足简单常数服务时间。 - 当利用率接近 1，微小 service-time 抖动、长请求和 burst 会导致队列及尾延迟非线性增长。
- dynamic batching 又让单请求 service time 依赖其他请求，需用真实 trace/离散事件模型或实测校准，而不能只套 M/M/1。
- admission、优先级、deadline、长度分桶和容量冗余用于控制尾延迟；目标是最大化受 SLO 约束的 goodput。
Q53. prefill-decode disaggregation 何时有收益？
高分回答要点
- prefill 偏 compute-heavy，decode 偏 memory/latency-sensitive；分池可独立扩缩容和批处理，避免长 prefill 干扰 decode TPOT。
- 代价是 KV 从 prefill worker 传到 decode worker的网络传输、序列调度、失败恢复和额外排队。
- 只有阶段干扰/独立扩缩收益大于 KV transfer 与空转成本时才值得；短 prompt、小模型或慢网络可能更差。
- 设计需计算每请求 KV bytes、NIC 带宽/并发、transfer latency 与可隐藏窗口，并观测 prefill/decode utilization、KV transfer p99 和跨池 backpressure。
追问：如何为 prompt 长度设置 colocated 与 disaggregated 的动态路由阈值？
Q54. speculative decoding 和量化分别如何加速推理？
高分回答要点
- speculative decoding 用便宜 draft 一次提出多个 token，由 target 并行验证；输出分布可保持正确，但速度取决于接受率、draft 成本、验证 batch、额外 KV 和调度交互。
- 理论每次 target step 接受更多 token 不等于端到端等比例加速；低接受率、强 batching 或内存压力会抵消收益。
- 量化通过减少权重/KV bytes、提高可用低精度吞吐来加速；区分 weight-only、W8A8/FP8、INT4、KV quant，它们影响的瓶颈不同。
- 必须验证硬件是否有高效 kernel、量化/反量化开销、精度/任务质量、校准集、长上下文稳定性与实际 batch shape。
追问：decode 明显带宽受限时，weight-only INT4 为什么可能有效？prefill compute-bound 时为什么收益比例可能不同？