作者：木行、冰瞳、春草、碧野、天步、青萤、广生、堇华、破音等

在绿色计算的背景下，计算能力分配将继续朝着更高效、更智能的方向发展。本文将介绍阿里妈妈从全球角度优化计算能力分配的新探索，使在线引擎像变形金刚一样灵活、强大。

在倡导节能减排、降本增效、追求绿色技术的大趋势下，充分利用计算能力资源，特别是阿里妈妈展示广告引擎，使用近百万core在机资源业务更为重要。

随着深度学习技术的大量创新，广告、推荐等在线引擎系统的架构和算法复杂性迅速飙升，对计算能力的需求呈爆炸性增长。以阿里巴巴展示广告系统为例（参考文章）[1]），与几年前的精排模型相比，对在线计算能力的需求几乎飙升 2 数量级。如此惊人的计算能力需求增长将在一定程度上给计算能力供应带来巨大的挑战。阿里巴巴展示广告团队 18 计算效能技术的研发从年开始，已进入第四代计算效能系统的阶段：

1. 算力效能 1.0 阶段 (2018):注重单点工程优化和模型减肥优化等技术

2. 算力效能 2.0 阶段 (2019)：将 Model Design 和 Engineering Optimization 结合算法-工程 Co-design 方法论的深入实践带来了显著的红利

3. 算力效能 3.0 阶段 (2020):从发动机单模块到系统全链路的进一步扩展"个性化"重新审视和改造整个广告引擎系统，为古典在线引擎注入新的活力，使其更加"柔性"：充分提高给定算力的性价比，使其能够适应任何复杂动态的业务需求和流量环境。

4. 算力效能 4.0 阶段 (2021):从全局角度，通过精细测量全链路各模块的计算能力性价比，优化引擎全链路计算能力的使用，进一步提高整个引擎将计算能力转化为业务价值的效率。

从算力效率的角度来看，我们将广告引擎命名为 Transformers(取自电影变形金刚，意味着系统可以自动调整以适应各种促销活动，将驱动系统运行的计算能力运用到极致) —动态计算能力的出发点是充分利用计算能力获得更多的业务收入（计算能力分配给增量收入）。

Transformers 引擎的核心概念是将计算能力分配纳入系统设计范畴。古典广告引擎的使命是确保引擎系统能够准确地实现和运行业务逻辑。原则上，任何流量请求的计算逻辑都是一致的(这里只考虑算力差异化的视角)。当资源充足时，这是一个合理的策略，但在计算能力紧张、需要移动资源甚至降级算法策略来完成特定系统资源约束下的业务逻辑时，背后隐藏着巨大的效率空间。以广告系统为例，我们可以选择：1. 开足算力对每条流量做最精细化最复杂的计算，对超出系统算力的部分流量做丢弃操作；2. 对不同价值的流量进行差异化的计算能力规划，以确保系统能够有效地服务于每个流量。哪种策略是最好的？这就是 Transformers 引擎目标：在有限的资源中实现"柔性"计算能力扩展，确保业务收入最大化。（参考文章[1]）

去年，动态计算能力完成了从0到1的建设。通过静态最佳分配和基于反馈的动态控制，在展示引擎的日常和推广中获得了稳定的业务收入，从战略到框架都有良好的沉淀。详情请参考文章[1]。业内也有跟进研究的团队，结合自己的业务场景获得了实际的业务收入，参考文章[2]，集团也在推动这一方向的进一步发展。然而，尽管动态计算能力去年得到了业务效果和软化系统的认可，但也存在一些问题。

整个引擎中包含众多调控点(一个应用模块包含一个或者多个调控点)，但各调控点都是孤立调控，只追求调控点内部一定时间的局部计算能力收入最大化。这种联动调控没有上下服务配合，其实是有问题的。具体表现如上游控制点档位过低，导致下游控制点水位过低，计算能力空闲。相应地，下游控制点档位过低，导致上游许多计算结果被切断，计算能力浪费。也就是说，每个功能点只关注自己的情况，很难形成合力，在整体情况下取得良好的效果。此外，业务引擎的一些场景是日常的RT P99接近上限300ms(影响系统稳定性和日常迭代)，由于加班（性能优化和资源扩张无法及时解决），经常出现在线功能，因此必须根据人为经验进行适当的降级以减少RT，所以也需要简单灵活。储备RT手段。以上问题都涉及到计算能力的分配，所以今年项目组的主要工作是围绕模块联动调控展开，从全局角度考虑优化计算能力的分配。

一、新探索

如何在现有AllSpark[1]调控框在框架的基础上实现联动调控？需要解决哪些具体问题？

目前单功能点独立调控，各功能点计算能力控制参数不同。例如，定向集合用于定向阶段，检索阶段用于定向集合token数量、粗排和精排的截断ad不同的模型用于策略和创意阶段，也不同。因此，如何统一调控参数，使联动调控成为可能。带着这样的问题，我们追根溯源，发现计算能力的分配本质上是计算量的分配，计算量 = RT * 物理机械资源，当物理机械资源固定时，计算能力的分配等于RT的分配。因此RT调控是从单点孤立调控过渡到多点联动调控的可行路径，从局部计算能力分配到全局计算能力分配的优化。

图1 RT调控的引出

二、实践

2.1 RT调控实践

要实现全链路RT我们的想法是从局部单调控点开始，然后扩展到应用模块，最后扩展到整个发动机链路。具体分为三个步骤：

• 第一步:在单个功能点实现准确性RT控制

• 第二步:在单模块的多个功能点之间实现RT分配和控制

• 第三步:引擎实现全链路RT调控

具体施工工艺如下：

图2 RT调整施工过程

下面分别介绍以上三个步骤:

? 第一步 单功能点的RT调控

单调控点通常不同user的RT不一样。RT分布如下：

图3 海选RT分布图

横坐标是RT，纵坐标是RT对应pv绿线右侧的比例RT高，可以认为是毛刺，所以只需要尽可能准确地把这部分user单拉出来调整，控制好RT，这个功能点可以实现RT的控制。我们采取的思路是先通过预估流量的RT，将RT接近的user分成一个人群，通过控制这个人群的档位来实现这个人群的平均水平RT(因为已经对人群进行了分类，人群中的一切user RT接近)控制。(注:降档时尽量只影响毛刺RT的user，不误伤其他user。但毛刺user可能是高活user，因此，人们通常认为降档更容易影响效果。部分功能点RT控制确实如此，但对效果的影响有限。因为一是比例低，二是以前不控制可能已经超时，不超时一定比超时效果好，以下在线实验效果可以充分说明这一点。此外，效果层面的优化体现在整体视角上RT在分配方面，即使是高活user目前的模块不能超过目标RT，因为使用了其他模块RT更高效。）

以召回检索的功能点为例，介绍单机分组RT机制示意图如下：

图4 分人群RT控制

当一个User根据检索阶段进入检索阶段user标签数量和估计标签数量召回ad预测召回深度(这里认为召回深度和RT成正比)属于哪个群体，比如红线user3属于crowd1，此时crow1的档位是80，因此直接控制user3的tag数到80档；同时crowd根据该人群的平均情况，1根据人群的平均情况RT，目标RT每10秒调整一次，确保人群的真实性RT接近但<=可用RT为8ms。这样，每个人都有自己的档位。这样，每个人都有自己的档位。此外，监管策略是Agent上单机自行运行，效率更高(无需基于反馈链接收集metric），而且由于是单机自行调节，也能适应不同机器的不同水位，但始终保持不变<=8ms。

召回检索功能点的实验效果数据如下表所示：

表1 效果对比

与中控调整(不分人群)相比，平均检索深度 10%，sn RT p99-6ms，ctr 0.18%, rpm 0.70%，无动态算力桶ctr-3%, rpm-5%。动态计算能力中控调节优于无动态计算能力，分为人群RT控制优于中央控制调整(原因是只有更精细的减少)RT或者超时部分user，减少误降user比例和减少加时的比例)。

? 第二步 多功能点单模块RT控制

基于现有AllSpark框架，中控Controller负责每个功能点加载离线处理后的数据计算RT，然后下发给Agent，Agent每个功能点对应一个基于第一步机制实现功能点的控制器RT控制。

图5 单应用模块RT调控

? 第三步 全链路面向目标RT自适应调控

此功能是从外部视角看整个广告引擎，不同业务场景对广告引擎的响应时间要求不一样，因此可以每个场景设置自己的响应目标时间。场景响应目标时间变化，整个引擎该场景全链路各模块的可用RT将重新分配。此功能主要是为了应对大促前端对引擎RT(或者局部链路)要求的变化和有的特殊场景日常就已经RT触顶需要进行RT控制而实现。

该功能的核心完全是基于第二步的扩展，但因是整个引擎，链路较长而且涉及跨模块的调控，因此会有包括预调控以及外部服务RT控制等新机制。几个新的概念如下：

1）基于实时反馈的逐层调控和全局预调同时存在，相互配合

基于实时反馈的逐层调控：基于实时反馈调控，这个功能是去年动态算力使用最普遍和成熟的技术，即根据实时收集的metric，看是否满足要求，不满足则下调档位。结合下图说明：当前端目标RT 由300ms下调到160ms，如下图APP1检测到平均响应时间是240ms > 160ms，因此它逐步下调APP2的可用RT。因为这个下调操作导致APP2的超时率变高，因此APP2又逐步下调APP3,APP4和APP5的可用RT。类似如此逐层传递，直到APP1的响应时间<=160ms。

全局预调：基于实时反馈逐层调控收敛时间长，原因是逐层传递，再多次反馈调整。而且调整过程中会出现超时率高的问题。因此需要一种预调机制，当目标RT变化时，整个系统的调控尽可能一次性到位。实际上不同目标RT下，基于历史效果和RT数据是可以计算出合适的RT组合数据，当需要的时候只需要查出来即可。预调虽然快，但基于历史数据，它并不知道线上真实系统的水位情况(预调档位偏高或者偏低)，还是需要实时反馈的数据来微调。因此预调档位有过期时间T，当时间超过这个点时，会在预调档位的基础上切换到基于反馈的调整，适应真实的系统状态。



2）内部功能RT控制和外部服务RT控制相互协作

一个应用的响应时间取决于它自身的处理时间和外部服务的响应时间。这两者在RT控制的时候是有区别的。

内部功能RT控制：对应第二步中的分人群RT控制，对于如sn这个应用，它的三个功能点逻辑全在sn本地，可以实现精细化人群划分和RT控制。

外部服务RT控制：对于依赖的外部服务，在进行RT控制时，控制的是最大RT，也即超时时间。主要的考虑是对于服务调用方而言，它无法感知user在被调用服务中的状态，因此无法分人群也没有控制RT的具体抓手，所以需要的只是把升降档这个信息传递给下游服务，具体的调控由下游服务自行处理。而充当这种传递信息的指标超时率要好于平均RT，原因是前者更精准，超时率是最能反映下游服务是否正常的指标（超时率的统计则是依赖超时RT阈值设置）。另外也考虑到如300ms->160ms这种情况，如果不直接调整超时RT阈值进行硬控制(超过阈值就丢掉)，而是通过平均RT，很多下游服务的毛刺流量控不住，从而拖慢整个PV的响应时间，导致前端超时。

整体调控示意图如下：

图6 全链路RT调控

比如某场景响应时间由300ms下调到160ms。具体调控分为如下几步：

1）预调先行， Controller中TimePlanner接收到响应目标RT由300ms->160ms后，根据160ms直接查到此时全链路所有功能点的可用RT和在此RT限制时功能点的档位，然后直接下发给引擎各模块。各模块在几秒内生效，系统RT将直接下调到160ms附近。查询整体RT对应的具体功能点RT数据是Controller定期统计分配好的。

2）预调档位会生效一段时间，比如生效20秒之后将失效，交由基于反馈调节根据具体真实的水位情况进行档位调整。

2.2 管控视图升级

✪ 管控

相比旧版接入效率更高。在用户体验和安全检查等方面都有优化，如调控策略模版化，支持自定义新模版和复用已有的调控策略，支持档位COPY以及参数类型检查等等。

a）调控策略模版复用

图7 调控策略模版

b）参数类型检查

图8 参数类型检查

✪ 视图

新版视图让动态算力的整个调控状态朝可视化的方向迈出了第一步。

a）档位排行，展示实时以及历史档位波动问题。

图9 档位排行榜

b）RT响应控制档位，场景目标RT超过阈值或者前端看引擎超时率超过阈值，引擎会自动重新分配下游链路RT，以满足前端要求。

图10 引擎整体响应时间档位

c）分场景分机房不同链路的档位。(APP代表应用，MOD代表该应用上调控功能点，对应数值表示档位)

图11 链路详细档位

三、实战表现

✪ 日常

a）召回链路RT精准控制，保障算力不足时系统的稳定性。日常对整个召回链路控制在130ms，稳定运行。核心场景相比关闭动态算力桶，动态算力桶多天稳定cost+3%左右(说明动态算力通过精准RT控制减少超时以及个性化算力分配对效果提升有益)，如下图：

图12 效果对比

b）系统异常预警，相比其他手段，更加精细化(功能点粒度)和实效性高(几十秒)，而且系统能自适应的调整。过去一年，及时发现数十个问题，包括数据更新异常，容量不足，发布错误，坏机器等。

✪ 大促双十一

a）峰值档位定时生效。11月10号，11:56生效0点档位，极大简化大促预案，并且降低过去多项独立预案11:45推送导致效果损失，减少接近10分钟的严重降级对效果的影响。

b）0点03分打开自动档，随着qps下降，档位自动回升，水位和效果也及时回升。

水位：

图13 大促峰值附近CPU使用图

效果：

图14 大促峰值附近效果图

c）11.11白天，展示引擎交由动态算力调控，在RT满足要求下，展示广告(alimama_k2)整体水位35+%，AIOS水位排名前列。

图15 大促白天CPU使用图

四、总结和展望

4.1 总结

✪ 好的方面

1）整个引擎所有的RT控制交由动态算力分配管理，RT管理更加灵活(支持分场景配置和实时变更生效不用发布应用)和分配更加合理，为未来追求极致效率，进一步实现全局最优算力分配，建设高效的商业广告引擎打下坚实的基础。

2）在广告引擎这种上下游依赖且模块异质的系统中，针对模块效率评估的方法已经探索出了一条可行路径，目前在完善和落地中。

3）跟阿里云能源与碳管理团队合作 [3] ，进行流量在机房间的调度实验，探索算力与电力的关系，为动态算力未来的应用开辟了新的空间。

✪ 不足的方面

1）今年较多的时间投入在全链路的RT控制机制设计和落地上，在这种模块众多且异质，效果又相互依赖相互影响的拓扑上进行最优RT分配策略研究不足，未来需探索更优的策略。

2）调控效果还存在优化空间，针对具体的场景(如大促峰值)需要定制调控策略，在保障系统稳定的前提下，充分利用算力拿到更多的业务收益。

4.2 展望

未来Transformers会继续推进全局RT分配策略优化，并且与机器资源进行联合建模优化，以期实现全局最优算力分配，促进算力的使用由粗犷走向精细，低效走向高效。同时也将继续对算力，容量和效果之间的关系进行研究，用于长期资源管理和容量规划。总之，在算力不足已成为常态且性能优化进入深水区，动态算力尝试建立成本，算力和收益之间的桥梁，并且朝着使系统更加稳定，更加高效和智能的方向持续演进，让在线引擎像变形金刚一样灵活和强悍。

欢迎大家把文章转发给你身边有需要的技术同学，也欢迎在文末留言一起讨论。

参考文章

[1] 阿里展示广告引擎的"柔性"变形之路：

https://www.infoq.cn/article/wEaIlWl7076Id2bQptAq

[2] 美团外卖广告智能算力实践: 

https://mp.weixin.qq.com/s/VNEqziysVwnWg48aLi6GeA

[3] 阿里巴巴创新研究计划：

https://damo.alibaba.com/air/3a27c13b13b54482b77d8daaea48a96e