01

60 秒回答模板

推荐精排 serving 的优化目标不是单纯把模型跑快，而是在 P99 延迟、QPS、资源成本和线上收益之间找到平衡。我会先拆链路：请求进入后要取用户/上下文特征、召回候选、补 item 特征、组装特征、批量模型推理、后处理和打散。精排推理慢可能来自模型本身、候选数过多、特征读取慢、序列特征太长、跨服务 RPC、CPU/GPU 利用率低或 batch 调度不合理。 优化手段可以分层做。模型侧做蒸馏、剪枝、量化、特征裁剪、embedding 维度压缩、双塔预打分、轻重模型级联和多目标头合并；特征侧做缓存、特征预计算、序列截断/摘要、近线特征刷新和缺失兜底；服务侧做候选数动态截断、micro-batching、异步并发、RPC 合并、线程池隔离、GPU/CPU 混部、熔断降级和热点缓存。验证时先离线看排序指标损失，再压测 RT/P50/P95/P99、QPS、CPU/GPU 利用率、内存、成本，最后线上 A/B 看 CTR、CVR、GMV、时长、负反馈和生态护栏。任何优化都要证明性能收益没有吞掉业务收益。

考点 先用 tracing 拆精排 serving 全链路耗时
难度 真实面经题
回答目标 让候选人能系统设计推荐精排推理优化方案，并用性能、成本和业务指标证明收益。
02

深入解析

01

链路拆解

精排耗时不只在模型。特征读取、候选数量、序列构造、RPC、后处理和打散都可能成为瓶颈。先用 tracing 找 P99 最大贡献段。

02

模型优化

可用蒸馏、量化、剪枝、embedding 压缩、特征选择、轻重模型级联和算子融合。要记录排序指标损失，避免只追求 latency。

03

特征优化

将稳定特征离线或近线预计算，热点 item 特征缓存，用户序列截断或聚合，缺失特征快速兜底。特征读取慢常常比模型算子更影响 P99。

04

服务调度

通过 micro-batching、异步并发、候选动态裁剪、线程池隔离、RPC 合并、GPU 批推理和超时降级提升吞吐并控制尾延迟。

05

降级策略

高峰或依赖异常时，可减少候选数、切轻模型、使用缓存分数、关闭部分重特征或回退规则排序。降级要可观测且有业务护栏。

06

收益验证

压测看 RT/P99、QPS、资源利用率和单请求成本；线上看 CTR/CVR/GMV/时长和负反馈。性能优化只有在业务指标可接受时才算成功。

03

易错点

  • 只说换小模型，不拆服务链路瓶颈。
  • 只看平均延迟，不看 P95/P99 和高峰。
  • 特征读取和 RPC 慢被忽略。
  • 优化后不看排序质量和线上业务损失。
  • 没有降级和熔断，负载升高时尾延迟失控。
  • 压测流量形态与真实线上候选数、特征分布不一致。
04

面试官追问

量化后离线 AUC 几乎不变，线上就一定安全吗？

不一定。还要看分层人群、长尾 item、校准、延迟分布和线上业务指标。量化误差可能集中在少数重要样本或影响分数排序边界。

micro-batching 会带来什么副作用？

它提高吞吐但可能增加排队延迟，尤其低流量或严格实时场景。要设置最大等待时间和 batch size，并监控 P99。

候选数动态裁剪怎么做？

可按请求预算、召回质量、用户活跃度和系统负载动态调整。高置信候选少的请求少排一些，低置信或高价值请求保留更多候选。

如何证明优化降低了成本？

比较同等流量下机器数、CPU/GPU 利用率、QPS/核、QPS/GPU、单千次请求成本和扩容需求，同时确认业务指标没有显著下降。