1. AI4S到底需要什么样的算力先把这个底座盘清楚再谈替代逻辑AI4SAI for Science这几年的热度不用我多说从蛋白质结构预测到材料筛选从分子动力学模拟到气象预报越来越多科研团队把深度学习模型当成和显微镜、粒子加速器同等重要的科研基础设施。但坦白讲很多团队在引入AI时对算力需求的理解还停留在“GPU越强越好”的粗放阶段等到真正把模型跑起来才发现瓶颈根本不在峰值算力上。浙大与曦望的这次合作标题里最值得琢磨的两个词是“国产推理算力”和“生态共建”。前者说明双方的切入点不是训练而是推理后者说明合作模式不是一锤子买卖的项目交付而是围绕算力底座的长期协同。把这个定位拆开看背后其实是对AI4S负载特征的一次重新认识。先说AI4S到底是什么样的负载。很多人把它等同于常规的大模型应用这是个不小的误解。AI4S工作流其实是“科学计算 机器学习 数据处理”的混合体前端可能是高吞吐量的模拟数据生成中间是特征提取和模型推断后端还有大量的统计分析、可视化和人工验证环节。推理在这个链路里不是一个独立步骤而是被反复调用的高频操作。比如分子动力学模拟里每走一个时间步都要调用一次机器学习势函数的推理材料性能预测可能是对几十万个候选结构批量打分筛选——这类需求的特点是单次推理延时敏感、累计调用次数巨大、批量吞吐要求很高。为什么会谈国产推理算力而不是训练算力道理很简单科研模型的训练虽然成本高但它是阶段性的一年可能就训几次推理则是常态化的模型训练完成后要被反复使用、反复验证、反复迭代。对一个科研团队来讲推理算力的总拥有成本、单位推理效率、可重复性比一次性的训练峰值性能更容易成为瓶颈。也正因为推理是常态化的它才是算力国产化替代最容易切入、也最能产生实际效益的环节。还有一个容易忽略的点AI4S领域的模型推理和互联网场景的推理负载特征差异很大。互联网推荐系统是典型的高并发短请求每个请求处理的数据量小要求毫秒级响应而很多科学模型不一样一次推理就要处理整个蛋白质序列或者一整块三维网格数据数据量大、计算密集但对时延的要求相对宽裕。这意味着科学计算场景下的推理优化重点不是堆并发而是把单次推理的计算效率和内存访问效率拉满。这个差异决定了国产推理算力在AI4S领域的优化路径不能简单照搬互联网推理的现成方案。把底座盘清楚了再回头看“国产”这两个字。国产推理算力过去最被诟病的不是性能而是生态——指令集不同、算子库不全、框架适配跟不上导致科研人员拿到卡之后光是让模型跑起来就要折腾几周。浙大和曦望这次合作的核心价值我认为恰恰在于它尝试回答一个问题国产算力在AI4S这条赛道上不做通用平台的追随者而是做科学计算场景的定向优化者能不能走出一条更高效的落地路径这个问题的答案对整个行业都有参照意义。2. 国产推理算力的真实家底不能只看芯片账面参数聊国产算力首先得克服一个思维惯性别用GPU的评测思路去看AI芯片。英伟达的生态太完善了CUDA、cuDNN、TensorRT这一套下来模型性能基本由硬件峰值决定软件栈不会拖后腿。但国产算力不是这样硬件账面性能是一回事实际跑起来是另一回事中间还隔着一个巨大的软件栈鸿沟。所以评估国产推理算力的真实实力要做的是“硬件工具链应用适配”三层拆开看。2.1 推理加速的核心瓶颈不在峰值算力而在内存和访存首先明确一个技术前提对推理任务而言特别是Transformer架构的大模型推理真正的瓶颈往往是显存的带宽和容量而不是计算峰值。为什么因为推理是典型的访存密集型任务——模型参数要从显存里读一遍中间结果比如KV Cache也要反复读写每个token的生成都有大量的矩阵乘法但这些矩阵运算的FLOPs往往没有显存访问那么慢。有个很直观的比喻计算峰值像是高速公路的最高限速而显存带宽是高速路的车道数推理任务里车多路窄限速再高也跑不起来。这就解释了为什么推理优化圈子里大家特别关注两个指标一个是显存带宽直接决定每秒能喂给计算单元多少数据另一个是显存容量决定能装下多大的模型和KV Cache。很多国产芯片在FP16/BF16的计算性能上已经能做到相当不错的水平但在HBM带宽上和国际顶尖产品还有差距这个差距对推理的影响是决定性的。浙大与曦望这类“高校厂商”的联合模式意义就在于不是等芯片厂商自己发现应用瓶颈而是由科研团队把科学模型的独特访存模式反馈给算力设计方让芯片的存储层级、缓存策略、算子实现去匹配科学计算场景的实际需求。这种应用驱动的软硬件协同优化比单纯堆带宽更聪明。2.2 软件栈是最真实的短板但也是最大的机会国产算力真正的家底不只在芯片本身更在编译器、算子库和运行时这套软件栈。以AI4S领域常见的算子需求为例分子动力学模拟里常用的Ewald求和、三维FFT气象模型里的网格插值和谱变换材料模拟里的近邻表计算——这些算子不是通用的卷积和矩阵乘法而是高度领域化的数学操作。国产推理芯片要真正服务科学计算就得在算子库里原生支持这些领域算子而不是让科研人员每次都在高级语言层面自己去实现然后忍受几倍甚至几十倍的性能折扣。坦率地说国产推理算力在通用AI算子比如Conv、GEMM、Attention上的覆盖已经不错了但面向科学计算的专用算子覆盖还远远不够。这既是短板也是差异化竞争的切入点。英伟达的GPU在科学计算上的优势除了硬件更重要的是CUDA生态里积累了二十年的科学计算库——FFT、BLAS、LAPACK、甚至专门的分子动力学加速库。国产算力要走AI4S这条路不是要和CUDA正面打而是在科学计算这个细分方向上做出自己的完整工具链让科研人员跑科学工作流时感觉“这个库就是为我准备的”。2.3 举个例子一个小分子动力学模型的推理优化思路为了说明问题我用一个具体场景来模拟一下国产推理算力在AI4S里的优化路径。假设我们要用机器学习势函数替代传统的DFT计算对一万个分子构型做能量和受力预测。这个负载的特点是每次推理输入一个小分子结构模型不大通常百万级参数但推理次数极多而且对单次推理的时延有要求——因为分子动力学模拟是串行的每一步都要先推理再更新坐标。在这种场景下单纯的批量推理优化帮助有限反而需要重点做三件事把模型权重做精度压缩FP16转INT8减少显存带宽压力把多个推理请求做动态批处理让计算单元始终饱和把输入预处理和模型推理做流水线并行隐藏数据搬运的延迟。这三件事听起来不复杂但在国产芯片上做每一步都要跟算子的实现细节死磕。比如INT8量化不同芯片对低比特计算的支持度差别极大有些芯片的INT8吞吐只有FP16的一半那量化反而得不偿失。这个就需要算力厂商提供精确的算子性能画像科研团队拿着画像再决定优化策略。高校和厂商联合的优势也在这里——高校团队清楚科学模型的结构特点厂商清楚硬件的行为特征两边对到一起才能找到最优解。3. 联合攻关的价值不止是“让模型跑起来”校企合作在AI领域不是新鲜事但“联合攻关”和“项目外包”有本质区别。外包的目标是交付一个能用的系统联合攻关的目标是沉淀一套“双方都能复用”的能力。浙大与曦望合作的关键我认为不在于做出了某个具体的模型或者平台而在于形成了一套将科学模型与国产推理算力深度适配的方法论。3.1 以算子级优化为入口比框架移植更务实现在很多算力厂商做生态思路是“把主流AI框架适配好让用户直接跑”。这个思路对互联网场景有效因为大家都用PyTorch、Transformer适配好一个框架几万个模型都能受益。但科学计算的模型五花八门框架适配只是第一步真正决定性能的是底层算子。联合攻关的第一层应该落在算子级优化上。比如在分子动力学模型里核心计算是某个自定义的相互作用算子它的计算逻辑和标准的卷积差异很大但又是整个模型的性能热区。如果把PyTorch代码直接跑在国产芯片上框架层能跑通但性能可能只有优化后的十分之一。这时候需要做的事情是把热点算子用芯片的原生指令重新实现或者用汇编级调优把访存、计算、流水线全部理顺。这部分工作光靠厂商闭门造车做不出来因为不知道科研模型的热点到底在哪儿光靠科研团队也做不了因为不了解芯片的指令集细节。必须两边坐在一起对着profiling结果一点点抠。3.2 模型压缩在科学场景中的应用边界AI4S的模型一般不大但精度要求非常高——预测蛋白质结构差一点点整个折叠构象就不对了预测分子间作用力差几个meV反应路径判断就会出错。把这个问题跟模型量化放在一起看有点意思。互联网大模型压缩到INT4还能保持可用因为生成任务对单个token的精度不敏感错了还能靠自回归慢慢修正。科学模型不行它对数值精度有近乎洁癖的要求。我做过的计算里有些模型在FP16下跑的完美结果转成INT8之后个别原子的受力误差直接翻倍。所以科学模型的压缩策略要保守得多优先使用FP16/BF16保留中间结果的FP32累加如果要用INT8量化必须做逐层敏感度分析而不是简单全局量化混合精度是常态量化的重点放在权重上激活值尽量保留高精度量化之后必须有验证环节不仅是看总精度指标还要关注误差分布——有没有个别样本出现严重偏离。这几点对芯片厂商的启示是国产推理算力在AI4S领域不能只强调低精度推理有多快更要提供精细的精度控制能力比如混合精度算子的原生支持、量化感知训练的工具链等。多做一步科研团队采用国产算力的意愿就强一分。3.3 科研团队算力团队之间的任务切分谁做什么边界在哪里联合攻关最怕的是职责混乱。科研团队觉得算力出了Bug都是厂商的锅厂商觉得模型跑得慢是用户代码写得烂最后陷入互相甩锅的泥潭。根据我的经验其实任务切分是有相对清晰边界的科研团队负责模型层面网络结构设计、训练策略、数据预处理、精度验证标准算力厂商负责平台层面算子库同步与优化、运行时性能调优、框架适配、profiling工具提供双方共同负责的是中间的“翻译层”如何把科学模型的算子映射到芯片的最佳实现上。这一层需要频繁沟通也是联合攻关真正产生化学反应的地方。这种切分方式能让双方都在自己最擅长的事情上发力避免资源浪费。我见过太多合作项目研发群里几百条消息一半时间在讨论跑不通的算子和无关紧要的环境变量。定好职责边界很多问题可以少走弯路。4. 共建的真正难点不在代码而在标准化和可复现从联合攻关走向生态共建不是换个名字的事。联合攻关解决的是特定项目的问题生态共建要解决的是“让没有参加联合攻关的第三方团队也能用起来”的问题。这一步跨越比想象中难得多。4.1 生态共建的度量标准不是接口多而是可复现性强一个科学计算生态能不能起来最朴素的检验方式是一个陌生团队拿到你的工具链能不能在不求助原厂支持的情况下把论文里的工作流完整复现出来。这个标准听起来低实际做到很难。在国产推理算力上复现科学工作流常见的问题包括文档里写了支持某个算子实际调用时性能巨差PyTorch代码跑通了但换一个batch size或者输入尺寸性能就崩了量化模型在某个固定版本上验证过精度更新一版之后结果出现轻微漂移。我在自己复现别人工作的过程中每次遇到类似问题都要花掉大量时间排查。一个生态如果让用户把精力都花在“和配置死磕”而不是“和科学问题死磕”上它就不可能形成真正的黏性。所以生态共建的第一项工作是建立完善的可复现性测试体系对每个支持的科学计算模型都有标准的精度验证基准、性能基线、依赖版本锁定说明。这个工作不性感也不容易出新闻但它是生态能滚起来的地基。4.2 中间件和科研社区是生态缺的那块拼图现在国产算力生态普遍存在一个断层最底层芯片指令集是有的最上层PyTorch是兼容的但中间层——面向具体科学领域的工具包和模板——极度匮乏。科研人员拿到AI芯片除了能跑PyTorch的基础示例马上要用的领域库比如生物计算里的AlphaFold类工具、材料计算里的机器学习势函数框架还是空白。没有这些中间件科研人员就要从C和底层优化开始造轮子这显然不现实。真正能吸引科研团队使用的生态一定是一个“带内容”的生态——不仅提供算力还提供领域里的通行工作流。这是生态共建中难度最大、也是最值得投入的部分。大学在这块有天然优势实验室里沉淀的科研代码、数据集、基准测试集本身就是最宝贵的生态资产。把这些资产整理成标准化接口、样例工程、技术教程交给算力厂商做集成和持续优化就能形成“资产复用→生态完善→更多团队使用→生态更完善”的正循环。4.3 衡量生态健康度的三个可量化指标谈生态容易飘在空中落到实操上可以用三个指标来衡量第三方复现时间一个没接触过该算力平台的科研团队把标准示例跑通需要多久。从几周缩短到几小时这个指标的变化最能说明生态在变好算子覆盖率AI4S热门工作流中用到的算子有多少在平台上有一等性能与理论峰值相比差距不超过某个阈值。覆盖率越高用户需要自己优化的部分就越少社区贡献回流外部团队使用平台后有多少工具、样例、问题反馈回流到生态里。一个只出不进、单向输出的生态本质上是不可持续的。这三个指标尽管无法精确掌握浙大与曦望当前的具体数值但可以作为评估这次合作成效的方向性参考。联合攻关刚结束的时候可能每个指标都很难看但如果生态共建的路子走对了几年后再看这三个数字就会成为最有说服力的证明。5. 普通科研团队想上国产推理算力实操层面的准备工作和避坑思路分析完战略层面的问题最后落到一个非常现实的问题上如果我的课题组想尝试国产推理算力做AI4S第一步该怎么迈5.1 先跑通一个最小工作流再把任务逐步放大很多团队走了一条艰难的路一开始就想把全部计算任务迁到国产算力上结果发现迁移过程中处处碰壁项目卡顿超过半年团队士气严重受损。更合理的思路是“最小工作流启动”选一个课题里最简单、最容易验证的模型先在国产推理算力上完整跑一遍。从这个最小工作流里重点观察三个点现有的模型代码在国产芯片上是否可以直接运行还是需要做框架层面的适配模型执行过程中有没有明显的性能热点这些热点是程序自身的计算瓶颈还是平台造成的额外开销工具链是否顺手Profiling、报错提示、调试手段是否够用。等这个最小工作流跑通并积累起项目经验后再逐步迁移更复杂的模型和应用。这个方法简单但实用能让团队用最小的沉没成本快速了解国产推理算力的真实能力边界也更容易在问题早期获得厂商支持。5.2 一个极简的适配流程示例为了方便理解我这里给出一个比较通用的适配参考流程适用于大多数PyTorch风格的科研模型。注意这不是唯一方案但一般够用在原来熟悉的计算平台上先把模型跑通记录正确的输出结果和关键性能指标比如单次推理时延、吞吐量作为后续验证的基准按照目标国产平台的文档配置好运行环境把模型的PyTorch版本和依赖库版本记录清楚不要直接照搬最新的包先将模型在国产平台上以纯PyTorch模式跑一遍确认功能性结果和基准平台一致这一步不追求性能只追求“跑得正确”查看Profiling报告标记耗时占比最高的几个算子用运行库官方提供的算子或替代实现在这些热区上做替换再次跑通流程确认功能仍正确然后对比性能指标看哪些算子替换有正收益、哪些反而变慢了根据对比结果决定后续优化策略——是继续深挖热点算子还是保持现状避免过度优化浪费时间。整个过程里最重要的一点是每一步只改一个变量。有的人喜欢一次换成最新版框架、顺手改掉预处理逻辑、再顺手批处理代码重构最后出了问题完全不知道是哪一步导致的。做国产化适配一定要有“每一步都可回溯”的耐心效率反而更高。5.3 两个容易被忽视的坑依赖锁定和厂商绑定最后分享两个我在类似项目里踩过、反复出现的坑。首先是依赖锁定。科学计算项目的依赖极其复杂——Python版本、CUDA对应芯片的驱动和运行时、PyTorch版本、领域框架版本、底层库实现任何一个环节的不兼容都会导致工作流跑不起来。迁移国产算力平台的时候第一个要做的就是冻结一个完整的、验证过的环境快照容器镜像或者conda环境导出后续所有实验都在这个环境里跑不要随意升级。很多团队用了两个月国产算力陷阱不是出在性能而是出在隔三差五的依赖冲突上极大消耗了耐心。其次是厂商绑定。用国产算力总会在不知不觉中依赖某些厂商特有的优化库接口。这本身没有问题——在生态初期深度适配是获取性能的必要代价。但一定要有意识地把“模型逻辑”和“算力特定优化代码”分离把模型定义、数据处理、训练推理逻辑写成通用的Python代码把性能优化相关的算子替换、图优化、量化逻辑封装成独立的模块并做好接口隔离。这样将来换平台或者需要复现别人的实验时不用从零开始。国产推理算力在AI4S这条路上已经走出了从“能不能用”到“好不好用”的关键阶段。浙大与曦望这类合作的示范意义不仅是让某个具体模型跑在了国产芯片上更重要的是它验证了一条高校、科研机构与算力厂商深度协同、共建生态的路径。这条路走通了接下来会有更多科研团队愿意把国产推理算力纳入自己的工具箱。对做科学计算的年轻团队来说现在开始积累国产算力平台上的适配经验不是在给自己找麻烦而是在给未来的科研生涯多买一份保险。 AI for Science的国产推理算力底座：从技术瓶颈到生态共建
1. AI4S到底需要什么样的算力先把这个底座盘清楚再谈替代逻辑AI4SAI for Science这几年的热度不用我多说从蛋白质结构预测到材料筛选从分子动力学模拟到气象预报越来越多科研团队把深度学习模型当成和显微镜、粒子加速器同等重要的科研基础设施。但坦白讲很多团队在引入AI时对算力需求的理解还停留在“GPU越强越好”的粗放阶段等到真正把模型跑起来才发现瓶颈根本不在峰值算力上。浙大与曦望的这次合作标题里最值得琢磨的两个词是“国产推理算力”和“生态共建”。前者说明双方的切入点不是训练而是推理后者说明合作模式不是一锤子买卖的项目交付而是围绕算力底座的长期协同。把这个定位拆开看背后其实是对AI4S负载特征的一次重新认识。先说AI4S到底是什么样的负载。很多人把它等同于常规的大模型应用这是个不小的误解。AI4S工作流其实是“科学计算 机器学习 数据处理”的混合体前端可能是高吞吐量的模拟数据生成中间是特征提取和模型推断后端还有大量的统计分析、可视化和人工验证环节。推理在这个链路里不是一个独立步骤而是被反复调用的高频操作。比如分子动力学模拟里每走一个时间步都要调用一次机器学习势函数的推理材料性能预测可能是对几十万个候选结构批量打分筛选——这类需求的特点是单次推理延时敏感、累计调用次数巨大、批量吞吐要求很高。为什么会谈国产推理算力而不是训练算力道理很简单科研模型的训练虽然成本高但它是阶段性的一年可能就训几次推理则是常态化的模型训练完成后要被反复使用、反复验证、反复迭代。对一个科研团队来讲推理算力的总拥有成本、单位推理效率、可重复性比一次性的训练峰值性能更容易成为瓶颈。也正因为推理是常态化的它才是算力国产化替代最容易切入、也最能产生实际效益的环节。还有一个容易忽略的点AI4S领域的模型推理和互联网场景的推理负载特征差异很大。互联网推荐系统是典型的高并发短请求每个请求处理的数据量小要求毫秒级响应而很多科学模型不一样一次推理就要处理整个蛋白质序列或者一整块三维网格数据数据量大、计算密集但对时延的要求相对宽裕。这意味着科学计算场景下的推理优化重点不是堆并发而是把单次推理的计算效率和内存访问效率拉满。这个差异决定了国产推理算力在AI4S领域的优化路径不能简单照搬互联网推理的现成方案。把底座盘清楚了再回头看“国产”这两个字。国产推理算力过去最被诟病的不是性能而是生态——指令集不同、算子库不全、框架适配跟不上导致科研人员拿到卡之后光是让模型跑起来就要折腾几周。浙大和曦望这次合作的核心价值我认为恰恰在于它尝试回答一个问题国产算力在AI4S这条赛道上不做通用平台的追随者而是做科学计算场景的定向优化者能不能走出一条更高效的落地路径这个问题的答案对整个行业都有参照意义。2. 国产推理算力的真实家底不能只看芯片账面参数聊国产算力首先得克服一个思维惯性别用GPU的评测思路去看AI芯片。英伟达的生态太完善了CUDA、cuDNN、TensorRT这一套下来模型性能基本由硬件峰值决定软件栈不会拖后腿。但国产算力不是这样硬件账面性能是一回事实际跑起来是另一回事中间还隔着一个巨大的软件栈鸿沟。所以评估国产推理算力的真实实力要做的是“硬件工具链应用适配”三层拆开看。2.1 推理加速的核心瓶颈不在峰值算力而在内存和访存首先明确一个技术前提对推理任务而言特别是Transformer架构的大模型推理真正的瓶颈往往是显存的带宽和容量而不是计算峰值。为什么因为推理是典型的访存密集型任务——模型参数要从显存里读一遍中间结果比如KV Cache也要反复读写每个token的生成都有大量的矩阵乘法但这些矩阵运算的FLOPs往往没有显存访问那么慢。有个很直观的比喻计算峰值像是高速公路的最高限速而显存带宽是高速路的车道数推理任务里车多路窄限速再高也跑不起来。这就解释了为什么推理优化圈子里大家特别关注两个指标一个是显存带宽直接决定每秒能喂给计算单元多少数据另一个是显存容量决定能装下多大的模型和KV Cache。很多国产芯片在FP16/BF16的计算性能上已经能做到相当不错的水平但在HBM带宽上和国际顶尖产品还有差距这个差距对推理的影响是决定性的。浙大与曦望这类“高校厂商”的联合模式意义就在于不是等芯片厂商自己发现应用瓶颈而是由科研团队把科学模型的独特访存模式反馈给算力设计方让芯片的存储层级、缓存策略、算子实现去匹配科学计算场景的实际需求。这种应用驱动的软硬件协同优化比单纯堆带宽更聪明。2.2 软件栈是最真实的短板但也是最大的机会国产算力真正的家底不只在芯片本身更在编译器、算子库和运行时这套软件栈。以AI4S领域常见的算子需求为例分子动力学模拟里常用的Ewald求和、三维FFT气象模型里的网格插值和谱变换材料模拟里的近邻表计算——这些算子不是通用的卷积和矩阵乘法而是高度领域化的数学操作。国产推理芯片要真正服务科学计算就得在算子库里原生支持这些领域算子而不是让科研人员每次都在高级语言层面自己去实现然后忍受几倍甚至几十倍的性能折扣。坦率地说国产推理算力在通用AI算子比如Conv、GEMM、Attention上的覆盖已经不错了但面向科学计算的专用算子覆盖还远远不够。这既是短板也是差异化竞争的切入点。英伟达的GPU在科学计算上的优势除了硬件更重要的是CUDA生态里积累了二十年的科学计算库——FFT、BLAS、LAPACK、甚至专门的分子动力学加速库。国产算力要走AI4S这条路不是要和CUDA正面打而是在科学计算这个细分方向上做出自己的完整工具链让科研人员跑科学工作流时感觉“这个库就是为我准备的”。2.3 举个例子一个小分子动力学模型的推理优化思路为了说明问题我用一个具体场景来模拟一下国产推理算力在AI4S里的优化路径。假设我们要用机器学习势函数替代传统的DFT计算对一万个分子构型做能量和受力预测。这个负载的特点是每次推理输入一个小分子结构模型不大通常百万级参数但推理次数极多而且对单次推理的时延有要求——因为分子动力学模拟是串行的每一步都要先推理再更新坐标。在这种场景下单纯的批量推理优化帮助有限反而需要重点做三件事把模型权重做精度压缩FP16转INT8减少显存带宽压力把多个推理请求做动态批处理让计算单元始终饱和把输入预处理和模型推理做流水线并行隐藏数据搬运的延迟。这三件事听起来不复杂但在国产芯片上做每一步都要跟算子的实现细节死磕。比如INT8量化不同芯片对低比特计算的支持度差别极大有些芯片的INT8吞吐只有FP16的一半那量化反而得不偿失。这个就需要算力厂商提供精确的算子性能画像科研团队拿着画像再决定优化策略。高校和厂商联合的优势也在这里——高校团队清楚科学模型的结构特点厂商清楚硬件的行为特征两边对到一起才能找到最优解。3. 联合攻关的价值不止是“让模型跑起来”校企合作在AI领域不是新鲜事但“联合攻关”和“项目外包”有本质区别。外包的目标是交付一个能用的系统联合攻关的目标是沉淀一套“双方都能复用”的能力。浙大与曦望合作的关键我认为不在于做出了某个具体的模型或者平台而在于形成了一套将科学模型与国产推理算力深度适配的方法论。3.1 以算子级优化为入口比框架移植更务实现在很多算力厂商做生态思路是“把主流AI框架适配好让用户直接跑”。这个思路对互联网场景有效因为大家都用PyTorch、Transformer适配好一个框架几万个模型都能受益。但科学计算的模型五花八门框架适配只是第一步真正决定性能的是底层算子。联合攻关的第一层应该落在算子级优化上。比如在分子动力学模型里核心计算是某个自定义的相互作用算子它的计算逻辑和标准的卷积差异很大但又是整个模型的性能热区。如果把PyTorch代码直接跑在国产芯片上框架层能跑通但性能可能只有优化后的十分之一。这时候需要做的事情是把热点算子用芯片的原生指令重新实现或者用汇编级调优把访存、计算、流水线全部理顺。这部分工作光靠厂商闭门造车做不出来因为不知道科研模型的热点到底在哪儿光靠科研团队也做不了因为不了解芯片的指令集细节。必须两边坐在一起对着profiling结果一点点抠。3.2 模型压缩在科学场景中的应用边界AI4S的模型一般不大但精度要求非常高——预测蛋白质结构差一点点整个折叠构象就不对了预测分子间作用力差几个meV反应路径判断就会出错。把这个问题跟模型量化放在一起看有点意思。互联网大模型压缩到INT4还能保持可用因为生成任务对单个token的精度不敏感错了还能靠自回归慢慢修正。科学模型不行它对数值精度有近乎洁癖的要求。我做过的计算里有些模型在FP16下跑的完美结果转成INT8之后个别原子的受力误差直接翻倍。所以科学模型的压缩策略要保守得多优先使用FP16/BF16保留中间结果的FP32累加如果要用INT8量化必须做逐层敏感度分析而不是简单全局量化混合精度是常态量化的重点放在权重上激活值尽量保留高精度量化之后必须有验证环节不仅是看总精度指标还要关注误差分布——有没有个别样本出现严重偏离。这几点对芯片厂商的启示是国产推理算力在AI4S领域不能只强调低精度推理有多快更要提供精细的精度控制能力比如混合精度算子的原生支持、量化感知训练的工具链等。多做一步科研团队采用国产算力的意愿就强一分。3.3 科研团队算力团队之间的任务切分谁做什么边界在哪里联合攻关最怕的是职责混乱。科研团队觉得算力出了Bug都是厂商的锅厂商觉得模型跑得慢是用户代码写得烂最后陷入互相甩锅的泥潭。根据我的经验其实任务切分是有相对清晰边界的科研团队负责模型层面网络结构设计、训练策略、数据预处理、精度验证标准算力厂商负责平台层面算子库同步与优化、运行时性能调优、框架适配、profiling工具提供双方共同负责的是中间的“翻译层”如何把科学模型的算子映射到芯片的最佳实现上。这一层需要频繁沟通也是联合攻关真正产生化学反应的地方。这种切分方式能让双方都在自己最擅长的事情上发力避免资源浪费。我见过太多合作项目研发群里几百条消息一半时间在讨论跑不通的算子和无关紧要的环境变量。定好职责边界很多问题可以少走弯路。4. 共建的真正难点不在代码而在标准化和可复现从联合攻关走向生态共建不是换个名字的事。联合攻关解决的是特定项目的问题生态共建要解决的是“让没有参加联合攻关的第三方团队也能用起来”的问题。这一步跨越比想象中难得多。4.1 生态共建的度量标准不是接口多而是可复现性强一个科学计算生态能不能起来最朴素的检验方式是一个陌生团队拿到你的工具链能不能在不求助原厂支持的情况下把论文里的工作流完整复现出来。这个标准听起来低实际做到很难。在国产推理算力上复现科学工作流常见的问题包括文档里写了支持某个算子实际调用时性能巨差PyTorch代码跑通了但换一个batch size或者输入尺寸性能就崩了量化模型在某个固定版本上验证过精度更新一版之后结果出现轻微漂移。我在自己复现别人工作的过程中每次遇到类似问题都要花掉大量时间排查。一个生态如果让用户把精力都花在“和配置死磕”而不是“和科学问题死磕”上它就不可能形成真正的黏性。所以生态共建的第一项工作是建立完善的可复现性测试体系对每个支持的科学计算模型都有标准的精度验证基准、性能基线、依赖版本锁定说明。这个工作不性感也不容易出新闻但它是生态能滚起来的地基。4.2 中间件和科研社区是生态缺的那块拼图现在国产算力生态普遍存在一个断层最底层芯片指令集是有的最上层PyTorch是兼容的但中间层——面向具体科学领域的工具包和模板——极度匮乏。科研人员拿到AI芯片除了能跑PyTorch的基础示例马上要用的领域库比如生物计算里的AlphaFold类工具、材料计算里的机器学习势函数框架还是空白。没有这些中间件科研人员就要从C和底层优化开始造轮子这显然不现实。真正能吸引科研团队使用的生态一定是一个“带内容”的生态——不仅提供算力还提供领域里的通行工作流。这是生态共建中难度最大、也是最值得投入的部分。大学在这块有天然优势实验室里沉淀的科研代码、数据集、基准测试集本身就是最宝贵的生态资产。把这些资产整理成标准化接口、样例工程、技术教程交给算力厂商做集成和持续优化就能形成“资产复用→生态完善→更多团队使用→生态更完善”的正循环。4.3 衡量生态健康度的三个可量化指标谈生态容易飘在空中落到实操上可以用三个指标来衡量第三方复现时间一个没接触过该算力平台的科研团队把标准示例跑通需要多久。从几周缩短到几小时这个指标的变化最能说明生态在变好算子覆盖率AI4S热门工作流中用到的算子有多少在平台上有一等性能与理论峰值相比差距不超过某个阈值。覆盖率越高用户需要自己优化的部分就越少社区贡献回流外部团队使用平台后有多少工具、样例、问题反馈回流到生态里。一个只出不进、单向输出的生态本质上是不可持续的。这三个指标尽管无法精确掌握浙大与曦望当前的具体数值但可以作为评估这次合作成效的方向性参考。联合攻关刚结束的时候可能每个指标都很难看但如果生态共建的路子走对了几年后再看这三个数字就会成为最有说服力的证明。5. 普通科研团队想上国产推理算力实操层面的准备工作和避坑思路分析完战略层面的问题最后落到一个非常现实的问题上如果我的课题组想尝试国产推理算力做AI4S第一步该怎么迈5.1 先跑通一个最小工作流再把任务逐步放大很多团队走了一条艰难的路一开始就想把全部计算任务迁到国产算力上结果发现迁移过程中处处碰壁项目卡顿超过半年团队士气严重受损。更合理的思路是“最小工作流启动”选一个课题里最简单、最容易验证的模型先在国产推理算力上完整跑一遍。从这个最小工作流里重点观察三个点现有的模型代码在国产芯片上是否可以直接运行还是需要做框架层面的适配模型执行过程中有没有明显的性能热点这些热点是程序自身的计算瓶颈还是平台造成的额外开销工具链是否顺手Profiling、报错提示、调试手段是否够用。等这个最小工作流跑通并积累起项目经验后再逐步迁移更复杂的模型和应用。这个方法简单但实用能让团队用最小的沉没成本快速了解国产推理算力的真实能力边界也更容易在问题早期获得厂商支持。5.2 一个极简的适配流程示例为了方便理解我这里给出一个比较通用的适配参考流程适用于大多数PyTorch风格的科研模型。注意这不是唯一方案但一般够用在原来熟悉的计算平台上先把模型跑通记录正确的输出结果和关键性能指标比如单次推理时延、吞吐量作为后续验证的基准按照目标国产平台的文档配置好运行环境把模型的PyTorch版本和依赖库版本记录清楚不要直接照搬最新的包先将模型在国产平台上以纯PyTorch模式跑一遍确认功能性结果和基准平台一致这一步不追求性能只追求“跑得正确”查看Profiling报告标记耗时占比最高的几个算子用运行库官方提供的算子或替代实现在这些热区上做替换再次跑通流程确认功能仍正确然后对比性能指标看哪些算子替换有正收益、哪些反而变慢了根据对比结果决定后续优化策略——是继续深挖热点算子还是保持现状避免过度优化浪费时间。整个过程里最重要的一点是每一步只改一个变量。有的人喜欢一次换成最新版框架、顺手改掉预处理逻辑、再顺手批处理代码重构最后出了问题完全不知道是哪一步导致的。做国产化适配一定要有“每一步都可回溯”的耐心效率反而更高。5.3 两个容易被忽视的坑依赖锁定和厂商绑定最后分享两个我在类似项目里踩过、反复出现的坑。首先是依赖锁定。科学计算项目的依赖极其复杂——Python版本、CUDA对应芯片的驱动和运行时、PyTorch版本、领域框架版本、底层库实现任何一个环节的不兼容都会导致工作流跑不起来。迁移国产算力平台的时候第一个要做的就是冻结一个完整的、验证过的环境快照容器镜像或者conda环境导出后续所有实验都在这个环境里跑不要随意升级。很多团队用了两个月国产算力陷阱不是出在性能而是出在隔三差五的依赖冲突上极大消耗了耐心。其次是厂商绑定。用国产算力总会在不知不觉中依赖某些厂商特有的优化库接口。这本身没有问题——在生态初期深度适配是获取性能的必要代价。但一定要有意识地把“模型逻辑”和“算力特定优化代码”分离把模型定义、数据处理、训练推理逻辑写成通用的Python代码把性能优化相关的算子替换、图优化、量化逻辑封装成独立的模块并做好接口隔离。这样将来换平台或者需要复现别人的实验时不用从零开始。国产推理算力在AI4S这条路上已经走出了从“能不能用”到“好不好用”的关键阶段。浙大与曦望这类合作的示范意义不仅是让某个具体模型跑在了国产芯片上更重要的是它验证了一条高校、科研机构与算力厂商深度协同、共建生态的路径。这条路走通了接下来会有更多科研团队愿意把国产推理算力纳入自己的工具箱。对做科学计算的年轻团队来说现在开始积累国产算力平台上的适配经验不是在给自己找麻烦而是在给未来的科研生涯多买一份保险。