1. 问题与动机
工业级 CTR 预估模型面临参数扩展与部署约束之间日益加剧的矛盾。传统 Transformer 类 CTR 模型通过堆叠更多参数层来提升模型容量，但这带来了计算和存储开销的线性增长。在生产环境中，CTR 系统需要在严格的延迟约束下对每个请求的数百至数千候选物品进行打分——在这一背景下，0.001 AUC 的提升已被认为具有统计和实际显著性。作者指出，现有的缩放方法将计算量增长与参数量增长紧密耦合，形成了扩展雄心与部署约束之间不断扩大的鸿沟。这一问题在推荐系统中尤为突出，因为模型需要同时处理异构特征（用户画像、物品特征、行为序列、交叉特征）且面临实时在线服务的延迟要求。
2. 方法详解
LoopCTR 提出循环缩放范式（Loop Scaling Paradigm），核心思想是通过共享参数的循环复用增加训练时计算量，从而将计算扩展与参数增长解耦。
架构设计采用三明治结构（Sandwich Architecture），包含三个模块：
- Entry Block：异构特征投影 + 分组自注意力，将不同来源的 token（用户画像、物品特征、行为序列等）通过各自的投影矩阵 W_g 对齐到统一特征空间
- Loop Block：共享参数的递归层，采用前缀注意力（Prefix Attention）机制——序列 token 仅在序列内部自注意力，而全局 token 可注意到所有输入。长序列通过类 Q-Former 的可学习查询 token 压缩（InHouse 数据集上 16 个查询 token 压缩最长 1024 的序列）
- Exit Block：交叉注意力 + MLP 任务塔
超连接残差（Hyper-Connected Residuals, HCR）是解耦共享层行为的关键设计。传统残差 h + f(h) 是固定的 1:1 连接，HCR 将单个状态扩展为 n 个并行流，通过输入依赖的系数实现自适应融合。更新规则为 Ĥ = A_r^T H + B^T · T((H^T A_m)^T)，其中系数通过 tanh 投影实现输入依赖：Ã_m = A_m + s_α ⊙ tanh(H̄W_m)。投影矩阵初始化为零，确保初始行为等价于恒等残差。消融实验显示 HCR 在 Amazon 数据集上贡献最大（移除后 AUC 下降 0.0201）。
稀疏 MoE 集成：在注意力层替换 W_V 和 W_O 为 MoE 层（Q/K 投影保持共享以维持一致的相似度计算），FFN 层也采用标准稀疏路由。负载均衡辅助损失 L_bal = E · Σ f_e · p_e 防止路由坍缩。最优配置为 4 个专家激活 2 个。
过程监督（Process Supervision）：在每个循环深度 l 生成预测 y^(l)，总损失为所有深度 BCE 损失的均值：L_total = (1/(L+1)) Σ L_BCE^(l)。这使得 L=0（零循环）的推理已经通过监督信号获得了多循环训练的收益。
训练配置：AdamW 优化器，学习率 0.001，批次大小 2048，嵌入维度 64，HCR 流数 n=2，在 8 块 NVIDIA H20 GPU 上训练。
3. 核心技术贡献
- 循环缩放范式：首次将"计算量扩展"与"参数量扩展"在 CTR 预估中彻底解耦。所有 Loop Block 参数在循环迭代间共享，模型参数量完全独立于循环次数 L。训练时通过 L 次循环增加计算量，推理时可灵活选择 0 到 L 次循环。
- "训练多轮、推理零轮"策略：通过过程监督机制，零循环（单次前向传播）的推理已超越所有基线。Oracle 分析揭示 36.8% 的样本在 i=0 时达到最优预测，说明过程监督有效地将多轮循环的收益编码进了共享参数。
- 超连接残差：解决了共享参数在不同循环深度需要差异化行为的核心问题。通过输入依赖的多流融合（而非固定残差），使同一组参数在不同循环迭代中产生不同的表达。
- 损失景观优化：循环训练将损失景观从 L=1 的局部最小值逐步拓宽为 L=3 的平坦宽谷，与更好的泛化能力相关联。
4. 实验结果分析
在四个数据集上进行了全面评估：Amazon（300万交互）、TaobaoAds（2500万交互）、KuaiVideo（1400万交互）和 InHouse 工业数据集（600万交互，60万用户，208万物品）。
核心结果对比：
| 数据集 | 方法 | AUC | FLOPs (M) | 延迟 (ms) |
|---|---|---|---|---|
| InHouse | LoopCTR(0/3) | 0.7007 | 13.38 | 9.26 |
| InHouse | HSTU | 0.6960 | 2150.00 | 775.72 |
| InHouse | OneTrans | 0.6985 | 417.97 | 494.58 |
| Amazon | LoopCTR(1/3) | 0.8728 | - | - |
| Amazon | OneTrans | 0.8689 | - | - |
LoopCTR 零循环推理在 InHouse 上仅需 13.38M FLOPs 和 9.26ms 延迟，AUC 比 HSTU 高 0.0047，而 HSTU 需要 2150M FLOPs 和 775ms 延迟——计算效率提升约 160 倍。
消融实验揭示了组件贡献的数据集依赖性：Amazon 上 HCR 贡献最大（-0.0201），KuaiVideo 上 MoE 贡献最大（-0.0060）。这说明 HCR 的自适应残差在特征复杂度较低时更关键，而 MoE 在特征丰富的视频场景中更重要。
Oracle 分析是本文最有启发性的发现：在每个样本级别选择最优循环深度可获得 0.02-0.04 AUC 的额外提升空间。Oracle 最优深度分布显示 36.8% 样本最优在 i=0，30.9% 在 i=3，中间深度各占 15-17%。
等 FLOPs 对比：LoopCTR(3/3) 对比参数量匹配的 StackCTR（使用独立参数的堆叠层），在三个数据集上分别高出 0.0036、0.0033、0.0025 AUC，证明循环共享优于简单堆叠。
5. 局限与未来方向
作者明确指出两个主要局限：(1) Oracle 差距——虽然循环架构有 0.02-0.04 AUC 的理论空间，但如何实现这一潜力仍是开放问题；(2) 过度思考现象——相当比例（36.8%）的输入在额外循环后反而预测退化。作者提出未来方向是自适应推理策略，即根据样本动态分配循环深度，但本文未解决这一问题。此外，较少的训练循环反而产生更高的 Oracle 上界（L=1 的 Oracle 为 0.8885 > L=3 的 0.8858），暗示训练策略与推理优化之间存在潜在冲突。
6. 工业实践意义
LoopCTR 对搜索/推荐从业者有三点核心价值：
部署友好性：零循环推理意味着线上服务延迟与传统浅层模型相当（9.26ms），但效果超越深层模型。这解决了工业场景中"效果好的模型上不了线"的痛点。KV 缓存策略——序列 KV 状态每个用户请求计算一次、在所有候选物品间共享——进一步降低了每物品的计算成本。
训练效率：增加训练循环次数相当于增加训练计算预算，但不增加模型参数和推理成本。这提供了一条新的"用训练换推理"的优化路径，适合有 GPU 训练资源但推理延迟受限的团队。
实践建议：(1) HCR 流数 n=2 是最优选择，更多流未带来收益；(2) MoE 配置 4 专家激活 2 个效果最佳；(3) 3 轮训练循环是效果-开销的甜点；(4) 零循环推理在大多数场景已足够，仅在延迟预算充裕时考虑 i=1。