本次由阿里云智能集团研究员人工智能平台PAI负责人林伟带来人工智能平台年度技术趋势主题演讲。
看来这个智能还要更智能一点，下午好，今天给大家分享一下过去一年里做的工作，以及这个行业工程技术的发展趋势，也是抛砖引玉，希望有同样感触的同行可以佐证，共同探讨我们看到的趋势是否有很好的共鸣，或者你有不同的观点，我也非常希望有更多这样的交流，一起推动AI的工程/AI的平台的建设。
我的分享包括五个方面：
第一是过去一年（2023年）大模型、特别是大语言模型非常快速的增长，刷新了很多人的想象空间。分享一下我们在大规模LLM训练中面临的一些挑战，我们做了哪些事情。
第二是AI的应用和服务，今年基模型的想象空间已经被打开，大家关心的是AI应用该怎么做，怎么落地，怎么样的把想象空间落实到真正的应用上、日常的工业、生活等所有的日常，它是一个很好的、能够提高人类生产力的工具。我主要是讲怎么应用这样的工具。
第三是怎么样在效率上提高AI工程，使我们能更环保的或更加有效的去把算力用好。
第四讲一下企业能力。最后还有我们把这些技术整合成一个大的技术品牌——Pai Prime 。
一、大规模LLM训练
我们在2021年-2020年就已经在说AI工程化很重要，我个人背景是做分布式系统的，我们一直认为不管是大数据还是AI最后需要非常大的算力集群、工程能力才能推动数据行业或AI行业发展。当时我们说AI工程化很重要时，有很多人有疑问，觉得当时AI的发展还是以CV为主，很多的情况下都是用AI做视觉识别、语音的识别等。那时只要有一台单G的GPU的服务器就可以了。
深度学习框架非常的透明化，得益于社区开源代码，大家有非常好的工具可以使用。客户会觉得还不如给一台GPU的服务器坐在脚下，想怎么折腾就怎么折腾，想写什么样的corner就写什么样的corner。作为一个云产品可以帮客户免运维、控制好整个服务器的稳定性、保障性能。但其实不是数据在上面，主要是模型训练，客户觉得这不像云存储，如果本地真的发生了灾难性的事情，可能数据丢失。在AI训练上面，大家会觉得那样反而不灵活。我们那时候说服客户去用云上的产品，会遇到一些难度和挑战。
但在过去的两年，挑战基本就没有了。因为真正要开始大语言模型需要成千上万张卡去规模化的训练。行业里的人都知道现在的硬件发展，我们对于算力的苛求是非常高的，已经推到了硬件的极限边界。有的时候大家都在说，现在的集群已经是在用英文把硅都在融化的状态，即算力对于能量的消耗是非常多的。我们可以看到集群里的硬件问题非常多，软件问题也非常多，因为迭代很快，又是一个高速互联的网络，有点像原来我们说的非常多的巨型机，像HPC的机器。
如果今年大家参加过GPC新制造的B200柜子，可以看到后面铜线已经让人觉得非常吃惊，怎样的把非常多的GPU卡利用非常高效的网络连起来。硬件已经在极限的边界。软件面对硬件非常快的迭代有很多问题，这不是一个人能够简单处理的，需要有集群能力，像我们这种专门做分布式、系统的人把系统维护、运行好。我们发现客户更加愿意用云上。我们说的AI工程化慢慢的越来越被很多人认同。AI工程化主要包括三个方面：第一是算力的云原生化。所谓的云化，就是可以用最经济的方式使用算力。如果觉得不需要，算力可能会被别人使用。大家按需使用，且有规模性，可大可小。这是为什么阿里云会积极的去建设一个非常大的data center集群。我们找电力、找很大的集群然后建设更大规模的集群。
第二是把编程和编程范式规模化。原来各种各样的引擎、框架是in house, 自己在自己的服务器装。版本管理、用这个软件的bug都可能会影响到训练的稳定性。我们通过把这些东西规模化、标准化，同时保证可扩展性，我们提供各种各样的用户可以自定义引擎。我们也提供非常多的官方引擎，能够使训练变得更加稳定。通过编程的范式化使用户在提交任务时更简单。第三是要有开放性， AI还是一个快速发展的阶段，我们怎么把开放性做好，使用户可以非常方便的做各种各样的探索是很重要的。
这是我们这几年一直在说的AI工程化。回到过去一年，我们的重点是在超大规模的集群里面碰到非常多的挑战。
第一个挑战就是大规模训练的故障问题。现在有很多人report我怎么训练大模型，包括最近facebook也提供了llama 3 405B的训练报告。大家可以看到里面的错误率是非常高的，在我们的集群里也同样。在这种错误率的情况下，需要有非常好的系统能力捕获错误。这种错误是繁杂的，有很多的错误是硬件的错误、软件的错误。有的错误还很难查，为了高效网络，有一个o reducer,就是ring通讯的一个集合原语，ring里哪一节点上发生了performance，从原语上是很难定位的。
怎么去快速定位，有很多错误，最难的错误不是fail stop错误，fail stop很简单，fell了、stop了，就有cool dump,看cool dump即可，最麻烦的是great fail，并不是不能跑，但不是稳定在某一节点上，这种错误该怎样找？这使我们很难定位这些错误，恢复成本很高。随着模型越来越大，我们的模型都是几百B，模型的拉起、重跑要花更长的时间。那我们怎么做？算法的同学对于模型的收敛也没有那么好的控制。我们基本上还是同步训练，不太用异步训练，因为异步训练会有一个变数，在收敛性上更难控制。同步训练一旦fair，所有的同步都会浪费，怎么样恢复训练是很大的挑战。这个图是在真实系统，可以看到非常多的错误，每个小的跳动都是一些错误。
要面对这样的挑战，我们主要从两个方向去做工作：
第一是高效的故障诊断，让用户能够无缝的感觉到我们对于框架、系统的理解，有很多好的set card信息诊断工具能够在用户正常的程序以外能够用探针的方式探查集群潜在的问题，预先发现问题，绕开问题。怎么样定义灰色的故障，如果错误的定义了故障，有可能会浪费现在做的一些工作，即false along,有一些误警报。如果没有定义出真正碰到错误，又浪费了很多的时间，训练会变得很慢等。
第二是如果出现故障，怎么让recover变得更快，我们怎样利用快照和恢复，原来的程序都是用户写的快照，用户用的是Patrick的safety point，这是一个同步方式，我们怎么样的把它转成异步的方式，转成on demand的方式，使它的恢复的开销很快，能够做到让check point的密度是分钟级的，也就是每次回滚最多能浪费一分钟/几分钟的训练。今天在主会场也说为什么要有高速的存储系统，就是因为我们希望recover能最快的方式回来，我们需要快速的漏很大的check point快速恢复。
怎么去诊断错误呢？我们通过对框架、系统的理解，可以做到透明的query。如果用过python其实都知道， python有一个master是拉起N个worker相连。我们现在需要有一个master能够观察整个训练的网络环境、资源环境，能够预先判断。中间触发自愈，规避一些有问题的节点。从用户的角度来说，他看到的是在连续训练，但我们其实已经帮助客户事先规避有可能出现的有问题或因负载过高开始出错的硬件。这叫做AI master。
怎样快速check point？我们怎么样把用户写的代码在无需改动的情况下就能复用异步化。我们把做check point的时间和做训练overlap，快速保存check point。有时甚至主动做check point，也就是忽然发现硬件绕不开，必须做checkpoint，回滚到上一个checkpoint，重新把任务拉起来，这个时候我们怎么样on demand做check point？
在面对很多硬件的情况下我们怎么保保证训练的稳定性和一直训练在去年是非常重要的。这也是我们为什么能够支持很多商业客户，比如通义，因为他们的训练都是资源饥渴的训练。如果每次都这样波动，一训练就训练很长时间，我们希望他完全感知不到这些硬件问题，可以持续不断的训练。
除此之外，这么大规模的集群怎么方便的做分布式训练也很重要，我们的算法创新因为写算法的人更关心的是算法结构以及怎样的清洗数据、怎么样的训练手段使模型有好的效果。对于工程、系统上面，我们怎么帮助他不需要担心分布式环境，由我们帮他做分布式，这也是为什么大家觉得分布式系统、平台或PAI的工程平台对他们有很好的帮助。
相比原来一个单机的服务器、单机的深度学习框架，我们在分布式主要有两个方面的工作：
第一是NV有一个很好的硬件，针对fast transformer或transformer结构的软件模块——maximum，对transformer结构支持的很好。这个结构考虑了怎么样充分利用NV所有的硬件能力（包括NV link），我们和NV有密切的合作，把它的易用性、很多其他功能进行加强，比如hacker face模型怎么样充分的利用magic所有能力、怎么在这个结构上做fantermjob、各种模式/格式的转换、微调、评估工具，我们推出pack maximum patch，如果大家对细节感兴趣，在今年的GTC有和NV一起关于这方面的分享，大家可以找一下。这是面对高频transformer结构模型我们做的工作。
另外PAI一直致力于通过智能化的东西让用户不考虑怎样分布式。前面的action分布式策略写的比较死，因为它的模型结构就是transformer。我们希望更加通用，我们作为平台不只服务transformer,需要有很多的同的创新，加一些模型结构，在算法上有非常多的想法。我们的一直投入AI compiler, 也就是AI编译器通过系统的理解把训练理解成一个图。
编译可以把它形式化的变成IR graph，然后通过graph的系统性理解，自动做分布式。早在pencil flow的时代就有尝试，其实pencil flow就是静态图，它有一个很好的工作XA，这个社区里面有很多的变，也有MRL等。我们非常早和XA和machine NL等国际团队紧密合作。最开始是做了一个动态shift的编译器，也是MR的工作，主要考虑the pencilshift有大小变化的时候怎么样编译称为 black disk. 随着pythontorch被更多人采用。
XA团队做了open XA，我们也是open XA非常关键的一个合作团队。我一起把XA的编译的技术和PAI torch结合，称为toech XA。，我们有很多基础框架的优化，在touch XA的框架下，在优化、扩的基础上把这个东西产品化，即把torch XA的产品化做touch a sandwich工作，这基本上是通过编译的能力，让更宽泛的模型结构能自动分布式。在去年的11月份 open XA团队在硅谷开了一次叫做open XA的default会议，在这个delay submit也讲了这个工作，如果大家对这个工作有兴趣可以去youtube上搜索。
正是因为它的通用性，我们可以很好的服务在ModelScope上所有的模型，以后在贡献模型时，这个工具也能自动优化，不需要手工分图，用户更少担心集群的分布式训练，只需要关注模型结构即可。这上面是我们写的一些提高性能的内容，我们已经整合和model scope的SDK做好衔接。在大部分model scope上，只要不是太裸写自己的模型，像python的编程的、net接口就能无缝利用这些能力。
刚刚说到的是怎么样帮助自动分布式。LLM最重要的能力就是不仅是要训练一个transformer，还需要用强化学习的方式alignment人类的能力，人类能够给很好的反馈。这也是为什么GTP能够有突破的一个很重要原因。我们在强化学习的部分会造成分布式训练的更大挑战。因为还要训练一个和模型结构、参数、规模对等的一个 reward model，那该怎么样去做？我们在工程上面怎么帮助？这个训练规模比原始模型在存储和分布式的消耗更大。我们怎么构建框架使得它更好的并行化alignment训练的方式。我们提供非常丰富的alignment、revolution model的训练帮助，真正想让自己的模型有非常好的效果，这是必不可少的步骤。我们积极的推动这个社区的建设。
正是因为我们有了这样好的alignment,帮助通义能够很好的去打榜、或逼近人类的认识。在今年的云栖大会，我们发布了新的72B以及我们即将要发布的在数学推理上面的增强。在数据推理上是要专门训练一个关于数学推理上的reward model, 能够强化数学推理能力。这背后都有框架在背后支持、帮助算法同学做分布式的训练，以及帮他们做好这些工程的封装。
二、AI应用和服务
现在的模型的服务是卷的很厉害，每半年就降价，今年我们又降价了。这些降价的背后是要工程支撑的。通过非常工程极致的优化调度，把所有资源能够充分利用以支撑成本的下降。只有成本下降才能够使模型真正能够普惠的服务到普通客户，这也是AI工程化的使命。我们不希望AI的建设只是给大家一个想象空间，而是希望它能真正普惠用到大家的日常生活中，给大家带来实惠，提高生活质量。怎样的把服务能力做到普惠是很重要的。
我们做些什么工作呢？我们主要的品牌是BladeLLM，有很多技术，有工程上面的技术也有模型上面的技术，模型上面优化的技术最重要的就是量化。但量化其实不像大家想的那么容易，因为模型本身是有一些玄学/黑盒的，怎么样证明量化下会造成统计分布的shift，中间会有一些bad case,怎么样评估量化效果没有带来副作用、怎么样的提供一个框架让用户/系统能够adaptive量化，而不是说简单的全图量化，全图量化效果不见得好，怎么adaptive，根据系统来/诉求的方法自动选择层，应该用什么方式量化……这些都是我们在推出工具帮助用户通过数据统计、各种各样的理解自动量化。同时我们也提供了丰富的量化evaluate工具，帮助用户evaluate量化出的模型到底效果如何。
在工程上面，我们根据AIM serving的这个preview和decoding的这个计算的python不同，怎么样做prefer和decoding的解耦；在服务态query是动态的，而模型服务是分布式、有多台机器共同服务的，我们怎么在动态的query的来时通过调度的方式balence多个资源，然后通过globe的调度、通过key value、cache各种技术做runtime的优化。如果大家对这个工作有兴趣，在今年的OSDI有一篇学术paper——nomics，可以去读一下paper、看一下我们在网上的payment的practice。这就是runtime的优化。
前面都是关于训练和推理，但真正要把AI应用起来，模型的应用是下一个爆发点，不然尽管有很好的训练，能够训练出好的机模型，服务成本也很低，但没有模型应用还是一个无源之水。这个图是关于模型应用的几个框架，框架不止这几个，有这llama index、也有long chain, 也有微软在做的powerful。在过去一年， gift star的star数都很高。大家都觉得训练机模型耗钱，但模型应用好像都可以参与。我们怎么样把模型应用给推动起来是很重要的。
这也有非常多工程上的挑战。举个例子， large知识增强的方式使用新模型的能力，过程很简单。模型怎样在一些context上面，在一专家领域的知识约束下回答问题。需要把文档要分片， poke net化后建index,即向量引擎。向量化后，通过query向量化后用向量引擎搜索一些相关内容。在相关内容上告诉这个机模型这是你的context，context综合和归纳所需的knowledge。这个过程有非常多的挑战。因为文档是千变万化的，格式也不统一。
第二文档不是一成不变的，可能不停的在增加新的文档，并且有订正。有时候会发现训练出来的模型没有达到预期，可能是文档有脏数据，怎么样的把脏数据文档找出并把它订正，又怎么样自动发布成模型，不可能每次发现有一个bad case都把所有的开发人员拉起来解决这个问题。
如果是全手工，这并不能快速迭代。如果做过工程都会发现这个过程中有非常多容易犯错的地方， 我们必须把AI和大数据紧密结合起来。通过非常好的数据平台能力，比如dataworks就是一个很好的数据平台能力。我们在原来做数据报表的时候也有同样的需求。有脏数据了，我们要更新这个报表，类似的，我也要更新我的向量引擎，我需要check中间怎么算出这些向量，这是数据清洗的部分。
在做模型服务的时候要收集很多模型服务的feedback，能够评估现在的prompt engineering或是我的向量数据库是否足够好，是否能正常的模型效果，怎么样的反馈给数据链路的开发者。刚刚的流程是有很复杂的流程，我们把怎么把复杂的流程工程化，并且自动发布。每一次都debug后，最终还是要把结果上升到方案服务，怎么样的把这个发布都做好，其实是需要紧密结合大数据和AI平台的能力，也就是把数据平台和PAI的平台紧密的结合。
三、GreenAI
总结起来是在工程上面我们从另一维度来思考这个问题，我们要用更加经济、更加高效的方式去服务AI，才能把AI真正的够普惠起来，才够可持续发展。我们发现AI是耗了非常多能量服务，这是不可持续的。成本最后都会matter，我们怎么样的通过分布式训练能力、容错、调度，快速应用的迭代（要是在摸索应用花了太长的时间，一样是资源的浪费）怎么通过高效的模型服务做到绿色AI的使命。
四、企业化能力
最后我想提一下，我们对于企业化的需求也非常重视。因为你在云上提供服务，不管是模型的提供方，还是数据提供方，他们对于自己的数据的安全，模型的安全都非常重视。有很多的客户在我们上面或者在百炼上面做function，包括是否会involve一些错误的数据使得模型被污染等面有大量的工具要做。我们在在数据安全上面其实做了很多工作，包括算法软件上面的工作、包括数据清洗、分析评估等。明天上午产品上面有一个同事会专门分享PAI在产品上的成果，如果大家对这个有兴趣可以去参加。
我们不仅在软件上面做这个事情，还从硬件上面就考虑可信计算。硬件上利用硬件的机密计算的能力，芯片上面的GPU、 CPU都有精密计算能力，从本质上面就能保证数据和模型的安全。我们联合基础软件团队、服务器团队、龙栖社区，以及S团队一起推出了全面的AI安全性的从硬件到上层软件的一个方案。如果大家有兴趣的话，今天这个论坛的最后一个session是由我的同事张佳会对这块进行详细的解读。我也很荣幸今天邀请了我们的合作伙伴赛迪公司一起做了一个全面性的关于安全AI的调研，以及怎么样定义一个完整安全性的AI它应该要具备的能力，之后会有一个发布。
五、Pai Prime
原来我们的所有的框架比较散，没有推出一个整体性的框架，但其实我们一直在做，可能这是第一次把这个框架整体上给大家做一个呈现。通过底层的核心技术，包括调度技术、编译的技术、分布式的技术和runtime这个技术，把自动分布式以及编译优化做起来，在上面呈现很多场景化的工作，包括在吸收模型、文生视频，LLM上面。整体这个框架的名词叫做prime，给大家呈现一下我们在自主可控的AI核心框架下整体的大图来了解我们怎样的去通过工程的能力、系统能力优化AI场景。
