穿越AI生产鸿沟，SUSE如何把“开放韧性”落到基础设施

IDC最新调研揭示了一组冷峻的数字：2026年至少50%的AI驱动数字化应用场景无法达到原定投资回报目标。另一边，企业部署AI的热情却在迅速上升：全球已经在一个或多个生产领域使用智能体的比例，半年时间从40%多上升至76.8%，中国则从44%升至81%。

显然，企业对AI的投入，已经跑在了运营AI的能力之前。

在SUSE Summit 2026上海创新峰会上，IDC中国副总裁兼首席分析师武连峰把现阶段企业布局AI系统的挑战拆成了六个方面：场景选择、数据清洗治理、异构算力调度、生产环境安全、运营复杂度、以及单一厂商锁定。他特别提到，企业AI最大的隐性成本正在从最显眼的GPU，转向更难被看见的运营复杂度。

这也是SUSE试图切入的位置。SUSE中国区副总经理吉晖把SUSE的AI定位概括成两个词：Infra for AI和AI for Infra。

所谓Infra for AI，是SUSE要提供整套基础架构，来承载客户所有的AI应用。而AI for infra，则是SUSE用AI手段帮助客户最大化、最有效率地管理基础设施，减少他们的人员投入。

但在讨论这两条产品路线之前，SUSE先给出了一个更底层的原则：当AI技术栈不断变化时，企业基础设施本身必须具备足够的“韧性”。

“竹子哲学”，走向韧性开放

“在过去几年与全球IT领袖交流中，我听到最多的一个词就是Resilience，即中文里的‘韧性’。”SUSE首席营销官Margaret Dawson（戴珍珠）在演讲和采访中反复提到这个词。

西方语境里的“韧性”，很容易让人想到海里的“灯塔”：足够坚固，风浪来了也不被撼动。而她更推崇中国传统文化里的“竹子”：“狂风袭来时，竹竿可以随风弯曲，但它的根系深扎于地，坚韧不拔。这就是敏捷与灵活的真谛。”她认为，对今天的IT系统而言，真正的韧性不应该只是“足够坚固”，还应该包括“能够变化”。

这个比喻放到AI时代尤其具体。模型可能变，芯片可能变，云可能变，Agent框架也可能变。今天看起来最先进的技术路线，在瞬息万变的AI时代，很快就未必是最佳选择。如果企业把模型、GPU、Kubernetes、数据和应用全部绑进一套封闭技术栈，最大的风险并不是今天不好用，而是明天想换的时候换不掉。

所以，SUSE此次谈“韧性开放”，并不只是重复开源公司的传统立场，而是把它放到了AI生产系统的风险里重新解释。

戴珍珠同时回顾了几段技术史：无论是索尼的Betamax输给了JVC主导的开放许可VHS联盟，苹果的Lightning接口最终向USB-C标准让步，抑或是Adobe Flash被HTML5等开放Web标准取代，都在说明，封闭标准长期往往会面临开放生态的竞争压力。

SUSE提出了开放策略的三个支柱：开放式标准（Open Standards）、开放式架构（Open Architecture）和开放式混合云（Open Hybrid Cloud）。

首先，开放标准解决的是不同技术之间如何互通，譬如MCP(模型上下文协议)在AI层的迅速成熟，是这一趋势的近期例证。

其次，开放架构强调可组合性（Composability）和模块化设计，让企业能像搭积木一样替换局部组件而维持系统的完整。戴珍珠援引Gartner数据说，具备可组合架构的企业创新速度提升80%，系统维护成本降低30%；而从专有系统退出的成本，可能是初期部署投资的10倍以上。另有85%的IT领导者反馈，可组合性让他们能够快速调整自身的业务模式。IDC数据也显示，走向开放云原生架构的企业，基础设施与运营成本降低了35%。

最后，开放混合云则试图打破各自为政的“烟囱式”孤岛架构，通过通用控制平面(Universal Control Plane)，把分散在本地、公有云和边缘的环境纳入一套管理体系。

戴珍珠用“可组合性（Composability）”解释这种设计：像乐高一样，可以替换其中一块，但整个系统仍然保持完整。她引用的“迁移乘数（Migration Multiplier）”则描述了相反的一面：如果架构缺少这种可替换性，从专有系统退出所付出的代价，可能远高于最初部署本身。

“为什么开源、开放对于AI如此重要？大家面临的一个挑战是质疑、信任，必须理解它的背后到底发生了什么。而唯一要获得控制、治理、以及安全的扩展性的方法，就是开放，只有开放，我们才能保证一切都是可审计的、可见的，整个技术栈都是如此。”戴珍珠强调。从这个角度理解，她所谓的“竹子”的韧性，本质上是：外部技术可以变，但企业仍然保有选择权。

以上，开放只是原则。真正到了生产环境，企业还需要解决更具体的问题：怎样把一个AI Demo变成可以复制、规模化运营的系统？

Infra for AI：先把Demo变成可复制的生产系统

SUSE全球AI高级产品经理Alessandro Festa（Alex）在现场提了一个有意思的问题：为什么行业这么擅长做PoC（概念验证），却总是在进入Production（生产）时遇到麻烦？

他的回答很简单：因为PoC太简单了。概念验证阶段，企业往往只关心模型能不能工作。但一进入生产，扩展性、可观测性、GPU、生命周期管理、安全和成本会一起涌上来。于是，PoC阶段看起来运行顺利的一套东西，到了生产环境，突然变成一组彼此纠缠的工程问题。

SUSE AI Factory正是在此背景下出现。它并不是再造一个模型平台，而是试图把Linux、Kubernetes、容器管理、安全、可观测性、NVIDIA AI Enterprise以及AI工作负载，组织成一套可以持续运营的基础设施。

这里最重要的变化，不是多了几个组件，而是把一次性的AI实验，变成可复制的生产架构。这里有四层值得注意的技术点。

首先是统一底座。如上文所述，SUSE AI Factory建立在SUSE已有的Linux和Kubernetes基础设施之上，其中在Kubernetes层，SUSE提供面向高约束、高安全环境的RKE2（Rancher Kubernetes Engine 2）；更上层则通过Rancher Prime管理不同集群。

Alex在采访中指出，SUSE并不要求企业必须使用SUSE全栈，企业可以选用SUSE的Linux，也可以继续运行其他第三方的Linux发行版、Kubernetes发行版或云上托管Kubernetes，再交由统一控制平面管理，保留组件可替换、平台可迁移的“退出策略（Exit Strategy）”。这件事恰恰是企业AI进入生产后的现实：企业几乎不可能为了一个AI项目，把原来的IT环境全部推倒重建。

第二层，是深度嵌入NVIDIA AI Enterprise。Alex用“embedding partner（嵌入式合作伙伴）”来形容SUSE与NVIDIA的关系。SUSE AI Factory将NVIDIA AI Enterprise相关能力直接纳入平台，包括NIM、GPU Operator以及RAG和Agentic AI所需的组件与预验证架构，用户可以在同一环境中部署和管理。

对企业来说，重点是尽可能把NVIDIA AI Enterprise相关能力放进同一套平台和生命周期里。支持链路也采用类似思路：客户面对的是SUSE一个入口，L1、L2问题由SUSE处理；如果涉及NVIDIA相关的L3问题，再由SUSE透明地转交NVIDIA，而不是让企业自己在两家供应商之间反复开工单。

但把组件放到一起仍然不够。PoC到Production最难的一步，是如何把一套“好不容易跑通”的环境复制出去。

于是有了第三层Blueprints。Alex把Blueprints理解成一种预验证、可重复使用的架构模板。企业可以先以模板为起点进行定制，再通过GitOps自动化或者ClickOps进行部署。一旦某个PoC跑通，最终留下来的就不应该只是一个成功Demo，而应该是一套能够固化下来、重复部署的架构。

很多AI项目失败，并不是模型突然变差了，而是PoC阶段依靠几名专家手工拼起来的环境，没有办法在几十、几百个集群上重复。真正走向生产，要求企业把“这一次跑通”，变成“以后每次都能这样跑”。

而标准化也部分回答了人才问题。戴珍珠在采访中提到，企业从一个平台迁向另一个平台时，技术和技能缺口已经成为常见障碍。培训和赋能是一方面，另一种办法则是把大量工程经验提前沉淀到Blueprints和自动化流程里，让使用者不需要从零重新理解整套技术栈。

AI for Infra：再统一管理复杂的基础设施

问题的另一面也随之出现。

如果企业真的拥有多个Linux发行版、几十个Kubernetes集群、不同GPU、私有云、公有云、边缘节点，再在上面运行大量AI应用，那么“保持选择权”的代价，就是基础设施本身会变得越来越复杂。

于是SUSE给出的第二个答案是：AI for Infra。

既然人类已经开始用AI自动写代码、处理客服、分析数据，那么AI为什么不能反过来帮助工程师管理运行AI的基础设施？

在Linux环境中，SUSE开始将AI和MCP能力接入服务器管理、日志与运维信息；Multi-Linux Manager面向大规模Linux服务器环境，原本承担服务器管理、补丁和生产运维，现在则进一步引入AI辅助能力。Alex还提到，在SAP等关键工作负载中，也在尝试把Agent能力嵌入基础设施产品。

但此次最直接体现这条路线的，是Liz。

Liz是SUSE推出的智能体运维助手，面向Kubernetes和云原生运维。工程师可以直接针对集群中的对象询问：这个Pod为什么不断重启？哪里出现了瓶颈？当前配置是否合理？系统再结合Rancher以及相关运维信息给出分析。

同时，Liz采用“人在回路”（human-in-the-loop）机制，并兼容包括Model Context Protocol（MCP）在内的开放标准协议，确保工程师始终保持对生产环境的控制权，在提升自动化能力的同时兼顾安全性与可控性。

所以，它不是一个“什么都能干”的通用Agent，反而是一个很垂直的产品。Alex认为这正是它应该存在的位置：SUSE最了解的就是基础设施。Rancher本身已经能够看到不同Kubernetes环境，Agent如果直接嵌在这一层，就天然拥有更完整的上下文。

更值得一说的，是SUSE中国团队进一步推出了专为中国本土市场打造的Liz GC版本。

赵振阳作为SUSE中国云原生开发经理，解释了Liz GC 背后的技术起因。他的团队长期从事SRE和Kubernetes运维，很多日常工作仍然需要有经验的工程师处理生产台账、采集环境信息、排查问题。Liz GC最初想解决的，就是能否让Agent帮助工程师完成一部分排查、根因分析，并针对可信度较高的问题加快修复。

而中国市场之所以需要独立的GC版本，而不是Global版本，吉晖和赵振阳给出了两层原因：第一，中国企业在Agentic AI落地时，对数据主权、数据安全以及操作过程透明、可审计有明确需求；第二，中国AI大模型生态相对独立，因此Liz GC迅速适配了智谱、Kimi、MiniMax、千问、DeepSeek等国内模型。“千问刚发布，我们马上支持。DeepSeek刚发布，我们马上支持。智谱刚发布，我们马上支持。”吉晖用这样的节奏概括了适配速度。

这其实反映了AI for Infra的一个现实逻辑：AI越多，运行AI所需的基础设施越复杂；基础设施越复杂，又越需要AI来帮助人类管理。

Alex打趣说道：“我总是很自豪地对客户讲，SUSE甘愿做一家‘无聊的公司（The Boring Company）’。如果我们‘无聊’到让你在日常运营中彻底忘记了底层基础设施的存在，就说明你的底层系统运转得足够丝滑、稳健。我们负责枯燥繁重的底座，客户只需专注于他们精彩的核心业务创新。”

AI真正进入生产以后，安全变成了前提

在企业迈向开放AI的过程中，安全问题常常是顾虑之一。然而在PoC阶段，一个测试环境里的漏洞，最坏可能只是Demo失败；但到了生产环境，安全风险往往是致命的，可能意味着业务中断、客户数据泄露和合规责任。Agentic AI又进一步放大了问题，Agent不只是读取信息，还可能调用系统、修改数据、触发交易。

因此，在SUSE对“从PoC走向生产”的理解里，安全并不是上线后的补丁，而应该贯穿整个生命周期。

吉晖在采访中把它拆成了两个阶段来解释。

第一道是上线之前的软件供应链安全。今天企业的AI应用往往由大量开源组件拼装而成，包括Kafka、Nginx等传统组件，以及 vLLM、Ollama等AI基础设施件。如果企业直接从上游拉取镜像，生产环境很容易暴露在未知的CVE漏洞下。

SUSE的思路是通过App Collection（精选组件集，由社区维护、经SUSE安全加固后嵌入）对常用开源组件进行加固、扫描和漏洞处理，之后再推到软件库，再向客户提供相应的软件包和支持。吉晖介绍，这套体系对应的正是业界近年常提到的“软件供应链安全”(Supply Chain Security)，SUSE还提供配套的L1、L2级技术支持。

第二道则是上线后的运行时安全。一些风险只有程序真正跑起来以后才会暴露。SUSE此前收购了一家容器安全公司(即现在的SUSE Security，原NeuVector)并全面开源。这套体系采用零信任（Zero Trust）架构，持续监控微服务间的网络行为与进程变更，一旦发现异常行为，可立即在网络层阻断并对容器实施隔离。

到了Agentic AI时代，访问控制会进一步变得重要。戴珍珠用了一个类比：企业应该像管理一个人类员工一样管理Agent。不是因为它“聪明”就把所有权限开放给它，而是需要最小权限、身份、授权和完整的访问控制。

SUSE的差异化定位

在中国市场，伴随字节、阿里、腾讯等国内互联网和大模型巨头密集推出AI产品，业界也会好奇，SUSE作为开源软件公司，在中国市场究竟扮演什么角色？

吉晖解释说，这些本土巨头所进入的是“劳动力市场（workforce market）”，通过软件这一层，解决办公、生产力和人效的问题。而SUSE所处的是它下面那一层，也就是基础设施层，面向的是数据中心和云环境中稳定、可靠、可运营、可运维的基础设施。

吉晖进一步判断，随着客户越来越重视数据安全，越来越多的核心办公场景会走向“我需要在自己的数据中心建一套AI支撑体系”的自建路线，如果未来一家大型企业内部真的运行几百甚至上千个Agent，那么这些Agent最终总要运行在Linux、容器、Kubernetes、CPU和GPU之上。谁来管理这些资源、谁来保持安全、谁来控制数据、谁来保证某一天还能换模型和换平台，这就是SUSE所代表的基础设施公司看到的新市场。

吉晖以一台约200万元的八卡服务器作了一个粗略测算：如果基础设施管理能把资源利用效率提高10%，对应的就是约20万元的价值空间。“从财务角度来讲，那么用SUSE或者用开源，是一个很合算的交易。”他补充。

戴珍珠对此也划了一条边界：SUSE做的仍然是基础设施层，并不打算向上变成一家通用AI应用公司，除非Agent本身就是基础设施的一部分。

这一定位背后，是主权AI（Sovereign AI）在企业侧的普遍诉求。吉晖指出，主权AI的核心本质上是一个词：控制，尤其是数据的所有权和控制权。企业为什么愿意自己搭一套AI基础设施？一个重要原因就是不希望把自己的核心数据长期交到外部模型或外部平台手里。

戴珍珠补充了一个全球视角，她最近参加了联合国“开源周”活动，其中第一个议题就是“如何组合开源加主权控制”。真正实现主权控制的最好方法，恰恰是技术的开源。这一议题在全球范围已经不再是纸上谈兵，不同国家的措辞或许有别，但本质相当接近。

IDC的数据也印证了这一趋势。IDC与SUSE联合开展的亚太区调研（其中包含175个中国样本）显示，企业解决AI落地障碍的四大关注点分别是：安全部署、缺乏可扩展的AI基础设施、成本难以控制、以及AI主权与合规。武连峰概述说：“安全、扩展和成本是AI落地的三座大山，而数据主权与合规是本地化的硬约束。”

回到SUSE 在容器管理这个具体赛道上的位置，戴珍珠给出了另一层观察。她提到，SUSE连续三年入选Gartner容器管理领导者象限，差异化的核心是“中立性和全栈异构管理能力”：SUSE不仅管理自己的Kubernetes，也管理企业复杂的异构Kubernetes环境，这是SUSE很常见的工作方式。

戴珍珠认为，AI工作负载越来越高度依赖容器化交付，SUSE会把这些能力延伸到AI Factory的场景里。她同时提及，目前企业工作负载中只有15%到20%完成了容器化，传统应用和新的AI workload仍有大量迁移空间。

AI Factory的下一站：Token Factory

如果把SUSE所做的梳理来看，它试图把Linux、Kubernetes、安全、可观测性、异构算力以及NVIDIA AI Enterprise编织成一层可以替换、可以迁移、可以持续运营的AI基础设施。

而Alex给这套基础设施标的了下一站，是“Token Factory”（Token工厂）。

他的判断是，随着AI规模继续扩大，企业需要管理的东西会逐渐变化。今天AI Factory管理的是服务器、GPU、集群和AI应用；未来，如果企业真正开始以Token衡量AI产出，基础设施竞争也会从“有多少算力”进一步走向“如何把算力稳定地转化为可预测的Token产出和业务价值”。

因此，Alex认为，今天的AI Factory未来还会继续向Token Factory演化。企业需要把分散的算力组织起来，提供给模型和用户使用；基础设施和应用之间也会越来越难彻底分开。

这里其实出现了一个非常重要的变化：过去基础设施管理的是资源，未来它可能越来越需要管理的是产出。这或许才是“AI生产鸿沟”真正要跨过去的地方，让AI成为企业基础设施中一个可运营、可治理、可替换、也可持续计算成本的生产系统。