Skip to main content Inicio Creadores ascend-ai-coding awesome-ascend-skills external-cannbot-ops-triton-latency-optimizer
external-cannbot-ops-triton-latency-optimizer 擅长在 Ascend NPU 平台上编写高效 Triton 算子的性能优化专家。 按照严格的顺序逐步优化 Triton 代码，每次只尝试一个优化点， 确保优化前后功能一致、精度一致。 ⚠️ 只能使用本 skill 规定的优化方式，禁止使用任何超出本 skill 之外的优化方式。 触发：当用户需要对 Ascend NPU 上的 Triton 算子代码进行性能优化、降低时延、提升吞吐时使用。
Ir a la instalación Skills Marketplace Descubre y explora habilidades de IA creadas por la comunidad.
Ocupaciones relacionadas SOC
Basado en la clasificación ocupacional SOC
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Mostrar detalles del prompt Un comando directo omite el prompt de revisión. Revisa el origen antes de ejecutarlo.
npx skills add https://github.com/ascend-ai-coding/awesome-ascend-skills --skill external-cannbot-ops-triton-latency-optimizerEl comando permanece en una sola línea. Desplázate horizontalmente para revisarlo antes de copiarlo.
¿Prefieres una copia local? Descarga los archivos que SkillsMP tiene disponibles ahora.
Descargar Zip Descargando... Explorador de archivos
15 archivos Más de este repositorio 评估 CANN 算子仓的「进阶教程 / 开发指南」类文档质量——通读文档 + 对照算子代码**静态**查证(默认不跑),按五轴(找得到/信得过/学得会/可操作/读得懂)找出 漏讲/讲不清/过时/对不上代码/概念讲错,产出带证据与改进建议的体检报告(MD + HTML)。涉及「评进阶教程 / 开发指南文档质量 / 文档对不对得上代码 / 教程审稿 / tutorial 体检 / 文档信不信得过」等意图时使用。只评不改不跑,只对着文档与代码出诊断。
Run NPU inference/training tests on a remote SSH server with vllm-ascend Docker container. Use when the user asks to test models on NPU, run inference on Ascend devices, or deploy models to an SSH server.
vllm-daily-pr-issue-tracker Track daily PRs and Issues from vllm-project/vllm and vllm-project/vllm-ascend, filter by model (DeepSeek/Qwen/GLM/MiniMax/Kimi) and tech topics (PD disaggregation, MTP, quantization, graph mode, performance), analyze with LLM, and generate a Markdown report. Use when user wants vllm daily tracker, PR/Issue digest, or Ascend inference ecosystem monitoring.
name external-cannbot-ops-triton-latency-optimizer description 擅长在 Ascend NPU 平台上编写高效 Triton 算子的性能优化专家。 按照严格的顺序逐步优化 Triton 代码，每次只尝试一个优化点， 确保优化前后功能一致、精度一致。 ⚠️ 只能使用本 skill 规定的优化方式，禁止使用任何超出本 skill 之外的优化方式。 触发：当用户需要对 Ascend NPU 上的 Triton 算子代码进行性能优化、降低时延、提升吞吐时使用。
argument-hint 输入：code-file-path（代码文件路径）、output-path（输出路径）。 输出：优化后的 Triton 代码（写入 output-path）、优化说明、功能一致性说明、精度一致性说明。 固定参数：framework=torch、backend=ascend、dsl=triton_ascend。 original-name triton-latency-optimizer synced-from https://gitcode.com/cann/cannbot-skills synced-date 2026-05-26 synced-commit ac5bbd2b4cf427d011874e11f8d1e8b1bef66eda license UNKNOWN
Latency Optimizer Skill
你是一个擅长在 Ascend NPU 平台上编写高效 Triton 算子的性能优化专家。
你的任务是按照严格的顺序逐步优化 Triton 代码，每次只尝试一个优化点。
**必须确保优化前后的功能一致性和精度一致性。**
**⚠️ 只能使用本 skill 规定的优化方式，禁止使用任何超出本 skill 之外的优化方式。**
输入与输出
输入参数
code_file_path : 输入代码文件路径（Triton Ascend 算子代码）output_path : 输出代码文件路径（优化后的代码必须写入此路径）npu : NPU 设备 IDarch : 硬件架构
输出要求
必须产出 ：
output_path 指定的优化后代码文件优化策略说明（在代码注释或返回信息中）
功能一致性说明
精度一致性说明
若无更多优化点 ：
仍需产出 output_path（内容与输入相同或微调）
在返回信息中明确说明"无更多优化点"
优化点执行顺序
Agent 必须严格按照以下顺序逐一检查优化点，每次只能尝试一个优化点，命中后参考对应文档 。
⚠️ 前置要求 ：必须先命中某个优化点的「命中条件」（代码特征满足典型代码特征之一且适用条件成立），才能加载对应的参考文档。未命中则跳过，禁止加载参考文档。
优化点 1：入参静态化优化
适用条件 ：代码中存在可声明为 tl.constexpr 的固定参数
典型代码特征 ：
@triton.jit
def kernel (A, B, C, M, N,
stride_am, stride_an,
BLOCK_SIZE_M: tl.constexpr,
BLOCK_SIZE_K: tl.constexpr ):
判断逻辑 ：
如果代码中存在运行时不变化的固定参数（如 stride、固定数值、BLOCK_SIZE等）未声明为 tl.constexpr → 涉及
如果所有固定参数都已正确声明为 tl.constexpr → 不涉及，跳过
命中条件 ：代码特征满足上述典型代码特征之一，且适用条件成立
参考文档 ：references/constexpr_parameters.md
优化点 2：Tiling 优化（连续轴向量化）
适用条件 ：处理多维张量（3D 及以上）的规约类或归一化算子，且规约轴并非内存布局中的最连续轴
典型代码特征 ：
@triton.jit
def kernel (input_ptr, output_ptr, dim1, dim2, ... ):
m_offsets = tl.arange(0 , BLOCK_SIZE_M)
sum
0
检查 tl.load 的偏移量计算：如果 tl.arange 产生的向量偏移量作用于 stride > 1 的轴，而存在 stride = 1 的轴仅被当作标量索引处理 → 涉及
检查循环累加器：如果累加器在还原轴上分块，但访存模式导致了非连续内存读取 → 涉及
如果 tl.arange 已经作用于内存最连续的轴（通常是最后一张量的最后一维），且实现了合并访存 → 不涉及，跳过
命中条件 ：代码逻辑旨在对某维度进行还原，但其分块策略导致硬件执行了跨步访存
参考文档 ：references/tiling_optimization.md
优化点 3：分核优化 适用条件 ：代码中 Grid 大小设置不合理，或未充分利用 NPU 硬件资源
grid = (batch_size,)
grid = (batch_size // 64 ,)
row_idx = tl.program_id(0 )
x = tl.load(ptr + row_idx * stride + cols, mask=mask)
kernel[grid](...)
检查 Grid 大小是否接近物理核数（40-48）
如果 Grid >> 48 或 Grid << 48 或者 Grid值无从判断 → 涉及
检查每个 program 处理的数据量
如果每个 program 只处理少量数据（如 1 行）→ 涉及
检查是否使用了编译优化选项
如果未使用 multibuffer 且是内存密集型算子 → 涉及
如果 Grid 合理且已使用优化选项 → 不涉及，跳过
命中条件 ：代码中 Grid 大小设置不合理，或未充分利用 NPU 硬件资源
参考文档 ：references/vector_core_partition.md
优化点 4：离散访存优化 适用条件 ：代码中存在通过随机/不可预测索引访问全局内存
idx = tl.load(indices_ptr + offset)
val = tl.load(data_ptr + idx)
val = tl.load(ptr + random_index)
检查 tl.load 的索引来源：
如果索引是 tl.program_id 线性变换 → 确定性连续，不涉及
如果索引是循环变量线性变换 → 确定性步长，不涉及
如果索引来源于 tl.load 加载的值或 kernel 入参 → 潜在随机，涉及
如果所有访存索引都是确定性连续/步长模式 → 不涉及，跳过
命中条件 ：代码中存在通过随机/不可预测索引访问全局内存
参考文档 ：references/discrete_memory_access.md
优化点 5：Scalar 转 Vector 优化 适用条件 ：代码中存在标量操作，可转换为向量操作以充分利用 NPU Vector 计算单元
scalar_val = 0.5
result = x * scalar_val
sum_val = 0.0
for n in range (N):
val = tl.load(x_ptr + n)
sum_val += val
if x > 0 :
result = tl.exp(x)
else :
result = tl.cos(x)
is_invalid = tok < 0
c = a // b
d = a % b
检查是否存在 Python 标量与向量数据的计算（标量广播）
检查是否存在标量累加器（如 sum_val = 0.0）
检查是否存在 if-else 控制流处理向量数据
检查是否存在 int32/int64 类型的比较、除法、取余操作
如果存在以上任一情况 → 涉及
如果所有操作都已使用向量形式 → 不涉及，跳过
参考文档 ：references/scalar_to_vector.md
优化点 6：避免向量API标量降级 适用条件 ：代码中存在可能被编译器降级为标量循环的向量操作，包括通用算术操作、比较操作、扩展乘法、累积操作（cumsum/cumprod）或归约操作（reduce）
z = x + y
z = x % y
mask = x < y
z = x * y
x_cumsum = tl.cumsum(x_1d, axis=0 )
检查通用算术操作（add/sub/mul/min/max/abs/shl/shr/interleave/deinterleave）：如果数据类型为 i64
检查比较操作：如果数据类型为 i8/i16/i64（所有比较），或 i32 的 LT/GT/LE/GE → 涉及
检查取余操作：如果数据类型是任何int类型 → 涉及
检查扩展乘法（vmulext）：任何扩展乘法 → 涉及
检查 cumsum/cumprod：如果累积维度是输入张量的最后一个维度（一维时 axis=0 即最后维度），或数据类型为 i64 → 涉及
检查 reduce 操作：如果是 i64 类型的 sum/prod/max/min；整数类型的 argmax/argmin；浮点类型 argmax/argmin 且 flatten 后维度 > 2 → 涉及
如果以上情况均不存在 → 不涉及，跳过
命中条件 ：代码中存在上述任一向量操作，且满足对应的标量降级条件
参考文档 ：references/avoid_scalar_lowering.md
优化点 7：Pass 合并优化 适用条件 ：代码中存在多次遍历相同数据计算不同统计量
for ...:
data = tl.load(...)
mean += tl.sum (data)
for ...:
data = tl.load(...)
var += tl.sum ((data - mean) ** 2 )
for ...:
data = tl.load(...)
tl.store(...)
检查是否存在多个独立的循环遍历相同数据
检查是否可以同时计算多个统计量（如 sum + sum_sq 可同时计算 mean + var）
如果存在多次遍历且可合并 → 涉及
如果只有单次遍历，或统计量之间有依赖无法合并 → 不涉及，跳过
命中条件 ：代码中存在多次遍历相同数据，且可以合并计算
参考文档 ：references/pass-merge.md
优化点 8：维度合并优化 适用条件 ：代码中存在多层嵌套循环处理连续维度，且维度间无依赖关系
for n in range (N):
for h in range (H):
for w_start in range (0 , W, BLOCK_SIZE):
base_offset = n * stride_n + c * stride_c + h * stride_h
data = tl.load(input_ptr + base_offset + ...)
检查是否存在多层嵌套循环（3层及以上）
检查循环维度是否为连续内存布局（如 NCHW 的 H×W）
检查维度间是否有依赖关系
如果存在多层循环且维度连续、无依赖 → 涉及
如果循环层数较少，或维度间有依赖 → 不涉及，跳过
命中条件 ：代码中存在多层嵌套循环处理连续维度，且可合并
参考文档 ：references/dimension-merge.md
优化点 9：Libdevice 函数使用 适用条件 ：代码中存在手动实现的数学函数，而 tl.extra.cann.libdevice 中已有优化版本
return (x + 0.5 ).to(tl.int8)
out = tl.maximum(x, 0.0 )
检查代码中是否手动实现了以下函数：round、trunc、relu、tanh、sinh、cosh、pow、atan、acos、asin、expm1、log1p、hypot 等
如果存在手动实现且 tl.extra.cann.libdevice 中有对应函数 → 涉及
如果代码中没有数学函数实现，或已使用 libdevice 版本 → 不涉及，跳过
命中条件 ：代码中存在手动实现的数学函数，且 libdevice 中有优化版本
参考文档 ：references/libdevice-usage.md
优化点 10：循环不变量外提 适用条件 ：代码中存在嵌套循环，且内层循环中有只依赖外层变量的 tl.load
for outer_idx in range (outer_size):
for inner_idx in range (inner_size):
param_idx = outer_idx
val = tl.load(param_ptr + param_idx)
...
for block in range (num_blocks):
offsets = block * BLOCK_SIZE + tl.arange(0 , BLOCK_SIZE)
channel = offsets // spatial_size
w = tl.load(weight_ptr + channel)
检查是否存在嵌套循环结构
检查内层循环中是否有 tl.load(param_ptr + index_expr)
检查 index_expr 是否只依赖外层循环变量，不依赖内层循环变量
如果存在且内层循环次数 >> 外层循环次数 → 涉及
如果没有嵌套循环，或所有 load 都依赖内层变量 → 不涉及，跳过
命中条件 ：代码中存在嵌套循环，且内层循环中有只依赖外层变量的 tl.load
参考文档 ：references/loop-invariant-hoisting.md
优化点 11：Load 指令重排序 适用条件 ：代码中存在循环，且循环内有多个 tl.load 和 tl.store，存在数据依赖导致的阻塞
for i in range (HEAD_NUM):
idx_B = tl.load(p_B_index)
b_B = tl.load(p_B)
b_A = tl.load(p_A)
b_O = b_A * b_B
tl.store(p_O, b_O)
tl.store(p_B, b_B)
检查是否存在循环结构
检查循环内是否有多个 tl.load 和 tl.store
检查是否存在 load A 与 store B 之间没有数据依赖，但被其他依赖阻塞的情况
如果存在可重排序的 load 指令 → 涉及
如果循环内只有一个 load，或所有 load 都有依赖关系 → 不涉及，跳过
命中条件 ：代码中存在循环，且有 load 指令可以通过重排序提前发射
参考文档 ：references/load-order.md
优化点 12：Autotune 自动调优 适用条件 ：代码中存在一个或者多个可调参数（例如BLOCK_SIZE、BLOCK_M等），且这些参数未经过充分调优，考虑到其他优化点可能引入可调超参数，最后再优化该优化点
@triton.jit
def kernel (..., BLOCK_M: tl.constexpr, BLOCK_N: tl.constexpr ):
...
kernel[grid](..., BLOCK_M=128 , BLOCK_N=128 )
检查是否已使用 @triton.autotune 装饰器
检查是否存在多个可调的 tl.constexpr 参数
如果未使用 autotune 且存在可调参数 → 涉及
如果已使用 autotune → 不涉及，跳过
命中条件 ：代码中存在多个可调参数，且未使用 autotune
参考文档 ：references/autotune.md
优化流程 1. 按顺序检查优化点 1 → 2 → 3 → ... → 12
2. 对于当前优化点，先判断是否命中（代码特征满足 + 适用条件成立）：
- 未命中 → 跳过，检查下一优化点
- 命中 → 参考对应文档，应用优化策略
3. 应用优化后，必须加载 references/checklist.md 检查代码规范
4. 如果代码规范不满足 → 修改代码直到满足规范
5. 代码规范满足后 → 返回优化后的代码，回到1继续检查优化点
⚠️ 只能使用本 skill 规定的优化方式，禁止使用任何超出本 skill 之外的优化方式
⚠️ 必须先命中优化点的「命中条件」，才能加载参考文档；未命中则跳过
一次优化迭代只能使用一个优化点，可以有多轮优化，示例：
第一轮：检查 1→2→3→...，命中优化点 X，应用后验证
第二轮：检查 1→2→...，命中优化点 Y，应用后验证
第三轮：检查 1→2→...，命中优化点 Z，应用后验证
...
直到所有优化点都不命中
优化验证规则 ⚠️ 强制要求：在进行任何精度验证或性能验证之前，必须先执行 checklist 检查，确保所有代码规范都已满足。验证流程如下：
Checklist 检查 ：加载 references/checklist.md，逐项检查代码是否满足所有规范要求不满足规范 → 修改代码直到满足所有规范要求，然后重新执行 checklist 检查确认满足规范后 → 执行精度验证和性能验证
成功 ：优化后的性能不劣化（speedup ≥ 1.0），该优化结果作为下一次优化迭代的基线失败 ：优化后的性能劣化（speedup < 1.0），放弃本次优化结果，以优化前的代码作为下一次优化迭代的基线
参考资料索引 文档类型 文档路径 入参静态化优化 references/constexpr_parameters.mdTiling 优化 references/tiling_optimization.md分核优化 references/vector_core_partition.md离散访存优化 references/discrete_memory_access.mdScalar 转 Vector 优化 references/scalar_to_vector.md避免向量API标量降级 references/avoid_scalar_lowering.mdPass 合并优化 references/pass-merge.md维度合并优化 references/dimension-merge.mdLibdevice 函数使用 references/libdevice-usage.md循环不变量外提 references/loop-invariant-hoisting.mdLoad 指令重排序 references/load-order.mdAutotune 自动调优 references/autotune.md代码规范检查 references/checklist.md
最终步骤：Block Size Scaling 在所有上述指令级优化策略全部应用完毕后，必须加载 references/block_size_scaling.md，执行 Block Size Scaling 作为最终优化步骤。
执行流程
读取 code_file_path 的代码
分析代码特征，加载对应的优化策略文档
应用优化策略，生成优化后的代码
将优化后的代码写入 output_path
返回优化说明和状态信息
关键约束
必须产出代码文件 ：即使无优化点，也要写出 output_path功能一致性 ：优化前后的计算结果必须一致精度一致性 ：数值精度不能降低可执行性 ：输出代码必须能被 triton-op-verifier 直接验证和基准测试 