今年连续做了三个跟信创相关的项目其中一次验收会上客户CIO问了我一个此前真没认真想透的问题你们把系统从原来的架构迁移到国产环境这个自主可控的底座算是立起来了那下一步要上AI大模型路该怎么走这个问题放在两年前答案很简单——先完成迁移再说但放到现在AI和信创几乎成了数字经济规划里绕不开的一对组合。一个提供智能能力一个提供技术底座它们不是两条平行线而是深度咬合的两个轮子。这篇文章我从实践视角出发讲清楚AI与信创双轮驱动背后的逻辑、落地路径以及我实际踩过的一些坑给正在做类似规划的团队一个参考。1. 先看清两个轮子的真实咬合关系信创底座与AI算力1.1 信创在我的理解里到底是什么干这行的人都知道信创的全称是信息技术应用创新。如果从工程师视角用一个词概括就是体系性重建不只是换一台服务器、装一个新操作系统而是从芯片、操作系统、数据库、中间件、办公套件到安全防护整条技术栈都建立在国内自主生态之上。它跟普通的软件升级完全不同升级是在既有地基上换装修信创是把地基、框架、墙体全部重打一遍。这也就解释了为什么很多团队会低估工作量。我见过一个典型的案例某企业以为把应用从CentOS迁到国产Linux发行版顶多两周工作量。结果一跑起来数据库连接池参数不对存储过程的SQL语法有差异中间件里的类加载方式也变了最后连备份容灾脚本都要重写。原本两周的活干了两个多月。所以我常说一句话信创不是换一个Linux发行版那么简单它是整条技术链路的系统性替换。在这个体系里每个组件都不是独立存在的。CPU架构不同决定你编译代码时的优化策略操作系统不同决定你依赖的系统库和系统调用全都要重新验证数据库不同决定你的ORM框架和事务处理逻辑能不能平滑迁移。这些环环相扣的细节才是信创落地的真正主体。1.2 AI不是另一个项目而是底座存在的理由再看AI。以现在的大模型为例一个70亿参数的模型FP16精度下光权重就要占14GB显存加上KV Cache和中间激活推理时20GB以上是常态。如果要做LoRA这类轻量微调显存需求还要再翻几倍如果是从头预训练那就直接进入千卡万亿Token的范畴。AI天然是个吃基础设施的应用对算力、显存带宽、存储IO都极其敏感。问题在于过去这个底座高度依赖国外芯片和框架。底座一旦受限AI就是无根之木。但反过来看如果信创把底座建好了却没有大规模的智能化负载跑在上面这个底座就只是一个合规符号用不起来的哑资源。AI承担的角色恰恰是让底座活起来国产加速卡需要大模型这样的重负载去验证性能国产数据库需要智能分析这样的新应用去拓展价值国产操作系统需要AI Agent这样的新形态去吸引开发者。所以双轮驱动的本质是一个闭环信创提供环境AI提供服务服务产生数据数据又沉淀回底座推动底座继续演进。缺了任何一个方向另一个都跑不快。1.3 一组比喻帮你看清双轮的位置我经常用地基与建筑来类比信创是一套能盖楼的地基AI是这地基上长出来的智慧建筑。地基不稳楼会歪只有地基没有建筑就是烂尾工地。真正让人头疼的是很多政企客户在组织上恰恰把这两拨人完全分开——信创组负责迁移AI组负责建模两组人一个月都开不上一次碰头会。举个我亲历的例子某金融机构信创组已经把国产加速卡的环境验证完了集群也交付了结果AI组根本不知道这个资源池存在还在按老办法申请国外GPU资源排队排了两个月。两边需求完全不在一个频道上。这就是典型的两个轮子没有咬合——单看每个轮子都转得挺好但放在同一辆车上车却不动。双轮驱动的第一步不是选什么技术而是让负责两条线的人先坐到一个会议室里。2. 从能用到原生智能自主可控演进的四个阶段2.1 阶段一替代能跑通不等于成功大多数信创项目从替代开始。这个阶段的目标只有一个原本能跑的业务搬到国产底座上之后不报错、流程能走通。听起来简单实际上处处是坑。我自己做过一个系统迁移国产OS上跑了两周一切正常结果到月底跑批量任务时内存回收策略不同导致OOM连错误日志都抓不到。这就是替代阶段最大的陷阱——表面兼容不代表长期稳定底层机制不同很多问题要在高负载、长时间运行之后才暴露。替代阶段最容易犯的错误是能跑就收工。跑通几个核心接口只能说明主链路没问题边界条件、异常恢复、性能劣化这些隐性指标往往完全没验证。我的建议是在任何替代项目里都保留至少一周的稳定性观察期专门跑长时压力测试和故障演练。否则验收一结束问题全变成你的售后单。2.2 阶段二适配性能与稳定性的二次开发能跑之后下一步是让它真正适合国产环境。这个阶段的核心动作有三个按CPU架构重新编译优化x86、ARM、自主指令集架构的差异不只是指令集本身分支预测、内存序、Cache局部性策略都不一样。很多在x86上表现很好的代码在国产CPU上要重新调优。数据库深度适配从Oracle这类商业数据库迁到国产数据库SQL语法兼容只是最表层的问题。更麻烦的是锁行为、隔离级别、分页机制这些底层差异。存储过程、触发器、复杂视图基本都要重写一遍否则一上高并发就死锁或者出现脏读。中间件重新调优WebLogic迁到国产中间件类加载方式、连接池默认配置、部署描述符全都不一样。如果你有基于JNDI老代码适配工作量会再上一个台阶。这个阶段其实是一场二次开发——不是改接口而是让整个系统真正适配新的运行环境。判断标准也很明确关键业务的性能与稳定性达到或接近原有系统水平。达不到后面所有阶段都无从谈起。2.3 阶段三优化让用户从被迫迁变成愿意用适配做完系统稳定了就可以开始琢磨怎么让性能反超。这个阶段我重点做了三件事一是利用国产CPU多核特性做并行优化原来单线程的任务拆成多线程二是数据库读写分离、分库分表把热点数据单独拆分三是在运维侧引入智能巡检用日志异常检测替代传统的人工告警。到这一步用户会发现新系统不只是跟旧的一样还多了些以前没有的本事。判断进入这个阶段的标准很简单用户的评价里开始出现好用这个词。如果用户只是说能用说明你还在阶段一到阶段二之间当用户主动跟你反馈原来这里还可以更智能的时候说明他们开始从被迫迁转向愿意用。这个心态转变很重要它是整个双轮驱动后面能跑起来的用户基础。2.4 阶段四原生智能为AI而生的新底座到了这个阶段AI不再是给旧系统打补丁而是新系统从出生第一天就自带的基因。举个例子现在很多团队的智能客服平台模型推理默认就跑在国产加速卡上数据从头到尾不出域应用一上线就是智能化的。这不是迁完旧系统再外挂一个AI模块而是从架构设计时就按AI原生来规划算力预留、模型生命周期管理、数据回流管道、在线评估指标全部内置。这就是智能引领的真正含义。对信创来说原生智能是它最理想的终态——底座不再被动等待应用迁移而是主动定义新应用长什么样。我在下表里把四个阶段总结了一下方便大家对照自己项目所在的位置。阶段关键词判断标准典型动作主要风险替代能用功能跑通不报错基础迁移、链路打通表面兼容隐藏深水区问题适配好用性能稳定接近原系统架构级调优、库表重构工作量被低估、试错成本高优化想用用户主动认可新优势并行化、智能运维、性能反超投入产出不易量化原生智能智能引领新能力原生于底座算力预留、模型内置、数据闭环团队技能模型需重塑3. 国产加速卡上跑大模型一个真实迁移案例的完整记录3.1 迁移前先做算子地图去年我带团队做了一个OCR加文档理解的项目原来在NVIDIA V100上训练、T4上推理目标是把训练和推理全部迁到某款国产加速卡上下称NPU。我们第一步没有急着改代码而是先做了一张算子地图把模型导出成ONNX格式再用厂商提供的profiling工具逐算子扫描看哪些算子原生支持、哪些走通用回退路径、哪些完全不支持。扫描结果很有价值。我们发现LayerNorm和RoPE这类大模型里高频出现的算子在该NPU上走的是通用回退路径功能没问题但性能差了一个数量级。还发现模型里有几个动态shape的算子NPU平台不支持动态shape必须固定住。如果不做这个前置扫描这些问题会一个接一个在联调时炸出来排错难度会大得多。这个阶段我的经验是先用一个小模型把全流程跑通再上目标大模型。我们是用ResNet18先验证了环境、跑通了数据管道确认没问题之后才切换到OCR大模型的。看起来多花了两天实际上省下来的调试时间远不止这个数。3.2 改代码不是目的最小化改动原则真正动手改代码时我们定了一个原则业务逻辑尽量零改动只改设备管理相关部分。PyTorch生态里以华为昇腾为例有torch_npu适配层写法如下import torch import torch_npu # 原有代码里定义设备device cuda device npu model model.to(device) data data.to(device) # 如果不想手动改每一处设备声明可以用厂商提供的自动迁移工具 from torch_npu.contrib import transfer_to_nputransfer_to_npu这类工具能自动把CUDA相关调用替换成NPU调用适合快速跑通主链路。但要注意自动迁移只是第一层保障真正想性能达标还是得回到代码层面逐个算子核对。我们在自动迁移跑通之后又花了一周时间做手工算子和训练Hook的修正重点是数据加载部分——DataLoader的num_workers、pin_memory在NPU环境下的最佳配置和CUDA环境有明显差异这些参数直接影响了训练吞吐不改的话性能上不去。3.3 精度对齐一个容易被忽视的大坑这是整个迁移里让我印象最深的一关。模型在CUDA上训练loss正常下降换到NPU后loss忽高忽低偶尔还直接爆炸。排了很久才发现是混合精度策略的差异CUDA在部分算子内部默认保留FP32累加而NPU的通用回退算子直接把中间结果截断到FP16误差一累积就爆了。解决办法是显式控制autocast策略对敏感算子强制切换FP32对安全算子继续使用FP16。这里我想给所有正在做类似迁移的团队一个建议从一开始就定义精度验收标准不要笼统地说效果和原来差不多。我们当时定的标准就两条一是验证集F1值与原模型相差不超过0.5个百分点二是模型输出张量的余弦相似度大于0.999。没有这两个数值精度对齐就永远是一笔说不清的糊涂账。3.4 调优三板斧融合、图模式、显存池性能调优阶段我们没有走什么玄学路子就靠三件事算子融合把几个离散的小算子合并成一个大算子减少内核启动开销。光这一步性能大概提升了20%到30%。图模式编译用编译器的静态图优化替代运行时的动态调度减少Python层的解释开销。显存池策略调整NPU的显存分配跟CUDA不是一套逻辑把预分配缓冲池调大之后显存碎片少了吞吐也跟着提了上来。大致感受是基础适配做完性能大概是CUDA环境的60%到70%做完算子级优化和显存调优后可以到90%以上。具体数值肯定因硬件生态而异但趋势是明确的——性能短板大多出在适配深度上不是出在硬件本身的算力上。你投入多少精力在适配层系统就回馈你多少性能。4. AI反向驱动信创应用重构从迁完收工到智能原生4.1 为什么说迁移只是入场券如果只把信创理解成活干完了、验收单签了、系统能跑了那你实际上只拿到了入场券。真正有价值的事情是当这个底座具备自主可控属性之后你可以在上面重新定义应用。智能化就是最直接的重新定义方式。举个例子一个制造企业用信创OA替换了原来的办公系统迁移本身没有什么亮点。但后来他们直接在文档管理系统上叠了一层大模型检索增强生成RAG能力——一线工人不再翻几百页的设备手册直接在对话框里问这台设备的传送带卡纸怎么处理知识库问答做得又快又准。这个能力在旧OA架构里根本长不出来反而是因为迁移之后采用了新的国产架构数据管道重建了、接口口径统一了才让这个AI模块有了用武之地。这就是应用重构的价值不是你在老房子里修修补补而是基建换了之后你愿意盖一栋功能完全不同的新楼。4.2 三类最容易出成果的智能化场景从我们接触过的项目来看有三类场景最容易在信创环境里快速出成果办公协同智能增强AI写作辅助、自动生成会议纪要、基于知识库的语义检索。这类场景门槛低、见效快直接调用私有化部署的模型服务就能实现。对话式商业智能BI把固定报表升级成自然语言查询。业务人员不再需要提工单等数据部门出报表直接问数据库上季度华东区销量前三的产品是什么系统自动生成SQL并返回结果。这背后依赖的就是国产数据库做底座的NL2SQL能力。智能运维与安全分析日志异常检测、告警关联分析、AI辅助的日志归因。这类场景特别适合信创环境因为运维数据敏感度高天然要求本地化部署而AI正好把本地数据变成了决策能力。选择场景时我建议遵循一个原则数据敏感度越高的场景越优先放在信创环境上做AI私有化落地。一方面是合规要求另一方面也是因为私有化才能形成自己的数据资产——数据全部留在自己手里。4.3 智能应用反向倒逼底座升级很多人忽略了一个事实一旦AI应用真正跑起来它会用最直接的方式暴露底座的短板。我们有一个项目一开始只规划了20路并发的大模型推理结果业务上线一周就发现瓶颈不在模型而在底座。为了支撑更大的并发不得不把算力资源池化用Kubernetes加Device Plugin把国产加速卡变成可弹性分配的资源为了喂饱模型推理存储IO从普通硬盘换成了全闪阵列。这些都不是AI团队自己能解决的是智能化需求在反过来倒逼基础设施升级。这个过程我称之为AI反向驱动。信创不是请客吃饭是一个需要不断演进的基础设施。AI提供的不是一个静态能力而是一条会自己增长的需求曲线。底座不够强AI项目跑不快AI项目跑起来底座又必须跟上。这种互相拉扯、互相提升的关系才是双轮驱动的常态。5. 双轮驱动的团队组织与工程化流程我踩过的协作坑5.1 团队不能分成两拨人这一节的标题我原本想写团队配置但实在忍不住想先说协作问题因为这是我在项目里栽过最大的跟头。一开始我们也是常规配置信创组负责环境、AI组负责模型两组人各干各的。结果怎样AI组总在等环境信创组不明白AI组为什么在乎HBM显存和算力互联带宽。等到联调的时候两边才发现各自的假设完全对不上。后来我们把团队结构改成一个项目组、两个技术方向信创架构师和AI工程师在同一个迭代里工作需求文档一起写技术评审一起开。信创架构师能提前知道模型对算力的要求AI工程师能提前知道目标平台的算子支持情况。**双轮驱动的最大障碍从来不是技术而是两个方向的人没有互相理解。**这也是我想特别提醒各位的你可以在项目管理工具里把任务分成两条线但绝对不能把团队分成两个世界。5.2 一套代码适配多硬件抽象层怎么设计工程化落地时最头疼的问题是代码怎么写。我们的做法是坚持业务逻辑与硬件绑定完全解耦一套代码仓库通过适配层去屏蔽硬件差异。具体落地有三层。第一层是设备抽象用配置驱动的方式控制设备类型配置文件里写device: cuda或device: npu代码里不出现硬编码。第二层是模型格式统一导出ONNX作为中转格式再转成目标平台对应的离线模型格式这样模型资产不会跟加速卡厂商绑定。第三层是训练脚本隔离把训练器封装成统一的接口数据加载、优化器、精度策略都作为可配置项。工程上还有一个容易被忽略的点容器化。开发环境用Docker镜像把NPU驱动和运行库全部固化进去保证开发和生产环境一致。我们经历过无数次我本地能跑的惨案根源都是环境差异。容器化之后这种问题几乎绝迹。5.3 兼容性矩阵与验收标准怎么落地测试是双轮驱动的压舱石。我们内部维护着一张兼容性矩阵每次技术选型和版本升级都要对着它过一遍操作系统统信UOS、麒麟、openEuler等主要版本CPU架构x86、ARM、自主指令集架构加速卡当前团队支持的国产型号AI框架PyTorch、MindSpore、PaddlePaddle各框架版本严格锁定模型列表团队内部用到的所有算法模型包括精度和性能基准中间件与数据库业务系统依赖的核心组件版本。测试动作我同样分成四类兼容性测试做最快用自动化脚本批量跑性能测试要有基线必须拿原架构的数据做对照精度测试要有明确数值指标比如前面提到的F1和余弦相似度稳定性测试则要拉长周期至少观察一周的高负载运行。每次新版本发布全矩阵跑一遍即使要花两三天也值得。省下的测试时间最后都会变成线上的事故处理时间。5.4 从开发到生产的完整流水线最后把流水线串起来我们目前的推荐流程是需求拆解与场景定义、环境准备容器镜像加硬件适配层打底、模型评估离线小样本验证、精度兼容性测试、性能压测与调优、灰度上线与监控。每一步都有明确的产出物和评审点。这套流程初期搭建费时但一旦跑顺后续新项目的启动成本会降得非常低基本可以做到两周内把一个新场景跑通。6. 最容易翻车的五个认知误区与避坑思路6.1 误区一先信创、后AI很多团队把两个项目排成串行先把信创迁完再启动AI。这个思路最大的问题在于信创架构一旦定型后期再想加入AI算力就非常痛苦。比如选型的时候没有留GPU/NPU扩展位等AI项目启动时发现机柜空间、供电、制冷全都不够。我的建议是并行规划在信创设计阶段就把AI场景列入需求清单哪怕第一期不实现也要把算力扩展、网络带宽、存储布局的接口预留好。6.2 误区二把国产加速卡当N卡平替N卡能跑的换到国产卡上应该也能跑——这个想法在单卡推理场景可能勉强成立但一到训练和调优就露馅。国产卡的底层软件栈和性能特征跟CUDA生态有本质差异很多在N卡上默认就有的优化在国产卡上需要手工配置。理性做法是正视生态差异把它当作一次跨平台移植预留足够的适配时间而不是上来就抱怨性能。目标设得务实一点先保证功能正确再逐步逼近性能基线。6.3 误区三跑分高就等于适配好厂商的benchmark报告只能作参考不能当验收依据。跑分用的是理想化的测试脚本你的真实业务是几十个算子按特定顺序组合起来的数据流两者差距可能很大。我们遇到过某款加速卡在纯算子基准测试里成绩很好但一跑真实的RAG全流程显存带宽成了瓶颈。评估适配质量的唯一标准是你的真实模型加真实数据组合而不是几行benchmark脚本。6.4 误区四AI在信创里只是锦上添花这个认知错得离谱。AI不是点缀恰恰是让信创系统从合规响应变成业务价值的核心。信创替代初期用户体验大概率会有回落——这是客观现实不用回避。但如果没有AI能力作为弥补用户长期面对没有变好的新系统必然失去信心而一旦加入了智能化的新能力信创系统就拥有了旧体系根本没有的本事——用户用脚投票自然会从被迫用变成主动用。所以AI争取的不是什么加分项而是信创最终能被用户接纳的关键筹码。6.5 误区五自主可控之后安全就自动解决了自主可控解决的是技术体系自主的问题不等于整个系统就天然安全了。信创底座之上跑的如果是大模型应用那同样面临幻觉、提示注入、数据泄露这些AI特有的安全风险。我们做智能客服项目的时候专门加了一道防线对用户输入做注入检测、对模型输出做敏感信息过滤还要防止模型在成员推断攻击下泄露训练数据。底座换成自主可控的安全体系也照样要一板一眼搭起来。7. 复盘新范式到底新在哪里以及给同路人的建议7.1 一个可复用的三层参考架构把前面几章的内容串起来我觉得可以落到一套三层参考架构上这算是我们团队目前沉淀下来最通用的骨架算力层国产加速卡集群通过Kubernetes加Device Plugin做资源池化按业务优先级弹性调度模型层开源基座模型私有化部署结合LoRA做行业微调模型以容器镜像为单位迭代应用层业务知识库、AI Agent框架、前端交互界面全部通过标准API对接模型服务。这套架构最大的价值在两点。一是数据不出域模型和数据完全在自有环境内闭环这在数据敏感场景是决定性的二是每一层都可以独立演进算力不够就扩集群模型能力不够就换基座不用推翻整栋楼。7.2 数据飞轮为什么在信创环境更容易转起来我在做项目复盘时意识到一个有意思的现象**数据飞轮恰好是信创环境最容易形成的壁垒。**因为政企数据不能出域私有化部署几乎是唯一选择而信创底座天然支持私有化。数据在本地持续沉淀拿来微调模型模型能力提升后再服务更多业务场景业务场景又产生更高质量的数据。这个循环一旦转起来外部团队即使拿到同样的模型权重也拿不到你积累的行业数据和反馈信号。从这个角度说信创加AI不仅是一个技术方案更是一个数据资产的积累策略。7.3 给同路人的几点务实建议最后分享几条我自认为最实用的经验供正在规划这类项目的同路人参考。第一从一个高频、可量化的小场景切入把算力到应用的整条链路完整跑通再谈规模。我们做过一个成功案例是从文档问答开始的两个月内跑通全链路验证了选型也锻炼了团队。第二宁可选择生态小一点但自己hold得住的方案也不要选看着热闹但与自身能力断层的方案。很多项目翻车不是技术选型不够先进而是团队根本没有能力维护那套先进方案。第三让信创和AI两条线的人在同一个项目组里工作这个问题前面反复强调但太重要了值得在最后再提醒一次。说实话刚接触这类项目时我也觉得AI和信创是两件相隔很远的事。但一路做下来最大的体会是它们根本就是一体两面信创给AI提供了一个可信、稳定、自主的生长环境AI给信创提供了持续的用武之地和进化动力。正在规划这条路的团队如果能把这两件事从一开始就当成一件事来设计你大概率会比那些分开推进的团队少走一整年的弯路。