明确算力决策要解决的问题,定义算力决策的目标是一切讨论的基础。直观上,大家对算力决策的期待有两种表达形式:
“收益持平的前提下,成本降低x%”、“成本不变的前提下,收益增长x%”这种表达形式仅仅描述了在“当前算成本-收益点位下”的工作成果。成本与收益之间的关系往往是高度非线性的。同样的策略,在成本约束为100w core时收益增长1%,可能在成本约束为1000w core时仅增涨0.1%;在收益10亿/天时节省成本1000 w/天,可能在在收益8亿/天时节省成本500 w/天。如果约束本身也是波动的,我们很难长期跟踪算力决策系统的效果。
建议在长期跟踪算力决策价值时,首先将算力约束的值长期确定下来,并在此基础上定期进行反转实验,观察收益变化。
相对于理论分析,真实的广告系统有一些额外的考虑因素。
除了总算力需要满足约束以外,单个请求的算力开销也有限制,否则会导致超时。
若不考虑并行,单Req的时延约束 其实就是 单Req算力约束 的另一种体现形式。
由于各个模块的配比未必达到最优,可能在调控时出现短板效应。
不过长期来看,模块间资源配比应该达到动态最优,因此不应该是一个强约束。
机器资源总量是显而易见的约束。
调控分为两层:一是单请求的微观调控,实现单请求目标最大化;二是系统层面的宏观调控。实现系统的目标最大化。
让每个请求在规定时间内完成计算,并通过下面的调控手段进行干预:
策略分为多个子问题。
基于当下已有的调控点,测算各个调控Action带来的算力开销。
基于当下已有的调控点,测算各个调控Action对收入的影响。
max
调控策略
∑
i
Q
(
调控策略
)
/
C
(
调控策略
)
s.t.
单
R
e
q
时延约束
系统约束
上述宏观调控模型忽略了各模块间资源可能不匹配的现状。虽然长期不匹配问题不会存在,但是短期仍需考虑其实际影响。如考虑不匹配因素,则“算力充足/不足态”是一个局部概念,无法简单的做判断。
为了解决这个问题,可能需要对系统状态进行embedding,在求解单Req ROI最大化时,需要考虑系统约束。
系统约束可能包含各模块SLO、时延、集群CPU/网卡/内存负载等。
建立CPU、GPU、带宽、内存开销度量体系。
请求/系统粒度采样决策内容、算力开销、系统状态、广告收入等内容。
基于当前策略需要设计完善的在线决策工程体系。