把 8 类视觉能力拉到昇腾 310 上做一次验证矩阵

六月的时候，我已经给 WAVE 写过一条昇腾部署验证链：PyTorch 导出 ONNX，先在常规 GPU 环境里做中间对照，再用 ATC 转成 OM，最后到昇腾设备上推理。那时更像是在回答一个问题：这条链到底通不通？

7 月 9 日做的事情不一样。我开始追问第二个问题：如果 WAVE 想成为一个不只会做 YOLO 检测的平台，这条链能不能覆盖不同类型的视觉任务？

所以这次没有继续只盯着一个模型，而是把验证范围扩成了一个 8 项矩阵：

这 8 个名字放在一起看起来很整齐，但真正做完之后，我反而更确定了一件事：“验证过”不是一个二值状态。 不同模型的证据强度并不一样，文章里必须把边界写出来。

为什么要从四类任务一起看

WAVE 的目标不是做一个“YOLO 启动器”。平台里的数据标注、训练、测试、部署和 Workflow 最终要面对检测、分类、分割、跟踪等不同任务。

如果只验证 YOLO，那么部署页面再完整，也只能说明目标检测这一条路径有希望。分类模型的输出结构不同，分割要处理 mask，跟踪还引入跨帧状态；这些差异会直接影响模型转换、推理结果解析、可视化和后面的 Workflow 节点。

因此我给这轮验证设了一个很朴素的目标：每种任务至少拿两个代表项，确认“模型或算法如何进入设备侧链路、输出长什么样、结果怎么可视化”，而不是先追求一个漂亮的统一接口。

YOLOv5n、YOLO26n、AlexNet 和 ResNet50 此前已经有板端验证记录。两个 YOLO 模型保留了检测结果图，两个分类模型则有实际推理性能记录。为了让总表不是“有的模型有图、有的只有一句成功”，我又给分类结果补了统一的结果卡片。

7 月 9 日真正新增的是跟踪和分割四项。

SiamFC++ 走了一条最小可验证路径：把代表性的 score map 计算做成稳定的 ONNX 探针，完成 ATC 到 OM，再在设备侧得到推理输出和峰值可视化。它证明的是这类输出形态和转换路径可以工作，不等于我已经把完整 SiamFC++ 工程无损迁到了板子上。

UNET 也是类似思路。最小 mask 探针完成了 ONNX → OM → 板端推理，用来验证分割输出张量和 mask 可视化链路。

UNET++ 则复用了设备环境中已有的示例 OM 模型，直接验证实际 OM 推理和 mask 输出。这比只看转换日志更接近真实设备执行，但同样不能被写成“所有 UNET++ 变体都已经兼容”。

ByteTrack 最有意思，因为它提醒我不要为了“八个模型都转 OM”而强行统一口径。ByteTrack 本质上承担的是检测结果之间的关联和轨迹维护，是后处理算法，并不需要单独变成一个 OM。最后验证的是多帧目标关联、轨迹 ID 和轨迹线可视化，而不是伪造一个“ByteTrack.om”。

最开始为了快速构造探针，我尝试过手工 ONNX 里的卷积结构，ATC 转换并不稳定。继续硬顶某个手写 Conv，只会让这轮测试变成“和一个临时测试模型较劲”。

后来我把跟踪和分割探针改成更稳定的逐元素算子组合，把验证目标收紧到真正需要确认的部分：输入输出形状、设备侧执行、结果解释和可视化。

这听起来像是降低了难度，但我更愿意把它叫做缩小论断范围。测试越小，结论越应该准确。一个最小探针通过，只能支持“这条最小链路可行”；完整模型是否能部署，还要继续面对真实算子、预后处理、动态尺寸和精度一致性。

这轮最后整理文档时，我没有只放“成功 / 失败”。每一项都尽量留下：

因为对平台工程来说，最危险的不是失败，而是一个含义不清的“已支持”。如果半年后另一个同学看到一个绿色对勾，却不知道当时跑的是完整模型、示例模型还是最小探针，这个验证记录几乎等于没有留下。

八项验证没有让我得出“WAVE 已经支持所有视觉模型”这种结论。恰恰相反，它让我第一次比较具体地看到四类任务之间的差异。

检测和分类的设备侧链路已经比较直观；分割开始要求平台认真处理 mask；跟踪则说明有些能力根本不应该被塞进“模型文件”这个抽象里，而应该作为带状态的算法或 Workflow 组件存在。

这比再多跑一个 YOLO 版本更有价值。WAVE 后面真正要补的，不只是更多模型名称，而是让平台的数据格式、训练 runner、推理输出和 Workflow 能理解这些任务之间的结构差异。

这轮验证最想留下的一句话是：先证明能力边界，再把它包装成平台功能。 这样慢一点，但至少不会让页面跑在工程事实前面。