解读

面试官想知道三件事：

1. 你是否能把“毫秒级延迟”拆成可量化的技术指标（P99≤80 ms、QPS≥3 k、GPU利用率≤60 %）；
2. 你是否熟悉国内主流推理基建（阿里云 EAS、腾讯云 TI-EMS、字节跳动 BMInf、华为云 SIS、自研 K8s + Triton）；
3. 你能否把“权衡”做成可落地的决策流程，而不是一句“做蒸馏”就结束。

知识点

1. 延迟拆解：特征抽取（1020 ms）、模型推理（2040 ms）、召回后重排（1020 ms）、网络/序列化（510 ms）。
2. 国内监管红线：推荐算法需备案，不能因加速而跳过“日志留痕+可解释”环节。
3. 常用加速手段：
   • 模型侧：量化（INT8）、剪枝（50 %稀疏化）、蒸馏（Teacher 1.3 B → Student 110 M）、双塔解耦。
   • 工程侧：特征缓存 Redis+StarRocks、GPU 预热、Batch 动态 1→32、本地向量索引 Faiss-IVF1024。
   • 架构侧：三级漏斗（粗排 2000→300，精排 300→50，重排 50→10），粗排用轻量模型，精排上深度模型。
4. 决策指标：商业价值/延迟 弹性系数 = ΔCTR / ΔLatency；当系数 < 0.3 直接砍掉该特征或网络层。
5. 成本换算：一张 A10（24 G）约 1.4 万元/年，支撑 1.2 k QPS；若蒸馏后模型从 A10 降级到 T4，节省 45 % 预算，可直接算到 ROI。

答案

“我会把权衡拆成四步，确保业务指标和合规同时满足。

第一步，定红线。与核心推荐接口 SLA 对齐：P99≤80 ms、QPS≥3 k；同时留 20 % 缓冲给大促峰值。备案要求日志落盘不能异步，所以推理侧必须同步输出 128 bit 可解释向量，这 2 ms 不能省。

第二步，建基准。用线上 5 % 流量跑全量 Wide&Deep（200 M 参数）当 Reference，记录 CTR+Latency 基线；再跑轻量 DIN（40 M 参数）当 Candidate，形成 ΔCTR= –1.8 %、ΔLatency= –42 ms 的对比表。只要 CTR 降幅 > 2 %，就触发下一步优化，而不是直接上线。

第三步，系统级瘦身。

1. 特征瘦身：把 400 维实时统计特征换成 30 维“近 1 小时分桶均值”，离线评估 AUC 降 0.3 %，但特征抽取从 12 ms 降到 3 ms。
2. 模型瘦身：用自研蒸馏框架，把 12 层 Transformer 降到 4 层 + 2 层 Cross Attention，参数量 200 M→38 M；INT8 量化后再降 50 % 延迟，GPU 利用率从 92 % 降到 48 %，单卡 QPS 提升 2.3 倍。
3. 链路瘦身：粗排用双塔内积，Faiss-IVF1024 预载显存，单次查询 0.8 ms；精排只跑候选 50 条，Batch=50 合并推理，单条摊销 0.6 ms。

第四步，持续迭代。上线后开 10 % 灰度，实时监控“商业价值/延迟弹性系数”，若新特征使系数 < 0.3 立即回滚；同时把 GPU 预算省下的 45 % 费用，按季度返还给业务方，用 ROI 反向证明技术方案可持续。

通过这四步，我们把 P99 从 120 ms 压到 72 ms，CTR 提升 0.9 %，单 QPS 成本下降 38 %，并且一次性通过网信办算法备案。”

拓展思考

1. 如果业务突然要求 50 ms 以内，而 GPU 已无法扩容，可考虑“CPU+NEON int8 推理”做异构混部，但需评估 Cache Miss 带来的长尾；此时可把“重排”模型拆到客户端边缘计算，用端侧 GPU 跑 10 M 参数的轻量模型，把最后一英里延迟转移出服务端。
2. 国内大促场景下，凌晨 0 点流量 10 倍突发，可提前 48 h 把模型权重预热到本地磁盘，并用“弹性容器 + 竞价实例”临时扩容；但竞价实例可能被回收，需要把“降级开关”做到配置中心：一旦回收率 > 30 %，自动回退到纯双塔内积，保证可用性。
3. 长期看，模型复杂度与延迟的权衡会走向“动态架构”：同一网络根据实时 QPS 自动剪枝，比如用 SlenderNet 把 3 个 Expert 动态关掉 1 个，CTR 降 0.4 %，但延迟再降 15 %；产品经理需要把“动态剪枝”包装成白盒策略，写进备案材料，证明“可变结构”依然满足可解释与可追溯要求。