写点什么

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

个性化算力 + 个性化算法协同设计

陈日涵、张鹏业等

  • 2020-08-13
  • 本文字数:5387 字

    阅读完需:约 18 分钟

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

导读

近年来,伴随着互联网的蓬勃发展,工业界迎来了非常多的机会和挑战。以系统服务能力而言,流量规模持续增长,尤其进入移动化时代后,流量规模已经到达了一个新的高度。以淘宝为例,淘宝的 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 背包问题


其中 为采取 action 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 选取


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

引擎架构


Figure 5 DCAF 系统架构


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


在线执行模块会根据流量的实时特征,对 进行预估(Request Value Online Estimation),并依照分配公式实时决定每条流量所采取的 action(Policy Execution)。


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


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


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


  1. 训练 的预估模型(Request Value Offline Estimation Model),即根据离线日志建立 dnn 模型,对 进行预估。与以往的 CTR 预估不同,这里预测的是在不同 action 下,流量 i 的预期收益。

  2. 对 λ 进行求解(Lagrange Multiplier Solver),即根据离线日志,在一定假设的前提下通过二分法(bisection search)找到拉格朗日常量λ的全局最优解。

实验

离线实验

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

实验设置

  • action j 控制流量在广告排序阶段请求 CTR model 的广告数量。

  • 代表 action j 对应的请求 CTR model 的广告数量。

  • 代表流量 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


2020-08-13 14:005662

评论

发布
暂无评论
发现更多内容

SecureCRT for mac(终端SSH仿真工具)v9.4.1中文激活版

mac

securecrt 苹果mac Windows软件 终端SSH仿真工具

一图看懂华为云CodeArts Link六大特性,带你体验一站式跨平台数据互联

华为云PaaS服务小智

云计算 软件开发 华为云

跨平台.NET IDE集成开发 JetBrains Rider注册码激活版

mac大玩家j

代码编辑器 Mac软件

如何使用商品详情API接口获取商品数据:一篇详尽的论述

Noah

喜讯!云起无垠获评GEEKCON 2023"前沿突破奖"

云起无垠

DAPP合约代币质押算力挖矿系统开发

l8l259l3365

HarmonyOS数据管理与应用数据持久化(二)

HarmonyOS开发者

企业几种快速传输大文件的使用方法,你GET到了吗

镭速

大文件传输 传输大文件

Util应用框架介绍

何镇汐

C# 后端 软件开发 开源框架’

Util应用框架概述

何镇汐

文心一言 VS 讯飞星火 VS chatgpt (127)-- 算法导论11.2 2题

福大大架构师每日一题

福大大架构师每日一题

利用稳定扩散快速修复图像

3D建模设计

人工智能「 Stable Diffustion 图像修复

推送没人看?MobPush助力APP运营提质增效

MobTech袤博科技

MobPush后台配置教程

MobTech袤博科技

智能推送

git原理与基本应用

丛风

git

After Effects 2024 for Mac(ae视频特效制作工具) v24.0.2永久激活版

mac

windows 苹果mac After Effects 2024 AE2024 视频特效制作软件

云原生微服务的下一站:Proxyless Service Mesh

华为云开发者联盟

微服务 云原生 华为云 华为云开发者联盟

企业级API资产如何管理

RestCloud

API 资产管理 API 接口

MobPush智能推送:数智化运营释放APP用户生命周期价值

MobTech袤博科技

Techwalk攻略 | 来北京与OpenHarmony技术大会一起技术漫游!

OpenHarmony开发者

进击的代码之路:如何培养解决问题的架构思维?

互联网工科生

架构 架构师

MobPush智能推送工具,助力实现用户全生命周期管理

MobTech袤博科技

智能推送

以技术创新,让美好发生!第二届华为云杯“少年开发者”人工智能大赛总决赛成功落幕

彭飞

iZotope RX 10 for mac(音频修复和增强工具) 10.4.2完整激活版

mac

苹果mac Windows软件 iZotope RX 10 音频修复软件

Flink JobManager内存管理机制介绍与调优总结

腾讯云大数据

flink、

文心一言 VS 讯飞星火 VS chatgpt (127)-- 算法导论11.2 2题

福大大架构师每日一题

福大大架构师每日一题

MobPush自定义智能标签,赋能精细化运营

MobTech袤博科技

智能推送

.NET CORE 之gRpc使用

gogo

如何使用商品详情API接口来获取想要的商品数据?

Noah

突破算力束缚:阿里提出智能算力引擎DCAF, 节省20%GPU算力_大数据_InfoQ精选文章