)
在 Atlas 上跑通 DeepSeek-R1KTransformers 昇騰 NPU 部署實戰(zhàn)【免費下載鏈接】ktransformersA Flexible Framework for Experiencing Heterogeneous LLM Inference/Fine-tune Optimizations項目地址: https://gitcode.com/GitHub_Trending/ktr/ktransformers導(dǎo)語為什么要把 LLM 搬到昇騰 NPU 上跑最直接的答案是內(nèi)存和成本。DeepSeek-R1 這類滿血 MoE 模型的路由專家權(quán)重體量巨大GPU 集群要么買不起、要么排隊。Atlas 服務(wù)器配 1TB DDR5用 CPU NPU 異構(gòu)分工承接推理KTransformers 的 CPU 推理內(nèi)核正好吃下這條路徑——專家權(quán)重放在內(nèi)存里注意力與算子下沉到 NPU 執(zhí)行。本文是一次真實部署的復(fù)盤從 Atlas 硬件、CANN 軟件棧、雙權(quán)重合并到 balance_serve 服務(wù)啟動與性能核對每一步的坑都標在原地。部署前避坑清單先知道會踩什么坑后面裝環(huán)境時心里有數(shù)transformers 版本被釘死在4.57.1其他版本未驗證裝錯了直接報結(jié)構(gòu)解析異常。torch_npu 不能直接用 pypi 預(yù)編譯包。因為涉及新增算子必須從源碼編譯 v2.5.1 分支且編譯后版本號里的哈希后綴要手動去掉見下文。兩份權(quán)重缺一不可。Q4 的 GGUF 與 W8A8 的 safetensor 必須先用合并腳本合成一份只放一份進模型目錄服務(wù)起不來。400GB 物理內(nèi)存是下限。滿血版 DeepSeek-R1/V3 的路由專家權(quán)重需要約 400GB 物理內(nèi)存內(nèi)存不足的機器別硬試。CANN 環(huán)境變量沒 source一切白搭。libhccl.so、libascend_hal.so缺失都是同一個原因速查表里給了解法這里不重復(fù)展開。搭建 Atlas 硬件與操作系統(tǒng)本節(jié)目標是把一臺 Atlas 2UP 變成可用的 300I A2 推理節(jié)點。硬件與系統(tǒng)版本按下表核對項規(guī)格服務(wù)器Atlas 2UPNPU300I A2當前 KTransformers 適配的 NPU 型號CPUHUAWEI Kunpeng 920 7270Z內(nèi)存DDR5 服務(wù)器內(nèi)存1TB操作系統(tǒng)Ubuntu 22.04 for aarch64內(nèi)核5.15.0-25-generic裝完系統(tǒng)后做兩件事關(guān)閉自動更新并記錄好 CANN、NPU 驅(qū)動的實際安裝路徑——后面 source 環(huán)境變量要用。硬件插拔與固件確認建議拉原廠支持一起完成NPU 的固件版本直接影響后面 Kernel 能否加載。配置 CANN 軟件棧軟件棧分四層HDK 固件驅(qū)動 → CANN → Python 環(huán)境 → torch_npu。順序不能亂版本必須嚴格對齊下表任何一層漂移都會在算子加載階段報錯組件版本Ascend HDK25.3.RC1CANN8.3.RC1.alpha003需裝 ToolKit、Kernel、NNAL 三件Python3.11conda 環(huán)境一行conda create -n py311 python3.11即可PyTorchtorch2.5.1/torchvision0.20.1/torchaudio2.5.1transformers4.57.1必須無替代torch_npuv2.5.1 分支源碼編譯torch_npu 編譯前先把 CANN 與 NNAL 的環(huán)境加載進當前 shellsource /usr/local/Ascend/ascend-toolkit/set_env.sh source /usr/local/Ascend/nnal/atb/set_env.sh?? 編譯過程對 github、gitcode 等平臺的網(wǎng)絡(luò)訪問敏感網(wǎng)絡(luò)不暢通時子模塊拉取會靜默失敗。從源碼倉庫Gitcode 上的 Ascend/pytorch獲取代碼后編譯 v2.5.1 分支。編譯裝好后還有一個反直覺的步驟打開 site-packages 下torch_npu/version.py路徑用pip show torch_npu確認把形如__version__ 2.5.1.post4git69550dfc的版本號改為__version__ 2.5.1.post4去掉哈希后綴。環(huán)境對版本號有嚴格匹配帶后綴會直接被拒。合并 Q4 與 W8A8 雙權(quán)重KTransformers 對 NPU 路徑的精度要求決定了權(quán)重要走雙份合并Q4_K_M 的 GGUF 權(quán)重負責(zé)路由專家的 CPU 側(cè)存儲W8A8 的 safetensor 權(quán)重負責(zé) NPU 側(cè)算子。兩份原始權(quán)重都下載就位后跑倉庫里的合并腳本python merge_safetensor_gguf.py \ --safetensor_path /path/to/DeepSeek-R1-W8A8 \ --gguf_path /path/to/DeepSeek-R1-Q4_K_M \ --output_path /output/merged腳本位于 merge_tensors/。合并完成后后續(xù)啟動參數(shù)只指向合并后的目錄兩份原始權(quán)重不再參與推理。初始化項目與編譯擴展克隆倉庫并拉取子模塊git clone https://gitcode.com/gh_mirrors/ktr/ktransformers cd ktransformers git submodule update --init --recursive進入編譯前先安裝構(gòu)建依賴并加載 CANN 環(huán)境source /usr/local/Ascend/ascend-toolkit/set_env.sh apt install cmake libhwloc-dev pkg-config bash ./install.shinstall.sh 會編譯 CPU 側(cè)的 kt-kernel 擴展與 llamafile 算子庫。?? 在 aarch64ARM82上如果鏈接階段報iqk_mul_mat相關(guān)錯誤把 third_party/llamafile/iqk_mul_mat_arm82.cpp 文件內(nèi)的兩行宏定義注釋掉即可通過編譯// #define iqk_mul_mat iqk_mul_mat_arm82 // #define iqk_mul_mat_moe iqk_mul_mat_moe_arm82這是 aarch64 工具鏈的已知適配點x86 機器不用動這個文件。啟動 balance_serve 推理服務(wù)服務(wù)入口是ktransformers/server/main.py關(guān)鍵參數(shù)與 NPU 優(yōu)化規(guī)則文件一起給出export USE_MERGE0 export INF_NAN_MODE_FORCE_DISABLE1 export TASK_QUEUE_ENABLE0 source /usr/local/Ascend/ascend-toolkit/set_env.sh source /usr/local/Ascend/nnal/atb/set_env.sh python ktransformers/server/main.py \ --port 10002 \ --model_path merged_weights \ --gguf_path merged_weights \ --model_name DeepSeekV3ForCausalLM \ --optimize_config_path ./ktransformers/optimize/optimize_rules/npu/DeepSeek-V3-Chat-300IA2-npu-serve.yaml \ --max_new_tokens 1024 \ --cache_lens 20480 \ --backend_type balance_serve環(huán)境變量逐個說明故障排查時只需對照這一段速查表不重復(fù)TASK_QUEUE_ENABLE0關(guān)閉任務(wù)隊列保證算子下發(fā)順序嚴格有序這是開啟圖下沉的前置條件USE_BALANCE_SERVE1與USE_NUMA1啟用 balance_serve 后端與 NUMA 綁定啟動腳本中按需導(dǎo)出USE_MERGE0權(quán)重已離線合并運行時不再做在線合并INF_NAN_MODE_FORCE_DISABLE1禁用推理期的 NaN 強制檢查省去每步的開銷--backend_type balance_serve指定服務(wù)后端--cache_lens 20480決定 KV cache 預(yù)分配長度按上下文預(yù)算調(diào)整。優(yōu)化規(guī)則文件位于 ktransformers/optimize/optimize_rules/npu/300I A2 上 DeepSeek-V3 的服務(wù)化配置即上面啟動參數(shù)引用的DeepSeek-V3-Chat-300IA2-npu-serve.yaml同目錄還有非 serve 版與 Qwen3 的對應(yīng)配置可選。用基準數(shù)據(jù)驗證 NPU 推理性能服務(wù)起來后用固定長度 prompt 壓一遍 prefill 與 decode。以下為 Batchsize4、輸出長度 1024 條件下的參考值tokens/sPrompt 長度1K2K4KPrefill174.68169.52167.15Decode16.0716.1216.48實測與參考值偏差超過 20% 時先查 NPU 側(cè)算子是否真的走下去了npu-smi看利用率再查cache_lens是否被默認值截斷。需要定位慢算子時用PROF_PREFILL與PROF_DECODE兩個環(huán)境變量分別開啟兩階段的 profiling 輸出。故障速查現(xiàn)象處理報libhccl.so缺失見上文「配置 CANN 軟件棧」當前 shell 先source /usr/local/Ascend/ascend-toolkit/set_env.sh報libascend_hal.so缺失補驅(qū)動庫路徑export LD_LIBRARY_PATH/usr/local/Ascend/driver/lib64/driver:$LD_LIBRARY_PATHaarch64 編譯期iqk_mul_mat鏈接錯誤注釋 third_party/llamafile/iqk_mul_mat_arm82.cpp 中兩行宏定義見「初始化項目與編譯擴展」節(jié)torch_npu 導(dǎo)入即報錯檢查version.py是否仍帶git...哈希后綴服務(wù)啟動 OOM物理內(nèi)存不足 400GB滿血版無法容納路由專家權(quán)重下一步建議把--cache_lens按業(yè)務(wù)真實上下文長度調(diào)到位再用PROF_PREFILL抓一次 prefill 分布——prefill 吞吐從 170 tokens/s 量級再往上走瓶頸基本都在長序列的注意力段?！久赓M下載鏈接】ktransformersA Flexible Framework for Experiencing Heterogeneous LLM Inference/Fine-tune Optimizations項目地址: https://gitcode.com/GitHub_Trending/ktr/ktransformers創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考 在 Atlas 上跑通 DeepSeek-R1：KTransformers 昇騰 NPU 部署實戰(zhàn)
在 Atlas 上跑通 DeepSeek-R1KTransformers 昇騰 NPU 部署實戰(zhàn)【免費下載鏈接】ktransformersA Flexible Framework for Experiencing Heterogeneous LLM Inference/Fine-tune Optimizations項目地址: https://gitcode.com/GitHub_Trending/ktr/ktransformers導(dǎo)語為什么要把 LLM 搬到昇騰 NPU 上跑最直接的答案是內(nèi)存和成本。DeepSeek-R1 這類滿血 MoE 模型的路由專家權(quán)重體量巨大GPU 集群要么買不起、要么排隊。Atlas 服務(wù)器配 1TB DDR5用 CPU NPU 異構(gòu)分工承接推理KTransformers 的 CPU 推理內(nèi)核正好吃下這條路徑——專家權(quán)重放在內(nèi)存里注意力與算子下沉到 NPU 執(zhí)行。本文是一次真實部署的復(fù)盤從 Atlas 硬件、CANN 軟件棧、雙權(quán)重合并到 balance_serve 服務(wù)啟動與性能核對每一步的坑都標在原地。部署前避坑清單先知道會踩什么坑后面裝環(huán)境時心里有數(shù)transformers 版本被釘死在4.57.1其他版本未驗證裝錯了直接報結(jié)構(gòu)解析異常。torch_npu 不能直接用 pypi 預(yù)編譯包。因為涉及新增算子必須從源碼編譯 v2.5.1 分支且編譯后版本號里的哈希后綴要手動去掉見下文。兩份權(quán)重缺一不可。Q4 的 GGUF 與 W8A8 的 safetensor 必須先用合并腳本合成一份只放一份進模型目錄服務(wù)起不來。400GB 物理內(nèi)存是下限。滿血版 DeepSeek-R1/V3 的路由專家權(quán)重需要約 400GB 物理內(nèi)存內(nèi)存不足的機器別硬試。CANN 環(huán)境變量沒 source一切白搭。libhccl.so、libascend_hal.so缺失都是同一個原因速查表里給了解法這里不重復(fù)展開。搭建 Atlas 硬件與操作系統(tǒng)本節(jié)目標是把一臺 Atlas 2UP 變成可用的 300I A2 推理節(jié)點。硬件與系統(tǒng)版本按下表核對項規(guī)格服務(wù)器Atlas 2UPNPU300I A2當前 KTransformers 適配的 NPU 型號CPUHUAWEI Kunpeng 920 7270Z內(nèi)存DDR5 服務(wù)器內(nèi)存1TB操作系統(tǒng)Ubuntu 22.04 for aarch64內(nèi)核5.15.0-25-generic裝完系統(tǒng)后做兩件事關(guān)閉自動更新并記錄好 CANN、NPU 驅(qū)動的實際安裝路徑——后面 source 環(huán)境變量要用。硬件插拔與固件確認建議拉原廠支持一起完成NPU 的固件版本直接影響后面 Kernel 能否加載。配置 CANN 軟件棧軟件棧分四層HDK 固件驅(qū)動 → CANN → Python 環(huán)境 → torch_npu。順序不能亂版本必須嚴格對齊下表任何一層漂移都會在算子加載階段報錯組件版本Ascend HDK25.3.RC1CANN8.3.RC1.alpha003需裝 ToolKit、Kernel、NNAL 三件Python3.11conda 環(huán)境一行conda create -n py311 python3.11即可PyTorchtorch2.5.1/torchvision0.20.1/torchaudio2.5.1transformers4.57.1必須無替代torch_npuv2.5.1 分支源碼編譯torch_npu 編譯前先把 CANN 與 NNAL 的環(huán)境加載進當前 shellsource /usr/local/Ascend/ascend-toolkit/set_env.sh source /usr/local/Ascend/nnal/atb/set_env.sh?? 編譯過程對 github、gitcode 等平臺的網(wǎng)絡(luò)訪問敏感網(wǎng)絡(luò)不暢通時子模塊拉取會靜默失敗。從源碼倉庫Gitcode 上的 Ascend/pytorch獲取代碼后編譯 v2.5.1 分支。編譯裝好后還有一個反直覺的步驟打開 site-packages 下torch_npu/version.py路徑用pip show torch_npu確認把形如__version__ 2.5.1.post4git69550dfc的版本號改為__version__ 2.5.1.post4去掉哈希后綴。環(huán)境對版本號有嚴格匹配帶后綴會直接被拒。合并 Q4 與 W8A8 雙權(quán)重KTransformers 對 NPU 路徑的精度要求決定了權(quán)重要走雙份合并Q4_K_M 的 GGUF 權(quán)重負責(zé)路由專家的 CPU 側(cè)存儲W8A8 的 safetensor 權(quán)重負責(zé) NPU 側(cè)算子。兩份原始權(quán)重都下載就位后跑倉庫里的合并腳本python merge_safetensor_gguf.py \ --safetensor_path /path/to/DeepSeek-R1-W8A8 \ --gguf_path /path/to/DeepSeek-R1-Q4_K_M \ --output_path /output/merged腳本位于 merge_tensors/。合并完成后后續(xù)啟動參數(shù)只指向合并后的目錄兩份原始權(quán)重不再參與推理。初始化項目與編譯擴展克隆倉庫并拉取子模塊git clone https://gitcode.com/gh_mirrors/ktr/ktransformers cd ktransformers git submodule update --init --recursive進入編譯前先安裝構(gòu)建依賴并加載 CANN 環(huán)境source /usr/local/Ascend/ascend-toolkit/set_env.sh apt install cmake libhwloc-dev pkg-config bash ./install.shinstall.sh 會編譯 CPU 側(cè)的 kt-kernel 擴展與 llamafile 算子庫。?? 在 aarch64ARM82上如果鏈接階段報iqk_mul_mat相關(guān)錯誤把 third_party/llamafile/iqk_mul_mat_arm82.cpp 文件內(nèi)的兩行宏定義注釋掉即可通過編譯// #define iqk_mul_mat iqk_mul_mat_arm82 // #define iqk_mul_mat_moe iqk_mul_mat_moe_arm82這是 aarch64 工具鏈的已知適配點x86 機器不用動這個文件。啟動 balance_serve 推理服務(wù)服務(wù)入口是ktransformers/server/main.py關(guān)鍵參數(shù)與 NPU 優(yōu)化規(guī)則文件一起給出export USE_MERGE0 export INF_NAN_MODE_FORCE_DISABLE1 export TASK_QUEUE_ENABLE0 source /usr/local/Ascend/ascend-toolkit/set_env.sh source /usr/local/Ascend/nnal/atb/set_env.sh python ktransformers/server/main.py \ --port 10002 \ --model_path merged_weights \ --gguf_path merged_weights \ --model_name DeepSeekV3ForCausalLM \ --optimize_config_path ./ktransformers/optimize/optimize_rules/npu/DeepSeek-V3-Chat-300IA2-npu-serve.yaml \ --max_new_tokens 1024 \ --cache_lens 20480 \ --backend_type balance_serve環(huán)境變量逐個說明故障排查時只需對照這一段速查表不重復(fù)TASK_QUEUE_ENABLE0關(guān)閉任務(wù)隊列保證算子下發(fā)順序嚴格有序這是開啟圖下沉的前置條件USE_BALANCE_SERVE1與USE_NUMA1啟用 balance_serve 后端與 NUMA 綁定啟動腳本中按需導(dǎo)出USE_MERGE0權(quán)重已離線合并運行時不再做在線合并INF_NAN_MODE_FORCE_DISABLE1禁用推理期的 NaN 強制檢查省去每步的開銷--backend_type balance_serve指定服務(wù)后端--cache_lens 20480決定 KV cache 預(yù)分配長度按上下文預(yù)算調(diào)整。優(yōu)化規(guī)則文件位于 ktransformers/optimize/optimize_rules/npu/300I A2 上 DeepSeek-V3 的服務(wù)化配置即上面啟動參數(shù)引用的DeepSeek-V3-Chat-300IA2-npu-serve.yaml同目錄還有非 serve 版與 Qwen3 的對應(yīng)配置可選。用基準數(shù)據(jù)驗證 NPU 推理性能服務(wù)起來后用固定長度 prompt 壓一遍 prefill 與 decode。以下為 Batchsize4、輸出長度 1024 條件下的參考值tokens/sPrompt 長度1K2K4KPrefill174.68169.52167.15Decode16.0716.1216.48實測與參考值偏差超過 20% 時先查 NPU 側(cè)算子是否真的走下去了npu-smi看利用率再查cache_lens是否被默認值截斷。需要定位慢算子時用PROF_PREFILL與PROF_DECODE兩個環(huán)境變量分別開啟兩階段的 profiling 輸出。故障速查現(xiàn)象處理報libhccl.so缺失見上文「配置 CANN 軟件棧」當前 shell 先source /usr/local/Ascend/ascend-toolkit/set_env.sh報libascend_hal.so缺失補驅(qū)動庫路徑export LD_LIBRARY_PATH/usr/local/Ascend/driver/lib64/driver:$LD_LIBRARY_PATHaarch64 編譯期iqk_mul_mat鏈接錯誤注釋 third_party/llamafile/iqk_mul_mat_arm82.cpp 中兩行宏定義見「初始化項目與編譯擴展」節(jié)torch_npu 導(dǎo)入即報錯檢查version.py是否仍帶git...哈希后綴服務(wù)啟動 OOM物理內(nèi)存不足 400GB滿血版無法容納路由專家權(quán)重下一步建議把--cache_lens按業(yè)務(wù)真實上下文長度調(diào)到位再用PROF_PREFILL抓一次 prefill 分布——prefill 吞吐從 170 tokens/s 量級再往上走瓶頸基本都在長序列的注意力段?！久赓M下載鏈接】ktransformersA Flexible Framework for Experiencing Heterogeneous LLM Inference/Fine-tune Optimizations項目地址: https://gitcode.com/GitHub_Trending/ktr/ktransformers創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考