背景

使用MindIE提供的PD分離特性部署qwen2-7B模型，使用k8s拉起容器，參考這個文檔進行部署：https://www.hiascend.com/document/detail/zh/mindie/100/mindieservice/servicedev/mindie_service0060.html，1個Prefill，1個Decode。

最后一步測試推理請求的時候，出現(xiàn)報錯：model instance has been finalized or not initialized。

排查過程

不管發(fā)生什么，不要慌，首先要看日志，重點看看有沒有fail、error等關鍵字。

P節(jié)點和D節(jié)點都是用mindieservice-daemon起的服務，最后打印了”daemon start success!“，看上去沒有問題，但是用npu-smi info查看昇騰卡的顯存占用，發(fā)現(xiàn)沒有顯存被占用，說明模型沒有加載，和上面的報錯信息邏輯對上了。

于是繼續(xù)看controller和coordinator的啟動日志。其實有一定經(jīng)驗后，通過”model instance has been finalized or not initialized“就知道應該是controller出問題了，因為controller負責PD身份決策與下發(fā)，coordinator是數(shù)據(jù)面入口，用于對用戶的請求輸入進行調(diào)度。果然，在controller的日志里面發(fā)現(xiàn)這一一行Error日志：IsValidServer: server ip 10.xxx has invalid device num。這說明，controller在嘗試分配P或者D的時候，發(fā)現(xiàn)某個節(jié)點上沒有可用的device。由于device的信息是在rank_table文件中配置的，所以下一步需要檢查rank_table文件。

果然，打開rank_table文件一看，發(fā)現(xiàn)rank_table文件中沒有device字段！這樣的話controller廣播給P和D的rank_table中就缺失了device信息，導致P和D的server啟動找不到昇騰卡。

根因找到了就好辦了。

解決方案

對開發(fā)者最友好的方案，當然是修改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文件中，所以我們可以在創(chuàng)建容器的時候，把宿主機的/etc/hccn.conf掛載進容器，然后在容器中使用npu-smi info命令查看容器中的卡號（每個容器掛載了1張卡），再根據(jù)卡號和/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“出現(xiàn)，同時可以看到P和D的日志中在加載模型，說明P和D創(chuàng)建成功了。

稍等一會可以看到coordinator的日志中出現(xiàn)”MindIE-MS coordinator is ready!!!“，說明PD分離服務部署成功了，這時候再用curl命令向coordinator節(jié)點發(fā)送推理請求，就可以得到回復了。

總結

需要清楚controller、coordinator、P server和D server節(jié)點的職責，再根據(jù)日志中的error信息和fail信息進行逐步分析。

本文由博客一文多發(fā)平臺 OpenWrite 發(fā)布！