大家好，这里是最佳拍档，我是大飞。9月30日，国庆假期的前一天，DeepSeek一次性更新了六个代码仓库：TileLang、DeepGEMM、DeepEP、TileKernels、FlashMLA、DeepSelect，全都加上了对华为昇腾的支持。单看这个动作，像是一次普通的开源提交；但是放到中美算力的背景里，它更像一个信号。SemiAnalysis在10月21日发了一篇长文，标题是《华为与DeepSeek的共生关系》，判断很直接：就是这件事。显然任何一方都没法独自完成，简单来说，华为虽然有盘古，但是没有一家真正意义上的前沿实验室来证明自己的芯片能训练模型、能跑推理；DeepSeek有模型，却买不到它需要的算力。一个缺证明，一个缺卡：华为出硬件和原生软件栈，DeepSeek出工作负载，还有让这些硬件真正服务自己模型的那部分工程。9月30日的那批仓库就是这场交换的产物，而交换的接口落在内核的编写语言上。

文章还给了一个时间判断：到2028年，甚至更早的2027年，DeepSeek很可能主要跑在华为的软硬件栈上。技术原因是现成的；另一层原因是内外部的压力，要求建一套完全国产化的生态。今天我们就来聊聊这件事。先看芯片：文章从一个容易被忽略的细节切入，昇腾950PR和950DT已经出现了很多变体，包括核心数量、HBM堆叠高度、缓存大小都不一样。有些变体可能只是虚拟化或模拟出来的，或者纯粹拿来测试的。为什么档位这么多？因为受裸片缺陷以及功耗、性能参数不达标的影响，只有一部分裸片和HBM堆叠能满足目标规格。所以华为的做法是计算和内存同时分档，拆成多个SKU，把弱一点的内存配给弱一点的算力。英伟达的分档逻辑则不同：它主要只对计算部分分档。这其实不是什么新的做法，910B时代就有910B1、910B2、910B3、910B4这些变体。

这次微基准测试用的是一颗950PR_9579，28个Cube核心、128GB的HBM。接下来是一组很有意思的测试，第一个是指针追逐（pointer chasing）。每次启动读取16KB的整数载荷：18个线程块以内，耗时稳定在134纳秒左右；加到56个块，升到182纳秒；到64个块，直接跳到391纳秒。这个跳跃说明超过56个Vector核心之后，任务进入了第二波执行。再往下，他们在每一个Cube和Vector核心上分别跑标量指针追逐探针，记录遍历一条128MB链时、相同地址上的加载耗时。每个格子的颜色代表两个核心在这个地址上的耗时分布差异，结果自动聚成了两组，正好对应两颗裸片。

接着他们让一个核心跑内存流量或者纯寄存器任务，同时测另一个Vector核心的指针追逐被拖慢多少。拖慢的幅度能反推出哪些子系统共享资源，于是得到了0、2、4和1、3、5这样的分组。混合启动Cube和Vector还能识别出每个子系统里的一个Cube加两个Vector。当然，图上的物理位置只是示意图。这种测试方法说白了就是在没有厂商架构图的情况下，用计时把芯片内部结构测出来。

芯片里还藏着一个CPU：每颗950PR都带数量不等的Linx816 AArch64 ELF AICPU。从MIDR编号看，这些核心很可能和麒麟9000S、9010里的中核是同一款。指令集里能看到SVE、bf16、i8mm这些特性。在这颗SKU上，配置了7个AICPU，能看到的是6个，实际在跑的是5个。它的用途不只是设备控制，还能承担一部分CPU算子，比如处理KV元数据。对于那些设备到主机传输开销占大头、计算本身很短的活儿，AICPU就派上用场了。具体到DSA也就是DeepSeek那套稀疏注意力的调度，会有一个小的调度步骤读当前序列长度，把索引器的工作分给加速器核心。然后Cube和Vector核心会计算INT8的索引器分数，选出前2048个索引。在vLLM-ascend的实现里，规划、索引选择、汇集这三步都跑在AICPU上。文章也把它和放在主机CPU上跑做了对比，结论是：AICPU计算能力有限，只适合开销占主导的短任务，以及数据从NPU来、也在NPU上消费的任务。

接下来是性能：950PR的定位是预填充和推荐，和更强的兄弟950DT相比，它的内存带宽更低、核心也更少。测试用的是昇腾上原生的torch.matmul，最后落到aclnnMatmul那个实现——不是DeepSeek优化过的内核。他们挑了来自几个开源模型的1055种BF16 GEMM形状，结果华为最好的内核达到了性能上限的99.7%。这个数字值得说一下：DeepSeek用DeepGEMM做到99%以上利用率，一直被当成标杆；现在看，那不是唯一的路。华为自己的工程师也把这件事做成了：优势集中在计算受限的任务上。在昇腾Roofline拐点以下那些形状，实际达到的性能占可达到性能的比例中位数是41.5%，H100是46.8%。

不过有个细节：英伟达的部分结果受了功耗限制，没跑到最高的SM时钟700W的上限。下限下功耗中位数在690到698W，采样到的SM时钟中位数是1335到1470MHz，而最高是1830MHz。华为这边功耗大约599到600W，频率1500到1550MHz（参考频率是1650MHz）。所以这个对比并不是完全同条件下的。昇腾的MXU设计可能是它利用率高的原因之一：它把矩阵操作数放在专用的L0A、L0B缓冲里，累加器放在L0C。让数据搬运、计算和结果处理互相重叠；华为把扩大的L0C和更灵活的分块、复用联系在一起。但是在绝对性能上，950PR还是落后，大致落在英伟达的A100和AMD的MI300X之间。

内存带宽这块，结果更有意思：每个缓冲区的消息比较小时，950PR的有效带宽和带宽利用率都超过了H100；消息大了以后，带宽利用率几乎和H100持平。曲线上有一个下凹，原因是昇腾在这里切换了复制方式：改用一个启动开销更大的Vector核心TensorMove内核。所以复制量稍微变大，耗时反而变长；等到复制量非常大，这点额外开销占比变小，带宽又升回去。文章在这里特意提醒：高FLOPs利用率和高带宽利用率不一定能转化成高MFU或MBU。训练尤其用FSDP的时候，还要做集合通信、存检查点和搬数据，这些工作都很难完美重叠。他们还重申了之前文章里的观点：基准测试里的一颗“芯片”，其实是个社会建构出来的概念。多颗裸片可以拼成一颗更大的芯片，真正该比的是每瓦性能或者按总拥有成本（TCO）来计算的性能。不过对于中国来说，电便宜得多，这个变量的权重不一样；昇腾单位TCO的性能他们打算放到后面的文章里再算。

文章里有一句话，我觉得是全文的题眼：“硬件抬高了上限，但软件才能让你摸到那个上限。”华为的硬件可能落后5年以上（这是跟A100比），但是它的软件处在前沿。再看软件侧：DeepSeek更新的六个拿到昇腾支持的仓库，到文章编写时只有TileLang真正能用。原因很实际：CANN 9.2.0还没发布，DeepSeek需要这个版本；还需要一个C++20编译器。CANN 9.2.0-beta.2不提供这个，HDK要到10月15日才放出来。这几个仓库里有些在2025年DeepSeek开源周发布时只支持英伟达。从测试结果看，华为本来就能把基础算子跑好：所谓共生，重点不在算子本身而在于让应用的其余部分、以及支撑这些部分的工作变得更高效、更容易复用。这种工程影响是双向的：华为的架构已经在改变DeepSeek组织数据的方式。

早期FlashMLA的KV缓存布局把量化值和它的缩放因子放在不同区域，在英伟达上这么放没问题；但是在昇腾上取一个Token就得分别传输数值和缩放因子，等于多了一次请求。新的实现把两者放在一起内存传输引擎发起的请求数就少了：芯片的存储结构反过来塑造了软件的缓存格式。再往下是TileLang：昇腾950后端不是单独挂在华为的适配器里，而是合进了TileLang的主仓库。它给昇腾的执行模型加了原生编译、调度、同步和运行时集成，相当于以前写昇腾内核你得自己啃CANN那一套；现在TileLang把门槛降下来了。但是开发者还是得考虑硬件，比如选什么计算、分块多大、数据放哪儿这些都要人来定。编译器负责的是Cube核心、Vector核心和数据传输之间的大量协调工作：文章把它跟CANN和Triton-ascend做了对比，某些情况下能追平甚至超过CANN最佳实现会随规模变化。

不过要注意：这是个缓存已预热、实现很朴素的基准，不要过度解读。TileLang里有个叫AutoSchedule的东西：它靠数据依赖关系和预估执行时间规划哪些操作可以重叠，同时在片上内存的范围内决定用几个缓冲槽。让当前分块还在算的时候后面的数据就能开始加载；如果默认调度不合适，开发者可以手动干预。在950PR上AutoSchedule对小规模特别有用：单个算子的执行时间最多能减少40%。编译器还会做同步，它会插入必要的等待让算子等到需要的数据，同时把那些因为其他依赖关系而变得多余的等待删掉。它还会检查条件分支：不会因为代码里写了某个操作就假定它一定执行完了，因为那个分支可能根本没进去。这部分工作以前是程序员自己管的现在交给编译器。

通信这块，华为已经和英伟达一样把大规模纵向扩展的AI系统推向了商业化。昇腾超节点把紧耦合的加速器互连扩展到多个机架，从910的CloudMatrix384一直到950的SuperPod支撑wideEP那种横向扩展。在9月30日那次发布里，华为还公布了950DT超节点上通过URMA做EP16分发与合并的基准。这里有个对比很能说明工程成熟度：华为的分发是三个顺序执行的算子pre、URMA、post；GB300是一次融合调用。而华为的post阶段包含了接收完成（这个被算进了测量），它还包含按专家展开的工作；GB300的结果里没有这一块，所以这两个数字不能直接对着看。DeepEP-Ascend是DeepEP V2.5的移植版，Python API一样但是底层换成URMA和HCCL。这里有个小插曲：2025年7月华为昇腾团队曾经提议把DeepEP-Ascend放到deepseek-ai这个组织下面，后来被一位DeepEP维护者拒绝了。现在这个项目是在DeepSeek自己的组织下分发。

昇腾把Cube和Vector的执行路径分开，这给通信和计算的重叠创造了机会。但重叠不是免费的：专家计算本身也可能要用向量单元、要搬数据，而通信会抢共享的内存带宽。所以能藏多少通信开销又不拖慢并行计算是个权衡：这个资源平衡问题不只DeepSeek一家遇到。华为的Kimi K3配方里明确限制了向量单元的使用，给并发工作留出余量。所以通信到底走专用CCU还是走Vector取决于要重叠的是什么，只不过单个算子更快还不够它们的资源需求得能互相配合。DeepEP-Ascend的文档里也写了合并处理和URMA通信之间存在HBM资源争用，华为计划通过固件改进来缓解。这就是协同设计落到实处的样子：模型暴露出瓶颈，实现跟着调整；平台的开发优先级再去响应那些还没解决的问题。

文章引了一段5月份的DeepSeek投资者会议逐字稿，并且强调这份逐字稿未经核实。梁文锋在里面说：中美芯片的差距、软件生态的差距最终会消失，但硬件上有两个独立的劣势。一是需要4张华为加速卡才能匹敌1张英伟达卡；二是华为把硬件推向市场的时间大约落后2年4个月。4个月后，生态差距确实缩小了：同一份逐字稿里还提到了TileLang提到帮华为把生态做起来。然后是DeepSeek-V4.1 Flash：共生关系的另一半是DeepSeek把权重交给华为，让华为能在发布当天就拿出优化好的版本。V4和V4.1都是这么来的：由于昇腾的累加器设计逼着注意力计算换了一种写法。Cube的L0C缓冲没法对累加输出就地重新缩放，而把缩放后的结果再送回L0C需要做一次单位矩阵乘法代价很高。

DeepSeek的解法是把持续更新的输出累加器放在Vector的UB里，需要重新缩放和累加的时候再从L0C把部分和传出来。作为对照：Hopper把累加器放在寄存器里，Blackwell支持张量内存和寄存器之间的加载与存储所以它们不受这个限制。同一套注意力在三家的芯片上得写三套不一样的实现：华为还放了一份性能剖析，是在32颗昇腾950DT上部署DeepSeek-V4.1-Flash时某一个rank加上它的主机线程。6月份他们分析过V4 Pro的类似剖析，很多组件是相似的：比如用AICPU、把部分层分到不同的流里。执行顺序是这样的：首先40个目标模型层，然后是目标模型的LM头；接着3个DSpark草稿块然后草稿模型的LM头最后5轮采样。主计算跑在Stream 19上，草稿模型跑在Stream 173上。

V4 Pro轨迹里那个把计算和通信融在一起的V2 MC²内核这次以V3的形态又出现了：这也是为什么每一步有43次专家分发但由AI CPU发起的HCCL操作只有4次。这4次是目标模型和草稿模型词表头的hcom_allGather和hcom_alltoallv，先把隐藏状态汇集起来跑LM头的GEMM然后交换logits。草稿块只需要跑一次，目的就是为草稿位置产出基础logits；后面的Markov头通过采样和嵌入反馈对Token之间的依赖建模，它不会为每一个提案重新跑一遍Transformer块。每一步的末尾工作形态会变：从MoE和注意力变成一串串行的小投影和采样。而推测解码（speculative decoding）SemiAnalysis在之前的文章里解释过它是无损的：先预测草稿Token再用一次前向过程验证，权重加载的成本就被摊薄了。从解码步骤的图上能直接看出来DSpark生成草稿Token比验证那一步快多少。

V4.1 Flash还有一个身份：它是DeepSeek第一个用Engram的模型，不过在时间上晚于阿里千问和美团LongCat。由于Engram的输入是Token ID所以取数据可以异步做，和第0层的计算重叠起来。这意味着卸载到DRAM相比放在HBM里可以不掉性能；但是卸载到PCIe 4.0的SSD就会掉。再看稳态窗口里的内核时长：Stream 19占了这个窗口的88.8%，但是在设备时间加总里只占72.6%因为其他流和它重叠了。图中间那些大块的MIX_AIV和AI_VECTOR_CORE区段里面既有分发合并也有量化。昇腾通过MIX_AIC、MIX_AIV、AI_CORE、AI_VECTOR_CORE把Cube和Vector路径分别暴露出来，每个事件带任务类型所以这个时长核算是按类划分的。这里有个坑要说明：混合类型的事件实际工作发生在单一物理单元之外，所以虽然名字是混合的但是你不能把这段耗时当成纯Cube或纯Vector的利用率。

文章还做了一个一阶测算：假设Cube吞吐翻倍其他设备工作不动每步性能能到1.32倍。这个测算保持了实测的流重叠程度也保持了空闲时间不变：它是个基于工作构成的情景推演不是对新芯片的预测。毕竟带宽、依赖关系、调度都会改变结果：量化融合也还是个机会，吸引力在于生产者和消费者之间反复出现的边界以及量化在向量任务里占的比例不小。而这个类别同时还要承载融合通信：最后是生态缺口，这部分我觉得最值得国内从业者留意。文章说得很直白这种合作可能对

DeepSeek 极其有效，但是未必能让所有人都能一样方便地用上昇腾。对 DeepSeek 来说，自己写编译器、维护内核、调试厂商特有的行为，是要和模型研究、产品开发抢资源的。虽然文章判断这可能是暂时的，对其他人来说，麻烦在于硬件配置一旦和 DeepSeek 不一致就会出问题。

大部分优化都是围绕超节点做的，截至 vLLM-Ascend 0.26.0rc1，在 x86 主机上用昇腾还有一堆的毛病。比如 x86 主机不支持 DeepGEMM，vLLM-Ascend 依赖的 memfabric_hybrid 里硬编码了 ARM 头文件，启动会直接卡住，做不到开箱即用。以及非 ARM 的 CPU 会被跳过 CPU 绑定，也没有 NPU 加 x86 的持续集成（CI），部分配方得自己打补丁。

所以你看，昇腾加 DeepSeek 这套组合在自家超节点上是很顺的，但是出了这个配置，工程债就露出来了。文章收尾的判断是：华为已经给一批基础算子做了高效实现，DeepSeek 带来的是针对特定模型的工作负载和工程，让平台能力延伸到这些算子之外。

与此同时，华为的架构和原生软件栈又在塑造这些实现该怎么建。这批编译器和内核工作的价值，不只体现在今天的性能上，更体现在它能给下一个模型、下一次部署省下多少工程。

再往大一点看，真正的机会是给中国 AI 产业形成一种工程能力的倍增效应。其他跑 DeepSeek 服务的运营方可以直接复用这些内核和部署实践；其他的研究机构可以在共享的编译器能力上搭新模型。

如果这些使用者把修复和优化回流到社区，收益就是复利式的：相当于每个团队起步的时候，已经有人替你把难的部分做完了。文章最后提到了 Dwarkesh 博客里黄仁勋谈芯片出口限制的那段担忧，从目前这批软件成果加上对 950PR 的实测来看，在华为的基础上再叠上 DeepSeek 的工程，生态差距确实在缩小。

文章的原话是，“黄仁勋的噩梦正开始成为现实”。我倒不想把话说得那么戏剧化，只是更值得盯的是另一个问题：如果这套协同只在 DeepSeek 和华为之间跑得通，那它到底是国产算力生态的地基，还是一条定制化的专线呢？

既然代码是开源的，答案就取决于后面有多少团队真的把它用起来，并且把改动还回去。感谢收看，我们下期再见。