OSCHINA

在進行 DeepSeek 昇騰部署時，你是否遇到了問題？本文匯總了常見問題，助你快速定位并迅速部署 DeepSeek。

歡迎廣大開發者訪問魔樂社區 DeepSeek 專區查收更多適配模型和技術干貨：https://modelers.cn/topics/deepseek

1. 性能問題 1.1 問題現象：部署 DeepSeek 服務化，性能不及預期 模塊

性能測試

性能裂化，OS 內核，日志，環境

問題描述 MindIE 版本：2.0.T3 模型類型：DeepSeekV3/R1 部署 DeekSeekV3/R1 拉起后實測性能較差，與預期差異較大。

可能原因

• 日志級別問題

• OS 內核版本問題

• 環境變量優化問題

在發送請求時，觀察日志中是否存在大量的 debug、info 日志打印。如果存在可能是為了排查問題，各組件開啟了 debug 日志，事后忘記關閉，而大量的日志打印是十分耗時的行為，且在正常的服務過程中，不需要這些日志。

原因 2：

使用uname -r查看 OS 內核版本，版本小于 5.10；

原因 3：

在 PyTorch 的訓練或推理場景，可以通過設置環境變量 CPU_AFFINITY_CONF 來控制 CPU 端算子任務的處理器親和性，即設定任務綁核。該配置能夠優化任務的執行效率，避免跨 NUMA（非統一內存訪問架構）節點的內存訪問，減少任務調度開銷。

原因 4：

未關閉確定性計算 HCCL_DETERMINISTIC $\risingdotseq$ true，可以通過 env | grepHCCL_DETERMINISTIC 來查看是否設置。

解決方案 原因 1：

在 set_env.sh 中關閉各組件的 debug/info 日志等級，改成 ERROR 級別。

原因 2：

升級系統，內核版本升級到 5.10；（升級前需要找研發確認）

原因 3：

開啟綁核優化示例，開啟方式三選一，建議優先嘗試示例二

示例一：粗粒度綁核export CPU_AFFINITY_CONF=1

示例二：細粒度綁核export CPU_AFFINITY_CONF=2

示例三：自定義多張 NPU 卡的綁核范圍

export CPU_AFFINITY_CONF=1,npu0:0-1,npu1:2-5,npu3:6-6

原因 4：關閉確定性計算：

export HCCL_DETERMINISTIC=false

2 運行問題 2.1 問題現象：多機無法拉起 DeepSeek-R1 模型，HCCL 報錯 模塊

故障診斷

TLS、HCCL、AllReduce、通信

問題描述 MindIE 版本：2.0.T3 模型類型：DeepSeekV3/R1

開啟算子庫日志（export ASDOPS_LOG_LEVEL=INFO; export ASDOPS_LOG_TO_STDOUT=1）與開啟 ATB 日志（export ATB_LOG_LEVEL=INFO; export ATB_LOG_TO_STDOUT=1）多節點啟動 service 報 HCCL 問題，例如下圖：

可能原因

NPU 底層 tls 校驗行為不一致

排查方法

使用指令，查看每個節點的 device 的 TLS 開關狀態是否一致

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

用戶啟動服務前請檢查 NPU 底層 tls 校驗行為一致性，建議全 0；使用如下命令：

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

??2.2 問題現象：多機無法拉起 DeepSeek-R1 模型，從節點無法和主節點建立 RPC 通信???????????

??

模塊

安裝部署

RPC、多節點部署、防火墻

問題描述 MindIE 版本：2.0.T3 模型類型：| DeepSeekV3/R1

• 多節點部署從節點無法和主機點建立 rpc 問題，子節點報 RPC 問題，例如下圖：

• 4 機推理，deepseek r1 服務化拉起失敗，salve3 臺服務化都能起，master 起服務會失敗，報錯信息如下圖：

可能原因

防火墻攔截

排查方法

使用指令查看防火墻狀態，如果開啟防火墻，需要關閉；

sudo systemctl status firewalld

解決方案

每臺機器執行sudo systemctl stop firewalld，關閉防火墻。

2.3 問題現象：多機無法拉起 DeepSeek-R1 模型，服務器 NPU 通信問題 模塊

安裝部署

NPU、網絡、通信、中斷、拉起

問題描述 MindIE 版本：| 2.0.T3 | 模型類型：| DeepSeekV3/R1

• 啟動任務時，任務無法拉起

• 任務執行時，突然中斷或服務突然終止

• 其他需要檢測 HCCL 網絡通信的場景

NPU 網絡通信存在問題

排查方法

1. 檢測防火墻

2. 檢測 NPU 狀態

3. 檢測 NPU 之間通訊

步驟 1：查看防火墻是否關閉

firewall-cmd –state

已關閉顯示如下：

firewall-cmd --state not running

未關閉執行如下命令：

systemctl stop firewalld

步驟 2: 檢測卡狀態

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

顯示 up 為正常

其他狀態可以通過如下命令重啟卡（-i 后面填寫卡的 ID）

npu-smi set -t reset -i {RankId} -c 0 -m 1

步驟 3: 檢測卡的 IP 是否配置

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

步驟 4: 檢測多節點的每個卡 TLS 開關是否一致

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

所有機器的所有卡要么為 1，要么為 0。建議修改為 0 進行關閉。

TLS 關閉方法（-i 后面填寫卡的 ID）

hccn_tool -i {RankId} -tls -s enable 0

步驟 5：本機卡間通信檢測

• 進入任意目錄創建一個 test.py

• 文件文件加入如下腳本

import subprocess

ip_list = []
for i in range(8):
    try:
        cmd = ['hccn_tool', '-i', str(i), '-ip', '-g']
        res = subprocess.run(cmd, capture_output=True, text=True, check=True)
        res_str = res.stdout.strip()
        if 'ipaddr' in res_str:
            ip_list.append(res_str.split('\n')[0].split(':')[1])
    except subprocess.CalledProcessError as e:
        print(e)

for i in range(8):
    for other_ip in ip_list:
        try:
            cmd = ['hccn_tool', '-i', str(i), '-ping', '-g', 'address', str(other_ip), 'pkt', '3']
            res = subprocess.run(cmd, capture_output=True, text=True, check=True)
            print(ip_list[i], '==>', res.stdout.strip())
        except subprocess.CalledProcessError as e:
            print(e)
    print(f'========{ip_list[i]} is OK========')
print(f'========ALL is OK========')

• 在當前目錄執行腳本

python test.py

• 出現 ALL is OK 代表本機所有卡通訊正常

檢測無誤后，重新執行 AI 任務即可。

2.4 問題現象：多機無法拉起 DeepSeek-R1 模型，modeling_utils.py 報錯 模塊

故障診斷

NoneType、metadata、modeling_utils

問題描述

MindIE 版本：2.0.T3
模型類型：DeepSeekV3/R1

在服務化拉起過程中，若出現if metadata.get("format") not in ["pt", "tf", "flax", "mix"]: AttributeError: "NoneType" object has no attribute 'get';報錯

可能原因

輸入的權重中缺少 metadata 字段

排查方法

日志 modeling_utils.py 報錯

解決方案

安裝更新 transformers 版本（= 4.46.3)

2.5 問題現象：多機無法拉起 DeepSeek-R1 模型，Failed to init endpoint 模塊

安裝部署

server.key、ca.pem、key_pwd、endpoint、https、服務化

問題描述

MindIE 版本：2.0.T3
模型類型：DeepSeekV3/R1

MindIE 推理啟服務出現 Failed to init endpoint! Please check the service log or console output.

可能原因

開啟 HTTPS，但未設置證書導致的問題。

排查方法

查看日志是否存在圖片中描述的報錯

解決方案

1. httpsEnabled 設置的 true，如果為 true 的情況下需要配置證書，請檢查證書配置是否正確。證書配置請參考 MindIE 社區文檔：
   https://www.hiascend.com/document/detail/zh/mindie/100/mindieservice/servicedev/mindie_service0312.html

2. 將 httpsEnabled 修改為 false

3 精度問題 3.1 問題現象：多機拉起 DeepSeek-R1 模型服務化后，發送推理請求，返回內容亂碼 模塊

模型推理

請求、亂碼

問題描述

MindIE 版本：2.0.T3
模型類型：DeepSeekV3/R1

四機部署 deepseekR1，啟服務后，發送推理請求，返回內容亂碼，沒有報錯，例如下圖：

可能原因

用戶使用的模型配置文件和官網文件有差異，導致返回異常。

排查方法

模型權重目錄里的所有配置文件請與 Modelers，HuggingFace 等官方網站所上傳的權重等文件進行對比。

解決方案

把模型權重目錄里的所有配置文件和官網上的文件對齊之后 只修改 config.json 中的 model_type 更改為 deepseekv2（只有這一處修改），推理返回正常。

4. 安裝部署問題 4.1 題現象：NPU 卡健康檢查返回錯誤，提示 timeout 模塊

安裝部署

NPU、健康檢查、Receive timeout

問題描述

MindIE 版本：2.0.T3
模型類型：DeepSeekV3/R1

多機拉起 DeepSeek 模型時，服務化拉起卡住。進行 NPU 卡進行健康檢查時，返回 timeout 錯誤

可能原因

1、交換機和 NPU 的網關沒有配置
2、NPU 的網關 IP 和偵測 ip 沒有配置成一樣

排查方法

1、使用hccn_tool [-i 7] -netdetect -g，查看 NPU 的偵測 ip 有沒有配置或配置成多少。

2、再次執行hccn_tool [-i 7] -gateway -g，查看 NPU 的網關 IP 地址有沒有多少或者配置成多少，偵測 IP 和網關 IP 兩者比較是否一樣，發現沒有配置成一樣。

解決方案

偵測 IP 和網關 IP 沒有配置成一樣，使用如下命令行修改成規劃的網關 IP 地址，使兩者一樣，問題得以解決。配置 NPU 網卡地址，網關地址，偵測 IP 的命令行如下：

1、Npu IP 和掩碼設置

hccn_tool -i 0 -ip -s address 192.168.16.126 netmask 255.255.255.0

2、Npu 網關設置

hccn_tool -i 0 -gateway -s gateway 192.168.16.254

3、Npu 檢測地址設置

hccn_tool -i 0 -netdetect -s address 192.168.16.254

4.2 題現象：服務器開啟 lldp，查詢鄰居信息沒有輸出 模塊

故障診斷

LLDP

問題描述

MindIE 版本：2.0.T3
模型類型：DeepSeekV3/R1

多機拉起 DeepSeek 模型時，服務化拉起卡住。檢查網絡通信，服務器兩邊都開啟了 LLDP，在服務器上執行hccn_tool -i 0 -lldp -g命令，沒有任何新鄰居信息輸出

可能原因

1、交換機處沒有使能 LLDP

2、交換機端口或者網卡沒有 UP

排查方法

1、前往交換機執行display lldp neighbor brief，如果有如下回顯，證明交換機使能了 LLDP 功能。

2、現場確認下服務器連接交換機端口物理狀態是否正常，物理指示燈是否亮燈。經過現場確認發現物理指示燈沒有亮

解決方案

現場使用的交換機是 CE9860,400GE 端口使用 1 分 2 的光纖連接服務器 NPU 卡，物理指示燈未亮是因為 400GE 端口未做拆分，在交換機上執行如下命令行將端口進行拆分，port split dimension interface 400GE 1/1/1 split-type 2*200GE。拆分后端口物理指示燈亮了，再在服務器上執行 hccn_tool -i 0 -lldp -g 命令，能夠正常顯示鄰居信息了。

4.3 題現象：純模型推理，啟動階段 warm up 卡死 模塊

安裝部署

warm up、卡死

問題描述

MindIE 版本：2.0.T3
模型類型：DeepSeekV3/R1

Deepseek v3 4 機純模型推理，啟動后卡在 warm up 環節

可能原因

多節點的環境變量配置不一致

排查方法

查看每個服務器的環境變量 HCCL_DETERMINISTIC 是否為 false

解決方案

需要保證多節點的 HCCL_DETERMINISTIC 一致，例如：export HCCL_DETERMINISTIC=false

5. 其他 5.1 版本查看：如何查看各組件的版本 MindIE

cat /usr/local/Ascend/mindie/latest/version.info

CANN

cat /usr/local/Ascend/ascend-toolkit/latest/version.cfg

ATB-Models

cat /usr/local/Ascend/atb-models/version.info

NNAL

cat /usr/local/Ascend/nnal/atb/latest/version.info

5.2 快速定界 HCCL\ 內存 \ 代碼 等問題

在拉起模型的過程中，會遇到各類不太明確根因的問題，如多節點拉起服務化 \ 純模型卡住、加載過程中報錯、host 側內存不足等問題。這類問題可能需要多次修改代碼 \ 環境變量，再拉起模型進行驗證。拉起 670B 的權重是一個特別耗時的過程，短的可能 2、3 分鐘，長的可能需要 10、20 分鐘。

為了簡化、便捷、快速的定位問題，減少拉起模型的時間，我們可以使用減層驗證的方法來加速拉起時間。因為 Transformer 模型的每一層結構高度相似，包含自注意力機制和前饋神經網絡（FFN）兩個核心模塊。每一層的計算步驟和參數量基本一致。因此，我們可以將 DeepSeek-R1/V3 的層數從 61 層減少到幾層（比如 5 層）來減少參數量 \ 計算量，加速驗證、定位問題。

方法如下：

1. 進入模型權重的文件夾，打開權重文件夾的 config.json
2. 修改 "num_hidden_layers" 這個參數，修改為 5
3. 驗證、定位問題
4. 問題解決后，將 "num_hidden_layers" 修改回原層數

↓分享、在看與點贊~Orz