【精度】【核内同步】applyTopKTopPWithSorted算子精度问题定位

1. 精度异常表现

在进行applyTopKTopPWithSorted算子泛化验证时有少部分用例遇到精度问题，如下图所示，遇到的异常值精度误差极大：
![请添加图片描述](https://i-blog.csdnimg.cn/direct/c0bf7f59b986468d85ea5364c620b8ce.png
其中-200.0为实际为-inf值，为了避免精度比较失败特意做的修正。

applyTopKTopPWithSorted算子功能说明文档：https://gitcode.com/cann/ops-nn/blob/master/index/apply_top_k_top_p_with_sorted/README.md
功能介绍：算子通过升序排序后依次经过k和p两个条件做过滤取保留其中较大值，其他值涂成-inf，计算流程图如下：

2. 猜想，实验与现象

此类输出精度异常值差距极大，通常是有脏数据引入，比如输出的张量未初始化值，或者计算过程中获取到错误数据计算，这种错误数据一般来自初始化、数据踩踏和同步问题。
初始化是一种常见赋值操作，比如这个算子的输出就是保留部分较大值，其他值填充成-inf，那么kernel中的计算逻辑就会先把输出的所有值初始化成-inf，这样后续只需要计算哪些是保留的有效值并进行搬出就可以，不需要保留的值已经默认是-inf了。
数据踩踏一般是因为索引计算错误出现越界现象，比如A和B是两块相邻连续空间且本应互不相干，但是因为索引计算错误把B中部分数据干扰到A，或者反过来，在某些计算场景下这样的数据错乱就会导致结果异常。
同步问题则是前后数据计算之间有依赖，比如add，mul，reduceSum等vec操作，他们不是串行执行而是异步发射执行，如果指令间不插入同步，A变量可能在前一个vec函数还没有计算完情况下变已经传入到后续计算中处理，这样也会获取到错误数据计算导致异常。

2.1 初始化问题

初始化问题比较容易验证，笔者注直接释掉最后计算结果中红框部分的搬出操作接口，重新运行用例，输出全为-200（-inf），表明初始化没有问题。

2.2.数据踩踏和同步问题

数据踩踏和同步问题就稍微复杂些，通常需要跟着kernel实现流程进行分析。索引计算会更加复杂，所以笔者首先尝试定位是否是同步问题。
定位同步问题过程中，我们没办法一下子找到异常点，也没有查询到可以增加全局同步的方式。于是笔者用AI模型自制的一个小脚本，加载当下路径1.cpp文件内容逐行判断，在任意两行之间插入PipeBarrier<PIPE_ALL>()生成为1_modified.cpp，快速确认是否有核内同步问题存在。脚本如下，关键词是一些声明、赋值、变量创建等等不需要插入PIPE_ALL同步的相关语句（可能会引入报错），因此这些行都不增加PIPE_ALL。

# -*- coding: utf-8 -*- import re # 定义需要检查的关键词列表 keywords = ["constexpr", "using", "namespace", "__aicore__", "void", "SetFlag", "WaitFlag", "TQue<", "TBuf<", "void", "uint32_t ", "int64_t ", "float ", "inputT ", "GlobalTensor<", "LocalTensor<", "BinaryRepeatParams", "DataCopyExtParams", "for", " = ", "InitBuffer", "SetGlobalBuffer", " < ", " > ", "FreeTensor", "TPipe", "GM_ADDR", "continue", "+=", "//", "PIPE_ALL"] # 输入输出文件路径 input_file = "1.cpp" output_file = "1_modified.cpp" # 编译正则表达式以提高效率（忽略大小写） pattern = re.compile(r'|'.join(re.escape(kw) for kw in keywords), re.IGNORECASE) # 用于存储修改后的行 modified_lines = [] # 读取原始文件 with open(input_file, 'r', encoding='utf-8') as f: lines = f.readlines() # 遍历每一行 for line_num, line in enumerate(lines, start=1): # 去掉行尾换行符，处理时用 stripped_line = line.rstrip('\n') # 检查是否包含关键词（不区分大小写） if pattern.search(stripped_line) or len(stripped_line) < 5: # 包含关键词，原样保留 modified_lines.append(line) else: # 不包含关键词，检查是否包含 ";" if ';' in stripped_line: # 替换所有分号为 "; PipeBarrier<PIPE_ALL>();" # 注意：这里我们只替换分号本身，保持前后结构 new_line = stripped_line.replace(';', ';PipeBarrier<PIPE_ALL>();') modified_lines.append(new_line + '\n') else: # 不包含关键词也不含分号，原样保留 modified_lines.append(line) # 写入修改后的内容到新文件 with open(output_file, 'w', encoding='utf-8') as f: f.writelines(modified_lines) print(f"处理完成！已将修改后的内容写入 {output_file}")

我们将增加了PIPE_ALL的新代码重新进行kernel编译去运行用例（如果读者使用该脚本后进行kernel编译失败的话需要根据报错日志自己微调下），用例精度直接PASS了。连着运行几次都是成功，这说明我们的问题来自同步。后面笔者就用二分法逐步还原代码函数片段，最终定位到是下面这个函数还原后（即不增加PIPE_ALL）精度问题又出现了。再对这个函数内部进行二分，进一步缩小到346行到352行之间任意位置插入PipeBarrier<PIPE_ALL>()时没有精度问题。笔者再直接分析这一段代码的计算逻辑：①CumSum计算结果；②先直接搬运最后一个值（最大值，也就是算子最少会保留一个值）；③352行代码之后再根据loopProb-1遍历跟1-p阈值比较去搬运剩余的值。

从计算过程来看，①中Cumsum计算的值会在后续③中用来做判断依据，①和③是有依赖关系存在，但是笔者之前进行同步分析时在353行之后插入PIPE_ALL仍旧存在同步问题，这说明①cumsum计算过程是和②搬运最后一个值产生了同步问题，但这里二者本身不存在依赖关系，就很耐人寻味。
于是笔者想到唯一可能方向：复用空间。
①CumSum计算函数用到以下tensor：cumSumRes,cumSumTmp,softMaxRes,sharedTmpBuffer,
②搬运最后一个值用到以下tensor：scatterTensor，mGmOut_
其中①CumSum计算用到的临时空间sharedTmpBuffer和②中的scatterTensor是复用的，而他们之间只有347行有个PipeBarrier<PIPE_V>();和351行PipeBarrier<PIPE_MTE3>();操作，分别表示vec操作到vec操作之间的同步和mte3到mte3流水搬运之间的同步。这里就会出现一个情况，vec到mte3之间缺少同步，他们是异步执行的，在CumSum还在计算过程中时，scatterTensor取最后值并进行搬出的操作就已经开始了，这其中会产生错误数值导致最终精度异常。
# 3. 精度误差根源

CumSum和搬出最后一值过程中分别使用到的sharedTmpBuffer和scatterTensor共用一块空间，但是中间过程缺少相应同步，导致cumsum计算过程和最后一个值搬出过程冲突产生错误数值，最终使精度出现异常。

4. 解决方式

增加正确的同步操作：①508行cumsum计算→②509行vec到scalar同步确保cumsum计算完再使用scatterTensor取值：VToSSync();→③scatterTensor取最后值→④512行确保scalar取值完成后再进行搬出操作：SToMTE3Sync();→⑤最后一个值搬出。

5. 启发

在高性能计算中，合理复用内存空间能有效降低显存占用。但当多个异步操作共享同一块缓冲区时，若缺乏恰当的同步控制，极易引发数据竞争和精度异常。莫让“省空间”变成“出问题”，同步要“恰到好处”，要考虑空间复用之间的相互影响。