10. 面试题
从「会背概念」到「会算账」：端侧推理的面试核心是三本账的口算能力。
10.1 初级
Q1：为什么端侧 LLM 推理是带宽受限而不是算力受限？
decode 每生成一个 token 只计算一个向量与权重的矩阵-向量乘，FLOPs 极少但要把全部权重字节从内存读一遍，算术强度（FLOP/Byte）远低于芯片的算力带宽比，所以时延由「搬运多少字节 ÷ 带宽」决定。prefill 相反：一次处理整段 prompt，矩阵-矩阵乘算术强度高，是算力受限。
Q2：GQA 对端侧推理意味着什么？
KV cache 每 token 字节数 = 2 × 层数 × KV 头数 × head_dim × 字节数。GQA 把 KV 头数从 32（MHA）降到 4-8，KV 容量需求同比缩小 4-8 倍——在内存恒定下，上下文长度上限同比放大。对带宽账也有间接收益：decode 时 KV 工作集更小。端侧选型几乎应排除非 GQA 模型。
Q3：llama.cpp 的 mmap 加载是什么，为什么要默认开启？
权重文件直接映射进进程地址空间而不一次性读入内存：启动几乎零成本，页按需缺页换入，OS readahead 提供预取。好处是启动快、内存按需增长、多模型共存可行。代价是首 token 有缺页惩罚，可用 mlock 或预热换确定性。
Q4：端侧量化为什么常用 Q4_K_M 而不是整网 INT4？
K-quant 类混合量化对不同张量类型用不同粒度（attention 层更敏感用更高位宽），等效位宽约 4.5-4.8 bit，比整网 INT4 精度损失小得多，而体积几乎一样。端侧没有数据中心级别的精度回归资源，选择「社区已验证的甜点配方」是最优策略。
10.2 中级
Q5：手算：8B 模型（32 层、8 KV 头、head_dim 128）Q4_K_M 权重 5.18 GB，在 68 GB/s 带宽设备上的 decode 上限？再加 MTP（α=0.75、γ=4、draft 成本比 0.15）呢？
decode 上限 ≈ 68 × 0.85 ÷ 5.18 ≈ 11.15 tok/s。MTP 期望每验证循环产出 (1−0.75⁵)/(1−0.75) ≈ 3.05 token，每循环时间 = 1 + 4×0.15 = 1.6 单位，加速比 ≈ 1.91，叠加后 ≈ 21.3 tok/s。追问：为什么加速比不是 3.05？因为 draft 本身要花时间。
Q6：NPU 算子覆盖不足时，运行时怎么处理？代价是什么？
沿能力表回退到 GPU/CPU。代价是传输税（张量经统一内存 fabric 搬运）加慢设备计算时间。Demo 量级：单层 prefill 回退 softmax + 两个 norm，传输税占 16.8%。治理手段：编译期 lower 验证、算子融合批量搬运、把损失大的算子改写进 NPU 支持集。
Q7：设计端云路由策略，机密请求端侧 25 s 但 SLO 是 10 s，怎么办？
隐私是硬约束，不能因超时上云。可行手段：优化端侧路径（更长上下文没必要时裁剪 prompt、开投机解码、确认稳态数字是否被低估）；与产品协商放宽 SLO 或降级输出长度；最后一招是显式告知用户进度而非假装快。任何「悄悄上云」都是事故。
Q8：同一 LoRA adapter，热切换和权重合并怎么选？
热切换：adapter 以低秩增量驻留（rank16 全层约 56 MiB），切换一次约 2 ms，内存比合并方案省 99.5% 以上，适合端侧多 adapter。合并：切换零成本但每 adapter 需一份全量权重副本（8B fp16 约 12 GB），端侧不可行。数据点：8 GiB 设备可驻留 40+ 个热切换 adapter，连一份合并副本都放不下。
Q9：端侧 benchmark 为什么要报「稳态」数字？怎么测？
热节流使性能随时间衰减（峰值 ×0.6-0.7），冷启动数字外推长对话会系统性乐观。测法：预热后连续推理至热平衡（或用 45°C 环境箱加速），取 60 s 窗口均值；同时报 30 分钟准稳态。准入与路由估时都应用稳态数字。
10.3 高级
Q10：推导投机解码的期望加速比，并说明端侧与云端应用的差异。
几何接受模型：E[每循环产出] = (1−α^(γ+1))/(1−α)；每循环时间 = T_target × (1+γd)，d 为 draft 单步与 target 单步的时间比；加速比 S = E/(1+γd)。端侧差异：draft 可放 GPU/CPU 错开 NPU 带宽竞争（d 更可控）；接受率 α 领域敏感（闲聊 0.8+，代码 0.5 以下），需按会话滑动窗口动态开关与选 γ；内存受限端 draft 模型常驻有成本，小模型/MTP 头是更优载体。
Q11：8 GiB 手机要支持 32k 上下文，技术路线有哪些？各自代价？
账：32k × 128 KiB（FP16 KV，8 KV 头）= 4 GiB，加权重 4.83 GiB + 保留 0.8 GiB 已超。路线：a) KV 量化到 INT4（32 KiB/token → 1 GiB），代价是长上下文注意力精度回归需验证；b) 换更小 KV 占用的模型（更多 GQA/MLA 类架构）；c) 滑动窗口/稀疏注意力改算法层；d) 上下文摘要压缩（产品层）。通常 a+d 组合落地最快。
Q12：Private Cloud Compute 的可验证性设计给端云协同什么启示？
PCC 的做法：无状态节点、端到端加密、生产构建全部公开到防篡改日志、设备只连接与日志匹配的节点、盲签名凭证防定向追踪。启示：端云协同的信任不能只靠「服务商承诺」，要落到密码学可验证的透明机制上——对任何做企业端云产品的团队，「可验证」正从加分项变成采购门槛。
Q13：Jetson 边缘盒与手机跑同一个 8B 模型，系统设计上的三个最大差异？
散热（可近似持续性能，不用打七折）、供电（可上大功耗模式）、内存（64 GB 版 KV 预算宽 8 倍，可做长上下文与多会话并发）；反过来手机的统一内存零拷贝与功耗敏感调度是 Jetson 不需要的。软件栈差异次要（Jetson 可用 TensorRT-LLM 全功能栈）。
10.4 本章小结
端侧面试的护城河是「口算三本账」：给带宽算 tok/s、给内存算上下文、给回退算税；在此之上才是对六大运行时与生态演进的真实了解。