本文整理自美圖資深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)》，詳細介紹了美圖如何在多云環(huán)境中實施標準化管理和流程，從而更加高效一致地管理多云環(huán)境；深入探討了美圖在大模型訓練過程中遇到安全與合規(guī)問題后，如何通過實施有效策略，確保訓練集群的安全穩(wěn)固。
本文將摘選其中精彩內(nèi)容，統(tǒng)一整理，希望為諸君帶來啟發(fā)。
一、美圖的AIGC之旅
美圖是一家以美為內(nèi)核、以人工智能為驅(qū)動的科技公司，主要包括兩部分業(yè)務：一是影像與設(shè)計產(chǎn)品，如美圖秀秀、美顏相機、wink等；二是美業(yè)解決方案，包括美圖宜膚、美圖魔鏡等。
2017年，美圖曾因“手繪自拍”功能風靡歐美，還推出了全球首款智能繪畫機器人Andy。2022年底，美圖上線AI繪畫服務，并迅速在網(wǎng)絡(luò)走紅，此時美圖也開啟了算力追尋之路。
2023年6月，美圖一口氣發(fā)布以美圖視覺大模型為核心的七款產(chǎn)品，包括AI口播視頻工具開拍、桌面端AI視頻編輯工具WinkStudio、AI數(shù)字人生成工具DreamAvatar等。
在AI智能領(lǐng)域進行一番探索后，美圖總結(jié)出了AIGC的業(yè)務特點：第一，傳播速度很快，留給公司的反應時間很短；第二，數(shù)據(jù)增長迅猛，容易產(chǎn)生爆款，對資源的需求量很大、很急迫；第三，企業(yè)如果想要快速搶占市場獲得競爭優(yōu)勢，就需要在資源交付方面投入更多。
二、多元算力的選擇和應用
美圖AIGC的算力組成主要以GPU為主，包括T4、V100、A10組成推理集群的基礎(chǔ)，A800、A100、H100組成大模型訓練集群的基礎(chǔ)框架。AIGC業(yè)務最火爆的時候，美圖的GPU資源非常緊缺，因此也選擇了部分NPU作為GPU算力的補充。
有了算力之后，我們首先會做一個全面的基準測試，它能夠加速我們對GPU資源差異性的認知，同時也提供了可靠的數(shù)據(jù)幫助算法研發(fā)團隊在算力選擇以及算法優(yōu)化上找到方向。
美圖在面對多元算力的選擇時，遇到了很多挑戰(zhàn)：第一，多元算力的管理和維護工作很復雜；第二，在資源調(diào)度及優(yōu)化方面需要投入更多建設(shè)；第三是兼容性的問題，美圖在適配華為云昇騰這種異構(gòu)算力時，在平臺和算法適配方面投入很大的人力成本；第四，供應鏈方面，GPU廠商提供的高性能算力有限，而且會分散在不同的區(qū)域，這樣就需要在資源管理方面加大投入；第五，采用多云架構(gòu)，需要在故障管理、災備、穩(wěn)定性運行、性能、成本權(quán)衡等方面重點發(fā)力。
三、多云資源交付
美圖在多云資源交付方面也面臨頗多挑戰(zhàn)。
第一是資源方面的需求量巨大，包括計算、存儲、網(wǎng)絡(luò)等方面的資源；第二，隨著項目運營、社區(qū)傳播活動的推進，業(yè)務數(shù)據(jù)可能面臨爆發(fā)式增長，這時就需要具備高效的彈性伸縮能力；第三，對于性能的要求非常高，包括基礎(chǔ)資源GPU以及高性能存儲、網(wǎng)絡(luò)等；第四，交付周期緊張，需要在短時間內(nèi)交付一套或者多套完整可用的生產(chǎn)服務。
面對這一系列挑戰(zhàn)，美圖內(nèi)部制定了一個交付標準，其中包括廠商交付、內(nèi)部交付和持續(xù)協(xié)作能力，確保交付流程的順暢。
廠商交付方面，我們制定了一份名為AIGC項目GPU資源供應商必備資質(zhì)的清單。清單內(nèi)容包括我們在GPU資源、CPU資源、容器、周邊、網(wǎng)絡(luò)、存儲等方面的需求。通過這份清單，可以和廠商同步我們期望的交付內(nèi)容、交付時間以及責任人等具體事項。
內(nèi)部交付方面，我們針對每個GPU廠商制定了一份排期清單，具體內(nèi)容涉及工作細化及人員分工，環(huán)境準備、基礎(chǔ)設(shè)施建設(shè)及資源驗收，還包括業(yè)務部署、業(yè)務測試以及流量引入。
持續(xù)協(xié)作方面，我們和供應商定期舉行會議，同步項目進度以及交付過程中遇到的問題，此外還會根據(jù)非預期性的事件調(diào)整相應計劃。
AIGC時代，算力需求爆發(fā)式增長，緊張的GPU算力資源促進了多云環(huán)境的誕生，而多云架構(gòu)又促使我們在資源交付及使用方面制定一套自己的標準。同時，業(yè)務為了快速搶占市場，同樣也需要按照這套標準快速交付資源。
按照上述流程， 美圖在當時AIGC算力GPU資源最緊張的環(huán)境下，用兩天半的時間對接了三個云廠、十多個region、若干AZ，并向業(yè)務方交付了近萬張GPU卡的資源，最終得到了多云算力。
四、多云管理和穩(wěn)定性運營
擁有多云的算力后，美圖是如何在多云管理和穩(wěn)定性運營方面發(fā)力的呢？
第一，架構(gòu)選型。我們充分利用了云原生，以K8S為底座來構(gòu)建我們的多云生態(tài)。在資源規(guī)格及配比方面，我們會嚴格按照標準去執(zhí)行。總而言之，我們對廠商的云原生成熟度要求是非常高的。
第二，多云納管。美圖內(nèi)部研發(fā)了多云容器管理平臺，實現(xiàn)對多云集群的統(tǒng)一納管。我們的服務只要開啟了多集群部署，就可以把它一鍵部署到當前的多云環(huán)境中。當然，也允許我們的服務進行多集群差異化的配置。
第三，基礎(chǔ)設(shè)施完善。我們建立了統(tǒng)一的模型庫，對元數(shù)據(jù)、模型存儲、權(quán)限、入口、分發(fā)等進行統(tǒng)一。此外，我們還建立了統(tǒng)一的鏡像分發(fā)平臺，業(yè)務鏡像在該平臺上完成配置，這樣就可以定時、增量地分發(fā)到不同云廠商的鏡像倉庫中。
第四，穩(wěn)定性運營建設(shè)。我們在每個節(jié)假日會制定按需重保的工作列表，通過預操作確保節(jié)假日云的穩(wěn)定性；我們還建立了SRE的穩(wěn)定性運營平臺，可以定期生成SRE穩(wěn)定性運營周報、巡檢報告等等，報告包含核心業(yè)務的監(jiān)控、數(shù)據(jù)等。
在穩(wěn)定性運營建設(shè)方面，我還想分享兩點確保成本最優(yōu)的策略：
第一是GPU資源運營。通過建立GPU大盤，從云廠商、區(qū)域、GPU卡類型、計費類型以及卡單價等多個維度給GPU資源確定優(yōu)先級。我們會定期復盤，把一些業(yè)務從低優(yōu)先級的區(qū)域動態(tài)地調(diào)度到高優(yōu)先級區(qū)域，并且會定期清理一些未使用的資源、降低一些低利用率的資源規(guī)格，從而保證成本最優(yōu)。
第二是業(yè)務運營。美圖產(chǎn)品的大部分應用場景都是用戶上傳圖片或視頻后生成對應的效果。我們會結(jié)合這些功能單次生成的成本以及每日服務器的成本，最終確定每日的毛利，然后通過持續(xù)地關(guān)注ROI，保證業(yè)務穩(wěn)定并且成本更優(yōu)。
五、多云流量調(diào)度 & 彈性伸縮
了解美圖在多云管理以及穩(wěn)定性運營方面的挑戰(zhàn)和應對策略后，接下來聊聊多云的流量智能調(diào)度以及彈性伸縮。
美圖有兩個非常典型的算法模型。第一個是同步算法：流量經(jīng)過算法網(wǎng)關(guān)后，會被分發(fā)到不同的云中，在這個場景下，我們統(tǒng)一了算法網(wǎng)關(guān)并做了一些流量分發(fā)的動作；第二個是異步算法：流量經(jīng)過算法網(wǎng)關(guān)后，會把它的任務寫到消息隊列中，在其他云的資源啟動后，我們會讀取消息隊列中的任務，然后通過推理，把結(jié)果通過當?shù)鼐W(wǎng)關(guān)統(tǒng)一上傳，這個場景的特點就是統(tǒng)一隊列以及當?shù)厣蟼鳌?/p>
接下來結(jié)合兩個真實的業(yè)務場景，分享一下美圖在流量調(diào)度以及彈性伸縮方面遇到的痛點以及采取的解決方案。
痛點場景一：當產(chǎn)品過了火爆期后，如何合理地調(diào)度之前囤積的GPU卡呢？針對這個場景，我們首先要做到以下幾點：一是盡量選擇便宜且更合適的卡；二是減少不必要的網(wǎng)絡(luò)開銷，比如網(wǎng)絡(luò)成本、存儲成本等等；三是在保證業(yè)務穩(wěn)定性的前提下做好成本優(yōu)化工作。
對于這個痛點場景，我們采取的第一個最佳實踐方案是針對同步算法做基于5XX的回源策略調(diào)度。
當一個用戶流量經(jīng)過網(wǎng)關(guān)后，它會按照優(yōu)先級依次請求到包月集群、按需集群。當包月集群的資源負載非常高的時候，可能會出現(xiàn)一些5XX的狀態(tài)碼或者一些自定義的狀態(tài)碼。根據(jù)這些狀態(tài)碼，網(wǎng)關(guān)會把這個請求再次分發(fā)到按需集群，也是低優(yōu)先級的集群。這個場景會造成用戶等待時間增加，對業(yè)務是有損的。但這個場景可以大幅優(yōu)化成本，所以我們征得業(yè)務方的同意后，針對不同的算法把它調(diào)度到類似的流量架構(gòu)上。
第二個最佳實踐方案是在異步算法方面做一些工作。我們做了多集群聯(lián)動彈性伸縮，評估了每朵云的性價比。每朵云都有一個彈性伸縮的中控，比如某朵云想擴容，首先會上報中控，接著這個擴容動作會交給優(yōu)先級最高的云，讓它完成擴容。在縮容場景下也一樣，讓低優(yōu)先級的云完成縮容的動作。這個架構(gòu)畫起來比較簡單，但是實現(xiàn)過程非常復雜，因為需要考慮很多邊界場景。
除了以上提到的兩個最佳實踐，我們內(nèi)部還形成一個默認的調(diào)度準則，即基于服務親和性的調(diào)度，主要體現(xiàn)在網(wǎng)絡(luò)和存儲方面。比如某服務依賴A云，我們就盡可能避免將這個服務調(diào)度到B云上，以此減少跨云網(wǎng)絡(luò)傳輸成本。
痛點場景二：我們某個APP突然做了一個運營推廣，但業(yè)務沒有及時擴容，導致最終效果不佳。在這個場景下，我們總結(jié)出以下幾個問題：一是服務彈性不夠及時且速度較慢，主要體現(xiàn)在機器初始化流程非常長、鏡像體積大、模型文件大以及服務冷啟動非常久；二是常規(guī)的彈性伸縮策略無法滿足當前AIGC的業(yè)務場景；三是我們也在思考這種運營推廣類的需求應該如何定制策略，保證推廣能夠順利進行。
針對痛點場景二我們采取以下解決方案：
1、提供多種彈性指標的選擇。我們不僅提供基礎(chǔ)指標，比如CPU、網(wǎng)絡(luò)、內(nèi)存，也提供業(yè)務QPS、隊列MQ的長度指標。同時允許用戶通過自定義的Prometheus指標來滿足特殊的彈性場景。
2、在提升彈性速度方面，把容器的基礎(chǔ)鏡像放入虛機來降低pod的啟動時間。
3、對虛機系統(tǒng)鏡像做預熱。當前的K8S集群可能會納管多個可用區(qū)的節(jié)點，我們會把這個系統(tǒng)鏡像在這些可用區(qū)提前預熱，減少機器初始化時間。
4、我們會做一些親和性的配置，比如我們的服務都會配置一個優(yōu)先包月的策略，這個場景下一個包月機器有兩個重要特點：一是包月機器沒有購買初始化的流程，第二是包月機器在一些容器鏡像上面會有一定的預熱。
在冷啟動和多模型方面，我們制定了運行時動態(tài)模型加載的方案。比如一個AIGC請求進入Server后，會攜帶不同AIGC的請求參數(shù)，算法處理服務在啟動時會默認加載五個模型到內(nèi)存中，然后它會根據(jù)請求參數(shù)的不同進行動態(tài)切換，把某一個模型切為我們的主模型進行推理。在這個場景下，有這樣幾個特點：
1、模型是天然預熱的，而且能夠?qū)崿F(xiàn)動態(tài)切換。
2、我們會根據(jù)大盤中模型的使用頻率，動態(tài)地將當前一些算法服務中的模型切為主模型進行推理。
3、針對小流量業(yè)務，采用小業(yè)務的混合部署來提升整體的利用率，比如將五個業(yè)務所依賴的模型都加載到一個pod里面，通過動態(tài)參數(shù)來切換處理能力。
4、 在應對運營推廣帶來突發(fā)流量的場景下，我們做了基于運營事件的彈性伸縮。美圖內(nèi)部也有一套統(tǒng)一推送平臺，有運營推廣的時候它會發(fā)送包含以下內(nèi)容的信息：推廣app、推廣服務對象以及預估量。我們會根據(jù)這些信息預估針這個服務所需要擴容的數(shù)量，從而提前完成擴容動作，確保運營推廣能夠順利進行。
六、大模型安全和成本建設(shè)
最后分享一下美圖在大模型方面的安全和成本建設(shè)。
從SRE的角度看，我們在大模型方面遇到兩個比較大的痛點。第一，安全方面，我們擔心模型、用戶數(shù)據(jù)、訓練數(shù)據(jù)被泄露；第二，成本方面，大模型訓練集群的成本非常昂貴，我們也始終致力于將算力榨干；此外大模型訓練的上手成本非常高，所以我們也努力建設(shè)一部分應用工具來簡化這個流程。
在安全方面，我們給出以下解決方案。
首先在隔離策略方面，我們完成了環(huán)境隔離，集群是按照大團隊的維度授權(quán)的；在數(shù)據(jù)隔離層面，訓練數(shù)據(jù)、模型和產(chǎn)物存儲在不同的介質(zhì)上來做區(qū)分；在網(wǎng)絡(luò)隔離層面，我們直接掐掉集群的公網(wǎng)，一些依賴配置都是由平臺提前配置好的；在權(quán)限層面，我們講究所見即所得，細化到資源讀寫層面；在流程把控方面，比如基礎(chǔ)權(quán)限下發(fā)、資源申請、資源刪除都需要走OA審批。
其次在數(shù)據(jù)加密層面，我們做了鏡像加密、模型加密，另外在運行時加密方面，我們也在努力尋找更合適的方案；我們還要求平臺都增加必要的日志審計功能，所有資源開通、刪除以及權(quán)限變更都要有記錄；最后我們也會根據(jù)一些特定的場景增加一些必要的錄屏功能。
接下來分享一下成本問題的解決方案：
1、監(jiān)控告警、巡檢建設(shè)：如果發(fā)現(xiàn)當前GPU空載率比較高，我們會判斷是否出現(xiàn)訓練任務中斷等情況。
我們也會進行一些異常監(jiān)控，比如GPU卡異常、掉卡監(jiān)控以及一些常見的ECC錯誤監(jiān)控；通過巡檢報告，確保不遺漏集群任何時間點的運行狀況；另外，除了資源層面，我們也做了涉及大模型訓練資源所依賴的網(wǎng)絡(luò)、存儲等方面的告警，保證不丟失任何一個異常點。
2、在易用工具建設(shè)方面，我們內(nèi)部開發(fā)了Piczoo平臺，這個平臺主要在算力資源管理、權(quán)限管理以及一些環(huán)境初始化做更多的建設(shè)和努力。
我們也二次開發(fā)了一個大模型任務提交工具，算法研發(fā)同學通過這個工具可以很輕松地把訓練任務提交到大模型訓練集群中，利用這個工具也可以快速查看任務狀態(tài)以及任務運行日志等。
3、嚴格的項目流程控制。當前大模型訓練資源非常緊缺，但是美圖有很多項目都需要使用這樣的資源，那么就會出現(xiàn)一些項目排隊的情況。我們會通過一些嚴格的項目流程控制，來保證這些項目之間無縫地使用GPU資源，以此減少大模型集群的空跑期。
總之我們所做的所有降本增效的工作，都是為了讓企業(yè)獲得更大的競爭優(yōu)勢。
