昇腾部署第 D1 课：L3 服务层——推理服务是怎么跑起来的

编制：观澜｜日期：2026-10-05｜级别：T2 标准级 层级：D 层 · L3 服务（D 层第 1 课；L2 已在 C1–C3 讲完）素材来源：昇腾官方文档 MCP 实时抓取（MindIE 3.1.0 官方文档）数据纪律：组件定义、职责、官方推荐路线逐字出自官方文档；标注「归纳」的是便于记忆的整理，非官方口径。

第一段 · 章前定位

A0《一张地图》给过五条部署成功判据，第四条是：

端口 + curl 服务起得来

前面九课（A/B/C）把"服务"下面的三层都铺好了：

L2 框架（C 层）    ← 模型能跑起来
L1 基础软件（B 层） ← CANN 就位
L0 硬件与环境（A 层）← 卡可用

但从这一课开始，问题变了：

模型能在你的脚本里跑出结果，和"别人能通过网络调用它"，是两件事。 中间缺的那一层，就是 L3 服务。

这一课回答最基础的问题：

为什么需要"推理服务"这一层？它到底解决了什么？ MindIE 是什么？它和 vLLM、SGLang 是什么关系？ 为什么官方文档里"组件"有那么多名字？

⚠️ 而且这一课会讲一条很重要的变化 —— 官方已经调整了推理服务的推荐路线（第六段）。 如果你照着两年前的资料学，会学到一条已经不演进的路。

第二段 · 学习目标

学完这一课，你应该能回答：

"推理服务"这一层解决了什么问题（为什么不能在脚本里直接跑）
MindIE 是什么（官方定义），它包含哪些组件
MindIE Motor 的五个子组件各干什么
⭐ 官方当前推荐的服务部署路线是什么，以及为什么
几个必须分清的概念：推理引擎 / 服务化框架 / PD 分离

第三段 · 为什么需要"服务"这一层

先用一个对照说明问题（归纳）：

	在脚本里跑模型（L2）	做成推理服务（L3）
谁来调用	你自己，写死在一个进程里	任何人，通过网络
并发	一次一个（或你自己写多线程）	服务层管
多卡	你自己分配	服务层调度
挂了怎么办	进程退出，你自己重启	要有健康检查和自愈
换模型	改代码重跑	换配置

归纳成一句：

L2 解决"能不能算"，L3 解决"能不能被别人用、扛得住、坏不了"。

官方给 L3 的定位（原文）

MindIE Motor 是面向大模型推理的分布式调度与服务化框架，致力于通过高性能调度、资源池化和故障自愈，提升大模型推理集群的 吞吐、资源利用率与服务可靠性。

官方这句话里三个词，正好对应 L3 要解决的三件事：

官方用词	解决什么
高性能调度	请求太多怎么办
资源池化	卡怎么分、怎么用满
故障自愈	坏了怎么办

⭐ 一个很实用的判断： 当你的问题是"能不能跑通"，看 A/B/C；当你的问题是"扛不住 / 用不满 / 老挂"，看 D。 两类的排查路径完全不同。

第四段【如果我来做】：从定路线到看日志的八步

如果你现在就把"把推理服务跑起来"这件事交给我，我不会一上来就装东西 —— 我会先在心里把顺序排好，再动手。

我会按这个顺序做：

① 先定路线（不装任何东西，先问清"该装什么"）—— 先查官方当前推荐哪条： MindIE Motor + vLLM Ascend（本课第六段）。路线定错，后面每一步都是返工。 ② 查卡与驱动（先摸底，再谈服务）—— 用 npu-smi info 确认 L0 就位。这一步把不可返工的事（卡型号、驱动版本）先查出来。 ③ 对版本与支持列表（先在别处对一遍，拿清单和坑）—— 照《vLLM Ascend 快速入门》的「要求」表核一遍 CANN / TorchNPU / 硬件的配套关系。版本不匹配是最贵的错。 ④ 备环境与模型 —— 先让容器挂到卡、权重放对位置（官方用容器搭环境，镜像里已打包 CANN + TorchNPU + vLLM Ascend）。 ⑤ 起服务（每步立刻验，不攒着一起验）—— 起完马上看端口和日志，别等全配完再排。 ⑥ 验端口与返回 —— 端口通不算成功，要看到模型真的把内容回出来。 ⑦ 看日志出证据（难验证的就找反面证据）—— 日志是唯一能自证的东西，成功失败都要留。 ⑧ 诚实 —— 官方没给答案的地方（本课未展开的配置字段、随版本变化的启动参数），明写"到 D2–D5 查"，不猜。

为什么按这个顺序：它是手伸进去的顺序，不是知识点平铺的顺序 —— 先定"走哪条路"，再摸硬件底细，最后才动手起服务； 每一步都有一个"看到什么才算过"的判断点，这才叫理论结合实际。

这八步里能照抄的命令（命令 + 结果）

下面所有命令、参数、镜像名、报错原文均出自官方文档（出处见附录 A）。版本以官方《vLLM Ascend 快速入门》（v0.23.0.post1）与 MindIE 3.1.0 为准， 版本会变，动手前回官方对一遍。

第 ② 步 · 查卡与驱动

命令　npu-smi info

含义：查询本机所有昇腾设备的基本信息 —— "卡到底认没认到"的第一条命令拆解：npu-smi（昇腾设备管理工具）＋ info（子命令：查信息）。官方口径：npu-smi info 查询所有设备的基本信息；npu-smi info -l 查询所有 NPU 设备（列出的 NPU ID 就是后面 -i 要填的设备 ID）用法：npu-smi info（看全部）｜npu-smi info -l（只看设备列表与 ID）｜npu-smi info -t memory -i 0（看 0 号卡内存）期望：打印出一张表，每张卡一行，含 NPU ID、产品型号、温度、显存占用 —— 表能列出来 = L0 就位 不过会怎样：报 command not found → 驱动没装（回 A1）；有命令但列不出卡 → 容器没挂卡或权限不足（回 B5 / A1）

第 ④ 步 · 备环境（把卡挂进容器）

命令　（官方《vLLM Ascend 快速入门》容器命令，多行原文，直接照抄）

export DEVICE=/dev/davinci0                            # 按实际卡改，/dev/davinci0 ~ /dev/davinci7
export IMAGE=quay.io/ascend/vllm-ascend:v0.23.0.post1  # A3 加 -a3；950DT 加 -950dt；300I DUO 用 -310p
docker run --rm \
--name vllm-ascend \
--shm-size=1g \
--device $DEVICE \
--device /dev/davinci_manager \
--device /dev/devmm_svm \
--device /dev/hisi_hdc \
-v /usr/local/dcmi:/usr/local/dcmi \
-v /usr/local/bin/npu-smi:/usr/local/bin/npu-smi \
-v /usr/local/Ascend/driver/lib64/:/usr/local/Ascend/driver/lib64/ \
-v /usr/local/Ascend/driver/version.info:/usr/local/Ascend/driver/version.info \
-v /etc/ascend_install.info:/etc/ascend_install.info \
-v /root/.cache:/root/.cache \
-p 8000:8000 \
-it $IMAGE bash

含义：起一个挂好昇腾卡的 vLLM Ascend 容器，把宿主机的驱动与设备节点映射进去拆解：--device（把芯片设备节点给容器，容器能用卡的关键）｜-v /usr/local/Ascend/driver/...（映射宿主机驱动，容器不装第二份）｜-p 8000:8000（把容器 8000 端口放到宿主机）用法：镜像按卡换后缀（见代码注释）；进容器后按官方步骤 apt-get update -y && apt-get install -y curl（容器里要装 curl 才能验）期望：进入容器命令行（提示符切到容器内），说明卡与驱动都已映射进来 不过会怎样：容器里 npu-smi 看不到卡 → 设备节点没挂全（A3 是双 DIE，要挂 2 个设备节点，见 D2 / B5）

第 ⑤ 步 · 起服务（vLLM Ascend 路线）

命令　vllm serve Qwen/Qwen3-0.6B &

含义：用 vLLM 起一个 OpenAI 兼容的推理服务，结尾 & 让它后台跑拆解：vllm serve（起服务子命令）＋模型名 Qwen/Qwen3-0.6B（官方示范用的最小模型）｜& = 放到后台，前台还能继续敲命令用法：第一次跑要下模型（官方提示约 3–5 分钟，10 MB/s）；连不上 HuggingFace 就先 export VLLM_USE_MODELSCOPE=True 期望：日志出现 INFO: Application startup complete. 与 INFO: Uvicorn running on http://0.0.0.0:8000 —— 这两行出来才算起来了 不过会怎样：看到 We couldn't connect to 'https://huggingface.co' to load the files → 网络问题，按上面切 ModelScope；看到 Engine core ... died unexpectedly → 回看更上面的报错，多半是卡 / 显存 / 版本，不是服务本身

第 ⑤ 步（另一条路）· 用 MindIE Motor 起服务

命令　python3 deploy.py --config_dir ../infer_engines/vllm（在 examples/deployer/ 目录下执行）

含义：官方主线 MindIE Motor 的部署脚本，读 user_config.json 后拉起 PD 实例与调度组件拆解：deploy.py（官方部署脚本）＋ --config_dir（指定整套配置目录，官方推荐用法；也有 --user_config_path + --env_config_path 的单文件用法）用法：先 cd examples/deployer/，并改好 ../infer_engines/vllm/user_config.json（镜像名 / 硬件类型 / 权重路径 / 端口）与 env.json 期望：脚本按配置拉起各组件，日志目录 examples/deployer/log_collect/log 开始持续刷新 不过会怎样：报端口冲突 → 官方要求各组件端口互不重叠（Controller / Coordinator / P / D 各有端口段，见 D3）；提示权重路径不对 → 先确认 weight_mount_path 指向的目录存在且已 chmod

第 ⑥ 步 · 验端口与返回（vLLM Ascend 路线）

命令　curl http://localhost:8000/v1/models | python3 -m json.tool

含义：向刚起的服务要一次「模型列表」，确认端口通、服务在应答拆解：curl（发一次 HTTP 请求）＋ /v1/models（OpenAI 兼容的模型列表接口）｜| python3 -m json.tool 把返回的 JSON 排版，便于看用法：只看端口通不通：curl -I http://localhost:8000/v1/models｜验真实推理：curl http://localhost:8000/v1/completions -H "Content-Type: application/json" -d '{"model":"Qwen/Qwen3-0.6B","prompt":"Beijing is a","max_completion_tokens":5,"temperature":0}' | python3 -m json.tool 期望：返回一个 JSON，data 里能看到模型名 —— 有内容回来说明服务真的在工作（空返回 / 空补全不等于成功） 不过会怎样：Connection refused → 服务没起或端口没放出来（回第 ④ / ⑤ 步）；返回很长但不含生成文本 → 请求体写错（模型名或 JSON 格式）

第 ⑥ 步（另一条路）· 验 MindIE Motor 的返回

命令　curl -X POST http://127.0.0.1:31015/v1/chat/completions -H "Content-Type: application/json" -d '{"model":"qwen3-8B","messages":[{"role":"user","content":"who are you?"}],"max_tokens":36,"stream":true}'

含义：按官方《MindIE Motor 快速入门》的方式，给 Motor 服务发一次对话请求拆解：-X POST（发 POST 请求）＋ /v1/chat/completions（对话接口）｜-H "Content-Type: application/json" 声明请求体是 JSON｜-d '...' 是请求体（模型名、消息、最大 token、是否流式）用法：端口 31015 取自官方快速入门；实际端口以你 user_config.json 里的配置为准 期望：流式返回一段段 data: {...}，最后以 data: [DONE] 结束 —— 这就是已就绪 不过会怎样：返回 {"detail":"Service is not available"} → 官方原话是「尚未启动就绪」，不是坏了，等一会儿再发一次即可

第 ⑦ 步 · 看日志出证据（两条路线都适用）

命令　cat mindie-service_123_202410080206.log

含义：查看 MindIE 组件日志 —— 排查时唯一能"自证"的材料拆解：官方日志文件名格式统一为 mindie-<组件名称>-_pid_datetime.log，可按组件名 / 进程号 / 时间戳定位到具体文件 用法：默认落盘路径 ~/mindie/log（安全日志在 ~/mindie/log/security，调试日志在 ~/mindie/log/debug）；不知文件名就先 ls -lt ~/mindie/log 按时间挑最新的｜Motor 在 k8s 部署时，官方用 bash show_log.sh 收集，日志聚到 examples/deployer/log_collect/log 期望：能看到带时间戳、进程号、级别的日志行；起服务时找 Application startup complete、Platform plugin ascend is activated 这类成功标志 不过会怎样：~/mindie/log 为空 → 落盘路径被 MINDIE_LOG_PATH 改到了别处（官方支持用该环境变量配置）；只想在终端看 → 官方有 MINDIE_LOG_TO_STDOUT 控制是否打印到标准输出

第五段 · 组件全景（官方表 1）

先钉住定义：MindIE 是什么（官方原文）

官方原文：

MindIE（Mind Inference Engine，昇腾推理引擎）是华为昇腾针对 AI 全场景业务的 推理加速套件。通过分层开放 AI 能力，支撑用户多样化的 AI 业务需求，使能百模千态，释放昇腾硬件设备算力。 向上支持多种主流 AI 框架，向下对接不同类型昇腾 AI 处理器，提供多层次编程接口，帮助用户快速构建基于昇腾平台的推理业务。

从这段定义里读三件事（归纳）

① 全称是 Mind Inference Engine（昇腾推理引擎） —— 注意是推理（Inference），不是训练。 这一层是给"用模型"的人准备的，不是给"训模型"的人。

② 它的结构与 CANN 惊人地相似（B1 讲过）： - CANN：「向上支持多种 AI 框架……向下服务 AI 处理器」 - MindIE：「向上支持多种主流 AI 框架，向下对接不同类型昇腾 AI 处理器」

"上接框架、下接芯片"这个位置，在每一层都会重复出现。 CANN 是 L1 的中间层，MindIE 是 L3 的中间层。

③ 它是"套件"不是"一个软件" —— 和 HDK（A3）、CANN（B1）一样：先有总名，再拆具体组件。

再拆组件：官方给出的组件介绍表

官方《MindIE 是什么》给出的组件介绍表：

名称	官方说明（摘要）
MindIE Motor	面向大模型推理的分布式调度与服务化框架，通过高性能调度、资源池化和故障自愈，提升集群的吞吐、资源利用率与服务可靠性，目前支持 vLLM-Ascend 推理引擎
MindIE SD	构建昇腾亲和的多模态加速系列套件，配合业内模型套件（如 diffusers），实现多模态推理在昇腾上的效率；专注提供多模态生成的关键算子和融合算子，配合量化/稀疏算法、以存代算、多卡并行等策略
MindIE LLM	针对大模型优化的高性能 SDK，包含深度优化的模型库、大模型推理优化器和运行环境……

三个组件的分工（归纳）

MindIE（昇腾推理引擎）
  ├── MindIE Motor  →  服务化 / 调度 / 集群  ← 本层的主角
  ├── MindIE SD     →  多模态（图/视频生成）
  └── MindIE LLM    →  大模型推理 SDK  ← ⚠️ 见第六段

一句话区分： - Motor 管"怎么服务"（请求分发、调度、集群） - SD 管"多模态"（视图生成） - LLM 管"大模型怎么跑得快"（模型库 + 优化器）

⚠️ 还有一个命名变化要记住（官方原文）： 原 MindIE Motor 代码仓自 3.1.0 版本起正式更名为 MindIE Motor CPP，后续版本发布将统一使用此命名。该组件仅对接 MindIE LLM 推理引擎。

看文档时别把 'MindIE Motor' 和 'MindIE Motor CPP' 当成两个东西 —— 是同一个组件的更名，但对接的引擎不同（前者对 vLLM-Ascend，后者对 MindIE LLM）。

第六段 · ⭐ 一条重要的官方变化（本课最该记住的）

官方在 MindIE LLM 这一栏里，明确写了这样一段话（原文）：

MindIE LLM 组件「将暂停后续功能演进」，现有功能维持维护状态， 不再支持新特性和新模型。 推荐使用 MindIE Motor + vLLM Ascend 部署推理服务。 关于 vLLM Ascend 的快速部署，请参阅官方文档的《快速开始》章节。

这段话说清了三件事

官方原文	意味着什么
"将暂停后续功能演进"	这条路不再往前走了
"现有功能维持维护状态"	还能用，但不会有新东西
"推荐使用 MindIE Motor + vLLM Ascend"	当前官方推荐路线

这对你意味着什么（归纳）

① 学的时候按"新路线"学： - 主线：MindIE Motor + vLLM Ascend - 支线（维护状态）：MindIE LLM

② 看老资料要留个心眼：网上大量"昇腾部署 MindIE 推理服务"的教程基于 MindIE LLM 路线。 它们不算错，但已经不演进 —— 遇到"照着做但官方文档找不到对应章节"的情况，先想想是不是路线变了。

③ 这也印证了 C 层的一个结论（C2/C3）： 昇腾生态里"框架/引擎"的路线是会调整的 —— 所以"版本配套关系"和"官方推荐路线"这两件事，部署前都要查，不能靠经验。

⭐ 本课最实用的一条： 部署任何昇腾推理服务之前，先到官方《MindIE 是什么》页面看一眼组件表 —— 它会告诉你当前哪个组件是主线、哪个已经进入维护。

第七段 · 三个必须先分清的概念

官方文档里这几个词高频出现，且容易混。先用官方原文把它们钉住。

概念一：推理引擎（Inference Engine）

官方在 Motor 的说明里写：「目前支持 vLLM-Ascend 推理引擎」。在 EngineServer 的说明里写：「南向对接 vLLM-Ascend 框架」。

归纳：推理引擎 = 真正把模型跑在卡上、做推理计算的那一层。 在昇腾上，当前主线是 vLLM-Ascend。

概念二：服务化框架

官方原文：MindIE Motor 是"面向大模型推理的分布式调度与服务化框架"。

归纳：服务化框架 = 把推理引擎包起来，对外提供稳定服务的那一层 —— 管请求分发、调度、集群、可靠性。

两者的关系（归纳）：

       用户的 HTTP 请求
              ↓
   ┌──────────────────────┐
   │  服务化框架           │   ← MindIE Motor（管分发/调度/可靠性）
   │  (MindIE Motor)      │
   └──────────────────────┘
              ↓
   ┌──────────────────────┐
   │  推理引擎             │   ← vLLM-Ascend（管真算）
   │  (vLLM-Ascend)       │
   └──────────────────────┘
              ↓
         昇腾硬件

一句话：Motor 是"门面和调度"，vLLM-Ascend 是"后厨"。

概念三：PD 分离

官方原文（关键功能特性 · 服务化部署）：

MindIE Motor 提供将外部的客户请求分发到负载最低的 Prefill/Decode 实例上，起到负载均衡的作用，并增强 PD 分离服务的可靠性、可用性和可服务性。

归纳：大模型推理分两个阶段 —— Prefill（预填充） 和 Decode（解码）， PD 分离就是"把这两个阶段拆到不同实例上跑"。

为什么这件事值得单独讲：它是 L3 服务层最核心的架构概念之一，也是官方 Motor 反复提到的能力。 但本课只把"有这回事、官方这么称呼"钉住，机制留到 D4 展开。

⚠️ 数据纪律提示：本课只给出"PD 分离"这个官方术语与它的作用描述， 不展开 Prefill/Decode 的计算原理（那属于模型/推理层，且官方另有专门文档）。

第八段 · 出问题怎么查

先分清"我在哪条路"

L3 层的排查，第一步是确认路线（归纳）：

① 我部署的是 MindIE Motor + vLLM Ascend（主线）还是 MindIE LLM（维护线）？
② 若是主线 → 官方文档看《MindIE Motor》与《vLLM Ascend》的文档树
③ 若是维护线 → 官方文档看《MindIE LLM》的文档树，且注意它不再有新特性
④ 然后才看具体报错

为什么要先做这一步：两条路的目录结构、配置文件、启动命令、报错文本都不一样 —— 看着"都是 MindIE"的报错，其实在两条路上根本不通用。

分层排查表（把前面几课串起来）

现象	问题可能在	去哪一课
服务起不来，`npu-smi` 也看不到卡	L0	A1（驱动）/ B5（容器没挂卡）
卡在，但报找不到算子	L1	B2（算子库）/ B3（版本配套）
模型加载失败 / 框架报错	L2	C1–C3
服务进程在，但端口不通 / curl 无响应	L3	本层（D2–D5）
能起但一压就崩、吞吐上不去	L3 调优	D5
多卡 / 多机跑不起来	L3 集群	D3（Motor）

对照 A0 的五条判据：判据 ④ 是"端口 + curl 服务起得来"—— 这一课就是判据 ④ 的入口。它过不了，先确认路线（本节第一步），再看具体报错。

⭐ 一个最省时间的判断法

L3 的问题，先分清是"服务没起来"还是"算得不对"。

类型	表现	方向
服务没起来	端口不通、curl 无响应、进程不在	L3 的部署与配置（D2–D5）
服务起来了但算得不对/很慢	能返回结果，但结果错或慢	往下查：L2（框架）/ L1（算子）/ 调优（D5）

"服务通不通"和"算得对不对"是两条线 —— 先确认前者。

常见报错清单（原文出自官方文档与官方故障案例库）

用法：先在现象这一列找到你看到的那句原文，再顺着"先查哪里"走。 报错的位置 ≠ 问题的位置 —— 在 L3 报的错，根因可能在 L0/L1（E1 讲过，L3 尤其常见）。

你看到的原文	它其实在说什么	先查哪里
`{"detail":"Service is not available"}`	服务尚未就绪（不是坏了），等一会儿再发一次	官方《MindIE Motor 快速入门 · 推理验证》
`Failed to init endpoint! Please check the service log or console output.`	推理服务端点初始化失败，日志里有更早的根因	官方案例 `topic_0000002193313946`（查看 6455）
启动 MindIE Service 时找不到 `libboost_thread.so.1.82.0`	运行时动态库缺失	官方案例 `topic_0000002215064906`（查看 680）
用脚本 / Benchmark 发请求超时且无返回	服务在，但请求不回	官方案例 `topic_0000002215083154`（查看 1042）
发请求返回乱码	返回体异常	官方案例 `topic_0000002249944921`（查看 629）
加载模型时 `out of memory`	显存不够（模型过大 / 显存占用配得太高）	官方案例 `topic_0000002250112009`（查看 725）
`infer shape check fail` / `invalid reshape func`	并行配置与模型不匹配	官方案例 `topic_0000002598936025`（查看 1494）
`We couldn't connect to 'https://huggingface.co' to load the files`	连不上 HuggingFace，切 ModelScope：`export VLLM_USE_MODELSCOPE=True`	官方《vLLM Ascend 快速入门》

案例在哪查：官方案例库 https://www.hiascend.com/document/caselibrary/detail/<案例编号> —— 用编号直接跳，不要靠搜标题（搜关键词常搜不到，本课实测 启动失败、端口占用 都是 0 条，改用组件名 MindIE 才命中）。

第九段 · 小结与下一课

三句话带走

L3 服务层解决的是"能不能被别人用、扛得住、坏不了" —— L2 解决"能不能算"。L3 的三个关键词（官方原话）：高性能调度、资源池化、故障自愈。
MindIE 是昇腾推理引擎（Mind Inference Engine），是个套件不是一个软件： Motor（服务化/调度）/ SD（多模态）/ LLM（大模型 SDK）。
⭐ 官方当前推荐路线：MindIE Motor + vLLM Ascend。 MindIE LLM 已"暂停后续功能演进"，不再支持新特性和新模型。

本课在体系里的位置

─── L0 硬件与环境（A 层，已完成）─── A0 / A1 / A2 / A3
─── L1 基础软件（B 层，已完成）─── B1 / B2 / B3 / B4 / B5
─── L2 框架（C 层，已完成）─── C1 / C2 / C3
─── L3 服务（D 层）───
D1 L3 服务层：推理服务是怎么跑起来的        ★ 本课
D2（拟）vLLM Ascend：当前推荐的推理引擎
D3（拟）MindIE Motor：五个子组件各干什么
D4（拟）PD 分离与混部：为什么把 Prefill 和 Decode 拆开
D5（拟）服务起停、端口与调优
─── 排障（E 层）─── E1

本课留下的"钩子"

钩子	在哪一课填
vLLM-Ascend 是什么、怎么装、怎么起	D2
Motor 的 Controller / Coordinator / Deployer / EngineServer / NodeManager 各干什么	D3
PD 分离的完整机制与收益	D4
端口、健康检查、限流、主备倒换	D5
量化（msModelSlim）属于哪一层	A0 的地图里在 L4 应用层，D 层之后

课后自测（3 题）

用一句话说清"在脚本里跑模型"和"做成推理服务"的差别。L3 官方给的三个关键词是什么？
MindIE 的三个组件（Motor / SD / LLM）各管什么？哪个是当前主线，哪个已进入维护状态？
"推理引擎"和"服务化框架"在映射图里各处于什么位置？官方当前推荐的是哪一对组合？

附录 A · 本课引用的官方出处

内容	出处
MindIE 的定义（Mind Inference Engine，昇腾推理引擎，全场景推理加速套件，向上/向下范围）	官方《MindIE 是什么》 `zh/mindie/310/whatismindie/MindIE/26.1.0/zh/what_is_mindie.md`
表 1 组件介绍（MindIE Motor / SD / LLM 三者的官方说明）	同上
MindIE LLM「将暂停后续功能演进……推荐使用 MindIE Motor + vLLM Ascend 部署推理服务」	同上（MindIE LLM 一栏）
Motor 的五个子组件（Controller / Coordinator / Deployer / EngineServer / NodeManager）及各自职责	同上（MindIE Motor 一栏）
「高性能调度、资源池化和故障自愈」「提升吞吐、资源利用率与服务可靠性」	同上
关键功能特性 · 服务化部署：「分发到负载最低的 Prefill/Decode 实例」「PD 分离」	同上
MindIE Motor 更名为 MindIE Motor CPP（自 3.1.0 起），仅对接 MindIE LLM 推理引擎	官方《MindIE Motor CPP 开发指南 · 简介》 `zh/mindie/310/mindiellm/llmdev/mindie_motor_cpp/user_guide/introduction.md`
MindIE SD 的定位（多模态加速套件，配合 diffusers，以存代算、多卡并行）	官方《MindIE 是什么》表 1
`vllm serve Qwen/Qwen3-0.6B &`、容器启动命令（`--device` / `-v` 驱动映射 / `-p 8000:8000`、镜像 `quay.io/ascend/vllm-ascend:v0.23.0.post1`）、软件要求（CANN 9.1.0 / TorchNPU 2.10.0.post4）、`curl /v1/models`、`curl /v1/completions`、`export VLLM_USE_MODELSCOPE=True`、启动成功日志 `Application startup complete` / `Uvicorn running on http://0.0.0.0:8000`	官方《vLLM Ascend 快速入门》（独立于昇腾文档站的站外文档） `https://docs.vllm.ai/projects/ascend/zh-cn/v0.23.0/quick_start.html`
MindIE Motor 服务部署 `python3 deploy.py --config_dir …`（含 `--user_config_path` + `--env_config_path` 变体）、`user_config.json` 字段、推理验证端口 `31015` 与 `{"detail":"Service is not available"}`、日志收集 `bash show_log.sh` → `examples/deployer/log_collect/log`	官方《MindIE Motor 快速入门》 `zh/mindie/310/quickstart/docs/zh/user_guide/quick_start.md`
单容器 PD 分离部署 `python deploy.py --config_dir …`、各组件端口（coordinator 1025/1026/1027、controller 2026、node_manager 3026）不重叠要求	官方《单容器 PD 分离部署指南》 `zh/mindie/310/mindiemotor/motordev/examples/infer_engines/vllm/single_container/README.md`
MindIE 日志路径 `~/mindie/log`（含 `security` / `debug`）、文件名格式 `mindie-<组件名>-_pid_datetime.log`、`cat 日志文件`、`MINDIE_LOG_PATH` / `MINDIE_LOG_TO_STDOUT`	官方《日志参考 · 查看日志》 `zh/mindie/310/ref/logreference/docs/zh/user_guide/log/log_viewing.md`
`npu-smi info`（查询所有设备基本信息）、`npu-smi info -l`（查询所有 NPU 设备，NPU ID = 设备 ID）、`npu-smi info -t memory -i <id>`	官方《Atlas A2 npu-smi 命令参考 · 信息查询（info）》 `zh/HDK/2610/A2/A2npu/npusmi_0007.html`（基本信息）/ `…npusmi_0014.html`（info -l）
常见报错清单中的官方故障案例：`topic_0000002193313946`（Failed to init endpoint）/ `topic_0000002215064906`（找不到 libboost_thread.so.1.82.0）/ `topic_0000002215083154`（请求超时无返回）/ `topic_0000002249944921`（返回乱码）/ `topic_0000002250112009`（加载模型 out of memory）/ `topic_0000002598936025`（infer shape check fail）	昇腾官方故障案例库 `https://www.hiascend.com/document/caselibrary/detail/<案例编号>`

⚠️ 数据纪律提示： ① 本课只给出组件定义与职责；各组件的手册、配置文件、启动参数留到 D2–D5，本课不替代、不推测； ② PD 分离只钉住"官方术语与作用"，不展开计算原理； ③ 标注「归纳」的解读（分层对照表、Motor/引擎的"门面与后厨"类比）非官方口径。

附录 B · 本课出现的名词详解

MindIE

全称：Mind Inference Engine（官方原文：昇腾推理引擎）
定位：华为昇腾针对 AI 全场景业务的推理加速套件
不是：不是单个软件，是套件（同 HDK / CANN 的命名方式）

MindIE Motor

官方定位：面向大模型推理的分布式调度与服务化框架
目标：高性能调度、资源池化、故障自愈 → 吞吐 / 资源利用率 / 服务可靠性
当前支持的推理引擎：vLLM-Ascend
五个子组件：

子组件	官方职责
Controller	控制器，集群的状态管控器和决策大脑，负责全局业务状态管控及 RAS 能力决策
Coordinator	调度器，用户推理请求的统一入口，接收高并发请求，执行请求调度、管理与转发，是集群的数据流枢纽
Deployer	部署器，基于 Kubernetes 的推理服务部署参考脚本，提供服务启动、停止、弹性伸缩能力
EngineServer	节点推理服务入口，提供统一的 RESTful EndPoints（含 OpenAI 接口、Metrics）；北向对接 Coordinator 和 Controller，南向对接 vLLM-Ascend 框架
NodeManager	节点级服务管理器，提供节点级服务进程启动与节点级健康状态管理

⭐ 这五个名字记住了，D3 就不用重新学 —— 它们就是 Motor 的骨架。 其中和"服务通不通"关系最直接的是 EngineServer（它才是提供端口和接口的那个）。

MindIE SD

官方定位：构建昇腾亲和的多模态加速系列套件
配套：业内模型套件（如 diffusers）
手段：多模态生成的关键算子和融合算子 + 量化/稀疏算法 + 以存代算 + 多卡并行
现状：官方说明中提到"未来会进一步扩展到多模态理解、全模态等场景"

MindIE LLM

官方定位：针对大模型优化的高性能 SDK（模型库 + 推理优化器 + 运行环境）
⚠️ 现状：暂停后续功能演进，维持维护状态，不再支持新特性和新模型
官方推荐替代：MindIE Motor + vLLM Ascend

名词速查表

名词	一句话
MindIE	昇腾推理引擎（套件）：Mind Inference Engine
MindIE Motor	服务化 / 调度 / 集群（当前主线）
MindIE SD	多模态（视图生成）加速
MindIE LLM	大模型推理 SDK（已暂停演进）
vLLM-Ascend	当前主线推理引擎
推理引擎	真正在卡上做推理计算的那层
服务化框架	把引擎包起来对外提供服务的那层（Motor）
PD 分离	Prefill / Decode 拆到不同实例上跑
`EngineServer`	提供 RESTful EndPoints（含 OpenAI 接口、Metrics）的那个子组件

附：C 层与 D 层的分工

问题	在哪一课
框架怎么接到昇腾上（TorchNPU）	C1
有哪些框架、插件路线 vs 原生路线	C2
算子从框架到芯片走了哪条路	C3
为什么需要服务层、MindIE 是什么、官方当前推荐哪条路	本课（D1）
vLLM-Ascend 怎么装怎么起	D2
Motor 的五个子组件怎么配合	D3
PD 分离怎么做	D4
服务起停、端口、调优	D5