题目重点：MLE onsite 明确问精排输入候选量，按召回质量、模型复杂度、分布式实例吞吐和延迟预算推算，不套固定数。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 训练版一次 feed 请求最多从多源召回 C 个去重候选，每候选精排成本 f 秒 GPU 时间；线上有 Q QPS 与 I 个模型实例。
- ‘几千’是这篇题目讨论的数量级，具体服务必须用本模型、硬件、batch、目标召回率和 p95 延迟实测。
解题路线
- 先画候选数 C 与可用相关内容覆盖 Recall@C 的曲线，观察增加候选的边际收益在哪一段变小。
- 量测每候选精排成本和 batch 吞吐，估算每请求模型工作量 C×f 与全站每秒工作量 Q×C×f；按实例有效利用率和余量计算 I，不能用理论 FLOPs 当真实吞吐。
- 将请求延迟拆成召回、特征、网络、排队、粗排、精排、重排；C 太大时先粗排到 c，再精排高成本模型。
- 用线上流量与候选分布压测 p95/p99，特别看热门用户/大候选集、实例失效和跨区调用；结合质量与成本选可运营的 C。
手动走一遍
假设 Q=1,000 请求/秒，精排实例稳定吞吐 200,000 candidate/秒，目标利用率 50%，则每实例可安全承载约 100,000 candidate/秒。C=2,000 时每秒需 200 万 candidate，至少约 20 个实例；C=5,000 时约 50 个。还须看 p95 单请求时延与 Recall@C 的收益，不能仅凭这个吞吐算式决定上线。
规模与取舍
计算工作量随 Q×C 线性增长；若特征拉取和模型调用分别按 batch 合并，实际 p95 不简单等于 C×单样本延迟。候选数的合理上限是质量收益、成本和时延共同约束的结果。
易错点与追问
容易失分的边界
- 直接背‘几千’而不知道当前模型吞吐与召回曲线。
- 只算平均 QPS，不留峰值、故障和尾延迟余量。
- 忽略粗排后精排的两级成本。
- 混淆召回候选数量、粗排输出数和最终展示数。
继续深挖
- 新模型计算量翻倍但质量只小幅提升，怎样调候选数？
- 不同用户兴趣历史量不同，是否可以动态分配 C？
- 跨多个兴趣向量召回时，如何分配每路配额并去重？
