一个模型在昇腾 NPU 上“能跑”和“跑得快”之间，隔着很长一段距离。vLLM-Ascend 和 LLaMA Factory 已经让大部分主流模型可以在昇腾上开箱推理和微调，但开箱配置追求的是覆盖面：一个新的模型结构出现时，框架往往先用若干通用的小算子把它拼出来，保证结果正确，再慢慢补上融合算子和图模式的支持。于是在 Profiler 的时间线上，经常能看到这样的画面：一次前向被拆成几百个细碎的小算子，每一个都很快，加起来却很慢；NPU 在两次计算之间空等 Host 下发下一个任务；中间结果在显存里被反复写入、读出，真正的计算反而只占一小部分时间。
Qwen3.5 这一代模型让这个问题更加明显。它的大部分层不再是标准的 Attention，而是 Gated DeltaNet 这样的线性注意力，再配合卷积、门控和归一化组成新的结构。标准 Attention 在昇腾上已经有成熟的融合算子，而这些新结构的算子实现还在快速演进，其中往往藏着不少可以挖掘的性能空间。
任务要求
本题希望你通过算子优化等方式，实现至少一个模型（如 Qwen3.5-9B）在昇腾 NPU 上的推理加速和 LoRA 微调加速，并同时满足下面三个要求：
- 推理加速：相较默认的 vLLM-Ascend 框架的开箱1 推理速度，至少有 10% 的加速；
- 微调加速：相较原生的 LLaMA Factory 框架的开箱1 LoRA 微调速度，至少有 3% 的端到端加速；
- 精度无损：优化后的算子不应造成计算精度的损失或结果偏差。
建议通过 MindStudio Insight（结合 Ascend PyTorch Profiler 接口）查看 Timeline、算子耗时统计和 Flame Graph 等信息，自己分析哪些算子值得优化。值得关注的现象包括：耗时占比最高的算子；被拆成大量细碎小算子的计算模式；Host 下发跟不上导致的 NPU 空闲；频繁的 Host 与 Device 之间的同步和数据拷贝；回退到 CPU 上执行的算子；以及图模式没有覆盖到的部分。
优化的手段不做限制：
- 可以适当重构和优化已有算子的实现
- 可以把连续调用的多个算子融合成一个 Fused Kernel，减少 Kernel 下发和中间结果读写的开销
- 也可以实现时间掩盖，例如让 Host 侧的调度、采样和数据准备与 NPU 上的计算互相重叠，减少设备空等的时间
算子实现方式可使用原生的 AscendC 编写，也可以使用 TileLang、PyPTO 等更高层的 Kernel DSL
由于算力预算限制，本题暂时不考虑需要多卡或多机才可进行部署和微调的模型，亦不考虑 MoE 模型等的优化实现。
模型不限于 Qwen3.5-9B，但如果选择其他模型，请说明理由，并确保它在 vLLM-Ascend 和 LLaMA Factory 中都有开箱支持并给出推理和 LoRA 微调的运行基线数据。
本题需要昇腾算力，可以联系管理员获取算力代金券。初始将发放 48 核时的算力券（约 1600 元），每次速度提升达到 1% 时，可以获得等效 24 核时的算力券（约 800 元）。
基线说明
由于 910B4 或 910B2 性能存在一定差距，因此需固定实验环境并记录基线环境：
- NPU 型号及驱动版本
- CANN 版本号
- vLLM-Ascend 版本
- LLaMA Factory 版本
- 测试模型权重与数值精度
- 框架的全部启动参数
推理加速
推理场景下，请记录并固定如下基本情况：
- 固定输入输出长度的分布
- 并发数
- 请求数量
推理我们主要关注吞吐量等性能情况，但请同步记录：
- 吞吐量
- 首 Token 延迟（TTFT）
- 每个输出 Token 的延迟（TPOT）
微调加速
请记录并固定如下基本情况：
- 数据集
- 序列长度
- Batch Size
- 梯度累积步数
- LoRA 的秩和目标模块
需要记录的性能情况包括：
- 每步耗时
- 每秒处理的 Token 数
- 峰值显存
- MFU（Model FLOPS Utilization）
注意，推理和微调加速的所有测量都需要预热，并重复多次取均值
重要提醒
下面这些方式带来的加速不计入本题的成绩：
- 量化、剪枝，或者把数值精度从 BF16 降低到更低的格式。
- 修改基准负载，例如缩短输入输出长度、改变并发数，或者调整 Batch Size、序列长度、梯度累积步数、LoRA 的秩和目标模块。
- 开启基线没有开启的解码特性，例如投机解码。如果确实需要开启，基线也必须在同样的配置下重新测量。
- 计时方式有误，例如没有等待 NPU 上的异步计算完成就停止计时，或者把部分计算挪到计时区间之外预先完成。
- 优化后的 Kernel 在某些输入下悄悄回退到原有实现，却把这些输入计入了加速。
重要加分项：Profiler 分析 Skill
注意，本题推荐使用 Agent 完成探索。本题中的读取 Profiler 数据、定位热点、编写 Kernel、验证正确性、测量速度等环节均有可能有 Skill 化的可能性。如果能完成一个 MindStudio Insight 的 Skill，或者一个用于分析 Profiler 日志的 Skill，会有额外的高额加分。
一次 Profiling 产生的数据动辄几百 MB 甚至数 GB，不可能原样塞进 Agent 的上下文；而 Agent 直接阅读原始的 Timeline 数据，也很难从几十万个事件里看出规律。一个好的 Skill 应该把人分析 Profiler 数据的经验沉淀下来。包括不限于：
- 如何配置采集的范围和选项
- 如何解析和聚合原始数据
- 如何把结果压缩成适合上下文的结构化摘要
- 如何识别“Host 下发瓶颈”“小算子密集”“频繁同步”这类典型模式
- 如何从热点算子回溯到 Python 调用栈和源代码
- 如何对比优化前后的两份 Profiling 数据。
可以基于 msprof-analyze 等已有工具构建，也可以自己实现。
附录：参考资料
- vLLM-Ascend
- LLaMA Factory
- Qwen3.5-9B
- Ascend PyTorch Profiler 接口说明
- MindStudio Insight
- msprof-analyze：Profiling 数据的可视化与自动化分析工具
- ops-transformer：基于 CANN 的 Transformer 类大模型算子库，含算子开发模板与调试工具
- TileLang Ascend
- PyPTO
- Triton-Ascend
- Gated Delta Networks: Improving Mamba2 with Delta Rule
- flash-linear-attention
- Liger Kernel：面向训练的融合算子集合，可以参考其融合思路
- CANN Bench: Benchmarking Agent Generated Kernels against Real NPU and Algorithmic Limits
- Agent Skills
- 参考课程：SwanRmsNorm 算子加速 Qwen3-8B