这篇讲的是字节在推荐系统里怎么继续把模型做大，同时还不把在线延迟搞炸。两条线：RankMixer 负责“让算子更硬件友好”，OneTrans 负责“让序列建模和特征交互真正统一起来”。
先说结论
这篇的核心不是某个公式，而是一个工业推荐里的老问题：
你想把模型做大，但推荐系统又特别怕慢。
RankMixer 和 OneTrans 就是在这个矛盾里往前走：
- RankMixer：把特征交互结构改得更像 GPU 爱吃的矩阵运算；
- OneTrans：把不同类型的特征和序列打散成统一 token，再放进同一个主干里。
RankMixer 在干什么
你可以把它理解成：不再老老实实用 attention 去算特征两两关系，而是把 token 先拆开、打散、重组，让交互更便宜。
它做了三件很关键的事：
- Feature Tokenization先把不同维度的 embedding 切成统一长度的 token。
- Token Mixing不做传统 attention，而是拆 head、重组、shuffle，让 token 间的信息交换更像矩阵重排，而不是显式相似度计算。
- Per-token FFN + 参数隔离每个 token 都有自己的一套前馈网络，避免不同语义特征互相抢话语权。
它的工程意义很直接：
- 更容易跑到 GEMM 上；
- 更容易吃满 GPU；
- 参数可以继续涨，但延迟不一定跟着涨。
OneTrans 在干什么
OneTrans 更像是在解决“模型结构到底要不要分家”的问题。
传统推荐模型常见做法是：
- 一条路专门建模用户行为序列；
- 另一条路专门做静态特征交叉；
- 最后再融合。
OneTrans 觉得这样太晚了。它的做法是：
- 把静态特征、行为序列、候选目标都 token 化；
- 放进统一主干；
- 用 Auto-Split Token 和 Attractor 做逐层聚合；
- 用金字塔式 backbone 在不同层处理不同粒度的信息。
直白点说，它想把“序列建模”和“特征交互”揉成一个系统，不再是两套模块后面硬拼。
你该怎么理解这篇
可以把它记成一条线：
跟你有关的点
如果你以后看数据工程、推荐系统、搜广推方向，这类文章很值钱的地方不是“名字多”，而是它告诉你：
- 模型设计不是纯算法题；
- 结构、显存、吞吐、延迟、线上收益是绑死的；
- 统一架构不是只管效果，还得管工程可落地。
所以这篇适合放进“推荐系统 / 统一建模 / 工业架构”那一类，而不是当成纯论文记录。
原文
https://mp.weixin.qq.com/s/oMbtEcpqcl2EJk-aYVcIYA