导读

近年来，伴随着互联网的蓬勃发展，工业界迎来了非常多的机会和挑战。以系统服务能力而言，流量规模持续增长，尤其进入移动化时代后，流量规模已经到达了一个新的高度。以淘宝为例，淘宝的DAU已在上亿规模，每天有大量的流量请求淘宝的后台服务，使得整个系统承担着巨大的压力。每年双十一等大促期间，瞬时涌现的流量洪峰更是对后台服务端的大考。

诚然，流量的增长和规模是一个严峻的挑战，但这个问题长久以来一直存在，我们已经有较多的应对经验。而另一方面，深度学习技术带来的变化，让整个工业实时服务系统面临着一个完全崭新的局面，需要以新的视角迎接新的挑战。

Figure 1 模型效果与算力成本

硬件计算能力的发展驱动了深度学习技术的广泛应用，同时深度学习时代模型升级的频率显著高于以往。以推荐、广告系统为例，深度学习初期，我们称之为1.0时期，大部分团队在计算力增长红利下快速推动个性化算法在各个领域取得了巨大的进展。比如仅阿里巴巴一家公司近年来就推出了非常多工作：DIN、DIEN、MIND、TDM等。

这一次浪潮虽然取得了大量的效果增长，但是另一方面，模型的计算力需求增长将过去多年来累积的计算力成本下降的红利迅速蚕食。即使未来硬件计算成本保持线性下降的趋势（要知道目前CPU已经无法维持摩尔定律），同等算力带来的算法效果增长也在显著收窄。这也就意味着在新的阶段， 计算力可能从过去算法进化的推力变成阻力 。

Figure 2 算法与系统

为了打破这种挑战，我们提出 个性化算力+个性化算法 的思路。

以往的系统设计中，算力往往被定义为一个固定的约束项，然而深度学习时代，模型的自由度和可塑性更强，我们把算力定义为一个可以优化的变量。我们提出了算力&算法co-design，不仅从个性化算法角度提供个性化服务，也对算力进行个性化分配，对不同的流量进行差异化算法方案服务。

与传统的剪枝、量化、batching、kernel fusion等单点优化思路不同，我们更希望能结合系统，在更宏观和整体的视角进行全链路动态算力分配。本文是我们在这个思路下的一个初步尝试，我们在 阿里定向广告平台中率先尝试并落地了动态算力分配框架 DCAF （Dynamic Computation Allocation Framework， https://arxiv.org/pdf/2006.09684）。

2020年5月起，DCAF开始承接阿里定向广告的部分流量并取得了一定的成果。在广告Ranking阶段，DCAF在保证效果的前提下，能够节省20%的GPU算力，初步验证了DCAF在提升系统效率方面的有效性。

动因

以推荐/展示广告系统为例，面对极大的在线服务压力，以及庞大的候选集（如电商超过10亿的商品库），为了建立一套稳定可靠的在线服务系统，常见的推荐广告系统将整个最优展示结果寻优的过程拆分为多个模块，每个模块候选集依次递减的级联架构系统：

Figure 3 Cascade系统

该系统通常由多个阶段级联而成，各阶段的服务独立部署，上下游模块间采用高内聚、低耦合的设计模式，此种模式相对易于维护。同时拆分的过程中把整个推荐问题拆解为了多个子问题，每个问题单独约束了计算资源、latency or response time 上限，采取不同的算法方案，大多时候从组织架构上会由不同的团队维护。

这样的方案确实有效，拆解了整个问题的难度，也被业界广泛采纳。但是这个方案并不是最优的。试想：每个模块分配的计算资源和latency以多少是最优呢？每个模块的候选集多大是最优呢？模块与模块之间的变量联合优化是不是会更优？

过去的系统视野里把算力分配当做了一个固定的约束或者边界，但是我们认为算力应当是一个可以和系统联合优化的变量。试想一下，每一条流量或者用户请求，其背后无论是在广告的商业价值，还是可能的购买欲望、浏览欲望都不同，这些不同因用户而不同，同一个用户不同的状态也不同。我们的算法会为不同的流量请求提供个性化的算法结果，那么我们的系统又何尝不能提供个性化的算法方案服务，让不同的流量采取不同的算法方案使用不同的计算资源呢？

同时从宏观层面来看，对于任何系统而言资源都是有限的，因此任何商业平台的终极目标均可抽象为在算力约束下最大化收益的问题。而目前的主流做法，无论是在日常服务还是应对突发情况，均是对所有流量分配相同的算力。从整体看，在流量价值有差异的前提下，对所有流量分配相同算力一定无法得到全局最优解。因此，我们需要根据流量价值差异化地分配算力，才可以从理论上打破效果的天花板。

基于这些判断，我们团队尝试从另一个全新的角度来提升系统的服务能力。我们认为不同流量间存在流量价值差异性，而系统需要差异化地处理每条流量，即 算力消耗需要与流量价值成正比 。在以往的做法中，平台习惯对系统进行整体优化，而对于每一条流量提供等算力的服务。而我们团队观察到，在所有请求淘宝后台的流量中存在着大量低价值流量，他们消耗着与高价值流量相等的算力，而对平台收益的贡献却微乎其微，这无疑是对平台计算资源的浪费。基于此，我们在阿里定向广告平台中率先尝试并落地了动态算力分配框架 DCAF（Dynamic Computation Allocation Framework）。

Figure 4 DCAF动态算力分配

从本质上讲，DCAF是基于流量价值对平台算力进行动态分配，打破了传统做法中对流量一视同仁的束缚，即从算力分配角度进一步释放了平台的服务能力。

另一方面，DCAF能够根据系统状态（如CPU/GPU使用率、QPS规模、失败率等）自动调整其动态分配策略，使得平台在面对如流量洪峰等突发状况时可以及时且智能地对其自身进行调节，极大地减少了人为干预。

2020年5月起，DCAF开始承接阿里定向广告的部分流量并取得了一定的成果。在广告Ranking阶段，DCAF在保证效果的前提下，能够节省20%的GPU算力，初步验证了DCAF在提升系统效率方面的有效性。

面临的挑战

如上文所说，DCAF的目标是在有限算力资源下，在保证系统稳定的情况下实现整体收益最大化，对于引擎和算法都提出了极高的要求。

在引擎架构上，需要具备对系统状态的深度感知能力和调控能力，在当前各模块各自级联服务架构下，从逻辑上需要一套中控决策模块为每个模块实时提供算力决策：一方面收集整体系统状态，为后续的动态算力算法提供算力决策依据，实现收益最大化；另一方面根据当前的流量状态，实时调节各阶段算力天花板，保证系统服务的稳定性。

在算法方案上，对于流量价值需要精确的建模，同时，在计算出流量价值后，需要解决的核心问题是如何根据不同流量价值分配多少算力资源，既要保证效果的最大化，同时也要保证整体计算资源不超出限额。

算法方案

对于平台而言，不同流量间存在着流量价值差异性，例如高转化率的流量对平台具有更高的转化价值。在以往的做法中，平台忽视了流量间的价值差异性，对所有流量一视同仁采取相同的算力。比如对于每条流量我们都会召回数量近似相等的广告候选集并对其精确排序。显而易见的，这种忽视流量价值的差异性、每条流量上消耗等价算力的粗放方案，会导致平台算力无法被充分利用，最终造成损失。

而本文中提出的动态算力方案，则是从流量价值差异化的角度出发，根据流量价值“按需分配”算力，进而实现在有限资源算力约束下的平台收益最大化。

基于前文的分析，本文将动态算力问题抽象为“背包问题”，即在整体计算约束下（背包总量），对每条流量按照其不同的流量价值（物品价值）动态分配算力（物品容量），进而得到算力分配的全局最优解。将问题建模为背包问题后，可以从理论上保证DCAF的算力分配方案为全局最优。

具体而言，DCAF将不同的算力资源具象化映射为不同的算法action（打分数量、模型复杂度等等），通过评估在同一条流量上不同action的预期收益价值，结合每个action自身的资源消耗，从而为每条流量选取性价比最高的action，同时也在满足计算约束的同时，打破原先被有限算力制约的效果天花板。比如，对于价值较低的流量，可以选择较少的广告候选集进行打分，反之则选择更大的广告候选集合。

我们将问题定义如下：

Equation 1 DCAF背包问题

其中 ${ q_j}$ 为采取action j时系统所消耗的算力。而 ${Q_{i j}}$ 则是对于流量i，DCAF分配action j时其所产生的预期收益。对于每条流量i，DCAF会自动地为其分配唯一的action j。因此整个问题被定义为一个在满足整体算力约束C的前提下，最大化所有流量预期收益之和的问题。

问题求解

对于动态算力的背包问题，我们构建其对偶问题进行求解。

首先，我们构建该问题的Lagrangian，

Equation 2 DCAF Lagrange Function

由此我们可以得到该原问题的对偶问题为，

Equation 3 DCAF dual function

通过一系列推导可以得到最终的分配公式，

Equation 4 DCAF action选取

其中， ${Q_{i j}}$ 为采取action j时流量i的预期收益，因此可通过dnn模型利用用户行为等特征对其进行预估。而 λ 为拉格朗日常量，其求解通常较为困难。但在动态算力分配问题中，算力分配与平台收益往往符合边际效益递减的规律。在边际效益递减的假设下，我们可以利用离线数据，采取二分法（bisection search）的形式，找到 λ 的全局最优解。最终，DCAF会根据该分配公式，为每条流量分配性价比最高的action。

引擎架构

Figure 5 DCAF系统架构

DCAF框架主要分为在线执行模块和离线预估模块。

在线执行模块会根据流量的实时特征，对 ${Q_{i j}}$ 进行预估（Request Value Online Estimation），并依照分配公式实时决定每条流量所采取的action（Policy Execution）。

除此之外，在线模块还具有系统指标的实时感知能力（Information Collection and Monitoring)。该模块通过系统信息（例如当前的QPS、RT），实时地对系统所能采取的算力消耗最大的action进行限制，从而在面对流量洪峰时，为系统控制提供强力抓手。

因此，本质上说，DCAF在线调控分为两个部分：一、从平台收益层面看，通过将整个算力分配问题建模为背包问题，实现平台收益最大化；二、从系统层面看，利用其对系统指标的实时感知能力，实时调整系统的整体算力上下限，增强了对系统的控制力，保障了系统的稳定运行。

离线模块的作用主要有两个：

训练 ${Q_{i j}}$ 的预估模型（Request Value Offline Estimation Model），即根据离线日志建立dnn模型，对 ${Q_{i j}}$ 进行预估。与以往的CTR预估不同，这里预测的是在不同action下，流量i的预期收益。
对 λ 进行求解（Lagrange Multiplier Solver），即根据离线日志，在一定假设的前提下通过二分法（bisection search）找到拉格朗日常量λ的全局最优解。

实验

离线实验

通过离线模拟DCAF分配策略，我们可以得到在DCAF分配策略下，平台的预期收益及与其对应的算力消耗。

实验设置

action j 控制流量在广告排序阶段请求CTR model的广告数量。
${q_j}$ 代表action j 对应的请求CTR model的广告数量。
${Q_{i j}}$ 代表流量i在action j下对应的预期ecpm。
C为一段时间内，CTR model可负担的总请求数量。
baseline 为当前系统，即对所有流量系统均请求相同数量的广告候选集

实验一

Figure 6 lambda、ecpm及cost间的关系

从图中看到，相比较baseline，DCAF可以在算力相同的情况下增加3.7%的ecpm。而在效果相同情况下，DCAF可以显著的减少49%的算力，即减少49%的广告请求数量。在同样算力下，随机策略则会使得总体ecpm下降约36.8%。

实验二

Figure 7 ecpm与cost

从实验二，我们得出结论，为达到相同的平台收益（ecpm）。baseline策略需要请求CTR model的广告数量要远高于DCAF。换言之，在达到相同平台效果的前提下，DCAF模型可以节省较多的计算资源。

实验三

Figure 8 action与ecpm的关系

这里我们的action是按照算力消耗从低到高进行排序的。图三反映的是不同action对应的ecpm的和及其对应的算力消耗。可以观察到，DCAF通过对不同流量采取不同action实现了效果的全局最优。

在线实验

Table 1 等算力下的在线效果

Table 2 等效果下的算力节省

从2020年5月20日至2020年5月30日，我们在淘宝的定向广告系统中上线了DCAF，并进行了严谨公平的在线 A/B Test。我们以Revenue Per Mille（RPM）作为衡量平台收益的指标，算力消耗被定义为请求广告排序CTR model的广告总数。我们分别做了两组对比实验：一、在算力消耗一致的情况下比较平台收益。二、在平台收益基本持平情况下，比较算力消耗。从Table 1中，我们可以看到在算力一致的情况下，DCAF可以实现CTR+0.91%，RPM+0.42%。Table 2则表明在RPM基本持平的情况下，DCAF可以减少25%的广告请求数，对应约20%的GPU计算资源。

未来工作

DCAF是通过差异化区分流量对算力进行动态分配，从而在有限的算力下打开了效果天花板。尽管我们是在流量维度上，并基于流量价值对其进行差异化处理，但也不能够忽视在user粒度可能引发的“fairness”等一系列问题。

对于平台而言，在有限算力资源下最大化平台收益固然重要，但尊重用户、优化用户体验更是平台长期发展的基石。因此，从长期来看，DCAF需要持续关注差异化区别流量所可能引发的“fairness”问题，并在未来的迭代优化过程中将用户的长期体验作为重要的目标。

另一方面，诚然DCAF可以从理论上保证在单一模块下算力分配最优，但还未从全系统视角考虑最优分配问题，因此其分配策略从全局看还是次优的。

未来，DCAF将会逐步从单一模块调节发展为全链路统一调节，进而实现真正意义上的在系统资源约束下的全局收益最优。

论文原文链接： https://arxiv.org/pdf/2006.09684

创作场景

突破算力束缚：阿里提出智能算力引擎 DCAF， 节省 20%GPU 算力

突破算力束缚：阿里提出智能算力引擎 DCAF，节省 20%GPU 算力