CANN DeepSeek-V4推理优化

NPU DeepSeek-V4推理优化实践【免费下载链接】cann-recipes-infer本项目针对LLM与多模态模型推理业务中的典型模型、加速算法提供基于CANN平台的优化样例项目地址: https://gitcode.com/cann/cann-recipes-inferDeepSeek团队发布了最新的模型DeepSeek-V4系列模型包含DeepSeek-V4 Flash和DeepSeek-V4 Pro两种规格。在DeepSeek-V3.2的稀疏AttentionDeepSeek Sparse Attention的基础上在不同层间进一步通过KV Cache滑窗 (Window Cache) 和压缩算法 (KV Cache Compress)减少Attention的计算和访存开销可以大幅提升长序列的计算效率降低推理的成本。本实践0 Day支持了DeepSeek-V4的模型推理部署并适配支持Atlas-A3 Pod和950PR/DT多代际昇腾芯片提供长达1M序列的高性能推理能力。针对新模型结构特点实践打造了低时延、高吞吐的部署方案创新设计高性能NPU融合Kernel和多流并行方案大幅提升推理性能。在量化支持上本实践在Atlas-A3 Pod平台适配了W8A8C16Int8量化方案在950PR/DT平台上支持了原生Hybrid FP8-MXFP4混合量化模式以及硬件亲和的Hybrid MXFP8-MXFP4模式充分发挥不同硬件的算力优势。本实践同步开源了TileLang和PyPTO实现为高效算子开发提供可直接参考的样例仅需几百行代码即可完成复杂融合kernel的开发工作。 针对DeepSeek-V4模型的新结构本次开源提供了一系列高性能融合算子主要包括针对多Layer交织的Window/Sparse/Compress Attention提供了SparseAttnSharedKV (SAS)统一接口支持多种Attention计算。针对不同的Compress Ratio支持Compressor和CompressEpilog融合算子实现Cache的高效压缩与更新。强化LightningIndexer(LI)算子功能新增Compress Ratio特性支持。针对mHC (Manifold-Constrained Hyper-Connections) 架构提供了HCPre和HCPost融合算子。上述融合算子的AscendC实现均已在0 Day开源。此外本次开源还提供了PyPTO和TileLang实现为高效算子开发提供可直接参考的样例仅需几百行代码即可完成复杂融合kernel的开发工作。Highlights整体部署策略沿用DeepSeek的EP并行方案针对模型的新结构特征设计实现NPU亲和的并行策略支持Atlas-A3 Pod和950PR/DT多代际昇腾芯片部署提供长达1M序列的高性能推理能力。模型推理代码已在本仓开源同时也适配了主流开源推理框架vLLM和SGLang。基于AscendC开源发布HC Pre和HC Post融合算子高性能计算mHC的前后处理流程。AscendC Kernel技术文档和代码已开源。基于自研PyPTO发布HC Pre和MLAProlog融合算子提高融合算子的编程易用性算子前端无需感知芯片的代际差异后端通过pass IR和PTO_ISA指令进行区分实现代际兼容。PyPTO Kernel技术文档、PTO ISA的使用指南和代码已开源。开源社区TileLang同步支持了DeepSeek-V4中的所有新增算子开发并分别对应Tilelang-Ascend的Expert和Developer开发模式提供AscendC基础指令和PTO AS两种对接层次为各种编程前端语言和编译器提供多层开放接口在TileAi开源社区发布TileLang Kernel技术文档和代码已同步开源。基于NpuGraphEx后端叠加dynamo编译缓存、静态编译等独有特性释放昇腾算力实现极致的图模式加速。950PR/DT支持原生Hybrid FP8-MXFP4混合量化模式可实现权重无损平滑迁移。同时本实践支持采用MXFP8替代原生FP8计算在Prefill或Decode高吞吐场景下进一步提升计算效率。基于上述优化点CANN已0 Day支持DeepSeek-V4推理部署。Decode的参考性能DeepSeek-V4 Flash在950DT平台16卡128K序列场景TPOT小于10ms在Atlas-A3 Pod平台64卡8K序列场景Decode单卡吞吐4388TPS30ms。Outline模型结构融合Kernel并行策略MTP量化策略多流并行优化BenchmarkFuture Plan模型结构DeepSeek-V4每个Layer包含mHC、Attention和Mixture of Experts (MoE)三种模块。相较于DeepSeek-V3.2DeepSeek-V4在Attention部分沿用了LI稀疏注意力机制并新增了滑窗注意力机制 (Window Attention) 和KV Cache压缩技术使得Attention的整体计算量、访存量保持在较低水平对比Full Cache从而大幅提升长序列下的性能表现。DeepSeek-V4模型的结构如下图所示受篇幅所限图片所呈现的内容简化表达了部分结构。Attention 稀疏与压缩在模型的前两层Deepseek-V4 Flash采用Window Attention (SWA)使用sliding_window128大小的KV Cache有效降低Attention的计算量和KV Cache的内存占用Deepseek-V4 Pro则使用128倍Compress Ratio通过Compressor将Full Cache压缩128倍 (HCA)在后续的层中交替使用Compressed Sparse Attention (CSA)和Heavily Compressed Attention (HCA)通过Compressor将Full Cache压缩4倍 (CSA) 或128倍 (HCA)在CSA层中在压缩后的Cache上通过LI叠加KV Cache稀疏技术选取Top 512对KV参与Attention计算进一步提升长序列下的性能表现Attention计算采用MQA (Multi-Query Attention)而非MLA不再区分Prefill和Decode的计算流差异naive或者absorb同时引入attention_sink参数。MoE 专家模型规格路由专家数共享专家数单Token路由专家激活参数量285B25616G1.6T384122.5G在MoE部分DeepSeek-V4 MoE模块参数详见上表每次激活6个路由专家和1个共享专家。在专家选取上前3层采用了hash routing后40层则采用可学习的soft routing。mHC (Manifold-Constrained Hyper-Connections)mHC是对于传统残差连接的扩展它将hidden_state从一路扩展到多路在Attention/MoE计算前通过Pre Mapping融合回一路保持Attention/MoE的计算过程不变。对于Attention和MoE的输出结果再通过Post Mapping扩展回多路同时多路残差通过Res Mapping进行特征融合融合结果与Post Mapping结果加和得到mHC输出。图片源自mHC论文 Manifold-Constrained Hyper-Connections (Xie et al., 2026)KV Cache内存分析在DeepSeek-V4中通过多种算法有效降低KV Cache占用的内存。SWA仅需保留sliding_window大小的KV Cache在压缩Cache的层中KV Cache中存储压缩后的KV内存大小为 $$ \mathrm{batch_size}\times (\mathrm{kv_length} // \mathrm{compress_ratio} ) \times \mathrm{head_dim} \times \mathrm{storage_bytes} \times \mathrm{num_compress_layers} $$未满足压缩长度暂时不被压缩的kv_state和对应的score_state会被保存在remainder中。因此remainder的最大大小为 $$ \mathrm{batch_size}\times (\mathrm{compress_ratio - 1}) \times \mathrm{compress_dim} \times \mathrm{storage_bytes} \times \mathrm{num_compress_layers} $$在压缩倍率为4的层中CSA采用了LI进一步稀疏KV Cache因此与DeepSeek-3.2类似LI需要保留对应的Indexer Cache。为了与KV Cache的压缩对应在LI中也通过Compressor模块进行了4倍压缩因此Indexer Cache的存储数据量也为压缩后的长度如当前的kv_length不满足压缩长度则会暂存在indexer_kv_state和indexer_score_state中。综合来看得益于滑窗和高倍率压缩不保留Full Cache可以使得KV Cache整体存储的数据量明显降低如128k序列在128倍压缩HCA后仅需保留1k KV在4倍压缩CSA后保留32k KV对于长序列下的内存压力得以显著缓解。针对上述的差异和模型特点本实践设计了NPU亲和的并行策略并实现了SAS, Compressor, LI, GatingTopK, mHC等融合Kernel详细介绍请参考后续章节。融合Kernel使用融合Kernel可以获得算子间的数据流优化、流水并行、减少算子调度开销等优化收益。在DeepSeek-V4中本次开源的融合算子覆盖Attention、MoE、mHC等各模块。Attention部分的融合算子包括Compressor、LI、KvCompressEpilog、IndexerCompressEpilog、SAS其整体结构如下图所示LI部分Compressor结构与KV的Compressor结构相同图中简化表示。Compressor包含了KV/Gate的Linear计算和kv_state/score_state更新并选取对应的数据CSA场景存在Overlap计算压缩KV并输出KvCompressEpilog包含对压缩后的压缩KV的量化、量化后压缩KV和其Scale的拼接和刷新到KV Cache的操作IndexerCompressEpilog包含Indexer Cache的量化、刷新操作LightningIndexer包含了score_batchmatmul、re_lu、reduce_sum、topk等操作长序列场景topk操作会成为瓶颈可用topk计算耗时流水掩盖其他操作的耗时从而拿到计算流水收益SparseAttentionSharedKV包含了Sparse Attention、Compress Attention和Window Attention的计算mHC模块的融合算子由hc_pre和hc_post组成其中hc_pre融合算子同步提供 AscendC、PyPTO 两种实现版本融合范围如下图所示上述NPU融合Kernel均已开源使用方式参见融合Kernel执行指导 。并行策略针对Decode场景在950DT平台下可以采用8卡或16卡部署获取极低单用户时延在Atlas-A3 Pod平台采用64卡大EP部署获得高吞吐性能收益。针对Prefill场景在950PR平台下采用8卡或16卡部署针对长短序列可以分别选用DP或CP并行提升TTFT。Prefill并行策略DeepSeek-V4主要面向长序列推理场景Prefill阶段的内存占用和TTFT会面临巨大挑战因此优化内存占用和TTFT是并行策略设计的主要目的。如果采用Attention DP (Data Parallel) 策略每个Rank都需要推理超长序列总体计算量较大TTFT较高用户体验较差。因此针对长序列场景在Attention部分设计选用Context ParallelCP并行通过多Rank分摊计算和访存开销提升整体性能。由于LI采用causal_mask越往后的Context Chunk访存和计算量越大在CP切分时可以沿用之前Recipes在DeepSeek-3.2使用的zig_zag切分方式将首尾的序列块放在同一Rank上使得CP后各卡间的计算量相对均衡。此外在切分序列时还需要考虑Attention模块采用的Window Attention和KV Cache压缩。SWA层计算时每个Chunk需要获取到前序win_size128长度的KV在HCA层中可以通过切分使得前序Rank上的序列为128对齐则无需传递额外的Token给后续chunk所在的Rank同时除最后一个chunk以外其余chunk不需要处理remainder在CSA层中由于Compressor需要处理Token Overlap的信息因此需要获取到前序4个Token来实现Overlap压缩假设前序chunk的序列长度为128对齐则除最后一个chunk所在的Rank外无remainder。因此在Attention模块执行时需要从前序序列获取的最大Token长度为128满足Window Cache每个chunk向后续chunk传递128个Token。通过全局的all_gather通信算子获取所有Rank最后的128个Tokens并通过对应的receive_idx裁切出各chunk所需的数据。首个序列块chunk_0不需要获取额外的Token。因此在Attention模块会引入2次通信在MQA模块起始做一次通信通信128大小的hidden_states。此时MLAProlog的计算量会略有冗余但实现较为简洁在Compressor计算后由于Query已进行CP切分需要对Compress Cache进行CP域的all_gather获取到完整的压缩后的Cache用于LI和SAS的计算。针对zig_zag场景在all_gather后需要对Cache进行顺序重排。以CSA为例实现如下图由于两个Compressor存在并行空间同时CSA的Compressor仅需4个Overlap的Token信息因此也可以将Window Attention和Compressor需要的数据分别进行通信实现计算通信掩盖冗余计算的数据量也较少。Compressor后同样需要对Compressed Cache做CP域的all_gather通信。以CSA为例实现如下图Decode并行策略在Decode阶段并行策略参考DeepSeek-R1和DeepSeek-3.2的并行方案Attention采用Data Parallel (DP) 并行MoE采用Expert Parallel (EP) 并行LM_head采用Tensor Parallel (TP) 并行Attention后的Output Projection中o_a_proj的权重较大访存耗时较长。在低时延场景可以选择性地采用TP切分让多个Rank并行分担访存开销并通过all_to_all和reduce_scatter通信算子实现DP和TP间的转换如下图所示MTPDeepSeek-V4依然提供了原生的Multi-Token Prediction(MTP)机制MTP机制允许在一次主模型推理过程中同时计算验证多个Token在未达到计算瓶颈前可以通过较少的时延增加有机会获得更多的输出Token从而降低单Token的推理耗时。DeepSeek-V4涉及的滑窗/压缩/稀疏Hybrid Attention算法复杂度较高为适配MTP带来了新的挑战。Main Model方案Cache设计本模型针对Window KV和Compressor模块的kv_state/score_state设计了Ring Buffer可以通过block_table与slot_mapping实现对少数几块Cache的内存复用其余KV Cache的内存按照压缩后的最大长度申请。两种Cache管理方式的对比实现如下图所示MTP场景适配假如主模型在Decode阶段每个Step每个Batch需要额外验证next_n个Token。在每个Step的推理过程中算子正常在kv_length维度递进如果满足CSA/HCA的压缩条件就进行压缩。这一场景需要沿用LI和SAS算子内置的梯形掩码确保待验证Token的压缩Cache不参与主模型Token的计算。假如有MTP Token校验不被接受需要在下一个Step重新推导该Token。重新推导的场景需要为Compressor的kv_state/score_state额外缓存。如下图所示左侧是kv_state/score_state缓存范围右侧是Indexer/Attention计算使用梯形掩码。结合本模型的Ring Buffer设计只需要提前申请更大的Buffer就可以自然实现额外缓存的动作。需要缓存的Cache大小可以以compress_ratio个Token为一组进行统计具体多少组Token的计算公式为 $$ \mathrm{num_ratio_group} (1 \ \mathrm{if} \ \mathrm{next_n}\ 0 \ \mathrm{else}\ 2) \mathrm{overlap} $$其中overlap在CSA等于1在HCA等于0。num_ratio_group里预留了余数Token和可能需要重新压缩的前序Token。每个Batch需要的Cache Block个数为 $$ \mathrm{ceil}(\mathrm{num_ratio_group} * \mathrm{ratio} \ / \ \mathrm{block_size}) $$MTP Spec Model方案模型结构MTP模型仅使用Window Attention (SWA)。Cache结构在当前实现中next_n个Draft Token共享一份MTP权重和KV Cache。性能分析MTP机制允许Decode在一次主模型推理过程中同时对小模型投机的next_n个Token批量Verify在相似的数据搬运下有机会能得到更多的预测Token提高了Decode推理阶段的计算访存比Attention部分在MTP场景下CSA的FA计算在极端情况下需要搬运的KV Cache数据量是非MTP场景的next_n 1倍一定程度上增加了离散访存代价。但是SWA/HCA/LI的Cache搬运量与非MTP场景几乎一致能够自然地提升计算访存比。其余算子如Matmul等在MTP机制下可以复用权重搬运达到更好的计算访存比因此MTP有比较可观的加速比。在高吞吐场景下使用多个Draft Token很容易触及计算瓶颈因此可采用MTP1进行加速在低时延场景下计算密度更小可采用MTP3获得更大加速比量化策略Int8量化策略基于Atlas-A3 Pod平台本实践支持了Int8 W8A8量化。相对于BF16推理W8A8量化可以有效降低端到端时延提升系统吞吐。量化策略如下MLAPrologq_b_proj使用W8A8量化其它Linear不量化KV Cache使用C16IndexerPrologq_b_proj使用W8A8indexer_weight不量化indexer_q使用A8量化Indexer Cache使用C8量化LightningIndexer:batch_matmul使用Int8计算Compressor: Linear不量化MLAEpilogo_a_proj不量化o_b_proj使用W8A8量化MoE路由和共享专家的Linear使用W8A8量化LMHead不量化。注 W8A8W8指权重使用静态Per-Channel Int8量化A8指数据使用动态Per-Token Int8量化 A8C8A8表示LI中的Q使用动态Per-Token-Head Int8量化Indexer Cache使用动态Per-Token-Head Int8量化。出于性能考虑只对参数量较多的部分Linear模块进行量化。因此Linear模块里只对MLA的q_b_proj,o_b_proj和Indexer的q_b_proj进行量化KV Cache暂时维持BF16存算。LI通过A8C8量化进一步降低计算时延同步优化TTFT和TPOT。Hybrid MXFP8-MXFP4量化策略基于950PR/DT平台本实践支持了原生Hybrid FP8-MXFP4量化方式同时也支持了使用MXFP8替换原生FP8格式的Linear模块在Prefill和Decode高吞吐场景可以进一步提升算力利用率提高整体性能。Hybrid MXFP8-MXFP4整体量化策略如下MLAPrologq_a_proj,q_b_proj,kv_proj使用W8A8量化KV Cache采用C8伪量化IndexerPrologq_b_proj使用W8A8indexer_weight不量化indexer_q使用A8量化Indexer Cache使用C8量化LightningIndexer:batch_matmul使用FP8计算Compressor: Linear不量化MLAEpilogo_a_proj和o_b_proj使用W8A8量化MoE路由专家的Linear使用W4A8量化共享专家的Linear使用W8A8量化LMHead不量化。注 W8A8W8和A8指MXFP8量化 LI A8C8A8表示LI中的Q使用动态Per-Token-Head FP8量化Scale格式为FP32Indexer Cache使用动态Per-Token-Head FP8量化Scale格式为FP32 KV Cache C8表示KV Cache使用动态Per-Group-64 FP8量化Scale格式为E8M0。MLAProlog KV Cache的量化策略使用了动态存8算16。在超长序列情况下C8 KV Cache内存优化2倍。LI通过A8C8获取计算收益降低LI计算时延同步优化TTFT和TPOT。多流并行优化Attention多流并行在Attention计算前的MLAProlog模块Query的计算流与KV的计算流有计算并行的空间在CSA时LI与CSA Compressor无数据依赖同样存在并行空间。因此我们可以通过CANN软件栈提供的算子控核和多流并行技术实现Attention模块的细粒度的计算流控制提升推理性能。以CSA为例可以实现如下方案MLAProlog中的kv_projq_b_proj等Matmul使用Cube核进行计算与q_rms_norm等使用Vector核计算的算子可以并行q_b_proj后的rms_norm和rope可以和LI的li_q_b_proj并行计算LI和CSA的Compressor模块可以通过CV控核确保算子分配到合适的Cube和Vector核数在多流并行时减少计算资源抢占对性能的影响从而完全掩盖CSA的CompressorHCA中没有LI可以直接用MLAProlog计算掩盖部分Compressor。部分逻辑简化表示算子框的长度不代表实际的执行耗时仅作为图示。MoE共享路由多流并行在MoE模块中共享专家和路由专家也存在计算与计算、计算与通信的并行机会通过多流并行可以在基本不影响路由专家的同时掩盖共享专家的计算耗时。本实践针对Int8和MXFP8量化场景实现了专家多流并行可获得较大收益。实现如下图所示AICPU Scheduler算子多流并行Attention及LI这类算子在计算时依赖实际上下文长度本次实践中提供了对应的AICPU Scheduler算子可以在算子执行前计算出分核策略减少算子执行负担提升性能。 以SparseAttnSharedkv为例提供如下接口npu_sparse_attn_sharedkv_metadata根据cu_seqlens_q、seqused_kv、cmp_ratio等算子入参得到包含关键负载均衡信息的Tilingnpu_sparse_attn_sharedkv根据npu_sparse_attn_sharedkv_metadata输出的tiling信息执行Attention计算整网单轮推理中每个SASSWA, CSA, HCA, LI算子依赖的AICPU Scheduler算子只需要执行一次Tiling信息可在不同层的算子间复用。因此Tiling计算与Embedding及MLAProlog计算存在并行机会通过多流并行可以有效掩盖Tiling计算的耗时。以SWA为例参考伪代码如下# prepare metadata metadata_stream torch.npu.Stream() event_0, event_1 torch.npu.Event(), torch.npu.Event() input_tensor.record_stream(metadata_stream) event_0.record() with torch.npu.stream(metadata_stream): event_0.wait() attn_metadata torch.ops.custom.npu_sparse_attn_sharedkv_metadata(input_tensor, ..., cmp_ratio1) event_1.record() # input embedding calculation (skip details) for layer in model_layers: # attention forward event_1.wait() attn_output torch.ops.custom.npu_sparse_attn_sharedkv(input_tensor, ..., metadataattn_metadata) # moe forward (skip details)整网单轮推理需要调用4次AICPU Scheduler算子其多流并行方案图如下。Benchmark下述Benchmark数据均基于Offine推理模式采集不包含Serving调度和框架负载均衡影响。950DTprofile_data在950DT平台上本实践使用16卡部署W8A8C8模型部署策略采用 Attention Data Parallel (DP) 和 MoE Expert Parallel (EP)并行。DeepSeek-V4 Flash 8K序列场景Decode单卡吞吐1625TPS10ms对应的Profile数据已在上方链接开源不同Batch Size和序列长度的性能Benchmark测试如下950DT Deepseek-V4 Flash BenchmarkGlobal Batch SizeChipsMTPDataTypeSeq LengthTPOT (ms)Throughput (Tokens/p/s)16163Hybrid MXFP8-MXFP481926.71148.96256163Hybrid MXFP8-MXFP481929.841625.311536161Hybrid MXFP8-MXFP4819220.334722.2216163Hybrid MXFP8-MXFP41310727.80128.15256163Hybrid MXFP8-MXFP413107212.831246.89768161Hybrid MXFP8-MXFP413107221.652217.09256163Hybrid FP8-MXFP4819211.061447.001536161Hybrid FP8-MXFP4819224.283953.49DeepSeek-V4 Pro 8K序列场景Decode单卡吞吐不同Batch Size和序列长度的性能Benchmark测试如下950DT Deepseek-V4 Pro BenchmarkGlobal Batch SizeChipsMTPDataTypeSeq LengthTPOT (ms)Throughput (Tokens/p/s)16163Hybrid MXFP8-MXFP4819217.6456.764163Hybrid MXFP8-MXFP4819219.03210.16128163Hybrid MXFP8-MXFP4819220.61388.2316163Hybrid MXFP8-MXFP413107219.4651.3864163Hybrid MXFP8-MXFP413107221.23188.42注性能数据基于MTP投机与强制EPLB配置采集MTP3场景下平均3个Draft Token中Accepted Token个数为1.44MTP1场景下平均1个Draft Token中Accepted Token个数为0.7用户可按照数据集实际接受率自行折算benchmark性能。注Hybrid FP8-MXFP4指转换后的权重中部分Matmul FP8量化 MoE模块MXFP4量化Hybrid MXFP8-MXFP4指转换后的权重中部分Matmul MXFP8量化 MoE模块MXFP4量化详情见量化策略。Atlas-A3 Podprofile_data在Atlas-A3 Pod平台上本实践使用64卡部署W8A8C16模型部署策略采用Attention Data Parallel (DP)和MoE Expert Parallel (EP)并行。DeepSeek-V4 Flash 8K序列场景Decode单卡吞吐可达4388TPS30ms对应的Profile数据已在上方链接开源不同场景的性能Benchmark测试如下Atlas-A3 Pod Deepseek-V4 Flash BenchmarkGlobal Batch SizeChipsMTPSeq LengthTPOT (ms)Throughput (Tokens/p/s)7168641819227.8240258192641819229.174388注LI Cache使用Int8量化KV Cache使用BF16计算。性能数据基于MTP1与强制EPLB配置采集平均1个Draft Token中Accepted Token个数为0.7用户可按照数据集实际接受率自行折算benchmark性能。Future PlanAtlas A3 DeepSeek-V4 Pro模型支持在Atlas平台泛化支持DeepSeek-V4 Pro模型量化在950PR/DT平台将进一步支持HiFloat8量化方式丰富量化形态SuperKernel使能Super Kernel进一步降低算子启动开销与调度间隙提升计算执行效率融合Kernel性能优化通过Flash Decode等技术优化长序列场景下的LI/SAS性能。【免费下载链接】cann-recipes-infer本项目针对LLM与多模态模型推理业务中的典型模型、加速算法提供基于CANN平台的优化样例项目地址: https://gitcode.com/cann/cann-recipes-infer创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考