vLLM 专项：60 道面试题与参考回答

返回导航 · 知识地图 · KV 专题

这些问题覆盖常见考察主题，不是公司真题库，也没有题目频率统计。参考答案按“结论 → 原因 → 前提/代价”组织；涉及性能和设计时，应结合题目给定的硬件、模型、负载与 SLO。

建议练习方式：每题先用 60～90 秒独立作答，再尝试计算例子或画图。不能只背术语和“通常更快”。

A. 模型、显存与指标

Q01. Prefill 和 Decode 有什么区别？

参考回答：Prefill 处理输入序列并建立 KV，各输入位置可以在因果约束下并行计算；完成后通常得到用于采样首 token 的 logits。常规 Decode 每轮为请求继续计算一个位置，依赖已有 KV 和先前生成结果。大 Prefill 往往有较高计算强度，小批量 Decode 常受权重/KV 读取带宽限制，但 batch、上下文和模型结构会改变瓶颈。

追问：Chunked Prefill 的中间片段不一定产生用户可见输出。

Q02. KV Cache 到底节省了什么？

参考回答：它保存各层历史位置的 K/V，避免每生成一个 token 都重新执行历史序列的 forward。新位置仍需生成自身状态、读取历史 KV、计算 Attention 和 FFN。缓存换来重复计算减少，同时带来随上下文增长的存储和读取开销，因此长上下文 Decode 仍可能很慢。

Q03. 为什么通常缓存 K/V，不把历史 Q 一起保存？

参考回答：标准因果自回归 Attention 在新位置使用的是新位置的 Q，与历史 K 做匹配，再聚合历史 V；历史 Q 不参与新位置的注意力计算。保存它们通常不能减少这条计算路径，反而增加状态。这里针对普通自回归 Attention，不是声称所有模型都不存在其他可缓存状态。

Q04. 怎么估算 KV 显存？

参考回答：同构全注意力模型的逻辑 KV 约为 2 × 层数 × KV heads × head_dim × 元素字节数 × 缓存token总数。32 层、8 KV heads、dim=128、BF16 时每 token 为 128 KiB，8192 tokens 约 1 GiB。物理占用还要考虑 block 取整、共享、并行复制、量化元数据；MLA、SWA 和混合模型要按真实状态重新计算。

Q05. MHA、MQA、GQA 的区别及推理意义？

参考回答：MHA 通常为各 query head 配对应 K/V heads；MQA 让多个 query heads 共享一组 K/V；GQA 介于两者之间，按组共享。减少 KV heads 可降低 KV 存储与读取成本，但模型质量、训练设计和 kernel 效率也影响选择。计算容量时使用 KV head 数，不能把 query head 数直接代入。

Q06. 模型权重能放进 GPU，为什么仍然 OOM？

参考回答：权重只是显存的一部分，还有 KV、激活峰值、workspace、graph、通信和传输缓冲。并发、prompt 长度和输出增长会改变这些开销。应区分加载期、profile/capture 期、Prefill 峰值与运行期 KV 压力，再选择降低 token budget/并发、限制长度、调整并行或精度等措施。

Q07. TTFT、ITL、TPOT 怎么区分？

参考回答：TTFT 是选定起点到首输出的时间；ITL 是连续输出 token 的间隔；TPOT 通常是一个请求首 token 之后的平均每 token 时间。对 N>1，首到末输出耗时为 (N-1)×TPOT，但完整 E2E 还可能有尾部开销。客户端流式 chunk 可能包含多个 token，所以必须说明计时与分词口径。平均 TPOT 好不代表没有 ITL 尖峰。

Q08. 为什么吞吐提高不代表服务变好？

参考回答：增大 batch 或排队可以提高 tokens/s，却可能恶化 TTFT、ITL 和 P99。在线服务更关心在指定延迟约束下每秒完成的成功请求，即 Goodput。比较时固定模型、负载、资源和质量要求，同时报告拒绝率、失败率和提交负载，不能只看完成请求的平均值。

B. vLLM 引擎与调度

Q09. vLLM 的核心价值是什么？

参考回答：它把模型执行、KV 分页管理、迭代级调度、批处理、GPU 优化和服务接入组织成推理引擎。分页提高有效显存利用，Continuous Batching 提高执行资源利用，其他优化降低 kernel/CPU/通信开销。不能把 vLLM 的所有收益归因于一个 Attention kernel，也不能假设对任意硬件和负载都优于其他实现。

Q10. V1 的主要组件如何协作？

参考回答：API/Engine Client 负责输入和输出流；EngineCore 驱动执行循环；Scheduler 决定每请求本轮 token 数并协调 KV；Executor/Worker 分发执行；ModelRunner 准备输入并运行模型；采样和输出处理推动请求状态。在线路径常跨进程通信。外部 KV connector 还会参与查找、数据准备和生命周期管理。

追问：画出 D02、D04，并区分职责箭头与实际函数调用。

Q11. Continuous Batching 与传统动态 batching 有何不同？

参考回答：传统请求级动态 batching 在入口收集请求组成 batch；Continuous Batching 可以在生成迭代边界调整成员，完成请求退出，新请求加入，避免短请求被最长请求占住整个批次周期。它要求能管理不同长度、不同进度的序列与 KV；并不意味着一次正在执行的 GPU kernel 可随时插入请求。

Q12. V1 调度器为什么用 token budget？

参考回答：一个待 Decode 请求可能只需计算一个 token，待 Prefill 请求可能需计算很多；以请求数衡量工作量太粗。调度结果可以表示成 {request_id: 本轮token数}，统一容纳完整/分块 Prefill、Decode 和投机验证。仍要同时满足 KV、请求数、优先级、外部数据就绪等约束。

Q13. Chunked Prefill 为什么能改善 Decode 延迟？

参考回答：长 Prefill 一次执行可能延长 Decode 请求的下一轮等待。将其拆分后，可以控制每轮混入的 Prefill 工作量，让 Decode 更频繁地获得执行机会。较小 chunk 可能改善 ITL，却增加长 prompt 完成 Prefill 所需轮数和调度开销；TTFT 与吞吐要通过混合负载实测，不能保证所有指标一起改善。

Q14. max_num_batched_tokens、max_num_seqs、max_model_len 有什么区别？

参考回答：分别表达 token 工作量预算、序列数量约束和单序列允许长度。它们都不直接等于最终 QPS。新版本可能进一步拆分 scheduled/active/queued 限制，应检查所选版本。即使预算剩余，KV 不足或外部加载未完成也可能阻止继续调度。

Q15. PagedAttention 为什么能改善吞吐？

参考回答：通过 block table 将逻辑序列映射到非连续物理 KV blocks，避免为每条请求预留大块连续内存，并支持兼容前缀共享。减少浪费后，同样 HBM 可以承载更多有效工作，可能提高 batch 和吞吐。它并不减少每 token 的逻辑 KV 字节数，也不能保证完全没有尾块碎片和映射开销。

Q16. KV 不足时抢占为什么会有代价？

参考回答：暂停某请求并释放其活跃 blocks 可以让其他请求推进，但被抢占请求恢复时可能需要重算被丢弃的状态。V1 官方调优文档介绍的默认抢占路径偏向 recompute；具体以版本为准。频繁抢占会增加计算、排队和尾延迟，应检查并发、长度、显存规划和策略，而不是仅增加重试。

Q17. 请求结束后 KV 为什么可能还占着内存？

参考回答：GPU KV pool 往往预先分配，不会每次请求结束都把内存退给设备分配器；block 可能进入可重用队列，或保留完整前缀供复用。异步保存/远端读取也可能暂时保留引用。需要看 block 使用状态、缓存索引与在途操作，不能仅凭 nvidia-smi 显存不降判断泄漏。

Q18. 怎么安全取消正在运行的请求？

参考回答：先阻止后续调度和输出，再处理已经提交的 GPU/传输操作；这些操作访问的内存必须保持有效直到完成或安全取消。随后清理请求状态、引用、connector 资源和输出流。仅从等待队列删除 request ID 不足以处理已执行请求，过早复用 buffer 可能造成数据损坏。

C. GPU、kernel 与执行优化

Q19. 如何区分计算受限和带宽受限？

参考回答：用算术强度 FLOPs/搬运字节 与硬件计算/带宽能力估计上界，再用 profiler 验证实际 kernel。大 GEMM 常能提高数据复用，小批量 Decode 可能反复读取权重；长上下文还会增加 KV 读取。也要排除 launch、同步和 CPU 供给不足，不能只根据 GPU utilization 判定。

Q20. FlashAttention 与 PagedAttention 是同一类优化吗？

参考回答：FlashAttention 通过分块、融合和在线 softmax 等方式减少 Attention 中间结果的 HBM 往返，通常不把完整注意力矩阵写入 HBM；PagedAttention 解决 KV 的分页访问和内存管理。二者可以组合。FlashAttention 在算法上计算精确 Attention，浮点归约顺序可能导致数值差异，不能等同于稀疏/近似 Attention。

Q21. CUDA Graph 和 torch.compile 分别做什么？

参考回答：CUDA Graph 捕获并重放设备执行依赖，减少重复 CPU launch 开销；编译系统可优化算子图、融合、代码生成等。二者可以协作，但动态 shape、控制流、内存地址稳定性、padding 和 graph 数量会限制收益。CPU launch 不是瓶颈时，Graph 也不一定有明显提升。

Q22. 为什么更多异步 stream 不一定更快？

参考回答：异步提供重叠机会，不增加 HBM、PCIe 或 SM 的物理容量。如果计算和搬运竞争同一瓶颈、操作粒度太小或存在事件依赖，额外 stream 可能只增加调度成本。正确做法是明确依赖，用 event 确保数据就绪，再在 trace 中确认真实重叠及其端到端收益。

Q23. 怎么定位 CPU 开销限制 GPU 的情况？

参考回答：观察 GPU kernel 之间是否存在空洞，并对应检查 tokenization、调度、IPC、Python/GIL、序列化、日志和同步。用不同 batch、输入处理路径或服务/离线模式作对照。GPU 利用低只是线索；短 kernel、限流或通信等待也可能产生类似现象。

Q24. 量化为什么可能更省显存但更慢？

参考回答：量化减少数据字节，但反量化、scale 处理、布局转换或不成熟 kernel 会增加开销。收益依赖硬件低精度支持、矩阵形状、batch 和原瓶颈。权重量化与 KV 量化影响的容量、带宽和误差不同，应分别测量。不能用 4-bit 相对 16-bit 的存储比例直接推断 4 倍加速。

Q25. 投机解码如何在保持目标分布的同时加速？

参考回答：draft 先提出若干 token，目标模型批量验证。在一种经典精确采样方案中，p、q 分别是同一历史条件下的目标和草稿分布，对候选按 min(1,p(x)/q(x)) 接受，拒绝时从归一化的正部 max(p-q,0) 采样，以保持目标分布；还需正确处理后续 token。不同方法、greedy 路径的验证规则不同。收益依赖接受率、draft/验证成本及 batch，不等于无条件一次生成更多有效 token。

Q26. 优化一个 RMSNorm/Triton kernel 应该怎么做？

参考回答：先定义 dtype、shape、容差和参考实现；覆盖数值与边界情况。再分析读写量、归约、寄存器与 occupancy，测量实际 kernel 时间和有效带宽，比较融合前后的端到端影响。使用 warmup、正确同步和足够重复，不能用未同步的 Python 调用耗时当 kernel latency。

D. 并行与分布式推理

Q27. TP、PP、DP、EP 怎么选？

参考回答：TP 在层内切分，适合用高速互联减轻单卡权重/计算压力；PP 按层切分，需考虑阶段平衡和气泡；稠密 DP 复制模型处理不同请求；EP 分布 MoE experts，涉及 token 路由通信。选择需满足容量，再比较延迟、吞吐、拓扑和成本。没有一套配置对所有阶段和负载都最好。

Q28. 为什么 TP 增大后延迟可能变高？

参考回答：每卡计算变少，但集体通信、同步和小矩阵效率损失增加。小模型、小 batch 或慢互联下，通信成本可能超过计算节省。应测量每层计算和 collective 时间，并检查拓扑、消息大小和 kernel，而不是只按 GPU 数预期线性加速。

Q29. 模型单卡能放下，为什么仍可能用 TP？何时用副本？

参考回答：TP 可能降低单请求计算时间或减轻每卡权重占用，让出更多 KV 空间，但有通信代价。多个独立副本通常适合提高总吞吐和隔离故障。应比较相同 GPU 总数、SLO 与负载下的 Goodput；“能放下就必须不用 TP”也过于绝对。

Q30. TP 后 KV 显存是不是除以 TP 数？

参考回答：只有相应 KV heads/状态确实均匀切分时才能近似这样算。KV head 数少于 TP、backend 要求复制、MLA 或混合模型等情形会改变布局。PP 还改变每 rank 保存的层数。必须从实际每 rank 的层/head/state shape 计算，不能只看并行参数。

Q31. All-Reduce、All-Gather、Reduce-Scatter、All-to-All 的区别？

参考回答：All-Reduce 对各 rank 数据归约并让所有 rank 获得结果；All-Gather 汇集各自分片；Reduce-Scatter 归约后分发不同结果分片；All-to-All 让各 rank 向其他 rank 发送不同分块。它们常用于 TP、分片计算或 MoE dispatch，但实际通信模式由模型并行实现决定，不能机械一一对应。

Q32. MoE 为什么可能通信比计算更难优化？

参考回答：稀疏激活减少每 token 的专家计算，但 token 要分发到专家所在设备再合并。小批量、专家选择倾斜和跨节点通信可能导致小消息、负载不均和同步等待。EP、DP/TP 组合、专家放置与负载平衡都影响效率；活跃参数少不意味着服务系统自然更快。

Q33. PD 分离的价值和代价是什么？

参考回答：价值是分别规划 Prefill 和 Decode 资源与并行方式，减少长 Prefill 对 Decode 尾延迟的干扰。代价是 KV 传输、协调、路由、源缓存保留和失败恢复。应在相同资源与 TTFT/TPOT 目标下比较 Goodput，不能宣称分离天然提高原始 tokens/s。短 prompt、慢网络或负载不足时可能不划算。

Q34. P 和 D 的 TP 不同，可以直接传 KV 吗？

参考回答：不能只凭相同模型和 dtype 就认为可以。接收端需要兼容的层/head/rank、布局、位置和已计算边界；TP 不同可能要求 reshard、聚合或重排，以及 connector 明确支持。不支持时应选择兼容部署或实现转换，而不是复用对方的内存地址解释。

E. KV Cache、LMCache 与 Mooncake

Q35. 跨请求 Prefix Cache 为什么需要前序 hash？

参考回答：因果模型深层 K/V 依赖前文，同一文本块放在不同前缀后，其 KV 通常不同。链式 hash 将前序上下文、当前 token 块及相关身份组合起来，避免把不同上下文当作同一缓存。还需模型/adapter/多模态等命名空间，当前块文本 hash 不能独立保证正确性。

Q36. 温度、top-p 要放进 KV key 吗？

参考回答：普通 forward 对给定 token 前缀的 K/V 通常不依赖采样温度或 top-p，它们影响下一 token 的选择。生成出的历史 token 如果不同，自然会形成不同 token key。缓存 key 应包含影响 KV 计算和解释的因素，而不是把所有 API 参数无差别加入，既避免错误复用也避免无谓降低命中。

Q37. KV block 的 ref_cnt=0 是否意味着缓存失效？

参考回答：不一定。没有活跃请求引用的完整块可以仍保留 hash 与内容，处于可命中但也可驱逐的状态。下一请求命中会重新引用；分配压力需要复用时再移除旧索引。还需排除外部异步传输持有的使用权，不能仅看请求引用就释放物理内存。

Q38. vLLM 本地 APC、LMCache、Mooncake 分别做什么？

参考回答：vLLM 管理执行时 GPU blocks 并做本地兼容前缀复用；LMCache 管理跨请求的 KV chunks、分层保存和加载，连接引擎与后端；Mooncake Transfer Engine 提供高速搬运，Store 提供共享对象存储与元数据。LMCache 能使用 Mooncake Store，所以它们可以组合。各层都可能有缓存逻辑，但职责和粒度不同。

Q39. MooncakeConnector 和 MooncakeStoreConnector 有什么区别？

参考回答：前者主要提供 Prefill/Decode 间直接点到点 KV 传输；后者通过 Mooncake Store 使用共享 KV 对象池，可支持外部卸载与跨实例前缀复用。P2P 一次交接与可被多请求复用的存储对象具有不同生命周期，不能仅看“都用 Mooncake”就视为等价。

Q40. vLLM 直接接 Mooncake 与经过 LMCache，有何取舍？

参考回答：直接 Store connector 可满足共享对象池需求，减少一层缓存中间件的配置；LMCache 路线增加多后端、多级管理及其特定复用能力，也增加服务、元数据和搬运路径。应根据所需功能、版本兼容和实测成本选择，不能预设多一层必然更慢或必然更先进。

Q41. LMCache MP 为什么要独立进程？

参考回答：把缓存管理、hash、IO 等工作与引擎进程隔离，可独立配置 CPU/内存并为多个实例共享缓存，减少在引擎进程内竞争 Python/GIL 等资源。代价是跨进程控制、设备注册、通信和运维复杂度。它不意味着缓存路径完全没有 CPU 开销，数据面也不一定经过普通 RPC payload。

Q42. LMCache chunk 与 vLLM block 必须相同吗？

参考回答：不必须。block 是执行分配单位，chunk 是缓存/传输单位，一个 chunk 可以覆盖多个 blocks。它们需要满足模型 KV groups 的布局和对齐要求，某些 MP 版本会协商实际 chunk 大小。小 chunk 提升细粒度复用但元数据多，大 chunk 摊薄开销但可能浪费取回字节，需用实际负载选择。

Q43. 什么时候取回 KV 比重算更快？

参考回答：当 lookup、排队、远端 IO、网络、H2D、布局转换及同步的关键路径成本，小于被省掉的增量 Prefill 成本时，取回可能更快。还要考虑流水重叠、保存成本和负载变化。1 GiB 数据走 400 Gbit/s 单链路的理想下界约 21.5 ms，实际通常更高；如果重算只需几毫秒，不能因命中就盲目取回。

Q44. 命中率提高，TTFT 却变差，怎么排查？

参考回答：先确认命中分母和是否真的跳过计算；随后分解 lookup、取回队列、存储读取、网络、H2D、重排与等待。检查 chunk 过大、热点实例、CPU/GPU 带宽竞争及取消后残留。比较相同负载下禁用外部缓存、仅本地缓存和启用外部缓存的对照，找到真正收益区间。

Q45. lookup 命中为什么不代表可立即执行？

参考回答：lookup 只说明索引或远端对象存在，目标 GPU 可能尚未分配空间、数据未传完，也可能发生驱逐或失败。调度器必须等待相应完成状态，确认依赖 KV 的范围有效；layerwise 路径可逐层等待。失败时需要撤销无效命中和已计算状态，不能跳过 Prefill 后继续使用未初始化数据。

Q46. 异步传输时最容易出现的生命周期错误是什么？

参考回答：把“提交成功”或“请求结束”当作“数据已经不再被访问”。如果源 block 被复用，而 NIC/GPU 仍在读取，就可能传出其他请求的数据。应通过引用、pin/lease、完成事件和取消协议把内存生存期覆盖到真实访问结束。租约超时也需要与实际传输终止/保护机制协调。

Q47. Mooncake Store 的 Master 会转发所有 KV 数据吗？

参考回答：其设计分离元数据面与数据面。Master 管对象位置、分配、replica 和相关生命周期信息；客户端获得描述后，用 Transfer Engine 与存储节点直接交换 payload。这样避免让 Master 承担大块数据带宽，但 Master 的元数据 QPS、延迟和可用性仍是需要分析的系统因素。

Q48. RDMA、GPUDirect RDMA 与零拷贝如何理解？

参考回答：RDMA 可让 NIC 直接访问已注册远端内存，减少远端 CPU 搬运；GPUDirect RDMA 在支持环境中扩展到 GPU 内存，减少 CPU staging。零拷贝通常指减少中间副本，仍有物理传输、内存访问、注册和同步成本。必须核对 GPU-NIC/NUMA 拓扑、驱动与实际 transport，不能仅根据配置名声称走了最快路径。

Q49. CacheBlend 为什么不能等同于精确前缀缓存？

参考回答：普通精确前缀复用要求兼容的完整历史；非前缀文本在新前文后具有不同上下文依赖。CacheBlend 尝试复用片段并选择性重计算部分 token，降低重算成本，但不能普遍保证与完整 Prefill 数值完全相同。要对任务质量、顺序变化、tokenization、重算比例和 TTFT 做联合评估。

Q50. 外部 KV Store 宕机后如何回退？

参考回答：不能继续相信已失效的缓存位置。需超时或失败通知、清除无效命中状态、安全清理在途内存，再按支持路径重新 Prefill 或终止请求。大量 miss 同时重算可能压垮 P 端，所以需要限制回退并发、admission 和退避。缓存是可重算数据，不代表故障恢复没有业务成本。

F. 系统设计、性能诊断与工程实践

Q51. 怎样设计一个同时支持长文档与短对话的服务？

参考回答：先确认模型、输入/输出分布、峰值到达率和 TTFT/TPOT/SLO。估算权重与 KV，建立共置/Chunked Prefill 基线，再依据 trace 决定是否分池或 PD。配置路由、限流、队列、取消、缓存和监控；扩缩容要考虑模型加载与缓存冷启动。最后以混合负载和故障实验比较 Goodput 与成本。

追问：不要直接从“长文档”跳到“必须 PD”，先证明干扰与资源收益。

Q52. 缓存感知路由是不是优先去命中最多的实例？

参考回答：缓存收益必须与排队、取回和未命中计算一起比较。某节点命中多但队列很长，可能不如空闲节点重算；固定 sticky 路由也可能形成热点。可用预计完成时间加容量/SLO 约束做决策，必要时复制热门前缀。路由索引还可能过期，应支持失效和回退。

Q53. P99 TTFT 上升但 ITL 基本稳定，可能是什么原因？

参考回答：优先检查入口/Prefill 排队、长 prompt 比例、缓存 miss、外部加载和输入预处理，再检查 admission 与路由。Decode 稳定提示问题可能发生在首 token 前，但不能直接断定是 Prefill kernel。用分阶段时间和请求长度分桶验证，避免混合分布造成误判。

Q54. ITL 出现周期性尖峰，怎么查？

参考回答：将尖峰时间与长 Prefill 插入、调度轮次、collective、KV 保存/取回、CPU GC/日志或系统资源争用对齐。检查是不是客户端流式缓冲造成的观测假象。通过限制 Prefill budget、关闭某项 IO 或记录 GPU/CPU trace 做单变量对照，不把所有尖峰都归因于 Attention。

Q55. 为什么固定并发与固定到达率压测结果不同？

参考回答：闭环固定并发通常在请求完成后再补充请求，服务变慢会自动降低发送率，可能掩盖真实流量下的排队。开放式固定到达率继续产生请求，可观察过载和延迟增长。同时设置并发上限会限制实际发送率；必须报告 offered/actual rate、客户端排队和失败，不能混用不同口径。

Q56. 怎么避免 benchmark 得出虚假结论？

参考回答：固定模型、版本、硬件、精度、实际输入输出长度分布和资源；明确冷暖缓存与 warmup；随机化实验顺序并重复测量。避免意外公共前缀、EOS 导致长度变化、未同步计时和客户端瓶颈。保存原始结果，报告分位数、失败和正确性，不只展示一个最好点。

Q57. 如何估算服务容量与成本？

参考回答：先分别估算显存容量和计算/带宽/通信上限，再通过负载测试得到满足 SLO 的稳定吞吐。稳定系统中 Little 定律 L=λW 可关联平均在途数、实际完成率与平均停留时间，但不能直接用峰值 token/s 推算 P99。成本还要计入 GPU、CPU/缓存节点、网络和拒绝/重算开销。

Q58. 缓存共享有哪些正确性和隔离风险？

参考回答：错误模型/adapter/位置或布局复用会改变输出；不安全的对象生命周期会读到被覆盖数据；跨租户共享可能暴露内容存在性或越权访问。应有兼容命名空间、访问控制、必要 salt、读写完整性和完成保护。质量优化与精确复用分别验证；浮点执行差异也意味着不应无条件要求跨所有配置 bitwise 相等。

Q59. 如果要求实现一个 KV 缓存组件，你会先实现什么？

参考回答：先约定 key 兼容规则、对象粒度和状态机，实现写入预留/完成发布、查询、读取保护、释放和容量限制。再做简单可解释的驱逐策略与失败回退，验证并发写读、取消、超时、租约和内存复用。最后才加异步预取、多级后端和复杂策略，避免性能优化掩盖生命周期错误。

Q60. 怎样讲一个有说服力的推理优化项目？

参考回答：先讲业务负载和 SLO，再给基线与瓶颈证据；说明修改如何针对瓶颈，展示同条件对照、质量/正确性、分位数和成本。最后给出无收益或退化的负载，以及失败回退。真实未做过的多卡/RDMA 实验应明确说明，不能用理论估算或论文数字冒充自己的测量。

复习用的四个计算题

参考依据

引擎与指标：资料索引 V1～V13；LMCache：L1～L11；Mooncake：M1～M6；分页、PD、KV 中心化架构和 CacheBlend：P1～P4。接口细节应以固定版本源码和官方文档为准。