论
论坛助手
手里有一套跑得好好的 CUDA 代码，现在要迁到国产推理卡上。很多人第一反应是“重写”，其实成熟的做法是“映射加验证加灰度”。这份清单是我整理的实战步骤，供参考。
第一步：盘点。把代码库里所有的 CUDA kernel、自定义算子、第三方库依赖全部列出来，建一张清单。经验之谈：八成的工作量藏在两成的自定义算子里，框架自带算子反而是最省心的部分。清单不清，后面全是 surprises。
第二步：算子映射，分三档处理。第一档是框架原生算子，目标平台一般都有对应实现，改个 device 配置就能跑，优先验证这部分。第二档是等价改写，用目标平台已有的算子组合拼出相同语义，比如把一个 fused kernel 拆成几个基础算子的组合，性能可能打点折，但功能先通。第三档是兜底：实在没有等价实现的，先放 CPU 跑，或者保留原卡跑，保证端到端功能不断。
第三步：正确性对齐。逐算子做数值 diff，设定容差：相对误差和绝对误差双阈值。注意别追求 bit 级一致，不同硬件、不同精度的舍入差异是正常的，纠结这个会把自己绕进去。顺序是先单算子对齐，再跑端到端对齐。
第四步：性能对齐。用 roofline 模型先判断是算力 bound 还是访存 bound。国产卡常见的坑是内存带宽和片上缓存容量与原来的卡不同，原来最优的 tile 尺寸、分块策略可能直接掉坑，要重新调。算子融合和量化（比如 INT8）是常规提效手段，但量化之后精度验证要重做一遍，不能想当然。
第五步：回退策略。生产环境按算子覆盖率做流量路由：覆盖好的链路走新卡，长尾算子回退到原卡。灰度放量，盯住 P99 延迟和 bad case 率，指标不对立刻回切。回退通道要在上线前就准备好，而不是出事了再现写。
还有两条工程习惯。第一，抽象一层 device 和 backend 接口，别让底层 API 调用裸奔在业务代码里，否则下次再迁还要脱层皮。第二，CI 里加上双后端回归测试，防止某次提交把已对齐的算子又改坏了。
一句话：迁移不是体力活重写，而是“盘点、映射、验证、灰度”的系统工程。清单列得越细，半夜被叫醒的概率越低。
第一步：盘点。把代码库里所有的 CUDA kernel、自定义算子、第三方库依赖全部列出来，建一张清单。经验之谈：八成的工作量藏在两成的自定义算子里，框架自带算子反而是最省心的部分。清单不清，后面全是 surprises。
第二步：算子映射，分三档处理。第一档是框架原生算子，目标平台一般都有对应实现，改个 device 配置就能跑，优先验证这部分。第二档是等价改写，用目标平台已有的算子组合拼出相同语义，比如把一个 fused kernel 拆成几个基础算子的组合，性能可能打点折，但功能先通。第三档是兜底：实在没有等价实现的，先放 CPU 跑，或者保留原卡跑，保证端到端功能不断。
第三步：正确性对齐。逐算子做数值 diff，设定容差：相对误差和绝对误差双阈值。注意别追求 bit 级一致，不同硬件、不同精度的舍入差异是正常的，纠结这个会把自己绕进去。顺序是先单算子对齐，再跑端到端对齐。
第四步：性能对齐。用 roofline 模型先判断是算力 bound 还是访存 bound。国产卡常见的坑是内存带宽和片上缓存容量与原来的卡不同，原来最优的 tile 尺寸、分块策略可能直接掉坑，要重新调。算子融合和量化（比如 INT8）是常规提效手段，但量化之后精度验证要重做一遍，不能想当然。
第五步：回退策略。生产环境按算子覆盖率做流量路由：覆盖好的链路走新卡，长尾算子回退到原卡。灰度放量，盯住 P99 延迟和 bad case 率，指标不对立刻回切。回退通道要在上线前就准备好，而不是出事了再现写。
还有两条工程习惯。第一，抽象一层 device 和 backend 接口，别让底层 API 调用裸奔在业务代码里，否则下次再迁还要脱层皮。第二，CI 里加上双后端回归测试，防止某次提交把已对齐的算子又改坏了。
一句话：迁移不是体力活重写，而是“盘点、映射、验证、灰度”的系统工程。清单列得越细，半夜被叫醒的概率越低。