基于Ascend C的Pdist自定义算子开发：从基础入门到性能优化

本文详细解析了基于Ascend C框架开发Pdist自定义算子的全过程，重点探讨了如何在昇腾910B处理器上实现计算精度、显存带宽与硬件指令的极致平衡。文章首先剖析了Pdist算子的数学公式与赛题核心挑战，包括精度约束、性能要求和硬件限制。随后系统介绍了AI算子开发的基础知识，包括昇腾AI Core架构、Ascend C/TIK开发框架和双层架构设计。最后分享了基于TIK的Pdist实现方案，展示

得之我幸，失之我命

267人浏览 · 2026-03-15 20:12:56

得之我幸，失之我命 · 2026-03-15 20:12:56 发布

算子开发绝不是简单的“公式翻译”，而是一场在计算精度、显存带宽与底层硬件指令之间寻找极致平衡的走钢丝游戏。
本次赛题的核心任务是基于 Ascend C 框架，为昇腾 910B 处理器开发 Pdist（Pairwise Distance）自定义算子。本文将全景式地复盘我们是如何从零构建双层架构、如何通过 Tiling 切分榨干 NPU 算力，希望能为深入 AI Infra 与底层计算架构的开发者们提供一份极具实操价值的“通关手册”。

代码：https://pan.quark.cn/s/bfbfcb7f7312?pwd=cjcL

一、题目解析：Pdist算子核心需求与挑战

本次赛题的核心任务是基于Ascend C（或TIK）框架，为昇腾AI处理器开发Pdist（Pairwise Distance）自定义算子，对标PyTorch原生算子torch.pdist()。

1. 核心功能与数学公式

Pdist算子的核心功能是计算输入张量中每对行向量之间的 $p$ 范数距离，通用数学表达公式为：
$distance(xi,xj)=(∑k=1m∣xi,k−xj,k∣p)1/pdistance(x_i, x_j) = \left( \sum_{k=1}^{m} |x_{i,k} - x_{j,k}|^p \right)^{1/p}$

其中：

当 $p = 0$ 时，为Hamming距离（统计非零元素个数）；
当 $p = 1$ 时，为Manhattan距离（绝对值之和）；
当 $p = 2$ 时，为Euclidean距离（平方和开根号）；
当 $p=∞p=\infty$ 时，为Chebyshev距离（取绝对值最大值）。

2. 赛题核心挑战

精度约束：误差需控制在 $1 e - 4$ 以内，直接用float16全流程计算易因幂运算/开方的精度损失超标；
性能要求：需充分利用昇腾AI Core的算力，通过Tiling切分、流水并行等手段榨干硬件性能；
硬件约束：需满足32Byte地址对齐、UB（Unified Buffer）容量限制等昇腾硬件特性，否则易出现Core Dump。

二、算子开发核心基础知识（新手入门必看）

在正式进入开发实践前，我们先梳理算子开发的核心基础知识，这也是我们备赛初期花了大量时间吃透的内容——所有的性能优化、问题排查，本质上都是基于这些底层逻辑展开的。

2.1 什么是AI算子？为什么要开发自定义算子？

AI算子，本质上是AI模型中最基础的计算单元，我们熟悉的卷积、池化、矩阵乘法、激活函数，甚至本次开发的距离计算，都是算子。

我们日常使用PyTorch、TensorFlow等框架时，调用的大多是框架内置的通用算子。但在以下场景中，必须开发自定义算子：

框架内置算子没有覆盖的自定义计算逻辑（如特殊的距离计算、自研的模型层）；
内置算子在特定硬件上的性能未达预期，需要针对硬件架构做深度定制优化（本次赛题的核心场景）；
需适配昇腾等专用AI芯片的底层特性，实现端到端的算力最大化。

简单来说，算子开发就是“给AI芯片写可执行的计算函数”，而自定义算子开发，就是脱离框架的通用封装，直接操控硬件资源，实现精度、性能的极致平衡。

2.2 昇腾AI Core核心硬件架构（所有优化的底层基础）

https://developer.huawei.com/consumer/cn/doc/harmonyos-guides/cannkit-hardware-architecture-abstraction

昇腾AI Core是昇腾NPU的核心计算单元，基于华为自研的达芬奇（Da Vinci）架构设计，我们所有的算子代码最终都会运行在这个单元上，它的硬件架构直接决定了算子开发的所有规则和优化方向。

先来看昇腾处理器的整体硬件架构，理解AI Core在整个芯片体系中的位置：

红色虚线框内为 AI Core 集群，是算子执行的核心计算单元

在这里插入图片描述
*图 1 昇腾 910 处理器整体架构图

而我们算子开发需要深度适配的，是AI Core内部的微架构，核心组成如下：

在这里插入图片描述

图2 昇腾达芬奇架构AI Core核心组成示意图

AI Core的核心组件可分为三大类，每一类都和我们的算子开发息息相关，具体说明如下：

核心组件分类	组件名称	功能定位	开发核心注意事项
计算单元	Cube计算单元	专为矩阵乘运算优化的3D立方计算引擎，单周期可完成4096次乘加运算	本次Pdist算子以向量运算为主，核心算力释放依赖Vector单元，矩阵类算子需重点适配Cube单元
	Vector Core（向量计算单元）	负责执行向量运算，是本次Pdist算子的算力核心	支持单指令多数据（SIMD）并行计算，一条向量指令可同时处理数十个数据，性能是标量指令的百倍以上；开发中要尽量用向量化指令，避免标量循环
	Scalar Core（标量计算单元）	负责程序流控制、地址计算、标量运算，相当于AI Core的“小CPU”	标量运算会阻塞向量流水线，开发中需尽量减少标量计算，可预计算的标量尽量放在Host侧完成
存储层级	Global Memory（GM，全局内存）	对应芯片的HBM高带宽内存，容量大（几十GB）但访存延迟极高	算子开发的核心原则：尽量减少GM访问，避免频繁在GM和片上缓存之间搬运数据
	L2/L1 Cache	片上共享缓存，延迟远低于GM，高于UB	可通过数据预取、大块连续访问提升Cache命中率，减少GM访问频次
	Unified Buffer（UB，统一缓存/片上局部内存）	AI Core私有的片上高速缓存，容量极小（昇腾910B单AI Core的UB通常为256KB）但访存延迟极低，是GM的1/100不到	所有核心计算都必须在UB中完成，Tiling切分的核心就是适配UB的容量限制；32Byte地址对齐是硬件强约束，所有对UB的访问地址必须是32Byte的整数倍，否则会直接触发访问异常甚至Core Dump
数据搬运单元	DMA（直接内存访问）控制器	负责GM和UB之间的数据异步搬运，不占用计算单元资源	可通过乒乓缓存机制，实现“数据搬运”和“计算”的并行执行，彻底消除数据等待的空闲时间

2.3 Ascend C与TIK开发框架简介

本次赛题支持的两种开发框架，都是昇腾官方提供的算子开发语言，适配昇腾AI Core硬件：

TIK（Tensor Iterator Kernel）：基于Python的算子开发语言，提供了向量化指令、内存管理、循环控制等封装，语法简单，调试便捷，适合新手入门，官方内置算子也有大量基于TIK的实现（本文参考的官方Pdist代码就是基于TIK开发）。
Ascend C：基于C++的算子开发语言，更贴近硬件底层，提供了更精细的硬件操控能力、更强的类型安全和更高的执行性能，同时原生支持流水并行、多核并行等高级特性，是高性能算子开发的首选，也是本次赛题我们最终使用的开发框架。

两者的核心逻辑完全一致，只是语法封装不同，掌握了其中一种，就能快速迁移到另一种。

2.4 算子开发的标准双层架构

无论是Ascend C还是TIK，算子开发都遵循**Host侧（CPU侧）+ Kernel侧（NPU侧）**的双层解耦架构，这也是业界通用的算子开发规范，整体交互逻辑如下：

图3 昇腾算子开发Host+Kernel双层架构示意图

Host侧：运行在服务器CPU上的代码，相当于算子的“大脑”，核心职责是：
- 校验输入参数的合法性；
- 计算Tiling切分参数，规划数据分块策略；
- 申请Workspace临时内存，管理算子的内存生命周期；
- 下发Kernel执行指令，调度NPU完成计算。
Kernel侧：运行在NPU的AI Core上的代码，相当于算子的“手脚”，核心职责是：
- 按照Host侧的Tiling参数，完成数据从GM到UB的搬运；
- 执行核心的向量化计算逻辑；
- 将计算结果从UB写回GM，完成最终输出。

简单来说，Host侧负责“规划怎么算”，Kernel侧负责“实际执行计算”，两者解耦开发，既能保证逻辑清晰，也能最大化适配硬件的调度规则。

2.5 算子开发核心术语速览

本文后续会高频出现以下术语，这里先做统一解释，避免阅读障碍：

Tiling（数据切分）：因为UB容量有限，无法一次性放下完整的大张量，所以需要把大张量切分成多个能放进UB的小块，分批次完成计算，这个切分过程就是Tiling，是决定算子性能上限的核心。
乒乓缓存（Double Buffering）：把UB分成两个独立的缓存区，A区做计算时，B区通过DMA异步搬运下一批数据，计算完成后直接切换缓存区，实现“计算”和“数据搬运”的完全并行，彻底消除数据等待的空闲时间。
向量化指令：Vector Core支持的vec_xxx系列指令，一条指令可同时处理多个数据，是释放NPU算力的核心，比如vec_add、vec_abs、vec_ln等。
混合精度计算：结合float16和float32两种数据类型的优势，输入输出用float16降低带宽占用，核心计算用float32保证计算精度，是平衡精度和性能的核心方案。
Core Dump：AI Core执行异常导致的核心挂死，绝大多数是内存越界、地址未对齐、非法指令等硬件强约束违规导致的，是算子开发中最常见的致命错误。

三、Pdist算子核心实现逻辑（基于TIK语言）

我们在开发过程中参考了官方基于TIK的Pdist算子实现，（存在于昇腾开发套件）其逻辑清晰，对Ascend C开发也有很强的借鉴意义。以下是核心实现解析：

cat /usr/local/Ascend/ascend-toolkit/latest/opp/built-in/op_impl/ai_core/tbe/impl/dynamic/pdist.py

3.1 整体架构

算子分两个核心函数实现：

pdist_process：完成距离核心计算与核内累加（差值→绝对值→幂运算→累加）；
pdist_sum_process：承接累加结果，完成最终的开 $p$ 次方计算。

所有计算均依托片上UB完成，最大化利用高速缓存，同时通过ln+exp数学变换实现幂运算和开方，避免直接幂运算的精度损失。

3.2 `pdist_process`：距离核心计算与核内累加

该函数分 $p = 0$ 和 $p \neq = 0$ 两个分支处理，核心逻辑如下：

def pdist_process(self, mask, src_addr1, src_addr2, repeat_times, count_num, index_id):
    # 分支1：p=0（Hamming距离，统计非零元素个数）
    with self.tik_instance.if_scope(self.p == 0.0):
        # 步骤1：计算行向量差值
        self.tik_instance.vec_sub(mask, self.src1_ub[src_addr1], self.src2_ub[src_addr2], 
                                  self.src2_ub[src_addr2], repeat_times, 8, 8, 8)
        
        # 步骤2：遍历差值，零值置0、非零值置1
        with self.tik_instance.for_range(0, count_num) as k:
            with self.tik_instance.if_scope(self.src1_ub[src_addr1 + k] == 0.0):
                self.src1_ub[src_addr1 + k].set_as(self.scalar_zero_loop)
            with self.tik_instance.else_scope():
                self.src1_ub[src_addr1 + k].set_as(self.scalar_one_loop)
        
        # 步骤3：归约求和，得到非零维度总数
        self.tik_instance.vec_reduce_add(mask, self.temp_sum_tensor, self.src1_ub[src_addr1], 
                                         self.work_tensor, repeat_times, 8)

    # 分支2：p≠0（通用距离计算）
    with self.tik_instance.else_scope():
        # 步骤1：计算行向量差值
        self.tik_instance.vec_sub(mask, self.src1_ub[src_addr1], self.src2_ub[src_addr2], 
                                  self.src1_ub[src_addr1], repeat_times, 8, 8, 8)
        
        # 步骤2：取绝对值
        self.tik_instance.vec_abs(mask, self.src1_ub[src_addr1], self.src1_ub[src_addr1], 
                                  repeat_times, 8, 8)
        
        # 步骤3：通过ln+exp计算p次方（避免直接幂运算的精度损失）
        # 3.1 取对数：ln(|x-y|)
        self.tik_instance.vec_ln(mask, self.src1_ub[src_addr1], self.src1_ub[src_addr1], 
                                 repeat_times, 8, 8)
        # 3.2 乘以指数p：p * ln(|x-y|)
        self.tik_instance.vec_muls(mask, self.src1_ub[src_addr1], self.src1_ub[src_addr1], 
                                   self.p, repeat_times, 8, 8)
        # 3.3 取指数还原：exp(p * ln(|x-y|)) = |x-y|^p
        self.tik_instance.vec_exp(mask, self.src1_ub[src_addr1], self.src1_ub[src_addr1], 
                                  repeat_times, 8, 8)
        
        # 步骤4：归约求和，得到sum(|x-y|^p)
        self.tik_instance.vec_reduce_add(mask, self.temp_sum_tensor, self.src1_ub[src_addr1], 
                                         self.work_tensor, repeat_times, 8)

    # 多核并行结果转存：将每个核的中间结果写回
    scalar_sum_each_core = self.tik_instance.Scalar(dtype="float32", 
                                                    name="scalar_sum_each_core", 
                                                    init_value=self.dst_sum_tensor[index_id])
    self.tik_instance.vec_adds(1, self.temp_sum_tensor, self.temp_sum_tensor, 
                               scalar_sum_each_core, 1, 8, 8)
    self.dst_sum_tensor[index_id].set_as(self.temp_sum_tensor[0])

3.3 `pdist_sum_process`：最终距离计算（开 $p$ 次方）

该函数承接累加结果，通过ln+exp完成开方计算，同时提前在Host侧计算 $1/ p$ （p_reciprocal），避免向量计算中重复做除法：

def pdist_sum_process(self, compute_mask, dst_addr, repeat_times):
    # 步骤1：取对数：ln(sum(|x-y|^p))
    self.tik_instance.vec_ln(compute_mask, self.dst_sum_tensor[dst_addr], 
                             self.dst_sum_tensor[dst_addr], repeat_times, 8, 8)
    
    # 步骤2：乘以提前计算好的1/p：(1/p) * ln(sum)
    self.tik_instance.vec_muls(compute_mask, self.dst_sum_tensor[dst_addr], 
                               self.dst_sum_tensor[dst_addr], self.p_reciprocal, 
                               repeat_times, 8, 8)
    
    # 步骤3：取指数还原：exp((1/p) * ln(sum)) = sum^(1/p)
    self.tik_instance.vec_exp(compute_mask, self.dst_sum_tensor[dst_addr], 
                              self.dst_sum_tensor[dst_addr], repeat_times, 8, 8)

3.4 关键实现细节

vec_xxx向量指令：TIK核心指令，效率远高于标量计算，参数8为适配昇腾AI Core的位宽配置；
UB缓存利用：所有核心计算均在UB中完成，避免GM与UB的频繁数据交互，符合前文提到的“核心计算在片上完成”的开发原则；
标量预计算： $1/ p$ 、0、1等标量提前在Host侧计算，减少Kernel侧无效开销，避免占用Scalar Core资源。

四、算子开发典型问题与定位方法（基于250个错误案例统计）

结合昇腾算子开发250个错误案例的统计结果，以及Pdist算子的实现特点，我们梳理了12种高频问题，按优先级排序如下：

1. 算子运算结果错误（🔴 最高优先级，占比52.4%）

案例数：131
现象：无报错，但精度超标（误差> $1 e - 4$ ）或结果完全错误
核心排查：
- 精度折损：检查是否在FP16模式下强行运行了vec_ln和vec_exp，务必转FP32计算；
- 并发冲突：验证多核并行时index_id步长分配是否重叠，导致结果相互覆盖；
- 特殊逻辑错位：检查 $p = 0$ 分支的“零/非零判断”逻辑，是否因Mask错误遗漏尾部维度；
- 调试工具：开启CPU调试模式（export ASCEND_OPP_PATH=... + gdb --args python test.py），逐行打印张量值。

2. 算子耗时超出基线（🟡 次高优先级，占比9.2%）

案例数：23
现象：执行慢，吞吐量未达标
核心排查：
- 使用ms_prof_op抓取PMU数据，重点看UB利用率（若低于80%说明Tiling太碎）；
- 检查是否存在“长尾核”（单核处理过多尾巴数据）；
- 排查是否混入标量指令打断了Vector算力流水线。

3. 输出内存使用异常（🟡 次高优先级，占比8.8%）

案例数：22
错误码：507899
现象：内存泄漏，系统内存占用持续上涨直至崩溃
核心排查：
- 检查AllocTensor和FreeTensor是否成对出现；
- 核对输出张量的Shape是否与分配大小严格一致；
- 排查多核写回时是否存在核内临时张量未释放。

4. 访问无效内存地址（🟡 次高优先级，占比8.4%）

案例数：21
错误码：507015
现象：AICORE直接挂死（Core Dump）
核心排查：
- 查看~/.mindstudio/logs/debug/plog*.log与tlog，区分是UB越界还是GM越界；
- 检查地址偏移计算（如src_addr1 + k）是否越过申请的内存边界；
- 确认多核任务分发时Core ID没有超过物理核心数。

5. 算子命名错误/找不到二进制文件（🟢 中等优先级，占比6.0%）

案例数：15
现象：调用失败，提示找不到二进制文件
核心排查：
- 核对Host端调用名、算子类名与Json配置文件，确保名称、大小写完全一致；
- 检查环境变量是否正确指向了.so动态库。

6. GM/UB数据访问越界（🟢 中等优先级，占比5.2%）

案例数：13
现象：Kernel执行异常，常伴随Core Dump
核心排查：
- 打印repeat_times和count_num，验证实际读写长度是否大于UB物理容量上限；
- 非对齐场景下，检查Pad补全长度是否超出分配空间。

7. 找不到对应Tiling Key的Kernel（🟢 中等优先级，占比4.0%）

案例数：10
错误码：31361001
现象：提示Kernel未找到
核心排查：
- 确保Host侧生成的Key与Kernel侧注册的Key完全匹配；
- 检查Tiling配置文件是否被正确打包编译进算子包。

8. 算子执行超时（🔵 低优先级，占比2.4%）

案例数：6
现象：脚本>30s主动退出
核心排查：
- 检查for_range是否存在死循环；
- 超大张量场景下，排查Tiling粒度是否过大导致单轮执行卡死。

9. 地址未对齐（🔵 低优先级，占比1.2%）

案例数：3
现象：日志抛出“地址非32Byte对齐”警告，执行中断
核心排查：
- 昇腾NPU硬件强约束！确保地址必须是32的倍数；
- 使用异常检测工具锁定未对齐的汇编指令，修正指针位移算法。

10. 流同步超时（🔵 低优先级，占比1.2%）

案例数：3
现象：任务卡死/超时
核心排查：
- 输入极小数据测试，若仍卡死大概率是AllocTensor异常导致Stream锁死；
- 若极小数据正常，说明是大规模计算时性能极差导致超时，需重构流水并行。

11. Host侧Segmentation fault（🔵 低优先级，占比0.8%）

案例数：2
现象：Host侧程序崩溃
核心排查：
- 纯C++基础错误，使用GDB调试op_host侧代码；
- 重点排查输入空指针未拦截、可选参数获取崩溃、Tiling结构体内存操作越界。

12. 数据类型支持不全（🔵 低优先级，占比0.4%）

案例数：1
现象：测试用例Fail
核心排查：
- 检查是否全面覆盖了int8、float16、float32等测试用例类型；
- 缺少任何一个路由分支都会导致失败。

五、Pdist算子性能优化核心方法论（按优先级排序）

老师同学们好，我们来自郑州大学，在整个过程中我们踩了不少坑，也摸索出一些实用方法，最终实现了多p值支持，在精度和性能上达成了理想效果。以下是我们的实践心得，不当之处恳请各位批评指正，也希望这些不成熟的经验能给大家提供一点参考。

一、核心解题思路：在精度与性能间找平衡

精度保障：踩坑后摸索的混合精度方案

一开始我们直接用float16完成全流程计算，精度偏差特别明显。后来跟着Ascend
C官方思路和答疑会的讲解，尝试了混合精度计算方案：输入输出仍用float16以节省显存、转化为float32执行核心计算；最后再将结果转回float16输出。

性能优化过程我们也是跟着Ascend C优化指南慢慢摸索：

算法特化：避免用通用算法或Pow指令一刀切，对p=1、2、∞这些常用值做了分支优化，比如p=2: 使用平方根运算，提高效率，p=∞调用ReduceMax返回最大值，比通用逻辑效率高一些；

内存分块：在Host侧提前计算Tiling参数，把数据切分成小块，确保单个块能完整存入高速内存（Local Memory），减少全局内存访问次数；

向量化指令：我们用Ascend C向量接口，避免标量循环——刚开始没注意这点，性能一直上不去，后来修正后算力释放明显提升。

二、代码结构：参考成熟模板，保证逻辑清晰

我们的代码结构参考了Ascend C中级认证的模板和gitee上一个pytorch适配ascend npu的项目，逻辑上会比较清晰：

Op_Host（CPU侧）：主要负责统筹调度，比如计算Tiling参数、申请Workspace内存、下发Kernel指令。这里要特别注意GetWorkspaceSize的实现，我们用混合精度计算，float32临时数据需要双倍空间，一开始预留不足导致内存越界，后来调整后才解决；

Op_Kernel（NPU侧）：按“Init→Process→Compute”流程实现核心逻辑，我们用了模板类PdistKernel设计，一套代码兼容fp16和fp32两种数据类型，减少了不少冗余；

编译验证：建议大家用官方的compile_kernel.sh脚本调用ccec编译器测试，能成功生成.o文件，基本说明核函数代码符合硬件规范，后续调试也更有方向。

三、问题排查：分享几个我们踩过的坑

Cast指令位置：一定要在数据搬运至Local Memory后再转换，提前转换会导致数据量翻倍，浪费带宽；

Tiling分块对齐：Ascend C对数据地址对齐要求高，Block大小建议设为32 Bytes的整数倍，尾块逻辑要单独处理，不然容易出现Core Dump；

p=0场景单独处理：汉明距离是统计非零元素个数，和其他p值逻辑不同，一开始混在通用公式里导致错误，后来单独做了分支处理；

数值保护：开根号或除法前，要加个1e-8这样的极小值，避免全零向量场景出现NaN。

昨天任涛老师讲解的常见错误我们也出现过，指出的优化路线有很多我们都没有考虑到，后续会继续努力。感谢各位聆听，恳请各位老师同学们批评指正。

性能优化遵循“先功能正确，再性能调优”的原则，结合昇腾硬件特性和Pdist算子特点，我们梳理了以下可落地的优化方法：

1. 最高优先级：Tiling设计（决定性能上限）

正如前文基础知识中提到的，Tiling的核心是适配UB的有限容量，减少GM访问，它直接决定了算子的性能上限：

按特征维度切分：若单行列数超过UB容量，将一行拆分成多个UB大小的块，分轮次计算并核内累加；
多核负载均衡：将“尾巴”数据均匀分配到不同核，避免“单核扛所有、其他核空闲”；
32Byte对齐约束：块大小设为32Bytes整数倍，尾块Pad补全后结合Mask过滤无效数据；
Pdist专属技巧：优先按行切分，让每个核处理连续多行数据，减少跨核通信。

2. 次高优先级：流水并行与硬件资源利用

通过流水并行让数据搬运和计算同时进行，最大化利用AI Core的硬件资源，避免计算单元空闲：

Double Buffering（乒乓缓存）：将UB分成两个缓存区，一个计算、一个搬运GM数据，配合T Pipe自动同步，实现计算与I/O重叠；
避免核间同步：核内累加和结果写回尽量在核内完成，减少核间等待；
标量卸载：预计算的标量（如 $1/ p$ ）全部上卷至Host侧计算，直接向Kernel侧传递结果，避免占用Scalar Core资源。

3. 基础优先级：代码与存储细节优化

细节优化虽单条提升有限，但组合后能显著拉开性能差距，也是赛题中拉开分数的关键：

算法场景特化：对 $p=0,1,2,∞p=0,1,2,\infty$ 单独分支优化，比如 $p = 2$ 直接调用平方和与平方根专用指令， $p=∞p=\infty$ 调用ReduceMax，单场景效率提升超15%；
Cast指令后置：先以float16格式搬运数据至UB，再在片上转float32，访存带宽开销暴降50%；
Epsilon数值保护：在分母或底数中叠加 $1 e - 8$ 极小值，避免全零向量触发NaN异常；
存储搬运优化：保证DM地址512Byte对齐，优先搬运大块数据，充分利用L2 Cache缓存重复使用的行向量。

六、备赛与开发实操建议

功能优先，层层验证：先实现 $p = 2$ 欧式距离，用小数据量验证后再扩展全p值；每完成一个功能模块单独验证，避免后续排查困难。
先吃透基础，再谈优化：备赛初期不要急于写代码，先把AI Core硬件架构、双层开发规范、核心术语吃透，能少走80%的弯路。
熟练掌握工具：重点掌握ms_prof_op（PMU真实数据）和ms_prof_op_simulator（性能流水图），通过流水图分析时序，定位瓶颈而非盲目优化。
提前规避高频问题：重点关注结果错误、内存越界、Tiling切分三大高频问题，在核心代码处添加日志打印；规范内存申请/释放流程，养成配对使用习惯。
充分利用演练环境：多测试超大shift值、非对齐、多数据类型等边界场景；尝试不同Tiling策略，通过上板数据对比选择最优方案。
学会使用AI: 开发过程中尽量使用cursor或trae这种IDE去辅助编程，提升效率。