AIGC創新應用的云計算架構設計

沈 上

（北京工商大學，北京 102488）

0 引言

AIGC（Artificial Intelligence Generated Content /AI-Generated Content，人工智能生成內容），一般認為是相對于PCG（專家生成內容）、UCG（用戶生成內容）而提出的商業概念。AIGC有狹義和廣義兩種概念：狹義的AIGC是指利用AI技術自動生成內容的生產方式；廣義的AIGC則是指生成式AI，像人類一樣具備生成創造能力的AI技術，可以基于訓練數據和生成算法模型，自主生成各種形式的內容和數據，包括但不限于文本、圖像、音樂、視頻、3D交互內容等，也可以開啟科學新發現、創造新的價值和意義等[1]，一般在技術上將其稱為生成式AI。

GAN（對抗生成網絡）、CLIP、Transformer、Diffusion Modle、預訓練模型等技術可以被視為生成式AI，常被用于具體的工作領域構建AIGC創新應用，例如，在文本生成領域中，由GPT-3.5構建的ChatGPT項目、Notion.AI項目、微軟NewBing項目；在圖像生成領域中基于CLIP的DALL-E2項目、基于潛在擴散模型（LDM）的Stable Diffusion項目等。

在產業應用領域對于AIGC的要求是基于多模態的，即同一個模型能夠將文本、圖像、視頻、聲音等多種形態的信息作為輸入和輸出，在技術實現上往往將有相近似意義的多模態信息對應到相似的向量空間。

盡管大量研究人員和工程師在為實現通用人工智能開展工作，而從近年來的研究和工程實踐趨勢來看，尚未取得具有實用性的成果。在工程應用上往往采取協同多個專業能力突出的生成式AI構成工作流來實現具體場景的應用。由于這些項目并非針對AI算法、模型進行開發，而是利用現有的生成式AI進行應用開發，所以這類項目往往被稱為AI創新應用。2023年硅谷科技企業孵化器Y Combinator的孵化項目超過40%屬于AI創新應用，其中絕大部分大部分項目屬于工程化應用。

1 關于AIGC創新應用

1.1 有代表性的AIGC項目

在YC投資項目中，有基于文本介紹的常常用于個性化市場營銷領域的生成式AI模型Vellum、使用生成式人工智能為中小型企業制作數字營銷材料的SpeedyBrand，另外也有CorgiAI這類預防金融詐騙的項目。使用大型語言模型，可以幫助大型Shopify商家處理支持請求的Yuma項目，也可以幫助私募股權公司自動完成盡職調查，以便他們能更快地完成交易的AiFlow等新興項目。

目前，對信息技術領域影響巨大的生成式A I Github Copilot X Chat已經通過對話完成代碼編寫、Debug、注釋、安全檢查等能力，可以令編程人員從繁重的編碼工作中解脫出來，把更多時間和精力放在實現編程目標與提高程序執行效率上。

基于Meta MMS、Whisper、Wave2lips等語音和圖像的生成式AI模型，產生了大量服務于互聯網內容創作者的項目（如D-ID和硅語等），代表了數字人AIGC創新應用[2]。

1.2 AIGC創新應用有什么樣的工程特征

一般來說，AIGC創新應用依托開發者對于具體的工作或娛樂領域的深刻認知，簡單利用生成式AI模型對行業或領域的某一個工作環節或工種進行大幅度的效率提升或流程改善。而使用的模型往往是大型企業或研究機構開源的模型或者調用生成式AI服務企業的API（應用程序接口），根據行業特點設計適合的用戶交互界面，并設置按量付費的套餐供客戶選擇。

近一兩年來，AI模型的參數量達到了千億級別，鮮有創新應用自行訓練大模型，往往是基于開源大模型進行精調（Finetune）。在實際項目運行中，自行部署模型的項目，對于算力的需求集中在推理資源上。

AIGC創新應用所提供的服務從技術結構上分析，幾乎都是獨立的事件或者線性的工作流，狀態特性不明顯，對于響應時間相對不敏感。AIGC創新應用的開發團隊初期規模在4～11人左右，甚至有部分具有較高關注度的開源項目初期開發人員只有1～2人。開發人員的工作主要集中在模型精調和用戶界面開發上，一旦出現較大的用戶增長后，優先擴充的崗位為UI工程師、移動應用設計人員和云計算架構師。團隊的核心技術水平較高，但技術管理水平在最初階段通常不足以支撐對20人以上的團隊進行技術管理。

算力在絕大部分情況下處于稀疏調度的狀態，一旦出現高并發狀態，請求集中度非常高。算力需求分布嚴重不均勻，對于算力、存儲和帶寬具有極高的彈性要求。

2 AIGC創新應用的云計算資源需求分析

（1）GPU算力（單位：ms）。作為AIGC項目的核心計算需求，一般用于模型的訓練、精調、推理等方面。作為應用項目，客戶訪問項目提供的服務能力，GPU算力一般被用于推理，一般為Nvidia或AMD提供的企業級GPU，無圖型顯示能力，并且在云計算廠商環節實現了虛擬化，在絕大多數情況下，可以實現整數個核心的調用。一個用戶單一操作對于GPU核心的調用時長介于200 ms～50 s之間。

（2）存儲（單位：GB）。用于存儲模型文件、參數文件、生成內容的輸出文件以及用于生成內容的輸入媒體。存儲體積十分巨大，通常用于AIGC應用服務的文本生成圖像的模型和參數文件體量在數10 GB～1 TB之間。

（3）CPU算力（單位：ms）。一般用于托管Web訪問界面、App的API接口響應、用戶數據庫、用戶認證和安全防護等計算場景。單用戶單一操作對于CPU核心調用時長介于10～100 ms之間，有部分長時間調用能達到2 s，但該類型的操作一般都需要優化。

（4）帶寬（單位：Mbps）。用于用戶與服務端之間數據交換，當使用生成式AI的API調用時，帶寬會用于同AI模型服務商進行交換數據。通常單用戶觸發操作的帶寬最低需求為256 kbps。為保障用戶體驗，單用戶數據傳輸帶寬不得低于8 Mbps。許多項目在部署時會默認選擇100 Mbps共享帶寬，網絡帶寬高峰可能會導致用戶訪問速度下降，體驗變差。而獨享帶寬的成本會高出許多（即使1 Mbps的價格高于100 Mbps的價格），但在網絡高峰時期的表現更加穩定。

（5）內存（單位：MB·s）。根據優化情況不同和部署的服務器軟件不同，倍率系數在3～20倍之間。單用戶非核心應用操作產生的內存消耗，可根據云廠商去除基礎內存消耗之后的經驗數據計算，范圍在700 kB·s～50 MB·s之間。

（6）顯存（單位：GB·s）。主要用于AICG項目的核心業務內存需求，以生成512×512像素圖為例，需要至少160 GB·s的顯存時長。

（7）API Token（單位：Token）。調用AI模型服務商的API實現生成式功能，調用時長不參與計費，通常與生成內容的多少與消耗的Token相關，對話式文本生成的API與對話長度總有關，每一次發送的內容將包含該對話之前的所有內容。

3 實例分析

下面以Stable Diffusion為例說明改進型云計算架構設計。

①為提供系統穩定性，創建一個VPC專用網絡。將實例放入VPC中，并在外圍部署Web應用防火墻和DDoS高防。

②將用戶數據庫從實例中剝離，遷移到RDS服務中，將本地部署的Redis緩存遷移到內存數據中。

③將webUI與Stable-Diffusion分離，把用戶交互服務與API等單獨部署到一個容器服務中或者ECS中。并為ECS創建適應不同情況的彈性策略，為ECS開啟快照服務并將其存儲到對象存儲的桶中。

④將Stable-Diffusion的模型和訓練參數放置到NAS網絡存儲服務中，將用戶生成的結果存放到對象存儲中。

⑤在交付端可以采用彈性IP+API Getway服務為自有App和客戶提供核心能力交付。

該架構優勢：架構設計簡單，減少了系統運維、應用程序服務器運維、數據庫服務器運維等一些列專業運維人員的工作強度和崗位數量，并提供了可靠的初級安全保障。

該架構劣勢：架構實施難度較大，各環節調優參數較多，需要專人專崗管理，否則容易出現管理漏洞。在具有高并發隨機出現的稀疏資源消耗場景下，云資源消耗較多。

4 基于Serverless架構的設計——以功能即服務為核心FaaS

4.1 項目特性分析與設計目標

FaaS實例（13 GB左右的鏡像）的冷啟動時間通常在60 s以內，常見的業務運行時間也不會超過30 s，采用FaaS實例可以有效解決GPU稀疏訪問和突然高并發等問題。

孩子的情感發展與智力發展是相輔相成的，一個孩子的認知能力，需要在母嬰關系中得到發現和引導。即使一個孩子具有超前的智力潛力，那也需要他的母親或者主要養育者去發現。

AIGC創新應用的團隊所掌握的編程語言通常為Python，部分人員能夠運用Javascript進行Web應用開發。盡管大多數用戶交付形式為Web，也不乏大量成功的AIGC創新項目面向開發者交付API。利用EIP（彈性IP）與API Getway提供一套內外通用、包含認證和訪問資源管理能力的API系統非常必要。

項目持續性和擴展性都存在極大變數，所以盡量利用云廠商提供的Serverless類型的服務，比如Mysql Serverless數據、表格存儲、NAS存儲、內存數據庫、對象存儲等服務構建[3]。

設計目標為高彈性、高擴展、低成本、容易實現技術管理。

4.2 架構設計實例分析——以Stable Diffusion為例

函數計算GPU實例提供項目運行容器，網絡存儲服務NAS提供模型存儲，使用彈性IP+API getway提供AIGC能力交付、認證和費用計算。其他安全方面參考上一節的改進型云計算架構設計。具體操作過程如下。

①在函數計算管理界面中，創建Python應用。選擇Stable Diffusion應用，拉起鏡像即可（可以手動選擇開源的原始鏡像）。

②為函數計算提供訪問授權。

③選擇部署函數。

④啟用webUI。

（1）首次生成一張圖所耗費的資源（冷啟動）。

GPU費用：16×(60+5) = 1040 GB-S

CPU費用：8×(60+5) = 520

內存費用：32×(60+5) = 2080 GB-S

其中，60 s冷啟動，5 s生成一張圖。

（2）后續生成一張圖所耗費的資源（熱啟動）。

GPU費用：16×(5) = 80 GB-S

CPU費用：8×5 = 40

內存費用：32×5 = 160 GB-S

其中，5 s秒生成一張圖。

4.3 工程優勢

該架構對于系統設計的要求比傳統云計算架構更高，但對于參與項目開發的人員的DevOps能力要求大為降低，并且給出了最有效的持續優化指標。由于采用函數工作流方式組織不同功能環節，實現了全鏈路解耦，為熱更新、灰度版本發布等開發運維需求提供了成本極低的解決方式[4]。

由于無須關心資源調度問題和性能優化問題，只要單用戶訪問能夠正常，每個實例可承載并發數設置到不影響體驗的狀態后，就無須進行調整，系統會自動根據需要進行擴容。

4.4 功能擴展

如果需要在上述工作流中增加Wave2lip的函數部署，則可以在此基礎上實現生成圖像中的人物開口說話的能力。同樣，在需要調用第三方API時，也只需要增加響應函數并將其部署到工作流中即可。比如調用語音轉文字的功能即可立即為應用添加響應的功能。

但需要注意，工作流中的各函數在非冷啟動狀態下的延時約為10～200 ms，冷啟動時需要加上響應函數的冷啟動時間，要注意非異步任務的工況下，總體拉起時間不要超過16 s。

5 AIGC創新應用的架構決策分析

對應AIGC創新應用的不同階段，可以采用不同的架構形態。比如，在功能驗證階段，僅考慮設計功能在技術上是否具有可行性，開源時是否便于傳播可以考慮基于容器的單一架構部署和分發，因為基于容器進行的驗證只需要適度調整即可完成自定義鏡像的函數計算部署。

在面臨項目商業轉化的早中期，由于核心算力調用極度稀疏且可能出現突發的高并發情況，可以采用基于FaaS的架構設計。這個階段在商業運作上可以持續相當長時間，項目用戶逐漸增多或暴增都不會影響到開發團隊的持續研發，開發團隊可以將精力用到功能完善和更新上。

隨著用戶增加，項目中的核心算力稀疏性問題改善后，可以在FaaS的不同環節進行PaaS、IaaS資源的替換。伴隨著團隊的持續擴大，原有的架構也會逐漸走向適合自身需求的混合架構[2]。

從商業適應性上看，AICG創新應用采用基于FaaS和BaaS（Backend as a Service，后端即服務）結合的Serverless形式，可以有效降低前期技術風險和團隊擴張風險，并且由于FaaS和BaaS的計費特性，能夠計算出用戶的每一個操作所消耗的全部云資源費用，對于財務規劃極其友好，提供了隨收入一個線性增長的支出預期。對于根據用量收費的AIGC項目來說，這樣的技術架構提供了一個可預期的財務模型。

盡管在用戶增長到一定數量時，比如，某項目的GPU資源訪問稀疏性低于20%以后，采用Serverless架構的系統云資源成本已經高出傳統架構了，但由于技術團隊只服務于核心功能和用戶交互，實際成本要結合團隊擴張后的人員成本與管理水平才能計算，然而這部分支出是可以計算，但收益卻無法計算。在沒有出現客戶請求出現多個數量級變化時，不適合貿然進行架構轉換。

關于云計算廠商綁定問題，幾乎所有基于FaaS和BaaS結合的Serverless架構都面臨廠商綁定風險，因為在進行底層調用的時候不可避免地使用不同廠商所提供的底層接口。但由于近年來幾乎主流的云計算廠商都開始提供FaaS函數計算服務和函數工作流服務，使得開源的FaaS中間件也逐步開始成熟，并且主流的云計算廠商也參與到中間件的支持中，使得遷移成本大幅度降低，如果一開始就采取基于Serverless架構的多云部署，則完全不需要此類擔憂，更可以根據各廠商的動態成本實例對于訪問流量進行調整，以實現訪問速度和成本的有效控制。

6 結束語

傳統云計算架構提供了較強的靈活性且具有人力資源成熟的優點，而Serverless架構雖然不能滿足所有場景的需求（實時性AIGC），但包括準實時任務、延時任務、異步任務等時間特性場景下的AIGC創新應用適用性很高，成本收益比提高明顯，并且該類型架構可以在AIGC類項目的大部分產品生命周期中具有綜合優勢。■