MuseAI 是由阿里集團愛橙科技研發的面向阿里內部的 AIGC 創作工作臺，在《顯示卡在偷懶？阿里大模型創作平臺 MuseAI 極速模型切換技術提升 AI 創作效率》一文中，我們有詳細介紹該平臺相關背景資訊。本文以阿里真實使用場景出發，分享 MuseAI 多雲部署架構實踐。
隨著大模型技術從技術變革轉向產業變革，大模型應用也會進一步繁榮，傳統基礎設施技術已經不足以滿足大模型應用的快速發展，整個基礎設施技術和產業鏈正在快速轉型，向大模型基礎設施技術演變。2025 QCon 全球軟體開發大會（北京站）策劃了「面向 AI 的研發基礎設施」專題，將深入分析 AI 基礎設施的關鍵技術，包括機房伺服器和晶片設計、大規模高效能網路技術、分散式模型並行技術、推理架構最佳化、演算法和工程的結合等最佳化技術，以及它們在大規模生產環境中的應用和實踐。如果你有相關案例想要分享，歡迎透過以下連結提交演講申請：https://jsj.top/f/tUOLpz
Muse 平臺在集團內上線後獲得了大量使用者的使用和認可，也和眾多團隊建立了多種生圖、訓練場景的合作與共創。倍感榮幸的同時，發現大家對我們的平臺有更高的期望和更多的需求。
整體梳理下來，大家的需求主要有三個場景：
-
外部環境使用 Muse 生圖能力
-
基於 Muse 平臺的 AI 生成能力二次開發垂類平臺
-
複用 Muse 部分產品能力
我們基於這些需求去調整系統架構，從而系統地支援此類的需求。針對集團內外同時部署的場景，我們設計了 Java 後端統一程式碼庫進行多雲部署；針對二次開發，我們定義了 API 接入規範；針對複用產品能力，我們設計了前端元件化接入來實現高效複用。以上方案都已經在集團內外多個場景實現了落地，本文詳細分析各個方案的架構實現和演進過程。
要實現在外部環境使用，一般有兩種方案：（1）外部直接在阿里雲（公有云）上部署一套後端服務；（2）仍然使用內部的服務，透過集團公共閘道器暴露服務。
第一種方案在外部雲上環境直接部署一套後端服務，這個方案比較直接。集團內的應用必然依賴了很多集團內的中介軟體以及雲資源，如果要在外部部署的話，需要解決兩個問題：
-
內部的中介軟體換成外部的中介軟體；
-
自行實現自動化部署的鏈路。
前者的複雜度主要取決於產品依賴的中介軟體的數量，對於我們系統而言，主要是用了 Diamond，SchedulerX，Redis 和資料庫等，大多可以在雲上環境找到替代產品。後者的話，需要在 Aone 的流水線自行實現釋出部署的功能，我們會在下文介紹詳細邏輯。
第二種方案是基於淘寶開放平臺將內部的介面暴露出來保證雲上環境可呼叫，這個方案的複用程度很高，如果集團內外基本邏輯一致，資料也是共享的情況下，用這種方案算是改造成本較低的選擇。
無論採用哪種方案，都必然會面對一個問題：部分邏輯在不同環境的實現是有差異的。例如，使用者體系的差異，內部透過 BUC 可以獲取到使用者資訊，集團外可能是手機號註冊等別的鏈路；此外，集團內外對於安全管控的要求也不一樣，以及部分業務邏輯的實現也是有差異的。對於這些情況，集團外獨立部署的話，可以直接做不同的實現，更加自由，而透過 TOP 暴露內部介面的方案，就要考慮如何在一套服務裡去做不同的實現了。
對於 API 呼叫主要有兩個訴求：（1）介面化呼叫生圖能力；（2）介面化呼叫訓練能力。兩者都需要一套穩定的鑑權體系和資源隔離邏輯。如果生圖量較小的話可以直接複用我們的資源池，如果生圖量大的話可以選擇閒時呼叫，比如夜間集中呼叫。此外針對訓練任務，我們還支援使用私有資源進行呼叫。
透過 api 呼叫生圖介面主要面臨生圖引數過多的問題，讓業務方去構造複雜的生圖請求非常容易出現請求失敗。我們一方面支援直接傳全量生圖引數的介面，一方面支援先在 Muse 平臺生圖後儲存相關引數為生圖預設，後續根據生圖預設來生圖，並支援替換其中的部分引數。
針對訓練介面，我們除了提供發起訓練任務的功能，也提供圖片裁剪、圖片標註等輔助功能。由於訓練相關的功能鏈路和耗時較長，因此我們也提供了豐富的非同步狀態查詢和管理介面。
一些平臺希望在產品層面上覆用我們核心的生圖和訓練模組。這兩部分的功能除了 api 外，在前端也包含了非常複雜的業務邏輯，重新開發需要不少的人力投入。因此我們需要對這些模組進行元件化重構，讓其他平臺的前端專案能夠直接使用模組元件，實現快速上線，同時支援以下能力：
由於各個平臺的許可權系統、已有功能與 Muse 不同，接入前端模組元件時需要修改一些功能互動，比如在平臺本身沒有圖片庫的情況下，生圖時無法從圖片庫選擇圖片進行操作；圖片的分享操作各個平臺都希望有不同的處理 等等。對於這些比較聚合，可以統一剝離的功能，模組元件需要支援自定義配置或修改，來適配不同平臺的需求。
部分平臺在接入時已經有了自己的生圖資源（如模型資料），因此前端需要根據接入方需求展示不同來源的資料。這要求模組元件的頁面展示邏輯與介面請求邏輯不耦合，接入平臺可以自行選擇合適的資料來源，模組元件只負責接收資料並展示。
模組元件還需要支援主題色的定製以及細節樣式的修改，以確保和接入方已有介面保持風格的統一。
隨著應用功能的迭代，架構始終圍繞著功能迭代在持續更新，第一版架構我們只支援集團內的業務，是一個較為簡單的應用架構，如下圖。
整體架構分為三個模組：接入層包括前端和 api 呼叫，請求從接入層打到後端 Java 服務，Java 服務做一些業務處理後，將生圖請求轉發到 Diffusion Worker(Muse 自研推理引擎) 上，引擎層最終實現推理生圖，訓練請求的話會提交到集團內訓練平臺進行模型訓練。整體應用涉及到集團內的多箇中間件，SchedulerX 用來做輪詢，Diamond 作為中心配置服務，Whale 平臺提供 LLM 推理服務，Openlm 平臺提供模型儲存服務。
後期我們需要同時支援集團內外的架構設計，最終實現了一套程式碼庫多端部署的結構，如下圖：
接入層除了原有的 Muse 前端和 api 接入方式，還需要支援別的系統直接內嵌 Muse 的部分頁面（比如 ModelScope AIGC 專區），前端抽取出來了公共元件庫，來支援多種接入方式。
後端需要支援集團內外兩套服務，建立了統一程式碼庫，一套程式碼內實現兩套應用的支援。不同應用依賴集團內外不同的中介軟體，下文會有詳細實現的介紹。
引擎層集團內仍然用原來的設計，雲上環境主要依賴阿里雲的 PAI 平臺提供推理和訓練的環境支援。
在整個功能迭代過程中，為了滿足不同的需要，後端架構的演進整體可以看作三個階段，集團內應用——集團內外獨立部署兩套應用——統一程式碼庫支援集團內外應用釋出，下面詳細介紹架構演進過程中的思考與實現。本小節內容只涉及 java 後端工程架構的演進，不涉及生圖引擎的詳細結構。
第一階段，只需要搭建集團內的應用，這一階段的後端應用較為簡單，一個 Spring mvc 結構的後端工程結構，依賴了一些集團內的中介軟體，此時也沒有進行應用分層，所有模組平鋪展示，是一個比較基礎的 java 後端專案。
架構如下圖，抽象了 Executor 層，只用來做提交和處理，Service 層做完業務邏輯後呼叫 Executor 層的 submit 方法，submit 方法呼叫第三方平臺進行任務提交，比如提交生圖請求到 TPP 平臺，提交訓練請求到 AOP 平臺。透過 SchedulerX 進行定時輪詢，執行 Executor 的 process 方法進行任務狀態的更新和資料的回填。
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 集群后部署映象。
至此，我們已經實現了透過部署兩套應用來支援集團內外的服務。集團外上線後，隨著集團內外應用分開迭代，我們遇到了維護效率低和集團內外各項功能差異越來越大的問題，導致部分功能需要集團內外實現兩遍。基於此，我們進行了下一階段的架構設計。
第三階段，我們把集團內外兩套應用整合進了一套程式碼庫，同時釋出集團內外的模式，專案結構如下
整體結構分為三個部分，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 的相關介面即可。
透過合理的分層、通用的介面定義和繼承抽象類介面實現，最終實現了一套程式碼支援兩套應用。
透過對 Muse 集團外應用的大量探索，我們積累了一套基於公有云的 Muse 部署方案。該方案具備一定的可複製性，可以允許新的客戶在公有云上部署一套完全相同的產品。在 2024 年雲棲大會期間，也的確有客戶表達出了希望私有化部署一套 Muse 的訴求。因此展望一下未來，除了支撐集團內外的大量業務場景之外，Muse 也許可以作為一套整合公有云各類 IaaS、PaaS 層產品，可以獨立部署的 AI 高階 SaaS 應用。
考慮到生圖和訓練模組的功能相對內聚，外部平臺在接入時對於介面展示的改動需求也集中在幾個固定方面，且未來的功能更新需要多平臺同步，因此選擇將 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.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 規則，因此將所有類名修改為普通字串來支援需求。
架構演進是為了更高效地支撐需求，經過多次迭代，針對前文中羅列的使用者需求，我們順利實現了在不同合作團隊的不同場景下應用落地。
第一種是呼叫 API 進行生圖和訓練，這部分主要是集團內的業務場景，集團內有多個業務團隊會透過 api 批次生成圖片。
第二種是直接內嵌我們的前端頁面作為產品的一部分，像集團內的部分產品內嵌了 Muse 的快速生圖和專業生圖頁面。
第三種是共建類，我們和 ModelScope 團隊進行了深入的產品共建，ModelScope 平臺的 AIGC 專區是基於 Muse 實現的生圖和訓練平臺，後端服務部署在阿里雲上。
以上多種落地場景，在新的架構下，前後端都做到了一次程式碼改動，多套環境部署。新功能迭代時，對於後端而言，相較於前期需要在兩個程式碼倉庫分別實現功能，現在只需要在統一程式碼庫做功能實現，在 aone 上分別對兩個應用進行釋出即可。前端功能更新後，釋出 npm 包的新版本，通知接入平臺自行升級版本即可。
回顧這半年的工作，我們基於業務需求不斷進行功能迭代的同時，也在不斷最佳化專案架構。面對集團內外多雲部署的場景，前期我們由於時間原因快速上了一版雲上環境的應用，並未過多考慮兩個環境的功能迭代效率問題，導致產生了很大的技術債，在清理技術債的過程中，我們透過統一程式碼庫來做多雲部署，解決了迭代效率的問題，雖然過程坎坷，但未來迭代會很高效。
架構演進是貫穿應用生命週期永恆的話題，沒有最好的架構，只有最貼合業務場景的架構。本文將 Muse 平臺今年來的架構演進思路詳細列出來，希望過程中的一些思考和實現能對大家有幫助，當前架構也並非最優架構，也歡迎大家有更好的意見可以進行私下交流。
新年重磅折扣，直擊全年底價，暢享 7 折優惠，掃圖片購票二維碼，限時加贈實用 AI 工具包！