人工智能行業(yè)：云原生人工智能白皮書

CNCFAI工作組云本土人工智能AuthorsAdelZaaloukAlexJonesAndreyVelichkevichBorisKurktchievCassandraChinCathyZhangClaudiaMisaleHuaminChenJoelRobertsKai-HsunChenMaliniBhandaruMichaelYaoNikhitaRaghunath彼得潘RajasKakodkarRasikPandeyRicardoAravenaRonaldPettyRyanTaylorSaadSheikhShawnWilsonTomThorleyVictorLu已發(fā)布3月20,2024（第1版）執(zhí)行摘要云原生（CN）和人工智能（AI）是當(dāng)今最關(guān)鍵的技術(shù)趨勢(shì)。ClodNative1技術(shù)為運(yùn)行應(yīng)用程序提供了可擴(kuò)展且可靠的平臺(tái)。鑒于AI和機(jī)器學(xué)習(xí)（ML）的最新進(jìn)展，它作為主要的云工作負(fù)載正在穩(wěn)步上升。雖然CN技術(shù)很容易支持AI/ML工作負(fù)載的某些方面，但挑戰(zhàn)和差距仍然存在，為創(chuàng)新和更好地適應(yīng)提供了機(jī)會(huì)。本文簡(jiǎn)要概述了最先進(jìn)的AI/ML技術(shù)，其次是CN技術(shù)提供的內(nèi)容，在討論不斷發(fā)展的解決方案之前涵蓋了下一個(gè)挑戰(zhàn)和差距。本文將為工程師和業(yè)務(wù)人員提供知識(shí)，以了解不斷變化的云原生人工智能（CNAI）生態(tài)系統(tǒng)及其機(jī)遇。我們建議閱讀路徑取決于讀者的背景和興趣。假設(shè)暴露于微服務(wù)2和CN技術(shù)3，如Kberetes(K8s)。對(duì)于那些沒(méi)有工程AI系統(tǒng)經(jīng)驗(yàn)的人，我們建議從頭到尾閱讀。對(duì)于那些在AI/ML采用或交付過(guò)程中走得更遠(yuǎn)的人，根據(jù)他們的用戶角色4，我們建議深入到與他們正在努力解決或有興趣解決的挑戰(zhàn)相關(guān)的部分。我們還分享社會(huì)在這方面需要投資的地方。WHITEPAPER2WHITEPAPERWHITEPAPER內(nèi)容表云原生(CN)04的出現(xiàn)人工智能進(jìn)化(AI)05結(jié)束注釋28云人工智能(CNAI)簡(jiǎn)介在我們進(jìn)入CNAI之前，將CloudNative和AI技術(shù)結(jié)合在一起，讓我們簡(jiǎn)要地研究一下每種技術(shù)的演變。云原生的出現(xiàn)自2013年以來(lái)廣為人知，5隨著容器技術(shù)從LXC6到Docer7再到Kberetes（K8s）的興起，ClodNative（CN）一詞越來(lái)越受歡迎8如今，ClodNative更廣泛地成為使用微服務(wù)設(shè)計(jì)模式構(gòu)建的平衡系統(tǒng)的理想目標(biāo)，該模式可促進(jìn)模塊化設(shè)計(jì)和開(kāi)發(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ù)測(cè)地進(jìn)行高影響的更改。云原生計(jì)算基金會(huì)尋求通過(guò)培育和維持一個(gè)開(kāi)源、供應(yīng)商中立的項(xiàng)目生態(tài)系統(tǒng)來(lái)推動(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ù)的味道，便于訪問(wèn)基礎(chǔ)設(shè)施和一系列支持服務(wù)來(lái)運(yùn)行各種工作負(fù)載，包括AI/ML。WHITEPAPER4人工智能的進(jìn)化人工智能，最早在1956年被稱為一個(gè)術(shù)語(yǔ)，12是機(jī)器模擬人類智能的能力。幾十年來(lái)，它已被用于語(yǔ)音識(shí)別，機(jī)器翻譯，圖像處理，游戲等應(yīng)用，甚至是作為危險(xiǎn)玩家的出色表現(xiàn)。13但是，由于人工神經(jīng)網(wǎng)絡(luò)和深度學(xué)習(xí)的創(chuàng)新，人工智能最近在midshare中爆發(fā)了，主要應(yīng)用于自然語(yǔ)言理解。AI有兩種主要分類：判別性和生成性。判別式AI尋求學(xué)習(xí)決策邊界或分類，將知識(shí)捕獲為“模型”,用于預(yù)測(cè)新數(shù)據(jù)。例如，將電子郵件分類為垃圾郵件，區(qū)分貓和狗的圖像等等。判別AI通常用于已知所需輸出的任務(wù)（例如Procedre，通過(guò)監(jiān)督學(xué)習(xí)，一種機(jī)器學(xué)習(xí)的形式)。人工智能擅長(zhǎng)序列預(yù)測(cè)，例如，通過(guò)分析大量現(xiàn)有文本，包括我們的個(gè)人寫作風(fēng)格，以高概率猜測(cè)我們接下來(lái)要輸入的內(nèi)容。卷積神經(jīng)網(wǎng)絡(luò)14（CNN）最初是在1980年代開(kāi)發(fā)的，但直到21世紀(jì)初才被廣泛使用。近年來(lái)，由于它們能夠從圖像的大型數(shù)據(jù)集中進(jìn)行學(xué)習(xí)，并在各種圖像處理任務(wù)（例如對(duì)象檢測(cè)，圖像分類和分割）上表現(xiàn)良好，CNN變得越來(lái)越受歡迎。生成AI學(xué)習(xí)數(shù)據(jù)中的潛在結(jié)構(gòu)或表示。它可以使用這些結(jié)構(gòu)或表示來(lái)合成新數(shù)據(jù)，例如創(chuàng)建故事，音樂(lè)和視覺(jué)藝術(shù)來(lái)自單詞提示。生成性AI用于所需輸出未知或“正確”輸出定義不明確的任務(wù)。使用生成性AI，AI已經(jīng)超越了人類認(rèn)為的創(chuàng)造性，原創(chuàng)性和崇高性。讓我們仔細(xì)看看AI的一些驚人突破。變壓器由多倫多大學(xué)和谷歌的研究人員于2017年開(kāi)發(fā)。變形金剛使用一種稱為縮放點(diǎn)積注意力的專門機(jī)制，該機(jī)制使它們充滿了類似記憶的結(jié)構(gòu)。15基于變形金剛的模型對(duì)于自然語(yǔ)言處理任務(wù)非常有效，例如回答問(wèn)題，總結(jié)文本和翻譯。因此，它們?cè)诖蠖鄶?shù)大型語(yǔ)言模型（LLM)中至關(guān)重要。最著名的LLM是GPT，該模型為流行的ChatGPT服務(wù)提供動(dòng)力。WHITEPAPERLLM是在海量數(shù)據(jù)集上訓(xùn)練的。除了能夠針對(duì)具有額外數(shù)據(jù)的專業(yè)領(lǐng)域進(jìn)行微調(diào)之外，它們還采取可能很長(zhǎng)的提示序列來(lái)生成上下文敏感的響應(yīng)，無(wú)論是時(shí)事，醫(yī)學(xué)，法律還是其他。用于微調(diào)的新技術(shù)，例如來(lái)自人類反饋的強(qiáng)化學(xué)習(xí)（RLHF）和直接偏好優(yōu)化（DPO），已經(jīng)被開(kāi)發(fā)出來(lái)，以使LLM更具吸引力。研究和創(chuàng)新使最終用戶的交互比以往任何時(shí)候都更快，更有創(chuàng)造力，更準(zhǔn)確。與數(shù)據(jù)科學(xué)和軟件的創(chuàng)新一樣重要的是基礎(chǔ)設(shè)施的發(fā)展模型推理（從AI模型計(jì)算結(jié)果的過(guò)程）和模型訓(xùn)練（從數(shù)據(jù)構(gòu)建AI模型的過(guò)程）。使用AI加速器技術(shù)，人工智能從業(yè)者可以更快地迭代，以在幾天和幾周內(nèi)提供更高質(zhì)量的模型，而不是幾個(gè)月。此外，數(shù)據(jù)科學(xué)家和統(tǒng)計(jì)學(xué)家采用的幾種傳統(tǒng)技術(shù)正在重新評(píng)估，以利用CN系統(tǒng)的功能。云原生與人工智能的融合正如上一節(jié)所述，人工智能是一個(gè)更廣泛的概念，旨在創(chuàng)建可以執(zhí)行類似于人類任務(wù)的系統(tǒng)。機(jī)器學(xué)習(xí)是一種基于數(shù)據(jù)進(jìn)行學(xué)習(xí)并做出明智預(yù)測(cè)和決策的方法。它可以被認(rèn)為是另一種形式的自動(dòng)化，涉及使用算法來(lái)學(xué)習(xí)和改進(jìn)，而無(wú)需顯式編程。最后，數(shù)據(jù)科學(xué)作為一個(gè)多學(xué)科領(lǐng)域，融合了統(tǒng)計(jì)學(xué)，數(shù)學(xué)和計(jì)算機(jī)科學(xué)的技術(shù)來(lái)制定。廣泛的活動(dòng)，從數(shù)據(jù)分析和解釋到機(jī)器學(xué)習(xí)算法的應(yīng)用。從廣義上講，我們可以將AI，ML和數(shù)據(jù)科學(xué)的應(yīng)用程序分為兩大類：預(yù)測(cè)性AIand生成AI。預(yù)測(cè)性AI旨在預(yù)測(cè)和分析現(xiàn)有模式或結(jié)果（例如，分類，聚類，回歸，對(duì)象檢測(cè)等）。相比之下，生成AI旨在生成新的和原始的內(nèi)容（例如，LLM，RAG17等）。因此，支持預(yù)測(cè)性和生成AI的算法和技術(shù)可能會(huì)有很大差異。WHITEPAPER以下是預(yù)測(cè)和生成AI在計(jì)算、網(wǎng)絡(luò)和存儲(chǔ)方面有不同需求的一組示例：挑戰(zhàn)/需求生成AI預(yù)測(cè)性AI計(jì)算型Power需要專門的硬件。中等到高。通用硬件就足夠了。數(shù)據(jù)量和多樣性用于培訓(xùn)的大量、多樣化的數(shù)預(yù)測(cè)的具體歷史數(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ù)訪問(wèn)。高效存儲(chǔ)，吞吐量適中。它更側(cè)重于數(shù)據(jù)分析，而不是數(shù)據(jù)生成；數(shù)據(jù)主要是結(jié)構(gòu)化的。聯(lián)網(wǎng)用于數(shù)據(jù)傳輸和模型同步(例如,在分布式訓(xùn)練期間)的高帶寬和低延遲。數(shù)據(jù)訪問(wèn)的一致可靠連接。在接下來(lái)的部分中，我們將探討如何滿足這兩種形式所產(chǎn)生的需求，隨之而來(lái)的挑戰(zhàn)，以及在面對(duì)這些挑戰(zhàn)時(shí)可能提出的建議。什么是云原生人工智能？云原生人工智能允許構(gòu)建實(shí)用的系統(tǒng)來(lái)部署、運(yùn)行和擴(kuò)展AI工作負(fù)載。CNAI解決方案解決了AI應(yīng)用科學(xué)家、開(kāi)發(fā)人員和部署人員在云基礎(chǔ)設(shè)施上開(kāi)發(fā)、部署、運(yùn)行、擴(kuò)展和監(jiān)控AI工作負(fù)載時(shí)面臨的挑戰(zhàn)。通過(guò)利用底層云基礎(chǔ)設(shè)施的計(jì)算(例如Procedre，CPU和GPU），網(wǎng)絡(luò)和存儲(chǔ)功能，以及提供隔離和受控共享機(jī)制，可加速AI應(yīng)用程序性能并降低成本。圖2（下圖）在工具和技術(shù)之間映射了這些啟用機(jī)制。WHITEPAPER7啟用工具和技術(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)，容器是輕量級(jí)、可移植、自包含的軟件單元，AI模型可以打包成容器然后部署到K8s集群。容器化對(duì)于AI模型尤其重要，因?yàn)椴煌哪Ｐ屯ǔＰ枰煌彝ǔＯ嗷_突的依賴關(guān)系。在容器中隔離這些依賴關(guān)系可以在模型部署中提供更大的靈活性。CN工具允許AI模型的高效和可擴(kuò)展部署，并不斷努力為AI工作負(fù)載定制這些模型。WHITEPAPERKubernetesScheduler21繼續(xù)發(fā)展，2223特別是為了更好地集成和支持共享圖形處理單元(GPU)，這些圖形處理單元在加速AI工作負(fù)載方面變得非常流行。除了支持共享GPU和處理多租戶的應(yīng)用程序之外，還在努力支持利用Kubernetes之外的遠(yuǎn)程資源池。需要高質(zhì)量的數(shù)據(jù)來(lái)訓(xùn)練和測(cè)試AI模型，以獲得卓越的推理。云原生基礎(chǔ)設(shè)施可以通過(guò)各種方法訪問(wèn)數(shù)據(jù)，例如數(shù)據(jù)湖和倉(cāng)庫(kù)。許多云提供商提供塊、對(duì)象和文件存儲(chǔ)系統(tǒng)，非常適合提供低成本、可擴(kuò)展的存儲(chǔ)。例如，模型的大小可以達(dá)到千兆字節(jié)。在訓(xùn)練階段，每次拉取模型的檢查點(diǎn)都會(huì)導(dǎo)致網(wǎng)絡(luò)和存儲(chǔ)帶寬的嚴(yán)重負(fù)載。將模型視為容器化的工件為在OCI24注冊(cè)表中托管它們打開(kāi)了大門，并啟用了緩存。它進(jìn)一步允許應(yīng)用。軟件供應(yīng)鏈模型的最佳實(shí)踐，例如工件簽名,驗(yàn)證，證明和數(shù)據(jù)來(lái)源。此外，容器化模型/工件促進(jìn)了WebAssembly(WASM)二進(jìn)制文件的捆綁。WASM是一種獨(dú)立于平臺(tái)的高效CN推理方法。為什么選擇云原生人工智能？憑借其彈性，始終在線的基礎(chǔ)架構(gòu)，云允許企業(yè)，初創(chuàng)公司和開(kāi)發(fā)人員快速原型，提供新服務(wù)，擴(kuò)展解決方案等等。它還通過(guò)憑借其彈性，始終在線的基礎(chǔ)架構(gòu)，云允許企業(yè)，初創(chuàng)公司和開(kāi)發(fā)人員快速原型，提供新服務(wù)，擴(kuò)展解決方案等等。它還通過(guò)資源共享實(shí)現(xiàn)了成本效益。普通用戶不再需要擔(dān)心訂購(gòu)硬件或處理空間、電源、網(wǎng)絡(luò)連接、冷卻、軟件許可和安裝等物流問(wèn)題。人工智能也有類似的擔(dān)憂——快速原型設(shè)計(jì)、訪問(wèn)存儲(chǔ)、網(wǎng)絡(luò)和計(jì)算資源，以解決小型和大規(guī)模的訓(xùn)練和推理任務(wù)。使用AI改進(jìn)云原生系統(tǒng)無(wú)論是打包為可觀察性工具還是利用LLM功能進(jìn)行日志的自然語(yǔ)言處理（NLPAI驅(qū)動(dòng)的解決方案/項(xiàng)目都在進(jìn)入運(yùn)營(yíng)商和最終用戶的手中，以提高他們的生產(chǎn)力并使他們的生活更輕松。一個(gè)這樣的開(kāi)源云原生計(jì)算基金會(huì)(CNCF）項(xiàng)目是K8sGPT，它利用LLM的模式識(shí)別和語(yǔ)言功能，如Bedroc，Cohere等，以幫助K8s運(yùn)營(yíng)商。日常工作。更重要的是，CN和AI的共生為新的和不可預(yù)見(jiàn)的機(jī)會(huì)打開(kāi)了生態(tài)系統(tǒng)。例如，我們預(yù)計(jì)能夠操作和管理復(fù)雜系統(tǒng)的技術(shù)含量較低的用戶將會(huì)增加。WHITEPAPER云人工智能的挑戰(zhàn)重要的是要注意，CNAI的挑戰(zhàn)在不同的角色之間會(huì)有所不同。26而且，盡管ClodNative的靈活，可擴(kuò)展的平臺(tái)非常適合AI工作負(fù)載，但AI的規(guī)模和延遲需求帶來(lái)了挑戰(zhàn)，并暴露了CN技術(shù)中的差距，同時(shí)也帶來(lái)了機(jī)會(huì)。我們?cè)诙说蕉薓L流水線的背景下梳理這些內(nèi)容。27在文獻(xiàn)中也稱為MLOps.28傳統(tǒng)的時(shí)間和空間，并行性和同步權(quán)衡的問(wèn)題都存在，暴露了易于使用的差距?？偠灾琈L生命周期如下所示：周期典型的ML管道包括：?數(shù)據(jù)準(zhǔn)備（收集、清洗/預(yù)處理、特征工程）?模型訓(xùn)練（模型選擇、架構(gòu)、超參數(shù)調(diào)優(yōu)）?CI/CD,模型注冊(cè)表（存儲(chǔ)）?模型服務(wù)?可觀察性（使用負(fù)載、模型漂移、安全性）訓(xùn)練、相似性搜索和模型大?。ㄌ貏e是LLM）中涉及的數(shù)據(jù)量，每個(gè)驅(qū)動(dòng)器內(nèi)存和性能方面的考慮因素。雖然CN處理CPU的訪問(wèn)控制和調(diào)度，但具有充分共享的GPU分配仍在不斷發(fā)展。ML訓(xùn)練階段涉及搜索，需要跟蹤中間模型的性能，以確定要保留哪些模型以及如何進(jìn)一步調(diào)整模型參數(shù)以獲得更高的準(zhǔn)確性?？紤]到處理數(shù)據(jù)的敏感性和模型的內(nèi)在價(jià)值，安全性更為重要?？捎^察性對(duì)于檢測(cè)模型漂移、使用負(fù)載等至關(guān)重要。讓我們更深入地探討每個(gè)管道階段的挑戰(zhàn)。鼓勵(lì)讀者考慮與其領(lǐng)域相關(guān)的其他挑戰(zhàn)，并添加到對(duì)話中。數(shù)據(jù)準(zhǔn)備作為AI/ML管道的第一階段，數(shù)據(jù)準(zhǔn)備可能會(huì)帶來(lái)各種挑戰(zhàn)。這些可以大致分為三大類：管理大數(shù)據(jù)大小，確保開(kāi)發(fā)和部署期間的數(shù)據(jù)同步以及遵守?cái)?shù)據(jù)治理策略。WHITEPAPER數(shù)據(jù)大小構(gòu)建更好的AI/ML模型的數(shù)據(jù)需求增長(zhǎng)速度快于摩爾定律，每18個(gè)月翻一番。30無(wú)論是數(shù)據(jù)管理/處理、數(shù)據(jù)處理還是數(shù)據(jù)分析，構(gòu)建AI/ML模型的數(shù)據(jù)需求都在快速升級(jí)。因此，分布式CloudNative計(jì)算和高效的數(shù)據(jù)移動(dòng)和存儲(chǔ)對(duì)于彌合這些計(jì)算需求和硬件能力之間的差距至關(guān)重要。數(shù)據(jù)同步數(shù)據(jù)可能需要以不同的格式從多個(gè)不同的位置獲得；開(kāi)發(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)重要的作用，無(wú)論他們是在本地制作原型還是以分布式方式運(yùn)行大型工作負(fù)載。但是，ML工作負(fù)載沒(méi)有行業(yè)標(biāo)準(zhǔn)接口。因此，數(shù)據(jù)科學(xué)家在本地使用小數(shù)據(jù)集開(kāi)發(fā)他們的MLPytho腳本，然后分布式系統(tǒng)工程師重寫這些腳本以進(jìn)行分布式執(zhí)行。如果分布式ML工作負(fù)載未按預(yù)期運(yùn)行，數(shù)據(jù)科學(xué)家可能需要使用其本地Pytho腳本調(diào)試問(wèn)題。這個(gè)過(guò)程是低效的并且通常是無(wú)效的。盡管有更好的可觀察性工具和容器技術(shù)提供的可再現(xiàn)性,但這是真的。存在可能可行的解決方案來(lái)解決本地開(kāi)發(fā)和生產(chǎn)環(huán)境之間的這種不一致。首先是使用行業(yè)標(biāo)準(zhǔn)接口來(lái)支持端到端ML生命周期。例如，用戶可以利用PyTorch或TesorFlow等原生ML框架的API來(lái)創(chuàng)建訓(xùn)練代碼，并通過(guò)在Pytho運(yùn)行時(shí)本地運(yùn)行來(lái)驗(yàn)證它。然后，用戶可以輕松。重用相同的代碼并利用Kbeflow的PythoSDK通過(guò)Kid/Miibe以分布式方式在本地運(yùn)行此代碼，或者通過(guò)使用相同的PythoSDK將其部署到遠(yuǎn)程大型Kberetes集群來(lái)輕松擴(kuò)展其訓(xùn)練代碼。另一種選擇是使用通用分布式計(jì)算引擎，如Ray,其計(jì)算抽象還使用戶能夠在本地和生產(chǎn)環(huán)境中無(wú)縫運(yùn)行相同的Ray腳本。數(shù)據(jù)量是一個(gè)貫穿各領(lǐng)域的問(wèn)題，也體現(xiàn)在訓(xùn)練階段。數(shù)據(jù)治理數(shù)據(jù)治理對(duì)于建立信任和確保負(fù)責(zé)任的AI開(kāi)發(fā)至關(guān)重要。應(yīng)該考慮關(guān)于數(shù)據(jù)治理的三個(gè)關(guān)鍵支柱。1.隱私和安全：應(yīng)對(duì)GDPR31和CPA32等數(shù)據(jù)隱私法規(guī)的復(fù)雜環(huán)境至關(guān)重要。應(yīng)實(shí)施強(qiáng)有力的安全措施來(lái)保護(hù)人工智能模型中使用的敏感數(shù)據(jù)。應(yīng)使用加密、訪問(wèn)控制和定期漏洞評(píng)估來(lái)保護(hù)有價(jià)值的信息。2.所有權(quán)和譜系：必須明確定義從收集到使用的整個(gè)AI生命周期中誰(shuí)擁有和有權(quán)訪問(wèn)數(shù)據(jù)。應(yīng)使用數(shù)據(jù)沿襲跟蹤工具來(lái)了解數(shù)據(jù)如何通過(guò)系統(tǒng)流動(dòng)，確保透明度和問(wèn)責(zé)制。這樣做有助于防止對(duì)敏感信息的未經(jīng)授權(quán)的訪問(wèn)和濫用。WHITEPAPER3.緩解偏差:人工智能模型僅與所訓(xùn)練的數(shù)據(jù)一樣好。因此，必須積極監(jiān)控和解決數(shù)據(jù)和算法中的潛在偏差。這包括使用不同的數(shù)據(jù)集，采用公平性指標(biāo)，并不斷評(píng)估模型以確保其提供公平和道德的結(jié)果，包括捕獲其局限性。ModelCards33正在不斷發(fā)展以捕獲這些結(jié)果。數(shù)據(jù)隱私和安全是一個(gè)跨領(lǐng)域的問(wèn)題，需要在每個(gè)階段加以考慮。模型訓(xùn)練模型訓(xùn)練數(shù)據(jù)量呈指數(shù)級(jí)增長(zhǎng)，導(dǎo)致需要分布式處理和加速器來(lái)實(shí)現(xiàn)更多的并行性。進(jìn)一步的訓(xùn)練是一個(gè)迭代的多步驟過(guò)程，這使得擴(kuò)展成為一個(gè)復(fù)雜的多組件協(xié)調(diào)任務(wù)。我們?cè)诒竟?jié)中更詳細(xì)地回顧了這些方面。不斷上升的加工需求LLM正在迅速突破界限，以滿足不斷增長(zhǎng)的AI/ML訓(xùn)練和推理計(jì)算需求，加速器正在變得流行。這些范圍從多個(gè)供應(yīng)商的GPU與谷歌的張量處理單元（TPU），英特爾的高迪，甚至現(xiàn)場(chǎng)可編程門陣列（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（請(qǐng)參閱詞匯表）和動(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ù)框架來(lái)實(shí)現(xiàn)，該框架根據(jù)需求動(dòng)態(tài)調(diào)整資源。36KServe，37一個(gè)LFAI和DataFodatio項(xiàng)目，提供了這樣的功能。可持續(xù)能力38可以通過(guò)各種方式得到顯著改善,例如使用更小、更專業(yè)的模型、使用專家的混合以及諸如壓縮和蒸餾的技術(shù)。將ML服務(wù)分配到由可再生或更清潔能源提供動(dòng)力的地理區(qū)域可以顯著減少碳足跡。ML模型的負(fù)責(zé)任開(kāi)發(fā)可以包括有關(guān)碳足跡的元數(shù)據(jù)，以幫助跟蹤和報(bào)告模型排放對(duì)環(huán)境的影響。其他工具，例如mlco240and編解碼器41存在局限性，以幫助在體育鍛煉之前預(yù)測(cè)新神經(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)目通過(guò)利用容器化、微服務(wù)和可擴(kuò)展云基礎(chǔ)設(shè)施的固有特性，簡(jiǎn)化了AI工作負(fù)載的編排和調(diào)度。復(fù)雜的AI工作流可以分解為模塊化組件，從而更容易獨(dú)立管理和擴(kuò)展特定功能。但是，如前所述，GPU是一種寶貴的需求資源，能夠更有效地管理基于GPU的AI工作負(fù)載的共享和調(diào)度對(duì)于AI開(kāi)發(fā)團(tuán)隊(duì)的成功至關(guān)重要。用于解決高級(jí)調(diào)度需求（如裝箱，放置，資源爭(zhēng)用和搶占）的經(jīng)過(guò)良好測(cè)試的工具對(duì)于云原生AI的蓬勃發(fā)展至關(guān)重要。通過(guò)Yior，42Volcao，43和Kee，44后兩種解決批量調(diào)度的努力，更好的調(diào)度支持在Kberetes中不斷發(fā)展，這對(duì)于有效的AI/ML訓(xùn)練特別有價(jià)值。訓(xùn)練作業(yè)受益于gag（或組）調(diào)度，45因?yàn)閷儆谧鳂I(yè)的容器副本需要全有或全無(wú)放置策略才能正常運(yùn)行，并且這些作業(yè)不容易放大或縮小。幫派調(diào)度支持是一個(gè)機(jī)會(huì)領(lǐng)域。自定義依賴項(xiàng)AI應(yīng)用程序通常依賴于特定的框架和版本的庫(kù)，這些依賴關(guān)系可能無(wú)法輕易獲得或與標(biāo)準(zhǔn)容器映像兼容。由于許多AI工作負(fù)載受益于GPU加速，因此擁有必要的GPU驅(qū)動(dòng)程序和庫(kù)來(lái)支持在GPU上運(yùn)行的工作負(fù)載可能具有挑戰(zhàn)性，尤其是在與不同的供應(yīng)商和GPU架構(gòu)打交道時(shí)。例如,當(dāng)在NVIDIA設(shè)備上運(yùn)行分布式訓(xùn)練時(shí),可以使用NVIDIA集體通信庫(kù)(NCCL),以利用優(yōu)化的多GPU和多節(jié)點(diǎn)通信原語(yǔ)。不同版本的庫(kù)可能會(huì)導(dǎo)致不同的性能?？蓮?fù)制的構(gòu)建是所有軟件的良好構(gòu)建衛(wèi)生實(shí)踐，需要使用版本化的依賴關(guān)系來(lái)避免運(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ù)載需要來(lái)自ML基礎(chǔ)設(shè)施的各種支持。例如，在LLM出現(xiàn)之前，模型服務(wù)通常只需要一個(gè)GPU。如果工作負(fù)載對(duì)延遲不敏感，則一些用戶選擇基于CPU的推理。但是，當(dāng)服務(wù)LLM時(shí)，由于Trasformer解碼器的自回歸特性，性能瓶頸從計(jì)算綁定轉(zhuǎn)移到內(nèi)存綁定。46。WHITEPAPER本節(jié)探討CN如何支持這些方面以及仍然存在哪些挑戰(zhàn)。微服務(wù)架構(gòu)和開(kāi)發(fā)人員體驗(yàn)CN基于微服務(wù)架構(gòu)。然而，這可能對(duì)AI構(gòu)成挑戰(zhàn)，將ML管道中的每個(gè)階段作為單獨(dú)的微服務(wù)來(lái)處理。許多組件可能使保持和同步它們的輸出和切換具有挑戰(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模型生命周期中集成來(lái)自不同系統(tǒng)的每個(gè)階段時(shí)，成本會(huì)大大增加。Samsara工程博客47提到，它的ML生產(chǎn)管道托管在幾個(gè)微服務(wù)中，具有單獨(dú)的數(shù)據(jù)處理、模型推理和業(yè)務(wù)邏輯步驟。拆分基礎(chǔ)架構(gòu)涉及復(fù)雜的管理以同步資源，從而減慢了開(kāi)發(fā)和模型發(fā)布的速度。然后，使用Ray，Samsara構(gòu)建了一個(gè)統(tǒng)一的ML平臺(tái)。增強(qiáng)了他們的生產(chǎn)ML管道性能，為公司提供了近50%的年度ML推斷總成本，這主要源于資源共享和消除了各個(gè)階段的序列化和反序列化。這些問(wèn)題凸顯了對(duì)基于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í)也尋求共享推理框架以降低成本并獲得模型隔離。此外，對(duì)于彈性，他們希望在不同的故障區(qū)域中復(fù)制副本。Kberetes提供了親和力和反親和力機(jī)制來(lái)調(diào)度不同拓?fù)溆蛑械墓ぷ髫?fù)載（例如Procedre，zoe，ode52但可用性改進(jìn)可以幫助用戶利用這些功能。資源分配模型服務(wù)主要需要處理模型參數(shù)。參數(shù)的數(shù)量和表示大小指示所需的內(nèi)存。除非處理萬(wàn)億參數(shù)LLM，否則這些通常只需要GPU的一部分。這凸顯了需要能夠分割昂貴的加速器，如GPU。DRA項(xiàng)目53仍處于alpha狀態(tài)，旨在使GPU調(diào)度更加靈活。另一個(gè)考慮因素是響應(yīng)延遲，這在很大程度上取決于用例。例如，在自動(dòng)駕駛環(huán)境中檢測(cè)道路上的物體所需的響應(yīng)延遲比創(chuàng)建圖像或?qū)懺?shī)時(shí)的可容忍低幾個(gè)數(shù)量級(jí)。其他服務(wù)實(shí)例可能需要為高負(fù)載條件下的低延遲應(yīng)用程序啟動(dòng)。如果可以實(shí)現(xiàn)所需的延遲，這些應(yīng)用程序可能會(huì)降落在CPU、GPU或其他計(jì)算資源上。在Kubernetes中，對(duì)可用資源的這種級(jí)聯(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ì)是通過(guò)以O(shè)peCotaierIitiative55(OCI)格式交付模型來(lái)為模型共享提供更好的支持，OCI是一種適用于共享的不可變文件系統(tǒng)。另一種解決方案是將AI用于CN，特別是預(yù)測(cè)使用情況，并主動(dòng)浮動(dòng)或關(guān)閉服務(wù)實(shí)例以處理預(yù)期的負(fù)載。用戶體驗(yàn)CN的標(biāo)志，也就是容器，允許可移植性和可重復(fù)性，而Kberetes的API和操作員，如Kbeflow，簡(jiǎn)化了AI工作負(fù)載的部署，使它們以易于擴(kuò)展的方式“編寫一次并（幾乎）在任何地方運(yùn)行”。一旦用戶從裸機(jī)或虛擬化環(huán)境上的傳統(tǒng)批處理系統(tǒng)過(guò)渡到容器和Kberetes，他們就會(huì)欣賞云技術(shù)的優(yōu)勢(shì)，盡管它們最初的采用面臨挑戰(zhàn)。然而,學(xué)習(xí)曲線可以是陡峭讓我們考慮AI培訓(xùn)工作負(fù)載。配置運(yùn)行時(shí)環(huán)境可能是耗時(shí)的,特別是當(dāng)使用高度可定制的庫(kù)時(shí)。用戶可以選擇對(duì)大量環(huán)境變量使用默認(rèn)設(shè)置，但這些設(shè)置可能會(huì)產(chǎn)生較差的性能。一旦在給定的Kberetes平臺(tái)上針對(duì)特定的訓(xùn)練工作負(fù)載進(jìn)行了優(yōu)化，就不能保證它將在另一個(gè)平臺(tái)或訓(xùn)練任務(wù)或包含不同庫(kù)的容器捆綁上執(zhí)行同樣的操作。這會(huì)影響工作負(fù)載的可移植性和易用性。上一段只看了AI管道中的一個(gè)階段，通常是多階段，涵蓋數(shù)據(jù)準(zhǔn)備、訓(xùn)練、調(diào)優(yōu)、服務(wù)和微調(diào)。如何為不一定精通系統(tǒng)或云概念的AI從業(yè)者提供無(wú)縫的用戶體驗(yàn)，并為他們提供簡(jiǎn)化的產(chǎn)品體驗(yàn)，以消除AI開(kāi)發(fā)中的摩擦？為AI從業(yè)者提供用戶友好且眾所周知的Pytho編寫的SDK，抽象出Kberetes的復(fù)雜細(xì)節(jié)，可以幫助提高ClodNativeAI工具的采用率。用戶希望使用PyTorch和TesorFlow構(gòu)建ML模型，然后通過(guò)使用簡(jiǎn)單的PythoSDK快速輕松地將其部署到Kberetes基礎(chǔ)設(shè)施，而不必?fù)?dān)心打包，構(gòu)建Docer映像，創(chuàng)建Kberetes自定義資源等細(xì)節(jié)（例如。Procedre，PyTorchJob，TFJob），并使用復(fù)雜的云原生工具擴(kuò)展這些模型。要為MLOps生命周期創(chuàng)造一個(gè)更加用戶友好的開(kāi)源產(chǎn)品體驗(yàn)，需要一個(gè)強(qiáng)大的產(chǎn)品開(kāi)發(fā)重點(diǎn)。集成像JupyterLab這樣的工具，它包含了類似IDE的體驗(yàn)空間，這些體驗(yàn)可能存在于當(dāng)今可用的AI/ML工具（例如KubeflowKatibAPI）中，這將使ML從業(yè)者能夠更快地迭代他們的AI開(kāi)發(fā)，而在多個(gè)用戶界面上的上下文切換更少。JupyterLab的可擴(kuò)展特性為ML從業(yè)者提供了一個(gè)工作區(qū)，可以在熟悉的工具中構(gòu)建，部署和監(jiān)視AI/ML工作負(fù)載,而無(wú)需學(xué)習(xí)新的工具和界面。甚至可以使用JupyterLab使用像Elyra56這樣的GUI工作流構(gòu)建工具以及Kubeflow管道來(lái)安排在各個(gè)AI/MLNotebooks中開(kāi)發(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)中的工具沒(méi)有很好的連接。需要額外的開(kāi)銷來(lái)準(zhǔn)備數(shù)據(jù)、構(gòu)建功能、將功能存儲(chǔ)到磁盤，然后將這些功能讀回內(nèi)存以用于訓(xùn)練工作負(fù)載。RayData59或基于ArrowFlightRPC構(gòu)建的數(shù)據(jù)緩存微服務(wù)等解決方案可能會(huì)顯著提高訓(xùn)練工作負(fù)載第一階段的輸入/輸出開(kāi)銷。WHITEPAPERML工具很復(fù)雜，用戶通常需要幫助才能在Kubernetes上部署它們。識(shí)別和部署GPU的適當(dāng)驅(qū)動(dòng)程序并使其與用戶的AI/ML兼容是不平凡的工作負(fù)載。應(yīng)簡(jiǎn)化和改進(jìn)現(xiàn)有ML工作負(fù)載的升級(jí)路徑，類似于其他Kubernetes控制平面組件。用戶應(yīng)獲得有關(guān)如何使其AI工作負(fù)載適應(yīng)Kubernetes升級(jí)和集群停機(jī)的明確指南。影響易用性的另一個(gè)方面是多租戶，使用配額和名稱空間。非管理員用戶需要幫助來(lái)確定他們可用的系統(tǒng)資源。通常，管理員提供工具(例如，Grafana儀表板)以實(shí)現(xiàn)可觀察性；當(dāng)缺乏這些工具時(shí)，非專家/非管理員用戶會(huì)陷入困境。最后，調(diào)試是具有挑戰(zhàn)性的，在分布式環(huán)境中更是如此，當(dāng)處理管道包括多個(gè)復(fù)雜服務(wù)時(shí)更是如此。硬件和軟件故障可能或多或少是明確的，并且很容易識(shí)別云用戶，但人工智能從業(yè)者可能需要幫助來(lái)查看故障的完整情況。例如，NCCL終止錯(cuò)誤可能是模糊的，有許多可能的原因，每個(gè)原因都需要調(diào)查。用戶可能需要將錯(cuò)誤消息解析給管理員以獲得進(jìn)一步的幫助。交叉關(guān)注在前面的章節(jié)中，我們解決了AI管道中特定階段的挑戰(zhàn)。但其他是所有階段和所有軟件應(yīng)用程序所共有的，涵蓋參考實(shí)現(xiàn)、可觀察性、安全性等。例如，適當(dāng)調(diào)整大小的資源對(duì)于處理數(shù)據(jù)、訓(xùn)練或服務(wù)是有效的。它具有資源利用率，成本和可持續(xù)性的影響。讓我們深入一點(diǎn)。參考實(shí)施云和人工智能都不是容易的研究，在從許多工具和項(xiàng)目中做出選擇后，讓它們一起工作并不容易。需要通過(guò)要求滿足大多數(shù)簡(jiǎn)單用例的參考實(shí)現(xiàn)來(lái)改進(jìn)采用。Kberetes的Kid創(chuàng)造了奇跡，幫助開(kāi)發(fā)人員開(kāi)始使用筆記本電腦。JpyterNoteboo也為新興的AI/ML開(kāi)發(fā)人員做了同樣的事情。對(duì)于在云中運(yùn)行的AI/ML管道，我們需要類似的東西。適當(dāng)調(diào)整資源調(diào)配規(guī)模AI/ML工作負(fù)載是資源密集型的，尤其是具有數(shù)十億或數(shù)萬(wàn)億參數(shù)的LLM。如前所述，像GPU這樣的加速器價(jià)格昂貴且供不應(yīng)求，使用適當(dāng)?shù)拇笮》峙鋪?lái)節(jié)省資源和控制成本至關(guān)重要。我們不僅需要能夠?qū)PU進(jìn)行時(shí)間排序，還需要將它們切片或劃分為分?jǐn)?shù)段，并根據(jù)不同工作負(fù)載的需要明智地分配它們。結(jié)合上述后端工作，需要前端支持在啟動(dòng)工作負(fù)載時(shí)請(qǐng)求GPU子單元并對(duì)其進(jìn)行配置。為了滿足這一需求，Kubernetes引入了一個(gè)新的API，動(dòng)態(tài)資源分配(DRA)6061作為v1.26中的alpha。該API為管理專用硬件資源提供了更大的靈活性，特別是：?網(wǎng)絡(luò)連接資源?資源請(qǐng)求的任意參數(shù)?任意、特定于資源的設(shè)置和清理操作?自定義匹配資源請(qǐng)求與可用資源，包括處理可選請(qǐng)求。WHITEPAPER?與現(xiàn)有方法相比，DRAAPI提供了幾個(gè)優(yōu)點(diǎn)：-可以通過(guò)開(kāi)發(fā)和部署DRA驅(qū)動(dòng)程序來(lái)添加自定義硬件，而無(wú)需修改核心Kubernetes代碼庫(kù)-供應(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í)例可以利用策略來(lái)捕獲平衡風(fēng)險(xiǎn)并滿足服務(wù)級(jí)別協(xié)議(SLA)?？捎^察性可觀察性在AI/ML管道中很有價(jià)值。CN提供了OpeTelemetry62和Promethes63等工具，可以監(jiān)控負(fù)載、訪問(wèn)次數(shù)、響應(yīng)延遲等。在生產(chǎn)環(huán)境中監(jiān)控模型性能和運(yùn)行狀況至關(guān)重要。跟蹤模型漂移以確保AI系統(tǒng)的準(zhǔn)確性和可靠性至關(guān)重要。例如，在COVID-19大流行期間，隨著越來(lái)越多的人戴著口罩，面部識(shí)別系統(tǒng)可能會(huì)退化。同樣，由于自然災(zāi)害或利率變化等外部因素,房?jī)r(jià)預(yù)測(cè)模型可能會(huì)偏離現(xiàn)實(shí)。因此，持續(xù)監(jiān)控AI模型對(duì)于檢測(cè)任何性能問(wèn)題并進(jìn)行必要的調(diào)整至關(guān)重要?；A(chǔ)設(shè)施監(jiān)控是必不可少的，尤其是對(duì)于長(zhǎng)時(shí)間運(yùn)行的工作負(fù)載。當(dāng)AI訓(xùn)練工作負(fù)載運(yùn)行時(shí)，GPU和網(wǎng)絡(luò)可能會(huì)出現(xiàn)異常。例如，GPU內(nèi)存中的錯(cuò)誤或無(wú)法訪問(wèn)的節(jié)點(diǎn)可能會(huì)導(dǎo)致作業(yè)崩潰。但是，可能會(huì)出現(xiàn)無(wú)法立即識(shí)別的問(wèn)題：例如，訓(xùn)練性能可能會(huì)開(kāi)始下降，而不會(huì)報(bào)告任何明顯的硬件故障。在這些情況下，只有深度診斷才能識(shí)別問(wèn)題。當(dāng)前的度量不會(huì)暴露深度診斷的結(jié)果。因此，在運(yùn)行AI培訓(xùn)作業(yè)之前、期間和之后提供檢測(cè)、避免和處理基礎(chǔ)設(shè)施問(wèn)題的工具變得至關(guān)重要。災(zāi)難恢復(fù)和業(yè)務(wù)連續(xù)性所有生產(chǎn)服務(wù)都必須具有彈性，并有備份，AI服務(wù)沒(méi)有什么不同，服務(wù)失敗或響應(yīng)緩慢會(huì)導(dǎo)致聲譽(yù)受損和收入損失。制定全面的災(zāi)難恢復(fù)計(jì)劃至關(guān)重要，可能包括數(shù)據(jù)備份，在多個(gè)可用區(qū)中運(yùn)行實(shí)例以及運(yùn)行多個(gè)實(shí)例。策略可以幫助您解決這些問(wèn)題。安全性和合規(guī)性審核所有面向外的服務(wù)，特別是ModelServing實(shí)例，都需要防火墻保護(hù)、訪問(wèn)控制等。與任何其他服務(wù)一樣，您的AI/ML工作負(fù)載必須遵循安全最佳實(shí)踐。這些包括滲透測(cè)試、漏洞掃描和工作負(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ù)和可測(cè)試性。TEE在使用過(guò)程中保護(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這樣的大型語(yǔ)言模型。培訓(xùn)排放可與多個(gè)橫貫大陸的航班相媲美，而由于查詢量高，推斷排放加起來(lái)。68行業(yè)傾向于對(duì)市場(chǎng)主導(dǎo)地位的過(guò)大模型的趨勢(shì)導(dǎo)致效率低下，從而導(dǎo)致能源和資源消耗。69在報(bào)告模型的環(huán)境影響方面，提高透明度和標(biāo)準(zhǔn)化是挑戰(zhàn)。最近，有努力增加與LLama70的透明度，同時(shí)一些見(jiàn)解正在成為可用的關(guān)于水使用的冷卻服務(wù)器運(yùn)行的LLM，如ChatGPT。ChatGPT的碳足跡是顯著的，因?yàn)樗臄?shù)以百萬(wàn)計(jì)的用戶。可持續(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ù)教育主要集中在沒(méi)有AI或計(jì)算機(jī)輔助的傳統(tǒng)編程語(yǔ)言上。學(xué)校通常不使用支持重構(gòu)，模板或API幫助的現(xiàn)代IDE，并且將在包含的網(wǎng)站上提供學(xué)生代碼，以便于設(shè)置。他們也不教授使用像Githb的Copilot這樣的AI編碼輔助技術(shù),盡管這將成為未來(lái)的標(biāo)準(zhǔn)開(kāi)發(fā)模式。大多數(shù)學(xué)生甚至不知道這項(xiàng)技術(shù)的存在。由于擔(dān)心作弊，學(xué)校積極勸阻學(xué)生使用ChatGPT和Copilot等AI技術(shù)。這阻止了學(xué)生學(xué)習(xí)如何使用AI技術(shù)來(lái)增強(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)。我們接下來(lái)考慮來(lái)自這些挑戰(zhàn)的機(jī)遇。WHITEPAPER云本土人工智能前進(jìn)的道路本節(jié)提供了一個(gè)前瞻性的方法來(lái)主動(dòng)實(shí)施CNAI。我們從建議（或行動(dòng)）開(kāi)始，然后列舉現(xiàn)有但不斷發(fā)展的解決方案（即CNAI軟件最后考慮進(jìn)一步發(fā)展的機(jī)會(huì)。建議靈活性從用于接口的REST接口到基于云的資源和服務(wù),CN技術(shù)今天運(yùn)行良好,并將隨著新產(chǎn)品的發(fā)展而繼續(xù)運(yùn)行。可持續(xù)性改善AI工作量環(huán)境影響的問(wèn)責(zé)制對(duì)于生態(tài)可持續(xù)性至關(guān)重要，特別是在云原生景觀中。這可以通過(guò)支持項(xiàng)目、方法和分類法來(lái)實(shí)現(xiàn)，這些項(xiàng)目、方法和分類法有助于澄清、分類和催化AI工作量對(duì)生態(tài)可持續(xù)性的影響。此外，集成云原生技術(shù)以優(yōu)化AI工作負(fù)載調(diào)度、自動(dòng)擴(kuò)展和調(diào)優(yōu)是必要的。此外，倡導(dǎo)在環(huán)境影響評(píng)估中采用標(biāo)準(zhǔn)化方法至關(guān)重要。同樣重要的是，主要通過(guò)Kbeflow等云原生堆棧來(lái)促進(jìn)節(jié)能AI模型的開(kāi)發(fā)和使用，并提高模型開(kāi)發(fā)和使用的透明度。最后，強(qiáng)調(diào)有目的和有效使用人工智能的重要性將有助于最大限度地減少不必要的計(jì)算負(fù)荷。自定義平臺(tái)依賴項(xiàng)我們建議確保CloudNative環(huán)境具有所需的GPU驅(qū)動(dòng)程序，并支持針對(duì)AI工作負(fù)載的GPU加速。這一點(diǎn)至關(guān)重要，因?yàn)锳I應(yīng)用程序通常依賴于特定的框架和庫(kù)版本，這些版本可能無(wú)法輕松訪問(wèn)或與標(biāo)準(zhǔn)容器映像兼容。這將有助于應(yīng)對(duì)擁有各種供應(yīng)商和GPU架構(gòu)的挑戰(zhàn)。參考實(shí)施考慮到AI開(kāi)發(fā)中涉及的工具的數(shù)量和復(fù)雜性，建議考慮基于ClodNative，基于OpeTof的各種工具的用戶友好組合的參考實(shí)現(xiàn)的價(jià)值，這些工具可以為世界各地的任何團(tuán)隊(duì)提供類似產(chǎn)品的體驗(yàn)，以便快速開(kāi)始在云中進(jìn)行AI/ML。結(jié)合用于數(shù)據(jù)準(zhǔn)備、功能存儲(chǔ)、培訓(xùn)、調(diào)優(yōu)、模型注冊(cè)和服務(wù)的最佳可用開(kāi)源工具，可以幫助團(tuán)隊(duì)快速開(kāi)始進(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)對(duì)于推進(jìn)基于云的技術(shù)的開(kāi)放和負(fù)責(zé)任的AIML開(kāi)發(fā)可能非常有價(jià)值。WHITEPAPER行業(yè)接受術(shù)語(yǔ)隨著人工智能變得無(wú)處不在，它在某些方面變得越來(lái)越復(fù)雜，但在其他方面變得更簡(jiǎn)單。例如，術(shù)語(yǔ)演變，為企業(yè)提供了更輕松的關(guān)于人工智能的對(duì)話(例如，“重新利用”來(lái)重用現(xiàn)有內(nèi)容等術(shù)語(yǔ))。這也適用于更多的技術(shù)術(shù)語(yǔ)，如RAG、理性和精煉。AI/ML的演進(jìn)解決方案以下只是一些特定工具或技術(shù)的示例，這些工具或技術(shù)已成為啟用AI（包括CNAI）的選項(xiàng)。業(yè)務(wù)流程-KubeflowKubeflow是支持MLOperations(MLOps)的CNAI工具的一個(gè)例子。使用Kubernetes、無(wú)狀態(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。對(duì)于分布式訓(xùn)練，Katib用于超參數(shù)調(diào)優(yōu)微調(diào)，KubeflowKServe用于模型服務(wù)。這允許用戶將單個(gè)Kubeflow組件集成到他們的ML基礎(chǔ)設(shè)施中或使用Kubeflow作為端到端ML平臺(tái)。上下文-向量數(shù)據(jù)庫(kù)LLM在某個(gè)時(shí)間點(diǎn)使用大量的，通常是公開(kāi)可用的數(shù)據(jù)進(jìn)行訓(xùn)練。我們通過(guò)提示與他們進(jìn)行交互。但是為了使響應(yīng)更有價(jià)值，而無(wú)需用戶輸入更長(zhǎng)或更多的提示并可能檢索更多特定領(lǐng)域的響應(yīng)，“豐富”是有幫助的提示。這是矢量數(shù)據(jù)庫(kù)的來(lái)源。它們是矢量的巨大索引存儲(chǔ)，是數(shù)字形式的數(shù)據(jù)的數(shù)學(xué)表示。嵌入是每個(gè)附加數(shù)據(jù)的特定矢量表示形式，通常是專有的，特定于領(lǐng)域的或更新的，旨在捕獲關(guān)系和相似性(context)它們表示的數(shù)據(jù)之間。用戶提供的LLM提示使用向量數(shù)據(jù)庫(kù)使用的相同嵌入進(jìn)行轉(zhuǎn)換,然后使用結(jié)果向量在數(shù)據(jù)庫(kù)中查找相似向量。然后將它們合并以提供額外的上下文多模式GenAI系統(tǒng)將處理可能是文本、圖像、音頻或其他的提示，并具有處理不同輸入的嵌入能矢量數(shù)據(jù)庫(kù)可以是專門構(gòu)建的數(shù)據(jù)庫(kù)，也可以是具有擴(kuò)展功能的傳統(tǒng)數(shù)據(jù)庫(kù)，以更具體地處理矢量。實(shí)例在選擇索引方案，用于計(jì)算相似性的距離度量以及它們是否采用以及采用什么數(shù)據(jù)壓縮技術(shù)方面可能會(huì)有所不同。一些產(chǎn)品包括Redis，73Milvus，74Faiss，75和Weaviat.76可觀測(cè)性-OpenLLMetryOpeLLMetry77是一個(gè)構(gòu)建在OpeTelemetry78之上的項(xiàng)目，旨在為L(zhǎng)LM可觀測(cè)性提供徹底和供應(yīng)商中立的檢測(cè)。因?yàn)樯葾I在傳統(tǒng)意義上是不可調(diào)試的（i。Procedres.，您不能“只是逐步完成代碼”），開(kāi)發(fā)人員必須轉(zhuǎn)向可觀察性工具和實(shí)踐，以隨著時(shí)間的推移改善他們對(duì)生成性AI的使用。這些數(shù)據(jù)通常也是評(píng)估和微調(diào)工作流程的來(lái)源。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可以鳥(niǎo)瞰CN生態(tài)系統(tǒng)。下圖列出了按功能區(qū)域分組的已建立和正在發(fā)展的項(xiàng)目。ML工具任務(wù)思維導(dǎo)圖WHITEPAPERCNAI兒童和學(xué)生孩子們已經(jīng)每天使用像ChatGPT這樣的AI輔助技術(shù)，不知道它們是如何工作的?，F(xiàn)代人工智能的基礎(chǔ)，如辨別和生成人工智能算法，是一個(gè)孩子甚至技術(shù)精湛的父母都不理解的黑匣子，所以很難對(duì)它產(chǎn)生興趣。學(xué)生的教育不僅應(yīng)將ChatGPT之類的LLM視為理所當(dāng)然，還應(yīng)包括神經(jīng)網(wǎng)絡(luò)和機(jī)器學(xué)習(xí)算法的基礎(chǔ)知識(shí)，以解釋AI技術(shù)的工作原理以及如何在未來(lái)的職業(yè)生涯中更好地使用它們。ClodNative社區(qū)和KbeCo的CNCFKidsDay82等成功計(jì)劃提供了有關(guān)ClodNative和AI技術(shù)的教育機(jī)會(huì)。盡早向孩子們介紹AI技術(shù)也將防止困擾計(jì)算機(jī)科學(xué)的多樣性，公平性和包容性問(wèn)題。AI是一種平等的技術(shù)，因?yàn)槊總€(gè)種族，性取向和社會(huì)經(jīng)濟(jì)地位的人都可以每天體驗(yàn)AI/ML，并通過(guò)適當(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ù)變得無(wú)處不在，甚至普通工人也接受了這項(xiàng)技術(shù)來(lái)改善他們的業(yè)務(wù)。隨著AI/ML技術(shù)在社會(huì)中無(wú)處不在，我們必須確保學(xué)生跟上AI和CloudNative技術(shù)的進(jìn)步。Participation隨著AI的發(fā)展，更多的教育和參與機(jī)會(huì)發(fā)生。有AI專家的空間（例如。Procedre,Ph.D.在ML中對(duì)數(shù)據(jù)科學(xué)家)和AI通才(例如Procedre、運(yùn)營(yíng)商和最終用戶)。MOOCs83和認(rèn)證等教育項(xiàng)目已經(jīng)出現(xiàn)，專注于各個(gè)方面的AI工具和技術(shù)。專業(yè)社團(tuán)（e。Procedre，ACM84和IEEE85）和聚會(huì)提供了面對(duì)面學(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)。這些可能是由于無(wú)意的設(shè)計(jì)問(wèn)題對(duì)弱勢(shì)群體造成不利影響，例如，推薦算法無(wú)意中推廣基于仇恨、暴力、極端主義的材料。它們也可能是由于個(gè)人或團(tuán)體惡意使用系統(tǒng)和/或工具來(lái)故意傷害，例如使用生成性AI工具來(lái)創(chuàng)建錯(cuò)誤信息和虛假信息活動(dòng)，或者個(gè)人故意將LLM精細(xì)起來(lái)以產(chǎn)生兒童性虐待材料。AI和ClodNative技術(shù)也是TrstadSafety使用的工具的核心：“數(shù)字服務(wù)用于管理內(nèi)容并對(duì)用戶和他人進(jìn)行風(fēng)險(xiǎn)掃描，減輕在線或其他形式的技術(shù)促進(jìn)濫用，倡導(dǎo)用戶權(quán)利并保護(hù)品牌安全的領(lǐng)域和實(shí)踐。“已經(jīng)建立了89個(gè)系統(tǒng)來(lái)提供信任和安全周期的每個(gè)部分，包括識(shí)別和評(píng)估潛在的暴力行為，對(duì)案件進(jìn)行分類和優(yōu)先排序，制定和記錄執(zhí)法決策，選擇和應(yīng)用干預(yù)措施以及收集威脅情報(bào)。除了對(duì)互聯(lián)網(wǎng)的安全和健康至關(guān)重要之外，如果在設(shè)計(jì)時(shí)沒(méi)有適當(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ì)和開(kāi)發(fā)的中心?！?2這種主動(dòng)和預(yù)防性的方法側(cè)重于將安全嵌入到組織的文化和領(lǐng)導(dǎo)中。它強(qiáng)調(diào)問(wèn)責(zé)制，旨在為每個(gè)人培養(yǎng)更積極，文明和獎(jiǎng)勵(lì)的在線體驗(yàn)。有越來(lái)越多的專家來(lái)幫助這些發(fā)展最佳做法，例如全球反恐互聯(lián)網(wǎng)論壇（GIFCT93技術(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的開(kāi)放式創(chuàng)新和科學(xué)，以提出封閉式AI系統(tǒng)的替代方案，并推進(jìn)負(fù)責(zé)任的AI領(lǐng)域（道德，信任，安全）。OpeAI是ChatGPT背后的組織，最初是一家非營(yíng)利性組織，致力于保證AI的安全性和公平性。一門新的工程學(xué)科的出現(xiàn)在過(guò)去的二十年中，我們已經(jīng)看到科技行業(yè)如何根據(jù)他們的職責(zé)迅速創(chuàng)造和改變工程工作角色。我們見(jiàn)證了DevOps工程師、SRE工程師和基礎(chǔ)設(shè)施工程師等角色的崛起。我們預(yù)計(jì)MLDevOps或AI工程師將在未來(lái)幾個(gè)月或幾年內(nèi)成為數(shù)據(jù)科學(xué)、基礎(chǔ)設(shè)施和開(kāi)發(fā)之間的粘合劑。重要的是要知道這個(gè)行業(yè)領(lǐng)域正在發(fā)展，角色頭銜可能會(huì)波動(dòng)；只有時(shí)間才能證明。不同的術(shù)語(yǔ)也可能成為現(xiàn)實(shí)。將來(lái)，該角色將需要更多地關(guān)注AI工具，以及部署AI鏈和代理。WHITEPAPERCLOUDNATIVE的人工智能本文主要關(guān)注支持AI開(kāi)發(fā)和使用的ClodNative。但AI可以通過(guò)多種方式增強(qiáng)ClodNative，包括預(yù)測(cè)負(fù)載和更好的資源調(diào)度，特別是涉及多個(gè)優(yōu)化標(biāo)準(zhǔn)，例如節(jié)能、提高資源利用率、減少延遲、尊重優(yōu)先級(jí)、增強(qiáng)安全性、理解日志和跟蹤等用于群集控制的自然語(yǔ)言接口在202399年芝加哥的ClodNativeAI+HPCDay上，演示了具有自然語(yǔ)言界面的Kberetes控制器來(lái)處理與集群相關(guān)的任務(wù)。它在該后端使用了LLM，該LLM理解了用戶請(qǐng)求并將其轉(zhuǎn)換為KberetesAPI調(diào)用。它還支持啟動(dòng)混沌測(cè)試，以確定服務(wù)彈性，掃描CVE等。它是Kberetes集群更直觀的編排和管理的先驅(qū)，并及時(shí)降低了管理員和站點(diǎn)可靠性工程師的學(xué)習(xí)曲線。安全機(jī)器學(xué)習(xí)可以分析大量數(shù)據(jù)集，以快速識(shí)別模式并預(yù)測(cè)系統(tǒng)中的潛在威脅或弱點(diǎn)。將AI集成到Redteamig100中可以加速識(shí)別安全漏洞，并使組織能夠加強(qiáng)對(duì)新興網(wǎng)絡(luò)威脅的防御。檢測(cè)異常網(wǎng)絡(luò)行為的ML模型可以輕松地用于集群中，以保護(hù)工作負(fù)載，或用于邊緣部署的集群隊(duì)列。更智能的編排/調(diào)度AI可以分析日/周/月的歷史集群使用情況，以識(shí)別工作負(fù)載模式和資源可用性，了解何時(shí)以及如何部署工作負(fù)載，是水平擴(kuò)展還是垂直擴(kuò)展，何時(shí)在幾個(gè)節(jié)點(diǎn)上整合工作負(fù)載以使其他節(jié)點(diǎn)處于靜止?fàn)顟B(tài)以節(jié)省電量，甚至將其從集群中刪除以降低成本。ML驅(qū)動(dòng)的模型可以優(yōu)化任務(wù)排序，自動(dòng)化決策過(guò)程，并提高工作負(fù)載管理的整體效率。自然語(yǔ)言接口有助于整個(gè)編排和調(diào)度過(guò)程。這些增強(qiáng)功能將使組織更容易在動(dòng)態(tài)云環(huán)境中管理和安排復(fù)雜的工作流。正在構(gòu)建處理器電源模型，以幫助規(guī)劃和優(yōu)化以降低功耗。飛行中和探索中的AI集成努力?微調(diào)自定義LLM以分析日志。?MLOps管道，用于捕獲和維護(hù)數(shù)據(jù)來(lái)源。?OpenTelemetry.101等CNCF項(xiàng)目的AI語(yǔ)義約定?AI驅(qū)動(dòng)的開(kāi)發(fā)環(huán)境(IDE)用于開(kāi)發(fā)和部署AI應(yīng)用程序。我們希望在不遠(yuǎn)的將來(lái)報(bào)告這一領(lǐng)域的進(jìn)展。WHITEPAPERConclusion人工智能（AI）和云原生（CN）技術(shù)的結(jié)合為組織提供了開(kāi)發(fā)前所未有的功能的絕佳機(jī)會(huì)。借助云原生基礎(chǔ)設(shè)施的可擴(kuò)展性、彈性和易用性，AI模型可以更高效、更大規(guī)模地進(jìn)行訓(xùn)練和部署。本白皮書深入研究了這兩個(gè)領(lǐng)域的交集，討論了組織利用這種有效組合的當(dāng)前狀態(tài)、挑戰(zhàn)、機(jī)遇和潛在解決方案。雖然仍然存在一些挑戰(zhàn)，包括管理復(fù)雜AI工作負(fù)載的資源需求，確保AI模型的可重復(fù)性和可解釋性，以及簡(jiǎn)化非技術(shù)從業(yè)者的用戶體驗(yàn)，但ClodNative生態(tài)系統(tǒng)正在不斷發(fā)展以解決這些問(wèn)題。像Kbeflow、Ray和KbeRay這樣的項(xiàng)目為在云中運(yùn)行AI工作負(fù)載提供了更加統(tǒng)一和用戶友好的體驗(yàn)。此外，對(duì)GPU調(diào)度，矢量數(shù)據(jù)庫(kù)和可持續(xù)性的持續(xù)研究為克服局限性提供了有希望的解決方案。隨著AI和CloudNative技術(shù)的成熟，擁有這種協(xié)同作用的組織將處于有利地位，以釋放顯著的競(jìng)爭(zhēng)優(yōu)勢(shì)。從自動(dòng)化復(fù)雜任務(wù)和分析大量數(shù)據(jù)集到生成創(chuàng)造性內(nèi)容和個(gè)性化用戶體驗(yàn)，可能性是無(wú)窮無(wú)盡的。通過(guò)投資合適的人才、工具和基礎(chǔ)設(shè)施，組織可以利用AI和云原生技術(shù)的強(qiáng)大功能，可推動(dòng)創(chuàng)新、優(yōu)化運(yùn)營(yíng)并提供卓越的客戶體驗(yàn)。這份文件帶給你的CNCFAI工作組。APPENDIX參考文獻(xiàn)詞匯表AI從業(yè)者在本文的上下文中，它指的是（不限于）ML工程師，數(shù)據(jù)科學(xué)家，數(shù)據(jù)工程師，其主要職責(zé)包括操縱相關(guān)數(shù)據(jù)，創(chuàng)建和優(yōu)化機(jī)器學(xué)習(xí)模型。開(kāi)發(fā)人員在本文的上下文中，它是指（不限于）軟件工程師，前端工程師，后端工程師，全棧工程師，軟件架構(gòu)師和軟件測(cè)試員。其主要職責(zé)包括編寫和測(cè)試軟件，包括用戶界面，微服務(wù)和后端軟件。WHITEPAPER部署人員在本文的上下文中，它是指（不限于）DevOps工程師，站點(diǎn)可靠性工程師，基礎(chǔ)架構(gòu)架構(gòu)師，應(yīng)用程序管理員，群集管理員。主要職責(zé)包括將軟件和云基礎(chǔ)架構(gòu)部署到多個(gè)環(huán)境（包括開(kāi)發(fā)，暫存和生產(chǎn)）。DRADRA代表動(dòng)態(tài)資源分配。它是對(duì)Pod的一般資源聲明和配置的API抽象，允許第三方供應(yīng)商按需提供HW/SW資源，而無(wú)需重寫Kubernetes核心API。LLM“LLM”代表“大型語(yǔ)言模型”。大型語(yǔ)言模型是在大量文本數(shù)據(jù)上訓(xùn)練的人工智能模型，用于理解和生成類似人類的文本。LLM是專門為自然語(yǔ)言處理(NLP)任務(wù)設(shè)計(jì)的機(jī)器學(xué)習(xí)模型的子集。LLMOpsLLMOps代表大型語(yǔ)言模型操作，包含專門為大型語(yǔ)言模型（LLM）量身定制的操作方面。從本質(zhì)上講，LLMOps是MLOps原則和工具的適應(yīng)LLM支持的應(yīng)用程序的獨(dú)特要求，涵蓋了從開(kāi)發(fā)到部署和維護(hù)的整個(gè)生命周期。MIG多實(shí)例GPU技術(shù)是一項(xiàng)創(chuàng)新，它允許將單個(gè)物理GPU（圖形處理單元）劃分為多個(gè)更小的實(shí)例，每個(gè)實(shí)例都作為一個(gè)獨(dú)立的GPU運(yùn)行，具有自己的資源和功能。該技術(shù)增強(qiáng)了數(shù)據(jù)中心和云計(jì)算環(huán)境中的GPU利用率和靈活性。MLOpsMLOps是機(jī)器學(xué)習(xí)操作的縮寫，是指用于簡(jiǎn)化和自動(dòng)化機(jī)器學(xué)習(xí)模型在生產(chǎn)環(huán)境中的部署、監(jiān)控和管理的實(shí)踐、方法和工具。MLOps旨在彌合機(jī)器學(xué)習(xí)開(kāi)發(fā)和運(yùn)營(yíng)之間的差距，確保機(jī)器學(xué)習(xí)模型的高效、可靠和大規(guī)模部署。它涉及結(jié)合軟件工程原則、DevOps實(shí)踐和專用工具，實(shí)現(xiàn)端到端ML生命周期的自動(dòng)化，包括數(shù)據(jù)準(zhǔn)備、模型訓(xùn)練、模型部署、監(jiān)控和維護(hù)。MLOps可幫助組織加速其ML項(xiàng)目，提高模型性能，并在ML管道中保持一致性和可靠性。MPSMPS在GPU計(jì)算中代表多進(jìn)程服務(wù)，MPS技術(shù)允許多個(gè)GPU加速的應(yīng)用或進(jìn)程共享單個(gè)物理GPU，同時(shí)保持隔離和高效RAGWHITEPAPER在AI的背景下，RAG代表“檢索增強(qiáng)生成”?！斑@是一個(gè)模型架構(gòu)，結(jié)合了基于檢索的模型和生成模型來(lái)生成文本。RAG的生成過(guò)程通過(guò)檢索機(jī)制增強(qiáng)，該機(jī)制可幫助模型從廣泛的數(shù)據(jù)庫(kù)或知識(shí)庫(kù)中訪問(wèn)相關(guān)信息。該檢索組件允許模型將外部知識(shí)合并到生成過(guò)程中，從而提高生成文本的質(zhì)量和相關(guān)性。vGPUvGPU（即虛擬圖形處理單元）技術(shù)使多個(gè)虛擬機(jī)（VM）共享單個(gè)物理GPU（圖形處理單元）。該技術(shù)可在云計(jì)算，數(shù)據(jù)中心和虛擬桌面基礎(chǔ)架構(gòu)（VDI）等虛擬化環(huán)境中有效利用GPU資源。WHITEPAPER參考文獻(xiàn)123456789https://github.com/cncf/toc/blob/main/DEFINITION.mdhttps://en.wikipedia.org/wiki/Microserviceshttps://travide.cncf.io/guidehttps://docs.aws.amazon.com/whitepapers/latest/build-secure-enterprime-ml-platform/personas-for-an-ml-platform.htmlDocker2013年3月20日首次發(fā)布。https://en.wikipedia.org/wiki/LXChttps://en.wikipedia.org/wiki/Docker_（軟件）https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/44843.pdfhttps://github.com/cncf/toc/blob/main/DEFINITION.md截至7月18,202https://en.wikipedia.org/wiki/DevOpshttps://about.gitlab.com/topics/gitops/https://ai100.stanford.edu/2016-report/appendix-i-short-history-aihttps://youtu.be/P18EdAKuC1U?si=Dd74AdpbF3EgzVmnhttps://arxiv.org/abs/2008.02217https://openai.com/chatgpthttps://en.wikipedia.org/wiki/Prompt_engineering#Retrieval-augmented_generationhttps://github.com/zanetworker/ai-landscapehttps://openai.com/research/scaling-kubernetes-to-7500-nodeshttps://huggingface.co/blog/hugging-face-endpoints-on-azure21https://kubernetes.io/docs/concepts/schedution-eviction/kube-scheduler/22https://github.com/intel/platform-感知調(diào)度/tree/master/gpu-感知調(diào)度23https://kubernetes.io/docs/tasks/manage-gpus/schedulation-gpus/24https://opencontainers.org/25https://k8sgpt.ai/26https://docs.aws.amazon.com/whitepapers/latest/build-secure-enterprime-ml-platform/personas-for-an-ml-platform.html28https://docs.databricks.com/en/machine-learning/mlops/mlops-workflow.html29https://cloud-native.slack.com/archives/C05TYJE81SR33https://iapp.org/新聞/a/5-要知道的東西-ai-模型卡/34https://arxiv.org/abs/2205.0714735https://kubernetes.io/docs/concepts/schedulation-eviction/動(dòng)態(tài)資源分配/37https://github.com/kserve/kserve/38[2112.06905]GLaM：使用專家混合的語(yǔ)言模型的有效擴(kuò)展39面向云的多集群Kubernetes環(huán)境中的碳感知工作負(fù)載調(diào)度程序WHITEPAPER