共计 11348 个字符，预计需要花费 29 分钟才能阅读完成。
作者：褚杏娟
上图来源于基于函数计算部署 SD 实现光影成果
前言：
Serverless 在中国倒退这些年，经验了低潮、低谷、当初从新回到公众视线。很多企业都十分感兴趣，局部企业开始大规模利用；也有一些企业对在生产环境真正落地蠢蠢欲动。
同时，在当下 AIGC 技术浪潮中，Serverless 如何与 AIGC 更好联合施展更大的价值？
带着这些问题，InfoQ 记者对话阿里云智能 Serverless 研发负责人杨皓然、高德服务端负责人孙蔚，一起探讨 Serverless 和 AIGC 联合能够激发哪些想象力？
Serverless 新进展
问题 1：从去年强调 Serverless 化至今，在这半年的工夫里，阿里云在 Serverless 技术方面获得了哪些停顿？
杨皓然： 2022 年，阿里云在 Serverless 方面提出了十分明确的观点，认为 Serverless 是云计算的下一个阶段，阿里云致力于让整个产品体系 Serverless 化。次要在以下几个方向上继续倒退：
第一个方向是产品体系的 Serverless 化。 2022 年，数据库曾经全面采纳了 Serverless 的模式，而往年更多的中间件服务也逐渐 Serverless 化，包含传统的微服务注册核心和网关等，同时消息中间件也会提供 Serverless 的产品状态。
第二个方向是通过 Serverless 让云服务可能更细腻地集成，最终目标是让这些服务成为开发者构建利用的原子化、可组合组件，使开发者可能应用即开即用的组件来疾速构建利用。
第三个方向是持续深耕 Serverless 计算平台自身的技术能力。 这包含进一步晋升函数计算、Serverless 利用引擎 SAE 的弹性速度，以及 GPU 的 Serverless 化停顿等。在容器的 Serverless 状态方面，阿里云推出了全新降级的容器服务 Serverless 版，为开发者提供更丰盛的抉择，从容器到利用将失去全栈反对。
孙蔚： 从具体利用 Serverless 的角度，我来补充下关注到的三个停顿。
第一方面，Serverless 的产品越来 越稳固，而且反对以单元化的形式部署。 同时，其可观测性和性能等方面做得也十分好，观测指标丰盛，能够直观看出问题实质；性能方面，延时很低，对服务自身没有影响，冷启动工夫也在一直优化。依据咱们的实测，业务切换到 Serverless 的确会减少 TP99 RT（Response Time）工夫，大概提早 2 毫秒左右，稳定性方面体现十分好。从交易切换到 Serverless 上的实际论断得出，交易架构 Serverless 化是可行的。
第二方面，Serverless 生态工具、产品十分丰盛， 如：反对工具流、集成工具等。开发者真正要做的是组装式研发：代码和配置拆散，抉择实用的工具流，采纳 BFF（Backend For Frontend）模式，联合本人的 FaaS（Function as a Service）框架去开发，这可能极大地晋升工作效率，升高开发成本。
第三方面，目前有很多产品反对 Serverless。 其中对高德吸引较大的是数据库类 Serverless 产品。如果数据库的全副性能都曾经实现了 Serverless，那么咱们就能够实现从前端到后端再到数据库的全面 Serverless 化，从而极大地降低成本，真正做到零运维、按需付费。
问题 2：实际中，还有哪些技术难点仍在攻坚中？
孙蔚： Serverless 的开发存在许多技术难点，而每家公司在这方面的摸索都各不相同。每个公司都有本人的框架，须要将其与现有架构相结合并进行调用。这个过程中，确保本人的架构可能真正与 Serverless 产品紧密结合、晋升效率的同时还要保障稳定性，可能须要在运行时 Runtime 上或原有架构上做一些改变。
杨皓然： 我从平台角度再补充下。方才提到的冷启动或者延时方面，的确对 Serverless 来说是一个比拟大的挑战。Serverless 的资源应用是动静的，这给性能和延时稳定性带来了挑战。解决这个问题也是往年阿里云要攻克的技术难点之一，即提供十分稳固的 TP99 延时。 这须要对整个端对端链路的优化，甚至软硬联合的优化，以尽可能地缩减整个链路的延时。另外，还须要深度优化和整合整个零碎，包含操作系统和平安容器，以尽可能地让实例利用、实例函数的执行以及算力保持稳定。另外在 GPU 下面，新的 GPU 虚拟化技术和弹性技术也有很多技术须要攻关。
问题 3： 在利用方面，企业通常会遇到什么样的问题？**
孙蔚： 每个企业在 Serverless 上的决策不同，面临的问题也不同。我分享下高德开始接入的难题，就是解决“一套代码解决多地运行的问题”。外围来讲就是 2 个词：“提效、降本”。所以，高德在最开始就做了脚手架，后续也会对其开源。该脚手架的外围指标是解决间接应用 Serverless 老本高的问题，让业务只关怀业务自身，无需治理底层运行机制。借助这个脚手架，利用能够更高效地开发，同时在在函数外面也能够调用多个中间件或聚合服务。脚手架实现 MQ、事件、编排等性能，目前也在反对“多云底座”。
杨皓然： 高德可能一开始就在 Serverless 畛域里投入并获得比拟好的成果，我察看有以下几个起因：
首先它自身在整个服务端的架构设计，包含语言选择等有长时间的积攒。比方他们整个技术栈是用 Go，这跟 Serverless 的理念十分合拍；其次他们做了大量针对业务场景的定制化脚手架，促成 Serverless 研发提效。咱们明天看到的一些 Serverless 落地，更多地是在 Golang、Node.js、Python 等十分适配云原生理念的语言上，可能取得更多的益处。
阿里外部研发配套的框架能力绝对残缺， 咱们次要工作方向就是为私有云的客户把配套的研发提效能力释放出来，让私有云客户充分利用好云的能力。并且是以开源的形式，包含跟高德一起凋谢 runtime Golang 相干的工具。咱们会以更凋谢的形式去打造针对 Serverless 的研发效力服务。大家会在往年看到咱们的一些后果，并且以开源凋谢的模式来经营。
问题 4：这些性能是不是 Knative 也能够实现？这样其实背地也是想理解下厂商的产品和开源产品有什么区别？
杨皓然： 能够实现的。但实质上说，当探讨 Serverless 平台时，开发者次要关注投入产出比。举个例子，用户有多种抉择，一种是基于 Knative+Java 体系，应用 Spring Boot、Spring Cloud 框架，并在 ECS 上运行。在微服务场景下，这种生态环境十分残缺，但资源应用不足弹性，与云相比降低成本难度较大。为了解决这个问题，能够采纳容器化加上 HPA 模式的弹性伸缩。
整个 Serverless 平台能够大抵分为两个档次。第一个档次是计算层， 旨在实现实例的疾速弹性伸缩，甚至反对 0～N 的弹性伸缩。在弹性伸缩的状况下，要放弃 P99 延时的稳定性，但这会带来系统性挑战。目前在开源体系中尚未有对应的产品可能解决这些挑战，但云平台或云服务能够更好地解决，因为它们能够进行软硬体系整合并投入更多资源进行优化。这样的投入老本须要由较大的平台来摊派，能力使整体投资回报率较为合算。
第二个档次是应用层， 即与利用的治理和研发效力服务配套的研发效力服务。这包含整合云服务和开源软件，为开发者提供问题诊断测试、开发测试、问题诊断以及自动化部署等全流程服务。这方面的优化也须要投入大量精力进行打磨。
在我看来，大家都有能力做好这些，关键在于解决问题是业务导向还是技术导向或平台导向。如果以业务导向为指标，就须要思考口头的老本效益。我集体十分看好 Serverless，如果可能将研发提效和降本的价值更好的传播给企业和开发者，它必定会变得十分风行，因为这合乎业务导向公司的实质需要。
问题 5：在国内 Serverless 落地处在哪一个阶段？
杨皓然： 依据我的察看，很多头部公司面临着高速变动和高速增长的业务需要。为了可能疾速撑持这些业务诉求，这些公司开始思考采纳 Serverless 架构。然而，要让 Serverless 架构得以理论利用，就须要相应的配套研发效力服务以及平台自身的性能和稳定性能力。这是 Serverless 落地的次要挑战点。
另一个问题是对于 Serverless 如何落地，我认为须要依据具体情况来思考。对于相似 SAE（Serverless 利用引擎，一款极繁难用的利用托管产品）的产品，这类产品最次要的劣势在于其弹性和差异化能力，如果可能做好对存量利用的兼容，那么用户在选型时就不会遇到特地大的阻力。例如，它在降本提效方面给用户带来更多劣势？如果可能明确体现出这一点，那么许多公司都会对这类产品产生趣味和需要。
目前，国内的头部公司实际上曾经在十分外围的链路上应用了 Serverless。然而，当初最次要的问题是如何将这些能力以开源凋谢的形式在私有云上释放出来，使其成为一个普惠的能力，进而让更多公司受害于 Serverless 所带来的成绩。
孙蔚： 我补充两个倡议。对于前端业务，实践上个别是用 Node.js 来进行多端适配，解决前端研发提效的问题，即客户的研发和产品开发，再加上测试，就能够搞定端到端服务。
对于后端业务，相对来说应用 Go 语言会比拟好。雷同环境和性能下，Java 的包会比拟大，镜像也比拟大，启动工夫比拟长，而 Go 语言能够做到疾速拉起，天生适宜后端业务。当然也能够思考应用 Rust 语言，但 Rust 的门槛比拟高，且对于前端来说，通常会应用 Node.js 作为 FaaS 的函数语言，后端则能够抉择 Go 语言。如果波及到较多算法，能够思考应用 Python 等。C++ 也能够是一个抉择，但次要问题依然是老本较高，模板的老本也较高。不论如何，外围还是要让开发变得更简略。
以高德为例，前端次要应用 Node.js，后端在导航层面应用 C++，在性能层面应用 Go，而算法层面则局部应用 Python。这样多种语言联合起来应用，可能更好地满足业务需要。
AIGC 带来了哪些变动
* 问题 6： AIGC 给咱们两位老师的日常工作带来了哪些变动？高德和阿里云有做过哪些初步的尝试吗？*
杨皓然： 我认为 AIGC 对咱们的工作有着微小的影响，或者说在将来会有微小的影响。作为一个次要从事服务方面工作的人，咱们要解决云原生利用的弹性、容错性和开发便捷性等问题。在 AIGC 的框架下，我置信将来 AI 能力将以 API 的模式开释，并与业务紧密结合。 这须要咱们将多变的业务与 AI 的能力无效联合起来，这也是咱们始终关注的 Serverless 畛域的一个重点。
另一方面，AI 不断加强的一个体现就是代码生成能力，咱们要思考将来的利用架构如何更适配 AIGC 的能力和特点。比方，如果你有一个全功能的单体架构利用，那你是否可能在这个单体架构上借助 AIGC 的能力来增量开发性能？是否存在其余更好的架构可能充分利用 AIGC 的代码生成能力，从而减速整个代码开发和测试效率？
在将来，我认为开发者或架构师须要具备一个十分重要的能力，就是思考如何设计一个利用架构，使其与 AI 的能力适配，并可能更好地应用 AI 的能力。无论是从疾速性能迭代、架构弹性、稳定性，还是从老本等角度思考，这都是一个十分有意思且值得咱们长期思考的问题。
孙蔚： 我关注的次要有两个方面。
从业务和商业产品的角度来看，每家公司都有本人的业余畛域常识。比方在营销畛域，你可能领有很强的业余能力，并且所在公司也是一家营销公司，你可能会思考如何将 AIGC 利用到营销畛域中。当然你可能会面临一些挑战，例如如何利用开源工具构建大型模型利用、如何应用深度学习办法和多个图像来训练模型、如何构建向量数据库，以及如何在业务场景下进行调度和聚合等。这些波及将序列化架构的理念与 AIGC 基于 API 的服务架构相结合，从而构建整体利用并向别人提供服务或 API。用户能够依据业务畛域的常识和积攒，充分利用 AIGC 来优化业务畛域的产品设计。
综上所述，我认为 有三个要害因素 ： 首先是本身领有十分业余的业务畛域常识，如：向量数据库、Serverless 架构等方面；其次是具备大模型的技术能力，可能须要算法方面的常识；最初是 Serverless 架构的销售理念。 将这三者联合起来，就能够打包输入做商业变现。
Serverless+AIGC=？
问题 7：业界有一种说法，Serverless 是 AIGC 的下一块拼图，为什么会这样说？在两位看来，与 AIGC 联合将会带来哪些全新的设想？
孙蔚： AIGC 的确给各行业带来了很多设想的空间，涵盖了图像处理、视频剪辑、文字生成、广告素材、Logo 设计、智能客服以及语音合成等方面。然而，目前存在的一个次要问题是，大多数厂商提供的大模型对外都是量化调用的，须要通过 API 接口调用，因厂商算力问题调用一次工夫很长，还会受到调用次数限度。因而，咱们目前仍处于摸索阶段。
然而，假如所有的大模型（无论是 GPT 系列还是其余开源模型）作为产品来进行销售和计费，能够按需付费，同时最大化解决算力问题。此外，还波及到运行隔离和大数据安全等问题。从这个角度来看，Serverless 能够被视为解决 AIGC 商业化问题的下一个拼图。
我集体的判断是，AIGC 存在这些问题最终都会失去被解决，许多与 AIGC 相干的产品就会去解决算力和调度等问题，推动 AIGC 相干产品的倒退。如果这些产品可能联合起来，对整个零碎从工程到终端服务、数据库、底层中间件以及 AI 和算力等层面进行一体化的调用，那么整个系列将全副残缺。
杨皓然： AI 与利用架构和服务集成的适配是一个重要问题。针对 AIGC 利用，能够从几个方面进行思考。
首先，软件架构应该适应 AI 的能力。 以前的 ”All in One” 单体架构能够充分利用 AIGC 的后劲，然而基于 AI 的利用通常须要更涣散耦合的微服务架构，以便实现每个性能或微服务的繁多指标和明确的输入输出。这种架构能够进步代码生成的精确度和效率，但也带来了治理和调试挑战，这些其实正好就是 Serverless 架构要解决的问题，我感觉这是他们很好的结合点。
其次，AIGC 在利用的全流程中都施展重要作用。 在开发阶段，咱们能够利用 AIGC 的代码生成能力和辅助工具（如 GitHub Copilot）放慢迭代速度。在部署阶段，能够应用基础设施即代码（IaC）等自动化工具疾速部署不同的云服务或资源，满足利用的依赖关。此外，通过相似申明式语言或 YAML 的定义，底层的 IaC 服务也能够自动化地执行这些能力，而不是手动在管制台上进行操作。
那么，Serverless 怎么帮忙 AIGC 更好地落地？咱们能够从以下几个方面开展。
首先，在业务逻辑与 AI 能力的联合方面，AI 利用能够分为两方面。 一方面，只有将 AI 的能力与业务逻辑联合，能力实现真正的业务价值。另一方面，AI 模型的能力通常是通过 API 裸露进去的，相似在线利用将业务逻辑与 AI 的 API 能力组合起来后能够疾速构建利用。这种状况下，倡议采纳相似微服务架构的松耦合架构和组装式开发理念。
此外，AI 模型的托管和服务化也是重要的思考因素。 将 AI 模型的能力转化为 API 服务、提供灰度公布和回滚等性能，能够更高效地利用资源并升高复杂性。这种模式可能让更多的模型能力通过 API 形式提供。我置信 Serverless 能让这个复杂度变得更低。有助于让更多的模型能力通过 API 形式施展进去。
最初，AIGC 中的模型迭代和版本化也很重要。 特地是对于大型公司来说，可能须要围绕大型模型构建数据库和知识库等周边资源，并进行数据荡涤、提炼和模型微调，最终将它们转化为新的模型。这种以版本化形式进行迭代并部署公布形式的实现，须要大量的软件工程能力。在这方面，开源软件和云服务提供商都在致力减少本身能力，以便更好地整合 AIGC 的简单流程和软件栈、升高复杂度。这种集成对于 AIGC 来说是十分有价值的，也是 Serverless 可能为 AIGC 提供价值的一个重要方面。
问题 8：Serverless 是用于部署 AIGC 相干模型的吗？
孙蔚： 有两个角度能够思考。首先，你能够将 AIGC 与 Serverless 联合。Serverless 能够解决后期服务的按需定制、计算资源爱护等问题。在耗费大量计算资源、同时运行多个计算工作导致内存溢出等状况下，你能够在 Serverless 上进行部署，并采取适当的调度。
另一方面，如果要解决相干模型的问题，须要思考模型的数量以及在何处部署模型。在部署模型时能够应用 Serverless，这意味着当你搭建本人的算法平台时，能够自行设计算法平台。当要部署多个模型或者拆分模型等时，能够联合 Serverless 来进步性能并改善效力。无论是进行训练还是自动化都可用 Serverless。
总结来说，Serverless 能够用于内部，也能够利用于外部。 在内部应用时，它更像是一个黑盒，你能够通过公开的信息进行解释。而在外部应用时，它次要用于进步算法模型的部署、主动迭代训练，包含数据荡涤等方面。外部还是内部应用取决于集体抉择，因为 Serverless 自身是一种架构理念，并没有限定的应用范畴。
杨皓然： 从架构理念的角度来看，咱们能够更具体地探讨 Serverless 平台和计算服务是否适宜托管模型。我认为这取决于具体情况。通常状况下，Serverless 计算服务适宜托管一部分模型，即那些可能充分发挥服务弹性的模型。
然而，对于通义千问、ChatGPT 或开源版本等较大的模型来说，它们对计算资源的需要十分高。在这种状况下，我认为这类模型可能不太适宜在 Serverless 平台上托管。是否托管最终还是取决于平台自身的计算能力取向与限度。
问题 9：AIGC 利用有哪些特点？Serverless 如何帮忙帮忙开发者进行 AIGC 利用开发和部署？此外，Serverless+AIGC 还有哪些成熟的案例或者利用场景？
杨皓然： 我感觉，AIGC 利用与常见的在线利用有许多相似之处。在许多状况下，它们依然会组合底层模型的 API 能力，以实现业务逻辑。然而，对于一类非凡的 AIGC 利用，更适宜采纳异步自驱动的架构，例如聊天机器人或者像 LangChain 这样专门的开发框架。在 LangChain 框架中定义了许多相似代理 (agent) 的概念，这些代理与底层模型的 API 进行交互，像一个大脑，但须要执行许多实际操作。
这些实际操作是真正与理论业务需要和场景联合、解决理论问题的。 而这些操作实际上是具体的性能，是无状态的，能实现简略的操作，但非常灵活。在这种模式下，将它们部署在相似函数服务上是十分符合的。
因而，依据咱们之前的察看，AIGC 利用的特点与 Serverless 架构理念十分适配。Serverless 提供了一些开发工具，让客户将模型转化为服务的能力更加简略。通过 Serverless 平台，用户可能不须要太多的开发背景，只需理解其中的一些细节就能够疾速设置并应用。
我之前与一位客户进行过交换。他是一位设计师，有肯定的代码开发背景，但并不深刻。他在 Serverless 平台上可能疾速设置 Stable Diffusion 等开源模型，并最终实现业务成果。这是 Serverless 与 AIGC 利用联合的理论案例。
我置信在将来，随着以 LangChain 为代表的 AI 利用框架的成熟，咱们将看到许多相似的利用将在 Serverless 平台上运行，这是最短的门路。
孙蔚： AIGC 利用的实质是提高效率。无论是制作广告素材、内容、视频或 Logo 等，AIGC 利用都是利用现有工具提高效率来代替传统的人力老本。此外，AIGC 利用还能够用于数据处理，包含数据标注和数据荡涤等畛域。应用 AIGC 能够实现提效的外围指标，一方面是智能提效，另一方面是性能提效。
然而，在部署 AIGC 时，是否真正应用 Serverless 平台次要取决于预测的场景，以及是基于开源还是自行开发的模型。对于基于开源的状况，须要思考利用中的挑战点；而对于自行开发的模型，须要依据耗费状况来应用 Serverless 进行优化和爱护。
具体应用 Serverless 平台部署 AIGC 利用时，还需综合思考应用场景和相干挑战，并依据预测场景进行优化。对于基于开源或自行开发的模型，能够通过 Serverless 平台来优化算力耗费，尤其是在模型加载和 AI 计算环节中耗费较大的状况，能够思考应用 Serverless 架构进行重写。同时，引入其余向量并在训练值上构建畛域性的向量数据库，也有助于进一步优化 AIGC 利用。
通过将架构拆分并应用 Serverless 平台进行开发和部署的优化，用户能够依据业务需要在内核层面进行适当的改良。倡议在应用 Serverless 打包时，不仅将其视为黑盒进行公布和部署，而是依据业务层面或内核层面的需要进行调整。
须要指出的是，目前尚没有大规模利用于线上的 AIGC 案例。 这些都还在摸索阶段。提出的这些想法是咱们正在摸索的一个方向，供大家参考。
问题 10：在 AI 浪潮下，根底云服务或者说 Serverless 服务怎么体现为其带来的价值？
杨皓然： AIGC 利用须要将 AI 能力与理论业务逻辑联合起来，根底的云服务如数据库、对象存储和音讯队列等依然是必须的，并且与底层的 AI 能力进行交互通常须要应用 API。如果这些组合人造造成了一个业务逻辑与 AI 能力的整体，那么与云服务整体架构严密集成后，开发者可能疾速组合这些性能来构建利用，这是十分匹配的。
随着云服务基础架构的 Serverless 化以及云产品整体架构的严密集成，这对 AI 利用的倒退具备微小的减速作用。AI 利用可能并不仅限于传统的在线利用模式，还能够采纳事件驱动的架构或像 LangChain 这样的疾速开发框架，实现交互式的 AI 能力利用。
从逻辑上看，AIGC 利用能够分为两个局部：决策逻辑和执行动作。 决策逻辑波及依据输出进行决策的 AI 能力，而执行动作波及与第三方 API 的交互等碎片化的代码、强调轻量和牢靠地执行。这种执行性能非常适合在 Serverless 计算服务上运行。
此外，刚刚还提到了如何依据业务场景对 AI 模型进行 Fine-tuning，甚至构建专属于企业的大型模型。这是一个简单的流程，须要深刻的技术栈和软件栈。在这方面，须要集成许多开源软件和云产品，使客户可能更快地设置整个流水线。问题诊断等能力也十分重要。因而，Serverless 服务的指标是使云的整体产品体系互相集成和可组合。
通过工作流等工具，能够疾速编排流水线，将大数据服务或 AI 服务等已有的服务通过事件驱动的形式与用户本人的业务逻辑和数据处理流程相结合。这样，客户能够依据本身企业的状况建设适配的学习流水线，这些能力将极大地帮忙客户。
问题 11：阿里云的 Serverless 产品线有因为 AIGC 做一些相应的调整吗？
杨皓然： 在过来几年的布局和倒退中，咱们平台重视适配各种性能，包含与风行的开源 AI 框架匹配。在整个平台的倒退方向上，咱们重视与 AI 的倒退相符合。从整个布局来看，咱们在几年前就开始布局 GPU 和 Serverless 等能力，并公布了相应的产品，并继续进行迭代和改良。
孙蔚： 在我看来，Serverless 实质上是一种架构理念。在以后的技术浪潮中，我认为它有两个重要的价值。
首先，AI 的痛点有很多，比方算力等问题，通过联合服务化的架构理念，能够将 AI 产品进行服务化，这的确可能解决目前中心化的问题，并实现更多的 AI 产品商业化。
其次，如果 AI 反对商业化、整个业务也反对商业化，那么通过业务逻辑与 AIGC API 的联合上，再加上对整个算法的商业化反对，就可能实现从前到后的全方位反对，例如能够实现按需弹性扩大、事件驱动、流程编排等各种性能，这才是真正的实现。
举例来说，对于一个守业公司来说，如果他们只懂前端、Python、PHP 或 Node.js，他们也能够应用 AIGC，还能够进行工程开发、提供服务、设计界面等各种工作，简直能够做任何事件。实际上，Serverless 屏蔽了所有底层实现的细节，从工程到算法到数据到服务，极大地开释了效率。 这样，有人专一于底层开发，其他人专一于工程开发，我认为这才是将来的终局。
问题 12：底层技术演进对大模型等最新 AI 趋势会带来哪些影响？
孙蔚： 依据我的察看，次要有两个方面的倒退。
首先，我想先谈谈算力的普惠化。 在将来两到三年，算力将变得越来越遍及。目前算力的确是一个问题。随着技术的倒退，算力将可能真正解决大规模商业 AI 的问题，并广泛应用于各行各业，迎来一个普惠的时代。
其次，我想谈谈技术工程的倒退， 这包含云原生利用、服务化以及后面提到的云原生数据库等。这些底层技术的倒退将促成 AI 技术畛域的提高。从前到后，无论是算法的内核、模型加载还是训练局部，它们都将采纳公正的理念，即算法的交融，来推动整个 AIGC 或 AI 的功能化，使其更多地商用化。换言之，通过算力、AI、工程、业务、前端等的普及化，使研发变得更加简略。
杨皓然： 我认为底层技术的演进对于大模型等最新 AI 趋势会产生以下影响。
首先，波及到大模型的生成和训练，与服务化、虚拟化关系不大。这些大模型的训练通常须要高性能计算集群，相似于高性能计算（HPC）的模式，对于网络带宽和计算效力的要求十分高。然而，一旦这些模型训练实现，如何通过 API 等形式施展其能力，或者让客户可能疾速开发基于这些大型模型的 AI 利用并实现业务价值，则与 Serverless 或云原生等相干技术密切相关。这与咱们之前重复提到的内容相干，我就不再赘述了。
这里的重点在于，底层技术的演进不仅波及到大型模型的生成和训练，还包含如何将其能力通过服务化和云原生等技术利用于理论业务中，以实现疾速开发和兑现价值的指标。
问题 13：将来 3~5 年，高德对于 Serverless 还会有哪些技术改革和深刻摸索的中央？阿里云面对 AIGC 的疾速倒退将如何布局？
杨皓然： 我了解阿里云的 AIGC 布局十分重要，因为 AI 和大型模型的能力对阿里云来说是外围策略。 这涵盖了从大型模型训练到以大型模型为外围构建利用的能力，都是阿里云十分重要的工作。我并不是该畛域的专家，因而不会展开讨论大型模型的训练，但我认为阿里云将通过将 Serverless 与 AIGC 能力联合，实现围绕大型模型能力疾速构建利用的指标，这与我的工作相干。
在这种联合形式方面，我提到了几个方向。首先，咱们将推动利用开发架构与 AI 能力的适配。 咱们提倡打造一系列产品和研发效力工具，反对松耦合、精简的代码和利用架构，使这些利用可能与 AIGC 能力完满适配。
其次，咱们的研发效力工具将与 AIGC 能力联合， 使客户更容易生成精准的代码，包含工作流程定义和云资源的基础设施及代码（IaC）定义，从而让客户可能更疾速地在整个利用生命周期中享受 AIGC 带来的效率晋升。
第三，咱们会在 Serverless GPU 方面继续投入研发。 然而，咱们的指标并不是托管大模型，而是让更精简的模型可能适配 Serverless 平台的特点，并在该平台上运行。实质指标依然是帮忙用户解决高老本的问题。
孙蔚： 高德目前次要在上面三个方面进行摸索。
第一，是高德的 Serverless 次要在事件驱动、工作流方面进行改良和深刻摸索，实现 Serverless 的极致弹性和有限扩大，目标是降低成本和提高效率。 工作流方面，高德的指标是实现代码和配置的拆散，并联合本人开发的业务流程引擎，使晋升效率加倍。
这不仅仅是简略的低代码，还波及流程编排和与业务的联合，与高德的特点密切相关。高德的特点在于领有大量的流量，同时能够提供打车和加油等不同的交易服务，这是一个跨多个利用的畛域。
第二，高德将持续与行业联合， 在数据库相干的 Serverless 产品以及向量数据库等方面持续摸索。这些产品都具备一个特点，即存算拆散。通过存算拆散能够充分利用 Serverless 来升高研发老本、极大地晋升效率。
不过，可能须要依据开源工具进行定制和 Serverless 攻关的解决。Serverless 不仅指应用各种云端工具，还与系列产品进行摸索联合，定制各种利用和性能。要害指标是极致地晋升研发效率，降低成本，实现业务收益，实现商业指标。
第三，咱们将尽量屏蔽多种语言的差别，使常识具备多语言个性。 此外还有底层解耦，包含将来的云漂移，外围在于解除厂商锁定。高德将致力参加开源，共建更好的运行环境、回馈生态系统，使大家能更好地接入这些技术。