本文整理自美圖資深SRE工程師李彬在【W(wǎng)OT2023·深圳站】大會上的主題分享，更多精彩內(nèi)容及現(xiàn)場PPT，請關(guān)注51CTO技術(shù)棧公眾號，發(fā)消息【W(wǎng)OT2023PPT深圳】即可直接領(lǐng)取。

嘉賓 | 李彬

編輯 | 如煙

出品 | 51CTO技術(shù)棧（微信號：blog51cto）

日前，在51CTO主辦的WOT全球技術(shù)創(chuàng)新大會上，美圖資深SRE工程師李彬帶來了主題演講《美圖：AIGC運維之旅的探索和挑戰(zhàn)》，詳細(xì)介紹了美圖如何在多云環(huán)境中實施標(biāo)準(zhǔn)化管理和流程，從而更加高效一致地管理多云環(huán)境；深入探討了美圖在大模型訓(xùn)練過程中遇到安全與合規(guī)問題后，如何通過實施有效策略，確保訓(xùn)練集群的安全穩(wěn)固。

本文將摘選其中精彩內(nèi)容，統(tǒng)一整理，希望為諸君帶來啟發(fā)。

一、美圖的AIGC之旅

美圖是一家以美為內(nèi)核、以人工智能為驅(qū)動的科技公司，主要包括兩部分業(yè)務(wù)：一是影像與設(shè)計產(chǎn)品，如美圖秀秀、美顏相機、wink等；二是美業(yè)解決方案，包括美圖宜膚、美圖魔鏡等。

2017年，美圖曾因“手繪自拍”功能風(fēng)靡歐美，還推出了全球首款智能繪畫機器人Andy。2022年底，美圖上線AI繪畫服務(wù)，并迅速在網(wǎng)絡(luò)走紅，此時美圖也開啟了算力追尋之路。

2023年6月，美圖一口氣發(fā)布以美圖視覺大模型為核心的七款產(chǎn)品，包括AI口播視頻工具開拍、桌面端AI視頻編輯工具WinkStudio、AI數(shù)字人生成工具DreamAvatar等。

在AI智能領(lǐng)域進行一番探索后，美圖總結(jié)出了AIGC的業(yè)務(wù)特點：第一，傳播速度很快，留給公司的反應(yīng)時間很短；第二，數(shù)據(jù)增長迅猛，容易產(chǎn)生爆款，對資源的需求量很大、很急迫；第三，企業(yè)如果想要快速搶占市場獲得競爭優(yōu)勢，就需要在資源交付方面投入更多。

二、多元算力的選擇和應(yīng)用

美圖AIGC的算力組成主要以GPU為主，包括T4、V100、A10組成推理集群的基礎(chǔ)，A800、A100、H100組成大模型訓(xùn)練集群的基礎(chǔ)框架。AIGC業(yè)務(wù)最火爆的時候，美圖的GPU資源非常緊缺，因此也選擇了部分NPU作為GPU算力的補充。

有了算力之后，我們首先會做一個全面的基準(zhǔn)測試，它能夠加速我們對GPU資源差異性的認(rèn)知，同時也提供了可靠的數(shù)據(jù)幫助算法研發(fā)團隊在算力選擇以及算法優(yōu)化上找到方向。

美圖在面對多元算力的選擇時，遇到了很多挑戰(zhàn)：第一，多元算力的管理和維護工作很復(fù)雜；第二，在資源調(diào)度及優(yōu)化方面需要投入更多建設(shè)；第三是兼容性的問題，美圖在適配華為云昇騰這種異構(gòu)算力時，在平臺和算法適配方面投入很大的人力成本；第四，供應(yīng)鏈方面，GPU廠商提供的高性能算力有限，而且會分散在不同的區(qū)域，這樣就需要在資源管理方面加大投入；第五，采用多云架構(gòu)，需要在故障管理、災(zāi)備、穩(wěn)定性運行、性能、成本權(quán)衡等方面重點發(fā)力。

三、多云資源交付

美圖在多云資源交付方面也面臨頗多挑戰(zhàn)。

第一是資源方面的需求量巨大，包括計算、存儲、網(wǎng)絡(luò)等方面的資源；第二，隨著項目運營、社區(qū)傳播活動的推進，業(yè)務(wù)數(shù)據(jù)可能面臨爆發(fā)式增長，這時就需要具備高效的彈性伸縮能力；第三，對于性能的要求非常高，包括基礎(chǔ)資源GPU以及高性能存儲、網(wǎng)絡(luò)等；第四，交付周期緊張，需要在短時間內(nèi)交付一套或者多套完整可用的生產(chǎn)服務(wù)。

面對這一系列挑戰(zhàn)，美圖內(nèi)部制定了一個交付標(biāo)準(zhǔn)，其中包括廠商交付、內(nèi)部交付和持續(xù)協(xié)作能力，確保交付流程的順暢。

廠商交付方面，我們制定了一份名為AIGC項目GPU資源供應(yīng)商必備資質(zhì)的清單。清單內(nèi)容包括我們在GPU資源、CPU資源、容器、周邊、網(wǎng)絡(luò)、存儲等方面的需求。通過這份清單，可以和廠商同步我們期望的交付內(nèi)容、交付時間以及責(zé)任人等具體事項。

內(nèi)部交付方面，我們針對每個GPU廠商制定了一份排期清單，具體內(nèi)容涉及工作細(xì)化及人員分工，環(huán)境準(zhǔn)備、基礎(chǔ)設(shè)施建設(shè)及資源驗收，還包括業(yè)務(wù)部署、業(yè)務(wù)測試以及流量引入。

持續(xù)協(xié)作方面，我們和供應(yīng)商定期舉行會議，同步項目進度以及交付過程中遇到的問題，此外還會根據(jù)非預(yù)期性的事件調(diào)整相應(yīng)計劃。

AIGC時代，算力需求爆發(fā)式增長，緊張的GPU算力資源促進了多云環(huán)境的誕生，而多云架構(gòu)又促使我們在資源交付及使用方面制定一套自己的標(biāo)準(zhǔn)。同時，業(yè)務(wù)為了快速搶占市場，同樣也需要按照這套標(biāo)準(zhǔn)快速交付資源。

按照上述流程， 美圖在當(dāng)時AIGC算力GPU資源最緊張的環(huán)境下，用兩天半的時間對接了三個云廠、十多個region、若干AZ，并向業(yè)務(wù)方交付了近萬張GPU卡的資源，最終得到了多云算力。

四、多云管理和穩(wěn)定性運營

擁有多云的算力后，美圖是如何在多云管理和穩(wěn)定性運營方面發(fā)力的呢？

第一，架構(gòu)選型。我們充分利用了云原生，以K8S為底座來構(gòu)建我們的多云生態(tài)。在資源規(guī)格及配比方面，我們會嚴(yán)格按照標(biāo)準(zhǔn)去執(zhí)行?？偠灾?，我們對廠商的云原生成熟度要求是非常高的。

第二，多云納管。美圖內(nèi)部研發(fā)了多云容器管理平臺，實現(xiàn)對多云集群的統(tǒng)一納管。我們的服務(wù)只要開啟了多集群部署，就可以把它一鍵部署到當(dāng)前的多云環(huán)境中。當(dāng)然，也允許我們的服務(wù)進行多集群差異化的配置。

第三，基礎(chǔ)設(shè)施完善。我們建立了統(tǒng)一的模型庫，對元數(shù)據(jù)、模型存儲、權(quán)限、入口、分發(fā)等進行統(tǒng)一。此外，我們還建立了統(tǒng)一的鏡像分發(fā)平臺，業(yè)務(wù)鏡像在該平臺上完成配置，這樣就可以定時、增量地分發(fā)到不同云廠商的鏡像倉庫中。

第四，穩(wěn)定性運營建設(shè)。我們在每個節(jié)假日會制定按需重保的工作列表，通過預(yù)操作確保節(jié)假日云的穩(wěn)定性；我們還建立了SRE的穩(wěn)定性運營平臺，可以定期生成SRE穩(wěn)定性運營周報、巡檢報告等等，報告包含核心業(yè)務(wù)的監(jiān)控、數(shù)據(jù)等。

在穩(wěn)定性運營建設(shè)方面，我還想分享兩點確保成本最優(yōu)的策略：

第一是GPU資源運營。通過建立GPU大盤，從云廠商、區(qū)域、GPU卡類型、計費類型以及卡單價等多個維度給GPU資源確定優(yōu)先級。我們會定期復(fù)盤，把一些業(yè)務(wù)從低優(yōu)先級的區(qū)域動態(tài)地調(diào)度到高優(yōu)先級區(qū)域，并且會定期清理一些未使用的資源、降低一些低利用率的資源規(guī)格，從而保證成本最優(yōu)。

第二是業(yè)務(wù)運營。美圖產(chǎn)品的大部分應(yīng)用場景都是用戶上傳圖片或視頻后生成對應(yīng)的效果。我們會結(jié)合這些功能單次生成的成本以及每日服務(wù)器的成本，最終確定每日的毛利，然后通過持續(xù)地關(guān)注ROI，保證業(yè)務(wù)穩(wěn)定并且成本更優(yōu)。

五、多云流量調(diào)度 & 彈性伸縮

了解美圖在多云管理以及穩(wěn)定性運營方面的挑戰(zhàn)和應(yīng)對策略后，接下來聊聊多云的流量智能調(diào)度以及彈性伸縮。

美圖有兩個非常典型的算法模型。第一個是同步算法：流量經(jīng)過算法網(wǎng)關(guān)后，會被分發(fā)到不同的云中，在這個場景下，我們統(tǒng)一了算法網(wǎng)關(guān)并做了一些流量分發(fā)的動作；第二個是異步算法：流量經(jīng)過算法網(wǎng)關(guān)后，會把它的任務(wù)寫到消息隊列中，在其他云的資源啟動后，我們會讀取消息隊列中的任務(wù)，然后通過推理，把結(jié)果通過當(dāng)?shù)鼐W(wǎng)關(guān)統(tǒng)一上傳，這個場景的特點就是統(tǒng)一隊列以及當(dāng)?shù)厣蟼鳌?/p>

接下來結(jié)合兩個真實的業(yè)務(wù)場景，分享一下美圖在流量調(diào)度以及彈性伸縮方面遇到的痛點以及采取的解決方案。

痛點場景一：當(dāng)產(chǎn)品過了火爆期后，如何合理地調(diào)度之前囤積的GPU卡呢？針對這個場景，我們首先要做到以下幾點：一是盡量選擇便宜且更合適的卡；二是減少不必要的網(wǎng)絡(luò)開銷，比如網(wǎng)絡(luò)成本、存儲成本等等；三是在保證業(yè)務(wù)穩(wěn)定性的前提下做好成本優(yōu)化工作。

對于這個痛點場景，我們采取的第一個最佳實踐方案是針對同步算法做基于5XX的回源策略調(diào)度。

當(dāng)一個用戶流量經(jīng)過網(wǎng)關(guān)后，它會按照優(yōu)先級依次請求到包月集群、按需集群。當(dāng)包月集群的資源負(fù)載非常高的時候，可能會出現(xiàn)一些5XX的狀態(tài)碼或者一些自定義的狀態(tài)碼。根據(jù)這些狀態(tài)碼，網(wǎng)關(guān)會把這個請求再次分發(fā)到按需集群，也是低優(yōu)先級的集群。這個場景會造成用戶等待時間增加，對業(yè)務(wù)是有損的。但這個場景可以大幅優(yōu)化成本，所以我們征得業(yè)務(wù)方的同意后，針對不同的算法把它調(diào)度到類似的流量架構(gòu)上。

第二個最佳實踐方案是在異步算法方面做一些工作。我們做了多集群聯(lián)動彈性伸縮，評估了每朵云的性價比。每朵云都有一個彈性伸縮的中控，比如某朵云想擴容，首先會上報中控，接著這個擴容動作會交給優(yōu)先級最高的云，讓它完成擴容。在縮容場景下也一樣，讓低優(yōu)先級的云完成縮容的動作。這個架構(gòu)畫起來比較簡單，但是實現(xiàn)過程非常復(fù)雜，因為需要考慮很多邊界場景。

除了以上提到的兩個最佳實踐，我們內(nèi)部還形成一個默認(rèn)的調(diào)度準(zhǔn)則，即基于服務(wù)親和性的調(diào)度，主要體現(xiàn)在網(wǎng)絡(luò)和存儲方面。比如某服務(wù)依賴A云，我們就盡可能避免將這個服務(wù)調(diào)度到B云上，以此減少跨云網(wǎng)絡(luò)傳輸成本。

痛點場景二：我們某個APP突然做了一個運營推廣，但業(yè)務(wù)沒有及時擴容，導(dǎo)致最終效果不佳。在這個場景下，我們總結(jié)出以下幾個問題：一是服務(wù)彈性不夠及時且速度較慢，主要體現(xiàn)在機器初始化流程非常長、鏡像體積大、模型文件大以及服務(wù)冷啟動非常久；二是常規(guī)的彈性伸縮策略無法滿足當(dāng)前AIGC的業(yè)務(wù)場景；三是我們也在思考這種運營推廣類的需求應(yīng)該如何定制策略，保證推廣能夠順利進行。

針對痛點場景二我們采取以下解決方案：

1、提供多種彈性指標(biāo)的選擇。我們不僅提供基礎(chǔ)指標(biāo)，比如CPU、網(wǎng)絡(luò)、內(nèi)存，也提供業(yè)務(wù)QPS、隊列MQ的長度指標(biāo)。同時允許用戶通過自定義的Prometheus指標(biāo)來滿足特殊的彈性場景。

2、在提升彈性速度方面，把容器的基礎(chǔ)鏡像放入虛機來降低pod的啟動時間。

3、對虛機系統(tǒng)鏡像做預(yù)熱。當(dāng)前的K8S集群可能會納管多個可用區(qū)的節(jié)點，我們會把這個系統(tǒng)鏡像在這些可用區(qū)提前預(yù)熱，減少機器初始化時間。

4、我們會做一些親和性的配置，比如我們的服務(wù)都會配置一個優(yōu)先包月的策略，這個場景下一個包月機器有兩個重要特點：一是包月機器沒有購買初始化的流程，第二是包月機器在一些容器鏡像上面會有一定的預(yù)熱。

在冷啟動和多模型方面，我們制定了運行時動態(tài)模型加載的方案。比如一個AIGC請求進入Server后，會攜帶不同AIGC的請求參數(shù)，算法處理服務(wù)在啟動時會默認(rèn)加載五個模型到內(nèi)存中，然后它會根據(jù)請求參數(shù)的不同進行動態(tài)切換，把某一個模型切為我們的主模型進行推理。在這個場景下，有這樣幾個特點：

1、模型是天然預(yù)熱的，而且能夠?qū)崿F(xiàn)動態(tài)切換。

2、我們會根據(jù)大盤中模型的使用頻率，動態(tài)地將當(dāng)前一些算法服務(wù)中的模型切為主模型進行推理。

3、針對小流量業(yè)務(wù)，采用小業(yè)務(wù)的混合部署來提升整體的利用率，比如將五個業(yè)務(wù)所依賴的模型都加載到一個pod里面，通過動態(tài)參數(shù)來切換處理能力。

4、 在應(yīng)對運營推廣帶來突發(fā)流量的場景下，我們做了基于運營事件的彈性伸縮。美圖內(nèi)部也有一套統(tǒng)一推送平臺，有運營推廣的時候它會發(fā)送包含以下內(nèi)容的信息：推廣app、推廣服務(wù)對象以及預(yù)估量。我們會根據(jù)這些信息預(yù)估針這個服務(wù)所需要擴容的數(shù)量，從而提前完成擴容動作，確保運營推廣能夠順利進行。

六、大模型安全和成本建設(shè)

最后分享一下美圖在大模型方面的安全和成本建設(shè)。

從SRE的角度看，我們在大模型方面遇到兩個比較大的痛點。第一，安全方面，我們擔(dān)心模型、用戶數(shù)據(jù)、訓(xùn)練數(shù)據(jù)被泄露；第二，成本方面，大模型訓(xùn)練集群的成本非常昂貴，我們也始終致力于將算力榨干；此外大模型訓(xùn)練的上手成本非常高，所以我們也努力建設(shè)一部分應(yīng)用工具來簡化這個流程。

在安全方面，我們給出以下解決方案。

首先在隔離策略方面，我們完成了環(huán)境隔離，集群是按照大團隊的維度授權(quán)的；在數(shù)據(jù)隔離層面，訓(xùn)練數(shù)據(jù)、模型和產(chǎn)物存儲在不同的介質(zhì)上來做區(qū)分；在網(wǎng)絡(luò)隔離層面，我們直接掐掉集群的公網(wǎng)，一些依賴配置都是由平臺提前配置好的；在權(quán)限層面，我們講究所見即所得，細(xì)化到資源讀寫層面；在流程把控方面，比如基礎(chǔ)權(quán)限下發(fā)、資源申請、資源刪除都需要走OA審批。

其次在數(shù)據(jù)加密層面，我們做了鏡像加密、模型加密，另外在運行時加密方面，我們也在努力尋找更合適的方案；我們還要求平臺都增加必要的日志審計功能，所有資源開通、刪除以及權(quán)限變更都要有記錄；最后我們也會根據(jù)一些特定的場景增加一些必要的錄屏功能。

接下來分享一下成本問題的解決方案：

1、監(jiān)控告警、巡檢建設(shè)：如果發(fā)現(xiàn)當(dāng)前GPU空載率比較高，我們會判斷是否出現(xiàn)訓(xùn)練任務(wù)中斷等情況。

我們也會進行一些異常監(jiān)控，比如GPU卡異常、掉卡監(jiān)控以及一些常見的ECC錯誤監(jiān)控；通過巡檢報告，確保不遺漏集群任何時間點的運行狀況；另外，除了資源層面，我們也做了涉及大模型訓(xùn)練資源所依賴的網(wǎng)絡(luò)、存儲等方面的告警，保證不丟失任何一個異常點。

2、在易用工具建設(shè)方面，我們內(nèi)部開發(fā)了Piczoo平臺，這個平臺主要在算力資源管理、權(quán)限管理以及一些環(huán)境初始化做更多的建設(shè)和努力。

我們也二次開發(fā)了一個大模型任務(wù)提交工具，算法研發(fā)同學(xué)通過這個工具可以很輕松地把訓(xùn)練任務(wù)提交到大模型訓(xùn)練集群中，利用這個工具也可以快速查看任務(wù)狀態(tài)以及任務(wù)運行日志等。

3、嚴(yán)格的項目流程控制。當(dāng)前大模型訓(xùn)練資源非常緊缺，但是美圖有很多項目都需要使用這樣的資源，那么就會出現(xiàn)一些項目排隊的情況。我們會通過一些嚴(yán)格的項目流程控制，來保證這些項目之間無縫地使用GPU資源，以此減少大模型集群的空跑期。

總之我們所做的所有降本增效的工作，都是為了讓企業(yè)獲得更大的競爭優(yōu)勢。