Activity

1. Dong1017

   added

   area:workbenchCLI workbench: profile, A/B loop, quality gates, evidence reportsCLI workbench: profile, A/B loop, quality gates, evidence reports

   kind:taskBounded delivery task with a delegated sliceBounded delivery task with a delegated slice

   on Nov 3, 2026
2. Bounty-hunter commented on Nov 3, 2026

   

   Bounty-hunter

   on Nov 3, 2026

   Author

   More actions

   补充验证预登记：共享任务能否支持实际工程判断

   关联 #252、#337、PR #338。现有交付已验证接口和两个消费者的运行通路；本次进一步检查一项现实错误与一个固定优化假设，公开保留原版对原版的对照。

   固定输入与条件

   • Runtime implementation: d0ce9d785e1bead9124eed1cf3f6e9f2e0cf05db；不修改运行时、oracle 或任务定义。
   • Task: rmsnorm-cpu，六个现有公开 CPU float32 工作负载、axis=1、原有容差和 epsilon。
   • 三个审核过的本地实现：逐字复制 baseline 的 unchanged；省略 epsilon 的错误实现；使用 axis-1 einsum 平方和避免显式 x*x 中间数组、保留 epsilon 的候选。
   • 额外普通输入冒烟：seed 2026、shape (4,17,9,7)、float32 正态分布乘以 4；使用相同独立 oracle/容差。不按测试结果更换输入。
   • unchanged 和 einsum 各运行 6 个 AB/BA 配对组，每个 comparison 最长 2 分钟，描述性 min_improvement_pct=0；沿用每 case 2 warmups、5 samples。两次比较串行执行，不并行运行本地测试。
   • baseline 与 einsum 独立 CPU profiling；三个实现经过实际 SkillEval retained-artifact verifier。错误实现请求 measure，验证其不能贡献性能指标。
   • 计划摘要与脚本摘要在执行前冻结，见下方附录。输出目录为一次性，不根据结果重复或选择胜出的记录。

   功能通过条件和不满足时的处理

   正确实现通过两条路径；错误实现被完整任务和 SkillEval 拒绝且没有可用性能指标；任务/grader/runtime 与实际输入一致；两次比较完整保留所有逐 case 样本与源码检查；profile 无性能 verdict。任何不满足项保留失败并修正实现或明确限制，不能用改阈值让它通过。

   普通输入冒烟是否漏检、优化候选是否更快均是待观测结果，不是功能通过条件。原版对原版如获得描述性 PASS，原样记录并解释为本次噪声/协议分辨能力的限制。不会从一次 PASS 推导实际收益。

   已有 cProfile 的总时长约毫秒量级；能观察调用路径，不能确认内存带宽/分配瓶颈。einsum 是源码检查提出的待检验假设。宿主机不是专用性能隔离环境。本补证不建立统计显著性、服务/GPU/NPU 收益或 agent/skill/search 收益，不改变 #252 范围或关闭状态。

   执行前冻结附录

   • plan SHA-256: 05fdde5a55f7420569fa85168c39b7873e6a4ed207d05940de5622ab9933b51e
   • probe SHA-256: 317285d0534f9935d06e1fc488ef35c56a76ab7cba2c2423e5a73ba09799ebc7
   • replay helper SHA-256: 6d7670a62203676de519e893ca5abfaa1d1de6fca94b2b9e136c30382f8959cd
   • 独立动作超时 25 秒；复用 helper 的 client/trial 上限为 20/40 秒。
   • 独立静态检查后增加了比较结束的质量验证门槛；早期 prepare 只生成计划，没有执行 payload。以下为实际执行版本。

   {
     "unchanged": {
       "task_id": "rmsnorm-cpu",
       "task_sha256": "903359c46cbbd4059325c2807532449d12beb3eec9931471c84510ba035b1677",
       "grader_sha256": "e12a40fd37d402668a48f5adacbada6ce864e6aadfa882862f35f767e838b4b0",
       "candidate_sha256": "c7bc1a3f3ec2e2396a0b2788d1f7b21c059341a7853effaf6f7131c81da292aa",
       "runtime_sha256": "2141480b7ee5ecc2ccc6bd0032db5c6cd6816403a8f2e790abb187e41b1ab844"
     },
     "einsum": {
       "task_id": "rmsnorm-cpu",
       "task_sha256": "903359c46cbbd4059325c2807532449d12beb3eec9931471c84510ba035b1677",
       "grader_sha256": "e12a40fd37d402668a48f5adacbada6ce864e6aadfa882862f35f767e838b4b0",
       "candidate_sha256": "8f29ea405865f4493775ca809e37c0dd7f054dbb2b203e6290975b2e9e41b471",
       "runtime_sha256": "2141480b7ee5ecc2ccc6bd0032db5c6cd6816403a8f2e790abb187e41b1ab844"
     },
     "no-eps": {
       "task_id": "rmsnorm-cpu",
       "task_sha256": "903359c46cbbd4059325c2807532449d12beb3eec9931471c84510ba035b1677",
       "grader_sha256": "e12a40fd37d402668a48f5adacbada6ce864e6aadfa882862f35f767e838b4b0",
       "candidate_sha256": "9b78a97381b4e5775af022934ea504f6eb6269915adcfb5ffc580fc68693f046",
       "runtime_sha256": "2141480b7ee5ecc2ccc6bd0032db5c6cd6816403a8f2e790abb187e41b1ab844"
     }
   }
3. Bounty-hunter commented on Nov 3, 2026

   

   Bounty-hunter

   on Nov 3, 2026

   Author

   More actions

   补充对照已按上方预登记执行一次，结果随 PR #338 的提交 c06b72555d4643df133c59fe7cead5a91e7b86f5 保留。

   • 功能用途得到实证： 省略 epsilon 的 RMSNorm 通过预定普通输入冒烟，但被完整共享任务和实际 SkillEval verifier 一致拒绝，六项断言失败，测量没有可用指标。
   • 两个正确实现通过： 原版及 einsum 候选均通过两条路径，两个 Workbench 比较结束的质量检查也通过。任务/grader/runtime 与实际输入一致，八项功能检查全部通过。
   • 可靠性能排序尚未通过： 两个比较均原样保留 FAIL；原版对原版的报告 improvement 为 -50.52%，einsum 为 -76.95%。相同源码已有很大计时差异，不能把这些数值解释为稳定的优化或退化。保留原版，不采用 einsum，不重跑挑选结果。
   • 全部 720 个计时样本和两份 CPU profile 已公开；profile 支持调用路径检查，未确认内存瓶颈。完整本地命令和日志仍保留。

   对照方案、结果和复现命令 · 原始汇总及全部样本

   Issue 正文已保留计时稳定性未完成项。运行时、oracle 和任务定义未修改；不宣称 agent/skill/search 收益或 GPU/NPU/服务收益。原始数据一致性已独立核对，本地 Ruff 与 diff 检查通过；新提交 CI 单独记录。
4. Bounty-hunter

   changed the title [-]task: validate shared engineering tasks through Workbench and offline SkillEval[/-] [+]task: connect shared tasks to RSI and verify their use[/+] on Nov 3, 2026
5. Bounty-hunter

   changed the title [-]task: connect shared tasks to RSI and verify their use[/-] [+]task: integrate shared tasks into RSI and validate the optimization flow[/+] on Nov 4, 2026
6. Bounty-hunter commented on Nov 4, 2026

   

   Bounty-hunter

   on Nov 4, 2026

   Author

   More actions

   NPU 试点：执行前固定的验证计划

   用户已明确将当前试点改为 NPU 跑通。本轮从 rmsnorm-npu affine RMSNorm 开始，替代“CPU 试点优先”的实施顺序；已有 CPU 结果只作为历史软件控制。四子项仍按选题、契约、题包、接入分工，PR #338 保持 Draft。

   待测源码：6308268fc6d1fbf90e9ab97b5da8af79152f39ea。任务与实现见 rmsnorm-npu，流程与边界。P2 canonical-loader 修复已在 00c41b24 纳入，等待新提交的 Linux 控制及复审；不改写原 reviewer 的 CHANGES_REQUESTED。

   已确认与待执行

   已在有效单卡预约下完成 API 探测：Ascend 910B1、Python 3.12.13、torch 2.10.0+cpu、torch_npu 2.10.0.post4；融合输出设备为 NPU，float32 数值探测正确，已有真实 RmsNorm device trace。最后调用探测脚本中不存在的 key_averages 方法导致该次脚本退出 1，故不能将它记为完整试点通过；正式 adapter 直接解析真实 hardware trace，不使用该方法。更早的容器用户名初始化失败同样保留，不计入性能数据。

   下面才是完整资格实验，当前尚未执行，结果另行追加。

   冻结范围和门槛

   • 单张预约 NPU，二维 contiguous float32，compute(x, weight, *, eps)；非全 1 权重和独立 scalar double/math.fsum oracle。
   • manifest 固定 5 个基础 case；decode [1,4096]、prefill [64,4096] 为计时 workload，另有 zeros/large/tiny 正确性边界。每计时 case 10 次预热、25 次变化输入采样；输入、权重、oracle 和拷贝在计时外。
   • 主指标为设备同步的 eager 完成调用延迟，包含 Python dispatch 与完成同步；不是纯 kernel 时间。profiling 单独运行，必须存在真实 Ascend Hardware kernel 事件，不计为速度分数。
   • baseline 和既有 fused reference 均需所有数值、shape/dtype/device、输入与权重保持检查通过。zeros、漏 epsilon、漏 weight、错误轴、原地改输入 shape、旧输出 replay 六个错误控制必须失败且没有可用性能 metric。
   • Workbench A/A（同码/no-op）和 baseline→fused 各 4 对 AB/BA。各 workload 的 A/A 两臂中位数差绝对值须 ≤10%，且不能越过同一 10% 收益门槛；最终 correctness validation 必须通过。
   • fused reference 只有在两个 workload 分别达到 ≥10% 的中位数改善、Workbench 对应比较通过、上述全部正确性/无收益控制通过时才记为本轮软件资格通过；否则记 INCONCLUSIVE 并保留所有数据，不删除慢样本或事后放宽门槛。
   • 所有 action、trial 与 final validation 的实际环境、源码/task/grader/runtime identity 必须一致并匹配执行前 freeze。运行时限 20 分钟、排队上限 5 分钟；单动作 timeout 180 秒，每个 Workbench 比较预算 8 分钟。

   复现入口（应由已有资源调度器包裹，路径使用本地环境值）：

   python -m tools.npu_benchmark_validate \
     --repo <checkout> --output-dir <new-evidence-dir> \
     --repetitions 4 --min-improvement-pct 10 --max-aa-difference-pct 10 \
     --max-minutes 8 --timeout-seconds 180

   冻结计划、裁判、源码、逐次样本、profile、Workbench report 和错误控制均保留。该实验是预先选定的作者控制；不声称 Agent 自主发现新 kernel、真实 skill 收益或服务端到端收益。正式 SkillEval NPU 产物隔离仍未建立，CPU sandbox 不替代它。维护者范围接受与项目验收另行记录。
7. Bounty-hunter

   changed the title [-]task: integrate shared tasks into RSI and validate the optimization flow[/-] [+]task: run and validate the NPU optimization workflow[/+] on Nov 4, 2026
8. Bounty-hunter

   changed the title [-]task: run and validate the NPU optimization workflow[/-] [+]task: connect engineering tasks to existing Agent execution and evaluation[/+] on Nov 4, 2026
9. Bounty-hunter commented on Nov 5, 2026

   

   Bounty-hunter

   on Nov 5, 2026

   Last edited by Bounty-hunter

   Author

   More actions

   本次根据用户明确要求，将此前保留在本地的复杂双 NPU MoE 任务与六组真实 Agent 实验发布到现有 Draft PR #338。这是历史实测的公开归档和评测入口整理，不是新增设备实验，也不等同于本 Issue 的统一接入验收。

   执行前冻结身份与本次发布身份：

   • 历史 InferRSI source: 6ed93bb41f7db9dafb420dcb6f8705f1864bc45c。
   • 原四组计划 SHA256: fdf792c46212b1a31c7b72923847a6c3716d5b435f580688a4115b03653233b7；Astra 追加计划: 3c98fbb3db5b6f3fcdb72c0a7a985fc0eaac83d844f316dd5c4a4d59387f1e1e。
   • 历史 baseline: ee41e4c926a7f0484848012e5bf22a31b3685daa2385c7bfe34a89d75f5568c6；grader: 34f8068e6a9d1fd1a09c8b55107ac42d2f8e6dbc86e16ae4232f3ecc6a24520e。所有候选的原字节身份见发布包的 patch/candidates.csv。
   • 发布提交: 3266e153b2a5c2354576a17d7fbd736505e2b845（已推送）。原始汇总 SHA256: 5507e6f5683acf5d888dddad3e7f6ac42a8ddbe16731cb5ea008bb1a11244227；不改写历史裁判和数据。

   任务与验收范围：两张自动分配 Ascend 910B1，EP=2 MoE 完整 forward（8 个路由专家和共享专家），检查双 rank、只读输入/参数、独立 CPU FP32 oracle、变化输入与边界。原冻结逐元素 atol/rtol 0.03、NRMSE 0.01；三类场景采用成对 AB/BA 完成延迟，逐次取较慢 rank、按 case 中位延迟比计算几何平均。每组 8 轮探索，再对预选有效候选独立测 4 对 final。限定为此任务的正确性/有效测量，不声明模型质量、生产服务收益或通用知识库因果优势。

   六个新会话依次执行：6.1 Sol、5.6 Sol、6 Astra，分别知识库 ON/OFF、均 xhigh。48 轮探索保留 46 次通过及 2 次候选调用失败，6 次 final 全部通过；完整候选、逐轮分数、累计 token、5,568 个聚合计时样本和合并曲线随代码保留。失败和慢轮未丢弃。知识库 OFF 仍然使用 RSI；不是 RSI OFF 对照。

   任务与命令 · 公开结果与限制 · 计划字段提取。公开字段提取不包含私有连接信息、原始会话日志及全部逐 rank 日志；这些省略和独立复核边界已说明。

   历史实验复用既有 external.execute_trial 和实验编排；没有使用本次新封装的 MoE wrapper，也没有使用单算子 TaskPackage/SkillEval NPU 路径。本次 CPU 回放复核全部 52 份成功计分，相关回归通过；新 wrapper 仍待自己的设备回放，统一 Agent/外部工程接入和整轮消耗关联仍属于本 Issue 的未完成工作。#336 继续跟踪题库扩展；#338 保持 Draft，原 RMSNorm 超时 review 仍未解决。不关闭本 Issue，不代替维护者验收。

   发布后软件验证补充：当前 PR head 为 8f3aebd2e1359d11d8bcdd034f5dacedf9a1f12d。Linux CI 的 Python 3.10/3.11 均为 3,688 passed、19 skipped、284 subtests passed；独立 wheel 和 Linux 产物控制均通过，包括实际 detached-worker 清理测试。同步修复了清单数量断言及旧后台进程权限阻断清理扫描的问题。未重跑 NPU，未改动历史任务裁判、候选或测量数据；新便携入口的设备资格仍待独立验证。
10. Bounty-hunter commented on Nov 5, 2026

    

    Bounty-hunter

    on Nov 5, 2026

    Author

    More actions

    三种使用场景：以前怎么做，这次增加什么

    对应总需求 #252、题库 #336 和 Draft PR #338。这里的“原来”指本次工程任务与适配加入前；原来已有 Workbench 的配对比较、通用 external 执行器和 SkillEval 框架，不是从零没有评测能力。

    图中 【本 PR】 表示 #338 已实现但尚未合并；【调用方】 表示由操作者、已有编排或 Agent 显式组织；【待接入】及虚线表示 #337 的后续目标。颜色只是辅助，文字标记才是状态依据。

    场景一：用户让 Agent 优化内置题，例如 RMSNorm 或双 NPU MoE forward

    以前：执行能力已有，每道题的检查和计时需要另外准备、接线。

    flowchart LR
      O1["用户提出优化目标"] --> O2["任务作者准备基线、输入、正确性检查和计时脚本"]
      O2 --> O3["Agent 修改实现"]
      O3 --> O4["调用方把候选和脚本接到已有 Workbench 或执行器"]
      O4 --> O5["查看检查结果与性能，决定继续还是交付"]
      O5 -->|"继续优化"| O3
    

    Loading

    现在：对于已经收录的题，直接复用任务和裁判；Agent 集中修改实现。

    flowchart TD
      N1["调用方选题并固定版本、设备条件和预算"] --> N2["【本 PR】题目提供基线、输入、允许修改范围和验收规则"]
      N2 --> N3["Agent 交付一版候选源码"]
      N3 --> N4{"【调用方】提交候选，选择对应入口"}
      N4 -->|"RMSNorm 单算子"| N5["【本 PR】benchmarks compare<br/>复用已有 Workbench 检查和配对测量"]
      N4 -->|"双卡 MoE 完整 forward"| N6["【本 PR】moe_benchmark<br/>复用已有 external 执行双 rank 裁判"]
      N5 --> N7["返回正确性、性能、失败原因及源码和测量证据<br/>错误或不完整结果不能成为有效加速成绩"]
      N6 --> N7
      N7 --> N8{"【调用方或 Agent】继续修改、保留旧版还是停止？"}
      N8 -->|"继续，保留本轮记录"| N3
      N8 -->|"停止"| N9["交付选定实现和证据<br/>需要独立复测时由调用方安排"]
      classDef added fill:#e8f5e9,stroke:#2e7d32,color:#111;
      class N2,N5,N6,N7 added;
    

    Loading

    实际增加的作用： 不再为每次 RMSNorm/MoE 优化重新写一份题目定义和计时脚本；每版候选用同一依据验算、测量和留证，Agent 可以据此改下一版。两种入口按各自任务契约验收，不是互换的命令。

    • Agent 决定怎么优化；裁判给出“这版是否正确、测得多快”的事实；调用方或已有控制器决定轮数、选优和停止。该 PR 没有新增自动搜索策略。
    • 这些脚本需要显式调用。只说“用 InferRSI 优化”不会保证自动触发它们；task: connect engineering tasks to existing Agent execution and evaluation #337 要补的正是可复用的候选交接及结果/消耗关联。当前 MoE 命令一次评一个候选，不启动 Agent、不自动跑八轮、不采集模型 token。
    • NPU 路径当前接收已审核源码；CPU SkillEval 产物适配只检查正确性，不能代替 NPU 接入。Profiling 是可选诊断，不列为必经步骤。

    单算子入口 · MoE 入口及运行命令

    场景二：用户优化自己的项目，例如 vLLM 某个 forward 或服务路径

    以前：项目自己的测试与 benchmark 已能运行，调用方针对这次任务组织整个过程。

    flowchart LR
      O1["用户指出项目和优化目标"] --> O2["操作者选工作负载、质量检查、指标及基线"]
      O2 --> O3["Agent 改项目代码或配置"]
      O3 --> O4["运行项目测试和 benchmark<br/>可使用已有 Workbench 或 external"]
      O4 --> O5["本次脚本或人工关联代码版本、结果和会话消耗"]
      O5 -->|"继续优化"| O3
    

    Loading

    #337 完成后的目标：项目不用先进入题库，也能走有明确交付与验收记录的流程。以下虚线部分尚未统一接通。

    flowchart TD
      V1["用户的项目、目标和实际业务工作负载"] --> V2["任务负责人固定基线、质量要求、测试及 benchmark 命令"]
      V2 -.-> V3["【待接入】建立外部任务描述、工作区及候选交付约定" ]
      V3 -.-> V4["已有 Agent 修改实际项目<br/>保留交付的代码或配置版本"]
      V4 -.-> V5["【待接入】将候选交给已有执行器<br/>运行固定的项目检查与 benchmark"]
      V5 -.-> V6["【待接入】关联候选版本、质量与性能、证据、整轮消耗"]
      V6 -.-> V7["调用方或 Agent 决定继续、回退或交付"]
      V7 -.->|"继续优化"| V4
      classDef future fill:#fff3e0,stroke:#ef6c00,color:#111;
      class V3,V5,V6 future;
    

    Loading

    实际增加的作用： 把“这份项目代码、这次验收结果、这轮 Agent 花费”关联成一次可追溯的优化执行，不要求把所有用户目标先做成内置题。

    例如优化 vLLM 的推理路径，裁判可以是固定请求集下的输出质量/回归测试和项目 benchmark；若目标是服务吞吐或延迟，就测对应服务负载。MoE 小题的分数不能替代 vLLM 服务验收。 项目测试是否足以代表目标，需要任务负责人确认；共享工具不能自动发明业务正确性标准。外部项目的统一接入仍未交付，不能把这张目标图当作现成功能。

    场景三：比较不同模型，或同一模型知识库开启/关闭

    以前：已有条件比较框架，但具体 NPU 工程任务的验收接线和整轮消耗关联需要自行补齐。

    flowchart LR
      O1["调用方确定 A/B 条件和共同任务"] --> O2["为此任务准备并接入验收脚本"]
      O2 --> O3["通过已有比较框架或实验脚本分别运行 Agent"]
      O3 --> O4["收集候选、测量结果和会话 usage"]
      O4 --> O5["本次脚本核对口径并汇总效果与代价"]
    

    Loading

    现在：可复用同一题目和候选评测；条件控制、启动会话、循环和 usage 汇总仍由调用方组织。

    flowchart TD
      C1["【调用方】固定任务、裁判、预算和环境要求<br/>选择 A/B 条件并记录实际环境差异"] --> C2["【调用方】分别启动全新会话<br/>A 例如模型 X 知识开；B 例如模型 X 知识关"]
      C2 --> C3["每个 Agent 持续交付候选"]
      C3 --> C4["【本 PR】使用同一任务版本和评测规则<br/>返回各轮正确性、性能及证据"]
      C4 -->|"调用方安排下一轮"| C3
      C2 --> C5["【调用方】从会话遥测采集实际 usage<br/>保留失败、等待和检索等消耗"]
      C4 --> C6["【调用方】按候选和轮次关联数据<br/>汇总优化曲线、累计 token 与独立复测记录"]
      C5 --> C6
      C6 --> C7["比较达到目标的速度与代价<br/>重复实验后再判断条件的作用"]
      C6 -.-> C8["【待接入】把本次实验编排和关联方式<br/>收敛为 #337 的可复用流程"]
      classDef added fill:#e8f5e9,stroke:#2e7d32,color:#111;
      classDef future fill:#fff3e0,stroke:#ef6c00,color:#111;
      class C4 added;
      class C8 future;
    

    Loading

    实际增加的作用： 多个条件消费同一套任务与验收依据，不必让裁判理解条件改变的是模型、知识库还是 indexer。改变什么、如何控制变量和重复几次，由实验调用方决定。

    本次六组 MoE 已完成“新会话 → 8 轮探索 → 独立 final → 曲线及累计 token”的实验级执行，历史上复用了既有 external executor 和当时的实验编排。它们没有运行本次新封装的 MoE wrapper，也不证明 #337 的通用接入已经完成。知识库 OFF 仍使用 RSI；若要测 RSI 整体作用，需要另外定义不使用 RSI 的对照。每条件只有一条轨迹，不能据此下普遍因果结论。

    六组结果、曲线、逐轮改动与限制

    图中的三个角色到底各做什么

    角色	负责什么	交付什么
    任务/裁判作者（#336）	定义需要优化什么、允许改什么、如何判断正确及测量	可复用题目、基线、输入、oracle/项目检查和计时规则
    Agent	阅读目标，提出并实现优化，可按需要调研、profiling、测试	实际候选代码或配置
    调用方与已有 RSI 执行/评测能力（#337 接入）	把候选送去验收，保留结果，并组织下一轮/停止与过程成本关联	每版候选的证据，以及整次优化的结果与代价

    一句话：以前要为这次工程目标自己把“题目、候选和测量”接起来；本 PR 先让已收录题目的验收可以直接复用，#337 再把真实 Agent 交付和整次运行记录接完整。

    状态依据：PR #338 仍为 Draft，代码头 8f3aebd2e1359d11d8bcdd034f5dacedf9a1f12d；Linux 软件 CI 已通过。新 MoE wrapper 的设备回放、外部工程统一接入和原 RMSNorm timeout P2 仍未完成。本说明不变更历史实验数据或项目验收状态。
11. Dong1017

    added

    status:proposedWaiting for the decision named in the status blockWaiting for the decision named in the status block

    on Nov 5, 2026