AI 异常计算点的监控调度

作者：胡俊彬

一、背景

互联网产业拥抱AI成为了当下的热潮：无人驾驶、医疗AI和智能推荐从实验室走出，融入到工程实业中；腾讯自主研发的王者荣耀等游戏AI给人们带去了快乐，“绝艺”更是获得了UEC杯冠军；而AI和海量计算力分不开，绝艺每天的盘数计算量都在亿级，王者每天计算结果均在百T，这些业务源源不断的计算力均来自腾讯架平TCS-弹性计算平台。该平台是根置于架平存储设备搭建而成，建设中最突出的问题是如何发现并调度异常计算点，本文从cpi的角度来介绍弹性平台的解决之道。

二、CPI

弹性平台中的设备都是在线业务与计算业务混部，尤其是AI计算，cpu时间片可完全吃满，利用率持续100%，但利用率反映的是当前机器在某个时间点的运行情况，并不能用于度量程序指令的cpu消耗，因此弹性平台需量化一个指标反映每条程序指令的执行耗时，CPI技术便被引入了弹性平台。

CPI的全称：Clock cycles Per Instruction，表示执行某个程序或者程序片段时每条指令所需的时钟周期数。从cpi角度计算程序执行的cpu周期，参考如下公式：

C表示指令数，假设程序的指令数一定，程序耗费在cpu上的周期数，取决于cpi值，cpi值越大，时钟周期数越多，反映到业务层的耗时也就越久。下图为计算测试的cpi值与延时的趋势图（存在噪点）：

三、业务建模

弹性平台采用异常CPI检测算法，使用cpi值监控业务运行状况，运营中捕获cpi异常点。cpi检测算法：监控正常运行的各种程序指标数据，将数据计算一个模型，通过模型的正常范围衡量实时运行的cpi值，超出范围，则为捕捉异常点。

模型定义

弹性平台复用的存储类母机上在线业务cpu使用率特点：稳定的分布在某个小范围内，针对这种情况，构建模型如下：

上图中每个圆代表一簇cpi值，由于映射到同一个cpu使用率区间而聚成簇。对于每一簇cpi值，计算其标准差，作为对应cpu使用率的cpi值所在的分布范围。0-n的cpu_usage计算所得cpi值分布范围组成模型。检测阶段，对于每个（cpu_usage,cpi）值对，首先根据cpu_usage映射到模型中某个簇中，通过cpi值比对标准差，判断该cpi是否在对应的正常范围内。

模型运营 模型训练的关键点：如何划分cpu_usage区段，划分过粗，模型中cpi值的区分度模糊；划分过细，模型中的cpi值失去统计意义。当前的实现中，结合存储业务的cpu特性，cpu_usage按照每0.001跨度划分，划分在目前看来有效。模型运营中简单的归纳为几个准则： a） 对于cpu利用率稳定的，宜细分cpu_usage；cpu跨度大的，宜粗分cpu_usage，且考虑同时映射到两个不同的簇。 b）考虑最近的簇所代表的cpu使用率，与当前cpu使用率值的差距，如果差距过大基本直接判定为异常分布。 c）现网运营中发现：cpu利用率低，但存在cpi值异常升高的情况，将其定义为噪点因素。而对于存储等cpu稳定的设备，当cpu利用率超过某个值（架平存储是25%），可以拟合出一条线性回归直线，采用训练和检验打分矫正有效性。

四、调度

运行中的AI运算，持续的吃cpu时间片，虽然Linux采用了CFS公平调度策略，但存储引擎与AI计算混部竞争，相比于单跑存储引擎，增加了调度和现场恢复等时延消耗。现网运营中还发现，AI计算火力全开时（如下图），存储引擎偶尔会出现获取cpu时间片不够的情况。综上，弹性平台监控存储引擎的cpi标准差，当偏差超过限定的范围，即为异常计算点，平台执行调整或调度操作。

冲突检测

存储引擎的实时cpi值与模型偏差差距N（可配置）倍的标准差，平台计为一次异常，考虑到毛刺的收敛，连续出现多次或者某段时间内出现N次，平台置为有效异常点并告警，根据异常的严重程度，平台做调整或者调度操作。

动态调整

监控到cpi异常，平台优先调低AI计算的quota值，调整采用“乘性减 加性增”策略，将quota值降一半，限制AI容器的cpu时间片分配，若一段时间内，cpi监控未检测到异常，平台加性恢复AI容器quota值。

跨机调度

平台统计的cpi异常调整次数超过N次，或者quota值小于period值，即可用的cpu能力小于一核，平台执行调度替换操作，并冻结被调度母机一段时间，此时间段内不会创建计算容器。下图为某业务调度月图。

五、总结

平台基于cpi构建的模型监控调度异常点，但由于在线业务的业务量、业务模型、网络环境的变化，会使cpi模型可用性降低。模型需动态更新，可持续性的描述现网业务的运行状态。对此，弹性平台正在做cpi异常告警数据的收集分析，并结合业务侧的时延不断的修正模型。

本文来自：腾讯架构师 公众号