★ FEATURED ARTICLE 本文系统性地总结了我们以华为昇腾 910C为国产算力底座在大模型在线推理场景下完成国产化适配与性能优化工作。项目从建立 Qwen3.5-35B-A3B 在 910C 上的性能基线出发通过 MindStudio 进行性能剖析定位瓶颈按照「镜像与版本升级 → 参数与环境变量调优 → vllm-ascend 源码修改 → 算子层融合优化 → MTP 投机解码」五个层次逐层推进累计落地 20 余项有效优化。最终成果在 910C-560t单卡双 die、TP2上未开启投机解码时TPOTTime Per Output Token单 token 解码延迟从基线14.22ms 降至 7.8msc1下降 45.1%开启 MTP 投机解码并叠加全部源码级优化后真实业务场景的数据集上 c1/c4/c8 的 TPOT 分别达到5.0ms/8.8ms/11.9ms较基线分别下降64.8%/49.9%/43.8%在 GSM8K 公开数据集上 c1 TPOT 达到 4.2ms。同时同一套优化方法论在 Qwen3.6-27B 上也得到验证c1 从 30.7ms 降至 11.8ms。文中详细给出每一项优化的动机、实现含具体源码改动路径与关键代码片段、验证数据与踩坑记录包括十余项实测无效或负向的尝试希望为同样在国产算力上做推理优化的团队提供一份可直接复用的工程参考。一、背景当前国内 NVIDIA GPU 供给持续紧张H20 已无新增算力供给核心业务算力的国产化替代已迫在眉睫。华为昇腾 910C 作为主流国产算力已在实际业务的离线推理场景完成投产验证证明了国产算力在批处理场景下的可行性。然而在在线实时推理场景中由于业务对响应时间RT要求较为严苛直接部署大参数模型会导致 RT 无法满足 SLA因此 910C 暂时无法直接替换现有在线服务。为保证 910C 能应用于在线推理业务通过轻量级小模型如 Qwen3-32B、Qwen3.5-35B-A3B、Qwen3.5-27B、Qwen3.6-27实现在线场景下国产算力的平滑替代。昇腾NPU与英伟达GPU软硬件架构对比昇腾与英伟达架构对比英伟达与昇腾架构核心差异概览项目目标以华为昇腾 910C 为核心国产化算力底座完成在线推理优化的目标为建立 Qwen3.5 系列模型在 910C 上的性能基线并以 H20 作为对照组通过系统优化将低并发c1/4/8TPOT 与 H20 的差距缩小到 80%。二、软硬件环境硬件配置本次优化使用的机器型号为昇腾 910C-560t单卡双 die 形态一张加速卡上封装两个 chipdie每个 chip 拥有独立的 64GB HBM整机 8 卡共 16 个 die。模型信息Qwen3.5-35B-A3B优化工作的主力模型是 Qwen3.5-35B-A3B——总参数约 35B、激活参数约 3B 的 MoEMixture of Experts混合架构模型。该模型的架构特点对推理优化策略影响很大这里展开说明混合注意力结构模型包含 30 层 GDNGated DeltaNet线性注意力层与 10 层全注意力Full Attention层交替GDN 层使用递归状态recurrent state/mamba state代替 KV Cachedecode 阶段每层都要执行 causal_conv1d、L2Norm、recurrent kernel 等一系列小算子算子数量多、launch 开销占比高是优化的重点对象。MoE 共享专家每个 MoE 层除路由专家routed experts, GroupedMatmul外还有一个共享专家shared expertdecode 低并发时专家权重从 HBM 读取的带宽开销显著这为权重预取weight prefetch与多流重叠提供了优化空间。Gemma 风格 RMSNorm归一化权重以 (1.0 weight) 的形式参与计算若不做缓存每层每步都会产生一次加法 拷贝开销。MTPMulti-Token Prediction头模型自带 MTP 模块可直接用于投机解码speculative decoding训练时未开启 MTP 的真实业务场景的微调模型也可以在推理时直接受益。需要特别说明的是框架版本这条线vllm-ascend 社区版本迭代很快不同版本在图编译、MoE 通信MC2/AllToAll、投机解码等路径上的实现差异很大。我们早期的基线建立在 0.22.0rc1 上优化中期切换到 0.23.0rc1 并获得了 15% 以上的直接收益见 4.1 节最终所有源码级优化都迁移并固化在正式发布的 v0.23.0 基线的内部分支上。压测方法与指标定义为保证数据可比所有优化实验都遵循统一的压测协议核心指标TPOTTime Per Output Tokendecode 阶段每个输出 token 的平均延迟在线场景主优化指标与 TTFTTime To First Token首 token 延迟对照组为 H20 单卡vLLM 0.23.0。默认负载输入 1024 token、输出 512 tokenmin/max prompt 与 min/max tokens 分别锁定为 1024/512并发取 1/4/8 三档覆盖在线低并发场景。数据集基线使用 random dataset排除缓存与数据分布影响后期验证使用真实业务场景的数据集与 gsm8k 公开数据集。profile 工具昇腾官方 profiler采集 NPU/host 时间线通过 MindStudio 定位每个 decode step 内部的算子耗时、通信耗时与 host 侧空隙。标准的 evalscope 压测命令如下evalscope perf \ --parallel 1 4 8 \ --number 40 80 80 \ --warmup-num 20 \ --model model_name \ --url http://127.0.0.1:5001/v1/chat/completions \ --api openai \ --stream \ --dataset random \ --max-tokens 512 --min-tokens 512 \ --min-prompt-length 1024 --max-prompt-length 1024 \ --prefix-length 0 \ --tokenizer-path path/to/model/qwen3.5-35b-a3b \ --outputs-dir ./my_output三、性能基线与瓶颈分析基线数据在 910C-752t单卡双 die、TP2、vllm-ascend 0.22.0rc1、默认开启 cudagraph、random 数据集、输入 1024/输出 512 条件下测得 Qwen3.5-35B-A3B 的基线如下基线阶段还同步建立了 Qwen3-8B/14B/32B 与 Qwen3.5-4B/9B/27B 等模型在 910C 与 H20 上的完整对照基线涵盖单卡单 die、单卡双 die 两种形态输入输出 1024-512/1024-1024/4096-512 三种负载总体规律一致TTFT首 token 延迟方面昇腾占优H20 约为昇腾的 24 倍说明昇腾在 prefill 阶段计算密集效率不错TPOTdecode 延迟方面 H20 占优H20 约为昇腾的 0.60.65 倍decode 是在线场景的主优化指标也是本次优化的主攻方向。Profile 分析我们用 MindStudio 对 c1 的 decode 时间线做了逐层剖析。Qwen3.5-35B-A3B 单个 decode step 要穿过 40 个 decoder 层每层包含 GDN/全注意力 MoE 两个子模块一个 step 内要 launch 上千个算子。剖析结果可以归纳为六大类开销host 侧调度与下发开销低并发下每个算子的计算时间极短微秒级host 侧的 kernel dispatch、aclnn 执行、event record/wait 成为主要开销。典型例子triton slot_mapping kernel 固定约 131us 的 launch 开销每层 conv 权重 transposecontiguous 约 4.3us × 30 层 ≈ 129us/step。host-device 同步与冗余拷贝投机解码验证路径上MinTokens logits processor 每步在 host 侧用 numpy 重建 (rows, toks) 掩码并从分页内存做 H2D 拷贝——分页内存的 non_blocking 拷贝实际是同步的直接把异步调度流水打断实测占单步时间约 30%model_runner 中还有大量每步无条件执行的 copy_to_gpu/fill_。集合通信开销TP2 下每层有多次 AllReduce。默认配置下 HCCL 的集合通信算子跑在 AI CPU 上占用独立的 AI CPU 资源且与计算难以重叠此外 compute_logits 会做全词表 logits 的 all-gather通信量高达 O(batch × vocab_size)而贪婪采样其实只需要 argmax。HBM 带宽瓶颈MoE 权重读取c1 decode 时 batch 极小MoE GroupedMatmul 是带宽受限的专家权重从 HBM 加载的时间构成关键路径shared expert 的权重加载与 routed expert 计算默认串行。图模式编译质量aclnn 动态 shape kernel 在 replay 阶段仍要走 runtime GetWorkspaceSize 等流程静态 kernel 预编译可以把这部分开销固化掉但需要框架版本与编译选项支持。内存分配开销host 侧 glibc malloc 在高频小对象分配场景下锁竞争明显device 侧 HBM 分配器的 page 粒度影响碎片与映射开销。这六类开销分别对应了后文的五个优化层次。总体思路是先易后难先做容易见效的调整比如版本升级、环境变量等参数调整再做需要改源码的精细优化最后再进行底层的算子融合。下面是通过 MindStudio 进行昇腾性能分析是示例图MindStudio 进行性能 profile 分析示例优化路线图总览整个优化过程历时约 1 个月按层次与时间线归纳如下四、优化实践一镜像版本与参数调优本章记录所有不需要改源码、通过换版本或调参数/环境变量就能生效的优化。这部分投入产出比最高建议任何做昇腾推理优化的团队先系统性地过一遍。推理框架版本升级优化初期我们的基线建立在 vllm-ascend 0.22.0rc1 上。将镜像切换到 0.23.0rc1其余参数完全保持不变后c1 TPOT 直接从 14.2ms 降到 12.0ms下降 15.4%。升级 vllm-ascend 0.23.0rc1 后的压测结果TPOT 12.0ms版本升级的收益来自社区在 MoE 通信路径、图编译、调度器等方面的持续迭代。之后我们又试验了基于 v0.23.0 的 nightly 镜像额外收益约 0.1ms提升很小。这也给出一条经验版本升级要趁早做、一次到位后面所有源码级优化都应建立在最新稳定版本之上避免将来再做一次痛苦的迁移。我们最终的工程基线是正式发布版 v0.23.0。CANN 层面同理从 CANN 9.0.0 镜像更换为 CANN 9.1.0 镜像后c1 TPOT 从 8.8ms 降到 8.5ms-3.4%并且 9.1.0 是后续 SuperKernel stream fusion 等编译选项见 6.2 节的前置依赖。集合通信下沉到 AIVectorHCCL_OP_EXPANSION_MODEAIV默认情况下HCCL 的集合通信算子主要是 AllReduce由 AICPU 执行。AICPU 是独立于 AI Core 的计算单元其算力与带宽都弱于 AI Core且通信算子跑在 AICPU 上时与主计算流难以重叠成为 decode 关键路径上的串行开销。通过设置环境变量可以把集合通信算子「展开」到 AIVAI Vector单元上执行export HCCL_OP_EXPANSION_MODEAIV。在 Qwen3.5-35B-A3B0.23.0rc1 基线上该配置使 c1 TPOT 从 12.0ms 降到 11.2ms-6.6%此前在 Qwen3-8B 上验证时为 9.9ms → 9.25ms-6.5%收益稳定。值得注意的是vllm-ascend 社区后来也在特定模型如 MiniMax-M2的 ACL graph 捕获路径上默认开启了同样的配置侧面印证了该优化的通用性。HCCL_OP_EXPANSION_MODEAIV 压测结果静态 kernel 预编译Static Kernelvllm-ascend 的图模式默认使用动态 shape 的 aclnn kernel即使是 cudagraph 捕获的固定 batch sizereplay 时 runtime 仍要执行 GetWorkspaceSize 等动态推导逻辑。静态 kernel 预编译的思路是在服务启动的 graph capture 阶段提前为每个 cudagraph_capture_size如 [1,2,4,8,…]预编译静态 shape 的 aclnn kernel把 workspace 计算固化进编译产物replay 时直接走预编译的静态路径。开启方式注意多卡场景必须设置 LOCAL_WORLD_SIZEexport ASCEND_RT_VISIBLE_DEVICES0,1 export LOCAL_WORLD_SIZE2 # 多卡必须设置 vllm serve /root/workspace/models/Qwen3-32B \ --tensor-parallel-size 2 \ --compilation-config {cudagraph_mode: FULL_DECODE_ONLY} \ --additional-config {ascend_compilation_config: {enable_static_kernel: true}}收益与模型规模强相关Qwen3-32B 上叠加前序优化后c1 TPOT 从 31.5ms 降到 30.9ms-1.9%而在 Qwen3.5-35B-A3B 上叠加 HCCL AIV 后收益高达 18.7%11.2ms → 9.1ms因为 A3B 激活参数小、decode step 内算子多且碎host 侧动态推导开销占比更高。静态 kernel HCCL AIV 叠加后的压测结果静态 kernel 编译本身也有一些坑编译过程中会调用 CANN 工具链部分头文件路径与 CANN 版本相关。我们在容器环境里遇到过 cann_compat.h 缺失导致编译失败的问题最终通过启动脚本内联生成兼容头文件解决见下篇。HBM 分配器调优虚拟内存映射 pin_memory page_sizetorch_npu 的设备内存分配器支持一组通过 PYTORCH_NPU_ALLOC_CONF 控制的调优项。针对在线低并发场景我们开启了虚拟内存映射expandable segments、1GB 大页、pin memory 后台线程等组合export PYTORCH_NPU_ALLOC_CONFexpandable_segments:True,base_addr_aligned_kb:16,page_size:1g,pinned_use_background_threads:True,pin_memory_expandable_segments:True。各项的含义expandable_segments:True采用虚拟内存映射方式分配 HBMsegment 可按需扩展缓解碎片问题大张量分配不再要求物理连续。page_size:1g把虚拟内存页大小调整为 1GB减少页表项数量与映射开销。pinned_use_background_threads:True/pin_memory_expandable_segments:Truepin memory锁页内存分配走后台线程避免阻塞推理主流程同时锁页内存池可扩展。base_addr_aligned_kb:16/roundup_power2_divisions:16控制分配对齐与分桶粒度减少小对象分配的碎片。该组合在叠加前序优化的基础上使 c1 TPOT 从 9.1ms 降到 8.8ms-3.3%。后期配合 jemalloc见 4.5时我们改用了更精简的组合expandable_segments:True,roundup_power2_divisions:16。虚拟内存 pin_memory page_size 调优后的压测结果host 侧内存分配优化jemalloc 替换 glibc mallocvLLM 的 Python/host 侧每步会产生大量小对象分配tensor 元数据、调度结构、通信描述符等。glibc 的 ptmalloc 在多线程高频小对象场景下存在 arena 锁竞争与碎片膨胀问题。我们通过 LD_PRELOAD 将分配器替换为 jemallocexport LD_PRELOAD/usr/lib64/libjemalloc.so.2。收益随并发增大而增大c1 -0.1ms、c4 -0.3ms、c8 -0.6ms。原理上并发越高host 侧线程间分配竞争越激烈jemalloc 的 thread cache 结构优势越明显。这是一项零风险的通用优化建议默认开启。算子缓存与 batch memcpyaclnn 算子在 host 侧有一层执行信息缓存默认缓存条目有限。ACLNN_CACHE_LIMIT 用于配置单算子执行时 host 侧缓存的算子信息条目数export ACLNN_CACHE_LIMIT100000export VLLM_ASCEND_ENABLE_BATCH_MEMCPY1ACLNN_CACHE_LIMIT100000提高 host 侧算子缓存上限避免 decode 过程中缓存淘汰导致的重复解析实测 p99 从 9.1ms 降到 8.9ms收益不大但稳定对消除尾延迟毛刺有帮助VLLM_ASCEND_ENABLE_BATCH_MEMCPY1把分散的小块 H2D/D2H memcpy 合并为批量拷贝减少拷贝次数与 launch 开销。MoE 权重预取Weight Prefetchc1 decode 时 MoE 层的 GroupedMatmul 是带宽受限的专家权重体量远大于激活数据每个 step 都要从 HBM 读取。weight prefetch 机制利用 NPU 的 prefetch 能力在当前层计算时提前把下一层的权重搬进 L2 Cache用计算时间掩盖权重加载延迟。开启方式--additional-config {..., weight_prefetch_config: {enabled: true}, pa_shape_list: [1,4,8]}这里有三个关键细节。预取阈值改动源码上游 vllm_ascend/ops/weight_prefetch.py 中 MOE_PREFETCH_TOKEN_THRESHOLD 96即 batch 中 token 数少于 96 时不做 MoE 预取——这是为吞吐场景设计的保守值。而我们的在线场景恰恰是 c1~8 的极小 batchdecode 时 token 数等于并发数永远达不到阈值。将阈值改为 1 后c1 decode 也能触发预取MOE_PREFETCH_TOKEN_THRESHOLD 1 # 原值 96pa_shape_list显式声明 decode 的 batch 形状列表 [1,4,8]让 paged attention 与预取逻辑对这些低并发形状做针对性处理。shared expert 预取扩展源码原实现只预取 routed expert 的 w13gate_up权重我们在 preprocess 阶段追加了对下一层 shared expert gate_up 权重的预取_get_moe_shared_expert_gate_up_prefetch_weight使其在当前层 routed expert GroupedMatmul 执行期间提前进入 L2填补多流重叠暴露出的空窗。收益c8 时 TTFT 改善prefill 阶段 expert 权重提前进 L2 cache、c4 TPOT 改善 0.2ms、c1 改善 0.1ms。HCCL 通信参数与 CPU 绑定最终最佳实践脚本中还固化了以下通信与调度参数HCCL_BUFFSIZE128HCCL 通信缓冲区大小MB影响通信分块粒度需按消息大小试参。HCCL_DETERMINISTICfalse关闭确定性归约确定性模式会强制固定的分块与归约顺序牺牲一部分通信效率换取结果可复现在线服务不要求比特级复现关闭后通信更快。HCCL_WHITELIST_DISABLE1禁用 HCCL 白名单校验减少通信建链开销。COMBINED_ENABLE1开启算子组合combined标志优化两个非连续算子的组合场景在 35B-A3B 单独测试时未见收益但与整体组合保留。OMP_NUM_THREADS1/GE_USE_STATIC_MEMORY1限制 OpenMP 线程数避免 host 侧线程争抢GE 使用静态内存减少图引擎动态分配。enable_cpu_binding: trueadditional-config开启 worker 进程的 CPU 绑核注意这与更激进的 CPU_AFFINITY_CONF2 精细化绑核不同——后者实测是负优化见 4.10。cudagraph 配置模式、捕获尺寸与 warmup图模式是 decode 优化的基石我们把所有 decode 都放进图里执行cudagraph_mode FULL_DECODE_ONLY只对纯 decode 步骤做整图捕获prefill 与混合批走 eager 路径兼顾性能与灵活性。cudagraph_capture_sizes非投机场景使用 [1,2,4,8]开启 MTPnum_speculative_tokens4后每步实际执行的 token 数 并发数 / dp × (1 投机长度)例如 c4、TP2 对应 2×510再考虑 bonus token我们把捕获尺寸调整为 [5,20,40]详见 7.2 节这一步是修复 MTP 下 c4/c8 从 10.4ms 劣化到 42ms 的关键。cudagraph warmup 次数源码vllm_ascend/platform.py 中 cudagraph_num_of_warmups 从 1 提到 3原 1 次 warmup 下部分 aclnn 算子尤其 MoE fused experts首次执行仍残留 host 侧编译/初始化开销提到 3 次后稳态命中率显著提升低并发收益最大约 -0.2~-0.3ms。实测无效或负向的尝试避坑清单优化的另一半工作是证伪。下表记录了我们实测无效、报错或负向的参数尝试供后来者避坑。所有结论都基于 Qwen3.5-35B-A3B、TP2、vllm-ascend 0.23.0 链路实测几个有价值的观察其一昇腾的环境变量多达数百个很多开关与 SoC 型号、CANN 版本、模型结构强耦合文档上的「推荐值」不能替代实测其二部分功能如 MatmulAllReduce、FlashComm在 910Cascend910_93上的算子库支持尚不完整其三同一优化在不同模型上结论可能相反FINE_GRAIN_REPLAY_SYNC建立「每模型必实测」的流程比记住任何具体参数都重要。本文为《国产算力·昇腾 910C 大模型推理优化》上篇聚焦镜像版本升级与参数调优。下篇将继续深入 vllm-ascend 源码修改、算子层优化与 MTP 投机解码敬请期待。往期回顾1.动态规则的 Agent 实践用确定性工程驾驭 LLM 的资产智能验收2.发一张图它居然跃出屏幕了一文读懂得物 3D 空间图片技术实践3.别再只卷向量检索了得物交易搜索如何用“生成式”实现召回范式跃迁4.指标平台从语义底座到智能消费的实践路径得物技术5.企业级 MultiAgent 落地Plan 模式与主子 Agent 协作得物技术文 / 映川关注得物技术每周四更新技术干货要是觉得文章对你有帮助的话欢迎评论转发点赞未经得物技术许可严禁转载否则依法追究法律责任。
阅读完成 · 觉得有帮助？
