是的，这两条消息反映的其实是同一套技术底座在两类国产硬件上的落地，这个方向挺值得关注的。我帮你梳理一下脉络和意义：
背景：DeepLink 的定位
上海人工智能实验室的 DeepLink（OpenDILab 体系下）一开始的目标就是解决"算力碎片化"问题------不同加速卡（NVIDIA CUDA、海光 DCU、昇腾 CANN、寒武纪、天数智芯等）的算子接口、编译工具链互不兼容，导致框架和上层应用每换一个硬件就要重新适配一遍。DeepLink 做的就是跨硬件的抽象层和兼容层。
而 KernelSwift 是在这个基础上往前走了一步：不再靠人工写兼容层，而是用大模型 + Agent 技术来自动生成和迁移算子（kernel）。
两条合作其实是同一系统的两个落地
| 合作方 | 硬件平台 | 落点 |
|---|---|---|
| 海光信息 | DCU（类 ROCm/HIP 生态） | KernelSwift 全栈系统：大模型赋能智能算子生成 |
| 昇腾 + 毕昇编译器团队 | 昇腾 CANN 生态 | 基于 Agent 的智能算子迁移系统，面向多硬件平台 |
| 技术路径大致是这样的： |
- 代码理解：Agent 解析现有算子（比如 CUDA 写的 kernel）的语义、数据流和计算模式
- 目标平台生成：LLM 生成对应目标硬件的 kernel 代码（HIP / Ascend C 等）
- 编译 + 运行验证：调用目标平台的编译器（毕昇编译器、海光工具链）做编译，跑单元测试和数值对齐
- 性能 Profiling 反馈闭环：拿 profiling 数据反馈给 Agent，迭代优化性能（tiling 策略、内存访问模式、并行划分等），形成"生成→验证→修复→优化"的循环
为什么这个方向有价值
- 算子适配是国产算力最大的痛点之一。PyTorch 生态里数千个算子，靠人工一个个移植到新硬件，成本极高、周期极长。LLM 自动生成 + 自动验证，理论上能把移植成本压下一个数量级。
- 两家厂商同时接入，说明系统有一定的硬件无关性------这也正是 DeepLink 一贯的卖点。昇腾（编译器自研、CANN 生态相对封闭）和海光（类 CUDA/ROCm 路线）的技术栈差异很大，同一个系统能同时服务两边，说明抽象层设计是过关的。
- 与毕昇编译器的联动是关键。算子生成不是"能跑就行"，性能高度依赖编译器的调度和优化。KernelSwift 把编译器反馈纳入 Agent 循环，是比纯 LLM 代码生成务实得多的做法。
可以关注的几个问题
- 性能能到人工调优的几成：LLM 生成的 kernel 在数值正确性上通常好验证（对齐测试），但性能往往在 CUDA/手写 kernel 的 70%~95% 区间浮动，长尾算子尤其难
- 覆盖范围：首发一般覆盖高频算子（GEMM、Attention、LayerNorm 等），长尾算子和动态 shape 场景是真正的考验
- 生态策略 ：这个系统本质上是把"跨硬件迁移"的成本中心变成了可以标准化的工具，如果跑通，对中小芯片厂商（寒武纪、燧原、摩尔线程等）的吸引力会很大
如果你在做国产算力选型或者移植评估，这类工具的成熟度其实是一个值得纳入考量的"软指标"------它直接决定了你迁移到该硬件平台的工程成本。你目前是在做相关平台的适配工作，还是在做选型调研？