本文整理自美圖資深SRE工程師李彬在【WOT2023·深圳站】大會上的主題分享，更多精彩內容及現場PPT，請關注51CTO技術棧公眾號，發消息【WOT2023PPT深圳】即可直接領取。

嘉賓 | 李彬

編輯 | 如煙

出品 | 51CTO技術棧（微信號：blog51cto）

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

本文將摘選其中精彩內容，統一整理，希望為諸君帶來啟發。

一、美圖的AIGC之旅

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

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

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

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

二、多元算力的選擇和應用

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

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

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

三、多云資源交付

美圖在多云資源交付方面也面臨頗多挑戰。

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

面對這一系列挑戰，美圖內部制定了一個交付標準，其中包括廠商交付、內部交付和持續協作能力，確保交付流程的順暢。

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

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

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

AIGC時代，算力需求爆發式增長，緊張的GPU算力資源促進了多云環境的誕生，而多云架構又促使我們在資源交付及使用方面制定一套自己的標準。同時，業務為了快速搶占市場，同樣也需要按照這套標準快速交付資源。

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

四、多云管理和穩定性運營

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

第一，架構選型。我們充分利用了云原生，以K8S為底座來構建我們的多云生態。在資源規格及配比方面，我們會嚴格按照標準去執行。總而言之，我們對廠商的云原生成熟度要求是非常高的。

第二，多云納管。美圖內部研發了多云容器管理平臺，實現對多云集群的統一納管。我們的服務只要開啟了多集群部署，就可以把它一鍵部署到當前的多云環境中。當然，也允許我們的服務進行多集群差異化的配置。

第三，基礎設施完善。我們建立了統一的模型庫，對元數據、模型存儲、權限、入口、分發等進行統一。此外，我們還建立了統一的鏡像分發平臺，業務鏡像在該平臺上完成配置，這樣就可以定時、增量地分發到不同云廠商的鏡像倉庫中。

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

在穩定性運營建設方面，我還想分享兩點確保成本最優的策略：

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

第二是業務運營。美圖產品的大部分應用場景都是用戶上傳圖片或視頻后生成對應的效果。我們會結合這些功能單次生成的成本以及每日服務器的成本，最終確定每日的毛利，然后通過持續地關注ROI，保證業務穩定并且成本更優。

五、多云流量調度 & 彈性伸縮

了解美圖在多云管理以及穩定性運營方面的挑戰和應對策略后，接下來聊聊多云的流量智能調度以及彈性伸縮。

美圖有兩個非常典型的算法模型。第一個是同步算法：流量經過算法網關后，會被分發到不同的云中，在這個場景下，我們統一了算法網關并做了一些流量分發的動作；第二個是異步算法：流量經過算法網關后，會把它的任務寫到消息隊列中，在其他云的資源啟動后，我們會讀取消息隊列中的任務，然后通過推理，把結果通過當地網關統一上傳，這個場景的特點就是統一隊列以及當地上傳。

接下來結合兩個真實的業務場景，分享一下美圖在流量調度以及彈性伸縮方面遇到的痛點以及采取的解決方案。

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

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

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

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

除了以上提到的兩個最佳實踐，我們內部還形成一個默認的調度準則，即基于服務親和性的調度，主要體現在網絡和存儲方面。比如某服務依賴A云，我們就盡可能避免將這個服務調度到B云上，以此減少跨云網絡傳輸成本。

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

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

1、提供多種彈性指標的選擇。我們不僅提供基礎指標，比如CPU、網絡、內存，也提供業務QPS、隊列MQ的長度指標。同時允許用戶通過自定義的Prometheus指標來滿足特殊的彈性場景。

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

3、對虛機系統鏡像做預熱。當前的K8S集群可能會納管多個可用區的節點，我們會把這個系統鏡像在這些可用區提前預熱，減少機器初始化時間。

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

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

1、模型是天然預熱的，而且能夠實現動態切換。

2、我們會根據大盤中模型的使用頻率，動態地將當前一些算法服務中的模型切為主模型進行推理。

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

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

六、大模型安全和成本建設

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

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

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

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

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

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

1、監控告警、巡檢建設：如果發現當前GPU空載率比較高，我們會判斷是否出現訓練任務中斷等情況。

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

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

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

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

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