[Oseltamivir]

Follow-up to #4440.

Adds the standalone v6 UE8M0 GEMM reproducer used for the new Huawei 950PR results: a flat int64 Triton quantizer, exact scale expansion and CANN GEMM. Dynamic activation quantization and scale expansion stay inside the queued timer; static weight preparation stays outside. Existing BF16 and FP32-scale FP8 workers are unchanged.

The originating CANN 9.2.1 sweep passed 506/506 cases, including pre/post numerical checks, with separate finite-BF16, exponent-boundary and 4.29-billion-element indexing validation. Published measurements and raw evidence. The packaged runner retains health/idle checks, memory limits, source fingerprints and resumable journals. It does not claim CUDA graph, RNG-byte or instruction parity.

The additional packaged-CLI NPU smoke was cancelled before execution when the instance work was stopped; the 506-case validation above is from the originating measured implementation.

AI model disclosure

Codex prepared the implementation, tests, documentation and PR. The exact deployed model/version identifier could not be verified in this runtime. The measured research code was prepared in earlier Codex work whose exact model/version could not be verified either.

中文

这是 #4440 的后续 PR。封装后的 CLI 额外 NPU smoke 在实例工作暂停时尚未执行，已取消排队；上方 506 用例校验来自原始实测实现。

新增用于 Huawei 950PR 新测量结果的独立 UE8M0 v6 GEMM 复现工具，包含基于 int64 平坦地址的 Triton 量化内核、精确 scale 扩展和 CANN GEMM。动态激活量化及 scale 扩展计入排队执行的计时区间，静态权重准备不计入。原有 BF16 和使用 FP32 scale 的 FP8 路径保持不变。

原始 CANN 9.2.1 测试的 506/506 用例通过计时前后的数值校验，并另行通过有限 BF16 数值、指数边界及 42.9 亿元素寻址校验。测量结果和原始证据见上方链接。复现工具保留健康及空闲检查、内存限制、源码指纹和可恢复日志，不声称与 CUDA graph、随机数逐字节结果或指令行为完全一致。

[claude]

I reviewed this PR and didn't find any bugs. Because it's a large, numerically intricate addition (a new ~848-line queued worker plus a bit-level Triton UE8M0 quantizer) under a CODEOWNER-owned path, a human look would still be worthwhile.

What was reviewed:

• Contract classification in classify_case (rejecting tail K, fp32/static A scale, non-bf16 output) against the plan-semantics and rejection tests — consistent.
• The flat UE8M0 quantizer's exponent/scale bit math, int64 wide addressing, and odd-G scale-padding layout, plus expand_activation_scales dropping that padding — shapes line up with the validators.
• Plan wiring in prepare.py and the campaign dependency-hash fingerprint gated on kind=="ue8m0" — matched between producer and checker.
• Note the device-only quantize+expand+matmul pipeline and its FP64 reference checks cannot be exercised here, so correctness rests on the described CANN run.

Extended reasoning...

All seven changed files are under operatorx/, which .github/CODEOWNERS line 29 assigns to the CODEOWNER hbarclay; the change adds a new "ue8m0" UE8M0 group-128 FP8 GEMM worker, a Triton flat-address quantizer, a test module, docs, and example JSON, and wires the worker into prepare.py and the campaign dependency fingerprint. It touches no auth, crypto, or data-exposure surface — it is NPU benchmarking tooling — so there is no security-sensitive concern, and the contract-validation/scale-expansion/plan-wiring logic is internally consistent with the included tests. The decision is defer rather than approve because the change is large and the numerical kernel/validation code is intricate, the actual device pipeline cannot be run or verified in this environment, and the paths are CODEOWNER-owned, so a human (ideally the owner) should still look despite the clean automated pass.