当我们在生产环境里启动一套 Ascend MindIE 服务时，脚本往往比模型更容易出问题。这篇文章记录了笔者在部署大模型的过程中，围绕一个启动脚本，逐层排查并最终解决问题的过程——希望能帮到同样在 MindIE / Ascend 生态里摸索的你。

---

0、背景与脚本介绍

我们要启动 MindIE 服务，核心启动脚本如下（节选）：

docker run ... \
  -v /etc/mindie-models/$model_name:/huawei/model \
  -w /huawei \
  mindie-3:$VERSION \
  /bin/bash -c "bash start_mindie.sh;/bin/bash"

功能很直观：

• 模型路径准备
• 检查镜像
• 启动容器 & 运行 MindIE

看似简单，但真正跑起来，却出现了一系列问题。

---

1、第一阶段：模型路径错误

首次启动，日志里出现：

Get realpath parsing failed.
Failed to check model weight path.

表象看起来像：

Ascend / MindIE 出问题了？

但继续往前翻日志，发现这一段：

setting 640 to model path
chmod: cannot access '*': No such file or directory

也就是说：

/huawei/model 里根本没有文件

而 /huawei/model 是谁？

-v /etc/mindie-models/$model_name:/huawei/model

它其实是宿主机上的：

/etc/mindie-models/$model_name

进一步排查发现：

目录 是存在的，但是 —— 是空的。

导致原因是脚本中的逻辑：

if [ -d "$mindie_model_path" ]; then
  echo "start running model"
else
  # copy model
fi

只判断了目录存在，但没有判断是否为空。
而 Docker 早就帮我们创建过这个目录 → 于是：

• 目录存在
• 但模型文件没复制
• MindIE 看不到权重
• 直接崩

解决策略

增加“目录非空判断”：

if [ -d "$mindie_model_path" ] && [ "$(ls -A $mindie_model_path 2>/dev/null)" ]; then
  echo "model dir exists and not empty"
else
  echo "prepare model files..."
  mkdir -p "$mindie_model_path"
  cp -r $traind_model_path/* $mindie_model_path/
  cp tokenizer*.json vocab.json $mindie_model_path/
fi

至此，模型问题解决。

---

2、第二阶段：Python 报 Unknown option: -P

正觉得一切顺利时，又来了新的报错：

Unknown option: -P
usage: python3 [options]

看起来是：

MindIE 里的 Python 不支持 -P ？

但真正的线索在：

/home/hwuser/anaconda3/envs/ldc/bin/python3

这不是容器里的 Python，而是宿主机 Conda 里的 Python。

为何会跑到容器里？

因为启动脚本里有一行：

-e PATH=$PATH:/usr/local/python3.10.12/bin:...

意味着：

1. 把宿主机 PATH 带进容器

2. /home 又被挂载：

   -v /home/:/home/
   

3. 于是容器里「也能访问宿主机 conda」

结果：

python3 -> /home/hwuser/anaconda3/envs/ldc/bin/python3

这个 Python 不支持 -P 参数 → 报错。

解决方案

不要把宿主机 PATH 带进来：

# 直接删掉
# -e PATH=$PATH:...

如果确实要加目录：

-e PATH=/usr/local/python3.10.12/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

谨慎使用 $PATH

---

3、第三阶段：docker: invalid reference format

脚本再次运行，竟然又报新错：

docker: invalid reference format.

这类错误，通常源于：

Docker 认为“镜像名格式不合法”

检查 docker run 语法：

docker run [options] IMAGE [command]

而我们的脚本是：

-w /huawei /bin/bash -c "bash start_mindie.sh"

Docker 就把：

/bin/bash

解释成 镜像名，自然报错。

正确写法

必须把镜像名补上：

docker run ... \
  -w /huawei \
  mindie-3:$VERSION \
  /bin/bash -c "bash start_mindie.sh;/bin/bash"

至此，容器成功启动，MindIE 服务也正常。

---

4、这次 Debug 的 3 个关键教训

（1）判断“目录存在” ≠ 判断“模型已准备好”

部署脚本应该做：

✔ 目录存在
✔ 目录非空
✔ 关键文件存在（weights/tokenizer 等）

---

（2）容器里不要盲目复用宿主机 PATH

特别是：

• Conda
• Anaconda
• 自定义 Python 环境

一旦被挂载 + 注入 PATH，就会污染容器运行环境。

---

（3）Docker 语法要记牢：镜像名必须在 command 前

docker run [options] IMAGE [command]

命令越复杂，就越容易把 IMAGE 忘在中间。

---

5、在生产环境部署 MindIE 的一些建议

📌 写健壮的脚本

• 统一检查
• 防止误判
• 提前 fail-fast

📌 尽量不要传宿主机 PATH

📌 复杂场景下推荐显式打印关键路径

echo "MODEL PATH: $(realpath /huawei/model)"
ls -lh /huawei/model

📌 遇到 realpath failed → 先看挂载

---

6、总结

这次 Debug 的过程，从最底层的文件挂载，一路排到了：

• 模型目录结构
• PATH 污染
• docker 语法问题

实际上是一个非常典型的 “90% 问题不在 AI，在系统工程” 的案例。如果读者朋友们也在 Ascend 上部署 MindIE、vLLM、推理服务、微服务 Agent 平台——希望这篇文章，能在下一次奇怪的报错出现时，给大家一些启发。