前言把DeepSeek-V3和Qwen2.5-72B部署到昇腾910B集群上。客户说GPU上跑得好好的换昇腾应该也行吧。结果第一天就被砸懵——同样的模型、同样的batch昇腾上吞吐只有GPU的60%。不是算力不够是我根本没搞清楚CANN的优化逻辑和CUDA完全是两套体系。很多人以为昇腾上跑大模型就是把CUDA代码编译一下扔给CANN其实从Attention到显存管理每个环节的优化路径都不一样。工程经验DeepSeek-V3初次部署到昇腾910B未开优化时decode吞吐580 TPS。开完FlashAttention PagedAttention W8A16量化到2180 TPS涨了276%。不是算力不够是默认配置没打开昇腾的加速特性。推理瓶颈先 profile 再动手一上来就改算子调参数优化半天发现瓶颈在数据搬运。CANN自带的msprof跑一次就知道瓶颈在哪# 跑msprof做性能分析msprof--output./profiling_output\--aic-metricsmemory_bandwidth_utilization\python infer.py--modeldeepseek-v3--batch8# 看报告哪种算子占比高msprof--exporton--output./profiling_output# 打开生成的report.html看算子耗时分布我第一次profile DeepSeek-V3Attention计算38%、KV Cache访存27%、MoE RouterAllReduce 19%、其他16%。为什么GPU方案不能直接复用GPU上Attention占比通常50%瓶颈在计算昇腾Cube的MAC阵列算矩阵乘效率高但Vector做逐元素运算的吞吐比GPU的SM低——softmax、scale这些逐元素操作反而成瓶颈。GPU优化MatMul就够昇腾得同时优化计算和访存。工程经验msprof的输出在profiling_output/summary/目录下api_statistic.csv里能看到每个ACL API的耗时。aclmdExecute占比高说明算子调度开销大要开ATB融合aclrtMemMalloc占比高说明显存碎片多要开预分配。Attention 优化FlashAttention 只是起点ops-transformer里的FlashAttention算子针对达芬奇架构做了Cube/Vector流水线优化Cube算Q×K^T → Vector算scalemasksoftmax → Cube算P×V中间数据走L1不落HBM。# PyTorch接入FlashAttentiontorch_npuimporttorchimporttorch_npu# 开FlashAttentionops-transformer提供withtorch.no_grad():outputtorch_npu.npu_flash_attention(query,key,value,head_num32,head_dim128,dropout_prob0.0,inner_precise0,# 用FP16不用FP32累加)实测性能Ascend 910BFP16模型未融合FlashAttention开FlashAttention提升Qwen2.5-7B (seq2048)34 tokens/s89 tokens/s162%DeepSeek-V3-671B (seq4096)580 TPS1420 TPS145%DeepSeek-V4更激进——CSA4倍压缩和HCA128倍压缩交替使用。128K序列下HCA把KV Cache从7.3GB压到57MBTPOT 10ms950DT16卡。不压缩的Full Attention同场景TPOT 80ms。工程经验CSA/HCA压缩率不是越大越好。128倍压缩HCA长序列收益明显但短序列4K反而比Full Attention慢12%——Compressor本身有计算开销。我们的做法前两层用Window Attentionsliding_window128中间层按序列长度动态选CSA或HCA。KV Cache 优化省显存是手段涨 batch 才是目的Qwen2.5-7BFP16下每个token的KV Cache约57KB。seq2048、batch32时光KV Cache就吃3.6GB。三条优化路PagedAttentionMindIE推理引擎支持KV Cache分block按需分配消碎片。KV Cache量化INT8存KV Cache显存省一半。910B实测3.6GB → 1.8GB省出1.8GB多跑16个batch。KV Cache压缩DeepSeek-V4的HCA 128倍压缩128K序列KV Cache 57MB。很多人以为KV Cache优化就是省显存。真正的收益是省出的显存能跑更大batch更大batch吞吐更高。# MindIE配置开PagedAttention KV Cache量化frommindieimportMindIERuntime,ModelConfig configModelConfig(model_path/path/to/deepseek-v3,# PagedAttentionblock_size128kv_cache_modepaged,block_size128,# KV Cache量化INT8kv_cache_dtypeint8,# KV Cache压缩DeepSeek-V4use_hcaTrue,# 128倍压缩hca_threshold4096,# seq4096才开HCA)runtimeMindIERuntime(config)工程经验Qwen2.5-7B在910B单卡FP16 batch8吞吐72 tokens/s开KV Cache量化 PagedAttention后batch开到32吞吐147 tokens/s。算力没变显存够用了batch从8涨到32吞吐涨104%。算子融合省 Task 调度开销昇腾上每次算子下发走ACL→GE→Runtime调用链开销12-15μs。30层Transformer几百次调用光调度开销就3-5ms。CANN的graph-autofusion自动融合框架LayerNormMatMul、SoftmaxDropoutMatMul、GatingTopK等。DeepSeek-V4专门做了SAS统一Window/Sparse/Compress Attention、Compressor、HCPre/HCPost融合Kernel已开源在cann-recipes-infer。// graph-autofusion配置GE环境变量exportGE_FUSION_PASS_MODEaggressive// 激进融合策略exportGE_ENABLE_OP_FUSION1// 开算子融合exportATB_FUSION_MODEaggressive// ATB也开激进融合// 融合效果验证看GE编译日志// 搜索Fusion success看哪些算子融了grepFusion successge_compile.log|wc-l工程经验DeepSeek-V4 MoE的GatingTopK融合前router输出落HBM再给topk读融合后直接L1传数据省一次HBM读写。单层省18μs40层省720μs。decode每个token快0.7ms1000个token差0.7秒。显存管理 Batch 调优昇腾HBM管理跟GPU不一样。GPU的caching allocator基本是申请-使用-释放昇腾的DMA引擎要求显存预分配、零碎片、复用中间buffer。实测带宽利用率动态申请释放35% → 预分配复用82%。910B的1.2TB/s带宽82%是984GB/s可用35%只有420GB/s——差一倍多。# 开显存预分配Runtime环境变量exportACL_MEM_POOL_SIZE32GB# 预分配32GB显存池exportACL_MEM_POOL_REUSE_FLAG1# 复用中间bufferexportACL_MEM_POOL_GUARANTEE_FLAG1# 预分配不释放# Batch调优动态batchexportACL_DYNAMIC_BATCH1exportACL_DYNAMIC_BATCH_MAX64# 最大batch64Batch调优也不是越大越好。batch越大Attention的S矩阵越大L1装不下就溢出batch吞吐(tokens/s)TTFT(ms)显存(GB)45286.88721220.1321473839.26413872OOMbatch64吞吐反而降——KV Cache swap到Host内存。选batch看场景在线对话batch4-8TTFT100ms离线批处理batch16-32。我们的做法是动态batch短输入batch32长输入batch8。量化最后一板斧量化方案适用芯片精度损失性能收益W8A16910B, A30.5%吞吐45%显存-30%W8A8C16A31%吞吐85%显存-45%Hybrid FP8-MXFP4950PR/DT1.5%吞吐120%显存-60%DeepSeek-V4 Flash在950DT16卡128KHybrid FP8-MXFP4 TPOT10msFP16约35ms3.5倍提升。# 量化配置torch_npufromtorch_npu.contribimporttransfer_paramastp# W8A16量化modeltp.param_quantize(model,algow8a16,dtypetorch.float16,)# W8A8C16量化A3及以上modeltp.param_quantize(model,algow8a8c16,dtypetorch.float16,)# Hybrid FP8-MXFP4950PR/DTmodeltp.param_quantize(algohybrid_fp8_mxfp4,dtypetorch.bfloat16,)工程经验量化不是精度损失越低越好。W8A16精度损失0.5%但吞吐只涨45%W8A8C16精度损失1%但吞吐涨85%。如果业务能接受1%的精度损失比如推荐系统、文本摘要W8A8C16更划算。踩坑实录坑1FlashAttention在seq512的时候反而不如标准Attentionseq太小Cube利用率掉得厉害M/N维度太小Cube吃不饱FlashAttention的额外调度开销Tiling、softmax在线归一化占比高。解决设export ATB_FlashATTENTION_SEQ_THRESHOLD1024seq1024才开FlashAttention否则退化成标准Attention。坑2PagedAttention在batch动态变化的时候反而慢batch从8涨到32PagedAttention要动态分配block分配开销占比高~5ms。解决预分配最大batch的block池export MINDDIE_PAGED_POOL_SIZE64GB不动态分配。坑3W8A8C16量化在910B上编译失败W8A8C16需要INT8的矩阵乘指令CADIN8910B的Cube不支持只支持FP16/FP32要A3及以上的芯片。解决910B上用W8A16只量化权重激活还是FP16A3上用W8A8C16。坑4DeepSeek-V4的HCA压缩在seq512的时候反而慢12%Compressor的计算开销CSA/HCA压缩解压比省下来的KV Cache访存开销大。解决设export DEEPEEK_HCA_THRESHOLD4096seq4096才开HCA短序列用CSA4倍压缩或Full Attention。https://atomgit.com/cann/ops-transformerhttps://atomgit.com/cann/cann-recipes-inferhttps://atomgit.com/cann/graph-autofusion
DeepSeek / Qwen 大模型在昇腾上的推理优化实战
发布时间：2026/5/23 17:50:44
前言把DeepSeek-V3和Qwen2.5-72B部署到昇腾910B集群上。客户说GPU上跑得好好的换昇腾应该也行吧。结果第一天就被砸懵——同样的模型、同样的batch昇腾上吞吐只有GPU的60%。不是算力不够是我根本没搞清楚CANN的优化逻辑和CUDA完全是两套体系。很多人以为昇腾上跑大模型就是把CUDA代码编译一下扔给CANN其实从Attention到显存管理每个环节的优化路径都不一样。工程经验DeepSeek-V3初次部署到昇腾910B未开优化时decode吞吐580 TPS。开完FlashAttention PagedAttention W8A16量化到2180 TPS涨了276%。不是算力不够是默认配置没打开昇腾的加速特性。推理瓶颈先 profile 再动手一上来就改算子调参数优化半天发现瓶颈在数据搬运。CANN自带的msprof跑一次就知道瓶颈在哪# 跑msprof做性能分析msprof--output./profiling_output\--aic-metricsmemory_bandwidth_utilization\python infer.py--modeldeepseek-v3--batch8# 看报告哪种算子占比高msprof--exporton--output./profiling_output# 打开生成的report.html看算子耗时分布我第一次profile DeepSeek-V3Attention计算38%、KV Cache访存27%、MoE RouterAllReduce 19%、其他16%。为什么GPU方案不能直接复用GPU上Attention占比通常50%瓶颈在计算昇腾Cube的MAC阵列算矩阵乘效率高但Vector做逐元素运算的吞吐比GPU的SM低——softmax、scale这些逐元素操作反而成瓶颈。GPU优化MatMul就够昇腾得同时优化计算和访存。工程经验msprof的输出在profiling_output/summary/目录下api_statistic.csv里能看到每个ACL API的耗时。aclmdExecute占比高说明算子调度开销大要开ATB融合aclrtMemMalloc占比高说明显存碎片多要开预分配。Attention 优化FlashAttention 只是起点ops-transformer里的FlashAttention算子针对达芬奇架构做了Cube/Vector流水线优化Cube算Q×K^T → Vector算scalemasksoftmax → Cube算P×V中间数据走L1不落HBM。# PyTorch接入FlashAttentiontorch_npuimporttorchimporttorch_npu# 开FlashAttentionops-transformer提供withtorch.no_grad():outputtorch_npu.npu_flash_attention(query,key,value,head_num32,head_dim128,dropout_prob0.0,inner_precise0,# 用FP16不用FP32累加)实测性能Ascend 910BFP16模型未融合FlashAttention开FlashAttention提升Qwen2.5-7B (seq2048)34 tokens/s89 tokens/s162%DeepSeek-V3-671B (seq4096)580 TPS1420 TPS145%DeepSeek-V4更激进——CSA4倍压缩和HCA128倍压缩交替使用。128K序列下HCA把KV Cache从7.3GB压到57MBTPOT 10ms950DT16卡。不压缩的Full Attention同场景TPOT 80ms。工程经验CSA/HCA压缩率不是越大越好。128倍压缩HCA长序列收益明显但短序列4K反而比Full Attention慢12%——Compressor本身有计算开销。我们的做法前两层用Window Attentionsliding_window128中间层按序列长度动态选CSA或HCA。KV Cache 优化省显存是手段涨 batch 才是目的Qwen2.5-7BFP16下每个token的KV Cache约57KB。seq2048、batch32时光KV Cache就吃3.6GB。三条优化路PagedAttentionMindIE推理引擎支持KV Cache分block按需分配消碎片。KV Cache量化INT8存KV Cache显存省一半。910B实测3.6GB → 1.8GB省出1.8GB多跑16个batch。KV Cache压缩DeepSeek-V4的HCA 128倍压缩128K序列KV Cache 57MB。很多人以为KV Cache优化就是省显存。真正的收益是省出的显存能跑更大batch更大batch吞吐更高。# MindIE配置开PagedAttention KV Cache量化frommindieimportMindIERuntime,ModelConfig configModelConfig(model_path/path/to/deepseek-v3,# PagedAttentionblock_size128kv_cache_modepaged,block_size128,# KV Cache量化INT8kv_cache_dtypeint8,# KV Cache压缩DeepSeek-V4use_hcaTrue,# 128倍压缩hca_threshold4096,# seq4096才开HCA)runtimeMindIERuntime(config)工程经验Qwen2.5-7B在910B单卡FP16 batch8吞吐72 tokens/s开KV Cache量化 PagedAttention后batch开到32吞吐147 tokens/s。算力没变显存够用了batch从8涨到32吞吐涨104%。算子融合省 Task 调度开销昇腾上每次算子下发走ACL→GE→Runtime调用链开销12-15μs。30层Transformer几百次调用光调度开销就3-5ms。CANN的graph-autofusion自动融合框架LayerNormMatMul、SoftmaxDropoutMatMul、GatingTopK等。DeepSeek-V4专门做了SAS统一Window/Sparse/Compress Attention、Compressor、HCPre/HCPost融合Kernel已开源在cann-recipes-infer。// graph-autofusion配置GE环境变量exportGE_FUSION_PASS_MODEaggressive// 激进融合策略exportGE_ENABLE_OP_FUSION1// 开算子融合exportATB_FUSION_MODEaggressive// ATB也开激进融合// 融合效果验证看GE编译日志// 搜索Fusion success看哪些算子融了grepFusion successge_compile.log|wc-l工程经验DeepSeek-V4 MoE的GatingTopK融合前router输出落HBM再给topk读融合后直接L1传数据省一次HBM读写。单层省18μs40层省720μs。decode每个token快0.7ms1000个token差0.7秒。显存管理 Batch 调优昇腾HBM管理跟GPU不一样。GPU的caching allocator基本是申请-使用-释放昇腾的DMA引擎要求显存预分配、零碎片、复用中间buffer。实测带宽利用率动态申请释放35% → 预分配复用82%。910B的1.2TB/s带宽82%是984GB/s可用35%只有420GB/s——差一倍多。# 开显存预分配Runtime环境变量exportACL_MEM_POOL_SIZE32GB# 预分配32GB显存池exportACL_MEM_POOL_REUSE_FLAG1# 复用中间bufferexportACL_MEM_POOL_GUARANTEE_FLAG1# 预分配不释放# Batch调优动态batchexportACL_DYNAMIC_BATCH1exportACL_DYNAMIC_BATCH_MAX64# 最大batch64Batch调优也不是越大越好。batch越大Attention的S矩阵越大L1装不下就溢出batch吞吐(tokens/s)TTFT(ms)显存(GB)45286.88721220.1321473839.26413872OOMbatch64吞吐反而降——KV Cache swap到Host内存。选batch看场景在线对话batch4-8TTFT100ms离线批处理batch16-32。我们的做法是动态batch短输入batch32长输入batch8。量化最后一板斧量化方案适用芯片精度损失性能收益W8A16910B, A30.5%吞吐45%显存-30%W8A8C16A31%吞吐85%显存-45%Hybrid FP8-MXFP4950PR/DT1.5%吞吐120%显存-60%DeepSeek-V4 Flash在950DT16卡128KHybrid FP8-MXFP4 TPOT10msFP16约35ms3.5倍提升。# 量化配置torch_npufromtorch_npu.contribimporttransfer_paramastp# W8A16量化modeltp.param_quantize(model,algow8a16,dtypetorch.float16,)# W8A8C16量化A3及以上modeltp.param_quantize(model,algow8a8c16,dtypetorch.float16,)# Hybrid FP8-MXFP4950PR/DTmodeltp.param_quantize(algohybrid_fp8_mxfp4,dtypetorch.bfloat16,)工程经验量化不是精度损失越低越好。W8A16精度损失0.5%但吞吐只涨45%W8A8C16精度损失1%但吞吐涨85%。如果业务能接受1%的精度损失比如推荐系统、文本摘要W8A8C16更划算。踩坑实录坑1FlashAttention在seq512的时候反而不如标准Attentionseq太小Cube利用率掉得厉害M/N维度太小Cube吃不饱FlashAttention的额外调度开销Tiling、softmax在线归一化占比高。解决设export ATB_FlashATTENTION_SEQ_THRESHOLD1024seq1024才开FlashAttention否则退化成标准Attention。坑2PagedAttention在batch动态变化的时候反而慢batch从8涨到32PagedAttention要动态分配block分配开销占比高~5ms。解决预分配最大batch的block池export MINDDIE_PAGED_POOL_SIZE64GB不动态分配。坑3W8A8C16量化在910B上编译失败W8A8C16需要INT8的矩阵乘指令CADIN8910B的Cube不支持只支持FP16/FP32要A3及以上的芯片。解决910B上用W8A16只量化权重激活还是FP16A3上用W8A8C16。坑4DeepSeek-V4的HCA压缩在seq512的时候反而慢12%Compressor的计算开销CSA/HCA压缩解压比省下来的KV Cache访存开销大。解决设export DEEPEEK_HCA_THRESHOLD4096seq4096才开HCA短序列用CSA4倍压缩或Full Attention。https://atomgit.com/cann/ops-transformerhttps://atomgit.com/cann/cann-recipes-inferhttps://atomgit.com/cann/graph-autofusion
