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

CNCFAI工作組云本土人工智能AuthorsAdelZaaloukAlexJonesAndreyVelichkevichBorisKurktchievCassandraChinCathyZhangClaudiaMisaleHuaminChenJoelRobertsKai-HsunChenMaliniBhandaruMichaelYaoNikhitaRaghunath彼得潘RajasKakodkarRasikPandeyRicardoAravenaRonaldPettyRyanTaylorSaadSheikhShawnWilsonTomThorleyVictorLu已發(fā)布3月20,2024（第1版）執(zhí)行摘要云原生（CN）和人工智能（AI）是當(dāng)今最關(guān)鍵的技術(shù)趨勢。ClodNative1技術(shù)為運(yùn)行應(yīng)用程序提供了可擴(kuò)展且可靠的平臺。鑒于AI和機(jī)器學(xué)習(xí)（ML）的最新進(jìn)展，它作為主要的云工作負(fù)載正在穩(wěn)步上升。雖然CN技術(shù)很容易支持AI/ML工作負(fù)載的某些方面，但挑戰(zhàn)和差距仍然存在，為創(chuàng)新和更好地適應(yīng)提供了機(jī)會。本文簡要概述了最先進(jìn)的AI/ML技術(shù)，其次是CN技術(shù)提供的內(nèi)容，在討論不斷發(fā)展的解決方案之前涵蓋了下一個挑戰(zhàn)和差距。本文將為工程師和業(yè)務(wù)人員提供知識，以了解不斷變化的云原生人工智能（CNAI）生態(tài)系統(tǒng)及其機(jī)遇。我們建議閱讀路徑取決于讀者的背景和興趣。假設(shè)暴露于微服務(wù)2和CN技術(shù)3，如Kberetes(K8s)。對于那些沒有工程AI系統(tǒng)經(jīng)驗(yàn)的人，我們建議從頭到尾閱讀。對于那些在AI/ML采用或交付過程中走得更遠(yuǎn)的人，根據(jù)他們的用戶角色4，我們建議深入到與他們正在努力解決或有興趣解決的挑戰(zhàn)相關(guān)的部分。我們還分享社會在這方面需要投資的地方。WHITEPAPER2WHITEPAPERWHITEPAPER內(nèi)容表云原生(CN)04的出現(xiàn)人工智能進(jìn)化(AI)05結(jié)束注釋28云人工智能(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ì)算基金會定義云原生計(jì)算基金會定義9云原生為：CloudNative技術(shù)使組織能夠在現(xiàn)代動態(tài)環(huán)境（如公共云、私有云和混合云）中構(gòu)建和運(yùn)行可擴(kuò)展的應(yīng)用程序。容器、服務(wù)網(wǎng)格、微服務(wù)、不可變基礎(chǔ)設(shè)施和聲明性API就是這種方法的例證。這些技術(shù)使松散耦合的系統(tǒng)具有彈性，可管理和可觀察性。結(jié)合強(qiáng)大的自動化，它們使工程師能夠以最少的工作量頻繁且可預(yù)測地進(jìn)行高影響的更改。云原生計(jì)算基金會尋求通過培育和維持一個開源、供應(yīng)商中立的項(xiàng)目生態(tài)系統(tǒng)來推動這一范例的采用。我們將最先進(jìn)的模式民主化，使每個人都能獲得這些創(chuàng)新。云原生人工智能是云原生的一個不斷發(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)了一個分布式編排器，用于處理多種類型的網(wǎng)絡(luò)、存儲和計(jì)算資源。此外，K8s提供了一個接口，使DevOps10的最佳實(shí)踐，如GitOps.11每個云服務(wù)提供商（CSP）都有一些Kberetes服務(wù)的味道，便于訪問基礎(chǔ)設(shè)施和一系列支持服務(wù)來運(yùn)行各種工作負(fù)載，包括AI/ML。WHITEPAPER4人工智能的進(jìn)化人工智能，最早在1956年被稱為一個術(shù)語，12是機(jī)器模擬人類智能的能力。幾十年來，它已被用于語音識別，機(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í)決策邊界或分類，將知識捕獲為“模型”,用于預(yù)測新數(shù)據(jù)。例如，將電子郵件分類為垃圾郵件，區(qū)分貓和狗的圖像等等。判別AI通常用于已知所需輸出的任務(wù)（例如Procedre，通過監(jiān)督學(xué)習(xí)，一種機(jī)器學(xué)習(xí)的形式)。人工智能擅長序列預(yù)測，例如，通過分析大量現(xiàn)有文本，包括我們的個人寫作風(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ù)提供動力。WHITEPAPERLLM是在海量數(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ì)量的模型，而不是幾個月。此外，數(shù)據(jù)科學(xué)家和統(tǒng)計(jì)學(xué)家采用的幾種傳統(tǒng)技術(shù)正在重新評估，以利用CN系統(tǒng)的功能。云原生與人工智能的融合正如上一節(jié)所述，人工智能是一個更廣泛的概念，旨在創(chuàng)建可以執(zhí)行類似于人類任務(wù)的系統(tǒng)。機(jī)器學(xué)習(xí)是一種基于數(shù)據(jù)進(jìn)行學(xué)習(xí)并做出明智預(yù)測和決策的方法。它可以被認(rèn)為是另一種形式的自動化，涉及使用算法來學(xué)習(xí)和改進(jìn)，而無需顯式編程。最后，數(shù)據(jù)科學(xué)作為一個多學(xué)科領(lǐng)域，融合了統(tǒng)計(jì)學(xué)，數(shù)學(xué)和計(jì)算機(jī)科學(xué)的技術(shù)來制定。廣泛的活動，從數(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ù)可能會有很大差異。WHITEPAPER以下是預(yù)測和生成AI在計(jì)算、網(wǎng)絡(luò)和存儲方面有不同需求的一組示例：挑戰(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ū)動的任務(wù)。存儲和吞吐量具有出色吞吐量的高性能存儲。數(shù)據(jù)類型多需要高吞吐量和低延遲的數(shù)據(jù)訪問。高效存儲，吞吐量適中。它更側(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ò)和存儲功能，以及提供隔離和受控共享機(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個節(jié)點(diǎn)擁抱臉與Microsoft合作在Azure上啟動擁抱臉模型目錄云原生人工智能是云原生的一個不斷發(fā)展的擴(kuò)展。云原生人工智能是云原生的一個不斷發(fā)展的擴(kuò)展。Kubernetes是一個可用于部署和管理容器的編排平臺，容器是輕量級、可移植、自包含的軟件單元，AI模型可以打包成容器然后部署到K8s集群。容器化對于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ù)來訓(xùn)練和測試AI模型，以獲得卓越的推理。云原生基礎(chǔ)設(shè)施可以通過各種方法訪問數(shù)據(jù)，例如數(shù)據(jù)湖和倉庫。許多云提供商提供塊、對象和文件存儲系統(tǒng)，非常適合提供低成本、可擴(kuò)展的存儲。例如，模型的大小可以達(dá)到千兆字節(jié)。在訓(xùn)練階段，每次拉取模型的檢查點(diǎn)都會導(dǎo)致網(wǎng)絡(luò)和存儲帶寬的嚴(yán)重負(fù)載。將模型視為容器化的工件為在OCI24注冊表中托管它們打開了大門，并啟用了緩存。它進(jìn)一步允許應(yīng)用。軟件供應(yīng)鏈模型的最佳實(shí)踐，例如工件簽名,驗(yàn)證，證明和數(shù)據(jù)來源。此外，容器化模型/工件促進(jìn)了WebAssembly(WASM)二進(jìn)制文件的捆綁。WASM是一種獨(dú)立于平臺的高效CN推理方法。為什么選擇云原生人工智能？憑借其彈性，始終在線的基礎(chǔ)架構(gòu)，云允許企業(yè)，初創(chuàng)公司和開發(fā)人員快速原型，提供新服務(wù)，擴(kuò)展解決方案等等。它還通過憑借其彈性，始終在線的基礎(chǔ)架構(gòu)，云允許企業(yè)，初創(chuàng)公司和開發(fā)人員快速原型，提供新服務(wù)，擴(kuò)展解決方案等等。它還通過資源共享實(shí)現(xiàn)了成本效益。普通用戶不再需要擔(dān)心訂購硬件或處理空間、電源、網(wǎng)絡(luò)連接、冷卻、軟件許可和安裝等物流問題。人工智能也有類似的擔(dān)憂——快速原型設(shè)計(jì)、訪問存儲、網(wǎng)絡(luò)和計(jì)算資源，以解決小型和大規(guī)模的訓(xùn)練和推理任務(wù)。使用AI改進(jìn)云原生系統(tǒng)無論是打包為可觀察性工具還是利用LLM功能進(jìn)行日志的自然語言處理（NLPAI驅(qū)動的解決方案/項(xiàng)目都在進(jìn)入運(yùn)營商和最終用戶的手中，以提高他們的生產(chǎn)力并使他們的生活更輕松。一個這樣的開源云原生計(jì)算基金會(CNCF）項(xiàng)目是K8sGPT，它利用LLM的模式識別和語言功能，如Bedroc，Cohere等，以幫助K8s運(yùn)營商。日常工作。更重要的是，CN和AI的共生為新的和不可預(yù)見的機(jī)會打開了生態(tài)系統(tǒng)。例如，我們預(yù)計(jì)能夠操作和管理復(fù)雜系統(tǒng)的技術(shù)含量較低的用戶將會增加。WHITEPAPER云人工智能的挑戰(zhàn)重要的是要注意，CNAI的挑戰(zhàn)在不同的角色之間會有所不同。26而且，盡管ClodNative的靈活，可擴(kuò)展的平臺非常適合AI工作負(fù)載，但AI的規(guī)模和延遲需求帶來了挑戰(zhàn)，并暴露了CN技術(shù)中的差距，同時(shí)也帶來了機(jī)會。我們在端到端ML流水線的背景下梳理這些內(nèi)容。27在文獻(xiàn)中也稱為MLOps.28傳統(tǒng)的時(shí)間和空間，并行性和同步權(quán)衡的問題都存在，暴露了易于使用的差距?？偠灾?，ML生命周期如下所示：周期典型的ML管道包括：?數(shù)據(jù)準(zhǔn)備（收集、清洗/預(yù)處理、特征工程）?模型訓(xùn)練（模型選擇、架構(gòu)、超參數(shù)調(diào)優(yōu)）?CI/CD,模型注冊表（存儲）?模型服務(wù)?可觀察性（使用負(fù)載、模型漂移、安全性）訓(xùn)練、相似性搜索和模型大?。ㄌ貏e是LLM）中涉及的數(shù)據(jù)量，每個驅(qū)動器內(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)重要。讓我們更深入地探討每個管道階段的挑戰(zhàn)。鼓勵讀者考慮與其領(lǐng)域相關(guān)的其他挑戰(zhàn)，并添加到對話中。數(shù)據(jù)準(zhǔn)備作為AI/ML管道的第一階段，數(shù)據(jù)準(zhǔn)備可能會帶來各種挑戰(zhàn)。這些可以大致分為三大類：管理大數(shù)據(jù)大小，確保開發(fā)和部署期間的數(shù)據(jù)同步以及遵守?cái)?shù)據(jù)治理策略。WHITEPAPER數(shù)據(jù)大小構(gòu)建更好的AI/ML模型的數(shù)據(jù)需求增長速度快于摩爾定律，每18個月翻一番。30無論是數(shù)據(jù)管理/處理、數(shù)據(jù)處理還是數(shù)據(jù)分析，構(gòu)建AI/ML模型的數(shù)據(jù)需求都在快速升級。因此，分布式CloudNative計(jì)算和高效的數(shù)據(jù)移動和存儲對于彌合這些計(jì)算需求和硬件能力之間的差距至關(guān)重要。數(shù)據(jù)同步數(shù)據(jù)可能需要以不同的格式從多個不同的位置獲得；開發(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)試問題。這個過程是低效的并且通常是無效的。盡管有更好的可觀察性工具和容器技術(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ù)量是一個貫穿各領(lǐng)域的問題，也體現(xiàn)在訓(xùn)練階段。數(shù)據(jù)治理數(shù)據(jù)治理對于建立信任和確保負(fù)責(zé)任的AI開發(fā)至關(guān)重要。應(yīng)該考慮關(guān)于數(shù)據(jù)治理的三個關(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)和譜系：必須明確定義從收集到使用的整個AI生命周期中誰擁有和有權(quán)訪問數(shù)據(jù)。應(yīng)使用數(shù)據(jù)沿襲跟蹤工具來了解數(shù)據(jù)如何通過系統(tǒng)流動，確保透明度和問責(zé)制。這樣做有助于防止對敏感信息的未經(jīng)授權(quán)的訪問和濫用。WHITEPAPER3.緩解偏差:人工智能模型僅與所訓(xùn)練的數(shù)據(jù)一樣好。因此，必須積極監(jiān)控和解決數(shù)據(jù)和算法中的潛在偏差。這包括使用不同的數(shù)據(jù)集，采用公平性指標(biāo)，并不斷評估模型以確保其提供公平和道德的結(jié)果，包括捕獲其局限性。ModelCards33正在不斷發(fā)展以捕獲這些結(jié)果。數(shù)據(jù)隱私和安全是一個跨領(lǐng)域的問題，需要在每個階段加以考慮。模型訓(xùn)練模型訓(xùn)練數(shù)據(jù)量呈指數(shù)級增長，導(dǎo)致需要分布式處理和加速器來實(shí)現(xiàn)更多的并行性。進(jìn)一步的訓(xùn)練是一個迭代的多步驟過程，這使得擴(kuò)展成為一個復(fù)雜的多組件協(xié)調(diào)任務(wù)。我們在本節(jié)中更詳細(xì)地回顧了這些方面。不斷上升的加工需求LLM正在迅速突破界限，以滿足不斷增長的AI/ML訓(xùn)練和推理計(jì)算需求，加速器正在變得流行。這些范圍從多個供應(yīng)商的GPU與谷歌的張量處理單元（TPU），英特爾的高迪，甚至現(xiàn)場可編程門陣列（FPGA）不同的功能。這些多樣化的計(jì)算資源需要虛擬化支持、驅(qū)動程序、配置和共享它們的能力以及CN調(diào)度器增強(qiáng)功能。此外，這些加速器有限的可用性和成本促使人們探索多云資源帶寬，甚至是sy34計(jì)算。在GPU虛擬化和動態(tài)分配方面，將CN技術(shù)用于AI可能會很復(fù)雜。vGPU，MIG，MPS（請參閱詞匯表）和動態(tài)資源分配（DRA）等技術(shù)使多個用戶可以共享單個GPU，同時(shí)在Pod中的容器之間提供隔離和共享。它們可以提高GPU利用率，從而降低成本，此外還可以允許多個工作負(fù)載同時(shí)受益。但是，實(shí)施需要仔細(xì)的編排和管理，尤其是在動態(tài)分配和釋放資源時(shí)。AI和CN工程團(tuán)隊(duì)之間的緊密協(xié)作是確保順利和高效集成的必要條件。成本效率云原生環(huán)境固有的彈性和可擴(kuò)展性允許組織根據(jù)波動的需求動態(tài)調(diào)配和擴(kuò)展資源。這一點(diǎn)也適用于AI任務(wù)。However,resourcepropersizingandreactivescheduingtomeetvaryingworkloaddemandareevenmorecompliantinthecontextofacceleratorssuchasGPU,whichareexpensibleandlimitedinsupply.Itdrivestheneedtobeableto細(xì)分GPU更好地利用它們。在模型服務(wù)期間減少碳足跡可以使用自動擴(kuò)展服務(wù)框架來實(shí)現(xiàn)，該框架根據(jù)需求動態(tài)調(diào)整資源。36KServe，37一個LFAI和DataFodatio項(xiàng)目，提供了這樣的功能?？沙掷m(xù)能力38可以通過各種方式得到顯著改善,例如使用更小、更專業(yè)的模型、使用專家的混合以及諸如壓縮和蒸餾的技術(shù)。將ML服務(wù)分配到由可再生或更清潔能源提供動力的地理區(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ò)展,每個微服務(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)度支持是一個機(jī)會領(lǐng)域。自定義依賴項(xiàng)AI應(yīng)用程序通常依賴于特定的框架和版本的庫，這些依賴關(guān)系可能無法輕易獲得或與標(biāo)準(zhǔn)容器映像兼容。由于許多AI工作負(fù)載受益于GPU加速，因此擁有必要的GPU驅(qū)動程序和庫來支持在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)通信原語。不同版本的庫可能會導(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ù)通常只需要一個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管道中的每個階段作為單獨(dú)的微服務(wù)來處理。許多組件可能使保持和同步它們的輸出和切換具有挑戰(zhàn)性。即使用戶只想在筆記本電腦上使用這些解決方案，他們可能仍然需要創(chuàng)建數(shù)十個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è)知識和/或興趣之外學(xué)習(xí)許多系統(tǒng)。第三，在ML模型生命周期中集成來自不同系統(tǒng)的每個階段時(shí)，成本會大大增加。Samsara工程博客47提到，它的ML生產(chǎn)管道托管在幾個微服務(wù)中，具有單獨(dú)的數(shù)據(jù)處理、模型推理和業(yè)務(wù)邏輯步驟。拆分基礎(chǔ)架構(gòu)涉及復(fù)雜的管理以同步資源，從而減慢了開發(fā)和模型發(fā)布的速度。然后，使用Ray，Samsara構(gòu)建了一個統(tǒng)一的ML平臺。增強(qiáng)了他們的生產(chǎn)ML管道性能，為公司提供了近50%的年度ML推斷總成本，這主要源于資源共享和消除了各個階段的序列化和反序列化。這些問題凸顯了對基于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ū)與多個ClodNative社區(qū)廣泛合作，例如Kbeflow，48Kee，49GoogleGKE，50和OpeShift.51。模型放置理想情況下，用戶喜歡在單個集群中部署多個可能不相關(guān)的模型進(jìn)行推理，同時(shí)也尋求共享推理框架以降低成本并獲得模型隔離。此外，對于彈性，他們希望在不同的故障區(qū)域中復(fù)制副本。Kberetes提供了親和力和反親和力機(jī)制來調(diào)度不同拓?fù)溆蛑械墓ぷ髫?fù)載（例如Procedre，zoe，ode52但可用性改進(jìn)可以幫助用戶利用這些功能。資源分配模型服務(wù)主要需要處理模型參數(shù)。參數(shù)的數(shù)量和表示大小指示所需的內(nèi)存。除非處理萬億參數(shù)LLM，否則這些通常只需要GPU的一部分。這凸顯了需要能夠分割昂貴的加速器，如GPU。DRA項(xiàng)目53仍處于alpha狀態(tài)，旨在使GPU調(diào)度更加靈活。另一個考慮因素是響應(yīng)延遲，這在很大程度上取決于用例。例如，在自動駕駛環(huán)境中檢測道路上的物體所需的響應(yīng)延遲比創(chuàng)建圖像或?qū)懺姇r(shí)的可容忍低幾個數(shù)量級。其他服務(wù)實(shí)例可能需要為高負(fù)載條件下的低延遲應(yīng)用程序啟動。如果可以實(shí)現(xiàn)所需的延遲，這些應(yīng)用程序可能會降落在CPU、GPU或其他計(jì)算資源上。在Kubernetes中，對可用資源的這種級聯(lián)機(jī)會調(diào)度的支持仍在不斷發(fā)展。WHITEPAPER此外，事件驅(qū)動的托管是不浪費(fèi)資源和降低成本的理想選擇。Kberetes事件驅(qū)動自動縮放（KEDA）54項(xiàng)目非常適合這里，前提是模型加載延遲可以容忍仍然提供端到端服務(wù)延遲。這里的一個機(jī)會是通過以O(shè)peCotaierIitiative55(OCI)格式交付模型來為模型共享提供更好的支持，OCI是一種適用于共享的不可變文件系統(tǒng)。另一種解決方案是將AI用于CN，特別是預(yù)測使用情況，并主動浮動或關(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，他們就會欣賞云技術(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è)置可能會產(chǎn)生較差的性能。一旦在給定的Kberetes平臺上針對特定的訓(xùn)練工作負(fù)載進(jìn)行了優(yōu)化，就不能保證它將在另一個平臺或訓(xùn)練任務(wù)或包含不同庫的容器捆綁上執(zhí)行同樣的操作。這會影響工作負(fù)載的可移植性和易用性。上一段只看了AI管道中的一個階段，通常是多階段，涵蓋數(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)造一個更加用戶友好的開源產(chǎn)品體驗(yàn)，需要一個強(qiáng)大的產(chǎn)品開發(fā)重點(diǎn)。集成像JupyterLab這樣的工具，它包含了類似IDE的體驗(yàn)空間，這些體驗(yàn)可能存在于當(dāng)今可用的AI/ML工具（例如KubeflowKatibAPI）中，這將使ML從業(yè)者能夠更快地迭代他們的AI開發(fā)，而在多個用戶界面上的上下文切換更少。JupyterLab的可擴(kuò)展特性為ML從業(yè)者提供了一個工作區(qū)，可以在熟悉的工具中構(gòu)建，部署和監(jiān)視AI/ML工作負(fù)載,而無需學(xué)習(xí)新的工具和界面。甚至可以使用JupyterLab使用像Elyra56這樣的GUI工作流構(gòu)建工具以及Kubeflow管道來安排在各個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)建功能、將功能存儲到磁盤，然后將這些功能讀回內(nèi)存以用于訓(xùn)練工作負(fù)載。RayData59或基于ArrowFlightRPC構(gòu)建的數(shù)據(jù)緩存微服務(wù)等解決方案可能會顯著提高訓(xùn)練工作負(fù)載第一階段的輸入/輸出開銷。WHITEPAPERML工具很復(fù)雜，用戶通常需要幫助才能在Kubernetes上部署它們。識別和部署GPU的適當(dāng)驅(qū)動程序并使其與用戶的AI/ML兼容是不平凡的工作負(fù)載。應(yīng)簡化和改進(jìn)現(xiàn)有ML工作負(fù)載的升級路徑，類似于其他Kubernetes控制平面組件。用戶應(yīng)獲得有關(guān)如何使其AI工作負(fù)載適應(yīng)Kubernetes升級和集群停機(jī)的明確指南。影響易用性的另一個方面是多租戶，使用配額和名稱空間。非管理員用戶需要幫助來確定他們可用的系統(tǒng)資源。通常，管理員提供工具(例如，Grafana儀表板)以實(shí)現(xiàn)可觀察性；當(dāng)缺乏這些工具時(shí)，非專家/非管理員用戶會陷入困境。最后，調(diào)試是具有挑戰(zhàn)性的，在分布式環(huán)境中更是如此，當(dāng)處理管道包括多個復(fù)雜服務(wù)時(shí)更是如此。硬件和軟件故障可能或多或少是明確的，并且很容易識別云用戶，但人工智能從業(yè)者可能需要幫助來查看故障的完整情況。例如，NCCL終止錯誤可能是模糊的，有許多可能的原因，每個原因都需要調(diào)查。用戶可能需要將錯誤消息解析給管理員以獲得進(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é)合上述后端工作，需要前端支持在啟動工作負(fù)載時(shí)請求GPU子單元并對其進(jìn)行配置。為了滿足這一需求，Kubernetes引入了一個新的API，動態(tài)資源分配(DRA)6061作為v1.26中的alpha。該API為管理專用硬件資源提供了更大的靈活性，特別是：?網(wǎng)絡(luò)連接資源?資源請求的任意參數(shù)?任意、特定于資源的設(shè)置和清理操作?自定義匹配資源請求與可用資源，包括處理可選請求。WHITEPAPER?與現(xiàn)有方法相比，DRAAPI提供了幾個優(yōu)點(diǎn)：-可以通過開發(fā)和部署DRA驅(qū)動程序來添加自定義硬件，而無需修改核心Kubernetes代碼庫-供應(yīng)商可以定義資源參數(shù)-資源可以在容器和Pod之間共享成本控制AI/ML可以迅速成為預(yù)算黑洞。自動化資源分配和擴(kuò)展流程以優(yōu)化AI云成本至關(guān)重要。微服務(wù)可以根據(jù)需要單獨(dú)擴(kuò)展。此外,它非常適合使用Kubernetes自動擴(kuò)展功能，這將進(jìn)一步幫助正確調(diào)整活動實(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大流行期間，隨著越來越多的人戴著口罩，面部識別系統(tǒng)可能會退化。同樣，由于自然災(zāi)害或利率變化等外部因素,房價(jià)預(yù)測模型可能會偏離現(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ò)可能會出現(xiàn)異常。例如，GPU內(nèi)存中的錯誤或無法訪問的節(jié)點(diǎn)可能會導(dǎo)致作業(yè)崩潰。但是，可能會出現(xiàn)無法立即識別的問題：例如，訓(xùn)練性能可能會開始下降，而不會報(bào)告任何明顯的硬件故障。在這些情況下，只有深度診斷才能識別問題。當(dāng)前的度量不會暴露深度診斷的結(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)緩慢會導(dǎo)致聲譽(yù)受損和收入損失。制定全面的災(zāi)難恢復(fù)計(jì)劃至關(guān)重要，可能包括數(shù)據(jù)備份，在多個可用區(qū)中運(yùn)行實(shí)例以及運(yùn)行多個實(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)排放可與多個橫貫大陸的航班相媲美，而由于查詢量高，推斷排放加起來。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ì)的用戶。可持續(xù)發(fā)展的動力為創(chuàng)新提供了機(jī)會。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é)提供了一個前瞻性的方法來主動實(shí)施CNAI。我們從建議（或行動）開始，然后列舉現(xiàn)有但不斷發(fā)展的解決方案（即CNAI軟件最后考慮進(jìn)一步發(fā)展的機(jī)會。建議靈活性從用于接口的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)度、自動擴(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ù)荷。自定義平臺依賴項(xiàng)我們建議確保CloudNative環(huán)境具有所需的GPU驅(qū)動程序，并支持針對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)備、功能存儲、培訓(xùn)、調(diào)優(yōu)、模型注冊和服務(wù)的最佳可用開源工具，可以幫助團(tuán)隊(duì)快速開始進(jìn)行機(jī)器學(xué)習(xí)，并利用云的強(qiáng)大功能有效地?cái)U(kuò)展工作。考慮將一套復(fù)雜的技術(shù)組合成一個功能和可擴(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工具的一個例子。使用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生命周期的每個階段實(shí)現(xiàn)了單獨(dú)的微服務(wù)。例如，使用KbeflowTraiigOperator。對于分布式訓(xùn)練，Katib用于超參數(shù)調(diào)優(yōu)微調(diào)，KubeflowKServe用于模型服務(wù)。這允許用戶將單個Kubeflow組件集成到他們的ML基礎(chǔ)設(shè)施中或使用Kubeflow作為端到端ML平臺。上下文-向量數(shù)據(jù)庫LLM在某個時(shí)間點(diǎn)使用大量的，通常是公開可用的數(shù)據(jù)進(jìn)行訓(xùn)練。我們通過提示與他們進(jìn)行交互。但是為了使響應(yīng)更有價(jià)值，而無需用戶輸入更長或更多的提示并可能檢索更多特定領(lǐng)域的響應(yīng)，“豐富”是有幫助的提示。這是矢量數(shù)據(jù)庫的來源。它們是矢量的巨大索引存儲，是數(shù)字形式的數(shù)據(jù)的數(shù)學(xué)表示。嵌入是每個附加數(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ù)方面可能會有所不同。一些產(chǎn)品包括Redis，73Milvus，74Faiss，75和Weaviat.76可觀測性-OpenLLMetryOpeLLMetry77是一個構(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ī)會CNCF項(xiàng)目景觀包括CNCF，LFAI79和Data在內(nèi)的多個LinuxFoundation（LF）小組以及AIAlliance等合作伙伴80以上，為AI和云工程師都可以使用的AI項(xiàng)目提供了一個樞紐?，F(xiàn)有工具，例如CloudNativeLandscape，81可以鳥瞰CN生態(tài)系統(tǒng)。下圖列出了按功能區(qū)域分組的已建立和正在發(fā)展的項(xiàng)目。ML工具任務(wù)思維導(dǎo)圖WHITEPAPERCNAI兒童和學(xué)生孩子們已經(jīng)每天使用像ChatGPT這樣的AI輔助技術(shù)，不知道它們是如何工作的?，F(xiàn)代人工智能的基礎(chǔ)，如辨別和生成人工智能算法，是一個孩子甚至技術(shù)精湛的父母都不理解的黑匣子，所以很難對它產(chǎn)生興趣。學(xué)生的教育不僅應(yīng)將ChatGPT之類的LLM視為理所當(dāng)然，還應(yīng)包括神經(jīng)網(wǎng)絡(luò)和機(jī)器學(xué)習(xí)算法的基礎(chǔ)知識，以解釋AI技術(shù)的工作原理以及如何在未來的職業(yè)生涯中更好地使用它們。ClodNative社區(qū)和KbeCo的CNCFKidsDay82等成功計(jì)劃提供了有關(guān)ClodNative和AI技術(shù)的教育機(jī)會。盡早向孩子們介紹AI技術(shù)也將防止困擾計(jì)算機(jī)科學(xué)的多樣性，公平性和包容性問題。AI是一種平等的技術(shù)，因?yàn)槊總€種族，性取向和社會經(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ù)在社會中無處不在，我們必須確保學(xué)生跟上AI和CloudNative技術(shù)的進(jìn)步。Participation隨著AI的發(fā)展，更多的教育和參與機(jī)會發(fā)生。有AI專家的空間（例如。Procedre,Ph.D.在ML中對數(shù)據(jù)科學(xué)家)和AI通才(例如Procedre、運(yùn)營商和最終用戶)。MOOCs83和認(rèn)證等教育項(xiàng)目已經(jīng)出現(xiàn)，專注于各個方面的AI工具和技術(shù)。專業(yè)社團(tuán)（e。Procedre，ACM84和IEEE85）和聚會提供了面對面學(xué)習(xí)和討論挑戰(zhàn)的機(jī)會。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ì)問題對弱勢群體造成不利影響，例如，推薦算法無意中推廣基于仇恨、暴力、極端主義的材料。它們也可能是由于個人或團(tuán)體惡意使用系統(tǒng)和/或工具來故意傷害，例如使用生成性AI工具來創(chuàng)建錯誤信息和虛假信息活動，或者個人故意將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個系統(tǒng)來提供信任和安全周期的每個部分，包括識別和評估潛在的暴力行為，對案件進(jìn)行分類和優(yōu)先排序，制定和記錄執(zhí)法決策，選擇和應(yīng)用干預(yù)措施以及收集威脅情報(bào)。除了對互聯(lián)網(wǎng)的安全和健康至關(guān)重要之外，如果在設(shè)計(jì)時(shí)沒有適當(dāng)考慮，這些系統(tǒng)可能會產(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這種主動和預(yù)防性的方法側(cè)重于將安全嵌入到組織的文化和領(lǐng)導(dǎo)中。它強(qiáng)調(diào)問責(zé)制，旨在為每個人培養(yǎng)更積極，文明和獎勵的在線體驗(yàn)。有越來越多的專家來幫助這些發(fā)展最佳做法，例如全球反恐互聯(lián)網(wǎng)論壇（GIFCT93技術(shù)聯(lián)盟，94和互聯(lián)網(wǎng)協(xié)會。95AllTech是該領(lǐng)域的人類專家名單，可以提供與關(guān)鍵資源的鏈接。96AIAlliace97計(jì)劃（IBM，Meta和50多個機(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工程師將在未來幾個月或幾年內(nèi)成為數(shù)據(jù)科學(xué)、基礎(chǔ)設(shè)施和開發(fā)之間的粘合劑。重要的是要知道這個行業(yè)領(lǐng)域正在發(fā)展，角色頭銜可能會波動；只有時(shí)間才能證明。不同的術(shù)語也可能成為現(xiàn)實(shí)。將來，該角色將需要更多地關(guān)注AI工具，以及部署AI鏈和代理。WHITEPAPERCLOUDNATIVE的人工智能本文主要關(guān)注支持AI開發(fā)和使用的ClodNative。但AI可以通過多種方式增強(qiáng)ClodNative，包括預(yù)測負(fù)載和更好的資源調(diào)度，特別是涉及多個優(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)用。它還支持啟動混沌測試，以確定服務(wù)彈性，掃描CVE等。它是Kberetes集群更直觀的編排和管理的先驅(qū)，并及時(shí)降低了管理員和站點(diǎn)可靠性工程師的學(xué)習(xí)曲線。安全機(jī)器學(xué)習(xí)可以分析大量數(shù)據(jù)集，以快速識別模式并預(yù)測系統(tǒng)中的潛在威脅或弱點(diǎn)。將AI集成到Redteamig100中可以加速識別安全漏洞，并使組織能夠加強(qiáng)對新興網(wǎng)絡(luò)威脅的防御。檢測異常網(wǎng)絡(luò)行為的ML模型可以輕松地用于集群中，以保護(hù)工作負(fù)載，或用于邊緣部署的集群隊(duì)列。更智能的編排/調(diào)度AI可以分析日/周/月的歷史集群使用情況，以識別工作負(fù)載模式和資源可用性，了解何時(shí)以及如何部署工作負(fù)載，是水平擴(kuò)展還是垂直擴(kuò)展，何時(shí)在幾個節(jié)點(diǎn)上整合工作負(fù)載以使其他節(jié)點(diǎn)處于靜止?fàn)顟B(tài)以節(jié)省電量，甚至將其從集群中刪除以降低成本。ML驅(qū)動的模型可以優(yōu)化任務(wù)排序，自動化決策過程，并提高工作負(fù)載管理的整體效率。自然語言接口有助于整個編排和調(diào)度過程。這些增強(qiáng)功能將使組織更容易在動態(tài)云環(huán)境中管理和安排復(fù)雜的工作流。正在構(gòu)建處理器電源模型，以幫助規(guī)劃和優(yōu)化以降低功耗。飛行中和探索中的AI集成努力?微調(diào)自定義LLM以分析日志。?MLOps管道，用于捕獲和維護(hù)數(shù)據(jù)來源。?OpenTelemetry.101等CNCF項(xiàng)目的AI語義約定?AI驅(qū)動的開發(fā)環(huán)境(IDE)用于開發(fā)和部署AI應(yīng)用程序。我們希望在不遠(yuǎn)的將來報(bào)告這一領(lǐng)域的進(jìn)展。WHITEPAPERConclusion人工智能（AI）和云原生（CN）技術(shù)的結(jié)合為組織提供了開發(fā)前所未有的功能的絕佳機(jī)會。借助云原生基礎(chǔ)設(shè)施的可擴(kuò)展性、彈性和易用性，AI模型可以更高效、更大規(guī)模地進(jìn)行訓(xùn)練和部署。本白皮書深入研究了這兩個領(lǐng)域的交集，討論了組織利用這種有效組合的當(dāng)前狀態(tài)、挑戰(zhàn)、機(jī)遇和潛在解決方案。雖然仍然存在一些挑戰(zhàn)，包括管理復(fù)雜AI工作負(fù)載的資源需求，確保AI模型的可重復(fù)性和可解釋性，以及簡化非技術(shù)從業(yè)者的用戶體驗(yàn)，但ClodNative生態(tài)系統(tǒng)正在不斷發(fā)展以解決這些問題。像Kbeflow、Ray和KbeRay這樣的項(xiàng)目為在云中運(yùn)行AI工作負(fù)載提供了更加統(tǒng)一和用戶友好的體驗(yàn)。此外，對GPU調(diào)度，矢量數(shù)據(jù)庫和可持續(xù)性的持續(xù)研究為克服局限性提供了有希望的解決方案。隨著AI和CloudNative技術(shù)的成熟，擁有這種協(xié)同作用的組織將處于有利地位，以釋放顯著的競爭優(yōu)勢。從自動化復(fù)雜任務(wù)和分析大量數(shù)據(jù)集到生成創(chuàng)造性內(nèi)容和個性化用戶體驗(yàn)，可能性是無窮無盡的。通過投資合適的人才、工具和基礎(chǔ)設(shè)施，組織可以利用AI和云原生技術(shù)的強(qiáng)大功能，可推動創(chuàng)新、優(yōu)化運(yùn)營并提供卓越的客戶體驗(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í)模型。開發(fā)人員在本文的上下文中，它是指（不限于）軟件工程師，前端工程師，后端工程師，全棧工程師，軟件架構(gòu)師和軟件測試員。其主要職責(zé)包括編寫和測試軟件，包括用戶界面，微服務(wù)和后端軟件。WHITEPAPER部署人員在本文的上下文中，它是指（不限于）DevOps工程師，站點(diǎn)可靠性工程師，基礎(chǔ)架構(gòu)架構(gòu)師，應(yīng)用程序管理員，群集管理員。主要職責(zé)包括將軟件和云基礎(chǔ)架構(gòu)部署到多個環(huán)境（包括開發(fā)，暫存和生產(chǎn)）。DRADRA代表動態(tài)資源分配。它是對Pod的一般資源聲明和配置的API抽象，允許第三方供應(yīng)商按需提供HW/SW資源，而無需重寫Kubernetes核心API。LLM“LLM”代表“大型語言模型”。大型語言模型是在大量文本數(shù)據(jù)上訓(xùn)練的人工智能模型，用于理解和生成類似人類的文本。LLM是專門為自然語言處理(NLP)任務(wù)設(shè)計(jì)的機(jī)器學(xué)習(xí)模型的子集。LLMOpsLLMOps代表大型語言模型操作，包含專門為大型語言模型（LLM）量身定制的操作方面。從本質(zhì)上講，LLMOps是MLOps原則和工具的適應(yīng)LLM支持的應(yīng)用程序的獨(dú)特要求，涵蓋了從開發(fā)到部署和維護(hù)的整個生命周期。MIG多實(shí)例GPU技術(shù)是一項(xiàng)創(chuàng)新，它允許將單個物理GPU（圖形處理單元）劃分為多個更小的實(shí)例，每個實(shí)例都作為一個獨(dú)立的GPU運(yùn)行，具有自己的資源和功能。該技術(shù)增強(qiáng)了數(shù)據(jù)中心和云計(jì)算環(huán)境中的GPU利用率和靈活性。MLOpsMLOps是機(jī)器學(xué)習(xí)操作的縮寫，是指用于簡化和自動化機(jī)器學(xué)習(xí)模型在生產(chǎn)環(huán)境中的部署、監(jiān)控和管理的實(shí)踐、方法和工具。MLOps旨在彌合機(jī)器學(xué)習(xí)開發(fā)和運(yùn)營之間的差距，確保機(jī)器學(xué)習(xí)模型的高效、可靠和大規(guī)模部署。它涉及結(jié)合軟件工程原則、DevOps實(shí)踐和專用工具，實(shí)現(xiàn)端到端ML生命周期的自動化，包括數(shù)據(jù)準(zhǔn)備、模型訓(xùn)練、模型部署、監(jiān)控和維護(hù)。MLOps可幫助組織加速其ML項(xiàng)目，提高模型性能，并在ML管道中保持一致性和可靠性。MPSMPS在GPU計(jì)算中代表多進(jìn)程服務(wù)，MPS技術(shù)允許多個GPU加速的應(yīng)用或進(jìn)程共享單個物理GPU，同時(shí)保持隔離和高效RAGWHITEPAPER在AI的背景下，RAG代表“檢索增強(qiáng)生成”。“這是一個模型架構(gòu)，結(jié)合了基于檢索的模型和生成模型來生成文本。RAG的生成過程通過檢索機(jī)制增強(qiáng)，該機(jī)制可幫助模型從廣泛的數(shù)據(jù)庫或知識庫中訪問相關(guān)信息。該檢索組件允許模型將外部知識合并到生成過程中，從而提高生成文本的質(zhì)量和相關(guān)性。vGPUvGPU（即虛擬圖形處理單元）技術(shù)使多個虛擬機(jī)（VM）共享單個物理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/動態(tài)資源分配/37https://github.com/kserve/kserve/38[2112.06905]GLaM：使用專家混合的語言模型的有效擴(kuò)展39面向云的多集群Kubernetes環(huán)境中的碳感知工作負(fù)載調(diào)度程序WHITEPAPER