01 硬件要求及组网
推荐参考配置如下,部署DeepSeek-V3/R1量化模型至少需要多节点Atlas 800I A2(8*64G)服务器。本方案以DeepSeek-R1为主进行介绍,DeepSeek-V3与R1的模型结构和参数量一致,部署方式与R1相同。
02 运行环境准备
推荐使用镜像部署
1、镜像部署
昇腾官方在Ascend hub提供环境示例镜像,含推理部署配套软件以及模型运行脚本,用户可参考构建运行环境镜像进行部署。
镜像部署及启动参照ModelZoo指南中“加载镜像”章节,该指南中还包含“容器启动”等指引 Ascend/ModelZoo-PyTorch - Gitee.com
镜像申请/下载(含于上述指南): 昇腾镜像仓库详情
2、裸机部署
根据昇腾社区发布的MindIE安装指南安装软件包和运行依赖软件。
安装指南:
根据指南安装全部软件包和环境安装方案-MindIE安装指南-环境准备-MindIE1.0.0开发文档-昇腾社区
模型获取: Ascend/ModelZoo-PyTorch - Gitee.com
03 权重文件准备
BF16权重下载:
1、HuggingFace:https://huggingface.co/unsloth/DeepSeek-V3-bf16/
2、ModelScope:魔搭社区
3、Modelers:魔乐社区
INT8量化后权重下载:魔乐社区
如已下载BF16模型,也可采用以下步骤进行模型量化,权重BF16->INT8转换预计7~8小时。
更多详细量化教程请参考 DeepSeek 量化文档( msit: 统一推理工具链入口,提供客户一体化开发工具,支持一站式调试调优 - Gitee.com) Msmodelslim 代码仓:msit: 统一推理工具链入口,提供客户一体化开发工具,支持一站式调试调优 - Gitee.com
04 运行前检查
服务器检查:Ascend/ModelZoo-PyTorch - Gitee.com
软件版本配套检查,含: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 模型部署与配置
独立模型:
Ascend/ModelZoo-PyTorch - Gitee.com
服务化部署:
1、运行指南
Ascend/ModelZoo-PyTorch - Gitee.com
2、服务启动
启动服务-快速开始-MindIE Service开发指南-服务化集成部署-MindIE1.0.0开发文档-昇腾社区
3、接口指引
说明-服务化接口-MindIE Service开发指南-服务化集成部署-MindIE1.0.0开发文档-昇腾社区
06 模型运行
1、纯模型测试
模型脚本已预制在镜像中,参照以下链接即可拉起精度测试及模型测试 Ascend/ModelZoo-PyTorch - Gitee.com
2、服务化测试
1、运行指南
Ascend/ModelZoo-PyTorch - Gitee.com
2、服务启动
启动服务-快速开始-MindIE Service开发指南-服务化集成部署-MindIE1.0.0开发文档-昇腾社区
3、常用接口指引
说明-服务化接口-MindIE Service开发指南-服务化集成部署-MindIE1.0.0开发文档-昇腾社区
常见问题及解决方案
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的环境变量中却有确定性计算相关的环境变量。尽管执行推理请求的节点确定性计算相关的环境变量是关闭状态,仍可能影响推理卡住。
所以,请一定要一一核对好每个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 路径下。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。