同时交付瑞芯微和海思两个平台，很多团队的第一反应是维护两套代码、两套部署包，再各自配一条测试基线。但这样一来，算法版本稍微迭代几次，双线维护的成本就会迅速超过开发本身。更合理的做法，是把“算法逻辑”和“平台适配”拆开，让一套核心代码在不同芯片上跑出可预期的效果。
部署包层面，建议按“核心推理包 + 平台适配层”来拆分。核心推理包只包含模型、预处理/后处理的通用算子以及业务逻辑，这部分与芯片无关，编译产物可以是ONNX或自研的中间表示。适配层则针对瑞芯微的RKNN工具链和海思的SVP/IVE进行封装，负责将核心包翻译成对应芯片的运行时指令，并处理内存分配、算子映射等底层差异。这样，每次算法更新只需替换核心包，适配层基本不动；如果芯片SDK升级，也只动适配层，不动算法逻辑。
测试基线则要更细。不能简单地把同一套测试集跑两遍，因为两个平台的算子精度和数值表现本身就有差异，硬性对齐反而会让团队陷入无休止的调优。建议拆成三层：第一层是算法效果基线，用标准数据集（比如自有标注的测试集）验证mAP、召回率等指标，这一层只认算法本身的输出，不看平台；第二层是平台一致性基线，重点对比两个平台在相同输入下的输出差异，比如Tensor级别的最大绝对误差或余弦相似度，设定一个允许的容差范围，而不是要求完全一致；第三层是性能基线，分别统计瑞芯微和海思上的单帧耗时、内存占用、首帧延迟，这部分必须分开设阈值，因为芯片的算力和存储架构本就不同。
实际操作中，有个容易被忽略的细节：测试数据要按平台动态切分。某些算子在一个平台上有硬件加速，在另一个平台上可能走软件模拟，导致量化和非量化条件下的表现差异很大。所以基线里应该包含“平台差异化用例”，专门覆盖那些对指令集敏感的场景。同时，CI流程要允许同一个核心包分别拉两个平台的流水线，各自生成测试报告，但由同一个版本号关联。这样交付时，客户拿到的是一个核心版本加上对应的平台适配包，测试报告也清晰标注了各自基线的结论，既避免了“同一份报告套两个平台”的敷衍感，也减少了维护者的重复劳动。说到底，拆分的目的不是为了减少工作量，而是让每个组件的责任边界更清楚，出问题时能快速定位是算法不行，还是适配没做好。