当前位置:首页|资讯|AIGC|谷歌

Seal梁胜:近水楼台先得月,IT人员应充分利用AI解决问题

作者:Seal软件发布时间:2023-09-06

2023年9月2日,由平台工程技术社区与数澈软件Seal联合举办的⌈AIGC时代下的平台工程⌋——2023平台工程技术大会在北京圆满收官。吸引了近300名平台工程爱好者现场参会,超过3000名观众在线上直播平台观看了本届大会。

数澈软件 Seal 联合创始人梁胜博士和江鹏受邀出席此次大会并发表题为《AI时代的IT技术创新》的演讲,本文为演讲实录。


AI 正以不可逆转之势发展

这周二我去旧金山参加了谷歌一年一度的云计算大会(Google Cloud Next 23),这大约是我第8次参加这个活动,但今年与往届完全不同。在今年的大会上很少谈及云计算的底层基础技术,也没有介绍 Kubernetes 的进展,在近2个小时的主题演讲中几乎 100% 的时间都在谈论 AI 技术。从这里,我们可以看出 AI 技术给整个 IT 行业以及云计算带来了巨大的影响。
 

为什么会有这么大的影响呢?从我个人过去十几年从事云计算领域的体验来看,云计算根本上解决的是资源的问题。在没有云计算之前,如果需要资源,那么要购买机器、搭建机房,但云计算出现之后,就不需要干这样的事情了。取而代之的是,出现了 DevOps、Infrastructure as Code(IaC),这些新技术的出现大大增加了企业对人力资源的需求。在这样的情况下,未来的 IT 行业可能会面临的挑战不再是优化机器资源,而是优化人力资源,包括 IT 的人力资源或 IT 以外的人力资源。因此,AI 成为了一个恰如其分的主题。
 


现在技术领域的人力资源主要集中在两个方向:研发和运维。人员需求的方向定义了现代软件开发到部署、到运维、到升级的整个生命周期流程。我在上图的右侧列出了两个云厂商,但即便不部署在云上,部署在本地机器或者边缘设备上,整套软件开发流程并没有太大变化。
 

在过去十年中,甚至全球经济不景气的当下,对 IT 人员的需求量依旧非常大。这样的增长会不会继续呢?现在 AI 技术的出现对这个增长会有什么影响呢?
 


我们先从研发的角度来看这个问题。各位现在最为感同身受的可能是国内外的企业都在进行裁员,为什么会如此?
 

大家仔细想想过去的业界发展态势,比如移动互联网,大家每天都在手机端上使用各种 App,那么仔细回忆一下上次用到的新应用是什么时候?对我来讲,是有相当长的一段时间以前了。但是如果把时间拨回5年前、10年前,那可能每过几天、几个星期可能就会下载一个新的应用,当时新的东西源源不断地出现。但现在大家可能主要使用的只是各自领域里的主流App,比如抖音、微信、B站以及各种网银之类的。
 

尽管现在开发应用比以前容易得多,但长尾效应在慢慢减弱。
 

那么真正的研发现在去哪里了呢?从广义来说,现阶段的研发是那些在各种大平台不断生产内容的网红,他们可以吸引很多用户。那将来的研发又会往哪个方向走呢?从现在生成式 AI 的角度来看,研发的方向会越来越多。无论是 AI 会帮助研发,还是会直接被 AI 替代,AI 的发展是不可避免的。
 

接下来,我来讲讲软件 2.0,这个概念是由一个从事人工智能开发的程序员提出来的,是指世界上越来越多的事情是由软件来实现的。
 

现阶段,大家可以用 AI 助手来帮助生成一段代码,然后检查一下代码是否存在错误,如果没有问题就可以用了。我们大胆猜想:那么之后是不是可以用一个神经网或者一个 AI 模块来实现?可能你直接告诉 AI 你要做什么,神经网就直接把功能实现了,甚至不需要看到代码。
 

AI 在未来5年、10年的发展,会让很多想象的东西都成为现实,这对研发来说会造成很大的冲击。那么,将来研发人员的数量是否还会继续增长?我觉得毫无疑问,肯定会持续增长,但是方向可能和现在有很大的差别。
 

DevOps 遇瓶颈,AI 来破局


我个人对 DevOps 行业非常有体会,因为之前我做过 CloudStack、做过 Rancher,这些产品都是为 DevOps 服务的,过去十年伴随着云计算的快速发展,可以说是 DevOps 的飞速成长期,我们正好赶上了 DevOps 的热潮。
 

正如我前面提到的,在没有云计算之前使用资源需要购买机器、购买网络设备,这些设备需要有专门的人进行编程和配置,那些人就是思科认证的或者华为认证的工程师。
 

在 DevOps 时代,已经不依赖手动配置了,可能是 DevOps 工程师来写脚本,或者更多时候就直接写程序,所以可以说 DevOps 工程师其实是新一代的思科认证工程师。
 

但有些系统十分复杂,比如 Kubernetes,那么这给诸如 Rancher、HashiCorp、GitLab、DataDog 之类的公司创造很大的机会,这些创新公司都已经成长为大型企业。尽管是红利受益者,但我们也在反思:为什么企业对 DevOps 的需求量无法抑制地增长
 

最早 DevOps 刚刚出现的时候,正常的人员配比应该是 10 个研发人员,配 1 个 DevOps 工程师。但发展到后来就发现这样的人员配比导致 DevOps 人员的压力好大,于是变成 5:1。再到后来,那些发展迅速的互联网企业内部的配比已经变成 3:1,甚至 2:1。这通常意味着这个系统已经过于复杂了。
 

当前,在 DevOps 领域已经出现了很多工具,但这些工具也并不能完全减轻这些人的压力。那么在现在的 AI 时代,可能还会需要更多的运维人员对大模型、应用进行运维,情况也许会变得更加糟糕。
 

基于此,我们思考是否可以把 DevOps 的复杂度控制下来,那么“平台工程”的概念就出现了。不同企业的内部环境差异极大,那么怎么能够真正把内部的 DevOps 流程变得更加有效,而不是机械地重复?AI 的出现将会带来一个全新的机会。
 


AI时代中非常明显的现象是,无论是公有云、私有云还是混合云,将来在云上运行的大模型将会占据越来越高的比例。所以云需要针对大模型的运行进行优化,真正把它们给运行好。稍后我们也会演示如何快速部署大模型。
 

另外,AI 不应该仅仅服务于终端用户,我们既然是 IT 从业者,应该“近水楼台先得月”,充分利用 AI 技术来解决我们自己的问题,比如 AI 可以减轻 DevOps 工程师的工作量。这样研发与 DevOps 的比例就可以不断下降,最终达到理想状态。
 


绝大部分 AI 应用的本质是云应用,并且现在 Kubernetes 实际上已经成为大模型平台的运行标准。上图截取自 OpenAI 的官网,当时 GPT3 已经推出,但 ChatGPT 尚未诞生。值得注意的是,Kubernetes 官方推荐使用的最大节点数是5000,但 OpenAI 因为需求量大,已经把 Kubernetes 用到极致——扩展到7500个节点。
 

据我了解,他们现在仍然在使用 Kubernetes,但目前的具体使用状况外部也不是很清楚。我相信,在他们迎来爆发式增长的这段时间,应该是把 Kubernetes 扩展得更大了。OpenAI、微软 Azure 这些公司都在大量购入 Nvidia 的图像处理器,然后放在服务器里,由 Kubernetes 等技术进行管理,最后再在上层运行大语言模型。
 

总而言之,AI 时代下的整个应用架构基本上已经建立了,这也是目前业界都比较认可的标准:最底层是公有云、私有云,再往上是 Kubernetes,然后是管理 AI 本身的一些工具,比如 Pytorch、Tensorflow,再往上层是大模型,顶层是应用
 

AI释放开源力量,开源赋能AI发展


数澈软件Seal 本身是一家开源的公司,我们这个团队投身开源领域已经有十几年了,我们一直认为开源是非常好的方向。但直到 AI 出现之后,我们才真正体会到开源的力量。
 

上图中,红色的线表示 Kubernetes star 数量的增长趋势,到今年刚刚超过 10 万颗 star。众所周知,Kubernetes 早已成为业界认可的容器编排的事实标准。但是 AI 相关的开源项目 star 数量能在几个月之内就超越 Kubernetes,这令人惊叹。所以可以看出开源界对 AI 的重视程度,另外一方面,开源也能够为 AI 带来一些真正的机会。
 

在现阶段,闭源软件的创业已经很难成功了,所以在软件领域开源是必须的。因为开源社区是跨国界的,不受地缘政治的限制。比如,在中国结束了疫情管控之后,目前最流行的开源组织之一,云计算基金会 CNCF,就立马到上海来举办 KubeCon,完全没有受到政治方面的影响。
 

换言之,中国企业可以通过开源把真正世界级的技术推向全球,成为全球技术的引领者,并从中获得很多发展的机会。
 


上文提到 AI 必须能够帮助 DevOps 工程师提升效率,在传统 DevOps 领域也曾有类似的需求,那时候叫自动化(Automation),通过脚本把手工工作变为自动。
 

但是自动化发展到一定程度之后,仍然对人有巨大的需求。因为很多需要判断力的事情,无法通过简单的脚本规则来规定清楚,主要还得依靠人进行判断。所以自动化的下一步应该是 AI。
 

上方左侧的图片是波音747刚刚推出时的驾驶舱配置,当时(上世纪60年代)大约需要3、4个驾驶员,2个驾驶飞机,剩下的观测仪表盘。通过自动化的改进,现在基本上2个人就可以开飞机了,复杂的仪表也消失了。那要再往下前进一步,能不能既减少开飞机的人数,同时还能提升安全性?这时候光靠自动化已经不够了。
 

那么我们希望通过 AI 能够真正把运维工作自动化,一会儿江鹏会对我们目前已经完成的工作进行演示。目前我们只是刚刚开始,我们希望通过开源让大家能够尝试、使用并且能够给我们提意见。
 

平台工程为 AI 提供护栏(Guardrail)

大家在用 ChatGPT 的时候可能会发现,它尽管能回答你的问题,但并不一定是对的,因为大模型不是 100% 可靠。这个缺陷对于简单的任务来说无足轻重,但如果是在生产环境上运行的应用,在接收到错误的命令之后直接运行,可能会造成难以估量的后果。
 

因此我们在思考能够降低大模型出错的概率的方案,这在业界有一个标准的做法——Guardrail,即通过给 AI 系统设置规则来对其进行限制,比如预计限制让 AI 只控制阿里云、腾讯云、AWS。
 

因此我们在中间添加一层机制进行审核,如果出现明显的错误,那么审核不通过。在审核通过之后,再让 AI 的指令上手完成任务。而这些是可以平台工程实现的。这类似于我们常常提到的自动驾驶汽车,因为路况太复杂,所以自动驾驶汽车的实现是很困难的。但是如果说我们要做自动驾驶火车,那就简单很多。因为火车被限制在轨道上运行,路况相对来说简单很多。
 


所以平台工程不仅应该为工程师提供工具,还应该为 AI 提供护栏(Guardrail)。
 


数澈软件Seal 正在借助 Guardrail 机制开发 AI 时代的 DevOps 平台,希望能够给 DevOps 工程师减轻工作量并成为他们的 AI 助手。接下来,我将介绍我们目前已经完成的工作,然后邀请江鹏进行产品演示。
 


关于平台工程,业界已经形成了基本的认知:平台工程的出现主要是为了解决 DevOps 复杂度的问题。
 

首先,平台工程可以解决 DevOps 团队和研发团队之间的沟通协作问题。因为研发团队平时通常通过 IDE 来完成工作,他们也许能清晰地了解业务需求、程序设计语言和框架、包括当前的 AI 技术,但是他们可能完全不了解 DevOps 工具,比如 Terraform 可以做什么,怎么样部署 Kubernetes ,于是这些成为了 DevOps 团队的工作。那么这两个团队之间的协作成为一个问题,无论是通过邮件还是发工单进行沟通,都非常繁琐,且易出错,因此需要平台工程。
 


在过去两三年间,我们和至少几百家企业交流过,发现大家都有类似的需求。最终就形成了企业内部的平台,它为研发人员提供UI、CLI以及服务目录(Catalog),研发人员可以直接调用现成的工具来完成应用开发工作。
 

但是我们发现,由于没有现成的解决方案,每个团队在搭建平台过程中都对中间的一层花费了大量的精力,我们把它称之为“应用管理”。
 

为什么叫应用管理呢?因为它关心的是应用配置、部署可靠性以及多环境管理,甚至包括应用成本。通过应用管理层,企业可以清楚地了解各类环境信息,应用开发资源的成本管理,包括生产环境中的实例成本、研发团队成本、测试团队成本等,方便企业进行优化。
 


之前提到,我们与上百家公司交流过,每家公司内部都在构建自己的一套应用管理,并且再和开发者门户进行集成。实际上开发应用管理工作量是很大的,并且十分繁琐,于是我们构建了这样一个开源应用管理平台 Walrus。
 

Walrus 是一款 100% 开源的基于平台工程理念构建的应用管理平台,开源地址是:github.com/seal-io/walrus。除了基础的应用部署、服务模板等功能,我们把 AI 技术列为了开发重点。所以在 Walrus 平台内部整合了丰富的 AI 技术,我们还提供一个 AI 助手 Appilot(预计本月中下旬开源,敬请期待),帮助用户运维。那接下来有请江鹏来进行演示。
 

点击下方视频,空降至 35:45 即可查看 Seal联合创始人及COO 江鹏的产品演示,包括在 Walrus 上借助其服务模板的特性快速部署 Meta 开源大模型 Llama 2 和 Stable Diffusion,并引入 Seal AI 助手 Appilot,通过输入自然语言,借助 AI 大模型的推理能力完成资源调度、服务查询、应用部署等任务。

 https://www.bilibili.com/video/BV158411B7Mn/?spm_id_from=333.999.0.0&vd_source=0afbb2a94baeee24b5d65e44bc1e58d9

参考链接:https://mp.weixin.qq.com/s/4FHYX1Vlm__nCBX300moJg
作者:Seal 软件



Copyright © 2024 aigcdaily.cn  北京智识时代科技有限公司  版权所有  京ICP备2023006237号-1