DeepSeek V4首发适配背后：昇腾为什么坚持不做CUDA兼容层？

AI行业的节奏正在变得越来越快。

从去年的大模型，到今年Agent的集中爆发，技术热点在持续切换。但在表层变化之下，有一个趋势几乎没有发生改变：模型规模与使用强度的提升，正在持续推高对算力的需求。

当模型规模、调用频率与应用复杂度同时增长，单纯依赖算力堆叠已经难以为继。

在这种局面下，开发者天然希望找到一套已经经过验证、能覆盖全链路的成熟体系。这正是CUDA生态在过去十几年建立起来的护城河：它不仅提供了算力，更定义了从编程到部署的一整套标准。

也正是在这样的背景下，一个更现实的问题开始浮出水面：当CUDA生态已经形成稳定闭环，后来者的路径到底是什么？是尽可能兼容，以降低迁移成本；还是从底层出发，建立一套不依附既有体系的新结构？

华为张良给出了他的答案，他在分享会上反复强调：如果底层结构不改变，上层生态就很难真正建立。

这意味着，当前这场竞争，已经不只是算力性能的比较，而是一次围绕“体系”的重构。

为什么“继续优化”已经不够了？

在AI基础设施发展的早期阶段，“能不能跑起来”曾经是最核心的判断标准。

但随着大模型进入工程化与规模化阶段，这一标准迅速变得不再充分。系统的瓶颈，开始从“单点能力不足”，转向“整体链路是否匹配真实负载”。

张良在回顾昇腾早期发展时，并没有回避这一点。他提到，“2018年CANN刚发布时，我们知道CANN和硬件都是不完美的”。

那一阶段属于典型的“可运行但未成熟”状态，行业的关注点更多集中在框架对比、性能指标等表层问题，而真正决定长期能力的底层结构，并没有被充分展开。

面对大模型时代的新负载——长序列带来的访存压力、低精度训练成为主流，以及MoE等复杂模型架构的涌现，昇腾急需解决编程模型不够灵活、访存粒度无法适配、低精度支持缺失等问题。

这些问题无法通过软件优化或算子补丁彻底解决，只能在芯片和系统底层重新设计。

转折发生在近两年。

按照张良的说法，从2025年开始，昇腾团队“痛下决心”，不再围绕局部问题进行修补，而是回到一个更根本的判断：如果底层结构不改变，上层生态就不可能真正建立。

在最新一代昇腾950芯片中，这种调整体现在多个方面：编程模型更接近主流并行计算范式，降低开发迁移成本；数据访问引入更细粒度访存机制，以减少大模型场景下的无效带宽消耗；同时提前支持FP8等低精度计算，以提升吞吐并支撑更大模型规模。

张良提到：“有客户在测试不到一周后，就直接做出了下单决策。”

与此同时，昇腾在架构路径上也做出了一个关键选择。在专用加速芯片逐渐兴起的背景下，针对特定场景进行深度优化，往往可以获得更高的短期效率。

但张良明确表示，团队并没有沿着这一路径继续推进，而是坚持通用架构方向。原因在于，如果系统能力被限定在特定场景中，就很难形成外溢，也无法支撑多样化应用的持续增长。

这一选择意味着，昇腾并不只是试图把模型“跑得更快”，而是在解决一个更长期的问题：当模型不断变化、负载持续增长、开发范式不断演进时，这套系统是否仍然能够承载这些变化。

为什么不能“做一个CUDA兼容层”？

如果说底层结构决定了一套系统“能做到什么”，那么生态则决定了“有没有人愿意在上面继续做”。

在当前AI基础设施格局中，CUDA已经不仅是一套技术方案，而是一整套高度稳定的开发体系。从编程模型、工具链到社区与人才结构，它所形成的，不只是功能层面的能力，更是一种“默认可用”的环境。

对于后来者而言，最直接的路径，是尽可能向这一体系靠拢——通过接口兼容与生态复用，降低开发者的迁移门槛。

这是一条现实且常见的路径，但昇腾并没有选择沿着它走下去。

张良给出的判断非常直接：“如果基于CUDA来做，那我们做的一切生态发展，都无法彻底自主。”

这句话所指向的，并不只是技术路线之争，而是一个更底层的问题：如果核心体系建立在他人的标准之上，那么无论投入多少工程资源，最终强化的仍然是原有系统，而不是自身能力。

进一步看，这种依附关系还意味着技术演进主动权的缺失。张良提到，“一旦出现危机的时刻，这一套体系做不到，你的特性在里面就没了。”

这里的“特性”，不仅是具体功能，也包括体系能够持续演进的空间。如果关键能力受限于既有框架，那么新的特性就很难真正落地，更难形成长期积累。

在这一判断之下，昇腾选择了一条更复杂但更具独立性的路径：在底层体系上坚持自研，在上层生态上尽可能对齐主流。

这意味着，在虚拟指令集、编译器以及运行时等关键环节，昇腾不依赖既有标准，而是构建自己的实现；而在开发接口与使用方式上，则主动适配主流框架，使开发者可以在熟悉的环境中使用这套系统。

这种“分层处理”的方式，本质上是在控制权与使用门槛之间寻找平衡：既不完全依附，也不让开发者从零开始。

但这条路径的难度，很快体现在实际推进过程中。

在主流开源框架中，新硬件往往只能以插件形式接入，难以进入主干体系。

张良提到，昇腾最初面对的正是这样的情况——对方并不直接接纳，而是建议“你们可以自己做插件”。这意味着，生态上的“可用”与“被认可”之间，仍然存在明显距离。

昇腾的做法，是持续参与开源社区：提交代码、对齐规范，并通过工程实践验证自身实现的稳定性。在这个过程中，关系逐渐发生变化，从最初的外部适配，转向更深层的协同。

例如在Triton中实现后端支持，在PyTorch Foundation体系中建立起持续集成流程，使平台能够跟随主版本演进保持同步。这些变化的意义，在于昇腾不再只是“接入生态”，而是开始参与生态本身的构建。

与此同时，生态建设也被进一步转化为可量化的工程问题。

张良提到，昇腾对开源软件的支持能力、以及开源软件对昇腾特性的支持程度，被细化为特性支持率、模型适配率、CI覆盖率等一系列指标，“要求必须维持在95%以上”。

在模型侧，昇腾也在推进类似的覆盖能力。

昇腾已在DeepSeek V4发布当天实现全系列适配，950超节点推理时延低至10~20ms，并通过PyPTO编程范式将算子开发周期缩短至天级。

不过，这一路径并非没有不确定性。

在一个已经高度收敛的生态体系中，新的平台不仅要补齐能力，还需要在时间上追赶。这不仅是技术问题，更是节奏问题：当主流框架持续快速迭代时，新体系是否能够长期保持同步，并逐步建立自身影响力，仍然取决于持续的工程投入与社区协同。

也正是在这一意义上，“做一个CUDA兼容层”之所以没有被选择，是因为它无法回答一个更关键的问题——当生态演进发生变化时，这套体系是否仍然拥有自己的位置与空间。

Agent是新范式，还是“生态未成熟的补丁”？

在传统AI工程体系中，开发过程高度依赖人工经验。

从算子实现到性能调优，每个环节都需要工程师深入理解硬件、反复调试。这种模式在早期复杂度较低时尚可应对，但随着模型规模扩大、系统链路拉长，人的处理能力开始成为效率瓶颈。

昇腾的应对方式，不是继续在工具层面做优化，而是引入新的执行主体——Agent。

最直接的变化出现在算子开发环节：过去手写算子需要深入硬件、反复调试，现在开发者只需描述设计意图，Agent就可以自动完成环境配置并生成代码。开发起点从“如何实现”转向“要实现什么”。

围绕这一思路，昇腾将Agent扩展到更完整的流程——从模型检索、适配、量化，到迁移、优化与部署，原本分散的步骤被整合为一条连续路径。

张良给出的目标是：“一分钟找到模型，一小时验证，一天完成部署。”压缩的不只是时间，更是试错成本与迭代周期。

支撑这一体系的，是“Skill”——一种标准化的能力单元，它将专家经验、调优方法以及工程流程以模块化方式沉淀下来，供Agent直接调用组合。

这意味着，原本依附于个体经验的能力，开始被转化为系统的一部分。开发者不再需要从零构建流程，而是通过定义目标与约束，让系统完成大部分执行工作。

在标准化程度较高、路径清晰的任务中，Agent可以显著提升效率。但张良坦言，在“最深层次的复杂问题”上，当前Agent的能力“还不是那么强”，仍然离不开工程师的深度参与。

这使得Agent呈现出一种过渡性特征：一方面，它确实在改变开发节奏，使原本以天甚至周为单位的流程被压缩到小时级；另一方面，它也在承担一层“缓冲”的角色——在生态尚未完全成熟、底层差异仍然存在的情况下，通过自动化能力降低使用门槛。

这也引出一个更深远的问题：Agent所带来的，是一种长期稳定的新范式，还是在体系尚未完善时的过渡机制？答案或许取决于Skill的沉淀速度和底层差异的收敛程度。但无论如何，它在当下已经实实在在地改变了开发节奏。

回到最初的问题：当CUDA已经成为事实标准，后来者是否还有空间？

从昇腾这一路径来看，它给出的答案，并不是正面替代，也不是简单兼容，而是试图在既有体系之外，构建一套可以独立运转的结构，让这套系统在不依赖既有生态的情况下，仍然具备自洽能力。

当然，这一选择仍然处在进行时之中。生态能否持续积累、与主流框架的协同能否长期稳定、开发方式的变化能否真正沉淀为工程能力，这些都需要时间来验证。

雷峰网雷峰网