P7–P8 专家面试总纲：重点 KV Cache 存储
这份总纲按专家职责组织，不对应某家公司的官方职级标准。这里用 P7 型要求表示能独立负责关键子系统的设计、交付、性能与可靠性闭环；用 P8 型要求表示能定义跨子系统边界、容量与成本目标、演进路线，并协调多个团队形成可持续的平台能力。
重点不是背出更多项目名。面试需要证明：能建立问题模型，识别约束和风险，做取舍，落地验证，解释失败，并推动系统持续演进。建议将准备精力主要放在 KV 管理、共享存储、传输与故障闭环，保留足够的推理执行和 GPU 性能基础。
1. 专家回答的六层结构
- 需求：模型、负载、SLO、规模、租户和故障目标是什么？
- 约束：算力、显存、host、网络、元数据、兼容性和团队边界分别是什么？
- 协议：哪些不变量必须成立，状态由谁持有、发布、消费和回收？
- 取舍：比较至少两个可行方案，量化收益、成本和失效条件。
- 验证：给出正确性、性能、故障、升级与观测证据。
- 演进：解释灰度、回滚、后续瓶颈和跨团队接口怎样推进。
例如“远端缓存更快”只是结论。专家回答要说明什么负载、节省多少计算、引入多少排队和字节流量、失效率如何影响回源，以及在什么条件下应关闭它。
2. 必修能力矩阵
表中的 P0 表示本资料重点方向的必修能力；P1 表示需要分析清楚并按岗位深入。它不是题目出现频率统计。
| 能力域 | P7 型要求 | P8 型进一步要求 | 最低证据 |
|---|---|---|---|
| P0 推理与资源模型 | 算 KV/权重/在途量，解释 Prefill/Decode 和指标 | 把模型组合与流量变化映射到资源池规划 | 容量表、阶段成本模型 |
| P0 运行时与接入 | 追通调度、页管理、Connector、设备完成 | 定义跨引擎可复用的接入契约与升级边界 | 正常/取消/抢占时序 |
| P0 KV 身份与布局 | 解释前缀、模型、rank/group、页/chunk 与格式 | 定义版本化格式、共享域、迁移和兼容性矩阵 | 错误共享反例、格式设计 |
| P0 存储协议 | 设计发布、读保护、回收、幂等与部分失败 | 明确跨组件一致性、代际隔离与恢复不变量 | 状态机、故障矩阵 |
| P0 异步资源管理 | 处理 staging、引用、事件、取消与晚到完成 | 设计统一所有权和诊断模型，减少集成缺陷 | 资源所有者表、并发用例 |
| P0 LMCache/Mooncake | 用源码说明职责、调用与返回语义 | 识别接口契约与实现保证的差距，提出可验证改进 | 联合链路与代码定位 |
| P0 容量与数据放置 | 计算副本、对象数、元数据、内存和热点 | 设计跨故障域容量、修复和弹性规划 | 正常/故障/扩容三套预算 |
| P0 传输与拓扑 | 分析 RDMA、注册、NUMA、PCIe、批量与完成 | 协调传输、布局和调度，定义系统带宽目标 | 流量矩阵、分层测量 |
| P0 缓存策略 | 分析准入、淘汰、预取、路由和重算选择 | 联合优化 goodput、成本、公平性和资源池利用 | 对照与退化条件 |
| P0 HA 与故障恢复 | 处理节点退出、超时、主切换和回源压力 | 定义服务恢复目标、隔离和跨团队故障责任 | 故障演练与复盘 |
| P0 可观测性 | 分离候选命中、加载、少算 token 与排队 | 定义跨层 trace、指标口径和容量预测体系 | 一次端到端归因 |
| P0 多租户与演进 | 配额、共享边界、版本隔离、限流与回滚 | 平台化配置、兼容协议、治理和迁移路线 | 灰度/回滚方案 |
| P1 GPU 与模型优化 | 解释 kernel IO、Graph、量化、投机、并行 | 判断优化应落在哪层以及机会成本 | 代表性 shape 与质量约束 |
| P0 工程与技术影响 | 交付可维护代码、接口、测试和运维方案 | 明确目标、拆解风险、推进接口共识和长期迭代 | 设计评审、落地和复盘材料 |
如果面试通信/GPU 专家岗位，kernel 和并行需要提升为主修；本总纲默认 KV Cache 存储是主攻方向。
3. KV 存储必须能展开的十组问题
A. 身份、命名空间与格式
解释为什么相同文本不等于可共享状态，哪些信息进 key，哪些由 manifest/部署约束保证。能处理模型 revision、LoRA、位置、dtype、TP、混合模型和租户边界。
专家追问：格式升级时旧对象如何识别？能否双读新写？如何回滚？namespace 隔离和授权分别由谁负责？
B. 发布、不可变对象与多对象完整性
说明分配、写入、发布、可读之间的区别；处理重复写者、已有 key、部分成功和写者退出。区分对象级幂等、批量效率与多对象事务。
专家追问：前缀的多个 rank/group 只成功一部分怎么办？应提供事务、manifest commit，还是在消费者折叠有效范围？各自成本和故障语义是什么？
C. 资源生命周期与并发
画出 GPU 页、L1 staging、resident、远端副本和在途任务的所有者。区分本地锁计数、租约、pin、TTL、设备事件。解释超时不能直接触发内存复用。
专家追问：旧请求 ID、重启后的旧回调和地址复用如何隔离？如何证明不会重复释放、悬空访问或永久泄漏？
D. 缓存策略与调度协同
同时考虑复用概率、重算成本、对象大小、剩余寿命、写入成本和有效前缀。能解释 LRU 的优点与局限，并给出无需复杂模型也可上线的基线。
专家追问：预取如何限制在途内存？热点路由如何平衡缓存命中和计算排队？策略失效时如何降级与观测？
E. 副本、放置与故障域
区分 segment、host、rack 和可用区；定义复制目标和实际结果。说明副本对容量、写流量、热点读取与修复流量的影响。
专家追问：一个故障域退出后剩余容量够不够？修复是否抢占在线请求？扩容与重新放置期间如何限制读写放大？
F. 控制面扩展
计算对象数、元数据大小、查询 QPS 和批量开销。区分单进程锁分片与分布式分片，不能把哈希表有很多 shard 当作控制面已横向扩展。
专家追问：什么时候需要分布式元数据？客户端位置缓存怎样失效？主切换之后谁隔离旧写者、旧地址和未完成对象？
G. 传输、布局与完成
画真实的 GPU/host/NIC 路径，说明注册、批量、切片、GDR、NUMA 和多 rail 的收益边界。区分理论线速、微基准、对象读写和端到端 TTFT。
专家追问：RDMA 带宽未满但请求仍慢，查什么？怎样证明 H2D 或 CPU 完成处理成了瓶颈？负载变化后最优 chunk 是否改变？
H. 故障、隔离和回源
覆盖 miss、部分加载、超时未知完成、校验失败、节点退出、目录故障与容量打满。针对每一种情况明确允许消费什么、怎样释放、何时重算，以及谁承担背压。
专家追问：缓存故障导致重算激增，能不能维持服务？哪些请求优先、哪些被拒绝？恢复缓存会不会造成第二波预热风暴？
I. 成本、SLO 与实验
用固定模型、精度、负载、冷热状态和到达方式做比较。分别测量少算的 token、加载字节、队列、goodput 和成本。
专家追问：命中率提高但成本增加，是否上线？平均值更好但长请求或小租户 P99 更差怎么办？怎样排除本地 APC、预热和负载变化造成的假收益？
J. 接口与平台演进
说明哪些接口应稳定，哪些实现细节不应该泄漏给引擎。准备一个能分阶段实施的迁移方案，包括兼容性、灰度、回滚、指标和责任分工。
专家追问：一个新后端支持 put/get，但没有等价的锁与取消语义，接入层怎样适配？是否应降低能力承诺、改变上层协议，还是拒绝接入？
以上各组都能在 LMCache + Mooncake 联合链路中找到具体讨论对象；不得把设计建议说成框架当前已实现的能力。
4. 一道专家系统设计题
题目：为多租户推理服务设计共享 KV 缓存。示例模型每 8K 前缀约 1 GiB，保留 32,768 个不重叠前缀，两份副本；正常到达 200 请求/s，75% 请求需要远端恢复整份前缀。给定主机 DRAM、400 Gbit/s 网络和延迟目标，如何规划并验证？
这些是教学输入，不是实测。具体计算见存储预算。
| 讨论轮次 | 应主动完成 | 面试官可追加的约束 |
|---|---|---|
| 需求澄清 | 模型/长度分布、共享率、TTFT/ITL、租户和故障目标 | 流量翻倍，模型版本同时存在 |
| 容量建模 | 32 TiB 逻辑、64 TiB 副本 payload；再算其他资源 | 128×512 GiB 主机只能用 80% |
| 对象建模 | chunk/rank/group、对象数、key、布局、发布协议 | 改为更小 chunk，控制 QPS 增加 |
| 带宽建模 | 读取约 150 GiB/s，再算写入与修复的流量矩阵 | 热点落到少数主机，单机架故障 |
| 正确性 | 完整性、读保护、代际、超时、设备完成 | 第三个 rank 迟到，客户端已取消 |
| 策略 | 准入、预取、淘汰、路由、重算边界 | 热点切换，写入污染，租户争抢 |
| 可靠性 | 副本、主切换、回源限额、恢复顺序 | 缓存全冷，GPU 无额外重算容量 |
| 落地 | 兼容矩阵、实验、灰度、回滚、运维所有者 | 跨引擎接入，后端能力不对等 |
P7 型回答应能把一条方案讲到接口、状态、预算和验证闭环。P8 型回答还应比较资源组织和协议边界的替代方案，识别组织与演进成本，提出分阶段目标及退出条件。
不能只画“引擎→缓存→存储”三个框。至少还要画职责图、部署故障域图、正常与失败时序、资源状态图，并解释哪些是方案假设、哪些已有证据。
5. 编码与工程深度不能省略
| 练习 | 应证明的不变量 | 进一步追问 |
|---|---|---|
| 带容量限制的对象缓存 | 活跃读者不被普通淘汰，重复完成不重复释放 | 锁粒度、热点竞争、内存统计 |
| 同 key 在途加载合并 | 多个等待者共享任务，失败和取消都能正确唤醒 | 最后一个等待者退出时怎么办 |
| 异步 buffer 所有权 | 任务完成/取消确认之前不释放，旧回调无权操作新代际 | RAII、引用、线程安全和关闭顺序 |
| 分组命中折叠 | 不能跨过必需状态缺口；窗口语义单独处理 | 部分 rank/group、结果消费一次 |
| 有界重试与背压 | 失败不会形成无界任务、内存与回源放大 | 幂等、重试预算和公平性 |
实现语言随岗位选择。C++ 重点理解 RAII、move、原子与锁、内存模型和线程生命周期；Python/native 边界重点理解 buffer 所有权、跨进程地址、GIL 的适用范围和设备异步性。用清晰协议和可测不变量解释代码，不用“无锁一定快”代替分析。
6. 准备四份可被追问的材料
- 设计文档：需求、约束、两个备选方案、预算、协议、风险、验证和演进。
- 源码链路记录：一条保存、一条加载、一条取消，列出函数、状态、所有者和完成条件。
- 实验报告：冷基线、单变量对照、正确性、退化条件、原始数据和测量口径。
- 故障或设计复盘：症状、时间线、根因、修复、长期预防和仍未解决的问题。
有真实项目时说明自己负责的决策、协作边界和结果；没有真实集群证据时，可以提交推导与实验计划，但不能描述成已经生产落地。技术影响力应来自清晰目标、评审共识、交付与持续改进，而不是夸大参与范围。
7. 专家自评方法
对每个 P0 能力按下面的证据等级自评：
| 等级 | 判断标准 |
|---|---|
| 0 | 只认识术语，无法独立解释 |
| 1 | 能讲原理，但不能推导状态、预算或失败 |
| 2 | 能独立设计、算账、定位源码并分析失败 |
| 3 | 有可复现实现/实验或真实交付证据，能说明收益与局限 |
P7 型准备应让所有关键 P0 达到 2，并至少在一个完整子系统达到 3；P8 型还需跨层目标、协议与演进的闭环证据。这是学习自评，不是职级判定公式。 正确性、生命周期和故障回收的严重缺口不能被其他主题的高分抵消。
可进行一次 90 分钟模拟：10 分钟问题建模，25 分钟系统设计，20 分钟生命周期与故障追问，15 分钟源码或编码，15 分钟性能与成本，5 分钟演进复盘。每次把“说不清的假设”和“缺证据的结论”单独记录。
8. 怎样使用学习计划
28 天计划是查漏和整理作品的节奏，不能把从零学习到专家压缩成固定天数。已有相关经验者可以按它整合证据；缺少子系统实践者，应在协议正确性、性能实验和故障恢复三个阶段补足交付后再进入下一阶段。
主线：设计图册 → KV 存储详解 → 联合实现 → 系统设计与编码 → 实验与复盘。常规题库用于补薄弱点；公共问答与算例是底座，本篇是专家层的准备要求。