背景
使用MindIE提供的PD分离特性部署qwen2-7B模型,使用k8s拉起容器,参考这个文档进行部署:https://www.hiascend.com/document/detail/zh/mindie/100/mindie...,1个Prefill,1个Decode。
最后一步测试推理请求的时候,出现报错:model instance has been finalized or not initialized。
排查过程
不管发生什么,不要慌,首先要看日志,重点看看有没有fail、error等关键字。
P节点和D节点都是用mindieservice-daemon起的服务,最后打印了”daemon start success!“,看上去没有问题,但是用npu-smi info查看昇腾卡的显存占用,发现没有显存被占用,说明模型没有加载,和上面的报错信息逻辑对上了。
于是继续看controller和coordinator的启动日志。其实有一定经验后,通过”model instance has been finalized or not initialized“就知道应该是controller出问题了,因为controller负责PD身份决策与下发,coordinator是数据面入口,用于对用户的请求输入进行调度。果然,在controller的日志里面发现这一一行Error日志:IsValidServer: server ip 10.xxx has invalid device num。这说明,controller在尝试分配P或者D的时候,发现某个节点上没有可用的device。由于device的信息是在rank_table文件中配置的,所以下一步需要检查rank_table文件。
果然,打开rank_table文件一看,发现rank_table文件中没有device字段!这样的话controller广播给P和D的rank_table中就缺失了device信息,导致P和D的server启动找不到昇腾卡。
根因找到了就好办了。
解决方案
对开发者最友好的方案,当然是修改MindIE镜像 /usr/local/Ascend/mindie/latest/mindie-service/examples/kubernetes_deploy_scripts/gen_ranktable_helper 目录下的gen_global_ranktable.py文件。但是为了快速解决问题,我们手动获取device字段的信息,再添加到rank_table中。
device字段的格式如下:
"device":[
{
"device_id":0,
"device_ip":"xxx.xxx.xxx.xxx",
"device_logical_id":"0"
}
]
由于客户使用了k8s进行容器化部署,而device的device_ip信息在宿主机的/etc/hccn.conf文件中,所以我们可以在创建容器的时候,把宿主机的/etc/hccn.conf挂载进容器,然后在容器中使用npu-smi info命令查看容器中的卡号(每个容器挂载了1张卡),再根据卡号和/etc/hccn.conf获取卡的device_ip。由于容器中只有1张卡,device_logical_id就是取0。
通过上面的方法获取到P和D的device信息后,再添加到rank_table文件中,重新启动。重新启动后,有个新的报错”read ./conf/model_config/qwen2-b.json failed“,这个报错比较常见,把文件权限修改成640就可以了。再重新启动,可以看到controller中有日志”avaliable node 2“出现,同时可以看到P和D的日志中在加载模型,说明P和D创建成功了。
稍等一会可以看到coordinator的日志中出现”MindIE-MS coordinator is ready!!!“,说明PD分离服务部署成功了,这时候再用curl命令向coordinator节点发送推理请求,就可以得到回复了。
总结
需要清楚controller、coordinator、P server和D server节点的职责,再根据日志中的error信息和fail信息进行逐步分析。
本文由博客一文多发平台 OpenWrite 发布!
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。