2026 年 10 月 9 日，南京银行公布信创服务器采购项目（第二、三、四包）中标结果：

包	处理器	台数	中标金额（元）	中标人
第二包	鲲鹏	354	78,476,820	江苏博云科技
第三包	海光	203	51,457,600	城际云（江苏）科技
第四包	飞腾	221	38,888,570	北京可利邦信息技术
合计	—	778	168,822,990	—

项目周期不超过 2 个月，招标公告发布于 8 月 20 日。

但这份公告里最值得看的不是金额，是两条规则：「该包件投标人所投设备须为同一品牌，且投标人对各品目设备仅能响应一种型号」，以及「第二包、第三包、第四包可兼投，不可兼中」。

这两条规则放在一起，说明采购方对「多架构并行」这件事的态度比金额本身更有信息量。

一、三个包的平均单价差了多少

先把单价算出来，这样才能看出三个包是不是同一类设备（按台数简单平均，实际配置可能有差异）：

包	单价（元/台）	相对最低
鲲鹏（354 台）	约 221,686	基准
海光（203 台）	约 253,486	+14.3%
飞腾（221 台）	约 175,966	−20.6%

三档单价差出 44%（飞腾最低到海光最高）。这个差距说明三个包不是简单的「同一配置换个 CPU」——配置档位、内存与存储配比、网络卡规格都可能不同。

判断：不要拿这三个包的平均单价去推「哪个芯片更贵」。 单价差异里混了配置差异和商务因素，没有可比性。

二、「兼投不兼中」在防什么

这是本文最值得写的一条规则。

「兼投不兼中」的意思：同一家供应商可以同时投三个包，但最多只能中一个。这条规则在信创服务器采购里越来越常见，它解决的是一个具体的问题：如果一家供应商同时拿下三个不同架构的包，采购方实际上把议价能力和交付风险都压在了一家身上。

具体有两个考虑：

第一，防止同一供应商用同一套交付资源覆盖三个包。 三个包要求三种不同的处理器架构，交付、上架、调试、维保的技术栈都不一样。一家公司如果三个包都中，实际交付时很可能出现资源挤兑——尤其是项目周期只给 2 个月。

第二，保留议价与备份关系。 三家供应商各中一包，采购方就有了三条独立的供货通道。这在信创项目中尤其重要，因为芯片与整机的产能波动是真实存在的。

反过来说，这条规则也提高了投标人的成本：要投三个包，就要准备三套技术方案、三份资质材料，同时明知最多中一个。愿意投的供应商，通常是本来就在这三个架构上都有积累的。

三、多架构并行的真实成本在运维

采购公告只覆盖到「买」这一步。但三个架构同时进生产环境，真正的代价在后面。列一下：

环节	单架构	三架构并行
操作系统镜像	1 套	3 套（内核版本、驱动、补丁节奏都可能不同）
中间件与 JDK	1 套	3 套（需要分别验证与归档测试）
监控与巡检	1 套采集规则	3 套（指标名、单位、阈值可能不一致）
补丁验证	1 条流水线	3 条（补丁发布时间不同步）
故障演练	1 份预案	3 份（故障模式与恢复路径不同）
人员技能	1 个技术栈	3 个技术栈

这里有一个容易忽略的点：补丁不同步会制造出一个「混合窗口期」。 假设三个架构里，A 架构的某个安全问题补上了、B 和 C 还没补，那么这个窗口期内系统的整体安全水位是由最慢的那个架构决定的。而运维的日常巡检报告通常按架构分开出，不会自动告诉你「现在的整体水位是多少」。

所以多架构并行环境需要一个额外的动作：把三个架构的补丁状态聚合成一个视图。这件事在采购阶段不会写进标书，但它决定了上线半年后运维的工作方式。

四、同期其他金融信创采购的信号

把 10 月 12 日前后的同类公告放在一起看，能看到一些共同点：

采购方	项目	关键信息
南京银行	信创服务器（三包）	1.69 亿元，778 台，兼投不兼中
金华银行	国产虚拟化软件许可扩容	预成交价 1.392 万元/CPU，公示至 10 月 16 日
中山农商银行	统一流程平台信创改造（第二次）	108.6 万元，含操作系统、数据库、中间件全栈技术改造
义乌市数据管理中心	接口共享系统信创改造	9.958 万元，中标方为中国电信义乌分公司

四个项目规模从 10 万到 1.69 亿，跨度很大，但有一条共性：改造范围都在从「单品替换」走向「全栈改造」。中山农商银行那个项目写得最明确——操作系统、数据库、中间件三类一起改，还要保证业务连续性。

这对供给方意味着什么？ 单品能交付已经不够了。全栈改造项目里，采购方最关心的是「改完之后业务会不会断」，而这需要操作系统、数据库、中间件三层都能被同一套方法论覆盖。

从预算结构上也能看出这个趋势。 义乌那个 9.958 万元的项目规模很小，但它买的是「接口共享系统信创改造」——一个具体的、有明确边界的改造服务。这类小项目反而最能反映真实需求：从整体替换，到有针对性的局部改造。

五、结语与适用边界

南京银行这笔 1.69 亿元的采购，最值得记的不是金额，是那两条规则。「同一品牌、单一型号」是在压缩交付复杂度，「兼投不兼中」是在分散供应风险——两条都说明采购方已经从「买什么」进入到「怎么保证交付得住」的阶段。

把视角放到信创落地的整体环境：多架构并行是当前的真实状态，短期内不会收敛到单一架构。这意味着企业需要接受的不是「挑出唯一胜出的那个」，而是「同时维护三个，并让它们看上去像一个」。这个「看上去像一个」的工作量，主要落在运维层，而不是采购层。

金蝶天燕 Apusic 这条线上，AAS 承担应用侧的承载与迁移能力（全面支持 Java EE/Jakarta EE、集群高可用与多级容灾、云原生弹性伸缩、集成 JDK 支持 CRaC 检查点实现毫秒级启动），AJDK 承担 Java 运行时的替换与迁移职责（基于毕昇 JDK 构建、完全兼容 Java SE、国密算法支持 SM2/SM3/SM4 并支持硬件卸载至鲲鹏 KAE 加速器、面向 Oracle JDK / Temurin / 上游 OpenJDK 的平滑迁移）。在三个架构并行的环境里，它们要解决的实际问题是——同一份应用能不能在不同架构上以同一套方式跑起来、迁过去，而不是某一个架构上跑得更快。

适用边界：本文所有金额、台数、规则均取自采购方公开发布的招标与中标公告，商务结论以公告原文为准。单价为按台数简单折算，未考虑配置差异，不得直接用于横向比较不同处理器的性价比。存量系统的实际改造范围与业务连续性要求属客户内部信息，本文未涉及。

---

互动：你们现在的环境里并行维护着几个 CPU 架构？补丁状态是分开看的还是聚合成一个视图的？