本文へ移動
cccskills
無料GitHub で公開

perf-gate

共享 Ascend NPU 上的**性能验收标准**:判定"某优化到底有没有效、有多少效",并规定 **只有验收态结果才能写入总览表**。分双态:**探索态**(平时特性分析:不展开、 允许少步/单次,产物必须标 `[探索]`、不得进总览表)vs **验收态**(入库:同窗 ≥N 复现、按 window-ab-protocol 口径出数)。当用户问"这个优化有多少收益 / 是否有效 / 要不要采纳 / 为什么变慢了""A-B 一下""同窗对比""测 3 次取平均""把数据对齐到同一窗口" "数字对不对""是不是我眼花了",或需要在多卡共享机器上给出性能结论、刷新优化总览报表、 复核别人给的加速比时使用;即使用户只说"帮我确认下这个改动值不值"也应触发。 核心口径:同窗 A/B 是唯一权威(跨窗口绝对值不可比)、A/B/A 漂移校正、窗口内自带基线、 三次证明(HTTP 200 + 字节数 + 日志行)、产物 md5 与关键张量 dump 双证据、噪声地板内 不下结论、profiling 三张表统一到同一窗口;并覆盖 md5 门禁的盲区(忠实度对照)、 共享机器纪律与门控回退纪律。

インストール方法を見る

含まれるファイル(7)

  • SKILL.md21.6 KB
  • evals/evals.json21.0 KB
  • references/evidence-toolbox.md11.4 KB
  • references/measurement-discipline.md49.3 KB
  • references/window-ab-protocol.md6.3 KB
  • scripts/check_gate_script.py11.7 KB
  • scripts/engagement_check.py7.7 KB

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

性能验收标准(共享 NPU 机器上的测量口径)

在共享的多卡 NPU 上做性能结论,难点从来不是"跑得快不快",而是这台机器上的数字能不能代表配置 差异。本标准回答两件事:一个优化的收益算不算成立,以及什么样的数字才允许写进总览表。 每一条都来自真实踩坑:跨窗口对比得出的"收益"是假的、日志里的 t= 会被 profiler 污染、 md5 一致被当成"没问题"却漏掉了产物本身是坏的。目标只有一个:让报表里的每个数字都能被第三方复核。

定位与双态(先把"在探索"还是"在验收"分清)

态何时允许产物写法能否进总览表
探索态平时特性分析、方向试探、快速识别哪条路值得投全量不展开(少步/单次/单臂/N=1 即可),以首步耗时这类同口径辅助量做筛选产物与结论行必须标 [探索],并注明样本数与窗口不得进总览表(只作识别与筛选依据)
验收态收益要入库、要对外宣称、要写进总览报表必须同窗 ≥N 次复现(按 references/window-ab-protocol.md 的 N 与门槛),必要时 A/B/A给口径(窗口/卡组/步数/权重)+ 判据(地板、门槛)+ 单值可以(本条是入库的唯一入口)
  • 只有验收态结果才能写入总览表:探索态的读数可以在过程记录/细分材料里出现,但不得当作 收益列进主表,也不得用"我试过好像快了一点"替代验收。
  • 态要显式标注:产物里没有 [探索] 标注的少步/单次读数,一律按"未验收"处理。
  • 升态(探索 → 验收)的三件事:补齐同窗控制臂、跑到规定复现次数、把三证与 md5/dump 证据备齐。

何时用

  • 要判定一个优化"是否有效 / 有多少收益 / 要不要采纳",尤其是收益落在几秒甚至几百毫秒量级时;
  • 用户反问"为什么变慢了""是不是我眼花了""这个数字对不对"——先别解释,先查口径;
  • 要把多天的结论合并进一张总览表,或复核同事给的加速比(列契约见 ../model-auto-optimization/references/report-contract.md);
  • 任何需要"跑一次就下结论"的场合(共享机器上重跑很贵,越贵越要一次做对)。

一条铁律:同窗 A/B 是唯一权威

跨窗口的绝对值不可比(这是方法层面的结论,不随环境变化)。下面引用的漂移量级是同环境口径下的观测(8 卡 15 s/4 步),换机器、换负载、换形状都要重新测一次地板再下结论: 同一台机器上换个时段、换个体温/邻居负载,同一配置就能漂出与整段收益同量级的差距; 这比绝大多数优化的真实收益还大。同环境实测的实证:

窗口臂e2e(热态均值)
窗口 A交付档(旧解码器)基准(本窗分母)
窗口 B官方解码器(同窗对照:旧解码器)与窗口 A 同量级,略高
窗口 C交付档(新解码器 + 修复)比窗口 A 略慢(同量级)

直接把窗口 A 与窗口 C 的绝对值相减、说"变慢了"是错的。正确做法是分解:

窗口 C − 窗口 A = 总差
  = forward 漂移(跨窗口)      + 大头     ← 与配置无关,换窗口就会有
  + 解码器结构性代价(同窗实测) + 次大项   ← 这才是"配置差异"
  + 交付/噪声                  ± 小项     ← 落在噪声内

分解的算法:拿每个窗口自己的阶段账(编码/去噪/解码/forward),逐项相减;能对上就是漂移, 对不上的部分再去找结构性原因。只有同窗口内的差值才能写进报表当收益。

推论

  • 每个窗口必须有自己的控制臂;不要用历史窗口的基线当分母。
  • 跨窗口数字只能用于"量级参考",必须在报表里显式标注。
  • 单臂内也会漂:同环境实测同一臂逐请求 diffuse 逐次单调爬升(6 个请求,逐次 +0.1 s 量级), 另一处跨窗口 diffuse 也整体抬升、漂移量级更大。所以"跑一次就下结论"只在差值远大于漂移时成立。

A/B/A:同窗对照也分辨不出时的唯一出路

当同窗对照的差值落在噪声里,别急着写"不可分辨"就收工——用 base → arm → base 夹一次, 把前后两个 base 取均值当控制,抵消窗口内的单向漂移:

base_1 = B   arm = A   base_2 = B(同口径复测)
控制均值 = (base_1 + base_2)/2
净差 = arm − 控制均值 = 负值(arm 更快)  ← 这才是可写进报表的收益

本例中"同窗直接对比"给出的两个值几乎相同(差值落在噪声内,判不可分辨), 而 A/B/A 校正后得到一个稳定的负净差——结论从"没效果"翻转成"有效"。判据、算法与脚本骨架见 references/window-ab-protocol.md。

判定门槛:先算噪声地板,再谈收益

  • 同环境实测地板:e2e 零点几秒量级 / 相对 1% 量级;单请求粒度更差。
  • 差值小于地板 ⇒ 不下结论,写"落在噪声内,需 A/B/A 或更多重复"。
  • 想给"平均"就真的取多次:热态 3 次均值(第 1 次冷启动单独记录,同环境实测冷启动显著高于热态, 混在一起平均会得到无意义的数)。
  • 报告里的"3 次"必须是同一窗口同一次运行的 3 个热请求,不是三次跨窗口重跑。
  • 探索态放宽、验收态不放宽:探索态允许少步/单次(标 [探索]),但一旦要入库, 门槛按本节执行——不许把探索态的读数按验收态写法上报。

每个数字三条证据(三次证明)

任何写进报表的性能数字,必须同时能给出:

  1. HTTP 200(请求确实成功,500/超时不算数据);
  2. 字节数(产物大小,与预期量级一致,能发现"空响应/错误页当成了视频/张量");
  3. 日志行(服务端阶段账或内核计时,能解释这个数字是怎么来的)。

三缺一,这个数字就只是"感觉"。失败案例就在实测里:某次改动后 4 个请求全部 HTTP 500、 产物只有几百字节量级——如果只看 arm 脚本打印的 t= 而不看状态码与字节数,会误判成"跑完了"。

第三证(日志行)要先自证再采信:仪器本身得用负对照证明"它测得到"(故意塞一个已知坏值, 看它是否报出来)。仪器坏了不会报错,只会安静地把"没测到"报成"没发生"。口径与两种互不相干的 仪器交叉验证见 references/measurement-discipline.md §8。

证据强度阶梯(从弱到强)

级别证据能证明什么态
1单次运行 e2e只能证明"这次是这个数"探索
2同窗 A/B 差值配置差异(差值 > 地板时)验收
3A/B/A 校正差值小于地板时的净收益验收
4产物 md5 + 关键张量 dump md5优化是否改变了结果(无损声明)验收
5与独立真值对照(另一个解码器/实现)产物本身是否正确(见下节盲区)验收
6未参与实施的实例独立复核(多 agent 场景:另一 analyst 实例按判据复算,含计数契约与回执指针核对)结论与实施者无关的独立性(防自证偏置)——自证只算自验证,不等于复核验收

复核独立性(多 agent 场景强制):第 6 级的复核者必须未参与该特性实施;角色、交付件 与交接单契约见 ../model-auto-optimization/references/agent-roles-and-handoff.md §2/§3/§6。

最容易骗到自己的三个坑

坑 1:md5 门禁有盲区

"各臂产物 md5 与基线一致 ⇒ 优化无损"——这句话只证明优化没改变产物, 不证明产物本身是对的:如果基线本身就走了一条有缺陷的路径,所有臂都会一致地错。 实测实例:基线与全部优化臂共用同一个预览版解码器,md5 门禁全程绿灯, 但该解码器与真值几乎不相关,交付出去观众一眼就看出"糊"。

补救:另设忠实度对照。拿一个独立实现当真值(实测用完整解码器)跑同一输入,报 MAE / Pearson r。判据示例:官方时间维解码器 vs 真值 MAE 在 0–255 尺度上很小、相关系数接近 1(忠实); 另一预览档相关系数几乎为零、且含大量冻结帧(通过门禁但与真值无关)。 ("产物变了吗"的判据在精度验收标准 accuracy-gate;本节只负责"这个数字算不算证据"。)

盲区的另一半在参与度:md5 一致还可能意味着那条路径压根没跑—— md5 相同 ≠ 路径跑了、md5 变化 ≠ 路径跑了,两者都只能靠生效计数 + 远端文件 hash分开 (判据与三件套证据见 references/measurement-discipline.md §9、../remote-access/references/arm-driver-traps.md)。

坑 2:arm/服务日志里的 t= 会被污染

profiler 采集阶段、并发请求排队、共享机器上的邻居负载,都会让 curl 的 time_total 虚高。 实测实例:某臂日志 t= 被污染(读数为数十秒量级),而服务端阶段账 forward 只有十几秒、请求节拍也在十几秒量级。 判据:把日志 t= 与服务端阶段账/节拍交叉验证,冲突时以服务端为准,并在报表里标注被采样的那次请求。

坑 3:把"占比高"当成"优化空间大"

占比高 ≠ 有收益空间。先看天花板:同环境实测解码只占百分之几,即便做到零成本也只省下零点几秒量级 (落在噪声地板之内);而设备侧主导算子的利用率已经接近 100%(到屋顶线), 真正能动的是"减少工作量/降精度",不是"调 kernel"。给出占比后必须补一句"最多能省多少"。

与"上限"的关系:占比高 + 天花板低时,正确动作是先算上下限账(阶段账闭合到 ±10%), 再判"这次优化有没有把上限抬高"。设备耗时降了而 e2e 没降,不等于优化失败——那是上限提高了、 绑定约束换人了,下一步该去压新约束,而不是关掉这次优化。流程(四步规则 + device = total − host 为何禁用)见 references/measurement-discipline.md §10;点名约束的判据也在那里(§10.3): 从某资源移走的工作必须变成该资源新增的空闲 —— 空闲没等量增长,就说明不是它在卡着你。

共享机器纪律

  • 开工前查占用(npu-smi info、容器内进程表),确认哪些卡是别人的;实测中曾遇他户占卡。
  • 不要并发跑多臂:臂之间会互相污染(集合通信、HBM 带宽、温度)。串行跑,每臂之间留清理时间。
  • 每臂结束显式清理(杀 serve 进程、清锁文件、清端口),否则下一臂会静默复用旧服务, 测到的其实是上一个配置。
  • profiler 采集会显著改变时序:被采样那一次的 e2e 不能计入均值,只用它做阶段/内核归因。
  • 一次运行尽量多带信息(阶段计时 + 关键内核计时 + per-rank 分解),因为重跑很贵。

一次运行要带回来的东西

按这个清单设计 arm 脚本,避免"跑完发现缺一个数,还要再跑":

  1. 健康检查通过时间、每请求 HTTP 码 / t= / 字节数 / md5 —— 并写明每个数字来自第几个请求 (先确认日志的每请求行数再切片,否则会把冷请求当基线;见 references/evidence-toolbox.md §4.1);
  2. 服务端阶段账(编码/去噪/解码/forward)逐请求;
  3. 关键子模块计时(如解码器 per-rank 拆分);
  4. 配置指纹:生效的权重路径、关键 env、以及"是否走了降级/回退"的日志行;
  5. 产物落地路径 + 关键中间量(dump md5)。

脚本骨架与判定阈值见 references/window-ab-protocol.md。

入库门:什么数字才允许写进总览表

只有验收态结果才能写入总览表(探索态一律标 [探索] 并留在过程材料里)。入库前逐条自检:

  • 同窗控制臂存在,或已 A/B/A 校正;跨窗口数字只作量级参考且显式标注;
  • 差值 > 噪声地板(否则写"不可分辨"或补 A/B/A);
  • 三证齐(HTTP 200 + 字节数 + 日志行);被 profiler 采样的请求未计入均值;
  • 无损声明有 md5 + 关键张量 dump 双证据,必要时补与独立真值的忠实度对照。

列契约与格式复核(8 列固定契约、可选 序号 列、质量列语义、主表只收已验证有效项、 格式事故清单、数值自洽审计与复核流程)见 ../model-auto-optimization/references/report-contract.md——报表列契约归编排层(L1)单点持有, 本技能只给"数字可复核"的判据;跑 lint 用编排层的 model-auto-optimization/scripts/report_lint.py, 要求 error=0 才算交付。

何时读哪个文件

情况读
要设计同窗 A/B、判定收益、决定是否用 A/B/A、要 arm 脚本骨架与复现次数 Nreferences/window-ab-protocol.md
要采证据、怀疑 t= 被污染、要做忠实度对照、要统一 profiling 三张表references/evidence-toolbox.md
要做交错对照(ABBA)与哨兵翻转、判"差异算不算 bug"前先做数值敏感度校准、要用单测替代端到端、要外推站点/阶段收益、或要按模板上报结论references/measurement-discipline.md
要写/刷新总览报表、复核别人的数字、跑 lint 与表格审计(列契约)../model-auto-optimization/references/report-contract.md(编排层单点)
产物"看着不对"、怀疑是静默错误而不是性能问题../accuracy-gate/references/silent-failure-localization.md(判据不达标 → 排障入口)
要判"优化到底生效没有"——ON 臂要证明走了新路径、OFF 臂要证明没走(生效计数分开报、回退/失败另计)scripts/engagement_check.py(零依赖、离线、--selftest 自证;四项要求与双方向判据见 references/measurement-discipline.md §9)
要交付一个验证/门禁脚本(gate、校验器、对照脚本)作为判据——它属于哪个平台、有没有跑通过一次、路径是不是写死的scripts/check_gate_script.py(零依赖;检查平台归属/可运行自证/路径可解析,显式列出无法机检项;--selftest 自证;判据见 references/measurement-discipline.md §11.1)

门控纪律:每个新特性都要能"关回去"

在共享机器上做优化,可回退和可测同样重要。约定:

  • 新特性一律 env-gated + 默认 OFF:默认路径必须与改动前逐字节一致, 这样"没开"就能自证不是它导致的差异;
  • 门控还要可逐请求翻转(读环境变量或哨兵文件,且每次调用重新求值,而不是启动时读一次) —— 这是交错对照(ABBA)能成立的前提,见 references/measurement-discipline.md §2;
  • 提供一行回退(一个 env 或一行注释切换),并用注释写清楚回退值——半年后要复现历史产物时, 这一行就是唯一的线索;
  • 改动前备份原文件并记录 md5,保证一键回退;不要改共享库(别的会话可能依赖它), 需要时用附加库方式加载新算子;
  • 回归验证:改动期间反复跑基线路径,确认其输出 md5 恒定 —— 这是"门控未误伤既有路径"最有力的证据;
  • 采纳后把"默认值 + 回退开关"写进报表的说明列,让读者知道怎么关掉它;
  • 反过来,无效的改动要撤掉:实测中有两个补丁被证明与旧路径逐位等价 (假设被证伪),它们被显式回退,只保留真正有效的那个——否则树里会沉淀一堆"看起来在起作用"的开关, 下一个人无法判断哪个才是真的。

与既有技能的边界

  • model-auto-optimization:编排层(阶段推进与验收收口,持有报表列契约与 lint)。本技能是它的 性能验收口径支撑:当它要写"收益多少/是否采纳/能不能入库"时,按本技能的窗口、态与证据规则来; 本技能不负责决定流程走到哪一步。
  • benchmark-dev / profiling-collect / profiling-analyze:分别负责"怎么把 benchmark 跑起来" 与"怎么采/怎么读 profile"。本技能负责判定这些数据的可比性(同窗、漂移、污染、噪声地板), 以及最终入库的门槛。
  • accuracy-gate(精度验收标准)的 accuracy-gate/references/silent-failure-localization.md(排障入口): 当"收益"或"一致性"结论出现反常(例如产物 md5 一致但画质明显变差、或某个改动让结果"看着不对")时, 问题可能不是性能而是静默错误,转该入口排查;本技能负责先用 md5 / 张量 dump 确认"到底有没有变"。
  • vae-opt:当收益来自"把解码按卡切开"时,其等价性证明与交换预算由该技能给出; 本技能只负责验收(同窗差值与逐字节证据)。

结论是动态的:记判据,不记死结论

本节里的每个数字都是某次观测(同环境口径:8 卡 Ascend、15 s / 768P / 4 步),不是普适常量; 写进来是为了让你知道"该期待什么量级、该怎么判"。任何一条变了,旧结论就不再成立,必须重测:

会变的轴为什么会推翻旧结论重测方式
硬件 / 驱动 / CANN 或框架版本绝对性能与噪声地板都会变重测地板(同一配置重复跑几次取散布)
形状 / 分辨率 / 步数 / 批大小阶段占比与收益结构都随之变化用真实形状重跑同窗 A/B
并行拓扑与卡数通信占比、瓶颈位置改变重设窗口内基线
窗口 / 邻居负载 / 共享机器漂移可能大于收益本身同窗 A/B(必要时 A/B/A 校正)
权重 / 解码器 / 量化档同一门禁下语义可能不同补与独立真值的忠实度对照
用户裁决(某档冻结、某档不采用)这是决策,不是性能结论记录裁决与出处,不写成"更快/更好"

写结论请带证据卡三件套:口径(机器、形状/步数、窗口、权重)、判据(多大差异算成立、 地板多少)、失效信号(出现什么就说明这条结论过期)。

收尾自检

  • 每个结论都标了态:验收态(可入库)或 [探索](未入库);
  • 每个入库结论都来自同窗对比,或已标注"跨窗口量级参考";
  • 差值小于噪声地板的项,写"不可分辨"或补了 A/B/A,没有硬报收益;
  • 无损声明有 md5 + 张量 dump 双证据;有条件时补了与独立真值的忠实度对照;
  • 每个数字都能给出 HTTP 200 + 字节 + 日志行;
  • 被 profiler 采样的请求没有计入均值;
  • 报表里跨血缘/跨窗口的行都标了口径,lint error=0;
  • 机器的卡已释放、无残留服务。

维护与更新

  • 复核方法:改本文件或口径文件后,用 evals/evals.json 的四类探针自检——①跨窗口相减是否被 拒绝并给出分解;②md5 一致是否被判"只证没变、不证正确";③t= 污染与"3 次必须同窗"是否成立; ④探索态产物是否被判不得进总览表。
  • 失效信号:硬件/驱动/CANN/框架版本、形状/步数/批大小、并行拓扑与卡数、窗口与邻居负载、 权重与量化档任一变化 ⇒ 地板与结论都要重测(见上表)。
  • 同源联动:报表列契约单点在编排层 ../model-auto-optimization/references/report-contract.md(本技能只留"数字可复核"判据与指针); 测量与上报纪律单点在 references/measurement-discipline.md(与 window-ab-protocol.md / evidence-toolbox.md 构成唯一来源);精度侧判据在 accuracy-gate(精度验收标准)。

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

同じリポジトリのスキル

概要と使いどころ

**精度验收标准**:凡是"改动不应改变结果"的场合(等价替换、算子/子模块融合、并行切分、 编译与图下发、拷贝消减),都按本标准判"合格 / 不合格"——等价分层(L1 逐位 / L2 数值门 / L3 有损门)+ 三级验收序(① 同配置重跑逐位 → ② 跨配置数值门 + 产物 md5 不变 → ③ 质量门)+ 判据不达标时的排障入口。当用户说"这个算子能不能换个写法/换个 kernel/等价实现/ 无损替换""替换后结果会不会变""怎么证明逐位一致""结果不对""花屏""尾部塌了" "CPU 跑对 NPU 跑不对",或发现某个 hotspot 占了大头(例如某类算子在阶段里占 90% 以上)想动手时, 都应触发;即使用户只说"这样改有没有把结果改坏""能不能判它是无损的"也应触发。 覆盖:等价分层与判据、满足本标准的实现约定(per-shape 对拍写进实现,把索引/相位/顺序类重写 错误在首次调用抓住)、per-shape 条件性等价(同一改动在不同形状下结论可能不同)、 判据不达标 → `references/silent-failure-localization.md` 排障入口、否决案例的形态学 (换写法未换 kernel / 差异极小仍非逐位 / 等价但 OOM)、以及收益口径的归属(性能数字一律交 `perf-gate`)。 **近义分流**:选量化档 / 特性选档(要不要开量化、开哪一档)→ `dit-perf-opt`; 并行选型(USP / CP / TP 怎么切)→ `dit-parallel-opt`;本技能只判"结果是否被改变", 不负责选档与选型。

日本語の概要は準備中です。原文の説明を表示しています。

Ascend/MindIE-SD152026年10月10日 更新

NPU 图批量下发能力(aclgraph / aclgraph_ex 家族)的开发与调优。覆盖 mindiesd 的 aclgraph_backend:NPUGraph 静态 capture、全局 graph pool、 lazy capture、专用 copy stream + event 管线、shape/dtype 校验、max_entries 驱逐。 当用户需要减少 host launch 开销、静态 shape 大 batch 场景加速、 或排查 NPUGraph replay 输入不匹配问题时使用此 skill。 即使用户只提"批量下发""graph capture""图捕获"而未说 aclgraph,也应触发; pattern/Inductor 融合(default 后端)见 pattern-dev,算子本体见 operator-dev, 本技能只覆盖图批量下发。由 dev-workflow 的编译开发阶段与 model-auto-optimization 的 图下发场景指引加载。

日本語の概要は準備中です。原文の説明を表示しています。

Ascend/MindIE-SD152026年10月10日 更新

MindIE-SD 核心算子(FA/BSA/GMM/MM)性能基准工具链。使用:模型优化(model-auto-optimization 的 S1/S4 选型)中用 mindie_bench 对单算子做实现级实测,按 dtype/量化档/稀疏度/形态对比 选出最优配置(产物:选型证据;稀疏度-性能曲线供 S4 稀疏度选型);开发:benchmarks/ 工具链扩展与新算子接入测试(供 operator-dev / pattern-dev 调用)。 当用户需要对比算子实现选型、新增或修改 benchmark 代码、排查 benchmark 数据异常、 给基准加算子/指标时使用;即使用户只说"benchmark 数据不对""给基准加个算子" "对比下这几个 FA 实现哪个快"也应触发;特性级方案选档请走 dit-perf-opt (本 skill 只做实现级实测)。 由 model-auto-optimization 的 S1/S4 选型场景与 operator-dev 的算子接入验证场景调用, 亦由 dev-workflow 在基准开发时指引加载。

日本語の概要は準備中です。原文の説明を表示しています。

Ascend/MindIE-SD152026年10月10日 更新

MindIE-SD Python 代码格式与 lint 规则。当编写、格式化、lint 检查或审查 MindIE-SD 项目的 Python 代码时使用此 skill。 即使用户只提到"提个MR"或"代码好像有 lint 问题"而未明确说格式化,也应触发;Markdown 格式问题见 markdown-lint,提交/PR 规范见 mindie-sd-community-governance。 通常由 dev-workflow 在编码阶段指引加载。

日本語の概要は準備中です。原文の説明を表示しています。

Ascend/MindIE-SD152026年10月10日 更新

MindIE-SD 仓库开发总入口(侧轨)。当用户进行 MindIE-SD 的任何代码开发工作时使用此 skill—— 包括但不限于写 pattern、改测试、部署到昇腾、跑 benchmark、性能分析、多卡并行、复盘归档。 模型/三方框架自动优化类任务(非本仓代码改动)由 model-auto-optimization 入口承接, 本入口只在优化流程需要新增 pattern/算子/部署代码时承接其指向的开发子任务。 即使用户未明确提到"开发流程",只要涉及 MindIE-SD 代码改动都应触发。

日本語の概要は準備中です。原文の説明を表示しています。

Ascend/MindIE-SD152026年10月10日 更新

分布式并行策略选型与实测(USP / CP 通信掩盖 / CFG / TP/RSP/PP 概览;含拓扑相关选型 (按实测拓扑分域条件化:域内 bulk vs 跨域 head-parallel 翻转)与 AlltoAllV 缺陷绕过)。在 model-auto-optimization 中承担 S3:优先 USP、结合拓扑带宽差异选 CP,少量 step + 多 rank 验证特性开启与掩盖(产物:并行方案 + 多 rank 证据)。当用户需要多卡并行 策略选择、**序列并行形态抉择**(纯 Ulysses vs 复合 AllGather-KV×Ulysses:按 GQA / 跨域带宽 / 形态 plumbing 条件化定胜负)、**并行 × 稀疏叠加**(seam 契约:先汇聚后稀疏、 窗口偏移、块对齐、per-head 掩码;含「稀疏看似生效实则未生效」判定)、通信掩盖调优 (含**掩盖率上限**:1-1/n 何时成立、c/f 决定的真实上限、没生效的排查)、**并行方案 差异归因**(阶段 Δ 分解 / 集合通信按 communicator 归属 / 4→8 卡线性度),或排查多卡 跑不动 / 通信暴露大 / 换卡组 / 端口 bind / HCCL 带宽验证问题时使用;**并收编原并行作用域诊断**: 改了 SP/CP/Ulysses/AllGather-KV 后**不报错但结果没变/性能没变**、或小规模能跑大规模崩 (如 Ascend EE1003 coreDim 超限)时,用本技能证明"改动到底有没有生效"(判别量逐层收窄 + 两侧对照 + 日志≠生效,见 `references/scope-effectiveness-check.md`); 即使用户只说 "多卡跑不动""通信暴露大""为什么没达到 6/7 的掩盖率""CP 和 USP 该选哪个""CP 叠稀疏 怎么不生效"而未说并行,也应触发。特性档位/接口事实见 `docs/zh/features/parallelism.md` /`usp.md`(仓内真源),框架侧开启见 framework-integration; 本技能承载选型决策、monkey-patch 掩盖与多卡诊断实测。 由 dev-workflow 多卡场景触发,亦由 model-auto-optimization 的 S3 阶段触发。

日本語の概要は準備中です。原文の説明を表示しています。

Ascend/MindIE-SD152026年10月10日 更新

Ascend のスキルをすべて見る

このスキルの問題を報告する