[NPU] Add TeleChat4 support with fused mHC backends - #33972
Closed
momaekar1 wants to merge 6 commits into
Closed
Conversation
momaekar1
force-pushed
the
codex/telechat4-mhc-npu
branch
from
August 7, 2026 11:00
ebf9a81 to
d7099a3
Compare
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.
Motivation
TeleChat4-29B uses four mHC residual streams with
hidden_size=3584. On Ascend NPU, the previous Torch decomposition generated many eager operators, synchronization points, and intermediate tensors. The generic CUDA mHC path is not an NPU implementation.This PR adds native TeleChat4 registration and explicit NPU mHC backends while preserving the existing CUDA path. The AscendC backend depends on sgl-project/sgl-kernel-npu#670. If that package is unavailable,
autofalls back to Triton and then Torch.Modifications
TeleChat4Config,TeleChat4ForCausalLM, the TeleChat4 tool parser, and reasoning parser.model_type: telechat4and convert legacyrope_scalingfields to the Transformers v5rope_parametersrepresentation.SGLANG_TELECHAT4_MHC_BACKEND=auto|ascendc|triton|torch;autoresolves as AscendC -> Triton -> Torch on NPU.sglang.kernels.ops.layernorm.mhcimplementation.Checkpoint configuration
The checkpoint
config.jsonmust identify the native class:{ "architectures": ["TeleChat4ForCausalLM"], "model_type": "telechat4" }The released legacy
rope_scalingdictionary is supported. No--json-model-override-argsis required with this configuration.Build and source setup
This setup reuses the existing Torch, torch-npu, and CANN installation; it does not reinstall them.
Minimal TP=2 smoke launch
NEXTN throughput launch
Graph capture, RadixCache, and overlap scheduling remain enabled by omitting their disable flags.
Accuracy Tests
TeleChat4Config/TeleChat4ForCausalLMwithjson_model_override_args='{}'; TP=2 BF16 weight loading and API dialogue smoke completed.pytest -q test/registered/unit/configs/test_telechat4_config.py: 1 passed.pytest -q test/srt/models/test_telechat4_mhc_triton_npu.py test/registered/unit/npu/test_npu_topk_shared_expert.py: 19 passed on Ascend 910B3.Full GSM8K: 1319 questions, dataset SHA256
fb581f0270b25988e071316835842a1c8449f4e27af6fc0f539ef270b987f9ff, 5-shot, temperature 0, TP=2, BF16, concurrency 16, NEXTN steps=3, four draft tokens, Graph/Radix/overlap enabled.Speed Tests and Profiling
Triton and Torch were a same-container/card A/B and had nearly identical NEXTN acceptance (2.9299 / 64.33% vs. 2.9241 / 64.16%). Triton is 2.592x the Torch fallback throughput. The AscendC result came from the existing 0721 integration container, so its 4.882% lead over Triton also includes container/framework differences and is not attributed solely to the mHC kernel.
At 512 tokens,
msprof opmeasured AscendC HcPre at 135.1-136.3 us and HcPost at 48.8-49.3 us. Reproducible kernel microbenchmarks are included in the dependent kernel PR.Checklist
msprofresults.