王璽源《基于昇騰CANN的訓推開源軟件支持與實踐》.pdf

《王璽源《基于昇騰CANN的訓推開源軟件支持與實踐》.pdf》由會員分享，可在線閱讀，更多相關《王璽源《基于昇騰CANN的訓推開源軟件支持與實踐》.pdf（32頁珍藏版）》請在三個皮匠報告上搜索。

1、基于昇騰CANN的訓推開源軟件支持與實踐演講人：王璽源能運行 權重文件 模型結構 運行腳本能復現訓練數據訓練方法隨機種子能落地加速技術調優方法集群部署開源大模型開源了什么易用、高性能的開源全棧推理服務框架開源時間：2023年6月開源組織：伯克利Sky Computing Lab（前RISELab、AMPLab），曾孵 化出了Apache Spark、Ray、Alluxio等著名開源項目。項目介紹：vLLM 以PagedAttention 為核心算法提升內存利用率，支持 100+生成式大語言模型，能夠做到與 Hugging Face Transformers 相比 24 倍的吞吐量。競爭力特性：

2、PagedAttetion為起點，逐漸新增主流推理特性，學習Pytorch，以易用性和多樣性為主打賣點。能運行權重文件：基于pytorch和HF safetensor，原生支持，無需轉換模型結構：基于Pytorch重寫，原生支持HF transformers運行腳本:vLLM自研實現多種運行方式能落地加速技術：自研支持Paged Attention算法，支持Chunked Prefil、Prefix Cache、PD分離等加速技術，支持各種量化算法，支持pile圖模式，支持trition等自定義算子調優方法：支持多種Lora微調方法，支持海量自定義參數，支持benchmark打點分析。集群部署

3、：支持在線/離線，支持多機多卡，支持MP、Ray、Kubernetes多種部署方式from vllm import LLM,SamplingParams#用戶輸入prompts=Hello,my name is,The president of the United States is,The capital of France is,The future of AI is,#初始化vLLM，載入模型llm=LLM(model=Qwen/Qwen2.5-0.5B-Instruct)#執行推理outputs=llm.generate(prompts,sampling_params)#打印輸出fo

4、r output in outputs:prompt=output.promptgenerated_text=output.outputs0.textprint(fPrompt:prompt!r,Generated text:generated_text!r)config.jsonqwen.safetensorQwen2ForCausalLM1.讀取config.json，獲取模型結構名稱2.初始化模型，載入模型權重https:/huggingface.co/Qwen/Qwen2.5-0.5B-Instructclass Qwen2ForCausalLMself.model=Qwen2Mode

5、lself.logits_processorself.samplerclass Qwen2Modelself.embed_tokensself.layers=Qwen2DecoderLayer,Qwen2DecoderLayer,.self.normclass Qwen2DecoderLayerself.self_attn=Qwen2Attentionself.mlp=Qwen2MLPself.input_layernormself.post_attention_layernormclass Qwen2Attentionself.attn=Attentionself.qkv_projself.

6、o_projself.rotary_embclass Qwen2MLPself.act_fn=SiluAndMulself.gate_up_projself.down_projhttps:/ vllm import LLM,SamplingParams#用戶輸入prompts=Hello,my name is,The president of the United States is,The capital of France is,The future of AI is,#初始化vLLM，載入模型llm=LLM(model=Qwen/Qwen2.5-0.5B-Instruct)#執行推理ou

7、tputs=llm.generate(prompts,sampling_params)#打印輸出for output in outputs:prompt=output.promptgenerated_text=output.outputs0.textprint(fPrompt:prompt!r,Generated text:generated_text!r)1.接收請求，進行前處理2.發送待處理數據到隊列3.循環檢測隊列，有請求進來后，開始調度、推理，把結果放到輸出隊列4.對輸出進行后處理5.返回結果給用戶解決思路：1.支持多種attention后端，支持attention后端和硬件設備多對多

8、配合使用。2.插件化設計，支持硬件設備可擴展，支持自定義模塊實現3.針對不同硬件平臺,利用特定的硬件加速庫（如 CUDA、ROCm、CANN）進行優化核心問題：不同硬件平臺（如GPU、NPU 等）具有不同的架構特性，需要針對每種硬件優化算子實現，不同的硬件平臺對 Attention 后端的支持程度也不同，如何確保多后端在各種硬件上的高效運行是一個難點vLLMplugin interfacePlatformAttentionModel RunnerCustom OpWorkerCommunicatorvLLM plugin mechanismPython entry_pointsvLLMExec

9、utorLLMchatgenerate encodescoreWorker GPU/CPU/XPU/NPUScheduler pluginModel Runner GPU/CPU/XPU/NPULLM EngineCustom kernels APICache Engine Attention BackendDistributed CommunicatorDisaggregated PrefillingAttention、硬件多后端支持CANNvLLMExecutor后處理融合算子Worker Backend PluginScheduler Model Runner Backend Plugi

10、nLLM EngineModelingSampling Cache Engine NPU custom kernels量化kernelsCustom Ops API AdaptorEntryPoints API 請求入口LayersCustom kernels APIvllm-ascendFunctionalWorker NPU BackendModel Runner NPU BackendTorch/Torch-NPU Communicator NPU Backend解決思路：針對多batch（多用戶并行使用）推理場景，通過對Batch的時序優化，以達到去除空泡，提高NPU利用率和吞吐量優化

11、前：計算資源空泡優化后：充分利用資源核心問題：在輸入輸出長度差異、新請求動態加入等場景，批量推理請求下NPU資源空閑，產生算力浪費vLLM調度策略PPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPDDPPDDDDD連續批處理（Continuous Batching）核心問題：非PD分離部署場景，Prefill推理會打斷Decode推理，較長的Prefill序列會影響Decode的響應時延解決思路：Prefill屬于算力瓶頸，Decode屬于帶寬瓶頸，將Prefill數據切塊，每個chunk數據塊疊加多個Decode請求，使得處于prefill階段的請求和處于decod

12、e階段的請求能組成一個batch同時計算，而在組建這樣的batch的過程中，充分最大化GPU計算單元利用率、最小化IO讀寫次數。Chunked Prefill 動態分割融合解決思路：1.PagedAttention 的核心思想是引入分頁機制,將每個序列的KV緩存分割成固定大小的小塊（blocks），每塊包含固定數量的token。通過這種方式，避免了為整個序列一次性分配大塊顯存2.動態顯存管理,通過按需分配和釋放顯存塊，PagedAttention 能夠根據實際需求動態調整顯存使用，避免了傳統方法中顯存浪費的問題核心問題：1.在傳統的注意力機制中，鍵值對（Key-Value Pairs）需要為每

13、個序列分配一塊連續的大塊顯存，導致顯存利用率低下且難以擴展，顯存占用過高2.長序列推理時，注意力計算需要頻繁訪問和存儲大量的KV緩存數據，容易造成內存帶寬瓶頸，影響推理速度3.不同請求的序列長度可能差異較大，傳統方法難以靈活處理動態長度的序列，可能導致顯存浪費或調度效率低下Paged Attentiont1at1bendt2at2bt2ct2dendt3at3bt3cendseq1seq2seq3內存被劃分成block按需分配各序列輸出不同時才分配獨立的block解決思路：模型參數量大時，通過TP、PP、EP切分減少權重對單卡顯存占用的開銷，預留更多的顯存給KVCache，支持更大的請求數，滿

14、足高性價比的訴求核心問題：單卡推理無法滿足裝得下（顯存容量不足）和推得快（時延低）基于單機的TP并行基于多機的TP/PP/EP并行TP并行：參數拆分DP并行：數據拆分PP并行：模型拆分EP并行：專家模型拆分routerTP、PP、EP、DP并行策略GPU0Qwen3DecoderLayer0:4embed_tokenGPU2Qwen3DecoderLayer4:8Qwen3DecoderLayer8:200GPU4Qwen3DecoderLayer12:16Qwen3DecoderLayer16:20GPU6Qwen3DecoderLayer20:24NormGPU1Qwen3DecoderL

15、ayer0:4embed_tokenGPU3Qwen3DecoderLayer4:8Qwen3DecoderLayer8:12GPU5Qwen3DecoderLayer12:16Qwen3DecoderLayer16:20GPU7Qwen3DecoderLayer20:24Normall_reduce/all_getherTP2+PP4+DP2并行GPU8Qwen3DecoderLayer0:4embed_tokenGPU10Qwen3DecoderLayer4:8Qwen3DecoderLayer8:12GPU12Qwen3DecoderLayer12:16Qwen3DecoderLayer

16、16:20GPU14Qwen3DecoderLayer20:24NormGPU9Qwen3DecoderLayer0:4embed_tokenGPU11Qwen3DecoderLayer4:8Qwen3DecoderLayer8:12GPU13Qwen3DecoderLayer12:16Qwen3DecoderLayer16:20GPU15Qwen3DecoderLayer20:24Normall_reduce/all_getherdata1data2data解決思路：1.將整網計算圖切分為多個子圖，減少調度開銷，因為一次可以批量處理多個操作2.通過預編譯計算圖，進一步提高硬件資源的利用率核心

17、問題：單算子場景，計算圖的每個操作都需要單獨調度，這會導致頻繁的等待時間和上下文切換，增加延遲，隨著推理過程的進行，顯存分配和釋放可能會導致碎片化問題，降低顯存利用率V0:整圖編譯，不支持動態shapeV1:分段編譯，支持動態shape，但CPU overhead略有提升，整體性能更優Graph模式vllm-ascend的ACLGraph正在支持中解決思路：1.利用 NPU CANN編程技術，設計高效的自定義算子2.將自注意力計算涉及的多個算子（如QKV 計算、Softmax、矩陣乘法等）融合為一個高效算子，例如業界熟知的 FlashAttention核心問題：原生算子可能無法充分利用硬件資源

18、，例如在多卡并行環境中，算子的實現需要考慮分布式通信的開銷RMSNormforward_cudaforward_ootrotary_embeddingtorch.ops._CDispatch CUDADispatch NPUvLLM支持基于pytorch和CUDA/CANN兩種方式的自定義/融合算子的接入和實現。pytorch實現CUDA/CANN實現自定義/融合算子以Qwen3為例，vLLM+Ascend+CANN做了什么支持？ModelQwen方法vLLM算子對應torch接口描述Qwen3Modelembed_tokensVocabParallelEmbeddingtorch.nn.fu

19、ncational.embedding輸入token向量化Qwen3DecoderLayerinput_layernormRMSNormtorch_npu.npu_add_rms_normtorch_npu.npu_rms_norm均方根層歸一化（RMSNorm：Root Mean Square Layer Normalization）Qwen3Attentionqkv_projQKVParallelLineartorch.nn.linear線性變換q_norm,k_normRMSNormtorch.rsqrtQK均方根歸一化rotary_embRotaryEmbeddingtorch_npu

20、._npu_rotary_embedding旋轉式位置編碼（RoPE:Rotary Postion Embedding）attentionAttentiontorch_npu._npu_reshape_and_cachetorch_npu._npu_flash_attentiontorch_npu._npu_paged_attentiontransformer self-attentiono_projRowParallelLineartorch.nn.linear線性變換post_layernormRMSNormtorch_npu.npu_add_rms_normtorch_npu.npu_r

21、ms_norm均方根層歸一化（RMSNorm：Root Mean Square Layer Normalization）Qwen3MLPgate_up_projMergedColumnParallelLineartorch.nn.linear線性變換act_fnSiluAndMultorch_npu.npu_swigluSiluAndMul:SwiGLU激活函數+乘法融合算子down_projRowParallelLineartorch.nn.linear線性變換normRMSNormtorch_npu.npu_add_rms_normtorch_npu.npu_rms_norm均方根層歸一化

22、（RMSNorm：Root Mean Square Layer Normalization）以DeepSeek為例，vLLM+Ascend+CANN做了什么優化？通信、計算融合實現通算開銷掩蓋AllToAllV通信算子融合MoE算子總耗時=T計算+T通信總耗時=MAX(T計算，T通信)+拖尾開銷通信效率提升 15%+整網性能提升 10%+獨創多算力軟硬協同通信算法大幅降低單次通信時延AI-VAI-CPURoCEDataData A0Data B0軟硬協同通信通算融合及軟硬協同通信算法整網性能提升100%+MoE專家雙流并行技術整網性能提升5%10%MLA前處理融合算子，實現CV并行整網性能提升

23、10%+共享專家和路由專家的Cube和Vector可以使用兩個Stream進行并行計算，縮短計算時延Rope3全掩蓋Rmsnorm3部分掩蓋Concat2消除Split2消除ReshapeandCache1全掩蓋Matmul3降頭開銷通過融合大算子，消除推理場景MLA前處理算子多、shape小等問題AS IS：算子串行，頻繁占用內存、通信等資源TO BE：多算子融合，一次下發實現CV并行計算算子串行融合算子計算耗時降低70%算子融合方案收益MoeGatingTopkSoftmax將Softmax、topk融合，減少訪存增量場景：70%全量場景：100%+MoeInitRouting對token

24、進行專家重排，支持dropless、drop and pad的能力，并計算各專家的token數。將這些能力融合到一個算子中，避免了小算子拼接中重復計算邏輯以及不高效的histogram邏輯等增量場景：持平全量場景：20%GroupedMatMul支持分組MatMul，支持在device側按照專家數進行并發計算，避免在host側分組帶來的Host Device同步等問題。極大的提升了性能增量訪存利用率：90%全量長序列cube利用率：90%MoE模型關鍵流程節點優化，融合算子性能提升20-70%多模態理解圖像加載和預處理下沉，解碼和預處理加速88%圖片解碼ResizeToTensorNormal

25、ize中央處理器昇騰Device側支持硬件解碼+預處理，大幅減少預處理耗時圖片解碼ResizeToTensorNormalizeDVPPAIC940 ms96 msDevice1Device2Device3Device4按模型layer層切分到多個設備馬春梅馬夏梅馬秋梅馬冬梅Device1Device2Device3Device4DataMini batchMini batchMini batchMini batch數據切分到多個設備對模型某一layer內數據切分到多個設備X00X01X10X11Device1Device3Device2Device4行列切分X00 X01Device1Dev

26、ice3Device2Device4Device1Device3Device2Device4Device1Device3Device2Device4X00 X01X10 X11X10 X11001000100111011100011011000110110001101100011011行切分+復制列切分+復制全復制模型需要更細粒度并行切分到AI集群節約片上內存內存放下更大的模型優化器縮短大模型訓練時間TTAAttention模塊加速訓練切得好存的下數據并行流水線并行模型并行優化器并行|多副本并行|細粒度流水并行 選擇性重計算Self-Attention中的softmax和dropout算子計算

27、結果占用內存大但計算量少不保留正向計算結果到反向，在反向計算流程可以重新計算softmax和dropout的結果重計算時間換空間的優化策略：把一些前向計算的結果清除，當需要再次用到這些計算結果再根據之前緩存的CheckPoint重新計算節點中的每個值都要被保存下來，用以在一次反向傳播中計算梯度在內存中只保存一些節點，同時在需要時重新計算其他節點節點內通信量為百GB級，以allreduce為主。節點間通信量為GB級，包括allreduce和p2p，大部分可以被計算掩蓋。并行方式特征對通信的需求張量并行(TP)通信量巨大（百GB），通信時間不可掩蓋節點內allreduce超高帶寬Pipeline并

28、行(PP)通信量較大（模型相關，百M-GB級）通信時間不可掩蓋/流水可掩蓋節點間P2P中帶寬數據并行(DP)通信量大（GB級）通信時間計算可大部分掩蓋節點間allreduce高帶寬大模型訓練通信特點周期性計算和通信周期性重復迭代，每輪迭代的通信模式一致迭代迭代迭代迭代模型訓練流量示意圖流少量大每輪迭代，流條數少而通信量巨大，不同節點間的流量同步、傳輸數據量 GB降低通信開銷例：利用通信帶寬優化節點間 all-reduce場景-SDMA&RDMA通信流水化節點內 all-reduce場景-TP通信復用RDMA帶寬節點內通信需要超高帶寬，節點內通信期間，節點間的RDMA通信鏈路通常是空閑的，將數據

29、按照一定比例切分，分別由節點內SDMA通信、節點間的RDMA通信同時傳輸，從而充分利用節點內/間的通信鏈路并發，提升通信性能。同一時刻，節點間鏈路和節點內鏈路只有一個在工作，由此會造成帶寬的浪費將通信數據切片排布成流水，使節點內和節點間的鏈路并發利用起來通過小步快跑方式節省通信耗時節點內reduce scatter節點間reduce scatter節點間all-gather節點內all-gather以RLHF為例，vLLM+verl+Ascend+CANN做了什么優化？vLLM支持SPMD部署，提高RLHF場景吞吐https:/ ascend支持sleep mode特性，滿足RLHF場景訓推共

30、卡需求CANNVerl/openRLHFsleep/wake_upNPUCPUswitchvLLMvllm-ascendaclrtCreateContextaclrtSetCurrentContextaclrtMallocPhysicalaclrtFreePhysicalaclrtMapMemaclrtUnmapMemaclrtDrvMemHandle昇騰CANN的開源使能全面支持業界AI框架，原生適配PyTorch社區版本AI框架昇騰硬件昇騰系列硬件.GE 圖引擎圖編譯、圖執行，使能處理器并行加速，提升計算性能Ascend C 算子編程語言支持融合算子極簡開發C/C+規范|高底層API|混合

31、編程Driver 驅動Runtime 運行時控制流|內存管理|任務調度|設備管理算子加速庫覆蓋Transformer網絡提供大模型結構泛化的高性能融合算子HCCL 集合通信庫高效實現單機多卡、多機多卡分布式訓練高性能集合通信算法計算通信統一硬化調度計算通信高性能并發BiSheng Compiler 畢昇編譯器異構編譯|全局優化|指令親和操作系統CPU應用程序for(int i=0;i 16;i+)for(int j=0;j 16;j+)for(int k=0;k 16;k+)cij+=aik*bkj;運算器載入操作系統內存從內存讀取指令執行CPUNPU計算指令分配計算結果返還操作系統應用程序提

32、供硬件指令硬件指令封裝為用戶可操作接口應用程序封裝高級語言NPU資源管理/調度內存管理進程管理CPU的資源管理NPU編譯優化NPU編碼使能 for(int i=0;i 16;i+)for(int j=0;j 16;j+)cij=ai:*+b:j;通用計算操作系統使能CPU硬件指令抽象編碼及執行AI計算CANN使能CPU與NPU協同編碼，發揮NPU計算能力通過NPU卸載CPU算力文件管理驅動管理 控制器寄存器邏輯控制 串行運算c:=a:*+b:vectorcube邏輯控制并行計算NPU驅動NPU協同編碼使能NPU硬件資源管理/調度NPU驅動并行計算部分編譯&優化指令載入讀取指令模型應用算力工具鏈

33、框架加速庫/引擎目前正在、已經昇騰原生支持開源軟件：微調、工具鏈：Huggingface transformers(since v4.32,2023):huggingface/transformers/pull/24879Huggingface peft(since 0.5.0,2023):huggingface/peft/pull/772Huggingface accelerate(since 0.22.0,2023):huggingface/accelerate/pull/1676LLaMA-Factory(since v0.7.1,2024):hiyouga/LLaMA-Factory/

34、pull/975FastChat(since v0.2.29,2023):lm-sys/FastChat/pull/2422stable-diffusion-webui(since v1.8.0,2024):stable-diffusion-webui/pull/14801text-generation-webui(since v1.8,2024):text-generation-webui/pull/5541OpenCompass(since v0.3.4,2024):opencompass/pull/1250&1618lm-evaluation-harness(since v0.4.4,2

35、024):lm-evaluation-harness/pull/1886ComfyUI(since Dec.2024):ComfyUI/pull/5436DeepSpeed(since 2024.01)推理引擎：vLLM vllm-project/vllm-ascendONNX Runtime(since v1.13.1)microsoft/onnxruntime/pull/12416llama.cpp(since July.2024)llama.cpp/pull/6035Whisper.cpp(since Aug,2024)whisper.cpp/pull/2336AI框架：PyTorch(since 2.1,2023)pytorch/releases/tag/v2.1.0MindSpore(since 1.0,2020)vLLMvLLM Ascend v0.8.4rc1 releaseAscend v0.8.4rc1 releasevLLM Ascend First RC Release for vLLM v0.8.4$docker pull quay.io/ascend/vllm-ascend:v0.8.4rc1$pip install vllm vllm-ascendDoc:https:/vllm-ascend.readthedocs.ioFeedback: