论文信息：OneTrans: Unified Feature Interaction and Sequence Modeling with One Transformer in Industrial Recommender
发表：WWW 2026
核心结果：线上 A/B 测试人均 GMV 提升 5.68%，同时推理延迟下降 3.91%
1. 问题与动机
工业推荐系统长期沿用 "先编码，后交互"（Encode-then-Interaction） 的两阶段流水线架构：
- 第一阶段：用独立的序列模型（DIN / SASRec / LONGER 等）将用户行为序列压缩为固定长度向量；
- 第二阶段：将该向量与其他静态/上下文特征拼接后，送入特征交互模块（DCNv2 / DeepFM / RankMixer 等）做最终打分。
这种架构带来两个核心问题：
- 信息流单向受限：序列模型输出的向量是"冻结的"，特征交互模块无法反向影响序列表征。例如，当前上下文（时间、地点、候选商品属性）无法动态调整用户兴趣的聚合方式——信息只能从序列流向交互层，不能反向流动。
- 优化目标割裂：两个模块各自独立优化，缺乏端到端的统一梯度信号，限制了模型整体的表达能力。随着模型规模增大（参数从百万到数亿），这种架构瓶颈越来越成为 scaling 的天花板。
此外，从工程角度看，维护两套异构模块（一套序列模型 + 一套特征交互网络）增加了系统复杂度，也不利于复用 LLM 生态中成熟的训练和推理优化技术（FlashAttention、KV Cache 等）。
核心动机：能否用 一个统一的 Transformer 骨干网络，同时完成序列建模和特征交互，打破信息流壁垒并继承 LLM 的工程优化红利？
2. 方法概述
OneTrans 的核心思路是：将所有特征——无论是用户行为序列还是静态/上下文属性——统一转化为 token 序列，用一个 Transformer 栈一体化处理。
整体流程分为三步：
2.1 统一分词（Unified Tokenization）
- 序列特征（S-tokens）：将用户的多种行为序列（点击、加购、购买等）分别通过序列专属 MLP 映射到统一维度 d，再按时间戳排序合并为一条统一序列，不同行为序列之间插入可学习的
[SEP]token。 - 非序列特征（NS-tokens）：提出两种分词器：
- Group-wise Tokenizer：按语义分组（如用户画像组、商品属性组），每组经独立 MLP 生成一个 token；
- Auto-Split Tokenizer（推荐）：所有非序列特征拼接后通过单个 MLP 投影再切分，减少 kernel launch 开销。
最终输入序列为：X = [S-tokens; NS-tokens]。
2.2 OneTrans Block（混合参数化 Transformer）
在标准 Transformer block 上做了关键修改——Mixed Parameterization：
- S-tokens 共享参数：行为序列中的 token 共享同一组 Q/K/V 投影和 FFN 参数（因为它们是同质的、大量的）；
- NS-tokens 使用 token-specific 参数：每个非序列 token 有独立的 Q/K/V 投影和 FFN（因为它们是异质的、数量少）。
注意力掩码设计：采用因果注意力（Causal Attention），S-tokens 只能看到之前的 S-tokens，NS-tokens 可以看到所有 S-tokens 和前面的 NS-tokens。这确保了：
- 序列内部的自回归建模
- 跨序列的交叉建模
- 静态特征与序列的双向交互
2.3 金字塔堆叠（Pyramid Stack）
利用因果注意力的"近端注意力集中"特性，逐层递减 S-tokens 的 query 数量（仅最近的 S-tokens 发出 query），而 key/value 保持全序列。这样查询集从 1190 个 token 逐层缩减到 12 个，将注意力复杂度从 O(L²d) 降至 O(LL'd)，相当于用更少的计算逐层蒸馏长序列信息。
3. 核心技术贡献
| 贡献 | 具体内容 | 与现有方法的区别 |
|---|---|---|
| 统一架构 | 一个 Transformer 同时做序列建模 + 特征交互 | InterFormer 仍维持两套独立模块通过 summary 桥接；OneTrans 彻底消除架构边界 |
| 混合参数化 | S-tokens 共享参数，NS-tokens 独立参数 | 纯共享会丢失异质特征区分度；纯独立参数量爆炸。混合方案兼顾效率与表达力 |
| 统一分词器 | Auto-Split Tokenizer 将所有特征映射为统一 token 空间 | 传统方法将序列压缩为单一向量后拼接，信息损失大 |
| 金字塔堆叠 | 逐层剪裁 query 集，同等 FLOPs 下序列长度提升 1.75× | 标准 Transformer 序列长度受限于 O(L²) 复杂度 |
| 跨请求 KV 缓存 | 将 S-tokens 的 KV 缓存跨请求复用，新请求只需计算增量行为 | 传统方法每次请求重新编码全部序列；OneTrans 将复杂度从 O(L) 降至 O(ΔL) |
| LLM 优化技术复用 | FlashAttention-2 + BF16 混精度 + 激活重计算 | 统一 Transformer 架构使得这些 LLM 社区的成熟优化可以直接使用 |
最关键的创新：不是某个单点技术，而是 架构统一化带来的系统性收益——当序列建模和特征交互共享同一组参数和计算图时，双向信息流自然打通，LLM 工程优化自然适配，scaling law 自然涌现。
4. 实验结果分析
4.1 离线实验
数据规模：291 亿展现、2790 万用户、1020 万商品（工业级电商数据集）。
| 模型 | CTR AUC↑ | CTR UAUC↑ | CVR AUC↑ | CVR UAUC↑ | 参数量 | FLOPs |
|---|---|---|---|---|---|---|
| DCNv2+DIN (baseline) | — | — | — | — | ~10M | — |
| RankMixer+LONGER | +0.95% | +1.46% | +0.72% | +1.38% | — | — |
| OneTransS (91M) | +1.13% | +1.77% | +0.90% | +1.66% | 91M | 2.64T |
| OneTransL (330M) | +1.53% | +2.79% | +1.14% | +3.23% | 330M | — |
关键发现：
- OneTransS 在与 RankMixer+Transformer（2.51T FLOPs）相近计算量下，性能全面超越，说明统一建模本身比堆叠独立模块更高效。
- CVR UAUC 提升幅度（+3.23%）远大于 CTR（+2.79%），说明转化行为更依赖特征间的深层交互，统一架构在此受益更大。
4.2 消融实验亮点
- 去掉
[SEP]token：-0.13%，说明多行为序列的边界信息很重要。 - NS-tokens 改为全共享参数：-0.15%，证明异质特征需要独立参数化。
- 因果注意力 vs 全注意力：性能相当，但因果注意力支持 KV Cache，工程收益巨大。
- 金字塔堆叠在同等 FLOPs 下可处理 1.75× 更长的序列。
4.3 系统效率
各优化手段的累积效果（相对未优化 OneTransS）：
| 优化手段 | 训练时间↓ | 显存↓ | 推理延迟↓ |
|---|---|---|---|
| + 金字塔堆叠 | -28.7% | -42.6% | -8.4% |
| + 跨请求 KV Cache | -30.2% | -58.4% | -29.6% |
| + FlashAttention | -50.1% | -58.9% | -12.3% |
| + 混精度+重计算 | -32.9% | -49.0% | -69.1% |
最终 OneTransL（330M 参数）的 p99 延迟为 13.2ms，反而低于 DCNv2+DIN（10M 参数）的 13.6ms。参数量增加 33 倍，延迟更低——这是工程优化与架构设计协同的成果。
4.4 线上 A/B 测试
在两个生产场景部署（对比 RankMixer+Transformer）：
| 场景 | 点击/人↑ | 订单/人↑ | GMV/人↑ | p99 延迟↓ |
|---|---|---|---|---|
| 信息流 | +7.74% | +4.35% | +5.69% | -3.91% |
| 商城 | +5.14% | +2.58% | +3.67% | -3.26% |
额外收益：用户活跃天数 +0.75%，冷启动商品订单 +13.59%。
5. 局限与未来方向
现有局限
- 序列长度瓶颈：虽然金字塔堆叠和 KV Cache 大幅降低了成本，但论文中最长序列约为千级别。面对 LLM 动辄 128K 上下文的趋势，推荐场景中超长行为序列（如数月甚至数年的浏览历史）的高效建模仍有空间。
- 多任务/多场景适配：论文聚焦于 CTR 和 CVR 两个任务，但工业系统通常包含数十个目标（时长、关注、分享等）。统一架构下多任务的参数共享与冲突问题未深入讨论。
- 特征类型覆盖：当前方案主要处理 ID 类和数值类特征。对于文本（商品标题）、图像（商品图片）等多模态特征如何融入统一 token 序列，论文未涉及。
- 冷启动的系统性解决：虽然线上实验显示冷启动商品订单提升 13.59%，但缺乏对冷启动机制的深入分析。
未来方向
- 与 LLM 的进一步融合：既然架构已经统一为 Transformer，下一步自然是引入预训练语言模型的知识（如用 LLM embedding 初始化 token），甚至统一推荐与自然语言理解。
- 多模态统一分词：将图像 patch token、文本 token 也纳入统一序列，实现真正的全模态推荐 Transformer。
- 稀疏注意力与超长序列：引入 Ring Attention、Sliding Window 等机制，将行为序列扩展至万级甚至十万级。
- 动态金字塔剪裁：目前的 pyramid 结构是静态配置的，可以探索根据输入动态调整每层的 query 数量。
6. 工业实践意义
6.1 架构范式转移的信号
OneTrans 代表了工业推荐系统从 "模块拼装"到"统一骨干" 的范式转移。过去十年，推荐系统的典型做法是不断叠加专用模块（Embedding → 序列模型 → 交叉网络 → Tower → 融合层），每个模块独立演进。OneTrans 证明：用一个设计良好的 Transformer 替代整条流水线，不仅效果更好，工程上也更简洁。
6.2 LLM 技术栈的直接复用
这是本文最具实践价值的贡献之一。统一为标准 Transformer 后：
- FlashAttention、PagedAttention 等推理优化直接可用
- 混精度训练、梯度检查点 等训练优化零成本接入
- KV Cache 不再需要专门设计，因果注意力自然支持
- 未来 LLM 社区的任何新优化都可以低成本迁移
这意味着推荐系统可以搭上 LLM 基础设施的"顺风车"，大幅降低工程投入。
6.3 跨请求 KV Cache 的工程启示
在推荐系统中，同一用户在短时间内会触发多次请求（刷新、翻页等），用户行为序列的大部分是不变的。跨请求 KV Cache 将序列编码的复杂度从 O(L) 降至 O(ΔL)，这对搜索/推荐/广告系统中的实时打分服务有直接借鉴意义：
- 搜索场景：同一 query session 内的多次请求可复用用户侧 KV Cache
- 广告场景：同一页面的多个广告位可共享用户行为编码
- 推荐场景：瀑布流连续加载时增量计算
6.4 Scaling Law 在推荐系统中的验证
论文展示了 OneTrans 具有清晰的 对数线性 scaling 趋势（性能随计算量/模型规模对数线性增长），且斜率优于模块化方案。这为工业系统的资源规划提供了可预测的 ROI：增加 X 倍计算，可以预期 Y 的效果提升，不再是"试了才知道"。
6.5 落地节奏的参考
OneTrans 的部署策略值得借鉴：
- 先 OneTransS（91M）验证，再 OneTransL（330M）上量——渐进式扩展
- p99 延迟作为硬约束——330M 模型的延迟反而低于 10M baseline，说明工程优化的重要性不亚于模型设计
- 在 Feeds 和 Mall 两个场景分别验证——证明方案的泛化性
总结：OneTrans 不只是一个模型创新，更是一次推荐系统架构理念的升级。它用实际的线上结果证明了"Less is More"——一个统一的 Transformer 优于多个专用模块的拼装，同时继承了 LLM 生态的全部工程红利。对于正在思考推荐系统下一代架构的团队，这篇论文提供了一个极具参考价值的方向。