企业AI 走向生产环境，如何避免新一轮技术锁定

企业部署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可以帮助缩短集群故障的平均修复时间，但没有提供具体的对照数据。对于运维团队，更有价值的检验可能是：它能否准确区分故障原因与伴随出现的异常，分析依据是否可以追溯，错误建议会不会触发不当操作，以及人工确认机制是否适合日常工作流程。这些问题需要在实际使用中验证。