华为与DeepSeek各自补上了什么？

  • 合作的起点是资源互补：华为提供硬件与原生软件栈，DeepSeek提供真实模型负载和工程能力，将芯片能力转化为可运行的应用。
  • 9月30日发布的昇腾支持覆盖TileLang、DeepGEMM等六个代码库；报告将算子编写语言视为双方协作的连接点，价值在于减少重复适配工作。
  • 报告预计，DeepSeek到2028年、甚至2027年很可能主要使用华为技术栈，依据是双方工程协作，以及推动中国自主生态的内外部压力。

950PR的测试说明了哪些能力边界？

  • 基础矩阵计算已能高效运行。测试使用28个Cube核心、128 GiB HBM的950PR_9579；在1,055种BF16矩阵形状中，华为原生最优算子达到理论上限的99.7%。
  • 优势集中于计算密集任务。在算力拐点以下的形状中，昇腾实际性能占可达性能的比例中位数为41.5%，H100为46.8%；950PR绝对性能处于A100与MI300X之间。
  • 单项测试高效，整套训练仍受通信、检查点保存和数据搬运制约。这些操作难以完全重叠，因此算力与带宽利用率之外，还要看应用如何组织执行。

软件协作怎样减少实际开销？

  • 昇腾950后端已进入TileLang主代码库，提供原生编译、调度、同步和运行时支持；开发者确定计算与数据布局，编译器承担更多核心间协调工作。
  • 在950PR的小规模测试中，AutoSchedule可将单项操作耗时最多缩短40%。它安排计算与取数重叠，并按片上内存选择缓冲槽，减少等待。
  • 硬件也在改变模型实现。FlashMLA把量化值和缩放因子放在一起，减少传输请求；DeepSeek还向华为提供权重，支持V4、V4.1首日优化发布。

为什么算力翻倍，整体提升仍有限？

  • 通信会与计算争用资源。DeepEP-Ascend文档指出，组合处理与URMA通信争夺HBM资源，华为计划通过固件改进缓解；重叠执行的收益取决于资源能否配合。
  • 报告的情景测算显示：若Cube吞吐量翻倍，其他设备工作、流重叠程度及空闲时间保持不变，单步性能提升至1.32倍。
  • 这项情景揭示了优化重心：带宽、依赖关系与调度都会影响整体结果。报告还指出量化融合有优化空间，可减少反复出现的操作衔接开销。

专用优化如何变成更广泛的生态能力？

  • 推广障碍在于部署环境差异。多数优化面向超节点；截至vLLM-Ascend_0.26.0rc1，x86主机仍缺少DeepGEMM支持，部分依赖中的ARM头文件还会阻塞启动。
  • DeepSeek也承担工程成本：编译器建设、算子维护和厂商特有问题调试，会分散模型研究与产品开发的精力。
  • 报告看好的长期路径是成果复用：运营商复用算子和部署实践，其他实验室共享编译器能力；若使用者持续回馈修复与优化，后续模型所需的底层工程投入就能减少。