客户端
游戏
无障碍

2

评论

4

2

手机看

微信扫一扫,随时随地看

大模型多云部署怎么玩?阿里创作平台 MuseAI 集团内外落地指南

图片

作者 | 陈佳伟,王一凡
审校 | 刘侃,Kitty
写在前面

MuseAI 是由阿里集团爱橙科技研发的面向阿里内部的 AIGC 创作工作台,在《显卡在偷懒?阿里大模型创作平台 MuseAI 极速模型切换技术提升 AI 创作效率》一文中,我们有详细介绍该平台相关背景信息。本文以阿里真实使用场景出发,分享 MuseAI 多云部署架构实践。

随着大模型技术从技术变革转向产业变革,大模型应用也会进一步繁荣,传统基础设施技术已经不足以满足大模型应用的快速发展,整个基础设施技术和产业链正在快速转型,向大模型基础设施技术演变。2025 QCon 全球软件开发大会(北京站)策划了「面向 AI 的研发基础设施」专题,将深入分析 AI 基础设施的关键技术,包括机房服务器和芯片设计、大规模高性能网络技术、分布式模型并行技术、推理架构优化、算法和工程的结合等优化技术,以及它们在大规模生产环境中的应用和实践。如果你有相关案例想要分享,欢迎通过以下链接提交演讲申请:https://jsj.top/f/tUOLpz

一、使用场景

Muse 平台在集团内上线后获得了大量用户的使用和认可,也和众多团队建立了多种生图、训练场景的合作与共创。倍感荣幸的同时,发现大家对我们的平台有更高的期望和更多的需求。

整体梳理下来,大家的需求主要有三个场景:

  • 外部环境使用 Muse 生图能力

  • 基于 Muse 平台的 AI 生成能力二次开发垂类平台

  • 复用 Muse 部分产品能力

我们基于这些需求去调整系统架构,从而系统地支持此类的需求。针对集团内外同时部署的场景,我们设计了 Java 后端统一代码库进行多云部署;针对二次开发,我们定义了 API 接入规范;针对复用产品能力,我们设计了前端组件化接入来实现高效复用。以上方案都已经在集团内外多个场景实现了落地,本文详细分析各个方案的架构实现和演进过程。

二、需求分析
2.1 外部环境使用

要实现在外部环境使用,一般有两种方案:(1)外部直接在阿里云(公有云)上部署一套后端服务;(2)仍然使用内部的服务,通过集团公共网关暴露服务。

第一种方案在外部云上环境直接部署一套后端服务,这个方案比较直接。集团内的应用必然依赖了很多集团内的中间件以及云资源,如果要在外部部署的话,需要解决两个问题:

  1. 内部的中间件换成外部的中间件;

  2. 自行实现自动化部署的链路。

前者的复杂度主要取决于产品依赖的中间件的数量,对于我们系统而言,主要是用了 Diamond,SchedulerX,Redis 和数据库等,大多可以在云上环境找到替代产品。后者的话,需要在 Aone 的流水线自行实现发布部署的功能,我们会在下文介绍详细逻辑。

第二种方案是基于淘宝开放平台将内部的接口暴露出来保证云上环境可调用,这个方案的复用程度很高,如果集团内外基本逻辑一致,数据也是共享的情况下,用这种方案算是改造成本较低的选择。

图片

无论采用哪种方案,都必然会面对一个问题:部分逻辑在不同环境的实现是有差异的。例如,用户体系的差异,内部通过 BUC 可以获取到用户信息,集团外可能是手机号注册等别的链路;此外,集团内外对于安全管控的要求也不一样,以及部分业务逻辑的实现也是有差异的。对于这些情况,集团外独立部署的话,可以直接做不同的实现,更加自由,而通过 TOP 暴露内部接口的方案,就要考虑如何在一套服务里去做不同的实现了。

2.2 二次开发能力

对于 API 调用主要有两个诉求:(1)接口化调用生图能力;(2)接口化调用训练能力。两者都需要一套稳定的鉴权体系和资源隔离逻辑。如果生图量较小的话可以直接复用我们的资源池,如果生图量大的话可以选择闲时调用,比如夜间集中调用。此外针对训练任务,我们还支持使用私有资源进行调用。

通过 api 调用生图接口主要面临生图参数过多的问题,让业务方去构造复杂的生图请求非常容易出现请求失败。我们一方面支持直接传全量生图参数的接口,一方面支持先在 Muse 平台生图后保存相关参数为生图预设,后续根据生图预设来生图,并支持替换其中的部分参数。

针对训练接口,我们除了提供发起训练任务的功能,也提供图片裁剪、图片标注等辅助功能。由于训练相关的功能链路和耗时较长,因此我们也提供了丰富的异步状态查询和管理接口。

2.3 复用产品能力

一些平台希望在产品层面上复用我们核心的生图和训练模块。这两部分的功能除了 api 外,在前端也包含了非常复杂的业务逻辑,重新开发需要不少的人力投入。因此我们需要对这些模块进行组件化重构,让其他平台的前端项目能够直接使用模块组件,实现快速上线,同时支持以下能力:

2.3.1 功能定制

由于各个平台的权限系统、已有功能与 Muse 不同,接入前端模块组件时需要修改一些功能交互,比如在平台本身没有图片库的情况下,生图时无法从图片库选择图片进行操作;图片的分享操作各个平台都希望有不同的处理 等等。对于这些比较聚合,可以统一剥离的功能,模块组件需要支持自定义配置或修改,来适配不同平台的需求。

2.3.2 数据来源区分

部分平台在接入时已经有了自己的生图资源(如模型数据),因此前端需要根据接入方需求展示不同来源的数据。这要求模块组件的页面展示逻辑与接口请求逻辑不耦合,接入平台可以自行选择合适的数据源,模块组件只负责接收数据并展示。

2.3.3 样式调整

模块组件还需要支持主题色的定制以及细节样式的修改,以确保和接入方已有界面保持风格的统一。

三、方案介绍
3.1 整体项目结构
3.1.1 初版架构

随着应用功能的迭代,架构始终围绕着功能迭代在持续更新,第一版架构我们只支持集团内的业务,是一个较为简单的应用架构,如下图。

图片

整体架构分为三个模块:接入层包括前端和 api 调用,请求从接入层打到后端 Java 服务,Java 服务做一些业务处理后,将生图请求转发到 Diffusion Worker(Muse 自研推理引擎) 上,引擎层最终实现推理生图,训练请求的话会提交到集团内训练平台进行模型训练。整体应用涉及到集团内的多个中间件,SchedulerX 用来做轮询,Diamond 作为中心配置服务,Whale 平台提供 LLM 推理服务,Openlm 平台提供模型存储服务。

3.1.2 当前架构

后期我们需要同时支持集团内外的架构设计,最终实现了一套代码库多端部署的结构,如下图:

图片

接入层除了原有的 Muse 前端和 api 接入方式,还需要支持别的系统直接内嵌 Muse 的部分页面(比如 ModelScope AIGC 专区),前端抽取出来了公共组件库,来支持多种接入方式。

后端需要支持集团内外两套服务,建立了统一代码库,一套代码内实现两套应用的支持。不同应用依赖集团内外不同的中间件,下文会有详细实现的介绍。

引擎层集团内仍然用原来的设计,云上环境主要依赖阿里云的 PAI 平台提供推理和训练的环境支持。

3.2 后端架构细节和设计思路

在整个功能迭代过程中,为了满足不同的需要,后端架构的演进整体可以看作三个阶段,集团内应用——集团内外独立部署两套应用——统一代码库支持集团内外应用发布,下面详细介绍架构演进过程中的思考与实现。本小节内容只涉及 java 后端工程架构的演进,不涉及生图引擎的详细结构。

3.2.1 集团内应用

第一阶段,只需要搭建集团内的应用,这一阶段的后端应用较为简单,一个 Spring mvc 结构的后端工程结构,依赖了一些集团内的中间件,此时也没有进行应用分层,所有模块平铺展示,是一个比较基础的 java 后端项目。

架构如下图,抽象了 Executor 层,只用来做提交和处理,Service 层做完业务逻辑后调用 Executor 层的 submit 方法,submit 方法调用第三方平台进行任务提交,比如提交生图请求到 TPP 平台,提交训练请求到 AOP 平台。通过 SchedulerX 进行定时轮询,执行 Executor 的 process 方法进行任务状态的更新和数据的回填。

图片

3.2.2 集团外应用

3.2.2.1 方案选择

第二阶段,需要满足集团内外都提供服务,具体表现形式为,集团内继续以 Muse 平台提供服务,集团外在 ModelScope 建立 AIGC 专区,专区内容包括生图和模型训练。我们最终选择了在阿里云上独立部署一套服务的方案。

选择这种方案主要出于以下几点考量:

  • 核心原因:合作方 ModelScope 是集团外的应用,期望我们能在集团外独立部署,可以更好的长期维护甚至协助我们做维护

  • 数据互通问题:和 ModelScope 的数据放在一起,数据互通会更加高效

  • 集团外所需功能只有核心的生图和训练,前期没有复杂的资产管理和团队管理等其他功能,且集团内应用依赖的中间件较少,均可以在集团外找到替代产品,集团外直接开发一套的成本可以接受

  • 基于淘宝开放平台 TOP 的方式团队成员没有相关经验,不好评估影响范围和开发成本

3.2.2.2 分层架构

在做集团外独立部署时我们也对新的代码仓库做了详细的架构设计,参考了 COLA(Clean Object-Oriented and Layered Architecture)架构的设计原则——“整洁面向对象分层架构”,对我们的项目做了分层。COLA V5 的结构如下图:

图片

在具体实践过程中,这次架构设计的主要目的是分层管理,没有过分去抽象 Domain 层的实现,对我们项目而言,实体较少,主要集中在模型和图片上,用独立的 service 做不同的实现可以满足需要。我们项目的复杂度主要体现在生图链路和训练链路比较长,核心改造点在 App 层,最终项目结构如下,muse-cloud 对应 adapter 层,主要包含 Controller 和 SchedulerX 的入口类,muse-application 对应 app 层,主要包含 service 的实现,muse-infrastructure 层包含 client、repository、config 等底层配置,muse-domain 可以忽略。

内部具体功能的实现,仍和上文第一版架构保持一致。

图片

3.2.2.3 中间件 & 云资源替换

项目分层后,一方面我们需要把核心功能的实现搬到新的代码仓库中,另一方面,要完成云资源和中间件的替换。云资源整体替换为在阿里云上购买云资源,中间件也替换成云上的中间件服务,此时我们并未考虑需要和集团内的代码做兼容,完全是写一个新项目。我们做这件事的逻辑如下:先起一个 demo 应用,完成所有中间件的调用测试和 infrastructure 层的准备,后续工作就只剩下搬运集团内已有的 Controller 和 Service 到新的项目结构中。生图服务是部署在阿里云 PAI 平台的 EAS 上,训练服务部署在 PAI 的 DLC 上,本文不详细介绍,感兴趣的同学可以私下跟我们沟通具体实现。

3.2.2.4 集团外部署

最后是部署流程,部署流程需要在集团内的自动化部署平台 aone 上自定义流水线,核心是要实现将 aone 上构建好的镜像,发布到阿里云 ACK(阿里云容器服务 Kubernetes 版)服务上,链路如下

图片

其中,ACK 部署是自定义节点,需要自行实现。我们的实现逻辑是先在 OSS 上放一份 K8s 的部署模板,也就是 deployment.yaml 文件,同时放一份目标 ACK 的配置文件,配置文件是用来通过公网连接 ACK 集群。流水线的 ACK 部署节点用来执行 shell 脚本,获取【应用构建】节点产出的镜像地址后,从远端 oss 获取对应的模板和配置,连接 ACK 集群后部署镜像。

至此,我们已经实现了通过部署两套应用来支持集团内外的服务。集团外上线后,随着集团内外应用分开迭代,我们遇到了维护效率低和集团内外各项功能差异越来越大的问题,导致部分功能需要集团内外实现两遍。基于此,我们进行了下一阶段的架构设计。

3.2.3 统一集团内外代码库

第三阶段,我们把集团内外两套应用集成进了一套代码库,同时发布集团内外的模式,项目结构如下

图片

整体结构分为三个部分,muse-core 集成了公共实现,muse-ai 代表集团内应用,muse-cloud 代表集团外应用,muse-ai 和 muse-cloud 模块都依赖 muse-core,每个模块仍然采用上文集团外部署的 COLA 分层结构。

muse-core 模块承担了公共功能的实现、公共实体的定义、差异化功能的接口定义,差异化功能的实现落在 muse-ai 和 muse-cloud 中,分层具体来看:

  • adapter 层中的 controller 和 scheduler,核心的生图、训练、模型等功能的出入参结构集团内外完全一样,都放在 muse-core 中,一些特有的逻辑,比如集团内的社区管理,单独放在 muse-ai 的 adapter 层;

  • app 层中的 service 和 executor,如果集团内外的实现逻辑一样,直接在 muse-core 中做实现,差异化的业务实现,在 muse-core 中将 serviceImpl 定义为抽象类,muse-ai 和 muse-cloud 中继承后做不同的实现,通过注解 @Profile("ai") 结合 spring.profiles.active=ai 来加载不同环境的类;

  • config 层包括一些缓存、线程池、中间件和权限校验相关的配置,对于权限校验这样集团内外差异化实现的配置,单独在 muse-ai 和 muse-cloud 中实现不同的 SecurityFilterChain;

  • infra 层包括 repository 及 db 交互的部分,这类公共实现都放在 muse-core 中,infra 层还包括 client 模块,这部分主要是和第三方服务的交互,比如核心的生图和训练,在集团内需要调用 tpp 的接口,集团外需要调用 pai 平台服务的接口,对我们系统来讲是调用 modelscope 提供的接口,两边的接口格式差异很大,因此,抽象出来了 Client 的接口 (生图是 PredictCilent,训练是 TrainClient),只定义提交和查询的接口,参数格式也统一定义,muse-core 和 muse-cloud 实现对应的接口并完成实际参数转换,通过 @Profile 指定加载不同的类实现,Service 具体调用生图或者训练时只需要调用 Cilent 的相关接口即可。

通过合理的分层、通用的接口定义和继承抽象类接口实现,最终实现了一套代码支持两套应用。

3.2.4 SaaS 应用展望

通过对 Muse 集团外应用的大量探索,我们积累了一套基于公有云的 Muse 部署方案。该方案具备一定的可复制性,可以允许新的客户在公有云上部署一套完全相同的产品。在 2024 年云栖大会期间,也的确有客户表达出了希望私有化部署一套 Muse 的诉求。因此展望一下未来,除了支撑集团内外的大量业务场景之外,Muse 也许可以作为一套整合公有云各类 IaaS、PaaS 层产品,可以独立部署的 AI 高阶 SaaS 应用。

3.3 前端架构细节和设计思路
3.3.1 整体思路

考虑到生图和训练模块的功能相对内聚,外部平台在接入时对于界面展示的改动需求也集中在几个固定方面,且未来的功能更新需要多平台同步,因此选择将 Muse 前端项目中的多个页面重构封装为组件,通过 npm 包(muse-ai-components)的形式对外提供服务,便于统一升级维护。

目前 muse-ai-components 的架构如下图所示,该 npm 包为 Muse、ModelScope、ideaLab 三个平台提供服务,图中以 ModelScope 平台为例画出了具体使用方式。

muse-ai-components 内对页面展示逻辑和接口请求逻辑进行了拆分,形成了页面层和默认请求层:

3.3.1.1 页面层

页面层中最核心的部分是页面组件,接入方传递指定的参数就可以展示快速生图、专业生图等页面内容并定制部分功能。页面层中还包含了多个页面组件共同使用的公共前端模块,如快速生图和专业生图均需要的生图结果展示组件、生图参数 & 状态处理逻辑等。

3.3.1.2 默认请求层

当页面层中的内容需要获取数据时,可以通过默认请求层发起接口请求。默认请求层中配置了发起请求的方法(比如 axios 发起或 fetch 发起)、请求 url、请求参数以及对请求结果的处理(报错提示、格式转换)等内容。如果默认请求层不符合接入方的要求,接入方可以通过服务注册模块注册自定义的接口服务,代替默认请求层中的配置。如图中 ModelScope 前端注册服务后,可以实现一部分数据从 ModelScope 后端获取,一部分数据转发到 Muse 云上服务获取。

图片

3.3.2 方案细节

3.3.2.1 页面展示与接口请求解耦

Muse 前端项目中,发起接口请求由一个统一 util 管理,多个页面引入 util 进行使用。在将部分代码重构为 npm 包的过程中,为了确保上线效率,减少代码修改,保留了该 util 文件,透出了一个注册入口,接入方可以使用这个入口注册自定义的请求方法。页面组件需要发送请求时,会向该方法传递请求数据,该方法完成请求后,会将请求结果返回给页面组件,确保界面渲染正常进行。

3.3.2.2 差异化功能实现

不同平台功能的差异化实现主要可以分为以下两种:

页面展示不变,可以通过接口数据抹平

以生图使用的模型为例,模型的类型、来源分类、版本分类、模型列表原本就是通过接口获取的。在 ModelScope 接入后,生图时就可以从 ModelScope 选择模型,同时模型的来源分类也与 Muse 侧不同,没有团队模型的选项。

在设计页面组件时,我们还将一些原本由前端写死的数据调整为了后端接口获取,来适配不同平台的需求,如训练参数表单内容、训练数据集的分类等等。

此外,还有一些由于前后端数据交互过重,内外平台数据源不同导致的功能问题。如从 lora 模型训练任务详情跳转至生图页面时,需要调用接口获取生图参数和模型并回填到页面上,在 ModeScope 侧,该接口中的参数信息需要通过 Muse 云上服务获取,但模型数据需要从 ModelScope 后端获取,两个平台间仅有模型的唯一 key 有互相记录,目前的逻辑无法满足需求。

我们对前后端逻辑重新梳理后进行了调整,调整前后逻辑如下图所示。调整前,前端从后端获取完整的模型信息;调整后,前端仅从后端获取模型的唯一 key,再根据 key 查询模型的信息,在 ModelScope 侧,这一步就可以替换为从 ModelScope 获取数据,实现功能。调整后包括训练任务跳转在内的多个模型数据回填功能均遵循该链路,收拢了原本的多种实现,提升代码复用度。

图片

页面展示需要变化

在页面组件中透出参数做差异化实现。以分享功能为例,页面组件将原始分享按钮所在的区域挖空,支持外部项目传入一个渲染方法,根据图片数据来自定义按钮位置的展示和处理逻辑。

样式调整

页面组件的主题色可由 antd 的 theme 控制,外部前端项目自行定义即可。

具体元素样式的修改,由于原始的页面代码使用了 css module,导致在外部无法通过类名定位,推荐修改 css module 的命名规则,去除随机编码。但受当前 npm 包使用的框架限制,无法更改 css module 规则,因此将所有类名修改为普通字符串来支持需求。

四、多云部署落地实践

架构演进是为了更高效地支撑需求,经过多次迭代,针对前文中罗列的用户需求,我们顺利实现了在不同合作团队的不同场景下应用落地。

4.1 落地案例

第一种是调用 API 进行生图和训练,这部分主要是集团内的业务场景,集团内有多个业务团队会通过 api 批量生成图片。

第二种是直接内嵌我们的前端页面作为产品的一部分,像集团内的部分产品内嵌了 Muse 的快速生图和专业生图页面。

图片

第三种是共建类,我们和 ModelScope 团队进行了深入的产品共建,ModelScope 平台的 AIGC 专区是基于 Muse 实现的生图和训练平台,后端服务部署在阿里云上。

图片

4.2 高效迭代

以上多种落地场景,在新的架构下,前后端都做到了一次代码改动,多套环境部署。新功能迭代时,对于后端而言,相较于前期需要在两个代码仓库分别实现功能,现在只需要在统一代码库做功能实现,在 aone 上分别对两个应用进行发布即可。前端功能更新后,发布 npm 包的新版本,通知接入平台自行升级版本即可。

五、总结

回顾这半年的工作,我们基于业务需求不断进行功能迭代的同时,也在不断优化项目架构。面对集团内外多云部署的场景,前期我们由于时间原因快速上了一版云上环境的应用,并未过多考虑两个环境的功能迭代效率问题,导致产生了很大的技术债,在清理技术债的过程中,我们通过统一代码库来做多云部署,解决了迭代效率的问题,虽然过程坎坷,但未来迭代会很高效。

架构演进是贯穿应用生命周期永恒的话题,没有最好的架构,只有最贴合业务场景的架构。本文将 Muse 平台今年来的架构演进思路详细列出来,希望过程中的一些思考和实现能对大家有帮助,当前架构也并非最优架构,也欢迎大家有更好的意见可以进行私下交流。

会议推荐
免责声明:本内容来自腾讯平台创作者,不代表腾讯新闻或腾讯网的观点和立场。
举报
评论 0文明上网理性发言,请遵守《新闻评论服务协议》
请先登录后发表评论~
查看全部0条评论
首页
刷新
反馈
顶部