Repository navigation
fix(ascend): support 310P model operators and preserve 910C behavior - #1005
Merged
Merged
Conversation
baominghelly
marked this pull request as ready for review
October 22, 2026 08:16
whjthu
approved these changes
Oct 22, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Motivation
The existing Ascend backend encounters unsupported CANN paths and incomplete outputs on 310P model shapes. The changes preserve the existing 910C computation path except for the shared RMSNorm copy optimization, fused RMSNorm address correction, diagnostics, and RoPE chunk bookkeeping. RoPE uses one chunk on 910C.
Changes are split into eleven Conventional Commits so compatibility work, diagnostics, performance work, test corrections, and Ruff formatting can be reviewed separately. No related issue is claimed.
Type of Change
feat— new feature / new operator / new platformfix— bug fixperf— performance improvement (no behavioral change)refactor— code restructuring without behavior changetest— adding or fixing tests onlydocs— documentation onlybuild/ci— build system or CI configurationchore— tooling, formatting, or other non-code changesPlatforms Affected
WITH_CPU)WITH_NVIDIA)WITH_ILUVATAR)WITH_METAX)WITH_CAMBRICON)WITH_MOORE)WITH_ASCEND)WITH_TORCH)Smoke Test Result
Validated tree: commit
e7d34f701235fa63d1d81d6d236d78750eee3eb5, based on master1ca4777610d77e9063fffdb975ab35da8466104d. Both machines use the same source tree, with no tracked source changes after validation. The final commit formats six changed Python tests; their parsed ASTs match the pre-format versions, and the affected regressions are rerun after formatting.Both isolated CMake builds and installs passed with Release
-O3 -UNDEBUG,WITH_ASCEND=ON,WITH_CPU=OFF,WITH_TORCH=ON,WITH_LINKED=OFF,BUILD_ASCEND_CUSTOM=ON, and Python bindings. SoC targets wereAscend310P3on x86_64 andAscend910_9362on the ARM64 910C host. CANN 9.1.0, torch 2.10.0+cpu, torch_npu 2.10.0.post4; Python 3.12.13 and 3.11.15 respectively. Runtime headers/libraries and all build outputs used isolated configured prefixes; existing installations were preserved.Exact validation entry points, with
outset to the corresponding isolated validation directory:The external validation runner disables torch_npu JIT compilation, verifies the loaded extension/library prefix, and restricts 310P collection to native implementation 0 and FP16. It does not filter dtypes on 910C. The runner and logs are validation artifacts, not repository changes.
No FlashAttention module exclusion is used. The former workspace-query abort is fixed; the full native FP16 FlashAttention selection on 310P passes, including the ten single-sequence padding cases and twelve new length/block-table reuse regressions.
Test Results on Supported Platforms
Targeted commands used separate processes per module:
BF16 and general FP32 validation are not claimed for 310P. Its CANN RoPE D=8 limitation remains outside the tested supported model shapes. Only one NPU was exposed per process, so multi-device guard cases skip. The 910C NPU was idle; the 310P NPU was shared with an existing workload and only correctness tests were run for the new attention path. Smoke counts overlap targeted cases and are not added to targeted totals.
Benchmark / Performance Impact
External harness
bench_rms.py: FP16 Q/K RMSNorm pairs with head dimension 128, 16 query heads, 8 key heads, batch 1; input views sliced from[S,4096]. Measure wall-clock call plus stream synchronization, five warmups, twenty samples, report median milliseconds. Output values are checked against FP32 CPU reference.TASK_QUEUE_ENABLE=0, JIT disabled,ASCEND_LAUNCH_BLOCKINGunset. Both source versions use Release-O3 -UNDEBUGand the same runtime dependency. The clean-master baseline builds only native RMSNorm/Python bindings; the candidate is the full isolated validation build including Torch bindings.These measurements support the strided-copy improvement, not an across-the-board latency claim. The contiguous single-token path is 7-15 microseconds slower in this short run; repeated statistical characterization was not performed. No new whole-model throughput claim is made. The PromptFlashAttentionV3 path includes padding/copy overhead and is not claimed as a general speedup.
Notes for Reviewers
git diff --checkpass locally. GitHub Clang Format and Ruff pass for final heade7d34f70.SOC_VERSION=Ascend3103is unsupported by CANN 9.1; the NVIDIA unit job fails before compilation because its build environment rejects the existingtool.scikit-build.sdist.force-includesetting. Neither failure reaches operator tests. The corresponding CMake/packaging configuration is unchanged in this PR. The independently configured 310P3 and 910C builds/regressions above pass; other failed/pending platform CI jobs are not claimed as passes.