云原生人工智能白皮書

云人工智能(CNAI)簡介在我們進(jìn)入CNAI之前，將CloudNative和AI技術(shù)結(jié)合在一起，讓我們簡要地研究一下每種技術(shù)的演變。云原生的出現(xiàn)自2013年以來廣為人知，5隨著容器技術(shù)從LXC6到Docer7再到Kberetes（K8s）的興起，ClodNative（CN）一詞越來越受歡迎8如今，ClodNative更廣泛地成為使用微服務(wù)設(shè)計(jì)模式構(gòu)建的平衡系統(tǒng)的理想目標(biāo)，該模式可促進(jìn)模塊化設(shè)計(jì)和開發(fā)，具有高度的可重用性。這也有助于部署性、可擴(kuò)展性和彈性。云原生計(jì)算基金會(huì)定義云原生計(jì)算基金會(huì)定義9云原生為：CloudNative技術(shù)使組織能夠在現(xiàn)代動(dòng)態(tài)環(huán)境（如公共云、私有云和混合云）中構(gòu)建和運(yùn)行可擴(kuò)展的應(yīng)用程序。容器、服務(wù)網(wǎng)格、微服務(wù)、不可變基礎(chǔ)設(shè)施和聲明性API就是這種方法的例證。這些技術(shù)使松散耦合的系統(tǒng)具有彈性，可管理和可觀察性。結(jié)合強(qiáng)大的自動(dòng)化，它們使工程師能夠以最少的工作量頻繁且可預(yù)測地進(jìn)行高影響的更改。云原生計(jì)算基金會(huì)尋求通過培育和維持一個(gè)開源、供應(yīng)商中立的項(xiàng)目生態(tài)系統(tǒng)來推動(dòng)這一范例的采用。我們將最先進(jìn)的模式民主化，使每個(gè)人都能獲得這些創(chuàng)新。云原生人工智能是云原生的一個(gè)不斷發(fā)展的擴(kuò)展。CloudNativeArtificialIntelligence(CNAI)是指使用CloudNative原理構(gòu)建和部署AI應(yīng)用程序和工作負(fù)載的方法和模式。啟用可重復(fù)且可擴(kuò)展的AI工作流，可讓AI從業(yè)者專注于自己的領(lǐng)域。Kberetes已經(jīng)發(fā)展成為事實(shí)上的云操作系統(tǒng)，包括私有、公共和混合云產(chǎn)品。它實(shí)現(xiàn)了一個(gè)分布式編排器，用于處理多種類型的網(wǎng)絡(luò)、存儲(chǔ)和計(jì)算資源。此外，K8s提供了一個(gè)接口，使DevOps10的最佳實(shí)踐，如GitOps.11每個(gè)云服務(wù)提供商（CSP）都有一些Kberetes服務(wù)的味道，便于訪問基礎(chǔ)設(shè)施和一系列支持服務(wù)來運(yùn)行各種工作負(fù)載，包括AI/ML。WHITEPAPER|云人工智能4人工智能的進(jìn)化人工智能，最早在1956年被稱為一個(gè)術(shù)語，12是機(jī)器模擬人類智能的能力。幾十年來，它已被用于語音識(shí)別，機(jī)器翻譯，圖像處理，游戲等應(yīng)用，甚至是作為危險(xiǎn)玩家的出色表現(xiàn)。13但是，由于人工神經(jīng)網(wǎng)絡(luò)和深度學(xué)習(xí)的創(chuàng)新，人工智能最近在midshare中爆發(fā)了，主要應(yīng)用于自然語言理解。AI有兩種主要分類：判別性和生成性。判別式AI尋求學(xué)習(xí)決策邊界或分類，將知識(shí)捕獲為“模型”,用于預(yù)測新數(shù)據(jù)。例如，將電子郵件分類為垃圾郵件，區(qū)分貓和狗的圖像等等。判別AI通常用于已知所需輸出的任務(wù)（例如Procedre，通過監(jiān)督學(xué)習(xí)，一種機(jī)器學(xué)習(xí)的形式)。人工智能擅長序列預(yù)測，例如，通過分析大量現(xiàn)有文本，包括我們的個(gè)人寫作風(fēng)格，以高概率猜測我們接下來要輸入的內(nèi)容。卷積神經(jīng)網(wǎng)絡(luò)14（CNN）最初是在1980年代開發(fā)的，但直到21世紀(jì)初才被廣泛使用。近年來，由于它們能夠從圖像的大型數(shù)據(jù)集中進(jìn)行學(xué)習(xí)，并在各種圖像處理任務(wù)（例如對象檢測，圖像分類和分割）上表現(xiàn)良好，CNN變得越來越受歡迎。生成AI學(xué)習(xí)數(shù)據(jù)中的潛在結(jié)構(gòu)或表示。它可以使用這些結(jié)構(gòu)或表示來合成新數(shù)據(jù)，例如創(chuàng)建故事，音樂和視覺藝術(shù)來自單詞提示。生成性AI用于所需輸出未知或“正確”輸出定義不明確的任務(wù)。使用生成性AI，AI已經(jīng)超越了人類認(rèn)為的創(chuàng)造性，原創(chuàng)性和崇高性。讓我們仔細(xì)看看AI的一些驚人突破。變壓器由多倫多大學(xué)和谷歌的研究人員于2017年開發(fā)。變形金剛使用一種稱為縮放點(diǎn)積注意力的專門機(jī)制，該機(jī)制使它們充滿了類似記憶的結(jié)構(gòu)。15基于變形金剛的模型對于自然語言處理任務(wù)非常有效，例如回答問題，總結(jié)文本和翻譯。因此，它們在大多數(shù)大型語言模型（LLM)中至關(guān)重要。最著名的LLM是GPT，該模型為流行的ChatGPT服務(wù)提供動(dòng)力。WHITEPAPER|云人工智能5LLM是在海量數(shù)據(jù)集上訓(xùn)練的。除了能夠針對具有額外數(shù)據(jù)的專業(yè)領(lǐng)域進(jìn)行微調(diào)之外，它們還采取可能很長的提示序列來生成上下文敏感的響應(yīng)，無論是時(shí)事，醫(yī)學(xué)，法律還是其他。用于微調(diào)的新技術(shù)，例如來自人類反饋的強(qiáng)化學(xué)習(xí)（RLHF）和直接偏好優(yōu)化（DPO），已經(jīng)被開發(fā)出來，以使LLM更具吸引力。研究和創(chuàng)新使最終用戶的交互比以往任何時(shí)候都更快，更有創(chuàng)造力，更準(zhǔn)確。與數(shù)據(jù)科學(xué)和軟件的創(chuàng)新一樣重要的是基礎(chǔ)設(shè)施的發(fā)展模型推理（從AI模型計(jì)算結(jié)果的過程）和模型訓(xùn)練（從數(shù)據(jù)構(gòu)建AI模型的過程）。使用AI加速器技術(shù)，人工智能從業(yè)者可以更快地迭代，以在幾天和幾周內(nèi)提供更高質(zhì)量的模型，而不是幾個(gè)月。此外，數(shù)據(jù)科學(xué)家和統(tǒng)計(jì)學(xué)家采用的幾種傳統(tǒng)技術(shù)正在重新評估，以利用CN系統(tǒng)的功能。云原生與人工智能的融合正如上一節(jié)所述，人工智能是一個(gè)更廣泛的概念，旨在創(chuàng)建可以執(zhí)行類似于人類任務(wù)的系統(tǒng)。機(jī)器學(xué)習(xí)是一種基于數(shù)據(jù)進(jìn)行學(xué)習(xí)并做出明智預(yù)測和決策的方法。它可以被認(rèn)為是另一種形式的自動(dòng)化，涉及使用算法來學(xué)習(xí)和改進(jìn)，而無需顯式編程。最后，數(shù)據(jù)科學(xué)作為一個(gè)多學(xué)科領(lǐng)域，融合了統(tǒng)計(jì)學(xué)，數(shù)學(xué)和計(jì)算機(jī)科學(xué)的技術(shù)來制定。廣泛的活動(dòng)，從數(shù)據(jù)分析和解釋到機(jī)器學(xué)習(xí)算法的應(yīng)用。從廣義上講，我們可以將AI，ML和數(shù)據(jù)科學(xué)的應(yīng)用程序分為兩大類：預(yù)測性AIand生成AI。預(yù)測性AI旨在預(yù)測和分析現(xiàn)有模式或結(jié)果（例如，分類，聚類，回歸，對象檢測等）。相比之下，生成AI旨在生成新的和原始的內(nèi)容（例如，LLM，RAG17等）。因此，支持預(yù)測性和生成AI的算法和技術(shù)可能會(huì)有很大差異。WHITEPAPER|云人工智能6以下是預(yù)測和生成AI在計(jì)算、網(wǎng)絡(luò)和存儲(chǔ)方面有不同需求的一組示例：挑戰(zhàn)/需求生成AI預(yù)測性AI計(jì)算型Power需要專門的硬件。中等到高。通用硬件就足夠了。數(shù)據(jù)量和多樣性用于培訓(xùn)的大量、多樣化的數(shù)預(yù)測的具體歷史數(shù)據(jù)。模型訓(xùn)練和微調(diào)使用專業(yè)計(jì)算進(jìn)行復(fù)雜的迭代訓(xùn)練。適度的訓(xùn)練?？蓴U(kuò)展性和彈性高度可擴(kuò)展和彈性的基礎(chǔ)設(shè)施（可變和密集的計(jì)算需求）可擴(kuò)展性是必要的，但要求較低的彈性。批處理或事件驅(qū)動(dòng)的任務(wù)。存儲(chǔ)和吞吐量具有出色吞吐量的高性能存儲(chǔ)。數(shù)據(jù)類型多需要高吞吐量和低延遲的數(shù)據(jù)訪問。高效存儲(chǔ)，吞吐量適中。它更側(cè)重于數(shù)據(jù)分析，而不是數(shù)據(jù)生成；數(shù)據(jù)主要是結(jié)構(gòu)化的。聯(lián)網(wǎng)用于數(shù)據(jù)傳輸和模型同步(例如,在分布式訓(xùn)練期間)的高帶寬和低延遲。數(shù)據(jù)訪問的一致可靠連接。在接下來的部分中，我們將探討如何滿足這兩種形式所產(chǎn)生的需求，隨之而來的挑戰(zhàn)，以及在面對這些挑戰(zhàn)時(shí)可能提出的建議。什么是云原生人工智能？云原生人工智能允許構(gòu)建實(shí)用的系統(tǒng)來部署、運(yùn)行和擴(kuò)展AI工作負(fù)載。CNAI解決方案解決了AI應(yīng)用科學(xué)家、開發(fā)人員和部署人員在云基礎(chǔ)設(shè)施上開發(fā)、部署、運(yùn)行、擴(kuò)展和監(jiān)控AI工作負(fù)載時(shí)面臨的挑戰(zhàn)。通過利用底層云基礎(chǔ)設(shè)施的計(jì)算(例如Procedre，CPU和GPU），網(wǎng)絡(luò)和存儲(chǔ)功能，以及提供隔離和受控共享機(jī)制，可加速AI應(yīng)用程序性能并降低成本。圖2（下圖）在工具和技術(shù)之間映射了這些啟用機(jī)制。WHITEPAPER|云人工智能7啟用工具和技術(shù)18在云原生基礎(chǔ)設(shè)施上運(yùn)行AI云服務(wù)提供商和/或AI公司發(fā)布的媒體文章強(qiáng)調(diào)了CloudNativeforAI的價(jià)值。OPENAI將Kubernetes擴(kuò)展到7,500個(gè)節(jié)點(diǎn)擁抱臉與Microsoft合作在Azure上啟動(dòng)擁抱臉模型目錄云原生人工智能是云原生的一個(gè)不斷發(fā)展的擴(kuò)展。云原生人工智能是云原生的一個(gè)不斷發(fā)展的擴(kuò)展。Kubernetes是一個(gè)可用于部署和管理容器的編排平臺(tái)，容器是輕量級、可移植、自包含的軟件單元，AI模型可以打包成容器然后部署到K8s集群。容器化對于AI模型尤其重要，因?yàn)椴煌哪Ｐ屯ǔＰ枰煌彝ǔＯ嗷_突的依賴關(guān)系。在容器中隔離這些依賴關(guān)系可以在模型部署中提供更大的靈活性。CN工具允許AI模型的高效和可擴(kuò)展部署，并不斷努力為AI工作負(fù)載定制這些模型。WHITEPAPER|云人工智能8KubernetesScheduler21繼續(xù)發(fā)展，2223特別是為了更好地集成和支持共享圖形處理單元(GPU)，這些圖形處理單元在加速AI工作負(fù)載方面變得非常流行。除了支持共享GPU和處理多租戶的應(yīng)用程序之外，還在努力支持利用Kubernetes之外的遠(yuǎn)程資源池。需要高質(zhì)量的數(shù)據(jù)來訓(xùn)練和測試AI模型，以獲得卓越的推理。云原生基礎(chǔ)設(shè)施可以通過各種方法訪問數(shù)據(jù)，例如數(shù)據(jù)湖和倉庫。許多云提供商提供塊、對象和文件存儲(chǔ)系統(tǒng)，非常適合提供低成本、可擴(kuò)展的存儲(chǔ)。例如，模型的大小可以達(dá)到千兆字節(jié)。在訓(xùn)練階段，每次拉取模型的檢查點(diǎn)都會(huì)導(dǎo)致網(wǎng)絡(luò)和存儲(chǔ)帶寬的嚴(yán)重負(fù)載。將模型視為容器化的工件為在OCI24注冊表中托管它們打開了大門，并啟用了緩存。它進(jìn)一步允許應(yīng)用。軟件供應(yīng)鏈模型的最佳實(shí)踐，例如工件簽名,驗(yàn)證，證明和數(shù)據(jù)來源。此外，容器化模型/工件促進(jìn)了WebAssembly(WASM)二進(jìn)制文件的捆綁。WASM是一種獨(dú)立于平臺(tái)的高效CN推理方法。為什么選擇云原生人工智能？憑借其彈性，始終在線的基礎(chǔ)架構(gòu)，云允許企業(yè)，初創(chuàng)公司和開發(fā)人員快速原型，提供新服務(wù)，擴(kuò)展解決方案等等。它還通過資源共享實(shí)現(xiàn)了成本效益。普通用戶不再需要擔(dān)心訂購硬件或處理空間、電源、網(wǎng)絡(luò)連接、冷卻、軟件許可和安裝等物流問題。人工智能也有類似的擔(dān)憂——快速原型設(shè)計(jì)、訪問存儲(chǔ)、網(wǎng)絡(luò)和計(jì)算資源，以解決小型和大規(guī)模的訓(xùn)練和推理任務(wù)。使用AI改進(jìn)云原生系統(tǒng)無論是打包為可觀察性工具還是利用LLM功能進(jìn)行日志的自然語言處理（NLP），AI驅(qū)動(dòng)的解決方案/項(xiàng)目都在進(jìn)入運(yùn)營商和最終用戶的手中，以提高他們的生產(chǎn)力并使他們的生活更輕松。一個(gè)這樣的開源云原生計(jì)算基金會(huì)(CNCF）項(xiàng)目是K8sGPT，它利用LLM的模式識(shí)別和語言功能，如Bedroc，Cohere等，以幫助K8s運(yùn)營商。日常工作。更重要的是，CN和AI的共生為新的和不可預(yù)見的機(jī)會(huì)打開了生態(tài)系統(tǒng)。例如，我們預(yù)計(jì)能夠操作和管理復(fù)雜系統(tǒng)的技術(shù)含量較低的用戶將會(huì)增加。WHITEPAPER|云人工智能9云人工智能的挑戰(zhàn)重要的是要注意，CNAI的挑戰(zhàn)在不同的角色之間會(huì)有所不同。26而且，盡管ClodNative的靈活，可擴(kuò)展的平臺(tái)非常適合AI工作負(fù)載，但AI的規(guī)模和延遲需求帶來了挑戰(zhàn)，并暴露了CN技術(shù)中的差距，同時(shí)也帶來了機(jī)會(huì)。我們在端到端ML流水線的背景下梳理這些內(nèi)容。27在文獻(xiàn)中也稱為MLOps.28傳統(tǒng)的時(shí)間和空間，并行性和同步權(quán)衡的問題都存在，暴露了易于使用的差距?？偠灾琈L生命周期如下所示：周期典型的ML管道包括：?數(shù)據(jù)準(zhǔn)備（收集、清洗/預(yù)處理、特征工程）?模型訓(xùn)練（模型選擇、架構(gòu)、超參數(shù)調(diào)優(yōu)）?CI/CD,模型注冊表（存儲(chǔ)）?模型服務(wù)?可觀察性（使用負(fù)載、模型漂移、安全性）訓(xùn)練、相似性搜索和模型大?。ㄌ貏e是LLM）中涉及的數(shù)據(jù)量，每個(gè)驅(qū)動(dòng)器內(nèi)存和性能方面的考慮因素。雖然CN處理CPU的訪問控制和調(diào)度，但具有充分共享的GPU分配仍在不斷發(fā)展。ML訓(xùn)練階段涉及搜索，需要跟蹤中間模型的性能，以確定要保留哪些模型以及如何進(jìn)一步調(diào)整模型參數(shù)以獲得更高的準(zhǔn)確性?？紤]到處理數(shù)據(jù)的敏感性和模型的內(nèi)在價(jià)值，安全性更為重要?？捎^察性對于檢測模型漂移、使用負(fù)載等至關(guān)重要。讓我們更深入地探討每個(gè)管道階段的挑戰(zhàn)。鼓勵(lì)讀者考慮與其領(lǐng)域相關(guān)的其他挑戰(zhàn)，并添加到對話中。數(shù)據(jù)準(zhǔn)備作為AI/ML管道的第一階段，數(shù)據(jù)準(zhǔn)備可能會(huì)帶來各種挑戰(zhàn)。這些可以大致分為三大類：管理大數(shù)據(jù)大小，確保開發(fā)和部署期間的數(shù)據(jù)同步以及遵守?cái)?shù)據(jù)治理策略。WHITEPAPER|云人工智能數(shù)據(jù)大小構(gòu)建更好的AI/ML模型的數(shù)據(jù)需求增長速度快于摩爾定律，每18個(gè)月翻一番。30無論是數(shù)據(jù)管理/處理、數(shù)據(jù)處理還是數(shù)據(jù)分析，構(gòu)建AI/ML模型的數(shù)據(jù)需求都在快速升級。因此，分布式CloudNative計(jì)算和高效的數(shù)據(jù)移動(dòng)和存儲(chǔ)對于彌合這些計(jì)算需求和硬件能力之間的差距至關(guān)重要。數(shù)據(jù)同步數(shù)據(jù)可能需要以不同的格式從多個(gè)不同的位置獲得；開發(fā)人員和生產(chǎn)環(huán)境通常是不同的，所有這些都是除了處理分布式計(jì)算引起的復(fù)雜性增加之外，例如分區(qū)和同步。讓我們仔細(xì)看看后者。在像Spar這樣的數(shù)據(jù)處理系統(tǒng)中，行業(yè)標(biāo)準(zhǔn)接口SQL在為用戶提供熟悉的統(tǒng)一體驗(yàn)方面起著至關(guān)重要的作用，無論他們是在本地制作原型還是以分布式方式運(yùn)行大型工作負(fù)載。但是，ML工作負(fù)載沒有行業(yè)標(biāo)準(zhǔn)接口。因此，數(shù)據(jù)科學(xué)家在本地使用小數(shù)據(jù)集開發(fā)他們的MLPytho腳本，然后分布式系統(tǒng)工程師重寫這些腳本以進(jìn)行分布式執(zhí)行。如果分布式ML工作負(fù)載未按預(yù)期運(yùn)行，數(shù)據(jù)科學(xué)家可能需要使用其本地Pytho腳本調(diào)試問題。這個(gè)過程是低效的并且通常是無效的。盡管有更好的可觀察性工具和容器技術(shù)提供的可再現(xiàn)性,但這是真的。存在可能可行的解決方案來解決本地開發(fā)和生產(chǎn)環(huán)境之間的這種不一致。首先是使用行業(yè)標(biāo)準(zhǔn)接口來支持端到端ML生命周期。例如，用戶可以利用PyTorch或TesorFlow等原生ML框架的API來創(chuàng)建訓(xùn)練代碼，并通過在Pytho運(yùn)行時(shí)本地運(yùn)行來驗(yàn)證它。然后，用戶可以輕松。重用相同的代碼并利用Kbeflow的PythoSDK通過Kid/Miibe以分布式方式在本地運(yùn)行此代碼，或者通過使用相同的PythoSDK將其部署到遠(yuǎn)程大型Kberetes集群來輕松擴(kuò)展其訓(xùn)練代碼。另一種選擇是使用通用分布式計(jì)算引擎，如Ray,其計(jì)算抽象還使用戶能夠在本地和生產(chǎn)環(huán)境中無縫運(yùn)行相同的Ray腳本。數(shù)據(jù)量是一個(gè)貫穿各領(lǐng)域的問題，也體現(xiàn)在訓(xùn)練階段。數(shù)據(jù)治理數(shù)據(jù)治理對于建立信任和確保負(fù)責(zé)任的AI開發(fā)至關(guān)重要。應(yīng)該考慮關(guān)于數(shù)據(jù)治理的三個(gè)關(guān)鍵支柱。1.隱私和安全：應(yīng)對GDPR31和CPA32等數(shù)據(jù)隱私法規(guī)的復(fù)雜環(huán)境至關(guān)重要。應(yīng)實(shí)施強(qiáng)有力的安全措施來保護(hù)人工智能模型中使用的敏感數(shù)據(jù)。應(yīng)使用加密、訪問控制和定期漏洞評估來保護(hù)有價(jià)值的信息。2.所有權(quán)和譜系：必須明確定義從收集到使用的整個(gè)AI生命周期中誰擁有和有權(quán)訪問數(shù)據(jù)。應(yīng)使用數(shù)據(jù)沿襲跟蹤工具來了解數(shù)據(jù)如何通過系統(tǒng)流動(dòng)，確保透明度和問責(zé)制。這樣做有助于防止對敏感信息的未經(jīng)授權(quán)的訪問和濫用。WHITEPAPER|云人工智能3.緩解偏差:人工智能模型僅與所訓(xùn)練的數(shù)據(jù)一樣好。因此，必須積極監(jiān)控和解決數(shù)據(jù)和算法中的潛在偏差。這包括使用不同的數(shù)據(jù)集，采用公平性指標(biāo)，并不斷評估模型以確保其提供公平和道德的結(jié)果，包括捕獲其局限性。ModelCards33正在不斷發(fā)展以捕獲這些結(jié)果。數(shù)據(jù)隱私和安全是一個(gè)跨領(lǐng)域的問題，需要在每個(gè)階段加以考慮。模型訓(xùn)練模型訓(xùn)練數(shù)據(jù)量呈指數(shù)級增長，導(dǎo)致需要分布式處理和加速器來實(shí)現(xiàn)更多的并行性。進(jìn)一步的訓(xùn)練是一個(gè)迭代的多步驟過程，這使得擴(kuò)展成為一個(gè)復(fù)雜的多組件協(xié)調(diào)任務(wù)。我們在本節(jié)中更詳細(xì)地回顧了這些方面。不斷上升的加工需求LLM正在迅速突破界限，以滿足不斷增長的AI/ML訓(xùn)練和推理計(jì)算需求，加速器正在變得流行。這些范圍從多個(gè)供應(yīng)商的GPU與谷歌的張量處理單元（TPU），英特爾的高迪，甚至現(xiàn)場可編程門陣列（FPGA）不同的功能。這些多樣化的計(jì)算資源需要虛擬化支持、驅(qū)動(dòng)程序、配置和共享它們的能力以及CN調(diào)度器增強(qiáng)功能。此外，這些加速器有限的可用性和成本促使人們探索多云資源帶寬，甚至是sy34計(jì)算。在GPU虛擬化和動(dòng)態(tài)分配方面，將CN技術(shù)用于AI可能會(huì)很復(fù)雜。vGPU，MIG，MPS（請參閱詞匯表）和動(dòng)態(tài)資源分配（DRA）等技術(shù)使多個(gè)用戶可以共享單個(gè)GPU，同時(shí)在Pod中的容器之間提供隔離和共享。它們可以提高GPU利用率，從而降低成本，此外還可以允許多個(gè)工作負(fù)載同時(shí)受益。但是，實(shí)施需要仔細(xì)的編排和管理，尤其是在動(dòng)態(tài)分配和釋放資源時(shí)。AI和CN工程團(tuán)隊(duì)之間的緊密協(xié)作是確保順利和高效集成的必要條件。成本效率云原生環(huán)境固有的彈性和可擴(kuò)展性允許組織根據(jù)波動(dòng)的需求動(dòng)態(tài)調(diào)配和擴(kuò)展資源。這一點(diǎn)也適用于AI任務(wù)。However,resourcepropersizingandreactivescheduingtomeetvaryingworkloaddemandareevenmorecompliantinthecontextofacceleratorssuchasGPU,whichareexpensibleandlimitedinsupply.Itdrivestheneedtobeableto細(xì)分GPU更好地利用它們。在模型服務(wù)期間減少碳足跡可以使用自動(dòng)擴(kuò)展服務(wù)框架來實(shí)現(xiàn)，該框架根據(jù)需求動(dòng)態(tài)調(diào)整資源。36KServe，37一個(gè)LFAI和DataFodatio項(xiàng)目，提供了這樣的功能。可持續(xù)能力38可以通過各種方式得到顯著改善,例如使用更小、更專業(yè)的模型、使用專家的混合以及諸如壓縮和蒸餾的技術(shù)。將ML服務(wù)分配到由可再生或更清潔能源提供動(dòng)力的地理區(qū)域可以顯著減少碳足跡。ML模型的負(fù)責(zé)任開發(fā)可以包括有關(guān)碳足跡的元數(shù)據(jù)，以幫助跟蹤和報(bào)告模型排放對環(huán)境的影響。其他工具，例如mlco240and編解碼器41存在局限性，以幫助在體育鍛煉之前預(yù)測新神經(jīng)網(wǎng)絡(luò)的碳足跡。WHITEPAPER|云人工智能可擴(kuò)展性協(xié)調(diào)各種微服務(wù)的擴(kuò)展,每個(gè)微服務(wù)封裝特定的AI功能,此外，AI模型和框架的異構(gòu)性使標(biāo)準(zhǔn)化變得復(fù)雜，使得創(chuàng)建適用于各種應(yīng)用程序的通用擴(kuò)展解決方案具有挑戰(zhàn)性。編排/調(diào)度正如前面提到的，CloudNative工具和項(xiàng)目通過利用容器化、微服務(wù)和可擴(kuò)展云基礎(chǔ)設(shè)施的固有特性，簡化了AI工作負(fù)載的編排和調(diào)度。復(fù)雜的AI工作流可以分解為模塊化組件，從而更容易獨(dú)立管理和擴(kuò)展特定功能。但是，如前所述，GPU是一種寶貴的需求資源，能夠更有效地管理基于GPU的AI工作負(fù)載的共享和調(diào)度對于AI開發(fā)團(tuán)隊(duì)的成功至關(guān)重要。用于解決高級調(diào)度需求（如裝箱，放置，資源爭用和搶占）的經(jīng)過良好測試的工具對于云原生AI的蓬勃發(fā)展至關(guān)重要。通過Yior，42Volcao，43和Kee，44后兩種解決批量調(diào)度的努力，更好的調(diào)度支持在Kberetes中不斷發(fā)展，這對于有效的AI/ML訓(xùn)練特別有價(jià)值。訓(xùn)練作業(yè)受益于gag（或組）調(diào)度，45因?yàn)閷儆谧鳂I(yè)的容器副本需要全有或全無放置策略才能正常運(yùn)行，并且這些作業(yè)不容易放大或縮小。幫派調(diào)度支持是一個(gè)機(jī)會(huì)領(lǐng)域。自定義依賴項(xiàng)AI應(yīng)用程序通常依賴于特定的框架和版本的庫，這些依賴關(guān)系可能無法輕易獲得或與標(biāo)準(zhǔn)容器映像兼容。由于許多AI工作負(fù)載受益于GPU加速，因此擁有必要的GPU驅(qū)動(dòng)程序和庫來支持在GPU上運(yùn)行的工作負(fù)載可能具有挑戰(zhàn)性，尤其是在與不同的供應(yīng)商和GPU架構(gòu)打交道時(shí)。例如,當(dāng)在NVIDIA設(shè)備上運(yùn)行分布式訓(xùn)練時(shí),可以使用NVIDIA集體通信庫(NCCL),以利用優(yōu)化的多GPU和多節(jié)點(diǎn)通信原語。不同版本的庫可能會(huì)導(dǎo)致不同的性能。可復(fù)制的構(gòu)建是所有軟件的良好構(gòu)建衛(wèi)生實(shí)踐，需要使用版本化的依賴關(guān)系來避免運(yùn)行時(shí)不兼容和性能意外。模型服務(wù)由于負(fù)載可變性和通常的延遲要求，模型服務(wù)主要不同于數(shù)據(jù)處理和訓(xùn)練。此外,除了共享基礎(chǔ)設(shè)施之外,還考慮服務(wù)彈性以降低成本。此外，AI模型特征是不同的，在經(jīng)典ML，深度學(xué)習(xí)（DL），生成AI（GAI）LLM以及最近的多模態(tài)方法（例如。Procedre，文本到視頻)。不同的工作負(fù)載需要來自ML基礎(chǔ)設(shè)施的各種支持。例如，在LLM出現(xiàn)之前，模型服務(wù)通常只需要一個(gè)GPU。如果工作負(fù)載對延遲不敏感，則一些用戶選擇基于CPU的推理。但是，當(dāng)服務(wù)LLM時(shí)，由于Trasformer解碼器的自回歸特性，性能瓶頸從計(jì)算綁定轉(zhuǎn)移到內(nèi)存綁定。46。WHITEPAPER|云人工智能本節(jié)探討CN如何支持這些方面以及仍然存在哪些挑戰(zhàn)。微服務(wù)架構(gòu)和開發(fā)人員體驗(yàn)CN基于微服務(wù)架構(gòu)。然而，這可能對AI構(gòu)成挑戰(zhàn)，將ML管道中的每個(gè)階段作為單獨(dú)的微服務(wù)來處理。許多組件可能使保持和同步它們的輸出和切換具有挑戰(zhàn)性。即使用戶只想在筆記本電腦上使用這些解決方案，他們可能仍然需要?jiǎng)?chuàng)建數(shù)十個(gè)Pods。復(fù)雜性使得基礎(chǔ)架構(gòu)缺乏適應(yīng)多功能ML工作負(fù)載的靈活性。其次，基于微服務(wù)的ML基礎(chǔ)架構(gòu)導(dǎo)致了碎片化的用戶體驗(yàn)。例如，在他們的日常工作流程中，AI從業(yè)者可能需要構(gòu)建容器映像、編寫自定義資源YAML文件、使用工作流編排器等，而不是只專注于他們的MLPytho腳本。這種復(fù)雜性還表現(xiàn)為更陡峭的學(xué)習(xí)曲線，要求用戶在他們的專業(yè)知識(shí)和/或興趣之外學(xué)習(xí)許多系統(tǒng)。第三，在ML模型生命周期中集成來自不同系統(tǒng)的每個(gè)階段時(shí)，成本會(huì)大大增加。Samsara工程博客47提到，它的ML生產(chǎn)管道托管在幾個(gè)微服務(wù)中，具有單獨(dú)的數(shù)據(jù)處理、模型推理和業(yè)務(wù)邏輯步驟。拆分基礎(chǔ)架構(gòu)涉及復(fù)雜的管理以同步資源，從而減慢了開發(fā)和模型發(fā)布的速度。然后，使用Ray，Samsara構(gòu)建了一個(gè)統(tǒng)一的ML平臺(tái)。增強(qiáng)了他們的生產(chǎn)ML管道性能，為公司提供了近50%的年度ML推斷總成本，這主要源于資源共享和消除了各個(gè)階段的序列化和反序列化。這些問題凸顯了對基于Ray等通用分布式計(jì)算引擎的統(tǒng)一ML基礎(chǔ)架構(gòu)的需求。Ray可以補(bǔ)充現(xiàn)有的ClodNative生態(tài)系統(tǒng)，專注于計(jì)算，允許ClodNative生態(tài)系統(tǒng)專注于部署和交付。Ray/KbeRay社區(qū)與多個(gè)ClodNative社區(qū)廣泛合作，例如Kbeflow，48Kee，49GoogleGKE，50和OpeShift.51。模型放置理想情況下，用戶喜歡在單個(gè)集群中部署多個(gè)可能不相關(guān)的模型進(jìn)行推理，同時(shí)也尋求共享推理框架以降低成本并獲得模型隔離。此外，對于彈性，他們希望在不同的故障區(qū)域中復(fù)制副本。Kberetes提供了親和力和反親和力機(jī)制來調(diào)度不同拓?fù)溆蛑械墓ぷ髫?fù)載（例如Procedre，zoe，ode），52但可用性改進(jìn)可以幫助用戶利用這些功能。資源分配模型服務(wù)主要需要處理模型參數(shù)。參數(shù)的數(shù)量和表示大小指示所需的內(nèi)存。除非處理萬億參數(shù)LLM，否則這些通常只需要GPU的一部分。這凸顯了需要能夠分割昂貴的加速器，如GPU。DRA項(xiàng)目53仍處于alpha狀態(tài)，旨在使GPU調(diào)度更加靈活。另一個(gè)考慮因素是響應(yīng)延遲，這在很大程度上取決于用例。例如，在自動(dòng)駕駛環(huán)境中檢測道路上的物體所需的響應(yīng)延遲比創(chuàng)建圖像或?qū)懺姇r(shí)的可容忍低幾個(gè)數(shù)量級。其他服務(wù)實(shí)例可能需要為高負(fù)載條件下的低延遲應(yīng)用程序啟動(dòng)。如果可以實(shí)現(xiàn)所需的延遲，這些應(yīng)用程序可能會(huì)降落在CPU、GPU或其他計(jì)算資源上。在Kubernetes中，對可用資源的這種級聯(lián)機(jī)會(huì)調(diào)度的支持仍在不斷發(fā)展。WHITEPAPER|云人工智能此外，事件驅(qū)動(dòng)的托管是不浪費(fèi)資源和降低成本的理想選擇。Kberetes事件驅(qū)動(dòng)自動(dòng)縮放（KEDA）54項(xiàng)目非常適合這里，前提是模型加載延遲可以容忍仍然提供端到端服務(wù)延遲。這里的一個(gè)機(jī)會(huì)是通過以O(shè)peCotaierIitiative55(OCI)格式交付模型來為模型共享提供更好的支持，OCI是一種適用于共享的不可變文件系統(tǒng)。另一種解決方案是將AI用于CN，特別是預(yù)測使用情況，并主動(dòng)浮動(dòng)或關(guān)閉服務(wù)實(shí)例以處理預(yù)期的負(fù)載。用戶體驗(yàn)CN的標(biāo)志，也就是容器，允許可移植性和可重復(fù)性，而Kberetes的API和操作員，如Kbeflow，簡化了AI工作負(fù)載的部署，使它們以易于擴(kuò)展的方式“編寫一次并（幾乎）在任何地方運(yùn)行”。一旦用戶從裸機(jī)或虛擬化環(huán)境上的傳統(tǒng)批處理系統(tǒng)過渡到容器和Kberetes，他們就會(huì)欣賞云技術(shù)的優(yōu)勢，盡管它們最初的采用面臨挑戰(zhàn)。然而,學(xué)習(xí)曲線可以是陡峭讓我們考慮AI培訓(xùn)工作負(fù)載。配置運(yùn)行時(shí)環(huán)境可能是耗時(shí)的,特別是當(dāng)使用高度可定制的庫時(shí)。用戶可以選擇對大量環(huán)境變量使用默認(rèn)設(shè)置，但這些設(shè)置可能會(huì)產(chǎn)生較差的性能。一旦在給定的Kberetes平臺(tái)上針對特定的訓(xùn)練工作負(fù)載進(jìn)行了優(yōu)化，就不能保證它將在另一個(gè)平臺(tái)或訓(xùn)練任務(wù)或包含不同庫的容器捆綁上執(zhí)行同樣的操作。這會(huì)影響工作負(fù)載的可移植性和易用性。上一段只看了AI管道中的一個(gè)階段，通常是多階段，涵蓋數(shù)據(jù)準(zhǔn)備、訓(xùn)練、調(diào)優(yōu)、服務(wù)和微調(diào)。如何為不一定精通系統(tǒng)或云概念的AI從業(yè)者提供無縫的用戶體驗(yàn)，并為他們提供簡化的產(chǎn)品體驗(yàn)，以消除AI開發(fā)中的摩擦？為AI從業(yè)者提供用戶友好且眾所周知的Pytho編寫的SDK，抽象出Kberetes的復(fù)雜細(xì)節(jié)，可以幫助提高ClodNativeAI工具的采用率。用戶希望使用PyTorch和TesorFlow構(gòu)建ML模型，然后通過使用簡單的PythoSDK快速輕松地將其部署到Kberetes基礎(chǔ)設(shè)施，而不必?fù)?dān)心打包，構(gòu)建Docer映像，創(chuàng)建Kberetes自定義資源等細(xì)節(jié)（例如。Procedre，PyTorchJob，TFJob），并使用復(fù)雜的云原生工具擴(kuò)展這些模型。要為MLOps生命周期創(chuàng)造一個(gè)更加用戶友好的開源產(chǎn)品體驗(yàn)，需要一個(gè)強(qiáng)大的產(chǎn)品開發(fā)重點(diǎn)。集成像JupyterLab這樣的工具，它包含了類似IDE的體驗(yàn)空間，這些體驗(yàn)可能存在于當(dāng)今可用的AI/ML工具（例如KubeflowKatibAPI）中，這將使ML從業(yè)者能夠更快地迭代他們的AI開發(fā)，而在多個(gè)用戶界面上的上下文切換更少。JupyterLab的可擴(kuò)展特性為ML從業(yè)者提供了一個(gè)工作區(qū)，可以在熟悉的工具中構(gòu)建，部署和監(jiān)視AI/ML工作負(fù)載,而無需學(xué)習(xí)新的工具和界面。甚至可以使用JupyterLab使用像Elyra56這樣的GUI工作流構(gòu)建工具以及Kubeflow管道來安排在各個(gè)AI/MLNotebooks中開發(fā)的代碼的工作流。企業(yè)內(nèi)外的大數(shù)據(jù)是AI的支柱。必須考慮如何彌合大數(shù)據(jù)和ML生態(tài)系統(tǒng)之間的差距。例如，現(xiàn)代生成AI模型需要大量數(shù)據(jù)進(jìn)行訓(xùn)練。盡管如此，將Iceberg等格式的大量數(shù)據(jù)加載到PyTorch等訓(xùn)練框架中的工具仍需要增強(qiáng)，TorchArrow57和PyIceberg58等工具展示了早期的希望。用于大規(guī)模數(shù)據(jù)準(zhǔn)備的工具，如Spar，與ML生態(tài)系統(tǒng)中的工具沒有很好的連接。需要額外的開銷來準(zhǔn)備數(shù)據(jù)、構(gòu)建功能、將功能存儲(chǔ)到磁盤，然后將這些功能讀回內(nèi)存以用于訓(xùn)練工作負(fù)載。RayData59或基于ArrowFlightRPC構(gòu)建的數(shù)據(jù)緩存微服務(wù)等解決方案可能會(huì)顯著提高訓(xùn)練工作負(fù)載第一階段的輸入/輸出開銷。WHITEPAPER|云人工智能ML工具很復(fù)雜，用戶通常需要幫助才能在Kubernetes上部署它們。識(shí)別和部署GPU的適當(dāng)驅(qū)動(dòng)程序并使其與用戶的AI/ML兼容是不平凡的工作負(fù)載。應(yīng)簡化和改進(jìn)現(xiàn)有ML工作負(fù)載的升級路徑，類似于其他Kubernetes控制平面組件。用戶應(yīng)獲得有關(guān)如何使其AI工作負(fù)載適應(yīng)Kubernetes升級和集群停機(jī)的明確指南。影響易用性的另一個(gè)方面是多租戶，使用配額和名稱空間。非管理員用戶需要幫助來確定他們可用的系統(tǒng)資源。通常，管理員提供工具(例如，Grafana儀表板)以實(shí)現(xiàn)可觀察性；當(dāng)缺乏這些工具時(shí)，非專家/非管理員用戶會(huì)陷入困境。最后，調(diào)試是具有挑戰(zhàn)性的，在分布式環(huán)境中更是如此，當(dāng)處理管道包括多個(gè)復(fù)雜服務(wù)時(shí)更是如此。硬件和軟件故障可能或多或少是明確的，并且很容易識(shí)別云用戶，但人工智能從業(yè)者可能需要幫助來查看故障的完整情況。例如，NCCL終止錯(cuò)誤可能是模糊的，有許多可能的原因，每個(gè)原因都需要調(diào)查。用戶可能需要將錯(cuò)誤消息解析給管理員以獲得進(jìn)一步的幫助。交叉關(guān)注在前面的章節(jié)中，我們解決了AI管道中特定階段的挑戰(zhàn)。但其他是所有階段和所有軟件應(yīng)用程序所共有的，涵蓋參考實(shí)現(xiàn)、可觀察性、安全性等。例如，適當(dāng)調(diào)整大小的資源對于處理數(shù)據(jù)、訓(xùn)練或服務(wù)是有效的。它具有資源利用率，成本和可持續(xù)性的影響。讓我們深入一點(diǎn)。參考實(shí)施云和人工智能都不是容易的研究，在從許多工具和項(xiàng)目中做出選擇后，讓它們一起工作并不容易。需要通過要求滿足大多數(shù)簡單用例的參考實(shí)現(xiàn)來改進(jìn)采用。Kberetes的Kid創(chuàng)造了奇跡，幫助開發(fā)人員開始使用筆記本電腦。JpyterNoteboo也為新興的AI/ML開發(fā)人員做了同樣的事情。對于在云中運(yùn)行的AI/ML管道，我們需要類似的東西。適當(dāng)調(diào)整資源調(diào)配規(guī)模AI/ML工作負(fù)載是資源密集型的，尤其是具有數(shù)十億或數(shù)萬億參數(shù)的LLM。如前所述，像GPU這樣的加速器價(jià)格昂貴且供不應(yīng)求，使用適當(dāng)?shù)拇笮》峙鋪砉?jié)省資源和控制成本至關(guān)重要。我們不僅需要能夠?qū)PU進(jìn)行時(shí)間排序，還需要將它們切片或劃分為分?jǐn)?shù)段，并根據(jù)不同工作負(fù)載的需要明智地分配它們。結(jié)合上述后端工作，需要前端支持在啟動(dòng)工作負(fù)載時(shí)請求GPU子單元并對其進(jìn)行配置。為了滿足這一需求，Kubernetes引入了一個(gè)新的API，動(dòng)態(tài)資源分配(DRA)6061作為v1.26中的alpha。該API為管理專用硬件資源提供了更大的靈活性，特別是：?網(wǎng)絡(luò)連接資源?資源請求的任意參數(shù)?任意、特定于資源的設(shè)置和清理操作?自定義匹配資源請求與可用資源，包括處理可選請求。WHITEPAPER|云人工智能?與現(xiàn)有方法相比，DRAAPI提供了幾個(gè)優(yōu)點(diǎn)：-可以通過開發(fā)和部署DRA驅(qū)動(dòng)程序來添加自定義硬件，而無需修改核心Kubernetes代碼庫-供應(yīng)商可以定義資源參數(shù)-資源可以在容器和Pod之間共享成本控制AI/ML可以迅速成為預(yù)算黑洞。自動(dòng)化資源分配和擴(kuò)展流程以優(yōu)化AI云成本至關(guān)重要。微服務(wù)可以根據(jù)需要單獨(dú)擴(kuò)展。此外,它非常適合使用Kubernetes自動(dòng)擴(kuò)展功能，這將進(jìn)一步幫助正確調(diào)整活動(dòng)實(shí)例的數(shù)量，從而降低基礎(chǔ)設(shè)施成本。最后，Spot實(shí)例可以利用策略來捕獲平衡風(fēng)險(xiǎn)并滿足服務(wù)級別協(xié)議(SLA)?？捎^察性可觀察性在AI/ML管道中很有價(jià)值。CN提供了OpeTelemetry62和Promethes63等工具，可以監(jiān)控負(fù)載、訪問次數(shù)、響應(yīng)延遲等。在生產(chǎn)環(huán)境中監(jiān)控模型性能和運(yùn)行狀況至關(guān)重要。跟蹤模型漂移以確保AI系統(tǒng)的準(zhǔn)確性和可靠性至關(guān)重要。例如，在COVID-19大流行期間，隨著越來越多的人戴著口罩，面部識(shí)別系統(tǒng)可能會(huì)退化。同樣，由于自然災(zāi)害或利率變化等外部因素,房價(jià)預(yù)測模型可能會(huì)偏離現(xiàn)實(shí)。因此，持續(xù)監(jiān)控AI模型對于檢測任何性能問題并進(jìn)行必要的調(diào)整至關(guān)重要?；A(chǔ)設(shè)施監(jiān)控是必不可少的，尤其是對于長時(shí)間運(yùn)行的工作負(fù)載。當(dāng)AI訓(xùn)練工作負(fù)載運(yùn)行時(shí)，GPU和網(wǎng)絡(luò)可能會(huì)出現(xiàn)異常。例如，GPU內(nèi)存中的錯(cuò)誤或無法訪問的節(jié)點(diǎn)可能會(huì)導(dǎo)致作業(yè)崩潰。但是，可能會(huì)出現(xiàn)無法立即識(shí)別的問題：例如，訓(xùn)練性能可能會(huì)開始下降，而不會(huì)報(bào)告任何明顯的硬件故障。在這些情況下，只有深度診斷才能識(shí)別問題。當(dāng)前的度量不會(huì)暴露深度診斷的結(jié)果。因此，在運(yùn)行AI培訓(xùn)作業(yè)之前、期間和之后提供檢測、避免和處理基礎(chǔ)設(shè)施問題的工具變得至關(guān)重要。災(zāi)難恢復(fù)和業(yè)務(wù)連續(xù)性所有生產(chǎn)服務(wù)都必須具有彈性，并有備份，AI服務(wù)沒有什么不同，服務(wù)失敗或響應(yīng)緩慢會(huì)導(dǎo)致聲譽(yù)受損和收入損失。制定全面的災(zāi)難恢復(fù)計(jì)劃至關(guān)重要，可能包括數(shù)據(jù)備份，在多個(gè)可用區(qū)中運(yùn)行實(shí)例以及運(yùn)行多個(gè)實(shí)例。策略可以幫助您解決這些問題。安全性和合規(guī)性審核所有面向外的服務(wù)，特別是ModelServing實(shí)例，都需要防火墻保護(hù)、訪問控制等。與任何其他服務(wù)一樣，您的AI/ML工作負(fù)載必須遵循安全最佳實(shí)踐。這些包括滲透測試、漏洞掃描和工作負(fù)載域的合規(guī)性檢查，如醫(yī)療保健、財(cái)務(wù)等。WHITEPAPER|云人工智能像Grype64和Trivy65這樣的工具可以掃描容器化工作負(fù)載的漏洞。Kyverno66和策略實(shí)施服務(wù)可以確保容器化工作負(fù)載以所需的最低權(quán)限運(yùn)行，并且需要較小的功能。使用機(jī)密計(jì)算67或可信執(zhí)行環(huán)境（TEE）可以實(shí)現(xiàn)附加的安全層。這些硬件支持的環(huán)境提供加密內(nèi)存、數(shù)據(jù)完整性保護(hù)和可測試性。TEE在使用過程中保護(hù)數(shù)據(jù)和工作負(fù)載免受其他基礎(chǔ)架構(gòu)用戶的影響。AMD、英特爾、NVIDIA和IBM都有TEE產(chǎn)品，它們正在公共云中可用。保護(hù)敏感數(shù)據(jù)，如醫(yī)療保健和財(cái)務(wù)信息以及ML模型是主要用例?？沙掷m(xù)性AI/ML模型訓(xùn)練一直是資源密集型的，尤其是像GPT-3這樣的大型語言模型。培訓(xùn)排放可與多個(gè)橫貫大陸的航班相媲美，而由于查詢量高，推斷排放加起來。68行業(yè)傾向于對市場主導(dǎo)地位的過大模型的趨勢導(dǎo)致效率低下，從而導(dǎo)致能源和資源消耗。69在報(bào)告模型的環(huán)境影響方面，提高透明度和標(biāo)準(zhǔn)化是挑戰(zhàn)。最近，有努力增加與LLama70的透明度，同時(shí)一些見解正在成為可用的關(guān)于水使用的冷卻服務(wù)器運(yùn)行的LLM，如ChatGPT。ChatGPT的碳足跡是顯著的，因?yàn)樗臄?shù)以百萬計(jì)的用戶?？沙掷m(xù)發(fā)展的動(dòng)力為創(chuàng)新提供了機(jī)會(huì)。DeepMind的BCOOLER和DistilBERT和FlexGen等更小，更高效的模型在減少AI/ML能源方面顯示出希望71采用高效的機(jī)器學(xué)習(xí)架構(gòu)、優(yōu)化的處理器以及將云計(jì)算基礎(chǔ)設(shè)施定位在節(jié)能位置等最佳實(shí)踐，可以遏制機(jī)器學(xué)習(xí)訓(xùn)練的碳兒童教育如今，技術(shù)教育主要集中在沒有AI或計(jì)算機(jī)輔助的傳統(tǒng)編程語言上。學(xué)校通常不使用支持重構(gòu)，模板或API幫助的現(xiàn)代IDE，并且將在包含的網(wǎng)站上提供學(xué)生代碼，以便于設(shè)置。他們也不教授使用像Githb的Copilot這樣的AI編碼輔助技術(shù),盡管這將成為未來的標(biāo)準(zhǔn)開發(fā)模式。大多數(shù)學(xué)生甚至不知道這項(xiàng)技術(shù)的存在。由于擔(dān)心作弊，學(xué)校積極勸阻學(xué)生使用ChatGPT和Copilot等AI技術(shù)。這阻止了學(xué)生學(xué)習(xí)如何使用AI技術(shù)來增強(qiáng)他們的工作并有效地脫穎而出。因?yàn)閷W(xué)校以負(fù)面的眼光描繪人工智能技術(shù)，好學(xué)的學(xué)生害怕使用它，而尋找避免做作業(yè)的方法的學(xué)生更有可能使用人工智能。上面提到的挑戰(zhàn)為我們提供了在實(shí)施CNAI系統(tǒng)時(shí)關(guān)注的領(lǐng)域的洞察力。幸運(yùn)的是，CN工具正面臨著許多挑戰(zhàn)。我們接下來考慮來自這些挑戰(zhàn)的機(jī)遇。WHITEPAPER|云人工智能云本土人工智能前進(jìn)的道路本節(jié)提供了一個(gè)前瞻性的方法來主動(dòng)實(shí)施CNAI。我們從建議（或行動(dòng)）開始，然后列舉現(xiàn)有但不斷發(fā)展的解決方案（即CNAI軟件最后考慮進(jìn)一步發(fā)展的機(jī)會(huì)。建議靈活性從用于接口的REST接口到基于云的資源和服務(wù),CN技術(shù)今天運(yùn)行良好,并將隨著新產(chǎn)品的發(fā)展而繼續(xù)運(yùn)行?？沙掷m(xù)性改善AI工作量環(huán)境影響的問責(zé)制對于生態(tài)可持續(xù)性至關(guān)重要，特別是在云原生景觀中。這可以通過支持項(xiàng)目、方法和分類法來實(shí)現(xiàn)，這些項(xiàng)目、方法和分類法有助于澄清、分類和催化AI工作量對生態(tài)可持續(xù)性的影響。此外，集成云原生技術(shù)以優(yōu)化AI工作負(fù)載調(diào)度、自動(dòng)擴(kuò)展和調(diào)優(yōu)是必要的。此外，倡導(dǎo)在環(huán)境影響評估中采用標(biāo)準(zhǔn)化方法至關(guān)重要。同樣重要的是，主要通過Kbeflow等云原生堆棧來促進(jìn)節(jié)能AI模型的開發(fā)和使用，并提高模型開發(fā)和使用的透明度。最后，強(qiáng)調(diào)有目的和有效使用人工智能的重要性將有助于最大限度地減少不必要的計(jì)算負(fù)荷。自定義平臺(tái)依賴項(xiàng)我們建議確保CloudNative環(huán)境具有所需的GPU驅(qū)動(dòng)程序，并支持針對AI工作負(fù)載的GPU加速。這一點(diǎn)至關(guān)重要，因?yàn)锳I應(yīng)用程序通常依賴于特定的框架和庫版本，這些版本可能無法輕松訪問或與標(biāo)準(zhǔn)容器映像兼容。這將有助于應(yīng)對擁有各種供應(yīng)商和GPU架構(gòu)的挑戰(zhàn)。參考實(shí)施考慮到AI開發(fā)中涉及的工具的數(shù)量和復(fù)雜性，建議考慮基于ClodNative，基于OpeTof的各種工具的用戶友好組合的參考實(shí)現(xiàn)的價(jià)值，這些工具可以為世界各地的任何團(tuán)隊(duì)提供類似產(chǎn)品的體驗(yàn)，以便快速開始在云中進(jìn)行AI/ML。結(jié)合用于數(shù)據(jù)準(zhǔn)備、功能存儲(chǔ)、培訓(xùn)、調(diào)優(yōu)、模型注冊和服務(wù)的最佳可用開源工具，可以幫助團(tuán)隊(duì)快速開始進(jìn)行機(jī)器學(xué)習(xí)，并利用云的強(qiáng)大功能有效地?cái)U(kuò)展工作。考慮將一套復(fù)雜的技術(shù)組合成一個(gè)功能和可擴(kuò)展的分布的價(jià)值/力量。（例如JupyterLab，Kubeflow，PyTorch，Spark/Ray/Trino，Iceberg，F(xiàn)east，MLFlow，Yunikorn，EKS/GKE,S3/GCS等）。這樣的參考實(shí)現(xiàn)對于推進(jìn)基于云的技術(shù)的開放和負(fù)責(zé)任的AIML開發(fā)可能非常有價(jià)值。WHITEPAPER|云人工智能行業(yè)接受術(shù)語隨著人工智能變得無處不在，它在某些方面變得越來越復(fù)雜，但在其他方面變得更簡單。例如，術(shù)語演變，為企業(yè)提供了更輕松的關(guān)于人工智能的對話(例如，“重新利用”來重用現(xiàn)有內(nèi)容等術(shù)語)。這也適用于更多的技術(shù)術(shù)語，如RAG、理性和精煉。AI/ML的演進(jìn)解決方案以下只是一些特定工具或技術(shù)的示例，這些工具或技術(shù)已成為啟用AI（包括CNAI）的選項(xiàng)。業(yè)務(wù)流程-KubeflowKubeflow是支持MLOperations(MLOps)的CNAI工具的一個(gè)例子。使用Kubernetes、無狀態(tài)架構(gòu)和分布式系統(tǒng)等技術(shù),Kubeflow幫助AI/ML社區(qū)更有效地采用ClodNative工具。Kbeflow的成功采用凸顯了ClodNative技術(shù)在AI/ML/DL中的成功集成。Kbeflow在將機(jī)器學(xué)習(xí)概念應(yīng)用于Kberetes提供的彈性基礎(chǔ)的能力方面一直非常進(jìn)步，許多其他項(xiàng)目也遵循了這一要求。72Kbeflow遵循Kberetes最佳實(shí)踐，并將其應(yīng)用于AI/ML空間，例如聲明性API，可組合性和可移植性。Kbeflow為ML生命周期的每個(gè)階段實(shí)現(xiàn)了單獨(dú)的微服務(wù)。例如，使用KbeflowTraiigOperator。對于分布式訓(xùn)練，Katib用于超參數(shù)調(diào)優(yōu)微調(diào)，KubeflowKServe用于模型服務(wù)。這允許用戶將單個(gè)Kubeflow組件集成到他們的ML基礎(chǔ)設(shè)施中或使用Kubeflow作為端到端ML平臺(tái)。上下文-向量數(shù)據(jù)庫LLM在某個(gè)時(shí)間點(diǎn)使用大量的，通常是公開可用的數(shù)據(jù)進(jìn)行訓(xùn)練。我們通過提示與他們進(jìn)行交互。但是為了使響應(yīng)更有價(jià)值，而無需用戶輸入更長或更多的提示并可能檢索更多特定領(lǐng)域的響應(yīng)，“豐富”是有幫助的提示。這是矢量數(shù)據(jù)庫的來源。它們是矢量的巨大索引存儲(chǔ)，是數(shù)字形式的數(shù)據(jù)的數(shù)學(xué)表示。嵌入是每個(gè)附加數(shù)據(jù)的特定矢量表示形式，通常是專有的，特定于領(lǐng)域的或更新的，旨在捕獲關(guān)系和相似性(context)它們表示的數(shù)據(jù)之間。用戶提供的LLM提示使用向量數(shù)據(jù)庫使用的相同嵌入進(jìn)行轉(zhuǎn)換,然后使用結(jié)果向量在數(shù)據(jù)庫中查找相似向量。然后將它們合并以提供額外的上下文多模式GenAI系統(tǒng)將處理可能是文本、圖像、音頻或其他的提示，并具有處理不同輸入的嵌入能矢量數(shù)據(jù)庫可以是專門構(gòu)建的數(shù)據(jù)庫，也可以是具有擴(kuò)展功能的傳統(tǒng)數(shù)據(jù)庫，以更具體地處理矢量。實(shí)例在選擇索引方案，用于計(jì)算相似性的距離度量以及它們是否采用以及采用什么數(shù)據(jù)壓縮技術(shù)方面可能會(huì)有所不同。一些產(chǎn)品包括Redis，73Milvus，74Faiss，75和Weaviat.76可觀測性-OpenLLMetryOpeLLMetry77是一個(gè)構(gòu)建在OpeTelemetry78之上的項(xiàng)目，旨在為LLM可觀測性提供徹底和供應(yīng)商中立的檢測。因?yàn)樯葾I在傳統(tǒng)意義上是不可調(diào)試的（i。Procedres.，您不能“只是逐步完成代碼”），開發(fā)人員必須轉(zhuǎn)向可觀察性工具和實(shí)踐，以隨著時(shí)間的推移改善他們對生成性AI的使用。這些數(shù)據(jù)通常也是評估和微調(diào)工作流程的來源。WHITEPAPER|云人工智能機(jī)會(huì)CNCF項(xiàng)目景觀包括CNCF，LFAI79和Data在內(nèi)的多個(gè)LinuxFoundation（LF）小組以及AIAlliance等合作伙伴80以上，為AI和云工程師都可以使用的AI項(xiàng)目提供了一個(gè)樞紐?，F(xiàn)有工具，例如CloudNativeLandscape，81可以鳥瞰CN生態(tài)系統(tǒng)。下圖列出了按功能區(qū)域分組的已建立和正在發(fā)展的項(xiàng)目。ML工具任務(wù)思維導(dǎo)圖WHITEPAPER|云人工智能CNAI兒童和學(xué)生孩子們已經(jīng)每天使用像ChatGPT這樣的AI輔助技術(shù)，不知道它們是如何工作的?，F(xiàn)代人工智能的基礎(chǔ)，如辨別和生成人工智能算法，是一個(gè)孩子甚至技術(shù)精湛的父母都不理解的黑匣子，所以很難對它產(chǎn)生興趣。學(xué)生的教育不僅應(yīng)將ChatGPT之類的LLM視為理所當(dāng)然，還應(yīng)包括神經(jīng)網(wǎng)絡(luò)和機(jī)器學(xué)習(xí)算法的基礎(chǔ)知識(shí)，以解釋AI技術(shù)的工作原理以及如何在未來的職業(yè)生涯中更好地使用它們。ClodNative社區(qū)和KbeCo的CNCFKidsDay82等成功計(jì)劃提供了有關(guān)ClodNative和AI技術(shù)的教育機(jī)會(huì)。盡早向孩子們介紹AI技術(shù)也將防止困擾計(jì)算機(jī)科學(xué)的多樣性，公平性和包容性問題。AI是一種平等的技術(shù)，因?yàn)槊總€(gè)種族，性取向和社會(huì)經(jīng)濟(jì)地位的人都可以每天體驗(yàn)AI/ML，并通過適當(dāng)?shù)呐嘤?xùn)和教育幫助改進(jìn)這項(xiàng)技術(shù)。AI/ML革命類似于互聯(lián)網(wǎng)時(shí)代，在互聯(lián)網(wǎng)時(shí)代，網(wǎng)絡(luò)技術(shù)變得無處不在，甚至普通工人也接受了這項(xiàng)技術(shù)來改善他們的業(yè)務(wù)。隨著AI/ML技術(shù)在社會(huì)中無處不在，我們必須確保學(xué)生跟上AI和CloudNative技術(shù)的進(jìn)步。Participation隨著AI的發(fā)展，更多的教育和參與機(jī)會(huì)發(fā)生。有AI專家的空間（例如。Procedre,Ph.D.在ML中對數(shù)據(jù)科學(xué)家)和AI通才(例如Procedre、運(yùn)營商和最終用戶)。MOOCs83和認(rèn)證等教育項(xiàng)目已經(jīng)出現(xiàn)，專注于各個(gè)方面的AI工具和技術(shù)。專業(yè)社團(tuán)（e。Procedre，ACM84和IEEE85）和聚會(huì)提供了面對面學(xué)習(xí)和討論挑戰(zhàn)的機(jī)會(huì)。CNCF，86以及LixFodatioAI，AIAlliace，87等行業(yè)組織提供了大規(guī)模協(xié)調(diào)項(xiàng)目和協(xié)議的能力。信任和安全/設(shè)計(jì)安全當(dāng)我們構(gòu)建AI和云原生技術(shù)時(shí)，存在意外后果和負(fù)面影響的重大風(fēng)險(xiǎn)。這些可能是由于無意的設(shè)計(jì)問題對弱勢群體造成不利影響，例如，推薦算法無意中推廣基于仇恨、暴力、極端主義的材料。它們也可能是由于個(gè)人或團(tuán)體惡意使用系統(tǒng)和/或工具來故意傷害，例如使用生成性AI工具來創(chuàng)建錯(cuò)誤信息和虛假信息活動(dòng)，或者個(gè)人故意將LLM精細(xì)起來以產(chǎn)生兒童性虐待材料。AI和ClodNative技術(shù)也是TrstadSafety使用的工具的核心：“數(shù)字服務(wù)用于管理內(nèi)容并對用戶和他人進(jìn)行風(fēng)險(xiǎn)掃描，減輕在線或其他形式的技術(shù)促進(jìn)濫用，倡導(dǎo)用戶權(quán)利并保護(hù)品牌安全的領(lǐng)域和實(shí)踐?！耙呀?jīng)建立了89個(gè)系統(tǒng)來提供信任和安全周期的每個(gè)部分，包括識(shí)別和評估潛在的暴力行為，對案件進(jìn)行分類和優(yōu)先排序，制定和記錄執(zhí)法決策，選擇和應(yīng)用干預(yù)措施以及收集威脅情報(bào)。除了對互聯(lián)網(wǎng)的安全和健康至關(guān)重要之外，如果在設(shè)計(jì)時(shí)沒有適當(dāng)考慮，這些系統(tǒng)可能會(huì)產(chǎn)生重大的負(fù)面影響。負(fù)責(zé)任的技術(shù)是減少技術(shù)的危害，使技術(shù)管道多樣化，并確保技術(shù)符合公共利益。它探索并積極考慮技術(shù)的價(jià)值，意外后果和負(fù)面影響，以管理和減輕風(fēng)險(xiǎn)和傷害。在構(gòu)建AI和ClodNative技術(shù)時(shí)，我們必須考慮這些潛在的道德和人權(quán)影響。WHITEPAPER|云人工智能優(yōu)化言論自由、隱私權(quán)、生命權(quán)、自由權(quán)和人身安全權(quán)，91和其他基本普遍人權(quán)。世界經(jīng)濟(jì)論壇指出：“設(shè)計(jì)安全將用戶安全和權(quán)利置于在線產(chǎn)品和服務(wù)的設(shè)計(jì)和開發(fā)的中心?！?2這種主動(dòng)和預(yù)防性的方法側(cè)重于將安全嵌入到組織的文化和領(lǐng)導(dǎo)中。它強(qiáng)調(diào)問責(zé)制，旨在為每個(gè)人培養(yǎng)更積極，文明和獎(jiǎng)勵(lì)的在線體驗(yàn)。有越來越多的專家來幫助這些發(fā)展最佳做法，例如全球反恐互聯(lián)網(wǎng)論壇（GIFCT），93技術(shù)聯(lián)盟，94和互聯(lián)網(wǎng)協(xié)會(huì)。95AllTech是該領(lǐng)域的人類專家名單，可以提供與關(guān)鍵資源的鏈接。96AIAlliace97計(jì)劃（IBM，Meta和50多個(gè)機(jī)構(gòu)）專注于推進(jìn)AI的開放式創(chuàng)新和科學(xué)，以提出封閉式AI系統(tǒng)的替代方案，并推進(jìn)負(fù)責(zé)任的AI領(lǐng)域（道德，信任，安全）。OpeAI是ChatGPT背后的組織，最初是一家非營利性組織，致力于保證AI的安全性和公平性。一門新的工程學(xué)科的出現(xiàn)在過去的二十年中，我們已經(jīng)看到科技行業(yè)如何根據(jù)他們的職責(zé)迅速創(chuàng)造和改變工程工作角色。我們見證了DevOps工程師、SRE工程師和基礎(chǔ)設(shè)施工程師等角色的崛起。我們預(yù)計(jì)MLDevOps或AI工程師將在未來幾個(gè)月或幾年內(nèi)成為數(shù)據(jù)科學(xué)、基礎(chǔ)設(shè)施和開發(fā)之間的粘合劑。重要的是要知道這個(gè)行業(yè)領(lǐng)域正在發(fā)展，角色頭銜可能會(huì)波動(dòng)；只有時(shí)間才能證明。不同的術(shù)語也可能成為現(xiàn)實(shí)。將來，該角色將需要更多地關(guān)注AI工具，以及部署AI鏈和代理。WHITEPAPER|云人工智能CLOUDNATIVE的人工智能本文主要關(guān)注支持AI開發(fā)和使用的ClodNative。但AI可以通過多種方式增強(qiáng)ClodNative，包括預(yù)測負(fù)載和更好的資源調(diào)度，特別是涉及多個(gè)優(yōu)化標(biāo)準(zhǔn)，例如節(jié)能、提高資源利用率、減少延遲、尊重優(yōu)先級、增強(qiáng)安全性、理解日志和跟蹤等用于群集控制的自然語言接口在202399年芝加哥的ClodNativeAI+HPCDay上，演示了具有自然語言界面的Kberetes控制器來處理與集群相關(guān)的任務(wù)。它在該后端使用了LLM，該LLM理解了用戶請求并將其轉(zhuǎn)換為KberetesAPI調(diào)用。它還支持啟動(dòng)混沌測試，以確定服務(wù)彈性，掃描CVE等。它是Kberetes集群更直觀的編排和管理的先驅(qū)，并及時(shí)降低了管理員和站點(diǎn)可靠性工程師的學(xué)習(xí)曲線。安全機(jī)器學(xué)習(xí)可以分析大量數(shù)據(jù)集，以快速識(shí)別模式并預(yù)測系統(tǒng)中的潛在威脅或弱點(diǎn)。將AI集成到Redteamig100中可以加速識(shí)別安全漏洞，并使組織能夠加強(qiáng)對新興網(wǎng)絡(luò)威脅的防御。檢測異常網(wǎng)絡(luò)行為的ML模型可以輕松地用于集群中，以保護(hù)工作負(fù)載，或用于邊緣部署的集群隊(duì)列。更智能的編排/調(diào)度AI可以分析日/周/月的歷史集群使用情況，以識(shí)別工作負(fù)載模式和資源可用性，了解何時(shí)以及如何部署工作負(fù)載，是水平擴(kuò)展還是垂直