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

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