OneRec-V2 Technical Report
Guorui Zhou, Hengrui Hu, Hongtao Cheng, Huanjie Wang, Jiaxin Deng, Jinghao Zhang, Kuo Cai, Lejian Ren, Lu Ren, Liao Yu, Pengfei Zheng, Qiang Luo, Qianqian Wang, Qigen Hu, Rui Huang, Ruiming Tang, Shiyao Wang, Shujie Yang, Tao Wu, Wuchao Li, Xinchen Luo, Xingmei Wang, Yi Su, Yunfan Wu, Zexuan Cheng, Zhanyu Liu, Zixing Zhang, Bin Zhang, Boxuan Wang, Chaoyi Ma, Chengru Song, Chenhui Wang, Chenglong Chu, Di Wang, Dongxue Meng, Dunju Zang, Fan Yang, Fangyu Zhang, Feng Jiang, Fuxing Zhang, Gang Wang, Guowang Zhang, Han Li, Honghui Bao, Hongyang Cao, Jiaming Huang, Jiapeng Chen, Jiaqiang Liu, Jinghui Jia, Kun Gai, Lantao Hu, Liang Zeng, Qiang Wang, Qidong Zhou, Rongzhou Zhang, Shengzhe Wang, Shihui He, Shuang Yang, Siyang Mao, Sui Huang, Tiantian He, Tingting Gao, Wei Yuan, Xiao Liang, Xiaoxiao Xu, Xugang Liu, Yan Wang, Yang Zhou, Yi Wang, Yiwu Liu, Yue Song, Yufei Zhang, Yunfeng Zhao, Zhixin Ling, Ziming Li
cs.IR
2025-08-28
快手OneRec-V2用懒解码器把上下文编码从97.66%算力压到接近零,预训练扩到80亿参;线上相对V1,主端与极速版停留时长分别涨0.47%和0.74%。
OneRec 把短视频推荐改写成自回归生成:先把候选编成语义 ID,再像语言模型一样逐 token 往外吐。V1 已经在快手上线,但两处结构把继续扩参卡住了。
第一处是算力分配。V1 是 encoder-decoder,用户历史走 encoder,目标物品走 decoder 的 cross-attention。上下文长度 512 时,上下文编码吃掉 97.66% 的 FLOPs,真正生成目标物品只占 2.34%。参数看起来在 decoder 里,算力却耗在 encoder 上。第二处是强化学习。V1 只靠奖励模型打分,在线采样贵,只能覆盖约 1% 用户,还容易被代理奖励 hack。
OneRec-V2 要做两件事:把算力从「读历史」挪到「写下一个物品」,以及用真实播放反馈对齐偏好。
Lazy Decoder-Only 把用户画像和行为序列交给 Context Processor,一次性投影成各层共享的 key-value,不再给 K/V 做额外线性层。Decoder 只吃 BOS 加目标物品的 3 个语义 ID,块内是懒 cross-attention、因果 self-attention 和 FFN。多层 decoder 复用同一组 KV,再配 Grouped Query Attention 压 KV 体积。训练损失只加在「最新曝光」的目标物品上,避免按曝光切片造成的重复 next-token、也避开按用户整段历史训练带来的时间泄漏。
1B 稠密模型上,这条结构大约 18.9 GFLOPs,encoder-decoder 1:1 对照是 296 GFLOPs,算力砍掉约 94%,训练资源大约省 90%。稀疏版用 53 个 routed 专家加 1 个共享专家,4B 总参、0.5B 激活。
后训练先用流式曝光做监督微调,再上基于真实反馈的 RL。播放时长按用户历史、对数分桶后的同长度视频做分位数,压掉「长视频天然看得久」的偏差;每个 batch 里取分位数最高的 25% 当正样本,显式点踩当负样本,其余优势为 0。优化器用 GBPO:不去 clip 掉样本,改用动态下界把负样本梯度按住,避免概率已经很小的负例把梯度炸开。
架构对比在 2025 年 8 月 10 日至 14 日的快手曝光流上,固定采样比和全局 batch。稠密 lazy decoder 从 0.1B 收到 8B,收敛生成损失从 3.57 降到 3.19,拟合 L=3.13+3660/N^0.489,和固定数据量下的 Chinchilla 形式一致。4B MoE(0.5B 激活)损失 3.22,优于 2B 稠密的 3.23,算力仍接近 0.5B 稠密。KV 共享和 GQA 几乎不伤损失,KV 体积可以降一个数量级。
线上对照是 OneRec-V1。1B 模型、上下文约 3000、beam 512,L20 推理延迟 36ms、MFU 62%。为降低系统复杂度,全量实验只开了用户反馈 RL,没用奖励模型混合。5% 流量、一周、约 4 亿日活的主端与极速版:
| 场景 | 停留时长 | 观看时长 | 点赞 | 评论 |
| 快手主端 | +0.467% | +1.367% | +3.924% | +5.394% |
| 快手极速版 | +0.741% | +0.762% | +5.393% | +5.013% |
主端 LT7 +0.069%。只喂传统链路样本时,停留时长涨、播放量跌;混入 OneRec 自己曝光的样本后,播放量转正,点赞、关注、评论一起涨,说明生成式推荐可以用自己的流量做 on-policy 迭代。
生成式推荐的扩参瓶颈经常不在 decoder 宽度,而在「历史有多长」。把上下文当成静态条件、只在短目标序列上花 FLOPs,8B 预训练才负担得起。对已经上了语义 ID 生成式推荐的团队,可直接抄懒 KV 和「损失只打在最新曝光」。GBPO 加时长分位数,是把 LLM 里的 policy 优化搬到稀疏、有偏的播放信号上,不是换一套模型结构那么简单。
作者自己写了:奖励仍是用规则把短时播放接到长时满意,模型并没有直接优化长期价值。架构对比窗口只有四天曝光;全量 A/B 是 5% 流量一周,LT7 的 +0.069% 统计上很瘦。8B 只出现在预训练损失曲线,线上仍是 1B。语义 ID 仍是 V1 的 3 段,上下文被当成静态 KV,不会在 decoder 里被反复改写。GBPO 相对 PPO/GRPO 的线上对照没有单独开出来,看到的是奖励模型、真实反馈、两者混合三组。