今天给大家介绍的主题是灵骏智算实例异常预测技术，这是比较偏技术的分享，但不会介绍太多技术细节，如何提前预测GPU这类设备接下来是否会发生故障。围绕着这个主题，首先会讲一下为什么会想要做这件事情，就是我们的思路是什么；为什么我们会觉得预测这种事情是可行的，背后的原理是什么；我们目前做出了什么样的效果，是怎么做到的；最后是我们怎么样把预测技术和整个系统做集成、应用。
一、解决稳定性问题的思路
今天我们是在大模型训练场景之下来解决稳定性问题。大家应该对这个题目比较了解，本次会把和预测思路相关的要点介绍一下。大模型训练任务是在一个很大的GPU技术上跑的，它有成千上万张卡，从公开信息知道llama 3405B就用了16000张卡。其实光看这个数字也不是一个太大的问题，我们在几年之前就已经开始有超过万卡的异构集群生产了，我们也有这种运维经验。虽然故障很多，因为设备多、卡片多，同样的线性增长，故障就会更多。在这之前我们并不觉得这是一个特别大的问题，处理的非常好。但在大模型训练场景下，稳定性问题就开始变得突出。这是因为大模型训练是一个单一且同步的任务，即刚刚提到的16000张卡是在同步工作，这个里面任何一个故障都有可能导致任务中断，还需要重启。这有一个很严重的木桶效应，即一个故障会被放大，最后影响到集群的稳定性。我们能看到llama3405B的论文里面提到它平均每3.1个小时就会异常中断一次，这个对我们目前频率的稳定性造成了很大挑战，也使集群的运行效率变低。大部分普通的解决方法，其中有用户自己做框架，就是频繁存档，出了问题再去督导、恢复，然后重跑。这个方案的优化方向就是对存档、读档的开销优化，加快存档、读档的速度，还有优化任务、重启恢复的速度。当前这种方法还是有效的，但是我们从提供算力、做基础设施、做爱思、甚至做pass的角度出发，这种方案并不是我们乐意看到的，说明我们没有把自己的工作做好，需要用户在上层做些point。
我们希望做到的是直接提供有效稳定的算力，建设稳定的基础设施。这么说不仅是因为我们是做基础设施的，我们也认为如果能够从基础的层面解决问题，尽管过程更难、会面对更大的挑战、事情的复杂度会更高、有更多的工作量，但是一旦做到/实现，它的回报也是巨大的，因为这个收益具有更广泛的普适性。这张图表达了我们的愿景，我们认为应该在基础设施层面，指标监控/故障检测/异常预测/容错设计/任务性能感知都可以做好。我打个比方能帮助大家更好的理解我们做这件事的初衷。相信大家还记得以前我们去考驾照的时候，有一项考试是绕铁岭，这是非常难的考试项目，当时可能抽到这一项对大多数人来说意味着考试失败，要重新考了。但今天不再有这项考试了，因为现在道路的基础设施非常好，不需要驾驶员有这种高超的驾驶技巧去绕路上可能出现的坑坑洼洼。道理在算力基础设施这里也是一样的，我们应该把算力的基础设施做稳定，而不是让上面的用户锻炼自己高超的驾驶能力。
接下来就是为什么做稳定的基础设施很难，我们一开始并没有把它做好。这里我们先从向上层用户提供SL承诺的角度来定义一下什么是异常实例，即我们认为任何无法提供硬件有效算力服务的计算节点都是异常的，这里面包括有用户的任务无法初始化、跑起来之后卡住了，或故障退出、慢节点导致大模型训练任务被拖慢速度等。造成这些现象的原因环境不匹配、系统库bug、驱动bug、硬件故障等。所以对我们做基础设施稳定性而言，这更像是一个无限的责任。不管是已知的还是未知的问题，只要影响服务，我们都有责任去看他、解决他。另一方面是留给我们解决问题的空间在哪里。首先在实例节点上线之前，空间比较大，我们可以做规模较大、时间较长的压测，尽可能的发现问题。节点在入池上线之后，在真正有用户的业务还没有运行的空隙，空闲时我们可以安排快速巡检，也是一个主动检查，发现问题。这两种检测解决的问题是当用户的业务真正去跑起来，需要拿到一个实实例的节点的时候，我们能保证他拿到的是一个非常好的节点，这基本上可以做到。
我们看最后面的诊断，他的意思是已经知道节点有问题，先下线，然后我们再去用工具定位故障原因，这会有一些未知问题，需要人工介入，甚至于引入厂商的帮助。刚才说的压测、巡检和诊断都是比较容易做好的，但是真正的问题在于一个实例/计算节点绝大部分时间处于用户业务运行的时间里，这个图没有体现出来它的占比应该在90%以上，我们甚至希望是95% 或99%以上，因为用户业务运行的时间才是集群产生价值的时候。问题就在这里，这时留给我们检测的空间非常小，我们不能影响用户已经在跑的业务运行只能被动监控，当然也可以尝试做无感的主动的检测，但手脚是被束缚的，这种检测效果不如之前的压测、巡检。这就造成了刚才前面提到的我们无法很好的检查、无法提前发现问题，我们无法限于用户来找我们之前去主动的介入，大部分时候是用户的业务先挂了，然后再来问为什么，再定位。
二、预测的可行性和有效性
思路就转到了今天的主题：有没有可能去预测。答案是肯定的。虽然这听起来比较玄学，但是它和占卜的概念本质上是不一样的。原理是在一复杂系统中，这个复杂的系统不一定是指规模很大的GPU集群，单一一张GPU卡也是一个非常复杂的系统，我们知道hopper架构的GPU有800亿以上的基金管，它本身也是一个非常复杂的系统。在复杂系统中，业务的故障中断不会突然发生，之前一定有一系列小的问题异常。这些小问题/异常发生时不会引起系统立刻崩溃，只会逐渐增加系统压力风险，直到某一时刻变得不可逆，然后造成业务中断，系统故障发生。举两个例子大家应该就可以理解了。一是我们观察到的经验，在很严重的double bit error会造成卡的故障，业务的中断。double bit error发生之前可以观察到一系列single bit error的发生。
另外一种是故障发生之前，你会观察string micro processor的时钟频率和利用率这两个指标事先会发生不正常的抖动。这两个例子比较容易理解，它更多的像是一种运维经验沉淀到系统中。可以分为两类：一类是时序指标，提前会发生模式的突变，刚才举的两个例子都是这一种。另外一种是某些关键指标的分布模式可能是不同的。我也举个简单的例子，如果某一张卡的温度一直较高，那么它发生故障的概率就会大一些。这个例子可能不是那么好，但是它比较直观容易理解。打个比方，很有经验的汽车维修师傅主要听发动机的噪音就知道发动机的车况如何，原理其实都差不多。刚才所提到的三个例子都是可解释的、很容易被我们人所理解的例子，但还有很多数据里面存在的数据之间的关联性，我们可以用机器学习的方式去挖掘，而且机器学习可以更快的发现经验，并且把它用起来。
这里介绍一下，做到预场预测之后可获得的收益，就是可以大幅度的缩减需要训练的时间和任务重启的时间，从而提升系统的稳定性和效率。时间有限，我不会去一个一个去念。可以大致看到随着预测的和别的一些技术相结合，收益的空间逐步变大。特别是和刚才topic介绍，如果我们把预测和快速的热线移动结合可以把故障相关的开销压到极致小，几乎没有影响。这样就把集群的利用率在大模型训练场景下提升到很高。
三、监控能力建设和数据积累
这里介绍一下我们目前做到异常预测的算法效果。我们可以做到在1-250分钟之间提前预测，准确率达95%以上，召回率达20%以上。1-250分钟比较容易理解，就是最多提前四个多小时给出预测报警。但准确率和召回率怎么理解呢？先说召回率20%，意思是在接下来的时间中，所有真实会发生的故障里有20%多会给出预测报警，给出的预测报警的准确率在95%以上，也就是接下来95%的概率真的会发生。
这三个数字一起描述了预测算法的效果。大家可能会奇怪95%和20%这两个数字，为什么一个准确率这么高，但召回率这么低。这是我们主动选择的策略，我们希望尽可能有把握的情况下给出预测报警，为我们接下来主动介入的动作/影响到用户的业务的动作不要那么多。这是算法的阈值，可以调整，我们可以把准确率下调到90%左右，这时召回率就可以提升到50%以上。这都是同一个算法，我们应用时根据策略选择，对算法的阈值做调整。所以接下来如果热迁移做的非常好，或有一些别的主动运维动作，对业务影响、开销较小的话，我们就可以把召回率调高一些，我们可以覆盖的故障数量就会变得更多。所以我们不用太过于关注这几个算法效果的数字。
有没有可能做到双高，就是准确率很高，召回率也很高，这个很难，从刚才介绍大家也能够理解，准确率高的意思是算法也发现了一些别的故障，但是不是那么有把握，所以不敢保障，召回率就低了。想要做到双高，目前也还有提升的空间，还需要持续的把它做好。总体而言，这两个指标存在有一定的矛盾，所以不用太关注绝对的数字的效果。我们来看一下是怎么做到的。这背后并没有太多的奇思妙想，或非常有意思的创新，最主要、最关键的地方就是数据，数据的数量和质量都非常重要。首先来看数据方面，我们需要去做到有非常丰富的设备和业务指标，目前做到有超过千项的设备指标都可以采集和落盘，同时我们还可以主动探入业务的情况，对业务的性能指标也可了解。比方说推理的延时和存储量，训练一般不存在延迟，训练的速度也可用QPS描述，这些我们都是直接在底层知道的。
所有数据我们可以按照整机、整卡和视频卡维度整理和汇总。业务本身和设备本身的一些属性，这些静态信息是有的，还有运行时的一些不同指标、log日志，我们也有收集、落盘。做长期大规模的采集的建设不是一蹴而就的。自2020年起我们就已开始在阿里集团来做统一指标的采集和收集。一开始指标没有那么多，这也是逐渐增长的过程。目前规模达到了数万卡的集群的规模。这里还有很多工作是需要支持各种不同的业务场景，包括各种不同的技术栈、装饰，还有安全容器，不同技术也要去支持。所以能够去做多指标、这么大规模、这么长期的数据采集，本身也是基础设施的长期能力建设。这是数量方面，质量方面是有了这么多数据，我下一步就是要做到给这些数据打上充足且准确的标签。我希望能够做到对各种设备模块做细分检查，显存、SM、PCIE都要能够区别开，对各种不同的故障也要做专项识别，比如掉卡，显存泄露、ECC、驱动故障等。目前识别已经做到假阴性率几乎为0，非常准确。意思是识别出的故障是他，那他基本上肯定是，标签还是非常准的。质量的另一方面就是时效性，需要预测算法的完整生命周期能够快速迭代。一方面算法推理时，预测算法本身的推理模块部署在线上，我们要做持续跟踪，把结果作为监控数据的一部分，同时收集，然后做数据预处理，再训练，然后优化推理模块再部署。这些都需要有完整的热升级方案，在线上尽量非常快的迭代，以便及时、在线更新推理模型。
四、系统的集成和应用
刚才介绍的部分已经有系统化的设计了，最右边的这圈就是预测模型的快速迭代更新。这是我们与AI Infra集成的框架，中间是采集收集和预测推理模块在实例上是如何工作的，可以服务各种分析、治愈和观测的系统。前面应该有同学介绍过的相关内容。运行时也可以对引擎框架和调度系统提供健康方面的信息。别的模块就不展开讲了，我就介绍一个我们设计比较好的点，就是预测的算法推理模块是在端上部署的，不需要把推理所需的数据传到中心端平台再推理。这种设计、好处有两个：一是技术方面，显著降低了网络开销。预测算法的推理所消耗的数据量很大，对数据实时性的要求也比较高，因为要立刻推理，这部分的网络开销就被节省了。推理模块在端上对资源的消耗比较小。目前测下来，在峰值时不会超过0.13个CPU和700兆的内存消耗。它是一个机器学习的若干个小模型的综合体，本身不消耗GPU算力，这也是比较好的点。另一方面在产品设计上，我们在端上部署， 避免了从数据向中心端传递，很好的保护了用户的数据隐私，这也使得用户使用这个能力时可以更放心、更方便快捷的把预测能力用起来。我的介绍就到这里，谢谢大家。
