沈 上

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

0 引言

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

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

在產(chǎn)業(yè)應(yīng)用領(lǐng)域?qū)τ贏IGC的要求是基于多模態(tài)的，即同一個模型能夠?qū)⑽谋尽D像、視頻、聲音等多種形態(tài)的信息作為輸入和輸出，在技術(shù)實現(xiàn)上往往將有相近似意義的多模態(tài)信息對應(yīng)到相似的向量空間。

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

1 關(guān)于AIGC創(chuàng)新應(yīng)用

1.1 有代表性的AIGC項目

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

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

基于Meta MMS、Whisper、Wave2lips等語音和圖像的生成式AI模型，產(chǎn)生了大量服務(wù)于互聯(lián)網(wǎng)內(nèi)容創(chuàng)作者的項目（如D-ID和硅語等），代表了數(shù)字人AIGC創(chuàng)新應(yīng)用[2]。

1.2 AIGC創(chuàng)新應(yīng)用有什么樣的工程特征

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

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

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

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

2 AIGC創(chuàng)新應(yīng)用的云計算資源需求分析

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

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

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

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

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

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

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

3 實例分析

下面以Stable Diffusion為例說明改進型云計算架構(gòu)設(shè)計。

①為提供系統(tǒng)穩(wěn)定性，創(chuàng)建一個VPC專用網(wǎng)絡(luò)。將實例放入VPC中，并在外圍部署Web應(yīng)用防火墻和DDoS高防。

②將用戶數(shù)據(jù)庫從實例中剝離，遷移到RDS服務(wù)中，將本地部署的Redis緩存遷移到內(nèi)存數(shù)據(jù)中。

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

④將Stable-Diffusion的模型和訓練參數(shù)放置到NAS網(wǎng)絡(luò)存儲服務(wù)中，將用戶生成的結(jié)果存放到對象存儲中。

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

該架構(gòu)優(yōu)勢：架構(gòu)設(shè)計簡單，減少了系統(tǒng)運維、應(yīng)用程序服務(wù)器運維、數(shù)據(jù)庫服務(wù)器運維等一些列專業(yè)運維人員的工作強度和崗位數(shù)量，并提供了可靠的初級安全保障。

該架構(gòu)劣勢：架構(gòu)實施難度較大，各環(huán)節(jié)調(diào)優(yōu)參數(shù)較多，需要專人專崗管理，否則容易出現(xiàn)管理漏洞。在具有高并發(fā)隨機出現(xiàn)的稀疏資源消耗場景下，云資源消耗較多。

4 基于Serverless架構(gòu)的設(shè)計——以功能即服務(wù)為核心FaaS

4.1 項目特性分析與設(shè)計目標

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

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

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

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

設(shè)計目標為高彈性、高擴展、低成本、容易實現(xiàn)技術(shù)管理。

4.2 架構(gòu)設(shè)計實例分析——以Stable Diffusion為例

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

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

②為函數(shù)計算提供訪問授權(quán)。

③選擇部署函數(shù)。

④啟用webUI。

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

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

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

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

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

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

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

CPU費用：8×5 = 40

內(nèi)存費用：32×5 = 160 GB-S

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

4.3 工程優(yōu)勢

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

由于無須關(guān)心資源調(diào)度問題和性能優(yōu)化問題，只要單用戶訪問能夠正常，每個實例可承載并發(fā)數(shù)設(shè)置到不影響體驗的狀態(tài)后，就無須進行調(diào)整，系統(tǒng)會自動根據(jù)需要進行擴容。

4.4 功能擴展

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

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

5 AIGC創(chuàng)新應(yīng)用的架構(gòu)決策分析

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

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

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

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

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

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

6 結(jié)束語

傳統(tǒng)云計算架構(gòu)提供了較強的靈活性且具有人力資源成熟的優(yōu)點，而Serverless架構(gòu)雖然不能滿足所有場景的需求（實時性AIGC），但包括準實時任務(wù)、延時任務(wù)、異步任務(wù)等時間特性場景下的AIGC創(chuàng)新應(yīng)用適用性很高，成本收益比提高明顯，并且該類型架構(gòu)可以在AIGC類項目的大部分產(chǎn)品生命周期中具有綜合優(yōu)勢?！?/p>