TransX Technical Report: Scaling Sequence Transduction for Recommendation

同一个用户一次请求里有许多候选，相邻两次请求的行为历史又大部分重叠。如果每个候选都把整段历史重新过一遍模型，历史越长、候选越多，线上就做越多重复计算。LinkedIn 的 TransX 把用户历史提前编码成一份紧凑的“行为记忆”，每个候选只需带着自己的查询去读这份记忆。论文不只讲提速，还用扩容实验回答新增算力该放在哪个模块。线上结果是：基础模型对比生产中的 HSTU点击率提升 6.02%、转化提升 4.45%；解耦服务让总服务成本降到共置服务的 22%。共置服务是对照方案：每次打分请求都带上完整的原始行为历史，在线上把依赖历史的计算整个重跑一遍；解耦服务则把历史编码提前离线算好、增量更新，线上只读现成的行为记忆。需要先说清的是，这个基础模型每次请求的计算量约是 HSTU 基线的 5 倍，按同等计算量对比时两者离线质量几乎持平。所以线上收益很大一部分来自“省下来的钱能养更大的模型”。

1. 问题：一段历史为什么被反复计算

HSTU 这类序列推荐模型把用户历史和候选放在同一条序列里处理，每次请求都要从头编码历史。用户行为可达上千条，每次请求又要给大量候选打分，于是最贵的历史处理被放进了必须几十毫秒内返回的线上链路。想加大模型，就直接加大了线上成本。

另一种常见做法是双塔：提前把用户压成一个向量。但一个向量会把不同兴趣揉在一起，没法回答“这个候选和哪几条历史行为相关”。TransX 走中间路线：不压成一个向量，而是把历史存成一小组向量。最近的几条行为原样各占一格，更早的历史按时间切段、每段汇总成一格，下文把每一格叫一个记忆槽位。候选打分时自己决定从哪几格读。历史处理可以离线共享，每个候选仍然用自己的方式读取。

作者把这件事拆成两个耦合的问题。一是哪些计算可以复用、在什么范围复用；二是新增算力该放在历史编码、记忆容量还是候选融合上。模型的模块划分同时决定了这两件事的答案。

2. 方法：编码一次，按截点取记忆，候选各自读取

模型由三部分串成。第一部分是因果编码器，按时间顺序处理用户行为，每个位置只能看到它之前的行为，保证预测某次曝光时不会用到之后发生的点击。第二部分是记忆构造。在每次请求对应的时间截点，把最近 $W$ 条行为的编码原样保留为局部记忆。更早的历史按时间顺序切成若干连续的块，每块汇总成一个向量（可以是平均这类固定池化，也可以是学出来的汇总），最多保留 $R$ 个作为全局摘要，论文正文没有给出块长和 $R$ 的取值。两部分拼接后投影成注意力用的键和值，文中称为行为记忆键值（KV）。记忆槽位数远小于历史长度。第三部分是候选融合：每个候选用和历史行为相同的特征接口生成查询，对记忆做交叉注意力，再接点击、转化等输出头。

训练也按这条边界组织。日志通常一行一个候选，同一用户的多次请求会把重叠的历史重复存储、重复编码。TransX 把同一用户的行为轨迹和它的多次请求打包成一个训练单元：轨迹只编码一次，在每个请求截点提取对应的记忆，再分发给该请求的所有候选，各候选的损失梯度汇总回同一次编码。

在此基础上，作者先用点击和转化训练出基础模型，再保留共享的编码器和记忆，分别训练召回和偏好排序用的读取器与输出头。生成式召回和生成式排序也做了离线探索，但效果对 Semantic ID的设计和自回归解码更敏感，作者明确把它们当作探索，没有上线。

3. 服务：三个时钟和不可变快照

服务拆成三条链路，各自按自己的节奏和瓶颈扩缩。离线批量预填充在模型上线时为全部活跃用户算好状态，追求吞吐。近线更新在用户产生新行为时推进编码状态并发布新记忆，追求在新鲜度预算内的更新吞吐。线上预测只取记忆快照，完成候选融合和打分。

这里有两个容易混的对象。编码器续算状态让近线能接着上次的位置继续编码，中位数每用户约 496 KiB；线上读的行为记忆只有约 8.5 KiB。前者留在近线，不进线上缓存。记忆在发布前还会量化：每个键或值向量先拆成长度和方向，长度单独存，只压缩方向。用一批训练样本估计方向向量的协方差矩阵，做特征分解，再用全部特征向量组成的正交矩阵把方向向量旋转过去，维度一个不丢；旋转后每个坐标对应一个特征方向，它的方差（论文叫“能量”）就是对应的特征值，大部分能量集中在少数坐标上。然后按能量分配比特，方差大的多给几位、小的少给，总位数固定；把中位大小从 BF16 下的 28 KiB 压到 8.5 KiB，测试 AUC 变化在 2×10⁻³ 以内。

快照不可变是这套分工能成立的前提。请求开始时固定一个版本，更新任务随后发布新版本，也不会让正在打分的请求读到半新半旧的状态。状态缺失或过旧时，请求退回到较旧的兼容快照或非序列的兜底模型，重建在后台异步进行。线上实测近线更新延迟中位 1.2 秒、p90 1.8 秒，超过 92% 的流量读到最新兼容快照，约 3% 走兜底模型，主要是历史不足的冷启动用户。

4. 扩容实验：算力该加在哪里

作者把算力拆成三个坐标：每条轨迹的编码计算 $C_E$、暴露给线上的记忆预算 $B_M$、每个候选的融合计算 $C_F$。数据侧也拆成两个维度：历史丰富度按历史长度分位切成稀疏、中等、丰富三组，监督量 $\eta$ 是训练用到的候选标签数占参考总量（10 亿个有效候选标签）的比例，按整次曝光请求抽样凑够，取 0.20、0.25、0.30 三档。编码计算被很多候选共享，融合计算每个候选都要做一遍，所以作者先把编码计算按复用次数折算到每个训练目标上再比较。

第一个发现是编码器收益递减。固定记忆分辨率和融合容量，加大编码器在三组用户上都能提高测试 AUC，收益主要集中在扫描范围的前中段，超过约四层后明显变小。由于记忆分辨率没变，这部分收益不是“给线上看了更多状态”带来的，而是编码器把有用信息更好地压进了同样大小的记忆。

第二个发现是监督越多，算力越该给融合。融合宽度从 128 加到 1024，在 $\eta =0.30$ 时测试 AUC 提升约 90 个基点（1 基点为 0.0001），在 $\eta =0.20$ 时不到 10 个基点；加深融合层数则很早就饱和。在固定的总算力预算下，验证集选出的最优配置里，融合所占份额也随监督量增加而上升，最大一档预算下从一半左右升到九成左右，说明监督越充足，模型越需要更强的候选读取能力。作者用对数损失的分解解释这一点：总损失等于不可约的不确定性，加上“记忆丢掉的信息”，再加上“读取器的失配”。记忆预算决定“记忆丢掉的信息”有多少，融合容量决定“读取器的失配”能压到多低；监督充足时，读取器的失配更值得优化。

第三个发现是模型变大不需要同比加大记忆。作者把与最高分辨率记忆相差不超过 3 个 AUC 基点的最小预算定义为“够用”的记忆预算。这里的记忆密度指线上能读到的记忆槽位数除以用户历史长度。随着编码和融合计算增加，够用的记忆密度保持稳定甚至下降，绝对的槽位数和键值占用也是如此。这对系统很关键：模型可以继续变大，而线上要传输和缓存的状态不必跟着变大。

这组实验有两点要打折扣看。监督量只覆盖 0.20 到 0.30，跨度仅 1.5 倍，而融合收益的跃升几乎都集中在 0.25 到 0.30 之间，外推要谨慎。作者也说明，最优分配取决于模型族、数据和计算范围，这些规律不是通用的扩容定律。

5. 线上结果与系统效率

三个变体分别在不同产品位置、对各自的生产模型做了独立 A/B 实验，作者强调各列不能互相比较。除信息流浏览量外，所有提升的 p 值都小于 10⁻⁴。

按历史长度分组，基础模型在稀疏、中等、丰富三组上的点击率提升分别是 5.5%、6.0%、6.2%，说明收益不只来自历史丰富的用户。基础模型还做了五周的保留组观察，收益没有衰减；作者把这归功于每天重训和重新部署，而训练和预填充的优化正是让日更可行的条件。

系统效率方面，训练在 32 张 H200 上与朴素的 FSDP对比，模型、数据和批大小都固定。因为同一轨迹只编码一次，监督目标吞吐提高 84%，算力利用率从约 11% 升到 18%，收敛时间从约 25 小时降到 13 小时，这也是日更能做下来的原因。线上每张 H200 每秒处理约 250 个请求，端到端打分 p99 延迟 49 毫秒。

和同步处理历史的线上路径相比，读缓存记忆让 p99 打分延迟降低 71% 到 91%。延迟主要随候选数增长，几乎不随历史长度增长，这与“重的历史计算已经移出线上”的结构吻合。把 HSTU 式基线放大到与 TransX 每请求计算量相同，两者离线点击 AUC 相差不到 10⁻³，而 TransX 每张 H200 的请求吞吐约高 4 倍。

成本账需要把线下新增的开销也算进来。线上 GPU 消耗从每百万请求 5.8 降到 1.1 GPU 小时，下降 81.2%；但多出了近线每百万次行为更新 7.5 CPU 小时，以及每次部署 3.2 GPU 小时的离线预填充。作者把所有资源折算到同一成本基准后，总成本是共置服务的 22%。存储和网络基本持平，因为线上不再传输原始行为历史，改传紧凑记忆。

新鲜度也有代价。作者在线上逐级放宽允许的更新延迟：p90 从 1.8 秒变成 1.2 分钟，点击率下降 0.21%，会话内点击率下降 0.37%；再放宽到 18 分钟又降 0.12% 和 0.18%；继续变旧时损失迅速变小。损失集中在秒到分钟这一段，说明近线更新虽然不必和请求同步，但服务水平直接影响短期推荐质量。

6. 局限与实践意义

作者列出的局限有三条：扩容规律只在研究的数据、监督量、模型族和部署范围内成立，也不能唯一确定背后的机制；维护续算状态和记忆带来新鲜度、存储、版本兼容和恢复成本，部分绝对成本因披露政策省略，不构成完整的生命周期核算；共享记忆和冻结骨干不一定适合所有任务，某个任务若需要编码器没保留的信息，只换读取器不够。

对有长历史的推荐系统，最值得借鉴的是先量一下重复计算有多少：同一用户在相邻请求之间、同一请求的多个候选之间，各重复编码了多少历史。如果比例很高，把历史编码挪到近线、线上只读紧凑记忆，省下的算力可以换成更大的模型。扩容实验也可以照搬这种拆法，分别扫描编码、记忆和融合，并按历史丰富度和监督量分组记录，而不是只报一个总参数量。服务侧要把记忆年龄、兜底比例和版本不兼容率与延迟、点击率一起监控。