昇腾底座+SGLang框架，Qwen3-Next Day0首发配置实战：从MoE到注意力机制调优

1. 昇腾 NPU 上跑 Qwen3-Next，Day0 到底卡在哪

Qwen3-Next 是通义团队发布的新一代基础模型结构，核心变化集中在混合注意力机制、高稀疏度 MoE 结构，以及提升推理效率的多 token 预测机制。基于这套结构训练的 Qwen3-Next-80B-A3B，总参数 800 亿但每次只激活约 30 亿，官方给出的定位是：性能接近 Qwen3-32B dense 模型，训练成本却只有后者的十分之一不到，32k 以上长上下文推理吞吐是 Qwen3-32B 的十倍以上。对做长文档、代码库级上下文、Agent 长链路推理的人来说，这个性价比很有吸引力。

但 Day0 首发场景下，真正让人头疼的不是模型本身，而是昇腾 NPU 与 SGLang 框架的协同配置。Qwen3-Next 引入了线性注意力与注意力门控的混合结构，SGLang 需要走hybrid_linear_attn这个专门的 attention backend；MoE 专家路由在昇腾上又依赖 CANN 与 triton_ascend 的算子支持。我见过最常见的翻车点有三个：一是 attention backend 没指定，启动直接报算子缺失；二是tp-size与卡数不匹配，权重切分失败；三是mem-fraction-static给太高，KV cache 还没分配就 OOM。

这篇就按 Day0 首发的实际路径来：先讲清昇腾底座和 SGLang 的版本对齐关系，再给可复制的启动参数与 config 骨架，最后用首 token 延迟和吞吐两个动作验证是否真的跑起来了。适合手里有 Atlas 800I/800T A3（8×64G）或类似昇腾集群、想第一时间复现 Qwen3-Next 推理的开发者。

2. 前置准备：昇腾底座与 SGLang 的版本对齐

Day0 首发能不能一次跑通，八成取决于版本组合。Qwen3-Next 的混合注意力对算子版本敏感，SGLang 的 NPU 分支又和 CANN、torch_npu、triton_ascend 强绑定。下面这套是我实测下来比较稳的组合，你可以直接对照。

设备侧，Atlas 800I/800T A3（8×64G）最小支持 1 卡起，但 Qwen3-Next-80B-A3B 要跑得舒服，建议 8 卡以上，单机 16 die 的配置在首发文档里是主推形态。CANN 安装包从昇腾社区下载，注意 toolkit、kernels、nnal 三个 run 包要版本一致，安装前先--check校验完整性。

# 增加可执行权限，{version} 为版本号，{arch} 为 CPU 架构，{soc} 为昇腾 AI 处理器版本 chmod +x ./Ascend-cann-toolkit_{version}_linux-{arch}.run chmod +x ./Ascend-cann-kernels-{soc}_{version}_linux.run chmod +x ./Ascend-cann-nnal_{version}_linux-{arch}.run # 校验安装包一致性与完整性 ./Ascend-cann-toolkit_{version}_linux-{arch}.run --check ./Ascend-cann-kernels-{soc}_{version}_linux.run --check ./Ascend-cann-nnal_{version}_linux-{arch}.run --check # 安装 ./Ascend-cann-toolkit_{version}_linux-{arch}.run --install ./Ascend-cann-kernels-{soc}_{version}_linux.run --install ./Ascend-cann-nnal_{version}_linux-{arch}.run --torch_atb --install # 设置环境变量 source /usr/local/Ascend/ascend-toolkit/set_env.sh source /usr/local/Ascend/nnal/atb/set_env.sh

SGLang 走社区源码安装，NPU 扩展在python[srt_npu]里：

git clone https://github.com/sgl-project/sglang.git cd sglang pip install -e "python[srt_npu]"

triton_ascend 和 BiSheng toolkit 是昇腾侧的两个关键依赖，前者提供 Triton 算子在 NPU 上的编译能力，后者是编译器工具链。安装顺序建议先装 BiSheng，再装 triton_ascend 的 whl，最后 source 环境变量：

pip install triton_ascend-3.2.0+gitb0ea0850-cp311-cp311-linux_aarch64.whl ./Ascend-BiSheng-toolkit_aarch64.run --install source /usr/local/Ascend/ascend-toolkit/latest/bisheng_toolkit/set_env.sh

torch_npu 从昇腾官方下载对应 torch 版本的 tar 包，解压后装 whl：

tar -xzvf pytorch_v{pytorchversion}_py{pythonversion}.tar.gz pip install torch_npu-{pytorchversion}.xxxx.{arch}.whl

注意：torch、torch_npu、triton_ascend 三者版本必须严格对应，任意一个错位都可能在加载 Qwen3-Next 的线性注意力算子时报ImportError或undefined symbol。

3. 可复制配置：SGLang 启动参数与 config 骨架

权重从 HuggingFace 的Qwen/Qwen3-Next-80B-A3B-Instruct仓库拉取，建议提前用huggingface-cli download下到本地盘，避免启动时边下边加载导致超时。目录结构保持原样，config.json、tokenizer.json、model.safetensors索引文件都要在。

单机 8 卡 16 die 的启动命令如下，这是首发文档里验证过的形态：

cd /home/sglang # CANN 环境 source /usr/local/Ascend/ascend-toolkit/set_env.sh source /usr/local/Ascend/nnal/set_env.sh # 启动服务 python -m sglang.launch_server \ --model-path {权重路径} \ --host 127.0.0.1 \ --port 6688 \ --trust-remote-code \ --nnodes 1 \ --node-rank 0 \ --attention-backend hybrid_linear_attn \ --device npu \ --max-running-requests 32 \ --context-length 8192 \ --disable-radix-cache \ --chunked-prefill-size 32768 \ --max-prefill-tokens 28000 \ --tp-size 16 \ --mem-fraction-static 0.5 \ --disable-cuda-graph

几个参数值得单独说清楚，因为它们直接决定 Day0 能不能起来：

--attention-backend hybrid_linear_attn是 Qwen3-Next 的命门。这个模型不是纯 softmax 注意力，而是线性注意力与门控注意力的混合结构，SGLang 默认的 flash attention backend 不认识这套算子，必须显式指定 hybrid 后端，否则启动阶段就会在加载模型时抛算子未注册的错误。

--tp-size 16对应 8 卡 16 die 的切分粒度。如果你的机器是 8 卡单 die，这里要改成 8；卡数变了 tp-size 必须跟着变，否则权重切分维度对不上，会报 shape mismatch。

--mem-fraction-static 0.5是给 KV cache 留的显存比例。Qwen3-Next 的 MoE 专家权重占显存不小，首发阶段建议先压到 0.5，跑通后再往上调。给太高会在 KV cache 分配阶段 OOM，给太低则并发上不去。

--disable-radix-cache和--disable-cuda-graph在 Day0 阶段建议都打开。radix cache 在混合注意力结构下的前缀复用逻辑还在适配，cuda graph 在 NPU 上对应的是图模式，首发版本先关掉能避开不少兼容性问题，等基线跑通再逐个打开做性能对比。

--chunked-prefill-size 32768配合--max-prefill-tokens 28000，控制的是长上下文预填充的分块大小。Qwen3-Next 主打 256K 超长上下文，但首发验证建议先用 8192 的 context-length 跑通，再逐步往上加。

config 骨架方面，模型自带的config.json不要手改，SGLang 会读里面的num_experts、num_experts_per_tok、linear_attn_config等字段。你需要在启动脚本层面维护的是一份环境变量清单：

export ASCEND_RT_VISIBLE_DEVICES=0,1,2,3,4,5,6,7 export PYTORCH_NPU_ALLOC_CONF=expandable_segments:True export HCCL_CONNECT_TIMEOUT=1200 export HCCL_EXEC_TIMEOUT=1200 export SGLANG_NPU_MOE_GROUP_SIZE=8

ASCEND_RT_VISIBLE_DEVICES控制可见卡，多机场景下每台机器单独设。PYTORCH_NPU_ALLOC_CONF开可扩展段能缓解碎片化。HCCL 两个超时调大是因为 80B 权重加载和 MoE 通信在首发阶段可能偏慢，默认超时容易误杀。

4. 验证请求：首 token 延迟与吞吐怎么测

服务起来后，日志里看到The server is fired up and ready to roll才算真正就绪。接下来用两个动作验证：一个测首 token 延迟，一个测吞吐。

先发一个最小请求确认链路通：

curl http://127.0.0.1:6688/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "Qwen3-Next-80B-A3B-Instruct", "messages": [{"role": "user", "content": "用一句话解释 MoE 专家路由"}], "max_tokens": 64, "temperature": 0.7 }'

返回里有choices[0].message.content就说明推理链路通了。如果返回 400 或 500，先看服务端日志里的 traceback，八成是 attention backend 或 tp-size 的问题。

首 token 延迟（TTFT）用流式请求测更准，因为非流式会把整个生成时间算进去：

curl http://127.0.0.1:6688/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "Qwen3-Next-80B-A3B-Instruct", "messages": [{"role": "user", "content": "写一段 200 字的昇腾推理介绍"}], "max_tokens": 256, "stream": true }' | while read -r line; do echo "$(date +%s.%N) $line" done

第一个带content的 chunk 到达时间减去请求发出时间，就是 TTFT。首发阶段 8 卡 16 die 上，8192 上下文、32 并发的配置下，TTFT 落在几百毫秒到一秒出头是正常区间，具体取决于 prompt 长度和 prefill 分块。

吞吐用 SGLang 自带的 benchmark 脚本更省事：

python -m sglang.bench_serving \ --backend sglang \ --host 127.0.0.1 \ --port 6688 \ --model Qwen3-Next-80B-A3B-Instruct \ --num-prompts 100 \ --request-rate 8 \ --input-len 1024 \ --output-len 256

输出里的Output token throughput和Total token throughput就是你要的吞吐指标。Qwen3-Next 的卖点之一就是长上下文吞吐，你可以把--input-len从 1024 逐步加到 8192、32768，观察吞吐衰减曲线。如果 32k 输入下吞吐掉得特别厉害，检查--chunked-prefill-size是否给够，以及--max-prefill-tokens有没有成为瓶颈。

MoE 专家路由的验证可以看服务端日志里的 expert 分布统计，SGLang 在 debug 日志级别下会打印每个 expert 被激活的次数。如果发现少数 expert 承担了绝大部分 token，说明路由有偏，这时候要回头检查权重是否完整加载，以及SGLANG_NPU_MOE_GROUP_SIZE是否和实际卡数匹配。

5. 本篇常见错排查

Day0 首发踩的坑基本集中在下面几类，按报错关键词对号入座。

报Attention backend hybrid_linear_attn not supported：SGLang 版本太旧，NPU 分支没合入 hybrid 后端。确认pip show sglang的版本，并从社区 main 分支重装python[srt_npu]。

报undefined symbol或ImportError: libtorch_npu.so：torch 与 torch_npu 版本错位。用python -c "import torch, torch_npu; print(torch.__version__, torch_npu.__version__)"确认两者一致，不一致就重装。

启动卡在权重加载，最后 HCCL timeout：HCCL_CONNECT_TIMEOUT和HCCL_EXEC_TIMEOUT没调大，或者多机场景下 rank 配置不对。单机确认--nnodes 1 --node-rank 0，多机每台机器 node-rank 从 0 递增。

KV cache 分配阶段 OOM：--mem-fraction-static给太高。先降到 0.4 跑通，再以 0.05 为步长往上试，找到不 OOM 的上限。

tp-size 与卡数不匹配报 shape mismatch：--tp-size必须等于实际参与推理的 die 数。8 卡单 die 用 8，8 卡 16 die 用 16，改卡数时这个参数要同步改。

请求返回但输出乱码或重复：--disable-radix-cache没开，混合注意力下的前缀缓存复用了错误的 KV。首发阶段保持关闭，等官方适配说明更新后再开。

MoE 路由报算子缺失：triton_ascend 没装或版本不对。确认pip show triton_ascend是 3.2.0，且 BiSheng toolkit 的set_env.sh已 source。

6. 从跑通到跑好：接入与长期编码的路径

Day0 首发跑通只是第一步。如果你后续要把 Qwen3-Next 接进自己的应用，或者做长期的编码 Agent 场景，建议把 API 层单独抽出来管理。TaoToken 提供了兼容 OpenAI 协议的接入方式，API 地址是 https://taotoken.net/api，你可以在控制台里创建 API Keys 并查看接入文档，把模型对话、coding-plan 这些能力按需挂到自己的工程里。

具体来说，验证模型效果可以直接用模型对话页面快速对比 Qwen3-Next 在不同 prompt 下的表现；需要长期跑编码任务或 Agent 链路，可以看 Coding Plan 的配置方式；接入细节和参数说明都在接入文档里。控制台里能管理 API Keys，ClaudeCodeAnthropic 相关的接入方式也有对应说明。官网入口是 https://taotoken.net/?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content=，从那里进控制台和文档比较顺。

回到昇腾集群本身，跑通基线后建议做三件事：一是把--mem-fraction-static和--max-running-requests做成压测矩阵，找到你硬件配置下的吞吐拐点；二是逐步打开--disable-radix-cache和--disable-cuda-graph对应的优化项，观察首 token 延迟和吞吐的变化；三是把 32k、128k、256k 长上下文场景各跑一轮，Qwen3-Next 的线性注意力优势在长上下文才真正体现出来。这三步做完，你手里就有一份属于自己集群的 Qwen3-Next 性能基线，后面换模型、加卡、调并发都有参照。