题目重点：先量化延迟预算和瓶颈，再在候选数、特征获取、模型级联与缓存间取舍，并守住推荐质量。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 训练场景为在线召回→特征→排序→返回，多阶段有 trace；先确认 SLO 是 p50/p95/p99、客户端端到端还是服务器内部。
- 优化必须与线上质量/安全指标成对验证；没有延迟数据不能预先断定模型是瓶颈。
解题路线
- 先分解端到端 trace：网络、候选召回、远程特征、模型推理、后处理和排队。按 p50/p95/p99 与 cache hit/miss、用户/请求类型切片；CPU/GPU 利用率、队列深度和 fanout 超时定位尾部。
- Infra 侧可批量取特征、复用索引连接、热点候选/静态特征缓存、控制跨服务 fanout、做异步预计算和请求 deadline。缓存要带用户权限与特征版本，不能缓存过期职位或私有特征。
- ML 侧可减少进入重排的候选 K、用两级模型先轻排再精排、蒸馏/量化模型、特征裁剪、批推理与早退出。各方案量测 Recall/NDCG/点击/申请等质量损失和不同用户切片，按延迟预算选。
- 设置超时降级：重排超时回退经过硬过滤的轻排结果，缺失实时特征用已知有效的默认/缓存并标记；不能因降级绕过安全/权限。上线用 shadow 与小流量 A/B，监控延迟和业务指标双回归。
手动走一遍
Trace 显示 p99 从 150ms 升到 900ms，其中远程特征 fanout 占 700ms；先批取与限时回退，而不是先量化模型。若后续发现重排计算占 300ms，再测试减少候选从 1,000 到 200 对召回/质量的影响。数值仅示例，非题目规模。
规模与取舍
候选召回 K、特征 fanout F、模型每候选成本 C_model：重排约 O(K×C_model)，远程并行延迟受最慢分支和队列影响，不能只把 F 个请求均值相加。题目没有具体规模；容量规划应由测量得到。
易错点与追问
容易失分的边界
- 没有 trace 就宣称是模型慢。
- 只优化平均延迟、忽略 p99 尾部。
- 缩候选/量化后不看推荐质量。
- 权限或职位过期仍命中缓存。
- 超时降级绕过硬过滤。
继续深挖
- p99 慢但 p50 正常，优先看什么？
- 召回 K 缩小会损失哪些用户？
- 特征新鲜度与缓存命中如何取舍？
- GPU batch size 增大为何可能提高吞吐却拉高单请求尾延迟？
