📄 MixFormer: Co-Scaling Up Dense and Sequence in Industrial Recommenders
标题：MixFormer: Co-Scaling Up Dense and Sequence in Industrial Recommenders
作者：Xu Huang*, Hao Zhang*, Zhifang Fan*, Yunwen Huang*, Zhuoxing Wei, Zheng Chai, Jinan Ni, Yuchao Zheng, Qiwei Chen† （*并列一作）
机构：ByteDance Inc.（字节跳动）
发表：KDD 2026, Jeju Island, Republic of Korea
arXiv：2602.14110 | DOI: 10.1145/3770855.3818447
领域/任务：工业推荐系统 · CTR/CVR 预估 · Transformer 架构设计 · 规模化推荐
一句话论文：将推荐系统中"序列建模"和"特征交互"两套独立模块，统一到一套共享参数的 Transformer 骨干里，解决联合规模化（co-scaling）的结构性冲突。
标签：推荐系统Transformer联合规模化抖音KDD 2026特征交互序列建模
阅读决策：深度精读 — 这是推荐系统架构设计的顶级工业论文，从"为什么要统一"到"怎么统一"再到"上线效果"全链路完整，KDD 接收 + 抖音全量部署的双重背书，值得逐模块拆解。
🧭 整体认知
问题：推荐模型规模化的结构性冲突
当代工业推荐系统通常由两个独立模块组成：一个处理用户行为序列（序列 Transformer），另一个处理稠密特征交互（稠密 Transformer，如 DCNv2 / RankMixer）。这两个模块参数独立、优化独立。
核心矛盾——当你想同时扩大模型容量和加长序列长度时（这是 scale up 的两个方向），两个模块开始抢资源：
- 序列 Transformer 的计算复杂度随序列长度快速增长（$O(T^2)$ 或 $O(T)$），多给它参数 → 计算量爆炸，挤占特征交互模块的资源
- 先给特征交互模块扩参数 → 序列模块被压缩，长序列的收益被浪费
- 两个模块独立调参，永远找不到全局最优的规模和长度分配
这就是论文所说的 co-scaling challenge（联合规模化挑战）。本质问题是：参数是分开的，但计算预算是共享的，导致两组优化目标打架。
核心思想：统一参数空间，共享一切
MixFormer 的答案很直接——把序列建模和特征交互塞进同一套参数里。不再有"序列模块"和"特征交互模块"之分，只有一套统一的 Transformer backbone。这样一来：
- 扩参数 → 序列和非序列能力同步增长
- 不同层的参数自然分化出侧重（有些层更关注特征交互，有些更关注序列聚合）
- 高阶特征语义能直接参与序列建模（不再是"序列输出的 embedding 喂给特征交互"这种单向传递）
主要贡献
- 统一架构 MixFormer：一个 decoder-only Transformer，同时建模序列和非序列特征，共享参数、深度交互。
- 三个核心组件：Query Mixer（特征交互）→ Cross Attention（序列聚合）→ Output Fusion（深度融合），形成完整的统一建模流水线。
- UI-MixFormer 变体：用户-物品解耦设计，利用 Request-Level Batching 实现 ~36% FLOPs 降低和 ~30% 加速。
- Co-scaling 分析：系统展示在稠密参数缩放和序列长度缩放两个维度上，MixFormer 均优于分离式方案。
- 抖音全量部署：在抖音和抖音极速版上线的 A/B 测试，活跃天数、使用时长、互动指标全面正向。
🔬 方法详解
3.1 整体架构
Figure 1: MixFormer 整体架构。输入特征嵌入后按 head 切分 → 堆叠 L 个 MixFormer Block → 多任务输出塔。
MixFormer 是一个 decoder-only Transformer 的变体，由 $L$ 个 MixFormer Block 堆叠而成。每个 Block 包含三段：
- Query Mixer — 处理非序列特征的高阶交互（替代传统的 DCN/DLRM 特征交互模块）
- Cross Attention — 以 Query Mixer 的输出为 query，聚合用户行为序列
- Output Fusion — 深度融合非序列和序列信号，产出下一层的输入
3.2 特征嵌入与 Head 切分
输入特征分两类：
- 序列特征：用户行为序列 $\mathbf{S} = [\mathbf{s}_1, \mathbf{s}_2, \cdots, \mathbf{s}_T]$，每个 $\mathbf{s}_t$ 包含 item ID、行为类型、时间戳等
- 非序列特征：用户画像、物品属性、上下文特征，拼接为 $\mathbf{e}_{ns} \in \mathbb{R}^{D_{ns}}$
关键设计：将非序列嵌入 按维度切分成 $N$ 个 head（split → reshape），每个 head 代表了非序列特征的一个语义子空间。
Head 切分：$X_{ns} \in \mathbb{R}^{N \times D}$ 被 reshape 为 $\mathbb{R}^{N \times N \times D/N}$，然后 transpose 得到每个 head 独立的表示 $\mathbf{x}_i \in \mathbb{R}^{D}$。
3.3 Query Mixer——零参特征交互
Query Mixer 是 MixFormer 最精妙的设计之一。它用两个操作实现特征交互：
- HeadMixing：将 $N \times N \times D/N$ 的 tensor 进行 transpose → reshape，实现跨 head 的信息交换。零参数！这比 Self-Attention 做特征交互便宜得多。
- Per-head SwiGLU FFN：每个 head 独享一个 FFN，保持特征异质性。这和 RankMixer 的设计一脉相承。
HeadMixing 本质上是一个 shape permutation 操作——数学上等价于把所有 head 的同一维度的特征拼到一起再分散回去。由于它是线性的（实际上是恒等映射+reshape），论文的消融实验证实：Self-Attention 替代 HeadMixing 没有带来额外收益，说明对于异构的推荐特征，简单的跨 head 置换就足够了。
3.4 Cross Attention——特征感知的序列聚合
这是"统一"的关键所在。在传统方案中，序列先被聚合成一个固定向量，然后喂给特征交互模块（如同一个额外的特征）。MixFormer 的 Cross Attention 让高阶特征直接作为 query，去 attendance 序列。
具体运作：
- Query Mixer 输出的 $N$ 个 head 作为 $N$ 个 query
- 用户行为序列 $\mathbf{S}$ 通过 per-layer FFN 投影为 key-value（每层独立的投影，让不同层学习不同粒度的序列表示）
- 每个 head 的 query 独立计算对序列的 attention，产生语义专用的序列聚合
Cross Attention 计算：
\[
\mathbf{h}_t = \mathrm{SwiGLUFFN}^{(l)}(\mathrm{Norm}(\mathbf{s}_t)) + \mathbf{s}_t
\]
\[
\mathbf{k}_t^i = \mathbf{W}_k^i \mathbf{h}_t^i; \quad \mathbf{v}_t^i = \mathbf{W}_v^i \mathbf{h}_t^i
\]
\[
\mathbf{z}^i = \sum_{t=1}^{T} \mathrm{softmax}\left(\frac{\mathbf{q}_i^\top \mathbf{k}_t^i}{\sqrt{D}}\right) \mathbf{v}_t^i + \mathbf{q}_i
\]
和标准 Transformer Decoder Cross Attention 的关键区别：
- 不使用共享的 hidden state，而是用 per-layer 的 FFN 独立投影每一层的行为序列 → 不同层可以关注序列的不同粒度
- Query 不是从同一个 decoder hidden state 来，而是来自 Query Mixer 的高阶特征表示 → 特征语义直接驱动序列聚合
3.5 Output Fusion——深度融合
Cross Attention 输出 $\mathbf{z}^i$ 本身已经融合了序列和非序列信息，但还不够——因为不同 head 的 query 语义不同，产生的序列聚合带有 head-specific 的偏差。Output Fusion 通过 per-head SwiGLUFFN 进一步精炼，消除这种偏差，同时保持 head 之间的异质性。
注意：Output Fusion 和 Query Mixer 中的 FFN 共享参数风格（都是 per-head）——这就是"统一参数化"的关键：这些 FFN 既服务于非序列特征交互，也服务于序列-非序列融合，没有"哪套参数属于序列模块"的概念。
3.6 用户-物品解耦（UI-MixFormer）
Figure 2: UI-MixFormer——用户-物品解耦设计，支持 Request-Level Batching。
统一架构的一个副作用是 用户侧和物品侧的计算混在一起，无法利用推荐系统中常见的优化：Request-Level Batching（一个请求内多个候选 item 共享用户侧计算）。
UI-MixFormer 的解决方案：
- 非序列特征按来源分成 用户侧 heads（$N_U$ 个）和 物品侧 heads（$N_G$ 个）
- HeadMixing 加单向 mask：用户侧 heads 不接收物品侧信号，物品侧 heads 可以看用户侧信号
- 这样 用户侧计算在一次请求内只算一次，为所有候选 item 复用
Mask 矩阵：
\[
\mathbf{M}[i, j] = \begin{cases} 0, & i \lt N_U \text{ 且 } j \ge N_U \cdot D/N \\ 1, & \text{否则} \end{cases}
\]
\[
\mathrm{HeadMixing}_{decouple}(\cdot) = \mathbf{M} \odot \mathrm{HeadMixing}(\cdot)
\]
这个设计类似于 因果 mask 在自注意力中的作用——只允许信息从用户流向物品，不允许反向。与双塔结构不同，MixFormer 保留了用户→物品的交互能力，只是共享了用户侧计算。
📊 证据账本
| 主张 | 证据 | 强度 | 注意事项 | 待验证 |
|---|
| 统一架构优于分离式 |
Table 1: MixFormer-medium +1.28% AUC vs STCA→RankMixer，同时 FLOPs 减半 |
Strong |
对比用统一的超参，可能对 MixFormer 有利 |
给定相同计算量（不是参数），分离式能否追平？ |
| Co-scaling 在稠密+序列两个维度上均有效 |
Figure 4 (FLOPs scaling) 和 Figure 5 (sequence scaling)：MixFormer 的 scaling slope 优于或匹配 STCA 和 RankMixer |
Strong |
序列长度测试最大到 10K，未测试极端超长序列 |
10K+ 序列上统一架构是否仍有优势？ |
| HeadMixing 不输 Self-Attention |
Figure 3 消融：HM→SA 无显著增益，甚至略低 |
Strong |
受益于推荐特征的低秩异质性，不一定泛化到其他领域 |
更复杂的替代方案（如高效 Attention variants）能否更好？ |
| Per-layer FFN 优于共享 FFN |
Figure 3: [CA] PL-FFN→FFN 下降 ~0.03% AUC |
Moderate |
差距较小，在噪声范围内 |
深度更大的模型（L=12/24）差距是否会扩大？ |
| Per-head FFN 优于 head-shared FFN |
Figure 3: [OF] PFFN→FFN 下降 ~0.06% AUC |
Strong |
与 RankMixer 的发现一致（per-head FFN 有效） |
— |
| UI-MixFormer 保持精度，降低 36% FLOPs |
Table 1: UI-MixFormer-medium AUC 与 MixFormer-medium 完全持平，FLOPs 从 3,503 降至 2,242 |
Strong |
精度不变，速度提升显著 |
高并发下（candidate > 1000）的延迟降低是否持续？ |
| 在线业务收益 |
Table 2: 抖音 Active Days +0.0415%, Duration +0.28%, Finish +0.39%（两周，增益未收敛） |
Strong |
基数大 → 小百分比仍有业务意义。但与 ~1B 参数的 STCA→RankMixer 对比时 FLOPs 未明确说明 |
增益收敛后的稳态值是多少？长期留存如何？ |
| 低活用户受益更大 |
Table 2: 低活用户各项指标提升倍数于中高活用户 |
Strong |
可能因为低活用户行为稀疏，统一模型有更好的泛化 |
是架构优势还是长序列带来的额外信息？ |
🔍 批判评价
✅ 优点
- 问题定义清晰：co-scaling 是真实存在的工程矛盾，不是人造问题
- 架构设计优雅：HeadMixing 零参特征交互 + 特征驱动序列聚合，不堆复杂度
- 工程完备：精度→效率→解耦→部署，从学术模型到工程方案的完整 narrative
- 消融充分：6 个对比实验，每个设计决策都有消融支撑
- 上线验证：抖音 + 抖音 Lite 双平台 A/B，非纸上谈兵
- scaling law 分析：在推荐领域系统展示 scaling behavior，呼应 LLM 方法论
⚠️ 不足
- Cross Attention 复杂度未优化：每个 head 对每个序列位置都算 attention，$O(NTD)$ 不含优化方案（如 grouped-query attention？）
- 和 OneRec/生成式推荐的对话缺失：论文引用 OneRec 但不讨论 MixFormer 作为生成式推荐的 tokenizer/encoder 的可能性
- FLOPs 对比不够公平：MixFormer-medium (1,226M params, 3,503 GFLOPs) vs STCA→RankMixer (1,255M params, 6,736 GFLOPs)，参数接近但 FLOPs 差一倍，未说明为何 RankMixer 的 FLOPs 更高
- 缺乏冷启动物品分析：统一架构对冷启动 item 的影响未讨论
- 仅一组超参：Head 数 N=16 是否最优？L 的选择依据？
隐含假设
- 假设 HeadMixing 足以替代注意力做特征交互（消融验证了，但只在当前规模下）
- 假设 per-head FFN 有利于特征异质性建模（与 RankMixer 一致，但在其他领域是否成立？）
- 假设统一参数空间自然能学到合理的分工，而不需要额外的 inductive bias（长期训练中是否会出现 head collapse？）
复现风险
- 高风险：训练基础设施（数百 GPU 的混合分布式训练：sparse 异步 + dense 同步）在实验室规模难以复现
- 中风险：数据规模——论文基于抖音生产数据，序列长度 512~10K，小数据集上的行为未知
- 低风险：核心架构——HeadMixing + Cross Attention + per-head FFN 的组合在 PyTorch 中易于实现
缺失对照
- 未与 MoE（Mixture of Experts）方案对比——"统一参数" vs "稀疏激活"是另一条规模化路线
- 未与纯 dual-tower 深度统一方案对比（如类似 UI-MixFormer 但完全去掉 item→user 的信息流）
- 未测试不同超参组合（N, L, D 的不同配置）下的 co-scaling behavior
💡 研究用途
可复用的设计
- HeadMixing：零参数的特征交互方式，适用于任何需要跨特征子空间通信的场景
- 特征驱动的 Cross Attention：用高阶特征 query 去 attendance 序列，替代"先聚合再交互"的传统 pipeline
- Per-head FFN + Per-layer FFN：异质特征建模的两层粒度设计——head 级保持特征差异，layer 级支持渐进式表示学习
- 用户-物品解耦 + Mask：在不失交互能力的前提下实现 Request-Level Batching，对各种统一架构都适用
应规避的设计
- 避免将 HeadMixing 用于同质特征（如同一个模态内的 token 交互）——它的适用场景是异构特征的跨空间通信
- 避免在极小的模型（N 很小）上使用 per-head FFN——head 数少时共享 FFN 可能更高效
可能的后续研究方向
- MoE-MixFormer：统一架构 + Mixture of Experts，进一步 push co-scaling 的极限
- 生推统一：MixFormer 作为生成式推荐（如 GR4AD）的 encoder/backbone，实现"召回-排序-生成"的端到端 unified model
- 超长序列（100K+）：Cross Attention 的复杂度如何优化？能否用 Mamba/线性 attention 替代？
- 多模态推荐：将文本/图像/视频特征也纳入统一参数空间，做跨模态的 co-scaling
相关论文谱系
- 前置：DLRM → DCNv2 → DHEN → RankMixer（特征交互线）；BST → SIM → STCA（序列建模线）；OneTrans（第一个尝试统一的）
- 平行：LONGER（长序列优化，同团队）、NOVA（推荐系统架构自动演进，同公司）
- 后续：GR4AD（生成式推荐，快手）、OneRec（统一召回和排序，快手）
📎 附录图
Figure 3: 消融实验——各模块的贡献分析。
Figure 4: 稠密参数 Scaling——AUC 增益 vs FLOPs。
Figure 5: 序列长度 Scaling——MixFormer 的斜率与 STCA 匹配，优于 TA。
Figure 6: 推理延迟分析——UI-MixFormer 在候选数增加时延迟增长远低于原始 MixFormer。
Generated by mli-paper-reading skill · 2026-07-11