[RFC] Support GLM-5.3-Flash RL Training on Ascend 950 NPUs

Open
  • Is something wrong?
#2,495 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
25/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
python
Domain
machine-learning

Research direction

Start by reading scripts/run-glm5.3-flash-300B.sh, the relevant files in docker/npu_patch/, and the model path in slime_plugins/models/. Identify the Ascend 950 software and configuration requirements, then compare operator outputs and gradients with reference implementations. Done means documenting setup and supported versions, completing end-to-end RL iterations, and reporting stability, throughput, memory use, and regression results.

Written by the indexing model from the issue text.

Description

We propose adding native support for GLM-5.3-Flash (300B) RL training on Ascend 950 NPUs, using scripts/run-glm5.3-flash-300B.sh with the same model and training configuration, adapting hardware-specific settings as needed.

The implementation will reuse existing model and training code, keep Ascend-specific changes isolated, and preserve existing functionality and default behavior.

1. Proposed changes

  • Environment installation guide: Document validated software versions, container setup, dependencies, multi-node configuration, and launch instructions.
  • Update docker/npu_patch/: Add or update the compatibility patches required for GLM-5.3-Flash training on Ascend 950 NPUs, documenting their purpose and supported dependency versions.
  • High-performance operators in slime_plugins/models/: Integrate Ascend-optimized operators into the existing model path, with forward and backward support and minimal duplication.

2. Validation

  • Verify operator outputs and gradients against reference implementations.
  • Complete multiple end-to-end RL iterations, including rollout, policy updates, and weight synchronization.
  • Report the tested configuration, numerical stability, throughput, and memory usage.
  • Run regression checks on affected CUDA and shared code paths to ensure existing functionality remains unchanged.

Any required deviations from the baseline training configuration will be documented.

3. Timeline and maintainer feedback

We expect to have an initial PR ready sometime in November 2026, covering the environment guide, NPU patch updates, and initial operator integration.

@zhuzilin, would you be open to merging this support natively into the slime repository? We would appreciate your feedback on the proposed scope, code organization, and testing requirements before preparing the PR.

Dominant language
Python
Stars
8.8k
Forks
1.3k
Avg merge
20h 44m
Merged PRs (30d)
25

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from THUDM/slime

All issues in THUDM/slime

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.