一次 Feed 请求
推荐在线服务的硬约束是端到端大约百毫秒（工程惯例，具体 SLA 随机房和机型变化）。下面是一次「要下一批视频」在单元内的调用形状。时间片是拆分方式，不是线上精确计时。
上滑
本地还有缓冲吗
缓冲不足：要下一批
鉴权并纠偏到本单元
并行召回加排序
约十条 meta
ID / 封面 / 播放地址
拉当前和下一条视频
媒体流
出画
异步上报划走或完播
01 · 播放器决定要不要打 Feed
0–10ms 端上
本地还缓冲着下两条时不请求。预加载把 RTT 藏进观看时间。弱网时 MNet 切协议、降码率，而不是把压力交给推荐集群。
02 · 就近入口 + 网关
接入 5–20ms
DNS/GTM 按 GEO/ISP 落到最近 Region。DCDN 加速 API。网关做鉴权、设备风控、配额、单元纠偏，把请求打到本单元 Feed 编排服务。媒体 URL 不在这里传输。
03 · 画像 · 序列 · 多路召回
并行 20–40ms
编排服务一次 fan-out：Abase/Redis 拉 user profile 与实时序列；ANN 双塔召回；倒排/热门/同城/社交（ByteGraph 一跳关注）并行。单路超时直接丢，用降级候选补齐。
04 · 轻模型截断到百级
粗排 ~10ms
千级候选做向量点积或浅层网络。粗排模型和精排特征不同源，避免把精排特征服务打满。
05 · 特征拼接 + 模型前向
精排 20–40ms
特征服务点查（在线 KV 已是聚合好的窗口结果）。稀疏 ID 去 serving PS 查 embedding，稠密网络前向。Backup Request 切除长尾 PS。
06 · 规则 · 打散 · 混排
重排 <5ms
同一作者连续出现、相似度打散、安全打压、广告/直播插入、频控。输出约 8–12 条 meta：视频 ID、封面、多码率播放地址。
07 · CDN 出流，滑动进总线
播放与回流
播放器按 ABR 拉融合 CDN。曝光/完播/划走异步进 BMQ/Kafka，Flink 更新实时特征，Monolith worker 消费样本写训练 PS。这条路径绝不能同步阻塞下一次 Feed。
超时与降级
多路召回是 OR 关系：一路挂了应减少多样性，而不是 500。每路独立超时，超时返回空集。精排特征缺失要有默认值，并监控覆盖率。最终兜底是本单元最近一次成功 Feed、热门池、运营保底池。空 Feed 比错 Feed 更不可接受。