Broadcom VCF 擴展將 AI、安全與復原整合至單一平台

Broadcom 於 11 月 4 日公布最新產品組合擴展，將私有 AI 基礎設施、安全及復原方面的改動，與規模較小的虛擬化產品整合。這次 Broadcom VCF 擴展，將更多企業責任納入其私有雲軟件平台 VMware Cloud Foundation 之中。不過，這項公布涵蓋現有功能、未來發布項目及獨立的進階服務。對於正評估可部署內容及仍需採購項目的客戶而言，這些分別非常重要。

核心取捨在於營運整合。共享基礎設施可減少重複的管理工作，但同時亦會集中有關存取、維護及復原的決策。企業買家必須評估，較廣泛的平台是否真的能簡化其實際營運環境。單靠更長的功能清單，無法回答這個問題。

Nutanix 提供了一個有用的競爭參考，因為它同樣結合基礎設施與企業 AI 管理。因此，Broadcom 的公布屬於更廣泛競爭的一部分，焦點在於企業如何讓 AI 與既有應用程式一同運作。對基礎設施主管而言，眼前的決策是要在多大程度上，將責任整合至共享平台之內。

Broadcom VCF 擴展實際改變了甚麼

這項公布結合產品交付、未來開發及產品組合包裝，當中需要作出不同的部署決策。

Broadcom 的私有雲更新區分了已交付的功能，以及計劃在其 2027 財政年度第一季推出的新增項目。多租戶模型共享已隨 VCF 9.1.1 推出，而機密運算則見於 VCF 9.1。機密運算透過支援的硬件，在處理期間保護資料。

計劃新增的功能包括 AI Infrastructure Quickstart、原生兼容 S3 的物件儲存、基礎設施合規管理、以政策為本的連接，以及原生災難復原。Quickstart 旨在自動化 AI 基礎設施的初始設定。S3 兼容性是指用於儲存和擷取物件的介面，例如檔案及模型構件。

Broadcom 亦在其進階服務產品組合中列出 HyperArmor、Live Recovery 及工作負載合規管理。這些服務與原生基礎設施功能有不同用途。它們的定位相當重要，因為買家需要確認其協議實際涵蓋哪些功能。

實際結果是，發布評估比標題所暗示的更為複雜。基礎設施經理不能把每項已公布功能都視為可即時使用。安全團隊亦不應假設某項進階服務會自動成為其部署的一部分。

一個實用的評估方式，是將交付狀態與架構相關性分開看待。某項功能可以切合公司的需要，卻仍未適合目前的部署時間表。相反，一項已可使用的功能，仍可能需要更換硬件、培訓人員或進行額外驗證。

當團隊圍繞採購期限安排專案時，這種分別尤其重要。公布反映供應商的方向；發布文件說明管理員可安裝甚麼；而合約條款則界定機構可使用甚麼。

Broadcom VCF 擴展亦將基礎設施自動化，與用於管治該基礎設施的控制措施結合。兩者是相關投資，但解決的是不同問題。更快的部署可協助團隊建立環境；管治則決定環境建成後，他們可如何安全地運作。

例如，自動化叢集設定並不能決定哪個部門可存取機密文件。提供儲存空間並不等於建立保留政策。加入復原編排亦不會決定事故後哪個應用程式應最先恢復。

這些屬於分析上的區別，並非公告已證實的不足。Broadcom 的新增功能可支援這些決策，但不會代客戶作出決定。企業仍需要一個營運模式，將技術功能連繫至業務需求。

這個營運模式為評估更新提供合適框架。問題在於，新增功能是否消除特定工作、改善可強制執行的控制，或填補已記錄的復原缺口。若沒有這種連結，產品組合擴展仍然難以轉化為營運價值。

共享 AI 基礎設施令平台團隊承受壓力

集中 AI 模型會將責任轉移至管理存取、容量及服務持續性的團隊。

Broadcom 表示，共享模型基礎設施可服務多個內部單位，同時維持獨立的安全邊界及私有情境。其提出的好處是減少部門之間的重複工作。這是供應商對架構優勢的主張，而非特定客戶環境中節省成本的獨立證據。

其底層機制不難理解。不同部門有時希望使用相似的模型功能，同時處理不同資訊。中央服務提供了一種方式，讓各方共享模型部署，而非刻意共享每個部門的所有資料。

不過，共享令平台團隊所負責的不再只是可用性。它必須界定誰可獲得存取權、互相競爭的要求如何取得資源，以及哪些改動需要批准。即使佈建變得更容易，這些責任仍然存在。

設想一間假設中的機構，設有法務、工程及客戶支援助理。每個助理均使用共享模型服務，但從不同資料庫擷取資訊。基礎設施可以共用，而獲准使用的文件、用戶及操作則可以不同。

這種安排帶來具體的管治挑戰。員工獲准使用模型，並不代表其有權擷取每份已連接文件。同樣地，獲准閱讀某份文件，亦不代表其有權修改另一個業務系統。

這正是 VMware 私有 AI 成為組織決策的原因。基礎設施管理員、應用程式擁有人及安全團隊需要採用相容的存取定義。否則，每個群組都可能以為另一個群組擁有某項實際上無人落實的控制措施。

容量管理帶來另一重壓力。共享服務必須兼顧不同業務優先次序，同時避免單一工作負載耗盡所有可用資源。合適的政策取決於業務需要，而非平台的預設設定。

開發實驗與面向客戶的應用程式，對延遲的容忍度可以截然不同。共享底層基礎設施並不會消除這個差異。平台擁有人需要在資源爭用及維護期間，設法保留這些優先次序。

同一問題亦適用於變更。更新中央部署的模型，可能影響多個依賴它的應用程式。因此，在共享更新進入生產環境前，應用程式團隊需要一套程序來評估行為改變。

這項分析並未證實 Broadcom 的模型共享帶來不可接受的風險。它指出了整合所伴隨的責任。相關比較應在部門重複投入的工作，與營運共同服務所需的紀律之間進行。

企業知識亦有相關區別。基礎設施控制措施建立助理運行的環境；資訊控制措施則決定它可擷取甚麼。知識庫之間的區別，有助說明單靠部署位置無法確定存取政策。

壓力最直接地落在被要求支援 AI、但又不能建立另一個孤立營運環境的基礎設施主管身上。他們需要證明集中化能改善服務交付。這需要有關工作負載行為、管理工作量及權限執行的證據。

對開發人員而言，好處取決於共享平台能帶來甚麼可預測性。一致的申請程序、已記錄的限制及清晰的擁有權，可以與初始部署速度同樣重要。這些條件能將可用的基礎設施，轉化為可用的內部服務。

整合與營運選擇互相競爭

Broadcom 的整合策略，與其他組裝及管治企業 AI 基礎設施的方式競爭。

Nutanix 的企業 AI 控制措施提供了相關比較。其 Enterprise AI 2.8 版本描述細緻的權限、受控模型共享，以及適用於斷網環境的部署選項。該版本亦區分一般可用功能與預覽功能，買家在比較供應商時應保留這種區分。

這項比較呈現的是重疊的優先事項，而非整體勝負。兩種方法均處理企業基礎設施內 AI 資源的存取問題。單靠任何一間供應商的功能清單，均無法證實哪個平台適合特定機構。

Broadcom 客戶可能重視延伸管理員已熟悉的環境。只要新功能配合既有責任，熟悉的程序可減少部分過渡工作。這項優勢取決於客戶的起點，不應被普遍假定。

其他機構可能優先考慮讓基礎設施、模型服務及安全工具能夠獨立替換。這種做法可保留選擇權，但需要團隊維護元件之間的連繫。靈活性本身亦會產生營運責任。

因此，主要張力在於整合式營運與獨立控制之間。整合平台可讓某些工作流程更容易協調。組裝式環境則可提供更大自由度來更換元件，但需要更多整合工作。

這些是架構取捨，而非假定任何一條路徑必然較優的理由。合適選擇取決於員工技能、應用程式相依性、硬件要求，以及機構對變更的容忍度。買家需要直接測試這些條件。

公平的比較應在候選環境中使用相同的代表性工作負載，並檢視部署、存取限制、維護及還原。若只比較初始設定，便會偏向讓開場示範最容易的產品。

工作負載亦應足夠貼近生產環境，以揭示相依性。連接至已核准內部文件的助理，比孤立的聊天機械人示範更具參考價值。其行為同時取決於權限、擷取、模型可用性及應用程式設定。

文件說明在評估中同樣值得重視。團隊需要了解政策存放的位置，以及管理員如何查閱政策。即使某項控制措施在技術上存在，若其行為仍不清晰，實際操作依然可能困難。

疑難排解提供了另一個有用的比較角度。當應用程式出現故障，管理員必須判斷問題是涉及基礎設施、身分、儲存空間，還是應用程式行為。當整合能減少協調工作而有助釐清這類不確定性時，便能帶來價值。

Broadcom 的服務生態系統亦反映實施的重要性。Kyndryl 的 私人雲端聯盟介紹了圍繞 VCF 的顧問服務、現代化改造及技能投資。作為商業合作夥伴，Kyndryl 提供的是支持性的觀點，而非對成果的獨立評估。

不過，其參與仍突顯一個實際要點：軟件功能需要架構和營運準備配合。客戶仍須把供應商產品組合轉化為可運作的政策、職責及程序。評估時，這項工作應與部署所需的投入一併納入考量。

Broadcom 擴展 VCF，強化了其將更多職責整合至 VMware 基礎設施之內的論據。客戶是否接受這個論據，將取決於是否能證明營運摩擦確有減少。競爭產品仍然重要，因為買家可比較不同方式，以達到相同業務要求。

Hypervisor 保護並不能解決應用程式安全問題

保護虛擬化層可處理重要風險，但應用程式及資訊控制仍是獨立責任。

Broadcom 的 hypervisor 保護公告把 HyperArmor 描述為針對 ESX 的預防性防禦措施；ESX 是運行虛擬機器的軟件層。該公司表示，這項方案結合主機層虛擬修補、允許行為控制，以及管理登入流程中的額外驗證。

虛擬修補旨在毋須先更換有漏洞的軟件，也可阻止漏洞遭利用。Broadcom 將此方法定位為在風險暴露期間提供保護。客戶應區分這項說法與保證可防範所有漏洞或攻擊路徑之間的差別。

公告引用 IDC 分析師 Stephen Elliot 對 hypervisor 層預防性控制的支持性評估。他的觀點支持該層在架構上的重要性，但並不構成對每項 HyperArmor 功能的獨立驗證。

對買家而言，應以懷疑態度追問的問題是範圍。基礎設施防禦可以處理針對主機的攻擊，卻不能判定 AI 應用程式是否妥善處理機密資訊。這些控制措施在系統的不同層面運作。

試想一名獲授權員工要求內部助理摘要整理其本不應收到的文件。整個互動期間，主機可能完全沒有遭到入侵。問題會涉及資訊存取或應用程式行為，而非成功攻擊虛擬化軟件。

同樣地，連接商業工具的模型需要規管允許操作的規則。阻止未經授權的主機指令，並不會自動決定助理能否傳送訊息或修改紀錄。應用程式擁有人必須設定這些界線。

這項區別十分重要，因為安全措辭在採購討論中往往會逐步擴大。原本為某一層設計的產品，可能變成保護整個環境的代名詞。買家在把技術聲稱轉化為審批文件時，應保留原有範圍。

機密運算同樣需要審慎看待。在處理期間保護資料，是處理某一類風險暴露的方法；這並不代表每個使用者請求都恰當、每份檢索文件均獲授權，或每個生成答案都準確。

合適的結論是分層責任。基礎設施控制、身分政策、應用程式限制及資訊管治需要彼此支援。加強其中一層，並不能在沒有記錄理據的情況下，合理化移除其他層的控制措施。

管理程序也需要評估。團隊應了解獲授權的緊急存取如何運作，以及當身分相依項目失效時如何復原。額外驗證只有在管理員能於預期情況下可靠地操作時才有幫助。

這些問題並不需要否定 Broadcom 的安全方向。防止主機遭入侵，以及限制特權存取遭濫用，都是有意義的目標。需要審慎之處，在於把這些目標延伸為現有證據無法支持的說法。

因此，生產環境評估應測試具體行為，而不是籠統的安全標籤。預定管理員能否執行獲批准的工作？系統是否會阻止被禁止的操作，而團隊能否解釋結果？

同樣的紀律亦應適用於與 AI 相關的威脅說法。買家毋須接受有關攻擊者的全面敘事，才可評估某項控制措施。他們需要識別所處理的威脅、提供的保護，以及剩餘的風險暴露。

復原必須恢復可受信賴的服務

VMware 的復原功能值得在應用程式層面評估，而不只看基礎設施是否成功重新啟動。

產品組合可用性詳情區分了原生災難復原功能與更廣泛的進階服務產品組合。Network World 報道，vSphere Express 已即時供最多 128 核心的小型環境使用。多項 VCF 新增功能，包括復原及連接功能，計劃於 Broadcom 2027 財政年度第一季推出。

這項區分很重要，因為災難復原及網絡復原回答的是不同問題。災難復原關乎在中斷後恢復運作；網絡復原亦要求確信在遭受攻擊後，已復原的環境適合重新連接。

對 AI 應用程式而言，恢復運算能力只是工作的一部分。服務可能依賴模型檔案、文件、權限、應用程式設定，以及與其他系統的連接。復原規劃需要一併考慮這些相依項目。

設想一個在安全事故後復原的內部工程助理。其虛擬機器成功啟動，介面亦能接受請求；但其文件索引反映的是過時權限，而其應用程式設定則指向已更改的模型。

基礎設施復原可以成功，但服務仍可能不適合正常使用。這個例子說明，復原驗證需要應用程式擁有權參與。管理員可確認基礎設施正在運行，但業務擁有人必須協助判定服務的行為是否可接受。

因此，VMware 的復原功能應根據已定義的復原目標判斷。目標可能是恢復一個具備最新存取規則及經驗證來源資料的獲批准應用程式。機構需要先界定這項成果，才評估編排功能。

潔淨室，即用於檢查已復原系統的隔離環境，可支援這個流程。隔離讓團隊可在重新連接生產相依項目前進行調查，但並不會自動證明每個已復原的成品或設定均可受信賴。

評估亦應考慮復原決策如何獲得批准。安全人員、基礎設施管理員及應用程式擁有人可能有不同的證據要求。記錄完善的流程有助避免在事故期間才發現這些差異。

復原次序會帶來另一項實際相依關係。應用程式可能需要身分服務、儲存空間或網絡連接，才會變得可用。當編排反映這個次序，並協助團隊驗證每項相依項目時，便顯得重要。

這對共享 AI 基礎設施尤其相關。集中化可令共同服務對多個部門更有價值，也增加長時間中斷的後果。復原規劃應反映這些相依應用程式的重要性。

買家亦應區分功能示範與復原演練。示範證明某個工作流程可在選定條件下運作；演練則檢驗客戶的人員、相依項目及程序能否達成所需成果。

最有力的證據，會把復原自動化與已記錄的應用程式驗證連繫起來。團隊應知道哪些項目已恢復、哪些檢查已通過，以及由誰批准重新連接。這比單靠基礎設施狀態指標，提供更清晰的信心基礎。

對 VMware 私人 AI 部署而言，營運問題很直接：機構能否復原一項自己願意信賴的服務？答案取決於軟件功能，以及圍繞這些功能所作的準備。

買家在下一次發佈前應留意甚麼

下一批證據應證實交付情況、整合的實際效益，以及在具代表性條件下的復原行為。

第一個訊號是是否按已公布範圍交付版本。客戶應留意涵蓋計劃中基礎設施、儲存空間、連接、合規及復原新增功能的最終文件。Broadcom 所用的財政季度措辭，應與假定的曆法期限區分開來。

相關證據包括支援的設定、已知限制，以及原生功能與進階服務之間的關係。這些細節決定已公布的功能是否適合現有環境，也說明客戶在採用前需要作何準備。

若交付符合文件所載的客戶要求，將會加強 Broadcom 的整合論據。功能缺失、支援受限或可用性改變，則會削弱其對受影響部署的說服力。評估應依循實際要求，而不是公告的整體廣度。

第二個訊號是來自具代表性的共享模型部署證據。買家應尋找能說明工作負載特性、存取界線、服務行為及管理投入的結果。若沒有這些條件，資源效率的標題式說法便難以評估。

有用的證據會顯示各部門能否在維持對其資訊及工作負載適當控制的同時，共享基礎設施。它亦會說明平台人員在更新、資源爭用及疑難排解期間必須做甚麼。這可揭示整合究竟是減少工作，還是重新分配工作。

獨立客戶案例尤其有價值，因為供應商示範自然會挑選有利條件。即使是詳細案例，只要坦誠說明限制，仍可提供參考。買家應偏好可解釋的成果，而非無法解釋的改善聲稱。

第三個訊號是涉及完整應用程式的復原驗證。客戶應留意把已復原的基礎設施與權限、來源資訊及應用程式行為連繫起來的演練。這類證據會令營運韌性的說法更具體。

一次成功的演練，若能在保留所需檢查的同時減少協調工作，將更有力支持採用整合式復原方案。若演練揭示尚未解決的依賴關係，則可找出仍須完成的工作。無論結果如何，都比假設整合必然代表已準備就緒更具參考價值。

綜合而言，這些訊號提供了一套聚焦的方法，用以評估 Broadcom VCF 的擴展。交付說明了現有內容；部署證據說明其運作方式，而復原驗證則確認機構能否在服務中斷期間倚賴它。

在即將進行的架構審查中，選擇一個具代表性的應用程式，並記錄其存取要求、依賴關係、維護流程及復原準則。請平台團隊把每項要求對應至現有功能、計劃新增項目或營運程序。在評估中，應清楚區分原生功能與進階服務。以相同條件及驗收準則，將同一應用程式與可信的替代方案作比較。就 Broadcom VCF 的擴展而言，應優先考慮能證明減少行政工作、可強制執行資訊邊界，以及服務能以可接受方式復原的證據。在正式投入生產工作負載前，要求進行可由應用程式負責人評估的部署及復原演練。團隊將整合哪些責任？又會以甚麼證據證明最終服務符合其需要？