写出一个能运行的 HIP kernel 并不难，难的是把它变成可维护的 PyTorch 扩展：输入检查要完整、目标架构要明确、编译缓存要可控、错误要能定位，还要有正确性和端到端性能门禁。本文以一个通用逐元素算子为例，说明 DCU 自定义算子的工程结构、C++ binding、HIP kernel、在线编译、缓存管理和测试方法。示例只演示基础流程，不对应任何实际项目的优化实现。关键词：DCU、HIP

把一个 PyTorch 项目迁移到 DCU，真正费时间的部分通常不是修改模型，而是确认软件栈是否一致：驱动能否识别设备、PyTorch 是否链接到正确的 HIP 运行时、动态库路径是否混入其他版本、扩展是否为目标架构编译，以及错误究竟发生在 Python、框架还是设备侧。本文以 DTK 环境为例，给出一套可复用的迁移和排障顺序。目标不是列一堆环境变量，而是建立分层诊断方法：先验证硬件，再验证运行时

DCU 性能优化最常见的误区，是拿一个时间或一个显存数字直接下结论。端到端 wall time、设备事件、Profiler 算子时间、PyTorch allocated、PyTorch reserved 和整卡 VRAM 回答的是不同问题。只有把这些口径分开，优化结果才可解释、可复现。本文给出一套适用于 PyTorch/DCU 推理和训练任务的性能分析流程：如何建立基线、如何放置同步、如何导出 t

在 DCU 上优化模型，最容易犯的错误是看到addmm排第一，就立刻重写 GEMM。我的实际 Profile 显示，112 次共占 35.244 ms，确实是单项第一；但同一张表还显示 34 次占 14.521 ms、32 次占 5.740 ms，以及大量短逐元素 kernel。最终最稳定的端到端收益并不来自替换 GEMM，而来自围绕固定 shape 的 LayerNorm、窗口 gather 和