做AI开发的朋友大多听过这段往事，早些年DeepSeek启动昇腾适配的时候，很多人都抱有很高期待，盼着大模型能够稳定跑在国产算力上。但在训练环节接连遇到算子、精度、集群通信的卡点之后，项目节奏被迫放慢，训练任务暂时切回原有算力平台，昇腾只保留推理部署。当时不少行业看客直接判定，两边合作走不下去，算是分道扬镳。时隔一段时间再看，事情走向完全不一样，双方不再是简单的模型移植适配，而是进入co-design联合设计阶段，一起面向大模型需求打磨下一代昇腾芯片。今天抛开行业传闻，顺着时间线讲清楚当初卡住的真实原因，以及co-design到底和普通适配有什么本质差别。
一、当年暂缓适配，不是不想做，是真实技术鸿沟摆在面前
很多圈外读者会简单理解，适配就是把模型代码复制过来，改几行参数就能跑。实际上大模型迁移算力平台，远比想象复杂。最早DeepSeek和昇腾对接的时候，目标是实现训练、推理全链路跑在昇腾硬件上。推理场景的适配推进相对顺利，小规模服务上线没有太大阻碍，但是进入大规模预训练阶段，一连串底层问题集中暴露出来。
核心卡点集中在三个地方。第一是算子生态差异，当时DeepSeek自研的TileLang算子体系，大量计算逻辑是面向另一套成熟生态开发，昇腾CANN的指令、内存排布、并行调度逻辑不一样，直接迁移之后，一部分算子性能打折扣，还有一部分算子精度对齐困难，同样的模型参数，在不同硬件上输出结果出现偏差，对于追求稳定复现的预训练来说，这是硬门槛。
第二是多卡集群通信，大模型训练不是单卡跑，动辄上百卡、上千卡组网。集群里面卡与卡之间数据交换的延迟、带宽损耗，会直接拖累整体训练效率。早期大规模集群方案调优经验积累不多，多卡同步的时候容易出现瓶颈，训练速度达不到业务可用标准。

第三是工程成本，团队一边要维持自家模型版本快速迭代，一边投入大量人力去改写底层算子、调试集群。在资源有限的前提下，优先保障主模型研发进度是务实选择，于是做出阶段性调整：训练暂缓迁移，昇腾先承载推理业务。
消息传出去之后，信息慢慢变味。很多自媒体直接解读成合作失败、双方分开走路线。但从官方后续披露的信息来看，适配团队一直没有解散，基础层面的对接、问题反馈、联合调试还在持续推进，只是不再对外高调放出训练上线时间表，属于阶段性放缓，不是终止合作。
二、分清两个概念：普通适配，和现在的co-design，完全不是一回事
很多人会混淆适配和联合设计，这里把差别讲明白。
常规的模型适配，顺序是固定的：芯片厂商先把芯片、指令集、软件栈全部定型发布，大模型团队拿到成品硬件，再修改模型代码、算子、并行策略，去迁就硬件的固有设计。硬件已经定版，模型侧只能在软件层面做调整，硬件架构、存储带宽、互联接口都没法改动，遇到底层不匹配的痛点，只能想办法绕开。

而co-design，也就是软硬件协同联合设计，顺序反过来。模型团队深度参与芯片定义阶段，把大模型训练里真实遇到的痛点、算子访问特征、内存读写模式、集群通信需求，提前提交给芯片设计团队。芯片在规划架构、缓存布局、互联协议、指令集的时候，就针对性做出适配。硬件生来就贴合这类大模型的计算习惯，而不是模型后期强行适配硬件。
放到这次合作里，DeepSeek这边长期跑MoE混合专家模型，这类模型有自己独特的访问特点：激活专家分散、动态路由、频繁做跨卡数据搬运，对片上缓存、全局互联带宽要求和稠密模型不一样。在普通适配模式下，这些特性很难被硬件优化；进入co-design阶段之后，这些业务特征会直接输入到芯片前期定义环节。
简单打个比方，普通适配相当于鞋子已经做好，脚去适应鞋子，挤脚只能靠垫鞋垫；co-design相当于做鞋之前，先拿到脚的完整数据，按照脚型定制鞋子。这也是这件事最关键的增量信息，不再是单向软件迁就硬件，而是双向对齐。
三、中间这段过渡期，双方其实一直在铺垫底层能力，没有停下
从暂缓大规模训练适配，到官宣推进co-design，中间不是空白期，双方做了很多基础铺垫，也是后面能走到联合设计的前提。

在2026年9月底，DeepSeek正式开源面向昇腾平台的整套基础设施组件，包含TileLang算子编程语言对应的编译支持、计算库、分布式通信库，并且明确说明，这套组件和面向原有算力平台的组件一一对应。这一步非常关键，相当于把自家核心算子开发体系，完整移植到CANN生态上，后续写算子可以一套开发习惯，跨硬件复用，大幅降低持续适配成本。
同时双方联合落地昇腾950的128卡超节点方案，针对MoE模型的通信、调度做专项优化。这个阶段，重点不再是急着跑完整预训练，而是先把集群通信、内存访问、算子库这些地基打扎实，收集大规模跑起来之后的真实性能数据、瓶颈日志。这些一线实测数据，就是co-design阶段用来定义下一代芯片的依据。
很多行业生态合作都是停留在应用层，也就是模型跑起来给客户用；而这次合作下沉到算子、编译、互联架构，属于算力底座层面的共建。也正是因为有这一段持续的联合调优，双方清楚彼此的短板和诉求，才有底气往更早的芯片设计环节延伸。
四、co-design能解决哪些老适配解决不了的痛点，上限在哪
针对MoE这类主流大模型，联合设计可以针对性解决几个长期困扰开发者的痛点。
第一个痛点是动态路由带来的数据搬运开销。MoE每次推理和训练，样本会路由到不同专家，数据在卡之间来回搬运，通信开销占比很高。常规芯片是通用设计，不会专门针对这种动态流量优化；co-design阶段可以调整片间互联、本地缓存容量、路由硬件加速单元，减少无效数据搬运，直接压低通信延迟。
第二个痛点是算子冗余适配成本。之前很多特殊算子，需要工程师花大量时间手动改写、调优精度。在芯片定义阶段，就把高频算子的硬件加速单元、原生指令做好，软件侧不用反复做复杂的精度对齐，模型迁移成本会持续下降。
第三个痛点是超大集群的稳定性。上万卡规模训练的时候，微小的延迟抖动会层层放大。联合设计的时候，模型侧把真实的负载波动特征给到硬件团队，在芯片固件、超节点互联协议层面做对应的调度优化，提升集群长期稳定运行能力。
当然也要客观看待边界，co-design不是万能方案，不能一步抹平多年的生态差距。它是定向优化，优先服务这类MoE大模型的训练和推理需求，不会让一款芯片适配所有类型AI任务。而且芯片设计、流片、量产本身周期很长，现在处于联合定义阶段，成品落地、大规模上线还需要时间，短期内现有昇腾存量芯片，依旧还是走软件持续优化、算子迭代的路线。
五、放到整个国产算力生态里，这件事的示范意义是什么
国内昇腾生态里，大部分伙伴的合作模式，依然是拿到成熟芯片之后，做模型移植、行业方案落地。像这样头部大模型团队，深度前置到芯片架构定义环节的案例，不算多。
过去很长一段时间，国产算力生态有一个常见难题：芯片先造出来，再慢慢等模型厂商适配，模型厂商觉得硬件不好用，芯片厂商觉得模型没有把硬件潜力跑满，两边信息差很难消除。co-design模式，就是打通这个信息差的一条路径。模型方带着真实业务负载，芯片方带着硬件架构约束，在早期一起权衡带宽、缓存、算力单元、功耗之间的取舍。
这种模式跑通之后，也会给其他模型团队、算力厂商提供参考。不同模型架构，比如稠密推理模型、Agent智能体模型、多模态模型，计算特征各不相同，未来可以出现更多定向协同设计的算力方案，而不是全部用一款通用NPU去承载所有AI任务。
同时这件事也能纠正一个认知误区：国产算力生态建设，不是靠单一厂商独自完成。昇腾提供硬件底座、CANN软件栈，模型厂商贡献模型负载、算子需求、应用侧痛点，大家分工配合，才能够持续补齐短板。当年暂缓适配，不是生态失败，而是一次试错之后，找到了更深度、更长期的合作方式。
六、普通开发者和行业用户，能从中拿到什么实际好处
很多人会觉得，芯片联合设计是大厂之间的事情，和普通开发者、中小企业关系不大，其实不然。
第一，长期来看，定向优化后的硬件，跑对应架构模型的时候，同等算力规模，训练速度更快、单位token成本更低。后续中小企业租用算力跑模型、做微调，算力账单压力会变小。
第二，算子库、编译链这些基础组件开源之后，不只是DeepSeek自家模型受益，其他基于TileLang开发模型的开发者，都可以直接复用这套昇腾适配组件，降低迁移门槛，不用从零开始改写算子。
第三，整个联合调优沉淀下来的超节点集群方案、稳定性经验，会慢慢开放到昇腾社区，后续其他大模型在昇腾950以及后续新芯片上部署，踩坑会更少。
但是这里也要理性提醒：红利释放是循序渐进的。短期普通开发者感知不会特别明显，存量昇腾服务器的性能提升，主要来自持续的CANN版本迭代、算子优化；真正co-design的下一代芯片落地之后，差异化优势才会集中体现。
七、客观看待风险，不要过度乐观
利好之外，同样有几个现实约束不能忽略。
首先是周期风险。芯片从架构定义、仿真、流片、回片测试，再到量产、大规模集群交付，周期很长。即便现在方案对齐，用户能在市场上稳定买到、租到对应的算力，需要等待很久，中间还存在流片、良率等不确定性。
其次是定位问题。联合设计的芯片优先匹配MoE大模型的特征，其他类型模型不一定能拿到同等幅度的收益，通用算力场景的表现，还是需要单独验证。
最后，生态建设是系统性工程，单靠一次co-design，没办法瞬间补齐工具链、第三方库、配套服务上面积累多年的差距，软件生态的完善，依旧需要持续投入。
写在最后
回头梳理整件事，当年暂缓训练适配，是工程层面权衡之后的阶段性选择，不是合作的终点。外界很容易凭着阶段性的进展，快速下一个“分道扬镳”的判断，而行业里面很多深度合作，往往是在反复试错、暴露痛点之后，才走到更深层次的协同。
从模型适配硬件，到双方一起定义下一代芯片，这一步转变，对于国产AI算力生态来说，是很有参考价值的尝试。它证明算力和大模型不是单向的供给关系，可以双向对齐、一起打磨。当然最终成果好不好，还是要看后续芯片回片实测、大规模集群落地的真实数据。
你觉得软硬件co-design这条路，能不能加快国产算力生态成熟？你在使用昇腾算力部署模型的时候，遇到过哪些算子或者集群相关的难题？欢迎在评论区一起交流。
免责声明：本文内容基于昇腾社区、企业公开技术文档与行业公开信息整理，co-design项目处于前期联合定义阶段，芯片参数、落地时间表尚未正式定型，本文不构成算力采购、项目投入相关建议，项目进展请以官方后续发布为准。