Qwen3.5的核心是GDN线性注意力结构，但GDN结构复杂，算子选型与接入方案较为复杂。本文分享昇腾NPU上快速接入高性能算子实践，包括CANN环境搭建、自定义算子编译、PyTorch适配与算子接入示例。文章中提及的算子已合入vLLM最新版本。
背景
Qwen3.5介绍
Qwen3.5是2026年2月发布的原生多模态大模型，该系列采用了和Qwen-Next一致的混合架构，包含了线性注意力与传统注意力。获取长序列的高性能的同时，保持了传统Attention对等的模型表现力。Qwen3.5在MMLU-Pro、IFBench等多项基准测试中超越GPT-5.2和Gemini 3 Pro，并支持最长2小时视频理解、自主操作电脑手机等智能体能力。后续发布的Qwen3.5-Omni更实现原生全模态，在215项任务中达到SOTA。
截止今天，Qwen3.6也已经问世，不过模型结构没有出现大的调整。对于Qwen3.6的使用者而言，这篇文章的经验也是通用的。
模型Highlights
旗舰版Qwen3.5-397B的模型结构如图所示：
Qwen3.5每4层为一个循环，每个循环中包含1个传统非线性层，和3个线性层。非线性层与线性层的区分仅为Attention模块，FFN模块是完全一致的。具体的层数与FFN选型（包含Dense与Moe）依不同的模型小版本有所区别。
线性层将传统的非线性Attention演变成了Linear Attention，打破了长序列下O（n²）的复杂度，其采取的Linear Attention算法是业界最领先的Gated Delta Net（GDN），它融合了Mamba与Delta Net算法，可以兼顾全局衰减的同时，建立单键值替换的逻辑。
FFN层采用经典的MOE结构，专家数多达512，专家小，中间层hiddensize仅1024，每个token选择10个路由专家以及一个共享专家，符合当前的多且小的专家配置演进趋势。10个路由专家的选择算法是朴实的Topk，没有演进新的路由策略。
综上，Qwen3.5给NPU带来的冲击集中在Attention模块的GDN，也是开箱算子适配中最困难的地方。针对这样的痛点，本文整理了一套高性能算子接入的指导。后文中会重点介绍GDN，同时也会简要介绍一下FFN模块的算子选型。
本文的算子已合入vLLM最新版本并使能，版本链接：
https://quay.io/repository/ascend/vllm-ascend?tab=tags&tag=latest，v0.20版本与最新的main版本均包含本文中的算子。
快速使能指导
下图简单描述了复杂的GDN算子、MOE算子与融合算子的替换逻辑（图中未穷举所有涉及的接口）
对于GDN算子，需要替换的是预处理算子Causal_conv1D与6个GDN融合算子。对于MOE算子，除了GmmSwigluQuant有一处简单融合替换外，最值得切换的高性能接口是Dispatch/Combine。
准备工作
CANN开发环境部署
首先需安装CANN开发包，提供NPU算子运行所需的底层驱动与工具链。
推荐使用是社区版8.5.2，总共要下2个run包，这里以A3机器为例（即需要下载A3-ops、toolkit）
下载地址为
https://www.hiascend.com/developer/download/community/result?module=cann&cann=8.5.2
需要找到与你当前机器对应的包
#设置需要安装的路径export INSTALL_PATH=/usr/local/Ascend./Ascend-cann-toolkit*run --install-path=$INSTALL_PATH --full --quiet./Ascend-cann-A3*run --install-path=$INSTALL_PATH --install --quietsource $INSTALL_PATH/ascend-toolkit/set_env.sh
编译自定义算子包
接下来需要安装包含了高性能GDN算子的算子包，此处需要使用三方库fla-npu。
下载地址为
https://github.com/flashserve/flash-linear-attention-npu
# 编译命令，注意--soc=${soc_version}需要指定为当前机器的芯片类型bash build.sh --soc=ascend910_93 --pkg --ops=chunk_bwd_dv_local,chunk_bwd_dqkwg,chunk_gated_delta_rule_bwd_dhu,prepare_wy_repr_bwd_da,prepare_wy_repr_bwd_full,chunk_fwd_o,chunk_gated_delta_rule_fwd_h,recurrent_gated_delta_rule,recompute_wu_fwd# 安装run包./build_out/cann-ops-transformer-custom_linux-aarch64.run
torch_custom框架编译构建
下载并安装对应python和torch版本的最新发行版
https://gitcode.com/Ascend/pytorch/releases/
需要获取26.1 beta及以后的版本
编译torch适配whl包并安装
cd torch_custom/fla_npubash build.sh
算子接入
Qwen3.5中涉及算子众多，基于传统Attention的非线性层与整网耗时占比较小的成熟算子这里不赘述，只讲解一下新结构下的中重型算子。
重点算子列表
推理-Prefill场景/训练-前向场景
推理Prefill与训练前向场景使用的算子相同，共涉及7个融合算子，如下表所示：
推理-Decode场景
训练-反向场景
反向场景中包含较多前向算子，这里只单独提及仅反向涉及的算子
Attention模块-GDN接入实践
在接入GDN算子前，先说明一下我们追求极致性能做的一些小设计。要想获取到完整的性能收益，接入GDN算子需要注意以下两件事情。
模型中传递的默认tensor layout均为定长BSH，变长TND，对GDN来说，读写操作会跨越高N维，导致降低访存效率。GDN算子众多，transpose的开销会低于访存效率降低的代价，因此本篇文章中推荐的GDN算子统一采取了NTD或BNSD的特殊layout。为了减少这样的layout引入的transpose开销，我们在GDN预处理算子causal_conv1D的前反向完成默认layout到特殊layout的转换，所有的GDN算子均使用统一的特殊layout，GDN流程中不存在layout变化。
要想做到更好的tiling，做到更严谨的负载均衡，Ascend C算子的host阶段应拿到cu_seqlen，同时这也可以帮我们拦截掉一些索引错误的问题。因此，Ascend C GDN算子的输入cu_seqlens是list（在host上），而Triton GDN算子都是tensor（device上）。cu_seqlen的物理意义是组batch逻辑，这就意味着45个线性层中所有的GDN算子所需同一份输入。我们需要一开始就在device和host上各存储一份，从而使得每个训练step或每个完整Prefill任务仅做一次h2d。
接入代码示例：
https://github.com/flashserve/flash-linear-attention-npu/blob/main/examples/flash_gated_delta_rule.py
FFN模块-Dispatch/Combine接入实践
Dispatch和Combine算子用于替换Moe层中的AllToAllV通信算子，AllToAllV通信算子涉及H/D同步，导致耗时较长。使用Dispatch、Combine替换后，专家路由结果的处理，下沉到Device上，消除了Host和Device同步开销。经过多个迭代的演进，Dispatch和Combine算子利用了AIV驱动ROCE能力，并叠加了通信数据去重，机内机间流水并行等优化手段，典型场景下，模型吞吐性能提升50%。
Dispatch和Combine算子输入比较简单，模型侧只需将数据x和前级门控网络选择的topk个专家索引expert_ids作为输入，并提供moe专家数moe_expert_num、EP通信域大小ep_world_size、rank ID等属性即可。Dispatch输出数据expand_x、各专家token个数expert_token_nums直接提供给后级GMM。通信算法相关的辅助信息assist_info_for_combine，由Dispatch输出直接透传给Combine，模型侧无需意识。
算子接口参数详细说明、调用示例可参考接口文档：
Dispatch：
https://www.hiascend.com/document/detail/zh/Pytorch/2600/apiref/torchnpuCustomsapi/docs/zh/custom_APIs/torch_npu/torch_npu-npu_moe_distribute_dispatch_v2.md
Combine：
https://www.hiascend.com/document/detail/zh/Pytorch/2600/apiref/torchnpuCustomsapi/docs/zh/custom_APIs/torch_npu/torch_npu-npu_moe_distribute_combine_v2.md
优化结果
在输入规模bs=64，seqlen=1k，num_head=32场景下，重点GDN算子优化效果如下：
耗时平均缩短为原始triton算子的44%。
在输入规模ep64，bs=32，seqlen=1，hiddensize=7k，topk=8场景下，Dispatch/Combine算子优化效果如下：
耗时平均缩短为基线方案的43%。
