沈 上

（北京工商大學(xué)，北京 102488）

0 引言

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

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

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

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

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

1.1 有代表性的AIGC項(xiàng)目

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3 實(shí)例分析

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

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

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

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

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

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

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

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

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

4.1 項(xiàng)目特性分析與設(shè)計(jì)目標(biāo)

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

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

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

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

設(shè)計(jì)目標(biāo)為高彈性、高擴(kuò)展、低成本、容易實(shí)現(xiàn)技術(shù)管理。

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

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

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

②為函數(shù)計(jì)算提供訪(fǎng)問(wèn)授權(quán)。

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

④啟用webUI。

（1）首次生成一張圖所耗費(fèi)的資源（冷啟動(dòng)）。

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

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

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

其中，60 s冷啟動(dòng)，5 s生成一張圖。

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

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

CPU費(fèi)用：8×5 = 40

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

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

4.3 工程優(yōu)勢(shì)

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

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

4.4 功能擴(kuò)展

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

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

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

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

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

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

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

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

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

6 結(jié)束語(yǔ)

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