智能算力思考

一 背景

在广告业务体量不断扩大，但机器资源有限的大前提下，业务优化的思路从“优化总收益”向“优化资源收益效率”转变，如何将CPU/GPU的每一个运转周期发挥出其最大价值是一个新的课题。在这样的大背景下，智能算力分配的概念应运而生。
从工程的角度出发，智能算力主要解决两个问题：
1、优质流量分配算力过少，运行rt不满足系统rt强约束，导致超时，浪费算力且没有收益
2、流量总体规模大于系统承载能力时，没有做到系统资源收益最大化

二 智能算力问题拆解

参考MLFS的概念，将机器学习用于系统参数优化，实现资源利用率最大化。在进行思考时，需要紧紧围绕第一节中提到的智能算力解决的两个主要问题。同时，智能算力的方案一定是一个低成本方案，若投入成本过高，则违背了“优化资源收益效率”的初衷。

2.1 “算力投入-业务收益”模型

智能算力的初衷是用相同的计算资源获得更多的业务收益。

首先需要明确几个关键定义：

• 计算资源（算力）

狭义的算力指对CPU/GPU的占用时间，单位为“核秒”或“卡秒”；广义算力还可以广到内存、存储资源等。在初期设计中主要考虑狭义算力定义。

cost = core * t

• 业务受益

在广告业务中，直观的业务收益指的就是在占用算力进行计算后，产生的实际广告收入。但是在CPC计费场景，当对访问pv投入算力进行计算后，不一定会产生点击收入，却并不能因此说这些算力的投入就是没有价值的。因此，业务收益应该重新定义为后验ecpm。

profit = ecpm

• 资源收益效率

R = profit / cost

这里可以看出，在CPU/GPU占用时间 和 ecpm之间，无法建立直接关系，在投入算力获得实际收益的过程中，还有一个重要环节，就是算法策略。算法策略可以简单地抽象为 算法模型 和 quota的组合。其中模型的复杂度、quota 与 占用算力之间存在正相关。令M表示模型复杂度（模型对单个doc打分带来的算力开销，可以实验得到），q表示quota，考虑到计算策略外的开销，一部分通常与quota成正比，另一部分与quota无关，则有

cost = M * q + A * q + B

其中A表示算法策略外算力开销和quota相关的调节因子，B表示常量开销。

同时，在这里假设ecpm和M、q之间满足一定函数关系f

ecpm = f(M * q,Q)

其中Q表示流量质量（即潜在价值）

至此，可以建立起收益和算力之间的关系

profit = f(cost - A * q - B,Q) 

则收益率为

R = f(cost - A * q - B,Q) / cost

这里可以看出，对于一个pv来说，其收益与算力之间的关系由Q、A、B、q、f决定。其中：

• Q需要预估或embedding得到（必需）
• A可以通过统计获得平均值（可认为已知）
• B可以通过实验精准获得（可认为已知）
• q可以根据情况动态调整（可作为调控参数）
• f是一个未知的函数，不同算法模型的f曲线是不同的，在一定程度上f曲线定义了“模型效率”（难以分析确定函数形式，可以通过神经网络拟合）

综上，对于一个pv，影响其“资源收益效率”的调控因子有：

• 分配的quota
• 投入的CPU/GPU使用时间

2.2 约束条件分析

智能算力面临两类约束条件。

2.2.1 rt约束

任意pv，全链路总 rt < T。
在处理逻辑运行过程中，可以将整体运行流畅分为可并行 与 不可并行两部分。假设所有执行quota运算的逻辑都是可并行的:

• 其中可并行的部分，其运行rt与并行core数量成反比
• 其中不可并行的部分，其运行rt又分为quota相关 和 quota无关

结合2.1节中的算式，rt可以抽象为如下模型

rt = M * q / core + A * q + B < T

2.2.2 资源约束

任意时刻，当前占用CPU/GPU数量 小于 系统CPU/GPU总量。换算到pv视角，即对于任意pv，为其分配的CPU/GPU核数不能超过当前剩余核数S。

core < S

2.3 优化目标分析

将2.1节、2.2节中的分析推广到多模型共同作用场景，得出如下优化目标。

2.3.1 机器资源充足

当流量不足，系统资源充足时，无需关心CPU/GPU核数约束，最大化收益


考虑到quota理想情况下可以无限放大，需要的算力开销也随之无限放大，因此，机器资源充足的假设在实际中并不存在。

若出于保护系统考虑，quota会被设定一个固定的上限（线上系统即是如此）。在这样的场景下，机器资源充足的假设成立，quota达到上限时，quota无法再继续影响实际受益，优化目标转化为

注意此处qi已经为常数，实际上已经变成了简单地线性规划。

2.3.2 机器资源不足

考虑到quota理想情况下可以无限放大，需要的算力开销也随之无限放大，因此，机器资源不足才是常态。
当流量过剩，机器资源不足时，最大化资源收益效率



其中M，q为多模型复杂度向量和quota向量，Mi表示第i个模型的复杂度，qi表示第i个模型的quota，f表示多模型联合收益函数。
在上面的优化目标中，求解f函数是所有工作的第一步，也是关键点（算法团队动态算力大部分集中在这一步），只有求得f函数的形式才能作进一步优化。一般可以通过“建模+拟合”、“神经网络拟合”或者强化学习等方式确定f函数。

2.4 智能算力运行时架构

智能算力的运行时架构主要需要完成以下任务：

• 计算模型常量
  • 对流量价值Q进行预估（可简化为embedding）
  • 根据采集数据和已知规则，周期计算M、A、B常量值
• 数据采集、追踪与回流
  • 追踪确定流量的后验ecpm
  • 回流各个环节的q、core等调控参数
• 系统状态监控
  • 采集各个环节当前CPU/GPU使用状态
• 模型训练
  • 周期性求解f函数
• 算力决策
  • 根据已知模型和参数，求解f函数约束条件下最优化问题
• 决策执行
  • 按照决策内容分配CPU/GPU资源

三 智能算力落地节奏分析

在系统中最终实现智能算力涉及很多专业领域，需要很多团队多方配合。

现试列举主要工作方向如下（按照落地先后顺序）：

3.1 计算模型常量

3.1.1 流量价值预估

主要团队：算法团队
主要工作：对流量价值进行embedding

3.1.2 常量值计算

主要团队：工程团队
主要工作：设计埋点；搭建数据采集框架；周期计算M、A、B常量值

3.2 数据采集、追踪与回流

主要团队：工程团队
主要工作：设计埋点；搭建数据追踪、回流框架
待解决问题：cpc场景，如何追踪后验ecpm（目前算法团队使用pctr * ppc ，即预估ecpm，但是这样可能会产生因果循环？）

3.3 系统状态监控

主要团队：工程团队
主要工作：监控系统算力水位

3.4 模型训练

主要团队：算法团队
在对模型进行大量简化后（恰好是2.3.2节中模型的简化），得出以下结论

3.5 算力决策**

主要团队：算法团队？工程团队？
主要工作：根据已知模型、常量参数、系统当前状态，求解约束条件下最优化问题
待解决问题：目前算法的简化模型与终局模型不完全一致，有合作空间，也有差异点

3.6 决策执行

主要团队：工程团队
主要工作：精确执行决策中分配的算力
待解决问题：技术方案待细化
参考链接：https://www.cnblogs.com/clover-toeic/p/3845210.html