企业部署 AI 时，最初关心的往往是模型能否完成任务；进入生产环境后，问题会逐渐转向另一层：模型如何部署，算力怎样管理，数据存放在哪里，系统出了故障由谁处理。如果未来需要更换模型、芯片或平台，现有架构又能否支持迁移？
近日，SUSE 发布了“企业级私有 AI”战略，介绍了与 NVIDIA 合作的 AI Factory 方案，并展示了面向中国企业环境适配的云原生运维智能体 Liz。SUSE 将“开放选择”和“安全治理”放在此次发布的核心位置，希望以现有的 Linux、Kubernetes 和安全管理能力，参与企业 AI 从试点走向规模部署的过程。
在公开分享中，SUSE 首席营销官 Margaret Dawson（戴珍珠）、SUSE AI 高级产品经理 Alessandro Festa，以及 SUSE 中国区副总经理吉晖，分别谈到了基础设施、技术锁定、安全和本地化等问题。他们的观点共同指向一个判断：企业 AI 的竞争，正在从单个模型或应用的能力，延伸到支撑这些应用长期运行的基础设施。
SUSE 想做的是 AI 基础设施
此次发布的 SUSE AI Factory with NVIDIA，将 NVIDIA AI Enterprise 与 SUSE 的基础设施及安全治理能力结合，用于支持企业在本地数据中心、多云及离线环境中部署 AI 工作负载。新闻稿称，该组合方案能够将部署周期从数月缩短至数天。不过，这一时间是 SUSE 对方案效果的描述，具体项目所需时间仍取决于企业现有系统、数据准备和集成复杂度。
“AI Factory”听上去涵盖范围很广，但 SUSE 对自身业务边界的表述相对明确。Dawson 表示，公司主要聚焦基础设施层，不打算提供广泛的 AI 应用；当智能体直接服务于基础设施运行和管理时，相关能力才会成为产品的一部分。
吉晖将 SUSE 的工作概括为两个方向：一是 infra for AI，提供承载 AI 应用的基础设施；二是 AI for infra，利用 AI 提高这套基础设施的运维效率。按照这一定位，企业可以在上层选择不同的模型和智能体应用，而 SUSE 希望管理支撑它们运行的计算环境、容器集群和安全策略。
这也意味着，SUSE 与 AI 办公产品或模型厂商所处的位置有所不同。吉晖认为，办公类智能体主要进入企业的具体工作流程，基础设施厂商则要解决这些应用在哪里运行、如何获得算力以及怎样保持系统稳定的问题。当企业内部运行的智能体数量增加，底层资源的分配和管理会成为更实际的挑战。
Festa 进一步提出，AI Factory 未来可能向“Token Factory”演进。在他的描述中，企业需要将计算资源组织起来，持续向模型及用户提供推理服务，基础设施管理也会因此更紧密地连接上层负载。他同时提到，这一方向仍涉及方案设计和产品演进。因此，Token Factory 更适合被理解为 SUSE 当前提出的产品方向，而非此次已经完整交付的能力。
开放架构，如何转化为真正的选择权？
SUSE 长期强调开放架构，此次又将这一主张延伸到 AI 部署。原因在于，企业使用 AI 后，依赖可能同时出现在芯片、模型、工具链和运维平台等不同层面。即使其中一部分采用开源技术，替换一个组件也可能牵动整个系统。
Dawson 认为，企业不必为了追求开放，一次性替换所有现有系统。许多企业仍在使用专有平台，更现实的方式是先解决新旧系统之间的互操作问题，再根据业务条件逐步调整技术架构。她以虚拟化平台迁移为例：一些企业可以先让开放技术与原有系统共存，条件成熟后再完成更大范围的迁移。
Festa 则将标准化视为降低迁移难度的一种办法。按照他的说法，AI 相关部署方案应尽量采用可复用的设计，以减少企业从一个平台迁往另一个平台时的重复工作。但他也承认，部署迁移只是其中一步；迁移之后，如何管理不同操作系统和平台，仍然是实际问题。
Dawson 提到，技能缺口也会影响企业的选择。一套架构即使支持替换，企业仍需要具备迁移和维护新系统的人员能力。培训、系统集成及新旧环境的统一管理，因此与产品兼容性同样重要。
从企业的角度看，“支持多种模型和平台”只是选择权的起点。能否以可接受的成本替换它们，业务能否在迁移中保持连续，新的硬件或模型能否沿用现有管理流程，才决定选择权是否能够在生产环境中兑现。
私有 AI 的安全问题，贯穿上线前后
私有部署通常与数据控制权联系在一起，但将 AI 系统放进企业自身环境，并不意味着安全问题已经解决。企业仍要管理软件组件的来源和漏洞，控制模型与智能体的访问权限，并监测应用运行后的行为。
Festa 在分享中表示，没有“100%完美的安全”。在他看来，开放架构的价值之一，是让企业和供应商能够检查组件的安全状态，并在发现问题后进行修复。SUSE 所提供的应用集合，也试图将经过治理的常见开源组件纳入企业软件供应链。
吉晖将相关工作分为上线前和上线后两个阶段。上线前，SUSE 对常见开源组件进行扫描、修复和加固，供企业构建应用时使用；上线后，则通过容器安全及零信任机制，处理运行过程中出现的风险。这两部分分别对应软件供应链安全和运行时安全。
智能体的出现又增加了一层权限问题。Dawson 认为，当智能体能够访问系统、调用工具并执行操作时，企业需要像管理人员账户一样，为它们设置明确的访问规则。智能体可以辅助完成任务，但它能读取哪些数据、操作哪些系统、在什么环节需要人工确认，都应由企业事先确定。
SUSE 所说的“自主可控”，也与数据存放和合规要求有关。吉晖认为，中国企业对数据控制权和架构控制权都有关注；Dawson 则指出，其他市场同样重视数据主权，只是对数据保护、存储位置和控制方式的表述有所不同。各地要求不尽相同，但企业都需要弄清楚数据如何流动，以及由谁管理相关系统。
Liz 从云原生运维切入
Liz 是此次发布中用途较为具体的产品。根据 SUSE 的介绍，它集成于 Rancher Prime，面向 Kubernetes 集群运维，可以将集群指标和系统事件用于中文交互、问题分析及故障排查。其设计遵循“人在回路”的原则，由工程师保留对生产环境操作的决策权。
SUSE 中国云原生开发经理赵振阳解释，团队选择从运维场景切入，是因为工程师排查问题时，常要反复收集环境信息、整理运行记录并分析可能原因。Liz 希望承担其中一部分信息收集和分析工作，辅助工程师定位故障。Festa 也强调，Liz 是针对基础设施的垂直工具，而非解决各类企业问题的通用智能体。
中国版 Liz 的差异，主要体现在本地部署要求与模型生态适配上。吉晖表示，Liz 遵循全球产品路线，中国团队负责适配本地 AI 环境。赵振阳进一步提到，中国企业对数据安全、操作审计和归档有明确需求，因此团队开发了相应版本，并适配千问、DeepSeek、Kimi、智谱、MiniMax 等模型。
SUSE 称，Liz 可以帮助缩短集群故障的平均修复时间，但没有提供具体的对照数据。对于运维团队，更有价值的检验可能是：它能否准确区分故障原因与伴随出现的异常，分析依据是否可以追溯，错误建议会不会触发不当操作，以及人工确认机制是否适合日常工作流程。这些问题需要在实际使用中验证。
