这两年做项目最明显的一个感受是AI 和信创已经从两个各自发展的赛道变成了一辆车上必须同时转起来的两个轮子。一边是国产芯片、国产操作系统、国产数据库这些底层在快速迭代一边是大模型、AI Agent、多模态应用在拼命往生产环境里钻。以前我们谈信创谈的是能不能替现在 AI 一进来问题变成了替完之后能不能跑 AI。这完全是两个难度级别的事情。我陆陆续续参与过几个信创环境的智能化改造项目从最初在国产 CPU 上跑个 OCR 都费劲到现在逐步把大模型推理、知识库问答、AI 辅助测试这些场景稳定跑在国产算力栈上中间踩过的坑确实不少。这篇文章就围绕AI 信创双轮驱动这条主线把我自己实践中的方案选型、技术适配过程、性能调优方法、团队协作经验都梳理一遍。不管你是在做信创适配的技术负责人还是想把 AI 能力落到底层国产化环境里的开发工程师这篇文章应该都能给你一些能直接拿来用的东西。1. 为什么是双轮而不是单线AI 与信创的真正关系1.1 信创的本质不是替代而是适配升级信创这个概念很多人的第一反应还是国产替换。早几年确实是这样那时候项目的核心指标就是能不能跑起来办公软件换国产的、操作系统换国产的、数据库换国产的只要功能不掉链子就算过关。但现在的信创已经完全不是这个逻辑了。硬件平台从 x86 扩展到了 ARM、LoongArch 等多种架构操作系统从 CentOS 迁移到各大国产发行版芯片也从 CPU 延伸到 GPU/NPU 这类 AI 加速卡。整个产业的基础设施已经从有没有过渡到了好不好用的阶段。而 AI 的加入恰恰是这个好不好用阶段最大的变量。你问我信创环境下最大的痛点是什么绝对不是什么软件不兼容这种老问题而是国产算力平台对 AI 工作负载的支持深度不够。一个在 NVIDIA GPU 上训练好的模型迁移到国产加速卡上经常遇到算子缺失、精度不一致、显存管理策略不同这些新麻烦。所以现在做信创核心不再是替代而是让新能力在新底座上跑得更好这就是 AI 和信创真正交汇的地方。1.2 AI 给信创带来的三大增量很多人都以为 AI 信创就是在信创环境里跑模型这个理解太浅了。我自己的体会是AI 至少给信创领域带来了三个维度的增量应用形态的增量以前信创系统里跑的是 ERP、OA、邮件这些传统办公系统现在加入了大模型问答、智能文档处理、语音转写、图片生成、AI 视频分析这些全新的应用形态。这些不是把旧系统换个皮而是凭空多出来的业务能力。开发模式的增量在信创环境里做开发过去最头疼的是缺工具、缺生态、缺资料。现在 AI 编程助手、AI 测试开发工具、AI 辅助代码审查这些能力逐步进入生产流程开发效率低下的问题有了新的解法。特别是很多国产大模型本身就在信创环境下训练和部署开发者和模型之间形成了正向循环。底层能力的增量AI 反过来倒逼了国产芯片和基础软件的发展。大模型推理需要高性能计算倒逼国产加速卡发展数据安全需要端云协同倒逼国产操作系统提供更好的隔离能力大规模 GPU 集群需要调度倒逼国产云平台补齐容器调度、分布式训练这些能力。所以你看AI 和信创不是单向的AI 适配信创而是双向的AI 拉动信创、信创支撑 AI。这才是双轮驱动的真实含义。1.3 两个轮子脱节的典型症状在实际项目里两个轮子脱节的情况非常常见。我这里总结几个典型症状你可以对照自己的项目看看有没有中招团队立项的时候只写了信创环境部署 AI 模型没有提前摸底目标平台的算子支持范围结果模型迁移到一半发现某个关键算子根本不支持只能回头改模型结构。业务系统已经完成了信创改造但是 AI 能力还是跑在一套独立的、非国产的算力环境里数据和模型没有打通所谓的信创 AI其实还是两张皮。测试团队只会做功能测试面对 AI 模型在国产芯片上的精度损失、性能波动这些问题完全没有排查思路出了问题只能干瞪眼。选了信创目录里的硬件和基础软件但是没考虑 AI 框架的兼容版本装了半天环境才发现深度学习框架要求的系统库版本和操作系统预装的不一致。这些问题的根源其实只有一个把 AI 和信创当作两个独立项目来做而不是当作一个统一的系统工程。理解了这一点下面所有的技术方案才有讨论的基础。2. 从可用到好用AI 落地信创环境的五层适配我在实操中习惯把 AI 项目落到信创环境的过程拆成五个层次算力层、框架层、模型层、应用层、安全层。每一层都有各自的坑一层一层过问题就清晰很多。2.1 算力层国产芯片选型与算子覆盖摸底算力是 AI 系统最底层的土壤。目前国内能见到的主流 AI 加速卡厂商从芯片架构、软件栈成熟度到算子生态完善程度差异非常大。我的建议是选型不要只盯芯片峰值算力要看软件栈的成熟度。算子覆盖率是首先要摸清的指标。你拿一个经典的 ResNet-50 或者 BERT 模型在目标平台上跑一遍前向推理看看报不报算子不支持的错误。如果连这种主流模型都跑不全后面换更复杂的模型只会更痛苦。另外一个非常关键的工程细节是显存管理策略。国产加速卡在显存分配、回收、碎片整理上和 NVIDIA 的习惯很不一样。我遇到过这样的情况同一个模型在 NVIDIA 上显存占用 12GB切到国产卡上变成了 16GB而且跑几个 batch 之后显存碎片越来越严重最终 OOM。这种情况下模型架构没变纯粹是框架层和驱动层的显存管理差异导致的需要调整框架的显存池参数比如设置最大缓存比例、启用碎片整理功能。评估维度重点关注建议方法算子覆盖率目标模型涉及的 op 是否全部支持跑一遍官方算子支持清单 实机验证显存管理峰值占用、碎片率、OOM 概率用不同 batch size 压测观察显存曲线驱动生态是否适配主流深度学习框架版本检查驱动、框架、CUDA 兼容层版本多卡通信分布式训练时通信效率跑一次集合通信基准测试看吞吐量提示选型阶段一定要让算法团队参与而不是只看硬件采购清单。我在项目里吃过亏硬件采购部门按性价比选了一张卡结果算法团队花了两周才把模型适配好算力性能全浪费在迁移成本上了。2.2 框架层训练、推理框架与国产平台的兼容性框架层的核心任务是解决深度学习框架在国产芯片上能不能高效运行的问题。现在主流的国产 AI 加速卡通常都会提供对应的适配方案核心思路一般有两种第一种是使用原生适配的国产框架。像昇腾平台有 MindSpore百度系有 PaddlePaddle这些框架在设计之初就考虑了自家硬件的适配。如果你在国产芯片上使用这类框架性能一般是最好的但缺点也很明显如果你的团队一直用的是 PyTorch切换框架的成本不小很多 PyTorch 的生态工具没法直接复用。第二种是通过兼容层跑 PyTorch。现在很多国产加速卡提供了 PyTorch 适配层让你在代码层面几乎不用改动只需要把模型加载目标设备时的指令换一下。这种方式上手快但会有一些隐性的性能损耗和算子兼容坑。我在实际项目中的建议是两条腿走路线上推理服务这种追求极致性能的场景优先用原生适配方案算法团队做实验、跑调研的时候用兼容层跑 PyTorch 提升效率。两者通过统一的模型导出格式衔接避免算法团队和部署团队被绑死在同一个框架上。另外框架版本的锁定非常重要。国产平台的框架适配通常是滞后于上游版本的你追新的代价就是各种疑难杂症。我通常的做法是选定一个经过验证的版本组合后冻结它所有业务系统的依赖都以这个组合为准。宁可在老版本上多待半年也不要让版本升级打乱整个团队的节奏。2.3 模型层权重迁移、静态图转换与推理引擎选型模型层是整个适配过程中最繁琐的部分因为你永远不知道下一个模型会卡在哪里。首先是权重迁移。如果你是从 PyTorch 训练的模型转成别的格式需要注意权重映射名、维度顺序、精度类型这些细节。最稳妥的做法是写一个自动转换脚本把模型字典里的 key 全部打印出来核对一遍特别是那些带自定义层、条件分支的模型手动改最容易出错。其次是静态图转换。训练模型通常是动态图模式方便调试但是部署到国产加速卡上很多推理引擎要求使用静态图模式以获得更好的算子融合和显存优化效果。转换过程中经常遇到控制流if/else展开、动态 shape 固定、自定义算子替换等问题。我的经验是在模型设计阶段就尽量避免复杂的动态控制流宁可多写几个分支模型也不要让一个模型里的 shape 满世界乱跳。这能省掉后面部署期大量的返工。推理引擎的选择也是一个重点。现在国产平台上常见的推理加速方案有两大类一类是芯片厂商自带的专用推理引擎性能和硬件契合度最高另一类是开源的通用推理引擎比如带推理优化能力的通用服务框架生态好、插件多但在国产芯片上可能需要额外的适配层。我的建议是关键场景用厂商引擎做深度优化通用场景用开源引擎做快速部署两者通过同一份模型文件和服务接口统一对外。2.4 应用层AI 服务与信创中间件的协同模型部署好了接下来要对接业务系统这里就要面对信创中间件的兼容问题。信创环境下你很可能用的是国产数据库、国产消息队列、国产对象存储AI 服务要跟这些组件顺畅协作需要注意几个点数据库兼容AI 服务经常要把推理结果写回数据库而国产数据库在 SQL 方言、驱动包、连接池上都有自己的差异。我建议提前做好数据库驱动的验证特别是大规模并发写入时连接数的表现。消息队列衔接异步推理架构里任务是通过消息队列分发的。国产消息队列在吞吐量、消息持久化、延迟表现上参差不齐一定要压测尤其要注意消费堆积场景下 AI 服务的表现。部署框架兼容AI 服务通常容器化部署要确认你的容器平台、镜像仓库、日志收集链路在信创环境下能正常工作。我自己就遇到过这样的问题镜像在本地构建没问题推到信创环境的镜像仓库后运行报权限错误最后发现是仓库组件和操作系统的安全模块有冲突。应用层最核心的原则是AI 服务要把自己当作一个数据进、数据出的标准组件尽量不要和周边系统产生强耦合这样无论底层信创组件怎么换AI 服务都能稳定往外提供服务。2.5 安全层数据合规与模型审计AI 加入信创系统后安全管理的复杂度也随之上升了。除了常规的系统安全、网络安全还要额外关注以下几个点数据合规大模型训练和推理离不开数据数据在模型侧的处理方式是否出域、是否留存、是否用于二次训练需要在系统设计之初就明确。特别是涉及个人信息、企业敏感数据的场景要有清晰的脱敏和审计链路。模型版本管理模型的版本变更需要有记录谁在什么时候、用哪份数据、训练了什么版本、部署到了哪里都应该在管理平台上留下完整生命周期痕迹。这个在监管和内部审计时会非常有用。推理服务安全对外提供 AI 能力时要防注入攻击、防恶意请求、防模型窃取。一个常见的做法是在推理网关前加一层风控服务做请求内容的过滤和频率限制。安全测试与适配信创系统的安全测试不只是打打漏洞补丁还要关注 AI 特有风险的检测比如对抗样本攻击、数据投毒、提示词注入这些新型攻击面。3. 实操实录把一个 OCR 模型迁移到国产推理平台的完整过程纸上谈兵没意思我把一个典型的 OCR光学字符识别模型迁移过程完整记录下来。这个项目是给一个信创改造后的业务系统增加票据识别能力目标平台是一台搭载国产加速卡 国产操作系统的服务器。3.1 环境准备与基础信息收集动手之前先花一天时间把环境情况完全摸清。这里不是简单跑几个命令而是要建立一份完整的环境清单# 操作系统信息 cat /etc/os-release # CPU架构信息 uname -m lscpu # 内存与硬盘 free -h df -h # 加速卡信息不同厂商指令不同常见如下 npu-smi info # 或 xpu-smi query # 深度学习框架版本 python -c import torch; print(torch.__version__) python -c import mindspore; print(mindspore.__version__)这些信息要整理成文档发给所有项目成员。我在这个环节还有一个血泪教训环境信息一定要当场核实不要相信采购清单上的参数。有一次采购清单写的是某加速卡 16GB 显存实际npu-smi显示可用显存只有 12GB如果按 16GB 设计 batch size上线第一天就要 OOM。3.2 模型转换与量化OCR 模型一般是目标检测 文字识别两个子模型组成。我们的模型是基于 PyTorch 训练的目标推理平台要求静态图模式于是需要做两件事转静态图 转换成目标推理引擎支持的格式。我的做法是写一个独立的转换脚本分三步走# 第一步加载 PyTorch 模型并转成通用静态图格式 import torch model torch.load(ocr_det.pt, map_locationcpu) model.eval() # 示例输入固定 batch 为 1输入尺寸固定 dummy_input torch.randn(1, 3, 640, 640) # 导出为通用模型格式交给后续部署 torch.onnx.export( model, dummy_input, ocr_det.onnx, opset_version11, input_names[input], output_names[output], ) # 第二步在目标环境下加载静态图模型跑通一次前向 # 这一步用来验证算子是否全部支持 # 第三步如果有不支持的算子记录日志回模型侧调整这里要特别提醒转静态图前一定要保证输入尺寸固定。OCR 检测模型的输入图片尺寸如果不固定导出时就会生成动态 shape 的图很多国产推理引擎对这种情况的兼容性很不稳定。我们的做法是在预处理阶段做 padding把所有输入图片都缩放到相同的长宽转静态图的阻力一下就小了很多。量化是另一个关键环节。在国产加速卡上FP16 往往是性能和精度的最佳平衡点INT8 能进一步提效但精度损耗不可控。我们的做法是先跑 FP16确认精度达标后再试 INT8两步的评估用同一套 benchmark 集最后根据业务方给的精度接受底线决定用哪种精度。OCR 这类任务对文本行的检测框位置敏感INT8 量化后如果出现字符级别的位置偏移宁可放弃 INT8 的收益。3.3 推理服务部署与接口兼容模型转换完成后进入服务化部署环节。我常用的是一个标准的三层结构接入层API 网关— 推理服务层模型服务— 依赖层数据库、存储。推理服务层用通用推理框架搭建封装统一的 HTTP 接口让上层业务系统完全不感知底层换了什么芯片。核心代码框架大致是这个思路# 推理服务伪代码实际生产环境需要补充鉴权、日志、监控 from fastapi import FastAPI, UploadFile import numpy as np import inference_engine as engine app FastAPI() # 在服务启动时加载模型 model engine.load_model(ocr_det_static.model) recognizer engine.load_model(ocr_rec_static.model) app.post(/ocr/infer) async def ocr_infer(file: UploadFile): image load_image(file) # 读取并预处理 det_result model.infer(image) # 检测 text_result recognizer.infer(det_result) # 识别 return {text: parse_result(text_result)}这个环节有两点值得注意第一是接口设计要保持简单。对外只暴露最少的输入输出字段业务系统不需要关心模型内部结构。我曾经遇到过业务方直接调模型的原始输出结果适配团队换了一版模型后输出数据结构变了业务方连夜改代码。后来所有接口都统一封装业务方只面对固定的数据结构这类问题基本绝迹。第二是预热机制。模型加载后第一次推理往往比后面的推理慢很多因为引擎要执行算子编译、内存预分配这些初始化动作。建议在服务启动后做一个热启动请求用一张基准图跑一次推理把这个耗时吃掉否则你压测的时候第一个请求的数据会异常难看。3.4 性能与稳定性验证服务部署好之后不能急着上线先用基准工具打一轮压测。压测的关键指标我一般关注三块吞吐量QPS、延迟P95/P99、显存占用。这里记录一次实测的数据供你参考指标异构兼容层版厂商原生推理引擎版提升幅度单并发延迟 P50ms24.615.337.8%单并发延迟 P99ms48.229.538.8%16 并发 QPS30244547.4%峰值显存占用GB6.85.223.5%从数据可以直观看出厂商原生推理引擎在性能和显存控制上优势明显。但要注意这是同样的模型、同样的硬件下两种方案对比的结果。实际项目中如果团队对原生方案不熟悉调试周期会拉长需要自己权衡。压测过程中如果发现 QPS 不达标优先排查的不是模型代码而是这四类问题预处理是否成为瓶颈、CPU 和加速卡之间数据拷贝次数、推理服务的线程数和批处理配置、后端数据库写入是否阻塞推理流程。我见过太多人一压测就怀疑模型本身花了半天优化模型参数结果发现瓶颈在图片解码上。稳定性测试也要做。信创环境有个特点就是长时间运行时可能会出现一些玄学问题比如长时间运行后显存泄漏、加速卡温度升高导致频率降档、底层驱动经过长时间运行后日志爆满。我的建议是跑一轮至少 12 小时的稳定性测试观察显存曲线和推理延迟曲线是否平稳以及加速卡的温度记录。任何一条曲线出现持续爬坡的趋势都要在一开始就揪出来处理。4. 信创适配与安全管理容易被忽略的隐性工程很多团队把精力全扑在模型和代码上但信创项目能不能顺利过验收、能不能长期稳定跑起来往往取决于适配和安全管理这部分的隐性工作。4.1 信创目录产品选型与适配标准在实际项目申报和验收环节信创目录是一个绕不开的参照系。这里说的信创目录指的是经过统一评估和认证、进入推荐名单的信创软硬件产品集合。采购和集成时优先选择目录内的产品能省下很多合规上的麻烦。不过要有清醒的认知目录内产品的合规性和实际使用中的适配度是两个维度。我在项目里见过有客户指定了目录内的某款国产数据库结果我们的 AI 服务要连这个库时发现 Go 语言的驱动有问题只能临时起一个适配代理层。所以选型阶段就要把业务系统 中间件 AI 框架 操作系统 芯片整个栈的关系拉开一张大表把每一个连接点都跑一遍冒烟测试确认全部打通后再进入开发阶段。进行信创适配时还需要注意标准的把握。现在各行业对信创适配的验收要求不完全一样但核心大多集中在功能完整性、性能达标率、兼容性覆盖、安全合规性。我的建议是提前确认验收方的评分细则再倒推需要准备哪些测试报告和证据材料不要等项目快结束了才发现测试标准理解偏了。4.2 安全管理的关键维度AI 系统加入信创环境后安全管理至少要从五个维度考虑系统加固国产操作系统上要按等保要求加固包括不必要的服务关闭、内核参数优化、账户策略设置。AI 推理服务通常需要高性能系统加固时要特别注意不要误伤了高性能计算相关的内核配置。数据隔离AI 训练和推理过程中涉及的数据集、模型文件、推理日志要进行分级分类不同密级的数据要存储在不同的位置访问权限严格控制。访问审计记录所有 AI 服务的调用行为包括调用方身份、调用时间、请求内容必要时做脱敏后记录、响应内容、异常行为的告警。模型与数据安全防止模型被大规模复制、防止训练数据被恶意注入污染模型文件的存储要加密模型的加载过程要有校验机制。供应链安全AI 项目中依赖的开源组件、预训练模型、第三方库都可能是风险点需要建立组件清单和漏洞跟踪机制。4.3 适配测试怎么才算过信创适配测试不能只测功能是否正常我整理了一个完整的测试矩阵分四层功能测试模型推理结果是否准确、接口是否符合约定、业务链路是否完整。性能测试单请求延迟、并发吞吐、资源占用、长时间稳定性。兼容性测试不同国产操作系统版本、不同 CPU 品牌和型号、不同加速卡型号、不同数据库版本下的表现。安全测试漏洞扫描、渗透测试、数据安全合规、异常输入攻击包括针对 AI 模型的恶意样本。举一个最典型的测试盲区灰度切换测试。很多信创项目是双轨运行——老系统和新系统同时在线数据互相同步验证稳定后再切换。这个过程要充分考虑业务体量和数据同步延迟以及模型推理结果和原系统结果的差异分析。如果不做这个环节一次性切换的风险是非常高的。5. 团队、工具链与长期演进5.1 AI 信创复合人才梯队AI 信创最大的瓶颈不是技术是人。能调模型的和能搞底层系统适配的往往是两拨人。组织上需要建立复合型的项目梯队算法工程师负责模型选择、训练调优要具备我的模型将来要在国产加速卡上落地的意识训练阶段就关注算子兼容性不要等到上线前才发现问题。平台工程 / 信创适配工程师负责操作系统、驱动、容器、数据库、中间件的适配他们的核心能力是让不同厂商的组件在一套环境里稳定协作。这部分人在市场上的供给极少内部培养是主流路径。测试工程师 / 安全工程师要同时懂业务测试和 AI 测试能做性能压测、精度评估、安全巡检。AI 测试这个岗位以后会越来越重要因为 AI 模型的验证方法和传统软件差别很大。** DevOps 工程师**负责搭建持续集成和持续部署流水线让模型版本、软件版本、环境配置的变更都能追踪和回滚。我见过的项目凡是技术团队里缺少平台工程师的AI 模型适配的工作就会全堆在算法工程师身上这帮人又不熟悉底层往往一个环境问题折腾好几天。所以组织层面一定要舍得在平台适配岗位上投入人力。5.2 AI 辅助开发在信创环境中的落地信创环境做开发开发工具链往往比互联网大厂的环境落后一截AI 辅助开发工具就成了重要的缓解手段。我自己实践下来有三个场景收益最明显第一个是AI 辅助编码。国产代码补全工具在很多场景下表现已经相当不错特别是对常见框架Spring Boot、PyTorch的代码补全。在信创项目里大量的胶水代码环境配置、接口封装、数据转换是高度重复的AI 补全能明显提速。第二个是AI 测试开发。写接口测试用例、生成测试数据、做文本差异分析这些工作 AI 都能做到堪用的水平。我建议测试团队把让 AI 生成第一版测试用例人工审查修订变成标准流程能省下大量重复劳动。第三个是AI 辅助文档与知识管理。信创适配过程中最宝贵的资产就是踩坑记录。把工程师的聊天记录、故障排查过程、群里的解答沉淀到一个知识库再通过大模型做一个问答入口团队遇到问题能快速检索到过去的最佳实践这比招更多人有杠杆效应得多。5.3 从项目到平台Agent 化与多模型协作的演进路线双轮驱动的长期方向一定是平台化。单点项目解决的是某一个业务场景能跑 AI平台化解决的是所有业务场景都能以低成本接入 AI。现在很多团队在建AI 能力中台把模型推理、数据接入、效果评估、安全管控做成统一服务。我个人比较看好 AI Agent 在这个阶段的价值。Agent 和大模型单点问答不一样Agent 能调用工具、能编排流程、能协同多个模型。比如一个智能运维助手Agent发现磁盘空间不足可以自动调用数据分析模型判断趋势再调用工单系统的接口创建运维工单最后把处理建议推送给管理员。这个过程中Agent 调度的能力层全部跑在信创环境里整个闭环就是 AI 信创双轮驱动的一个立体示范。多模型协作也是同样重要的演进方向。没有哪个模型可以在所有任务上都最优。在一个平台上共存多个模型按场景路由比如代码生成走一个模型、文本摘要走另一个模型、图片识别走第三个模型能实现用最合适的模型做最合适的事。底层算力层统一调度按需分配资源比每个业务各自部署一套模型要高效得多。在做这个演进的过程中一定做好平台接口的标准工作。模型格式要统一、接口要统一、监控要统一。宁可前期多花点时间做规范也不要后期被各种半标准化的接口拖死。写在最后的几点个人体会做 AI 信创双轮驱动的项目跟做普通 AI 项目最大的不同在于你永远在跟不完全受自己控制的环境打交道。你会遇到今天能跑的算子明天升级系统就崩了会遇到芯片厂商的驱动文档写得不明不白会遇到上游框架迟迟不出适配版本。这些都不是代码层面能解决的需要的是整个团队对不确定性的承受能力和持续排查问题的耐心。我自己的体会是双轮驱动不是一句口号靠的是一个链路一个链路地打通。芯片和驱动的适配、框架和操作系统的适配、模型和推理引擎的适配、应用和中间件的适配每一层都是磨出来的。你在这每一层里沉淀的测试用例、踩坑记录、性能基线就是这个项目最值钱的资产。最后再分享一个小技巧所有适配工作中的关键步骤都要用脚本固化下来不要靠人工记忆。我在项目里建立了一个一键复现目录任何一台新机器到货后跑一遍脚本就能复现出完整的 AI 运行环境。这比文档可靠多了也让团队在设备扩容时不再诚惶诚恐。AI 和信创的双轮往前走速度不会像互联网产品那么快但它每往前走一步都很扎实。在这个领域里坚持深耕长期积累的红利一定会显出来。项目要做的就是选对方向、沉住气、把每一层的适配磨到极致那你手里的这套体系就是最稀缺的竞争力。