深度丨Serverless + AIGC，一场围绕加速创新的升维布局

作者：褚杏娟

上图来源于基于函数计算部署 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 不仅指使用各种云端工具，还与系列产品进行探索结合，定制各种应用和功能。关键目标是极致地提升研发效率，降低成本，实现业务收益，实现商业目标。

第三，我们将尽量屏蔽多种语言的差异，使知识具备多语言特性。 此外还有底层解耦，包括未来的云漂移，核心在于解除厂商锁定。高德将努力参与开源，共建更好的运行环境、回馈生态系统，使大家能更好地接入这些技术。