![]()
基礎設施可能是許多組織在將AI從概念驗證擴展到生產環境時遭遇失敗的根本原因。微軟最新的AI基礎設施狀況報告顯示,幾乎每家公司都提到了在擴展和運營AI方面的挑戰,超過半數來自各行業和地區的1500多位商業領袖表示,他們沒有合適的基礎設施來支持想要運行的AI工作負載——這一比例在其他調查中也得到了印證。
當你開始構建、部署和運營AI模型時,才會發現你的基礎設施到底有多現代化,以及它在哪些方面讓你失望。數字基礎設施公司Colt Technology Services的首席AI和平臺官Frank Miller表示:"在傳統架構上運行AI就像通過撥號網絡傳輸4K視頻一樣,你可以說服自己這會奏效,但現實卻大不相同。"
如果你不想被困在不斷救火的狀態中,只為了維持你花費巨資的AI系統正常運行,你需要同時具備治理能力和現代化架構。Miller補充說:"這意味著用混合的、云原生設計來替換僵化的傳統系統,以便為AI工作負載提供擴展能力。高帶寬、低延遲的連接確保快速數據訪問;冗余和自動故障轉移提供連續性;零信任安全和加密保護敏感的AI流程。添加可觀測性和預測性監控有助于在問題干擾操作之前預先發現問題,創建一個彈性、安全且為AI創新做好準備的基礎設施。"
IDC集團副總裁Daniel Saroff建議將此視為技術債務,因為大多數企業都低估了AI對連接性和計算能力的壓力。孤立的基礎設施無法提供AI所需的支持,CIO需要以更加整合的方式思考這些及其他問題,以使AI取得成功。他說:"你必須考慮你的GPU基礎設施、帶寬、網絡可用性以及各個應用程序之間的連接。如果你的環境沒有為高事務性、GPU密集型環境而設置,你就會遇到問題。擁有非常分散的基礎設施意味著你需要提取數據并整合多個不同的系統,特別是當你開始考慮智能體AI時。"
訓練、RAG和智能體工作流假設數據不僅正確,而且始終可達,且不會被瓶頸阻塞。像MCP這樣的常見API技術正在成為標準化數據訪問的方式,傳統系統可能無法輕松支持這一點。
擅長GPU運用
彈性對企業IT來說并不是什么新概念。高可用性、故障轉移和災難恢復是如此普遍的需求,以至于微軟添加到Azure Copilot的前六個智能體中就有一個專門用于改善云端的彈性。在本地,企業擁有數十年的基礎設施經驗可供借鑒,但這很少包括昂貴的GPU和其他加速器,而這些正是AI的關鍵,無論你是在訓練還是運行推理。
它們的要求也更高,無論是需要使用正確的驅動程序和操作器自動配置GPU Kubernetes集群的額外復雜性,還是構建更難維護的專用AI基礎設施,以及需要高速網絡處理具有陌生且快速變化模式的分布式流量。
VAST Data國際系統工程副總裁Jason Hammons說:"構建GPU基礎設施真的很困難。由于其大規模并行特性,它很脆弱,但也因為其組件性。它們只是要復雜得多。"
AI需要具有低延遲和關鍵可預測延遲的高帶寬網絡,以傳輸大量數據負載和小量推理及API調用負載。這可能意味著你的企業網絡至少有一部分看起來更像云數據中心中的網絡,可能配備SmartNIC、InfiniBand或RoCE,以及像SONiC這樣的可編程網絡操作系統,還有到AI數據中心和云API的直接路由的穩定鏈路。
Hammons表示,如果企業在GPU集群內部擁有高速網絡,就能提供良好的AI體驗,但構建智能體在存儲和網絡方面的要求更高。他說:"當你開始擴展智能體工作負載時,由于它們表現出的復雜I/O模式,維持這些系統運行的復雜性可能會加劇。"
智能路由和底層優化在AI中更為重要,負載均衡變得比以往任何時候都更加重要,需要智能的自適應路由和動態的多路徑I/O,這樣一個擁塞或不健康的路徑就不會中斷AI管道。你必須給關鍵AI流量足夠高的優先級,以支持你的工作負載,同時不妨礙ERP和支付服務等關鍵生產系統,或VoIP和視頻會議。
軟件開發商Fastly的CTO Artur Bergman表示:"AI工作流更依賴于網絡。你必須跨機器擴展,這與那些沒有這種網絡或延遲要求級別的企業工作負載相比是一個相當大的轉變。"
現在不再只是要避免關鍵故障或從中快速恢復。你還必須為優雅降級設計系統,這樣當出現故障時,它們仍能表現得足夠好。
同樣,彈性AI需要的不僅僅是你習慣用于任何生產工作負載的同步復制。Hammons說:"許多這些系統需要跨站點進行負載均衡,并在多個域之間具有冗余性。"這種復雜性甚至讓成熟的組織轉向CoreWeave等提供商以及他稱之為AI原生新云。
API采用混合方法幾乎是普遍的。無論你是突發到AI數據中心、在超大規模GPU基礎設施和云數據庫上構建,還是調用云API,你都需要考慮這些連接。這意味著更新傳統網絡并考慮多個連接提供商以實現冗余。
如果你在邊緣進行AI,特別是在工廠和零售等近實時環境中,你還必須考慮分布式可靠性,以及在各站點間提供推理或更新本地模型以保持一致性所需的連接性和延遲。
Bergman說:"跨云通信只會增長。"Fastly的客戶已經在那里保存訓練集數據,這樣他們就可以在多個云中使用它。"我們可以將其輸入到所有云中,而不產生云出口費用。"
他建議,當智能體代表員工行事時,對智能體訪問權限和特權進行身份驗證可能在未來增加復雜性。這不需要低級網絡更改,但在應用層,他預測需要發生大量演進,以便這些事物能夠以安全、可靠的方式擴展。
扁平化你的架構
云服務提供商Leaseweb的CEO Richard Copeland表示,如今大多數AI采用都發生在從未為這種波動性級別設計的架構上。他補充說:"每個人都想要AI的魔力,但當他們擴展時,他們就會面對數據重力、延遲預算和存儲經濟學的混亂現實。團隊試圖保護端點、擴展管道、添加GPU并增加帶寬,但如果底層基礎不是有意設計為彈性的,這些都無法阻止運營混亂。"
他指出,你幾乎肯定需要更多存儲來支持AI,而不僅僅是訓練集。他說:"你在存儲嵌入、向量索引、模型檢查點、智能體日志、合成數據集,而智能體本身每秒都在產生新數據。"因此,花時間弄清楚你實際需要存儲多少數據、在哪里存儲以及存儲多長時間。
但為連續性而設計意味著將彈性視為設計原則,而不是保險政策。Copeland說,保持領先地位的組織正在扁平化架構,將計算推向更接近數據的位置,自動化生命周期政策,并構建AI管道可以故障轉移而無人費力的環境。
扁平化架構也減少了技術債務,但大多數企業已經積累了如此多層的工具、代理、隊列、存儲層和檢查點,以至于他們的AI管道表現得像魯布·戈德堡機器。他補充說:"數據必須在到達需要它的模型之前在該堆棧中上下爬行,每一跳都增加延遲、脆弱性和運營開銷。"
找出延遲的來源,你可能會發現不需要的系統。他繼續說:"刪除冗余中間件,自動化數據放置和生命周期政策,并將工作負載轉向數據已經存在的環境。"整合存儲層,將GPU工作負載移動到更簡單的區域或本地環境中,并調優網絡路徑應該允許系統表現可預測而不是混亂。
數據設計
使AI擴展幾乎肯定意味著仔細審視你的數據架構。每個數據庫都為AI添加功能。數據湖倉承諾你可以將運營數據和分析結合在一起,而不影響生產工作負載的SLA。或者你可以使用像Azure Fabric這樣的數據平臺走得更遠,引入流和時間序列數據用于AI應用程序。
如果你已經嘗試了不同的方法,你可能需要重新架構你的數據層,以擺脫分散微服務的運營擴散,在這種情況下,獨立向量存儲、圖數據庫和文檔孤島之間的每次數據移交都會引入延遲和治理間隙。太多故障點使得難以提供高可用性保證。
云AI數據庫平臺SingleStore的首席產品和技術官Nadeem Asghar說:"傳統的數據庫、管道和定制向量存儲的拼湊根本無法跟上AI的延遲、治理和規模要求。統一智能平面將取代今天的分散堆棧,將數據、計算和推理合并到單一實時系統中。"
圖數據庫提供商Memgraph的CEO Dominik Tomicevic建議將形成智能層的模型和智能體與知識層分離,在知識層中,真理、數據和信息存在并需要跨區域或地區的同步或近同步副本。
盡管AI基礎設施意味著處理數據和網絡密集的分布式系統,但他將此視為可解決的工程問題。他說:"彈性AI堆棧始于強類型知識圖或GraphRAG存儲,可以像任何其他關鍵任務數據庫一樣被集群化、復制、備份、監控和訪問控制。"
這給你靈活性來分別擴展搜索和數據節點,甚至在未來更改模型和供應商。這也意味著安全和彈性攜手并進。
他補充說:"圖級別的細粒度訪問控制意味著檢索層永遠不會泄露底層數據庫不允許的數據,即使大語言模型很好奇。在此基礎上,你專門為AI烘焙可觀測性和服務級別目標,如GraphRAG查詢的延遲和錯誤預算、檢索結果的質量指標和模型調用的成本預算。"
建立平臺
從原型轉向提供AI價值的生產部署的壓力意味著個別項目需要政策和最佳實踐來構建,而不是必須自己做出所有正確決策,這樣他們就可以專注于技術問題,如選擇模型而不是構建基礎設施。
如果這聽起來像平臺工程的原則,那就是如何使AI成為能力而不是一系列實驗。IDC的Saroff認為,你已經完成的統一平臺工作流為你提供了流程、API、數據和技術的支柱。你提供包括GPU和加速器的基礎設施,以及多種計算方式、模型的可觀測性、API調用和應用程序,以及成本管理和治理,而不是一遍又一遍地解決相同的問題。
所有這些系統都需要饋入具有近實時反饋的可觀測性和優化工具。你不能等到收到月度云賬單才發現你已經超出預算,或者等到遭遇停機才意識到你依賴的API正在返回錯誤并需要多次重試。API管理是跟蹤使用情況和優化成本的關鍵。
你需要所有這些與現有基礎設施和工作流集成。Domino Data Lab的現場首席數據科學家Jarrod Vawdrey認為:"每家公司都有同樣的問題。你需要AI來競爭,但你所有的實際業務都運行在iPhone出現之前的傳統基礎設施和軟件上。"
他將前置部署工程師定義為在期望的業務成果、傳統系統和現代AI能力之間導航復雜性的翻譯者。"他們可以處理大語言模型并將其與你20年前沒人想碰的ERP系統集成。"
集成將是新的,但基礎不是。技術研究和咨詢公司CCS Insight的企業研究主管Bola Rotibi說,正確做IT就是讓你能夠正確做AI。
好消息是,你可能已經使用了例如云的良好架構框架完成了繁重的工作,因為AI應用程序將繼承該冗余、異常處理和混沌工程。她說:"如果你的架構是為彈性而構建的,那么你很可能已經開始思考支撐AI所需的所有事情。"
當然,所有這些都要花錢。IDC預測,到2027年,組織將意識到他們低估了AI基礎設施成本近三分之一,并將開始對其應用FinOps。
但Rotibi建議,真正的彈性依賴于理解業務和運營環境,形成更加結合、協作的環境。雖然CIO通常難以證明基礎設施投資的合理性,但將其與提供可靠和安全的AI聯系起來,使IT能夠繼續提供與業務優先級一致的價值,而不是被視為成本中心。
Q&A
Q1:為什么很多企業在AI從概念驗證擴展到生產時會失敗?
A:主要原因是基礎設施不足。超過半數企業領袖表示他們沒有合適的基礎設施支持AI工作負載。在傳統架構上運行AI就像通過撥號網絡傳輸4K視頻,現實與期望差距巨大。企業需要用混合云原生設計替換僵化的傳統系統。
Q2:AI對網絡和GPU有什么特殊要求?
A:AI需要高帶寬、低延遲的網絡來處理大量數據傳輸和推理調用。GPU基礎設施構建困難,需要特殊的驅動程序和操作器。AI工作流更依賴網絡,需要跨機器擴展,這與傳統企業工作負載有很大不同。還需要智能路由、負載均衡和自動故障轉移。
Q3:如何構建彈性的AI基礎設施?
A:需要扁平化架構,減少技術債務,將計算推向更接近數據的位置。要建立統一的數據平臺,避免分散的微服務架構。同時需要可觀測性和實時監控,API管理來控制成本,以及與現有系統的集成。將彈性作為設計原則而非事后補救措施。
特別聲明:以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布,本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.