背景
使用MindIE提供的PD分离特性部署qwen2-7B模型，使用k8s拉起容器，参考这个文档进行部署：https://www.hiascend.com/document/detail/zh/mindie/100/mindieservice/servicedev/mindie_service0060.html，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信息进行逐步分析。
