过去很长一段时间，科技行业围绕人工智能的竞争基本集中在单一维度：比谁训练出的基础模型参数更大，谁在通用基准测试里得分更高。但企业真要把人工智能放进核心业务流程，或者国家级科研机构试图突破传统算力的物理极限时，只调一个大模型接口，往往解决不了复杂的工程落地问题。

近期，IBM在企业级人工智能生态与前沿计算架构两个方向上动作密集。在孟买举行的 IBM Think on Tour Mumbai 2026 大会（当地时间2026年10月28日）上，其印度及南亚区董事总经理桑迪普·帕特尔（Sandip Patel）接受 Dataquest 专访 时表态称：“世界不会在模型上竞争（The world will not compete on models）”，并重点阐释了“数字自治（Digital Swaraj）”理念及配套落地的 IBM Bharat Core 技术栈。而在底层算力领域，IBM Research 发布了首个“以量子为中心的超级计算（Quantum-Centric Supercomputing）”系统参考架构，相关学术论文《Reference Architecture of a Quantum-Centric Supercomputer》也已在预印本平台公开，详见论文 arXiv:2603.10970 档案。这两条分别属于商业应用与前沿科研的线索，其实指向了同一个问题：如果未来的技术竞争不再围绕单一模型展开，真正决定企业和国家技术主导权的底座到底是什么？

为什么桑迪普·帕特尔认为“世界不会在模型上竞争”？

生成式人工智能发展初期，训练基础大模型被看作少数科技巨头垄断的稀缺能力。随着开源生态扩散和推理成本变化，模型本身正迅速走向商品化与模块化。帕特尔在探讨人工智能与“数字自治”时提出“世界不会在模型上竞争”，这是企业高管对行业演进方向的战略表态，核心在于把“通用智力组件”和“端到端业务系统”区分开。

这好比现代汽车工业：大语言模型像一台动力强劲的发动机，但光有发动机，车没法在复杂的城市道路上安全行驶。真正决定一辆车能否在特定路况下商业化运营的，是传动系统、制动控制、适应当地交规的导航软件，以及底盘集成架构。在企业级与国家级人工智能部署中，单一模型就像裸露的发动机，企业真正头疼的是怎么把本地语言数据、行业专有工作流、安全合规要求与底层算力拼接到一起。

为了把这一战略转化为具体产品，IBM 在孟买的大会上正式推出了 IBM Bharat Core。据上述专访介绍，这套专门针对印度市场优化的 AI 技术栈建立在 Sovereign Core（主权核心）之上，提供可复用的印度本土语言（Indic AI）服务、模型及连接器。靠着这些可复用组件，技术重心从“训练一个无所不知的超级模型”，转向了“让不同规模的本土化模型在可控、可复用的系统架构内协同运转”。

“数字自治”与本土化技术栈如何改变企业级AI的部署逻辑？

帕特尔在访谈中将这一技术路线与印度的“数字自治”概念绑定。“Swaraj”在印度历史语境中意为自治与自主，把它放进人工智能基础设施的讨论里，反映出各国政府与大型机构对数据主权、语言文化适配及技术供应链安全的迫切诉求。

跨国企业与公共部门在实际运作中，直接把数据发给海外的单一闭源大模型往往会遇到现实阻力。一方面是语言与语境壁垒，多语种国家的基层服务包含大量非英语语言和特定行业语境，通用模型未必能精准适配；另一方面是数据治理与合规考量，许多机构对敏感数据的跨境流转与控制权有严格的内部治理或监管要求，更倾向于在可控的主权或本地环境内完成数据处理与技术部署。

Bharat Core 基于 Sovereign Core 构建，本质上是在模型与业务需求之间垫了一层主权可控的本土化技术栈。这种架构旨在减少重复集成工作，提高组件复用能力，帮本地机构更顺畅地将 AI 能力接进既有业务环境。这种思路默认了一个现实：未来的企业环境必然是多模型并存的。谁能提供管理数据主权、连接异构系统并沉淀可复用组件的底座，谁就更有机会在企业级市场建立起比单一模型参数更稳固的客户粘性。

什么是“以量子为中心的超级计算”参考架构，它试图解决什么工程难题？

主权 AI 技术栈解决的是软件与应用层的系统集成，而 IBM Research 发布的“以量子为中心的超级计算”参考架构，则是在算力物理底座上推行同样的集成与协同逻辑。

这项成果有明确的学术与工程披露层级：底层理论与架构设计依托于论文《Reference Architecture of a Quantum-Centric Supercomputer》，可查阅 arXiv:2603.10970 论文档案（美东时间2026年3月11日提交、3月12日修订），同时由 IBM Research 官方博客 在美东时间2026年3月12日作为正式科研工程进展对外发布。

对非计算物理专业的读者来说，可以用交响乐团来理解这套架构。在公众的刻板印象里，量子计算机常被描绘成要彻底淘汰传统电子计算机的颠覆性机器。但在真实的科学计算场景中，量子处理器（QPU）并不是用来处理日常网页浏览、数据库读写或图形渲染的“全能选手”。它更像乐团里专门演奏高难度华彩乐段的独奏乐器；而传统中央处理器（CPU）和图形处理器（GPU）组成的经典超级计算机，则是负责铺垫背景、处理海量常规数据流的主力弦乐群。

长期以来，量子计算与经典高性能计算（HPC）基本处于分离状态：科研人员在实验室里单独测试量子芯片，超算中心则跑着纯经典的模拟程序。碰到分子模拟、新材料发现或复杂优化问题时，计算任务一部分需要量子力学层面的计算，另一部分需要经典超算做数据预处理、误差修正与结果整合。如果没有统一的“乐谱与指挥系统”——即参考架构，工程师就只能靠繁琐的手工编排在两套截然不同的硬件间协调任务。孤立的系统环境加上通信、兼容性摩擦，可能会造成性能与效率损失，妨碍研发生产率与算法探索。

IBM Research 推出的参考架构，就是为了在制度和工程规范上补上这块空白。它定义了量子处理单元与经典 HPC 集群如何在统一系统框架内协同工作，涵盖从底层硬件互联、中间件控制、编译器优化到上层混合工作流调度的完整层级，让量子计算从孤立的物理实验装置，变成超算中心里可被标准化调用的算力模块。

从架构图纸到生产级超算环境，混合计算离大规模商用还有多远？

任何参考架构如果只停留在纸面，都很难打消业界对其工程可行性的疑问。据 IBM Research 官方博客 披露，有一项已验证的关键事实：IBM 与日本理化学研究所（RIKEN）开展的早期集成工作表明，混合量子—经典工作流已经可以在生产级 HPC 环境中实际运行。

把混合工作流跑通在生产级 HPC 环境中，是算力工程化路上的一个重要节点。生产级超算环境不同于实验室里的单机演示，它要求极高的系统稳定性、严格的任务队列管理、统一的资源调度以及可重复的运行结果。早期集成的验证说明，混合量子—经典工作流已经走出孤立的实验室测试阶段，具备了在实际生产环境中落地运行的工程基础。

不过，必须明确的是，早期混合工作流的打通并不等同于量子计算的大规模商业化落地，更不代表整套参考架构已经全面成熟。IBM 官方在技术解读中明确指出，这套参考架构并非一成不变的既定蓝图，而是一个将在未来十年内逐步演进的开放框架。首先，参考架构与早期集成解决的是“系统如何协同”的工程通道问题，而量子硬件本身的物理限制——比如量子比特的相干时间、门操作的保真度以及大规模纠错的硬件开销——依然需要长期的物理与材料学突破。其次，混合工作流的软件生态与跨学科开发人才储备仍需持续积累；现阶段该架构的核心落地场景仍集中于国家级实验室、超算中心与前沿科研机构。

游仕观察

把帕特尔在孟买谈到的“不靠模型竞争”与量子中心超算参考架构放在一起看，能摸清一家老牌企业级技术巨头应对技术浪潮时的真实攻防策略。

消费级市场和初创公司把注意力放在单一模型的参数膨胀与对话效果上，而大型机构客户与国家级科研中心面对的，始终是复杂的系统工程问题。不管是靠 Bharat Core 把本土语言服务、模型与连接器封装进主权可控的技术栈，还是用参考架构把量子处理器编入生产级经典超算的工作流，底层的工程思路都是一致的：无论是某个大模型还是某块量子芯片，单一技术组件都无法独立构成完整的商业闭环；真正的壁垒在于制定连接不同组件的架构标准，掌握跨系统调度的中间层。

这也给正在规划人工智能与算力投资的企业管理者提了个醒：评估技术路线时，与其盯着市面上刚发布的单一模型焦虑，不如先看看自己的组织架构、数据治理管线与业务系统连接器，够不够模块化和自主可控。模型与底层算力越来越像可插拔的标准件，一个组织能不能把技术变成实际生产力，最后拼的还是驾驭复杂系统的架构能力与工程纪律。

来源