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 private AI 成为组织决策的关键所在。基础设施管理员、应用所有者和安全团队需要对访问权限形成兼容的定义。否则，每个团队都可能认为另一个团队负责某项实际上无人实施的控制措施。

容量管理又带来另一层压力。共享服务必须容纳不同的业务优先级，同时不能让单一工作负载耗尽所有可用资源。合适的策略取决于业务需求，而不是平台的默认设置。

开发实验与面向客户的应用，对延迟的容忍度可能截然不同。共享其底层基础设施并不会消除这种差异。平台所有者需要一种方法，在资源争用和维护期间保持这些优先级。

同样的问题也适用于变更。更新集中部署的模型可能影响依赖该模型的多个应用。因此，在共享更新进入生产环境之前，应用团队需要一套评估行为变化的流程。

这项分析并不表明 Broadcom 的模型共享会带来不可接受的风险。它指出了整合随之而来的责任。相关比较应当是在重复的部门投入与运行公共服务所需的纪律之间进行。

企业知识也存在类似区分。基础设施控制决定助手运行的环境，而信息控制决定其能够检索的内容。知识库之间的差异有助于说明，部署位置本身无法确定访问策略。

压力最直接地落在那些被要求支持 AI、又不能再创建一个孤立运营环境的基础设施负责人身上。他们需要证明集中化能够改善服务交付。这需要有关工作负载行为、管理投入和权限执行的证据。

对开发者而言，收益取决于共享平台让哪些事项变得可预测。一致的请求流程、已记录的限制和明确的责任归属，可能与初始部署速度同样重要。这些条件才能将可用基础设施转化为可用的内部服务。

整合与运营选择相互竞争

Broadcom 的整合战略，与其他组装和治理企业 AI 基础设施的方式形成竞争。

Nutanix 的企业 AI 控制措施提供了相关参照。其 Enterprise AI 2.8 版本介绍了细粒度权限、受控模型共享，以及适用于断连环境的部署选项。该版本同样区分了正式可用功能与预览功能，买家在比较供应商时应保留这一差别。

这项比较反映的是重叠的优先事项，而非整体胜者。两种方法都涉及在企业基础设施内访问 AI 资源。任何一家供应商的功能清单本身，都无法证明哪种平台更适合特定组织。

Broadcom 客户可能看重扩展管理员已熟悉的环境。只要新能力符合既有职责，熟悉的流程可以减少部分过渡工作。这一优势取决于客户的起点，不应被普遍假定。

其他组织可能更重视让基础设施、模型服务和安全工具能够被独立替换。这种方式可以保留选择空间，但要求团队维护组件之间的连接。灵活性也会带来自身的运营义务。

因此，主要张力在于一体化运营与独立控制之间。整合平台可以让某些工作流更易于协调。组装式环境则可以提供更大的组件替换自由，但也需要更多集成工作。

这些是架构层面的取舍，而不是认定任何一种路径天然更优的理由。合适的选择取决于员工技能、应用依赖关系、硬件要求以及组织对变化的容忍度。买家需要直接测试这些条件。

公平的比较应在候选环境中采用相同的代表性工作负载，并考察部署、访问限制、维护和恢复。若只比较初始设置，就会偏向于让开场演示最容易完成的产品。

该工作负载还应足够接近生产环境，以暴露依赖关系。连接到获批内部文档的助手，比孤立的聊天机器人演示更具参考价值。其行为取决于权限、检索、模型可用性和应用配置的共同作用。

文档在这类评估中同样值得关注。团队需要了解策略位于何处，以及管理员如何检查这些策略。即使某项控制措施在技术上已经存在，如果其行为仍不清晰，实际操作起来也可能十分困难。

故障排除则提供了另一项有用的参照。当应用程序出现故障时，管理员必须判断问题究竟涉及基础设施、身份、存储，还是应用程序行为。若整合能够减少协调工作，并帮助解决这种不确定性，便能带来价值。

Broadcom 的服务生态系统也反映出实施的重要性。Kyndryl 的私有云联盟介绍了围绕 VCF 的咨询、现代化改造和技能投资。作为商业合作伙伴，Kyndryl 提供的是支持性的观点，而非对结果的独立评估。

不过，它的参与仍突出了一个实际问题：软件能力需要架构和运营准备作为支撑。客户仍需将供应商产品组合转化为可运行的策略、职责和流程。这项工作应与部署工作量一并纳入评估。

Broadcom 对 VCF 的扩展强化了其主张，即在 VMware 基础设施内部整合更多职责。客户是否接受这一主张，将取决于其能否证明运营摩擦确有减少。竞争产品仍然具有意义，因为买家可以比较满足相同业务需求的不同路径。

虚拟机监控程序保护并不能解决应用安全问题

保护虚拟化层能够应对一项重要风险，但应用和信息控制仍是独立责任。

Broadcom 的虚拟机监控程序保护公告称，HyperArmor 是针对 ESX 的预防性防御措施；ESX 是运行虚拟机的软件层。该公司表示，它结合了主机级虚拟补丁、允许行为控制，以及管理登录路径中的额外身份验证。

虚拟补丁旨在无需先替换存在漏洞的软件的情况下阻止漏洞利用。Broadcom 将这种方法定位为暴露窗口期间的保护措施。客户应将这一说法与针对所有漏洞或攻击路径的保证区分开来。

该公告援引了 IDC 分析师 Stephen Elliot 对虚拟机监控程序层预防性控制的支持性评价。他的观点支持该层在架构上的重要性，但并不能构成对 HyperArmor 各项能力的独立验证。

对于买家而言，值得审慎追问的是覆盖范围。基础设施防御可以应对针对主机的攻击，却无法决定 AI 应用是否恰当地处理机密信息。这些控制措施作用于系统的不同层级。

设想一名已获授权的员工要求内部助手汇总其本不应接收的文档。在整个交互过程中，主机可能始终未被攻破。问题将涉及信息访问或应用程序行为，而不是对虚拟化软件的成功攻击。

同样地，连接到业务工具的模型需要规定允许执行哪些操作的规则。防止未经授权的主机命令，并不会自动决定助手是否可以发送消息或修改记录。应用所有者必须设定这些边界。

这一差异很重要，因为安全表述在采购讨论中传播时往往会被扩大。一款为某一层设计的产品，可能会被简化为保护整个环境的代名词。买家应在将技术主张转化为审批文件时保留其原始范围。

机密计算也需要同样谨慎。保护处理过程中的数据可以应对某一类暴露风险，但并不能证明每一项用户请求都恰当、每一份检索到的文档都已获授权，或每一个生成的答案都准确无误。

恰当的结论是分层责任。基础设施控制、身份策略、应用限制和信息治理需要彼此支撑。在没有书面理由的情况下，加强某一层并不能成为移除其他层控制措施的依据。

管理流程也需要评估。团队应了解授权紧急访问如何运作，以及身份依赖出现故障时如何恢复。只有当管理员能在预期条件下可靠地操作时，额外身份验证才有帮助。

这些问题并不意味着要否定 Broadcom 的安全方向。防止主机被攻破、限制特权访问被滥用，都是有意义的目标。需要谨慎的是，不应将这些目标延伸为现有证据无法支持的主张。

因此，生产环境评估应测试具体行为，而不是笼统的安全标签。预定管理员能否执行已批准的任务？系统是否会阻止被禁止的操作，团队又能否解释其结果？

同样的严谨态度也应适用于与 AI 相关的威胁主张。买家无需接受关于攻击者的宏大叙事，才能评估一项控制措施。他们需要识别所应对的威胁、所提供的保护以及剩余的暴露风险。

恢复必须重建可信服务

VMware 的恢复能力应在应用层面接受评估，而不应止于基础设施能否成功重启。

产品组合可用性详情区分了原生灾难恢复与更广泛的高级服务产品组合。Network World 报道称，vSphere Express 已立即面向规模不超过 128 个核心的小型环境提供。包括恢复和连接能力在内的多项 VCF 新增功能，计划于 Broadcom 2027 财年第一季度推出。

这一差异很重要，因为灾难恢复与网络恢复回答的是不同问题。灾难恢复关注如何在中断后恢复运行；网络恢复还要求确认恢复后的环境适合在遭受攻击后重新连接。

对于 AI 应用而言，恢复计算资源只是工作的一部分。服务可能依赖模型文件、文档、权限、应用设置以及与其他系统的连接。恢复规划需要将这些依赖关系一并纳入考虑。

设想一个在安全事件后恢复的内部工程助手。其虚拟机成功启动，界面也可以接受请求。但其文档索引反映的是过期权限，而应用配置指向了已经变化的模型。

基础设施恢复可以成功，但服务仍可能不适合正常使用。这个例子说明，恢复验证需要应用所有权的参与。管理员可以确认基础设施正在运行，但业务所有者必须协助确认服务行为是否可接受。

因此，应根据既定恢复目标来评判 VMware 的恢复能力。该目标可能是恢复具有当前访问规则和经验证源材料的获批应用程序。组织需要在评估编排功能之前明确这一结果。

洁净室，即用于检查已恢复系统的隔离环境，可以支持这一过程。隔离为团队在重新连接生产依赖项之前提供调查空间，但不会自动证明每个恢复的工件或配置都可信。

评估还应考虑恢复决策如何获得批准。安全人员、基础设施管理员和应用所有者可能有不同的证据要求。形成文档化流程有助于避免在事件发生期间才发现这些差异。

恢复顺序会产生另一项实际依赖。应用程序可能需要先具备身份服务、存储或网络连接，才能投入使用。只有当编排反映这一顺序，并帮助团队验证每项依赖时，它才具有意义。

这对共享 AI 基础设施尤其相关。集中化可以使一项公共服务对多个部门都有价值，从而加大长时间中断的后果。恢复规划应反映这些依赖应用的重要性。

买家还应区分功能演示与恢复演练。演示证明工作流可以在选定条件下运行；演练则检验客户的人员、依赖关系和流程能否实现所需结果。

最有力的证据应将恢复自动化与文档化的应用验证连接起来。团队应了解恢复了什么、哪些检查已通过，以及由谁授权重新连接。与仅凭基础设施状态指示器相比，这能提供更清晰的信心依据。

对于 VMware 私有 AI 部署，运营层面的问题很直接：组织能否恢复一项自己愿意信任的服务？答案取决于软件功能，也取决于围绕这些功能所做的准备。

买家应在下一个版本发布前关注什么

下一阶段的证据应证明交付情况、实际整合收益，以及代表性条件下的恢复行为。

第一个信号是针对已公布范围的版本交付。客户应关注涵盖计划中的基础设施、存储、连接、合规和恢复新增功能的最终文档。Broadcom 所说的财季应与假定的日历截止日期明确区分。

相关证据包括受支持的配置、已知限制，以及原生功能与高级服务之间的关系。这些细节决定已公布的能力是否适合现有环境，也明确客户在采用前需要做哪些准备。

若交付内容符合已文档化的客户需求，将强化 Broadcom 的整合论点。对于受影响的部署而言，功能缺失、支持受限或可用性变化都会削弱这一论点。评估应遵循实际需求，而非公告表面上的广度。

第二个信号是来自具有代表性的共享模型部署的证据。买家应寻找能够说明工作负载特征、访问边界、服务行为和管理工作量的结果。如果没有这些条件，仅凭资源效率的标题很难评估。

有用的证据应表明，各部门能否在共享基础设施的同时，对其信息和工作负载维持适当控制。它还应说明平台人员在更新、资源争用和故障排除期间必须做什么。这将揭示整合是减少了工作，还是只是重新分配了工作。

独立客户案例尤其有价值，因为供应商演示自然会选择有利条件。只要能如实描述限制，详细案例依然有用。买家应偏好可解释的结果，而不是无法解释的改进主张。

第三个信号是涉及完整应用程序的恢复验证。客户应关注将恢复后的基础设施与权限、源信息和应用程序行为关联起来的演练。这类证据将使有关运营韧性的主张更加具体。

一次成功的演练将强化集成式恢复的合理性：它既减少协调工作，又保留必要的检查环节。若演练暴露出尚未解决的依赖关系，则能明确仍需完成的工作。无论哪种结果，都比假设集成必然意味着就绪更具参考价值。

综合来看，这些信号为评估 Broadcom VCF 扩展提供了一种聚焦的方法。交付说明已有能力；部署证据说明其运行方式；恢复验证则说明组织能否在发生中断时依赖它。

在即将进行的架构评审中，选择一个具有代表性的应用程序，并记录其访问要求、依赖关系、维护流程和恢复标准。请平台团队将每项要求映射到现有能力、计划新增功能或运营流程。在评估中，应明确区分原生功能与高级服务。使用等同的条件和验收标准，将该应用程序与可信的替代方案进行比较。对于 Broadcom VCF 扩展，应优先关注能够证明管理工作更少、信息边界可强制执行，以及服务能够以可接受方式恢复的证据。在承诺运行生产工作负载之前，要求开展一项可由应用程序负责人评估的部署与恢复演练。你的团队将整合哪些职责？又将以哪些证据证明由此形成的服务能够满足其需求？