DeepSeek部署技術問題FAQ

2025-05-03 04:09 OSC開源社群

OSCHINA
↑點選藍字 關注我們
在進行 DeepSeek 昇騰部署時，你是否遇到了問題？本文彙總了常見問題，助你快速定位並迅速部署 DeepSeek。
歡迎廣大開發者訪問魔樂社群 DeepSeek 專區查收更多適配模型和技術乾貨：https://modelers.cn/topics/deepseek

1. 效能問題

1.1 問題現象：部署 DeepSeek 服務化，效能不及預期

模組

效能測試

關鍵字

效能裂化，OS 核心，日誌，環境

問題描述

MindIE 版本：2.0.T3 模型型別：DeepSeekV3/R1
部署 DeekSeekV3/R1 拉起後實測效能較差，與預期差異較大。

可能原因

  • 日誌級別問題
  • OS 核心版本問題
  • 環境變數最佳化問題

排查方法

原因 1：

在傳送請求時，觀察日誌中是否存在大量的 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-smiset-treset-i{RankId}-c0-m1

步驟 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" 修改回原層數
END
熱門文章
Gitee開源MCP Server：讓AI直接操作程式碼倉庫的“外掛”
大模型時代的軟體工程平臺：讓人類的歸人類，讓智慧的歸智慧
“太鏽啦”——SpacetimeDB 1.0正式釋出，Rust編寫的開源關係型資料庫
AI正在培養一代不會程式設計的“文盲程式設計師”
為了“取悅”使用者，大語言模型表現出強烈的“諂媚”傾向
↓分享、在看與點贊~Orz

相關文章