DeepSeek部署技术问题FAQ

摘要：在进行 DeepSeek 昇腾部署时，你是否遇到了问题？本文汇总了常见问题，助你快速定位并迅速部署 DeepSeek。

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 网络通信存在问题

排查方法

检测防火墙

检测 NPU 状态

检测 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 开关是否一致

所有机器的所有卡要么为 1，要么为 0。建议修改为 0 进行关闭。

TLS 关闭方法（-i 后面填写卡的 ID）

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

步骤 5：本机卡间通信检测

进入任意目录创建一个 test.py

文件文件加入如下脚本

import subprocessip_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.stripif '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 推理启服务出现 Failed to init endpoint! Please check the service log or console output.

可能原因

开启 HTTPS，但未设置证书导致的问题。

排查方法

查看日志是否存在图片中描述的报错

解决方案

httpsEnabled 设置的 true，如果为 true 的情况下需要配置证书，请检查证书配置是否正确。证书配置请参考 MindIE 社区文档：

将 httpsEnabled 修改为 false

3 精度问题 3.1 问题现象：多机拉起 DeepSeek-R1 模型服务化后，发送推理请求，返回内容乱码模块

模型推理

请求、乱码

问题描述

四机部署 deepseekR1，启服务后，发送推理请求，返回内容乱码，没有报错，例如下图：

可能原因

用户使用的模型配置文件和官网文件有差异，导致返回异常。

排查方法

模型权重目录里的所有配置文件请与 Modelers，HuggingFace 等官方网站所上传的权重等文件进行对比。

解决方案

把模型权重目录里的所有配置文件和官网上的文件对齐之后只修改 config.json 中的 model_type 更改为 deepseekv2（只有这一处修改），推理返回正常。

4. 安装部署问题 4.1 题现象：NPU 卡健康检查返回错误，提示 timeout 模块

安装部署

NPU、健康检查、Receive timeout

问题描述

多机拉起 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

问题描述

多机拉起 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、卡死

问题描述

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" 修改回原层数