| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
feat(PIDModelFit): 新增 9个 PID 整定算子 + E2E 验证（系列共 12个，完整覆盖 PID 整定流程） Co-authored-by: liuhaidong<aliutec@163.com> # message auto-generated for no-merge-commit merge: !21 merge devin/1781921853-pid-modelfit-ops into master feat(PIDModelFit): 新增 9个 PID 整定算子 + E2E 验证（系列共 12个，完整覆盖 PID 整定流程） Created-by: haikuo Commit-by: liuhaidong Merged-by: cann-robot Description: ## Summary 本次为 **PIDModelFit** 算子系列提交：当前正式口径共 **12 个 NPU 自定义算子**，其中包括前序已提交的 **3 个 *_basis_gemm_fit 模型辨识算子**，以及本轮新增并保留的 **9 个诊断、整定、候选仿真、特征提取和评估类算子**。这 12 个算子共同覆盖 PID 整定主流程：模型辨识 → 模型诊断 → PID 参数生成 → 候选闭环仿真/评分/选优 → 候选特征提取 → 控制性能与过程能力评估。 > 重点（committer 第一眼）：本次正式合入范围已从早期探索口径收敛为 **12 个正式算子**。前序 3 个 *_basis_gemm_fit 辨识算子作为模型辨识基础能力保留，并补充 benchmark、docs/benchmark.md 与 README 描述；本轮新增并保留 9 个下游算子，补齐 PIDModelFit 从“能辨识模型”到“能诊断、能整定、能仿真选优、能验收评估”的完整工程链路。探索/历史原型算子不进入本次正式提交范围。 ## 算子清单（9 新 + 3 已有 = 12），按 PID 整定 6 阶段 1. **模型辨识**：pid_fopdt_basis_gemm_fit · pid_ipdt_basis_gemm_fit · pid_sopdt_basis_gemm_fit 2. **模型质量诊断**：pid_residual_diagnostics · pid_windowed_residual_diagnostics 3. **PID 参数生成**：pid_tuning_rule_batch（Ziegler-Nichols / IMC / Cohen-Coon） 4. **候选闭环仿真、评分与选优**：pid_fopdt_batch_rollout_score · pid_ipdt_batch_rollout_score · pid_sopdt_batch_rollout_score 5. **候选响应特征提取**：pid_step_response_features 6. **控制性能与过程能力评估**：pid_control_performance_metrics · pid_process_capability_metrics → 新增的 IPDT / SOPDT rollout 补齐了候选仿真阶段对 FOPDT / IPDT / SOPDT 三类模型的覆盖；三个 batch rollout 算子已融合候选特征、候选评分和 best 选择，直接输出每条回路的最优 PID 候选结果。 ## E2E 验证：算子有效且具备 NPU resident 链路价值（Ascend910B3 / node202 真编真跑） - **有效（精度）**：12/12 算子均提供 Python/CPU reference、精度测试或 NPU smoke/benchmark 入口；NPU 输出与 CPU reference 在 float32 容差内对齐。FOPDT 全链路 E2E 覆盖 fit -> tuning_rule -> fopdt_rollout -> performance_metrics，分阶段与 CPU reference 对齐，链路语义自洽。 - **高效（vs CPU 64 线程）**：模型辨识 pipeline 是最明确 NPU 价值点，MatMul + reduce resident e2e 约 28x-180x；三类 batch rollout 在典型候选规模下约 4x-7x；残差诊断、窗口残差、候选特征和指标类算子适合作为 NPU resident 后处理，避免中间轨迹回传 CPU。 - **工程定位清晰**：pid_tuning_rule_batch 算术强度较低，不作为单独性能卖点，但它支撑 E2E 中“模型参数 -> PID 候选”的 device 侧候选生成阶段；评估类算子推荐挂在 NPU resident 流水线后端使用。 ## 主要改动 - 9 个新增正式算子目录，均包含 op_host / op_kernel / examples / tests / docs / README 等标准交付件结构。 - 3 个前序 *_basis_gemm_fit 模型辨识算子作为基础能力保留，并补充 benchmark、README 和文档说明。 - common/ 提供 CPU / NumPy reference 与共享辅助实现。 - e2e/ 提供全链路验证驱动，包括 e2e_perf、e2e_orchestrator.py 和 build_e2e.sh。 - 顶层 docs/ 收敛为正式交付文档：design.md、test_report.md、pid_operator_catalog_by_purpose.md。 ## 验证环境 Ascend910B3，CANN toolkit，g++ 10.3.1 See merge request: cann/mat-chem-sim-pred!21 | 1 个月前 | |
新增 Reformer LSH 桶排序算子 Co-authored-by: aliutec<aliutec@163.com> # message auto-generated for no-merge-commit merge: !30 merge feature/reformer-lsh-bucket-sort into master 新增 Reformer LSH 桶排序算子 Created-by: haikuo Commit-by: aliutec Merged-by: cann-robot Description: 变更概述 本 MR 新增 ReformerLshBucketSort，用于精确替换 Reformer LSH attention 中的两次通用排序。算子输入确定性的“桶编号 + token 位置”编码，同时输出： - 稳定排序后的 key； - 排序后位置到原位置的正向 permutation； - 从排序结果恢复 token 原顺序的 inverse permutation。 该算子替换 reformer-pytorch 1.4.4 中由 TSLib Reformer encoder 调用的 sort_key_val 与 inverse-sort 热点。它不替换 attention score、softmax、 value aggregation 或预测头，不改变 Reformer 的模型结构和预测语义。 ## Native、TorchAir 与自定义算子三路审计 当前 TSLib 源码在 hash 路径中创建 CPU torch.Generator，会阻断官方模型的 fullgraph 捕获。TorchAir 审计恢复了上游 torch.randn(..., device=npu) 的 NPU 随机旋转表达，不改变 hashing、sorting、inverse sorting、attention、 模型权重或输入。 | 测试形状 | Native eager，非 TorchAir | 兼容 TorchAir | ACLNN 自定义算子 | 判定 | |---|---:|---:|---:|---| | B4/L96 | 4.316 ms | 3.008 ms | 非目标提交形状 | TorchAir 最快 | | B16/L96 | 10.291 ms | 11.087 ms | 非目标提交形状 | Native 最快 | | B32/L96 | 18.088 ms | 32.048 ms | 非目标提交形状 | Native 最快 | | B4/L336 | 9.039 ms | 9.015 ms | 非目标提交形状 | 基本持平 | | B16/L336 | 28.604 ms | 50.493 ms | 非目标提交形状 | Native 最快 | | **B32/L336** | **55.528 ms** | **99.733 ms** | **17.577 ms** | **相对最快 Native 降低 68.35%** | 六档兼容 TorchAir 图均能正确执行，观察到的最大图模式/reference 误差为 3.40e-5。TorchAir 在最小 B4/L96 档占优，但没有吸收本算子所针对的 B32/L336 排序热点。 ## 算子阶段与完整测试集证据 - B32/L336 可替换阶段：37.2931 -> 0.6023 ms，延迟降低 98.38%， 加速 61.92 倍，三个输出均逐元素一致。 - 同轮三路完整模型：Native 55.5278 ms、TorchAir 99.7328 ms、 自定义算子 17.5769 ms，相对最快 Native 降低 68.35%。 - 独立交付 gate：55.1197 -> 17.5769 ms，延迟降低 68.11%。 - 完整 ETTh1 测试集共 2,857 个窗口：Native 1558.82 ms -> 自定义算子 682.56 ms，延迟降低 56.21%，预测指标保持不变。 完整测试集 headline 使用 Native 作为基线，因为同形状 TorchAir 图在替换前 比 Native 慢 79.62%。同轮三路 68.35% 与独立 gate 68.11% 来自两次独立 测试口径，不进行混算。 ## 对外接口与验证 - aclnnReformerLshBucketSortGetWorkspaceSize； - aclnnReformerLshBucketSort。 交付件包含 Host API、Ascend C kernel、稳定顺序与 inverse 索引契约测试、 独立构建、ACL smoke、输出所有权测试、文档、形状矩阵证据、checkpoint 模型 E2E 以及完整测试集性能证据。 See merge request: cann/mat-chem-sim-pred!30 | 21 小时前 | |
新增第一批 10个 时序预测模型相关 CANN/Ascend C 算子 Co-authored-by: aliutec<aliutec@163.com> # message auto-generated for no-merge-commit merge: !23 merge feature/cann-ops into master 新增第一批 10个 时序预测模型相关 CANN/Ascend C 算子 Created-by: haikuo Commit-by: aliutec Merged-by: cann-robot Description: 摘要 本 PR 新增一批 10 个面向时序预测模型的 CANN/Ascend C 自定义算子，覆盖 Mamba/SSM、Autoformer、Koopa、TiRex/xLSTM、CfC、coRNN、SRU、UnICORNN 和 LTC 等模型或模型族。 这些算子解决两类问题： 1. 将时间维递归、状态扫描或 lag 聚合从框架侧的 Python 循环和多次小算子调用，改为单个 NPU kernel 内部推进，减少 kernel launch、框架调度和中间 Tensor 物化。 2. 补齐框架当前无法在 NPU 上执行的模型路径。Koopa 使用的 torch.linalg.lstsq 会回落到 CPU，BatchSpdInvFp32 将该关键计算替换为全程驻留 NPU 的实现。 除 Koopa 外，本 PR 的性能基线均为同一 Ascend NPU 上的 PyTorch/torch_npu 框架实现，而不是 CPU。进一步补充的 TorchAir fullgraph=True 测试表明：即使与图编译后的框架路径相比，自定义算子在正式 shape 下仍有 1.39x-7.39x 的稳态运行优势。 ## 背景与价值 时序模型中的 scan、递归单元和 lag aggregation 具有明显的前后依赖：第 t 步需要读取第 t-1 步状态。框架通常会把每一步拆成若干独立 NPU 算子，因此一次序列推理可能产生数百到数万次小算子调度。单次计算量不大时，launch、同步、读写中间 Tensor 的成本会超过有效计算本身。 本 PR 将这些具有明确边界的热子图下沉为 Ascend C kernel，使中间状态保留在 kernel 内部或片上缓冲区中，并在一个 kernel 生命周期内完成时间维推进。该方式不改变模型公式和输出语义，模型接入层只需把目标子图替换为对应 ACLNN 调用。 ## 变更范围 text prediction/ProcessControl/TimeSeriesForecast/ ├── README.md ├── CANN_OPERATOR_LLM_PROMPT_TEMPLATE.md ├── PR_DESCRIPTION_first_batch_cann_ops.md ├── docs/ ├── deliverables/ ├── selective_scan_1d/ ├── s6scan_fused/ ├── autocorr_fused_aggregate/ ├── batch_spd_inv_fp32/ ├── tirex_slstm_cell/ ├── cfc_scan_fused/ ├── cornn_scan_fused/ ├── sru_scan_fused/ ├── unicornn_scan_fused/ └── ltc_scan_fused/ 同时更新： text prediction/ProcessControl/README.md ## 性能对比口径 性能数据按以下三种口径分别报告，不混合计算： 1. **历史 eager NPU 基线**：在 Ascend NPU 上使用 PyTorch/torch_npu 原始算子组合表达同一计算，包含时间循环和多次小算子 launch。该结果反映不开发自定义算子时的直接框架路径。 2. **TorchAir 强基线**：使用 fullgraph=True、dynamic=False 对完整框架子图编译，在 warmup 后比较稳态运行时延。首次图编译时间不计入下表运行时延。 3. **Koopa CPU fallback 基线**：torch.linalg.lstsq 当前不支持 NPU，原路径会回落 CPU。该项衡量的是从 unsupported/fallback 到全程 NPU 可执行的收益，不能与普通 NPU framework baseline 混写。 测试环境：Ascend 910B3、CANN 8.1.RC1、PyTorch 2.5.0、torch_npu 2.5.1。 ## 算子与性能总表 | 算子 | 服务模型/模型族 | 历史 eager torch_npu 对比 | TorchAir 或 fallback 强基线 | 精度与执行范围 | |---|---|---|---|---| | SelectiveScan1D | Mamba / SSM | Mamba block 9.02x；模型 validation loop 10.22x | 原表达直接 fullgraph：27.952/20.077 ms，custom 快 1.39x | prediction max diff 1.431e-06，MSE/MAE diff 0 | | S6ScanFused | S6 / Mamba-style SSM | 组件 136.56x；3 层 encoder 44.15x | 原表达缺少 aten.softplus.default converter；等价基础算子改写后 4.372/0.674 ms，custom 快 6.48x | 3 层 encoder max diff 5.22e-08；图基线 diff 4.47e-08 | | AutoCorrFusedAggregate | Autoformer | validation loop 10.06x；聚合子图 28.06x | 原表达缺少 aten.roll.default converter；等价 slice+cat 改写后 4.568/0.618 ms，custom 快 7.39x | prediction max diff 5.96e-08；图基线 diff 7.45e-09，宽动态范围 1.43e-05 | | BatchSpdInvFp32 | Koopa / DMD | 不适用：框架路径无法保持在 NPU | DMD：CPU fallback 4341.75 ms，custom 0.339 ms，12823.56x；Koopa 完整推理：5300.64/8.80 ms，602.19x | DMD max diff 6.80e-08；Koopa prediction max diff 2.38e-07 | | TirexSlstmCell | TiRex / xLSTM | sLSTM cell 14.31x；完整 sLSTM layer 10.46x | 原表达缺少 aten.log_sigmoid_forward.default converter；等价稳定公式改写后 6.318/3.542 ms，custom 快 1.78x | cell max diff 约 1.45e-06；图基线 diff 7.45e-08 | | CfcScanFused | CfC / continuous-time RNN | 组件 84.83x；3 层 encoder 70.26x | 原表达直接 fullgraph：8.090/1.265 ms，custom 快 6.40x | encoder max diff 2.33e-07；图基线 diff 2.38e-07 | | CornnScanFused | coRNN | 组件 56.73x；3 层 encoder 54.15x | 原表达直接 fullgraph：3.579/1.718 ms，custom 快 2.08x | encoder max diff 1.49e-07；图基线 diff 1.04e-07 | | SruScanFused | SRU | 组件 163.48x；3 层 encoder 71.46x | 原表达直接 fullgraph：5.272/0.884 ms，custom 快 5.97x | encoder max diff 1.04e-07；图基线 diff 1.79e-07 | | UnicornnScanFused | UnICORNN | 组件 160.68x；3 层 encoder 100.43x | 原表达直接 fullgraph：3.544/0.521 ms，custom 快 6.80x | encoder max diff 2.68e-07；图基线 diff 1.90e-07 | | LtcScanFused | LTC / continuous-time RNN | 组件 82.44x；3 层 encoder 76.90x | 原表达直接 fullgraph：10.227/4.909 ms，custom 快 2.08x | encoder max diff 2.53e-07；图基线 diff 1.34e-07 | 表中 框架/custom ms 均为同一正式 shape 下的稳态时延。详细 shape、warmup、重复次数和原始结果见 [docs/torchair_first_batch_report.md](docs/torchair_first_batch_report.md) 及各算子的 docs/benchmark.md、docs/test_report.md。 ## TorchAir 结论说明 - SelectiveScan1D、CfcScanFused、CornnScanFused、SruScanFused、UnicornnScanFused、LtcScanFused 共 6 个原模型表达无需改写即可直接 fullgraph=True 成图；custom 相对图模式仍快 1.39x-6.80x。 - AutoCorrFusedAggregate、S6ScanFused、TirexSlstmCell 的原模型表达当前不能直接完整成图，原因分别是缺少 aten.roll.default、aten.softplus.default、aten.log_sigmoid_forward.default converter。 - 为避免使用较弱的 eager 路径作为唯一基线，测试将上述 3 个表达人工改写为数学等价、TorchAir 可转换的基础算子组合。custom 与这种改写后的强图基线相比仍快 7.39x、6.48x、1.78x。 - 因此这 3 组结果不能写成“原模型直接 TorchAir 成图”。框架路径需要额外改写模型表达，自定义算子则直接实现目标语义，接入时只替换为 ACLNN 调用。 - Koopa 不属于图优化问题：底层 torch.linalg.lstsq 本身不支持 NPU，TorchAir 无法把 CPU fallback 自动转换为 NPU 图。 ## 算子实现逻辑 第一批算子主要采用三类实现方式： 1. **时间扫描融合**：SelectiveScan1D、S6ScanFused、CfC/coRNN/SRU/UnICORNN/LTC 将时间步循环放入单个 Ascend C kernel，状态在 kernel 内持续更新，避免每个时间步重新 launch 一组 NPU 算子。 2. **lag 聚合融合**：AutoCorrFusedAggregate 在一个 kernel 中完成相关性筛选、lag 权重计算和时移聚合，避免框架侧反复执行 roll/gather/reduce。 3. **不支持路径替换**：BatchSpdInvFp32 利用批量 SPD 矩阵求逆替换 Koopa/DMD 中会回落 CPU 的最小二乘关键路径；TirexSlstmCell 将 sLSTM 的门控、稳定化和状态更新合并执行。 每个算子的公式、输入输出、tiling、GM/UB 数据流和误差说明均记录在对应的 docs/algorithm.md 与 docs/api_reference.md 中。 ## 交付件完整度 10 个正式算子均提供以下核心交付内容： - CMakeLists.txt、README.md - op_host/、op_kernel/ - docs/algorithm.md、docs/api_reference.md - docs/benchmark.md、docs/test_report.md - examples/、tests/ - 按算子构建方式提供的 msopgen 配置、构建脚本或直接 CMake/host API 接入文件 项目级补充交付件包括： - TorchAir 第一批统一报告和原始结果 JSON - 第一批 10 个算子合入评审材料与逐页讲稿（Markdown） - CANN 算子开发规则、SCA 排查经验和 LLM 研发提示词模板 ## 验证情况 - 10 个算子已在 Ascend 910B3 完成 CMake/msopgen 构建、ACLNN runtime、正确性和 benchmark 验证。 - 9 个可由 torch_npu 表达的算子完成 eager NPU 对照；其中 6 个完成原表达直接 TorchAir fullgraph，3 个完成 converter 缺失确认及等价改写后的 TorchAir 强基线。 - Koopa 完成 CPU fallback、DMD 子图和完整模型推理对照，证明自定义算子消除了 NPU 不支持路径。 - 本地完成 Python 语法、JSON 解析、选择性扫描单测及 git diff --check。 本地检查命令： bash python -m compileall -q prediction/ProcessControl/TimeSeriesForecast python -m pytest prediction/ProcessControl/TimeSeriesForecast/selective_scan_1d/tests/test_selective_scan_1d.py -q git diff --check CANN 环境构建示例： bash source /usr/local/Ascend/ascend-toolkit/set_env.sh cd prediction/ProcessControl/TimeSeriesForecast/<op> rm -rf build cmake -S . -B build -DCMAKE_BUILD_TYPE=Release -DSOC_VERSION=Ascend910B1 cmake --build build -j 2 带 msopgen 的算子可按各目录 README.md 或 docs/api_reference.md 重新生成 ACLNN 包，并运行 tests/ 下的 probe、模型适配或 benchmark 脚本。 ## 结论 本 PR 的价值不只是“把 CPU 代码移到 NPU”。其中 9 个算子是在同一 NPU 上，相对 eager torch_npu 或 TorchAir 图模式减少框架拆分和调度开销；Koopa 则补齐了框架当前不支持、必须回落 CPU 的关键计算。这一批 10 个算子均具有明确模型入口、可复现性能数据、正确性验证和完整交付目录，可作为后续时序模型 Ascend 适配与算子扩展的基础。 See merge request: cann/mat-chem-sim-pred!23 | 25 天前 |
工业过程控制算子（Process Control）
本目录面向化工、能源、材料制造中的工业过程控制场景，聚焦模型辨识、控制器整定、在线预测与优化调度等任务。
当前算子
| 方向 | 算子/模型 | 状态 | 说明 |
|---|---|---|---|
| PID 模型辨识 | PIDModelFit | Ascend C 原型 | 面向 FOPDT/IPDT/SOPDT 低阶过程模型的多回路、多候选并行辨识 |
| 时序预测模型 | TimeSeriesForecast | P0 已迁入 | 面向 SSM/Mamba、Autoformer/FEDformer 等预测模型的高价值 fused operators |
典型场景
- 批量回路整定：一次性对装置中多条温度、压力、流量、液位回路进行候选模型筛选。
- 在线自整定：滚动窗口数据到达后，快速刷新过程模型参数，为 PID 参数整定提供基础。
- 仿真平台评估：在工艺仿真、数字孪生或控制策略搜索中，对大量候选参数进行批量打分。
- 在线时序预测：针对 torch_npu/PyTorch 框架路径中无法高效表达的 scan、autocorrelation 和频域分解子图提供 fused operator。