✍🏻 本文作者： 木行、冰瞳、春草、堇华、玄同等

在绿色计算的大背景下，算力使用将朝着更加高效和智能的方向持续演进。本文将介绍阿里妈妈展示广告引擎在全局视角下优化算力分配的最新思考和实践，欢迎留言一起讨论。

阿里妈妈动态算力系列文章：

【2021】阿里妈妈展示广告引擎新探索:迈向全局最优算力分配

【2020】动态算力起源-阿里妈妈展示广告引擎的“柔性”变形之路

▐ 写在前面

在追求节能减排，降本增效，绿色技术的大趋势下，充分利用好算力资源尤为重要，尤其是在阿里妈妈展示广告引擎这种使用近百万core的业务中。Transformers—动态算力的出发点就是利用好算力拿到更多业务收益(把算力分配给边际收益大的服务)。从最初的起源[1]，到去年尝试从全局视角去考虑算力的分配，建设了全链路RT分配[2]，动态算力始终围绕着如何把算力用好，提升服务运行时效率这个核心持续演进。今年上半年继续围绕从全局视角出发优化算力的分配，而这一次主要围绕机器自适应分配展开。另外令人非常兴奋的是，不管是集团内还是集团外都有多个团队开始投入到这个方向，如目前公开的具有代表性的美团外卖智能算力[3]，为该方向的建设提供了非常好的思路。

虽然动态算力去年在全链路RT分配上取得不错的成果，但也存在一些问题。算力本质是计算量，由qps和单请求的计算逻辑决定。在实际观测时，使用多少计算量是可以通过计算耗时RT乘以所用机器资源数估算，可见消耗的计算量由RT和机器资源共同决定。在实际调控中，有的场景RT调控空间非常有限(调不动)，如下图(引擎中为了减少RT，有大量的并发场景)调用精排Rank服务：减少单队列长度以及队列数，RT下降比例小，但是却能节省大量机器资源。

图1.并发场景中RT调控空间有限

图2集中体现了我们对算力，计算量，RT以及机器之间关系的理解，机器调配是动态算力技术体系中不可缺少的一部分。

图2.算力分配中调配机器的重要性

一、新的探索

考虑到RT和机器资源同时调控的复杂性，这一期先在固定RT分配的情况下探索机器资源的调配方案。主要的目标是：希望在总机器资源固定时(日常流量qps较稳定,可以认为不变)，通过合理的调配广告引擎全链路各服务间的机器，在业务效果rpm(业务效果可以是其他任何可量化的指标)和简化机器运维成本等方面拿到收益。

1.1 核心思路

机器资源一定的情况下，统计不同服务在不同机器资源组合下的rpm数据，取rpm最大时的资源组合，然后进行资源调配。（注意：rpm跟qps无关，因此统计数据的时候假定qps不变化以简化问题。）服务在不同机器下因为要保证服务不超时必然会导致降档[1]，降档也就意味着rpm下调。所以通过调配机器来实现档位控制，而档位又决定了效果，最终实现通过调配机器来实现对效果的控制。虽然原理看上去简单，但是落地却十分复杂，以下选择实践过程中我们遇到的几个挑战以及相应的解法来进行介绍。

1.2 关键挑战

挑战一：如何获取单服务使用机器资源跟效果rpm之间的关系

每个服务的机器资源跟rpm之间的关系数据其实可以通过定期扩缩容演练获得，但实操成本太高，也没有办法在线上进行操作，日常档位(也即level)变化会直接影响大盘效果。如果是在线下压测环境进行，需要维护单独的一整套压测环境，机器资源日常本来紧缺，无太多空闲资源给压测环境。而且数十个服务，每个服务扩缩容验证也比较麻烦，总之运维成本太高。那么如何高效又准确的得到服务机器资源跟rpm之间的关系呢？下面是我们的思考过程：

1. 机器资源 <-> rpm近似cpu cores <-> rpm: 因为引擎绝大部分服务主要关注cpu资源，rank部分要考虑gpu和mem，本次仅考虑cpu cores。
2. 已知level <-> rpm的关系，因为可以通过小流量开通设定档位然后统计level <-> rpm的关系，所以问题转为成求cpu cores<->level的关系。
3. 考虑到： **算力=计算量=RT*计算资源(cpu cores)，当level一定时，计算量一定** 。（注意qps是一定的）RT跟计算资源成反比。

当档位上升带来10%的计算量增加时，如果要保持RT不变，那么计算资源应该增长10%。而实际可以开小流量桶测量 level->计算量的关系，小流量上的计算量可以简化为 RT(响应时间) * 并发数(1个并发对应1个计算实例)，以100档的RT * 并发数记为1，当档位变化时，可以计算得到计算量的 相对变化率 。通过这里转化就可以得到level->机器资源的近似数据。比如Rank服务在75档和100档时的响应时间RT和并发数分别为(39.5ms, 7)，(40ms, 8)，并且线上Rank使用cpu cores为12万核。用Rank(level)表示取特定档位时对应的计算量，x表示rank level = 75时需要的近似cpu核数。

，然后结合校正方法对该数据进行优化(不同的服务可能不一样，相同的服务在不同档位时也可能需要增加校正系数)。

挑战二：如何获取多服务之间档位组合跟效果rpm的关系，小桶测量数据稀疏问题如何解

因为机器调配涉及多个服务，档位组合是叉乘关系(每个服务档位的变化都会影响效果)。比如A，B和C三个服务，每个服务对应一层实验，每个桶流量1%，那么一个组合只有100万之一的流量，量小结论不置信，而且扩展性差，后面会加入更多服务，这导致数据稀疏问题非常严重。考虑到数据量，(统一时间拉太长也会有实效性问题，因此取最近3天数据)只支持直接测两两服务档位组合的效果数据，如rpm(A=5,B=10)表示A取5档，B取10档时的rpm。那当有3个或者3个以上的服务时，档位组合对应的效果数据如何测量？下面是我们基于条件概率的思想给的一个方案：

基于上下游两两档位组合的效果数据推算出多服务的档位组合效果，通过rpm(A,B)和rpm(B,C)推导出rpm(A,B,C)结合采样点的实测数据试进行校正。如通过定义计算比值f：

针对两个服务例子：

则有：

同理三个服务例子：

假定只考虑上下游服务间的影响，不考虑间接的影响。注意我们计算的是比例：

而

日常服务档位未明确指定的则意味着档位是100满档(动态算力日常绝大部分时间不降档)。对比上述两个公式的分子和分母，A档位的变化会同向影响rpm(B=10,C=8)和rpm(B=10)，这里假定对二者的影响比例一样。(实际中也可能会有一定影响，所以结合单点开桶rpm(A=5,B=10,C=8)进行微校正。)

那么A和C在统计上是独立的，所以：

进一步有，

这样就可以通过两两档位组合rpm推算出三个及以上档位组合的rpm数据，解决数据稀疏的问题。

在基于上述数据的基础上，则可以实现最优机器分配(从资源池中扩缩机器或者定期调整机器分配)，比如：当前线上档位(或资源组合)：(A=10, B=5, C=8) rpm=20(非真实值)。

目标：缩容50台机器

**组合1: ** (A=9, B = 5, C=8) rpm=19.8 机器节省45

组合2: (A=10, B = 4, C=7) rpm=19.7 机器节省50

组合3: (A=9, B = 5, C=6) rpm=19.6 机器节省50

最优组合2跟线上组合取diff，计算B和C各自缩容机器数如：15 + 35。

二、方案设计&落地

2.1 框架图

图3. 机器调配框架图

2.2 核心模块

2.2.1 离线数据计算介绍

基于在线服务中的日志(主要包括服务响应时间,并发数以及level等)，产出各服务机器，档位和业务效果(rpm)之间的关系数据，产出逻辑请参考关键挑战部分。

2.2.2 Ops管控动态扩缩容

各ops管控提供http访问接口，通过调用这些接口实现对指定服务的quota查询和更新，来实现最终的动态扩缩容。

2.2.3 动态算力的管控和视图

1）管控负责提供人工管理机器调配的交互接口，包括机器调配目标，调控模式以及详细的扩缩容推荐方案

2）视图负责展示机器调配状态以及最终效果对比展示

4. 容器分配调控中心ASController

负责基于离线产出的各服务(机器，档位，rpm)的数据以及管控人工设定的要求(如缩容5000核cpu等)，选择最优的各服务机器组合。然后根据ops管控返回当前线上服务真实机器数据，通过求差值，最后生成每个服务的具体扩缩容计划同步到动态算力管控，人工确认后，则按照执行计划通过ops提供的API对每个服务进行扩缩容操作。

2.3 落地功能

目前整个机器调配链路已经发布到线上，接入了包括检索，粗排，精排和策略等多个核心服务。相关核心效率数据的计算也已经日常产出。下面对主要的一些数据和功能进行介绍：

2.3.1 相关效率数据展示

1）衡量服务边际收益(rpm/万核)的数据

图4. 各服务算力使用边际收益

2）档位跟算力以及效果的关系图

图5. 服务在各业务场景下档位,算力以及rpm关系

2.3.2 两种触发方式（rpm效果最优或者资源上下线）

1）效果最优，相同资源下，通过调配服务间的机器配比拿到更优的效果。如下图：当有更优的组合，rpm比线上组合rpm大0.05时，则会自动生成新扩缩容方案。

图6. 自动触发模式

自动生成计划，把机器从边际收益低的服务挪动给边际收益高的服务。

图7. 自动触发模式下生成的扩缩容报告

2）机器上下线，资源总量变化，扩容时会选择把机器分配边际收益最大的服务；缩容时会从边际收益最低的服务下机器，尽量减少效果损失。如下图在na630机房缩容4000核。

图8. 人工设定扩缩容目标模式

生成扩缩容计划，从边际收益低的服务缩机器。

人工设定扩缩容目标模式下的报告

2.3.3 两种使用模式

1）产出详细的推荐报告方案，业务方参考进行机器调整

2）自动模式，交由动态算力自动完成线上机器调整

三、实验

基于上述方案，我们针对App1和App2服务在线上进行实验。以验证理论计算出来的收益值跟实际是否一样。也希望通过实验，为进一步的精细化校正计算逻辑提供数据支持。本次实验分为两个实验，具体如下：

3.1 实验一：单服务档位实验

实验内容 ：验证购后场景的App1在50档时的效果，理论计算中，相比100档效果下跌0.6%~0.7%。

实验方案 ：na61为BASE（无操作），na630为EXP（固定App1档位为50）。

实验结果

表1. 单服务档位变化后效果变化情况

实验分析

实验打开前(对应20, 21两天)，机房间对比平均rpm为+0.81%，实验打开后(对应22, 23两天)，机房间对比平均rpm为+1.54%，说明调正后效果为rpm+0.73%，符合理论计算值0.6%~0.7%。

3.2 实验二：多服务档位实验

实验内容 ：验证首猜场景的(App1 100档, App2 90档)调整为(App1 80档, App2 100档)的对比效果，理论计算值为+3%左右。

实验方案 ：ea119为BASE（App1 100档, App2 90档），ea120为EXP（App1 80档, App2 100档）。

实验结果

表2. 多服务档位变化后效果变化情况

实验分析实验打开前(对应21, 22, 23这3天)，机房间对比平均rpm为-0.48%，实验打开后(对应26, 27, 28这3天)，机房间对比平均rpm为+3.02%，效果为rpm+3.5%，接近理论计算值+3%左右。

3.3 结论

（1）理论计算的档位效果组合，在大流量下的实验也基本符合预期。

（2）由于机房间的效果对比，不是完全的ABTest实验，本身机房之间就存在效果上的波动（波动大约有1%）。但第二个实验的两个组合的效果差距在3%左右，降低了波动带来的影响，其结论还是置信的。

（3）第二个实验中，首猜场景的App1 90档相比100档，算力-6.3%。调配3.9%的算力给App2，保证App2的cpu水位不变。最终整体上，节省算力2.4%，且调控后rpm+3%。

四、总结与展望

现阶段考虑到系统的稳定性和多团队之间的资源池未拉通，线上使用模式是：产出容器分配推荐报告后，作为人工扩缩容的参考，然后进行局部调整(如机器资源不足时优先保障哪个服务的算力)。后续推进在保障系统稳定的前提下，让调配更加精准以及资源池拉通，从更高的视角去优化机器资源的分配，在日常全面用起来。另外也在推进建设模拟环境，对度量的精准度进行优化。

4.1 总结

好的方面

（1）整个引擎链路涉及到多个服务分属多个团队，还有多套ops，但机器调配功能均可以调控。

（2）通过理论推演结合校正方法，可以通过较小的成本即可找到最优的机器配比。

不足的方面

（1）目前虽然整个机器调配功能已经上线，但只有精排，粗排和策略等服务接入，调控空间有限。后续还需要接入更多的服务，从更大的视角优化算力的分配。

（2）现在的扩缩容对level的影响是基于理论推算，但实际可能跟理论推算不一样，而且还可能跟不同时段系统水位甚至不同业务场景有关，因此需要在未来实战中进行不断优化。

4.2 展望

本文是全链路机器自适应调配的阶段性总结，Transformers将继续推进接入更多服务以及在精细化度量上的探索，希望在机器调配这里拿到最终的业务收益以及探索算力，容量和效果之间的关系，用来指导系统的容量规划。总之，动态算力会持续朝着使系统更加稳定，更加高效和智能的方向持续演进，让在线引擎像变形金刚一样动起来。

▐ 写在最后

我们是阿里妈妈广告技术部工程技术引擎平台团队，致力于高效智能营销引擎的打造。本文成果由包括广告算法、业务引擎和引擎平台等团队共同完成。希望给从事相关工作的同学带来一些帮助和启发，也期待与大家多多交流。

引用

[1] 动态算力起源-阿里妈妈展示广告引擎的“柔性”变形之路

[2] 阿里妈妈展示广告引擎新探索：迈向全局最优算力分配

[3] 美团外卖广告智能算力的探索与实践