昇騰DeepSeek模型部署優秀實踐及FAQ

2024年12月26日，DeepSeek-V3橫空出世，以其卓越性能備受矚目。該模型發布即支持昇騰，用戶可在昇騰硬件和MindIE推理引擎上實現高效推理，但在實際操作中，部署流程與常見問題困擾著不少開發者。本文將為你詳細闡述昇騰 DeepSeek 模型部署的優秀實踐，同時解答常見問題。

DeepSeek在昇騰上的模型部署優秀實踐

01硬件要求及組網

推薦參考配置如下，部署DeepSeek-V3/R1量化模型至少需要多節點Atlas 800I A2（8*64G）服務器。本方案以DeepSeek-R1為主進行介紹，DeepSeek-V3與R1的模型結構和參數量一致，部署方式與R1相同。

02運行環境準備

推薦使用鏡像部署

1、鏡像部署

昇騰官方在Ascend hub提供環境示例鏡像，含推理部署配套軟件以及模型運行腳本，用戶可參考構建運行環境鏡像進行部署。

鏡像部署及啟動參照ModelZoo指南中“加載鏡像”章節，該指南中還包含“容器啟動”等指引

https://gitee.com/ascend/ModelZoo-PyTorch/tree/master/MindIE/LLM/DeepSeek/DeepSeek-R1#%E5%8A%A0%E8%BD%BD%E9%95%9C%E5%83%8F

鏡像申請/下載（含于上述指南）：

https://www.hiascend.com/developer/ascendhub/detail/af85b724a7e5469ebd7ea13c3439d48f

2、裸機部署

根據昇騰社區發布的MindIE安裝指南安裝軟件包和運行依賴軟件。

安裝指南：

根據指南安裝全部軟件包和環境

https://www.hiascend.com/document/detail/zh/mindie/100/envdeployment/instg/mindie_instg_0001.html

模型獲取：

https://gitee.com/ascend/ModelZoo-PyTorch/tree/master/MindIE/LLM/DeepSeek/DeepSeek-R1#1-%E5%87%86%E5%A4%87%E6%A8%A1%E5%9E%8B

03權重文件準備

BF16權重下載：

1、HuggingFace：https://huggingface.co/unsloth/DeepSeek-V3-bf16/

2、ModelScope：https://modelscope.cn/models/unsloth/DeepSeek-V3-bf16/

3、Modelers：https://modelers.cn/models/State_Cloud/DeepSeek-V3-BF16

INT8量化后權重下載：https://modelers.cn/models/State_Cloud/DeepSeek-R1-W8A8/tree/main

如已下載BF16模型，也可采用以下步驟進行模型量化，權重BF16->INT8轉換預計7~8小時。

Step1：安裝ModelSlimgit clone https://gitee.com/ascend/msit.gitcd msit/msmodelslimbash install.shStep2: 運行量化命令cd msit/msmodelslim/example/DeepSeek/python3 quant_deepseek_w8a8.py \--model_path {浮點權重路徑} \--save_path {W8A8量化權重路徑}

更多詳細量化教程請參考 DeepSeek 量化文檔（ https://gitee.com/ascend/msit/tree/br_noncom_MindStudio_8.0.0_POC_20251231/msmodelslim/example/DeepSeek）

Msmodelslim?代碼倉：https://gitee.com/ascend/msit/tree/br_noncom_MindStudio_8.0.0_POC_20251231/msmodelslim

04運行前檢查

服務器檢查：https://gitee.com/ascend/ModelZoo-PyTorch/tree/master/MindIE/LLM/DeepSeek/DeepSeek-R1#%E5%89%8D%E7%BD%AE%E5%87%86%E5%A4%87

軟件版本配套檢查，含：HDK、CANN、PTA、MindIE、MindStudio

1、檢查組網鏈接狀態

a)????檢查物理鏈接

for i in {0..7}; do hccn_tool -i $i -lldp -g | grep Ifname; done

b)????檢查鏈接情況

for i in {0..7}; do hccn_tool -i $i -link -g ; done

c)?????檢查網絡健康情況

for i in {0..7}; do hccn_tool -i $i -net_health -g ; done

d)????查看偵測ip的配置是否正確

for i in {0..7}; do hccn_tool -i $i -netdetect -g ; done

e)????查看網關是否配置正確

for i in {0..7}; do hccn_tool -i $i -gateway -g ; done

f)?????檢查NPU底層tls校驗行為一致性，建議全0

for i in {0..7}; do hccn_tool -i $i -tls -g ; done | grep switch

g)????# NPU底層tls校驗行為置0操作

for i in {0..7};do hccn_tool -i $i -tls -s enable 0;done

2、根據組網設置準備rank_table_file.json

使用多節點推理時，需要將包含設備ip，服務器ip等信息的json文件地址傳遞給底層通信算子。參考如下格式，配置rank_table_file.json:

05模型部署與配置

獨立模型：

https://gitee.com/ascend/ModelZoo-PyTorch/tree/master/MindIE/LLM/DeepSeek/DeepSeek-R1#%E7%BA%AF%E6%A8%A1%E5%9E%8B%E6%B5%8B%E8%AF%95

服務化部署：

1、運行指南

https://gitee.com/ascend/ModelZoo-PyTorch/tree/master/MindIE/LLM/DeepSeek/DeepSeek-R1#%E6%9C%8D%E5%8A%A1%E5%8C%96%E6%B5%8B%E8%AF%95

2、服務啟動

https://www.hiascend.com/document/detail/zh/mindie/100/mindieservice/servicedev/mindie_service0004.html

3、接口指引

https://www.hiascend.com/document/detail/zh/mindie/100/mindieservice/servicedev/mindie_service0062.html

06模型運行

1、純模型測試

模型腳本已預制在鏡像中，參照以下鏈接即可拉起精度測試及模型測試

https://gitee.com/ascend/ModelZoo-PyTorch/tree/master/MindIE/LLM/DeepSeek/DeepSeek-R1#%E7%BA%AF%E6%A8%A1%E5%9E%8B%E6%B5%8B%E8%AF%95

2、服務化測試

1、運行指南

https://gitee.com/ascend/ModelZoo-PyTorch/tree/master/MindIE/LLM/DeepSeek/DeepSeek-R1#%E6%9C%8D%E5%8A%A1%E5%8C%96%E6%B5%8B%E8%AF%95

2、服務啟動

https://www.hiascend.com/document/detail/zh/mindie/100/mindieservice/servicedev/mindie_service0004.html

3、常用接口指引

https://www.hiascend.com/document/detail/zh/mindie/100/mindieservice/servicedev/mindie_service0062.html

常見問題及解決方案

01通信錯誤：Hccl execute failed

問題現象：

日志顯示卡（IP地址10.0.3.9）與卡（IP地址10.0.3.17）之間connection fail

查看日志發現出現hccl通信失敗相關日志內容：

解決方案：

（1）問題定位前需要先開啟日志生成環境變量：

算子庫&加速庫&模型庫日志保存路徑：/root/atb/log

CANN日志保存路徑：/root/ascend/log/debug/plog

（2）通過hccn_tool 工具進行連通性檢測，發現出現鏈路down，修復鏈路down的問題后，通信失敗問題解決。

02通信錯誤：Hccl通信超時

可配置以下環境變量，增大超時等待時間。

03顯存不足：NPU out of memory

問題現象：

在服務化拉起過程中，出現NPU out of memory報錯。

解決方案：

適當調高NPU_MEMORY_FRACTION環境變量（默認值為0.8），適當調低mindie-service服務化配置文件config.json中maxSeqLen、maxInputTokenLen、maxPrefillBatchSize、maxPrefillTokens、maxBatchSize等參數。

04推理卡頓：模型加載時間長，可能達到2H及以上

問題現象：

模型部署過程中，推理前的模型加載時間過長，部分極端情況需要等待>2H。

可能原因：

1）用戶場景內存不足導致swap介入；

2）首次加載權重，權重存儲硬件的傳輸速率慢，傳統的HDD或低速SSD或網絡存儲方式存在I/O瓶頸；

3）框架權重加載使用單線程加載；

解決方案：

1）更換NVMe SSD高速存儲硬件；

2）使用內存映射文件mmap加載權重，例如：

Weights = torch.load(“model.bin”,mmap=True)；

3）使用并行加載的方式，將權重按層或模塊拆分為多個文件，可google教程

4）減少多線程開銷，設置以下環境變量

?export OMP_NUM_THREADS=1

5）預熱加載，提前預加載模型權重到內存

05推理卡頓：純模型/服務化拉起卡住、停止

問題現象：

如果free -h中的free內存小于權重大小 / 機器數，純模型拉起會卡死，過一段時間后進程被殺。

根據經驗，可以確保一下free_mem >= (權重大小 / 機器數) * 1.3 （該計算方式待驗證，但需要確保內存足夠）

解決方案：重啟/釋放緩存。

推薦使用釋放緩存的方式，可以在容器內運行以下指令：

sync; echo 3 > /proc/sys/vm/drop_caches

注意，每次跑完模型，請檢查一下機器的host側內存占用。

06推理卡頓：首Curl請求卡死

問題現象：在服務化成功啟動后出現首次curl請求發送后，無返回的現象；或者服務化拉起卡死的現象。

可能原因：多節點的服務化config.json有區別，或是除了需要寫本機信息外的環境變量不一樣。

1、例如，A、B兩個8卡節點的服務化配置文件中，A配置了interNodeTLSEnabled=true，B配置了interNodeTLSEnbal=false。

2、容器A的環境變量中未設置確定性計算相關環境變量，容器B的環境變量中卻有確定性計算相關的環境變量。盡管執行推理請求的節點確定性計算相關的環境變量是關閉狀態，仍可能影響推理卡住。

#?確定性計算環境變量

export ? HCCL_DETERMINISTIC=false

所以，請一定要一一核對好每個8卡容器內的環境變量是一樣的，服務化的config.json也需是一樣的。

07推理卡頓：大流量下curl請求超時

問題現象：服務啟動后，在大流量下會出現掛死，具體表現為Curl請求超時，Aicore利用率為0：

所有卡利用率為0：

當前識別為重計算觸發的問題，可通過修改mindieservice的config文件進行臨時規避。

要求maxseqen與maxprefilltoken參數配置為相同大小。

當前識別為重計算觸發的問題，可通過修改mindieservice的config文件進行臨時規避。

要求maxseqen與maxprefilltoken參數配置為相同大小。

08配置問題：服務化benchmark初始化失敗

需正確配置Ranktable:??export RANKTABLEFILE=/Path/To/ranktable[X].json

09配置問題：Ranktable中的server id和container ip填寫

ranktable中的server id和container ip均填寫成主機IP，前提是起容器時需要設置成host模式：docker run --network host <image_name>，含義就是容器的ip地址=主機的ip地址，注意容器開放的端口不要和主機沖突。

10日志采集：純模型Profiling 采集

當前 MindIE atb-models 中已經內置了 Profiling 采集邏輯，核心代碼在 atb-models/examples/run_pa.py 的 PARunner 中。我們可以通過以下環境變量對 Profiling 采集進行控制：

執行采集時，只需要配置環境變量，在modeltest下拉起性能測試，即可獲取到 Profiling 數據。若需采集的卡數大于8,則需要在每個節點上同時開啟以下環境變量：

開啟環境變量后，參照性能測試，指令如下（可自行修改指令）：

采集完成后，核心數據解析到$PROFILING_FILEPATH /ASCEND_PROFILER_OUTPUT 路徑下。

11日志采集：通用方法

遇到推理報錯時，請打開日志環境變量，收集日志信息。

12Tokenizer 報錯

MindIE?報 XXX 錯誤，有一定誤導性。實際上只要是 transformers 加載 tokenizer 報錯，MindIE 會捕獲所有錯誤，直接退出，并且不會顯示真正錯誤原因。通常，transformers 加載 tokenizer 常見錯誤以及對應排查方法有：

1、詞表文件損壞

檢查tokenizer.json 文件完整性，V3 和 R1 的詞表不一樣。
推薦使用 ModelScope 由 Unsloth 維護的 bf16 版本

2、transformers / tokenizer 版本不匹配

確認 transformers、tokenizer 版本：查看模型權重路徑下的 config.json 中，transformers版本號。注意：不同的原權重由于fp8轉bf16時的transformers版本不同，可能會有不同的transformers 配套，請以機器上的deepseek官方權重中的config.json中的transformers版本為準）

若懷疑Tokenizer的問題，可以使用以下Tokenizer 校驗方法，創建一個 python 腳本，如果運行成功，則 tokenizer 加載無問題。若報錯，請按照上述方法檢查。

13性能問題：推理性能不符合預期

首先，請確保使能AIV，關閉確定性計算。

其次，DeepSeek-R1 官方推薦服務化請求遵循以下配置，以達到預期性能：

將溫度設置在0.5-0.7 范圍內（推薦0.6），以防止出現無休止的重復或不連貫的輸出。

避免添加 System Prompt；所有指令應包含在 User Prompt 中。?

對于數學問題，建議在提示中加入以下指令：“請逐步推理，并將最終答案放在\boxed{}內。”

在評估模型性能時，建議進行多次測試并取平均結果。

若遇到精度問題，請確保使用openai接口。

此外，DeepSeek-R1系統模型在回答某些問題時傾向于繞過思考模式（即不輸出“<think>\n\n</think>”），這可能會影響模型的表現。為了確保模型進行正確的推理，建議強制模型在每次輸出的開頭使用“<think>\n”。

14權重路徑和權限問題

問題描述：

在服務化拉起過程中出現權重路徑不可用或者權重文件夾權限問題。

解決方案：

注意保證權重路徑是可用的，執行以下命令修改權限，注意是整個父級目錄的權限：

15 16卡及以上配置推理測試類問題

1、16卡及以上配置推理測試類問題

問題描述：

多節點參與的推理超過兩小時不通信會超時，從而服務化報錯。

解決方案：

當前版本可以寫一個每小時調用健康監控接口的腳本，進行服務化保活。服務化監控探測接口參考MindIE官方文檔：https://www.hiascend.com/document/detail/zh/mindie/100/mindieservice/servicedev/mindie_service0102.html