10倍参数增长、GPU推理落地：爱奇艺广告CVR模型的升级之路

过去几年，广告预估模型从“稀疏特征 + 轻量 MLP”的阶段，走向更大的 dense 网络、更复杂的特征交互和更长的用户行为序列。在广告预估中，CVR（转化率）模型的精度直接决定广告收入和用户体验。过去两年，我们的模型参数量增长了10倍，稠密计算量从5~8 MFLOPs跃升至60~70 MFLOPs，原有 TensorFlow + CPU 链路已逼近算力和成本极限，模型迭代空间出现瓶颈。

从计算特点看，这类复杂 dense 模型更适合 PyTorch + GPU。其优势体现在：

• 矩阵计算优势：模型参数矩阵越来越大、序列越来越长、网络越来越深，核心计算会更多落到矩阵乘、batch matmul、归一化和向量化规约等高并行算子上。GPU 在矩阵计算、混合精度和大 batch 推理上更有优势；

• 生态成熟：PyTorch 则提供了更贴近算法研发的动态图体验，以及成熟的 CUDA 算子、AMP/BF16、attention module、算子融合和模型导出生态，可以让复杂结构从实验到上线的链路更短。

行业和开源生态也在向同一方向演进。广告算法和基础架构 Jarvis 团队合作进行了本次框架升级。

本次升级的目标不是简单完成框架替换，而是让广告预估模型重新获得可持续迭代空间。我们选定 TorchRec [1] 作为迁移框架，构建 GPU 在线推理链路，让更大的 dense 网络、更复杂的特征交互和更长的用户行为序列赋能广告业务。

建设初期，TorchRec 模型与线上 Tensorflow 模型有接近 1pp 的 AUC 差异。借助 AI 工具和TorchRec 源代码，定位多个因素并进行关键优化：

1. 模型参数初始化：例如，稠密层权重采用与 TensorFlow 一致的 Glorot 均匀初始化；稀疏 Embedding 采用 uniform unit scaling 策略。

2. 调用统一 api 时的默认值差别：例如，多值稀疏特征在 embedding 聚合时，TorchRec 的默认聚合参数 sum，需要修改为 mean 以对齐期望的聚合方式。

3. TorchRec 损失函数与优化器参数设计：鉴于PyTorch 分布式框架的梯度平均池化的同步更新模式，损失函数在 batch 维度调整为需使用 mean 方法聚合。此外，模型还对稀疏参数与稠密参数的优化器做了拆分。使用更加稳定、学习率设置更低的 AdamW 优化器，并且通过基准学习率缩放，补偿 global batch 的扩大导致的优化步长差异。

4. GPU 初始化设置：Tensorflow Estimator 采用了 master 节点初始化参数，worker 节点加载参数的方案；PyTorch 分布式框架每个 worker 节点独立初始化参数，故需要人工设定配置，保证初始化参数的一致性。

至此，TorchRec 模型离线 AUC 效果成功打平线上，消除框架间的效果差异，为后续稠密模型 scaling up 升级奠定基础。

打平效果后，我们开始对模型本身做升级——这就是 scaling up 的核心。推全的转化率预估模型自上而下分为三层：特征输入层、特征交互层与多任务预测层。交互层借鉴 HyFormer [2] 提出的 Query Decoding 与 Query Boosting 思路，将长序列行为与非序列异质特征纳入同一骨干网络；预测层采用 MMoE 的多任务专家结构。

图 1 给出 CVR 模型整体架构，包括数据流与模块划分，便于对照下文各小节阅读。

3.2.1 特征输入层

特征输入上, 分为两类:

• 序列特征: 用户历史交互序列 S=[s1,s2,…,sT]，每个交互行为由 item ID、action type、timestamp、side info 经过 embedding 层后 concat 来表示。

• 非序列特征: 包含用户特征、Item 特征和上下文特征, 并将这些特征各自经过Embedding后再concat。

序列侧由三组用户行为组成：实时点击、点击空间与离线转化序列。组内多列拼接后再经小型网络映射到统一隐空间。为降低查表开销，三组序列共用底层 ID 嵌入表，一次查表即可取出全部子特征，再按组组装为定长序列表示。

此外，由于差异化场景下样本分布的显著差异，故训练时采用 EPNet 进行多场景建模，最终输出一个多域感知的非序列 embedding。

3.2.2 特征token化

不同于 RankMixer[3]，我们对于非序列 token 的 tokenization 方法如下：

这种将 embedding 空间划分为多个头的方式可以保持表示多样性，使模型能够在不引入过度结构复杂性的情况下捕获异构特征语义。这样得到的X=[x1,x2,…,xN]将作为接下来的非序列 token 与序列特征进行交互。

三条行为序列则各自经过 SwiGLU 网络映射至同一隐式空间，使不同来源、不同维度的序列可在同一注意力语义下交互。

3.2.3 特征交互层

图 2 - Query Decoding 模块结构

为了兼顾线上推理的算力约束与复杂的特征交叉需求，参考Hyformer [2]，我们将特征交互层拆解为 Query Decoding 与 Query Boosting两个阶段，数据流清晰可控。

并行输入准备：对齐两类特征的语义空间。交互层首先需要将异构的输入拉齐到同一维度。对于非序列特征（用户、Item、上下文），我们并未采用简单的向量拼接，而是将其 Embedding 在隐空间上切分为 N 个独立 Head。这种多头化的 Tokenization 方式，能以极低的额外参数量保留特征的语义多样性，让不同 Head 在后续交互中自动分化出差异化的信息角色（如部分侧重场景环境，部分侧重长期兴趣）。

与此同时，三条用户行为序列（实时点击、点击空间与离线转化）各自独立经过 SwiGLU 网络映射至上述同一隐空间。这里选用 SwiGLU 而非自注意力，是考虑到广告序列的相邻事件依赖较弱，而 SwiGLU 以线性复杂度完成逐位置变换，在长序列场景下远比自注意力的平方复杂度更适合线上预算。

Query Decoding：以非序列为“问句”，检索序列信息。该模块本质上是为每个非序列 Token 提供“向历史行为提问”的能力，可类比 Transformer 解码器的交叉注意力层：

• Query（查询）的构造：针对每一组序列，我们将 N 个非序列 Token 与该序列的均匀池化向量拼接，送入一层 FFN 生成 1 个全局 Query Token。三条序列的 FFN 参数相互独立，以保留点击、空间、转化三类行为间的天然差异性，最终共生成 S=3 个 Query。

• Key/Value（键值）的供给：直接由上述经 SwiGLU 编码后的序列隐状态担任。

随后，3 个 Query 与序列的 K/V 执行交叉注意力计算。在此过程中，我们特别调整了注意力温度系数，对点积结果进行缩放以防止 Softmax 退化为 One-hot 极值。这保证了注意力权重的“有效秩”维持在高位——通俗来说，就是让每个 Query 都能平滑地从多步历史行为中吸收信息，而非过早锁定在极少数行为上，从而提升训练的稳定性。

Query Boosting：全量 Token 的深度融合与语义校准。交叉注意力之后，我们并未直接输出，而是将上一步得到的 3 个序列解码 Token 与原始 N 个非序列 Token 合并，共计 (N+3) 个 Token 一同送入 Token Mixer 模块。借鉴 TokenMixer-Large [4] 的思路，该模块执行“解构（Split）→ 融合（Mixing）→ 重构（Reverting）”三步：

• Mixing 阶段让所有 Token 两两充分交互，打破非序列与序列的边界，实现全局信息融合；

• Reverting 阶段则将混合后的表示映射回与原 Token 语义对齐的空间，确保后续残差连接时特征不发生语义错位。

灵活的 Scaling Up 潜力。该特征交互层支持像 Transformer Decoder 一样堆叠多层。考虑到线上推理时延与机器成本的 ROI，当前推全版本仅使用 1 层。但离线实验表明，当我们将层数从 1 层加深至 2 层时，离线 AUC 可获得超过千分之一的稳定提升——这为我们后续在算力充裕时继续纵向加深网络、充分释放 GPU 红利留下了明确的迭代空间。

3.2.4 预测层

预测层使用PLE+MLP预估头的结构，分别预估不同场景的pCVR值。其中，PLE由3个为单层全连接层的专家网络组成，预估头则由两层带非线性激活函数的全连接层组成。

在具体推全方案中，我们采用以下核心超参配置：Token 隐层维度 token_dim=128，特征交互层堆叠 1 层，非序列 Token 数量 N=13，序列解码 Token 数量 S=3，单条用户行为序列长度 T=50。该配置下的离线 AUC 相对基线模型提升 0.4 个百分点（pp）。

在此基础上，我们已规划明确的 Scaling Up 路线：后续算力继续扩充后，将沿“更宽的 Token 隐层维度、更深的特征交互模块堆叠、更复杂的序列 Token 建模”三个方向并行推进，持续挖掘模型在 GPU 算力下的性能上限。

TensorFlow 生态提供了成熟的 SavedModel 导出与 Serving 方案，而 PyTorch/TorchRec 模型的导出则面临更多挑战，难点主要来自稀疏/非定长特征中的 offset（偏移量）、序列长度等动态维度信息。训练时，这些信息通常以 Python 原生数据结构（如 list、dict）参与计算图构建，在 Python 环境中运行一切正常，但导出后容易被固化为计算图中的 int/string 常量。一旦线上请求的 batch size、特征组成或序列长度发生变化，这些固化常量便可能与真实输入不一致，轻则导致推理结果错误，重则使导出产物体积膨胀、版本更迭困难。

为解决这一问题，我们将训练链路与推理链路解耦，在推理链路中提前将前向计算逻辑固化为静态计算图。具体做法是：将模型版本间保持固定的信息——如 Embedding 权重、特征到 Embedding 表的映射关系、Pooling 方式等——作为模型配置随图一同保存；而将每次请求均可能变化的 meta 信息（如序列长度、特征偏移量、样本数量等）显式定义为 Tensor 输入，由原生算子在运行时动态计算。如此一来，导出的计算图不再依赖 Python 对象或导出时的固定 shape 样例，从根本上保证了线上推理的鲁棒性与正确性。

在模型的初版 GPU 推理链路中，我们保留了较多原始 PyTorch 执行路径，压测结果显示，单位资源下的吞吐量与时延收益均低于预期。随后，我们对推理过程进行了详细的性能剖析（Profiling），识别出 CPU/GPU 数据搬运、稀疏参数查表、变长序列处理、稠密网络计算以及请求合并等关键环节存在明显瓶颈，并逐一进行了针对性优化。

3.4.1 数据搬运 — 批量拷贝与 GPU Buffer 复用

线上请求进入服务时，大量特征最初驻留在 CPU 内存中。若对每个输入单独执行拷贝，或在 CPU 与 GPU 之间反复进行 reshape、concat 及用户特征展开等操作，数据搬运本身便会成为新的性能瓶颈。我们的优化思路是：在 CPU 侧完成批量的 concat 操作，统一搬运至 GPU 后再进行展开处理，同时尽可能复用已分配的 GPU 显存缓冲区（buffer），从而显著减少冗余拷贝与临时张量的产生。

3.4.2 Sparse 查表 — 合并小算子，减少 Kernel Launch 开销

广告预估模型通常涉及大量 Embedding Lookup、Pooling、序列补齐以及稀疏张量转稠密张量等操作。若这些操作逐个独立执行，将产生大量细碎的小 Kernel 和中间张量，导致 GPU 计算资源难以充分发挥。我们的优化方案是：将多组 Embedding 查表、User/Item 特征对齐、变长序列处理等逻辑合并至更少的 GPU 算子中，从而显著减少 Kernel Launch 次数与中间结果的写回开销，让稀疏侧的计算模式更贴近线上推理的真实数据布局（如按需访问、减少冗余补齐），进一步提升执行效率。

3.4.3 Dense 计算 —  TensorRT 图优化与 BF16 推理

复杂dense网络的主要计算集中在矩阵乘、归一化、激活函数和 attention/sequence block 上，这部分适合交给 TensorRT 做图优化、算子融合和 kernel 选择。在线上可接受的精度范围内，我们引入 BF16 推理，降低显存带宽和计算开销；同时通过动态 profile 覆盖不同的 batchsize 和序列长度，支持模型在各种输入 shape 下高效运行。

3.4.4 Kernel 调度 — CUDA Graph 捕获与重放

TensorRT Engine 虽然已经大幅优化了稠密计算部分的效率，TensorRT Engine 虽然已经大幅优化了稠密计算部分的效率，但推理过程中的输入输出张量绑定、显存分配与释放、执行上下文切换以及 CUDA Kernel 的逐个发起（Launch），仍会带来可观的调度开销和时延抖动。为此，我们按 batch bucket 复用执行上下文和显存 buffer，并用 CUDA Graph 将稳定的 kernel launch 序列捕获下来，在后续请求中直接重放，减少 CPU 侧逐个发起 kernel 的调度成本。最终的目标是让 GPU 的算力尽可能多地用在模型前向计算本身，而非消耗在运行时编排上。

3.4.5 请求合并 — Triton Server 的 User/Item 混合批处理

为了提升 GPU 利用率，我们会将多个线上请求聚合成一个批次（Batch）后再送入 GPU 计算。然而，在线广告请求与标准的深度学习推理请求存在一个关键差异：为节约网络带宽和减少计算图中的冗余操作，每个广告请求通常仅包含 一个 User 的特征 与 多个候选 Item 的特征，即 User 侧与 Item 侧在数量上天然不对齐。标准推理框架原生不支持这种 “User Batch + Item Batch” 的混合语义，无法直接合并请求。

为此，我们在 Triton Server 推理服务层补齐了这部分能力：服务能够区分用户侧特征与物品侧特征，分别按照各自的维度逻辑进行拼接，同时通过请求级别的标识符保留 User 与 Item 的一对多关联关系。在计算图中，我们采用“尽可能延迟（Lazy）”的策略，将 User 特征的复制（Repeat）操作尽量后置，直至与 Item 特征拼接的前一刻才执行。这样做既保证了批量推理的吞吐优势，又最大程度减少了中间张量的显存占用与计算冗余。

3.4.6 调优自动化 — 大模型辅助的性能调优 Workflow

在算子开发过程中，我们采用了基于大模型实现测试/规格驱动开发（TDD/SDD），提高代码的可维护性，大幅提升开发速度。并实现了 Develop/Debug/Test/Profiling/Monitor Agent 协同 workflow，自动定位推理瓶颈并持续优化，实现性能调优自动化工作流，人工调优耗时减少 50%，满足模型推理高吞吐、低延迟要求。

• CVR 模型：收入+3.42%，RPM+2.81%，点击数+1.91%，转化数 +7.22%，深层收入 +2.28%。

• DCVR 模型：收入+1.60%，RPM +1.21%，点击数+1.01%，转化数 +0.25%，深层收入 +2.37%。

• 机器成本减少15%，超时率从0.15% 降至0.03%。

本次框架升级为广告预估模型的长期演进打开了新的算力空间。我们将在模型结构、推理优化和平台化三个方向持续深耕：

• 模型结构：GPU 框架释放出的算力红利，将直接用于扩大稠密（Dense）参数规模，引入更强的序列建模能力（如更长时序依赖、多兴趣表征）、更复杂的注意力结构（如轻量级多头自注意力）以及更深层次的多任务学习体系。未来，CVR、DCVR 等核心模型可以围绕更精细的用户行为理解、更细粒度的转化目标拆解和更充分的特征交叉结构持续演进。

• GPU 推理优化：持续挖掘 GPU 算力潜力，重点推进算子融合（进一步减少 Kernel Launch 次数）、混合精度推理（如 INT8 量化探索）、动态批次处理（Dynamic Batching）、Embedding Cache（高频特征的显存驻留）以及多模型混部与资源弹性调度等方向，在保障时延的前提下持续提升单卡吞吐能力。

• 平台化：将本次迁移过程中积累的模型结构规范、导出工具链、性能调优方法论和 Triton 服务配置模板，沉淀为一套可复用的 TorchRec GPU 训推一体化框架。后续新模型接入时，仅需在框架内配置模型结构即可完成训练、导出与上线，接入工作从“系统工程”简化为“配置化接入”，大幅提高算法的迭代效率。