大流量业务想利用 3B 模型效果但不能实时调用时，如何设计离线推理、特征/结果缓存、蒸馏或轻量模型接力方案，并验证效果、时延和成本？｜字节跳动算法面经解析

60 秒回答模板

大流量业务如果不能实时调用 3B 模型，我会先拆清楚模型到底提供什么能力：是内容理解、用户意图识别、候选排序、风险判断，还是生成式解释。只要能力不强依赖当前毫秒级上下文，就优先做离线化。离线推理可以按内容、用户、作者、商品、候选 pair 或场景模板批量产出 embedding、标签、质量分、风险分、语义分等结果，再写入特征库或结果缓存，在线链路只做读取和轻量融合。缓存设计要有版本和新鲜度意识。结果 key 不能只用对象 ID，还要包含模型版本、特征版本、业务场景和时间窗口；对于变化快的内容或用户行为，要做增量推理和 TTL；对于热点对象，可以预热缓存；对于 miss 或过期，可以回退到轻量模型、规则或上一版本结果。这样 3B 模型主要在离线 GPU 集群消耗算力，在线服务只承担低延迟读缓存和简单计算。如果实时上下文很重要，就用蒸馏或接力方案。可以把 3B 模型作为 teacher，生成软标签、排序偏好或解释性特征，训练小模型在线推理；也可以做两阶段架构，在线先用轻量模型或规则覆盖全量流量，只对低置信、长尾、高价值或抽样请求调用较重模型的离线近实时更新。验证时不能只看离线指标，要同时看线上 A/B 的 CTR、CVR、留存或审核准确率，P95/P99 时延，缓存命中率，结果新鲜度，GPU/CPU 成本和单位请求成本。

考点 稳定能力离线化

难度 真实面经题

回答目标 让面试官看到候选人具备大流量系统思维，能把大模型能力拆成可离线、可缓存、可蒸馏和可灰度验证的工程方案，而不是简单说模型太慢就不能用。

深入解析

拆模型价值

先判断 3B 模型贡献的是语义理解、排序分、标签、风控还是解释，并识别是否必须实时。只有知道模型能力落在哪个业务环节，才能决定是离线算特征、缓存结果、蒸馏小模型还是抽样调用。

设计离线推理

按全量、增量、热点和高价值对象分批跑，产出可被在线链路读取的特征或结果。内容语义、作者质量、商品标签和稳定画像通常适合离线，用户会话意图等快变量则需要在线轻量修正。

建立缓存与特征库

key 包含对象、场景、模型版本、特征版本和时间窗口，支持 TTL、预热、回退和灰度。没有版本和新鲜度管理，线上效果变差时很难判断是模型问题、特征过期还是缓存污染。

在线轻量接力

用小模型、规则、线性融合或树模型消费离线特征，保证主链路低延迟。在线层负责结合实时上下文做最后调整，而不是让 3B 模型卡在每次请求的同步路径上。

做蒸馏压缩

用 3B teacher 产生软标签、排序偏好、边界样本和解释性特征，训练 student 在可接受效果损失下覆盖实时请求。蒸馏评估要看 student 与 teacher 一致率，也要看线上业务指标。

验证整体收益

用离线指标、线上 A/B、P95/P99 时延、缓存命中率、成本和新鲜度共同评估。单看模型准确率不够，因为高流量业务还关心单位请求成本、服务稳定性和缓存 miss 降级质量。

易错点

只说加缓存，但不说明缓存 key、版本、TTL、回退和一致性。
把所有 3B 能力都离线化，忽略实时上下文对结果的影响。
只做离线 AUC 或准确率，不做线上 A/B 和时延成本验证。
蒸馏只追求小模型指标，没分析 teacher 的软标签质量和边界样本。
缓存 miss 直接实时调用重模型，导致高峰期成本和延迟失控。
没有监控结果新鲜度，离线分数过期后仍然影响线上排序或决策。

面试官追问

如果用户实时行为变化很快，离线结果会不会过期？

会，所以要把特征分成慢变量和快变量。内容语义、作者质量等慢变量适合离线；用户最近点击、会话意图等快变量由在线轻模型处理。融合时让离线 3B 特征提供强语义底座，在线特征负责实时修正。

缓存 miss 时怎么办？

要有明确降级链路：先读上一版本或近邻结果，再用轻量模型补充，最后用规则兜底。高价值对象可以触发异步补算，但不能阻塞主请求。

怎么判断蒸馏后小模型是否可用？

先看 student 与 teacher 的一致率、排序相关性和关键 bad case 覆盖，再看线上业务指标和时延成本。可用不代表完全追平 teacher，而是在可接受效果损失下显著降低在线成本。

离线推理频率怎么定？

由对象变化速度和业务容忍的新鲜度决定。热点内容可能分钟级或小时级增量更新，稳定画像可天级更新。评估时要监控特征年龄分布和新鲜度对业务指标的影响。