type
Post
status
Published
date
Jul 5, 2026
slug
Recsys-Scaling
summary
Scaling 这个词从 LLM 扩展到推荐系统，最近也是驱动了推荐系统的核心收益。它有 Scaling Law 的 paper 提出，原本是指算力、参数、数据和 Loss 的 powerlaw 经验关系。由于推荐系统一直也是用全数据的，那么实际就是指扩展推荐模型的网络参数量，能够持续稳定地提升离线指标。
之前迭代了很久的成熟的工业模型，折腾网络结构和特征，每次迭代收益来到了千分位，突然又能有几个百分点地提升了，这就是网络参数 Scaling 的魅力，和转为业界共识的核心原因。
但这不是推荐系统的第一次 Scaling，或者说 网络参数Scaling 背后是一种做推荐目标优化的思维方式：放弃掉算法局部技巧的细枝末节，找到一个可以扩展的轴，转动它能够稳定地影响业务指标，你就把一个玄妙未定的算法研究问题转化成了稳定可预期的工程问题。
tags
推荐
category
推荐算法
icon
password
priority
3
Scaling 这个词从 LLM 扩展到推荐系统，最近也是驱动了推荐系统的核心收益。它有 Scaling Law 的 paper 提出，原本是指算力、参数、数据和 Loss 的 powerlaw 经验关系。由于推荐系统一直也是用全数据的，那么实际就是指扩展推荐模型的网络参数量，能够持续稳定地提升离线指标。
之前迭代了很久的成熟的工业模型，折腾网络结构和特征，每次迭代收益来到了千分位，突然又能有几个百分点地提升了，这就是网络参数 Scaling 的魅力，和转为业界共识的核心原因。
但这不是推荐系统的第一次 Scaling，或者说 网络参数Scaling 背后是一种做推荐目标优化的思维方式：放弃掉算法局部技巧的细枝末节，找到一个可以扩展的轴，转动它能够稳定地影响业务指标，你就把一个玄妙未定的算法研究问题转化成了稳定可预期的工程问题。
我在非深度学习，深度学习和参数Scaling 时代的迭代几年的业务上都经历过，通过系统化地重构轻松快速地拿到 10% 以上的业务收益，靠的其实并不是我对算法细节的理解，而是抓住了推荐系统可以 Scaling 的轴！
满天飞的 paper 可能会带偏一个刚刚入行的校招同学，一上来就把思维陷入到算法细节里，而忽略了它的顶层驱动逻辑。当推荐业务目标被转化成了一个确定性的工程问题，infra能力其实是算法的核心能力，这也是那些 paper 为什么能把赚钱的方法交给你，真正支撑有效性的部分是公司的Infra，你拿不走。
一直以来，推荐系统的排序模型都占据着核心算力，并驱动着最大头的业务收益。如果从 Scaling 的思维方式理解排序模型的迭代，就可以暂时忽略很多业务细节和网络结构细节，直接观察一个更本质的问题：系统是否具备足够强的工程能力，去快速、稳定、低成本地扭动若干个关键 Scaling 轴，并因此获得确定性的业务收益。
最早出现的 Scaling 轴，是特征数量。
无论是在大规模稀疏 LR 的时代，还是后来的深度学习时代，手工特征构造一直都非常有效。它的关键并不是精确判断某一个特征有没有用，而是一次性、大批量地构造出大量候选特征，不管它们最终有效还是无效，先把它们规模化地塞进系统里。真正的瓶颈并不是算法工程师能否凭经验判断特征价值，而是基础设施是否能够支撑大规模样本上的特征构造、可控的离在线存储与计算成本，以及可接受的线上 latency。
这本质上就是 Scaling 思想：把对算法和业务细节的依赖，转化为一个可重复、可放大、可工程化执行的过程。
第二个重要的 Scaling 轴，是 Embedding 参数量。
今天 LLM 的参数和训练数据规模已经非常夸张，但推荐系统其实在20年前就已经开始宣称自己有“万亿参数”。这里的主要来源不是深度网络本身，而是大规模 ID 特征及其 Embedding 表达。
前面提到的特征构造中，有一类实际维度极大的特征，也就是 ID 特征，例如 user id、item id、category id、author id、anchor id 等。更进一步，ID 特征之间、ID 特征与离散化特征之间，还可以做大量笛卡尔积组合。在大规模稀疏 LR 时代，即便做了极致稀疏化，模型实际参数量也很容易达到几十 B 到上百 B。
到了深度学习时代，这些特征从原来稀疏 LR 里的单个 logit，变成了多维 Embedding，并存储在 parameter server 中。于是，Embedding 参数量开到 TB 级别就变得非常自然。
因此，Embedding 参数量本身就是推荐系统最关键的 Scaling 轴之一。这里的核心问题依然不是单纯的模型结构，而是你有没有一套足够强的 parameter server，能够支撑万亿参数级别的训练和推理。说到底，这仍然是一个工程系统问题。
第三个 Scaling 轴，是用户行为序列长度。
推荐系统全面切到深度学习之后，一个纯粹增量的收益来自用户行为序列建模。除了设计各种模型结构去处理序列表征之外，大家很快发现：把序列拉长本身就有收益。
于是，“如何处理超长序列”逐渐变成了一个独立命题。无论是 search-based 的长序列，还是长序列入图与压缩，本质问题都不只是算法，而是模型与系统 Co-Design 之后的工程难题。你能不能把更长的历史行为接进来，能不能控制存储、训练、推理和 latency，能不能让长序列在真实线上系统中稳定生效，这些才是真正决定上限的东西。
第四个 Scaling 轴，是打分条数。
打分条数是一个更纯粹的工程 Scaling 排阶段多打一些候选，往往就能换来非常直接的业务收益。但问题在于：系统是否能支撑更大的打分规模？
这里涉及一系列工程问题：有没有存算一体的服务，让特征处理不产生额外的网络传输开销；有没有 shared 计算与结果合并机制，让整体 latency 可控；有没有模型与工程的 Co-Design，让模型结构充分利用 GPU 的计算特性。比如 HSTU 里的 M-FALCON 机制，本质上就是围绕 GPU 计算特性做系统和模型的协同设计。
数据 Scaling 其实也经历过一次重要演进。
今天，无论是流式学习，还是天级增量 batch，推荐系统默认都会尽可能使用历史全量数据进行训练。但这件事并不是天然发生的。
最早的基础设施往往是这样的：系统里有一个通用机器学习工具，你给它喂一个固定数据集，比如最近 N 天的样本窗口，然后训练出一个模型。后来大家发现增量数据的 freshness 有用，于是开始移动这个窗口。但这仍然是窗口范式，因为早期很多系统直接使用通用 LR、GBDT 工具箱，它们本身并没有天然的增量训练模式。
Google 2013 年的 FTRL 工作讲的是 online learning，但从 online learning 到工业界大规模流式训练，还有相当长的工程距离。它给我的最大启发并不只是“流式”，而是另一个更底层的思想：推荐模型应该用历史全部数据进行增量式、持续式训练。更多数据，往往就意味着更好的效果。
今天从深度学习视角看，mini-batch、checkpoint、warm start、持续训练这些机制已经非常自然，基础设施也默认支持。但在当时，这套算法流程、训练调度和工程系统都需要从零建设出来。
这也解释了今天推荐系统里的“老汤”问题：你迭代了一个新 feature，或者做了一个新的冷启动模型，离线或者短期实验看起来效果更好；但真正要和线上模型对比，你不能忽略线上模型长期持续训练积累下来的历史样本和参数状态。你需要合理初始化老汤权重，再持续追一段很长时间的数据，才可能公平比较。
这件事今天已经固化进推荐系统的认知和基础设施中，但它本质上依然是推荐数据规模的 Scaling。
所以，如果从 Scaling 视角回看推荐排序模型的演进，它并不是一条单纯的“模型结构升级史”，而是一条不断发现新 Scaling 轴、并用工程能力把这些轴扭到极致的历史。
特征数量、Embedding 参数量、序列长度、打分条数、数据规模，这些轴共同构成了推荐系统过去二十年的主要收益来源。真正的核心能力，是拥有一套足够强的工程系统，可以快速、稳定、低成本地放大这些轴。
在 2025 年以前，推荐系统里其实早就存在 TB 级别的 embedding 参数，但模型网络本体普遍只有 10M 左右。它很像一个巨型章鱼：八条触手无比庞大，但真正的脑袋却很小。
这个 10M 级别的网络规模是怎么来的？一部分来自最经典的多层 MLP，比如 5 层左右的 MLP，参数量大概在几 M 到十几 M 之间；另一部分来自各类 paper 卷出来的同量级模型结构，比如各种 attention、cross network、expert、gate、tower、feature interaction 模块。它们看起来结构不同，但本质上仍然是在 M 量级附近做并联、堆叠和局部改造。
2018 年 BERT 出来的时候，24 个 Transformer blocks 在当时看起来已经是巨型模型。但今天回看，BERT Large 也不过是 340M。问题是，为什么推荐系统长期以来都在抄模型结构，而不是关心网络本体的 Scaling？
我想过这个问题。首先，确实是意识不够。行业并没有充分意识到，推荐系统效果的核心来源往往不是某个具体网络结构，而是 Scaling。网络结构本身并不是最终答案，它只是提供了一条可以高效 Scaling 的工程路径。真正有效的不是“某个结构更聪明”，而是这个结构是否能把参数、数据、序列、打分量这些轴持续放大，并且放大之后还能稳定训练、稳定推理、稳定上线。
其次，当时的资源条件也不支持推荐模型网络本体的 Scaling。
BERT 出现时，它训练在几十 B token 级别的数据上，看起来已经很大。但推荐系统的数据规模早已来到 TB 级别。也就是说，推荐系统在数据 Scaling 上其实是领先的，它相当于把算力优先给了数据，就没有足够的 GPU 资源来 Scaling 模型参数。
今天 LLM 的训练数据已经来到几十TB，模型参数也进入TB 级别。LLM 把 GPU 集群、训练框架、混合精度、并行策略、算子优化、通信优化、推理服务等整套基础设施都往前推了一大截。当这些能力外溢到推荐系统时，推荐模型网络本体的 Scaling 才终于变得可行。
推荐系统历史上出现过很多模型结构改造。它们当然各自有一些局部收益，也能在特定场景里解决具体问题，但从更长周期看，它们并没有真正改变推荐模型的主线。原因很简单：它们没有 Scaling。
在模型网络本体长期只有 10M 量级的时候，所谓架构创新更多是在一个很小的参数空间里做排列组合。加一个 cross module，换一个 attention pooling，接一个 expert，套一个 gate，拆几个 tower，本质上还是在小模型时代做局部手工设计，这和加特工一样都是依靠大量人类经验，而不是基于Scaling Law 的经验规律。
它们可能带来千分位、万分位、甚至特定场景下更明显的收益，但没有把模型推向更大的参数规模，没有显著提升 GPU 利用率，没有形成统一、规整、可持续放大的 backbone，也没有真正改变推荐系统的工程范式。
业界长期养成了一种搞 paper 的习惯：改一个模型结构，起一个名字，包装一个动机，做几组 ablation，然后发一篇 paper。每个结构看起来都有自己的创新点，但很多时候，这些创新点并不是推荐系统收益的主要来源。真正的收益可能来自特征、样本、数据 freshness、embedding 扩容、打分规模、工程优化。
这就造成了一个错觉：好像推荐系统的进步来自各种网络结构创新。但实际上，推荐系统过去二十年的主要收益并不是由这些结构驱动的，而是由 Scaling 轴驱动的。特征数量、embedding 参数量、用户行为序列长度、打分条数、训练数据规模、增量学习机制，这些才是真正能持续产生大收益的东西。
当 GPU 变成了推荐系统 Scaling 最核心的依赖资源，那 backbone 的选择实际至关重要。GPU 上的 flops 不是独立的，它要通过大规模并行矩阵运算释放，那么 backbone 在 GPU 上的利用率至关重要。然后，这个 backbone 本身有着极高的 Scaling Limit（上限），以及足够高的 Scaling ROI。
GPU 擅长的是大矩阵 GEMM。矩阵要够胖，维度要足够规整，才能保障基本的计算强度。网络里不能有太多小算子，不能有大量不规则分支，不能有复杂的 CPU-GPU 同步，也不能有各种难以融合的碎片化模块。过去推荐系统里那种各种结构并联、各种小模块拼接、各种特征交互算子混在一起的做法，在 CPU 或 parameter server 时代也许还能接受，但在 GPU Scaling 时代会严重伤害硬件利用率。
Scaling 的 Limit 和 ROI 也很有趣，它本身就是你要先 Scaling Up 才能知道的，你对此的经验都是不充足的。但是可以从其他领域看到，Transformer 是最具备潜力的结构。
OneTrans 并不应该被理解成一次单纯的模型架构创新，它的核心思路是如何高效地使用 Transformer。推荐排序模型选择拥抱一个纯粹、规整、可扩展的 Transformer backbone，选择一条已经被 LLM 验证过的 Scaling 工程路径。
因为真正有效的是 Scaling。能不能最快完成 Scaling，并不取决于某个模型结构在 paper 上的局部 ROI，而取决于这个架构在工程上有没有卡点。它是否能高效跑在 GPU 上？是否能用成熟的并行训练框架？是否能享受 Transformer 生态里的 kernel、compiler、通信、显存优化和推理优化？是否能天然适配硬件厂商已经围绕 Transformer 做过的 Co-Design？
如果答案是肯定的，那么这个架构的价值就不只是“效果更好”，而是它能把推荐系统带到一个新的 Scaling 范式里。
推荐系统的进步，表面上是模型结构的迭代，实际上是不断发现可扩展的轴，并用工程系统把这些轴扭到极致。结构不是收益的主要来源，结构只是 Scaling 的摩擦系数。真正决定收益上限的，是资源、Infra 和工程效率。