# MindIE 2026 前沿大模型部署手册

> 版本基准：MindIE LLM 3.1.0（配套 CANN 9.0.1 / 9.1.0）　·　文档核验：2026-11-06
> 内容取自 mindie-llm-doc.readthedocs.io 官方中文文档（模型支持列表更新至 2026-04-24，特性文档更新至 2026-05-28）。

---

## 目录

- [00 导读](#00-导读)
- [01 2026 的部署格局](#01-2026-的部署格局)
- [02 显存预算与 KV 计算](#02-显存预算与-kv-计算)
- [03 架构与参数作用点](#03-架构与参数作用点)
- [04 核心参数详解](#04-核心参数详解)
- [05 并行策略选型](#05-并行策略选型)
- [06 逐模型实战配置](#06-逐模型实战配置)
- [07 调优方法论](#07-调优方法论)
- [08 生产化与排错](#08-生产化与排错)
- [09 附录](#09-附录)

---

## 00 导读

### 这份文档必须先把话说清楚

MindIE（Mind Inference Engine）是华为昇腾的官方推理套件，由 **MindIE LLM**（大模型推理组件）和 **MindIE Service**（服务化）组成。

**它是昇腾硬件上最"正统"的选择**：CANN、ATB、TorchNPU 全栈自研，算子针对达芬奇架构手工优化，在 Atlas 800I A2 / A3 上有官方性能数据。

**但它有一个必须提前知道的现实**：截至 2026-11 的官方文档，**MindIE 的已验证模型列表尚未覆盖 2026 年的旗舰模型**。

| 模型 | MindIE 官方支持状态 |
| :-- | :-- |
| DeepSeek-V3.2 | ✅ 已验证（32 卡 A2 / 16 卡 A3） |
| Qwen3-235B-A22B | ✅ 已验证（16 卡 A2 / 8 卡 A3） |
| Kimi-K2-Instruct / Thinking | ✅ 已验证（32 卡 A2 / 16 卡 A3） |
| GLM-4.5 | ✅ 已验证（16 卡 A2） |
| DeepSeek-V4 / V4.1 | ❌ 未出现在支持列表 |
| Qwen3.5 / Qwen3.8 | ❌ 未出现在支持列表 |
| Kimi-K3 / K3.1 | ❌ 未出现在支持列表 |
| GLM-5 / 5.3 | ❌ 未出现在支持列表 |
| MiniMax-M3 | ❌ 未出现在支持列表 |

> **这不是说 MindIE 不能跑这些模型**（可以通过模型适配流程自行迁移），而是说**官方没有验证、没有性能数据、没有推荐配置**。生产环境用未验证的组合风险很高。

### 那 2026 年的旗舰模型在昇腾上怎么跑？

官方在 vLLM-Ascend 的 DeepSeek-V4-Pro 教程里给出了明确指引：

> "PD Separation Deployment mentioned in this document is provided only as an example/reference design... For the production environment on the customer side, **MindIE Motor + vLLM-Ascend is recommended**."

也就是说，**昇腾官方推荐的生产路径是「MindIE Motor（服务编排）+ vLLM-Ascend（推理引擎）」**，而不是纯 MindIE LLM。

vLLM-Ascend 文档里已经有完整的模型教程：

| 模型 | vLLM-Ascend 教程 |
| :-- | :-- |
| DeepSeek-V4-Pro | ✅ |
| DeepSeek-V4-Flash | ✅ |
| DeepSeek-V4.1-Flash | ✅ |
| DeepSeek-V3.1 / V3.2 | ✅ |
| GLM-5 / 5.2 / 5.3-Flash | ✅ |
| Qwen3.5-397B-A17B | ✅ |
| Kimi-K3 | ✅ |

**本文的定位**：
1. 完整讲清 MindIE LLM 本身的部署、参数、调优（这是它擅长的、已验证的部分）
2. 对 2026 前沿模型，给出「MindIE 的现状 + 昇腾上的替代路径」的诚实判断

### 数据基准

| 组件 | 基线 |
| :-- | :-- |
| MindIE LLM | 3.1.0 |
| CANN | 9.0.1 / 9.1.0（3.1.0 兼容 9.0.0 及以上） |
| MindCluster | 26.0.0 |
| Ascend Extension for PyTorch | 26.0.0 |
| 硬件 | Atlas 800I A2（64GB）/ A3（128GB）/ 300I Duo / 950DT |

> **版本配套极其严格**：官方明确写「各组件需要配套使用，请勿跨版本混用」。MindIE 3.1.0 支持 CANN 9.1.0 / 9.0.1 / 9.0.0，3.0.0 支持 CANN 9.0.0 / 8.5.1 / 8.5.0。

### 三个必须先建立的心智模型

**① 配置在 `config.json`，不在命令行。**

MindIE 的服务化通过一个 JSON 配置文件驱动：

```
{
  "ServerConfig":  { ... },   // IP / 端口 / HTTPS
  "BackendConfig": { ... },   // 模型 / 调度 / 并行
  "LogConfig":     { ... }
}
```

启动命令只有一个：

```bash
./bin/mindieservice_daemon
```

**所有并行、调度、量化参数都写在 JSON 里**，这与 vLLM/SGLang 的命令行风格完全不同。

**② `npuMemSize` 和 `cpuMemSize` 是显存闸门。**

- `npuMemSize`：单 NPU 可用于 KV Cache 的 GB 数，**-1 表示自动**
- `cpuMemSize`：单 CPU 的 KV Cache 上限（用于 KV 池化/换出）

自动分配的公式（官方）：

```
npuMemSize = 单卡总内存 × 内存分配比例 − 权重占用 − 运行时占用 − 系统占用
```

内存分配比例默认 0.8，可通过环境变量 `NPU_MEMORY_FRACTION` 调整。

**③ 调度器有 `Standard` 和 `Mix` 两种模板。**

- `Standard`：PD 混部，Prefill 和 Decode **各自组 batch**（默认）
- `Mix`：SplitFuse 模式，Prefill 和 Decode **可以一起组 batch**

这个选择决定了整个调度行为，是 MindIE 最核心的架构分叉。

---

## 01 2026 的部署格局

### MindIE 的能力矩阵

从官方文档的「核心能力」章节：

| 能力 | 说明 |
| :-- | :-- |
| **高吞吐服务化** | Continuous Batching + PagedAttention |
| **KV Cache 管理** | 统一内存池，支持 KV 池化、CPU 换出 |
| **量化** | W8A8、W8A16、W4A8 混合精度、FA3 量化、KV Cache INT8 |
| **多维并行** | TP、DP、EP、CP、SP |
| **PD 分离** | Prefill / Decode 独立部署 + KV Cache 池化 |
| **调度优化** | SplitFuse 分块调度、异步调度、并行解码 |
| **模型特性** | MoE、MLA、MTP、Function Call、Multi-LoRA |
| **接口兼容** | OpenAI / Triton / TGI / vLLM |

### 四层架构

```
┌──────────────────────────────────────────────────┐
│  Server                                          │
│  RESTful 接口，兼容 OpenAI / Triton / TGI / vLLM  │
└────────────────────┬─────────────────────────────┘
                     ▼
┌──────────────────────────────────────────────────┐
│  LLM Manager                                     │
│  状态管理 + 任务调度 + 统一 KV Cache 内存池         │
└────────────────────┬─────────────────────────────┘
                     ▼
┌──────────────────────────────────────────────────┐
│  Text Generator                                  │
│  模型配置 / 初始化 / 加载 / 自回归推理 / 后处理     │
└────────────────────┬─────────────────────────────┘
                     ▼
┌──────────────────────────────────────────────────┐
│  Modeling                                        │
│  性能调优后的模块与内置模型（ATB Models）           │
└──────────────────────────────────────────────────┘
```

### 硬件矩阵

| 硬件 | 显存 | 定位 |
| :-- | :-- | :-- |
| Atlas 800I A2 | 64 GB × 8/16 | 主力推理服务器 |
| Atlas 800I A3 | 128 GB × 8/16 | 超节点，大模型首选 |
| Atlas 300I Duo | — | 边缘/低成本 |
| 950PR / 950DT | 96 GB × 8 | 新一代，支持 MXFP8/MXFP4 原生权重 |

### 2026 前沿模型的昇腾路径

| 模型 | MindIE LLM | vLLM-Ascend | 建议 |
| :-- | :-- | :-- | :-- |
| DeepSeek-V3.2 | ✅ | ✅ | 两者皆可 |
| Qwen3-235B-A22B | ✅ | ✅ | 两者皆可 |
| Kimi-K2 | ✅ | ✅ | 两者皆可 |
| GLM-4.5 | ✅ | ✅ | 两者皆可 |
| **DeepSeek-V4-Pro** | ❌ | ✅ | **用 vLLM-Ascend** |
| **Qwen3.5-397B** | ❌ | ✅ | **用 vLLM-Ascend** |
| **GLM-5 / 5.3** | ❌ | ✅ | **用 vLLM-Ascend** |
| **Kimi-K3** | ❌ | ✅ | **用 vLLM-Ascend** |

**vLLM-Ascend 的 DeepSeek-V4-Pro 需要多少硬件？**

官方教程给出的权重与硬件对应：

| 权重版本 | 硬件需求 |
| :-- | :-- |
| `DeepSeek-V4-Pro-w4a8-mtp` | 2× Atlas 800I A3（128GB×8）或 4× Atlas 800I A2（64GB×8） |
| `DeepSeek-V4-Pro-0813-w4a8` | 同上 |
| `DeepSeek-V4-Pro-0813-w4a4c8` | 950PR / 950DT |
| `DeepSeek-V4-Pro-0813`（原始 HF） | 950DT 产品（96GB×8），2 节点 |

---

## 02 显存预算与 KV 计算

### 显存划分

```
┌──────────────────────────────────────────────────────┐
│  Weights  │   Runtime   │      KV Cache Pool          │
└──────────────────────────────────────────────────────┘
                           └──── npuMemSize ────┘
```

`npuMemSize` 是**直接以 GB 为单位指定 KV Cache 上限**，不是比例。这和 vLLM/SGLang/TensorRT-LLM 都不同。

### 自动分配的快速公式

官方给出：

```
npuMemSize = 单卡总内存 × 内存分配比例
           − 单卡权重占用
           − 运行时相关变量占用
           − 系统占用内存
```

其中：
- **单卡总内存**：`npu-smi info` 查看
- **内存分配比例**：默认 0.8，环境变量 `NPU_MEMORY_FRACTION` 控制

官方说明：这个公式的结果「**仅作为取值参考**」，为了达到最佳性能，「可以适当向上调整该值并进行性能压力测试」。

### 何时该手动设置

| 场景 | 建议 |
| :-- | :-- |
| 默认情况 | `npuMemSize: -1`（自动） |
| 权重加载 OOM | 提高内存分配比例，或用更多卡 |
| 需要精确控制 | 手动指定 GB 数 |
| 多模型共存 | 手动分配，避免互相挤占 |
| `backendType: ms` + PD 混部 | **`npuMemSize: -1` 仅支持 `ParallelLlamaForCausalLM`** |

### KV Cache 计算

#### MHA / GQA / MQA（统一公式）

三种架构共用同一个公式，差异只在 `n_kv_heads`：

```
KV_bytes_per_token = 2 × n_layers × n_kv_heads × head_dim × dtype_bytes
```

| 架构 | `n_kv_heads` | 相对 MHA |
| :-- | :-- | :-- |
| MHA | `= n_heads` | 1× |
| GQA | `= n_heads / g` | 1/g |
| MQA | `= 1` | 1/n_heads |

> GQA 不是「另一种算法」，而是把 KV head 数除以分组比 g。Llama-3-70B 是 64 q-heads / 8 kv-heads，KV 只有 MHA 的 1/8。

#### MLA（DeepSeek 系）

```
KV_bytes_per_token = n_layers × (kv_lora_rank + qk_rope_head_dim) × dtype_bytes
```

#### KV Cache INT8 的收益

官方文档明确：

> "此量化方式将 k cache 和 v cache 量化为 8 bit，通过减少 KV Cache 的显存占用，在显存受限场景（如长序列场景）下，可以减少重计算触发次数以提升吞吐。"

**但约束很严**：

| 约束 | 说明 |
| :-- | :-- |
| 硬件 | **仅 Atlas 800I A2** |
| 量化组合 | **仅支持搭配 W8A8** |
| 模型 | **仅 LLaMA3.1-70B、Qwen2-72B、Qwen2.5-72B-Instruct** |
| 数据类型 | **仅 float16** |

> 这是一个典型的「能力存在但覆盖面窄」的特性。如果你不在上述四个模型的交集里，用不了。

### `cacheBlockSize` 与碎片

| 参数 | 默认 | 范围 |
| :-- | :-- | :-- |
| `cacheBlockSize` | 128 | [1, 128]，其他值需为 16 的整数倍 |

官方建议值就是 128。块太小 → 元数据开销大；块太大 → 尾部浪费。

---

## 03 架构与参数作用点

### 服务化进程

```
┌───────────────────────────────────────────────┐
│  mindieservice_daemon                         │
│  ├─ EndPoint（业务面 RESTful）  ipAddress:port │
│  ├─ EndPoint（内部面）  managementIpAddress    │
│  └─ Metrics（普罗格式）  metricsPort           │
└──────────────────┬────────────────────────────┘
                   ▼
┌───────────────────────────────────────────────┐
│  LLM Manager                                  │
│  ├─ Scheduler（Standard / Mix）                │
│  ├─ KV Cache 统一内存池                        │
│  └─ 多实例管理（ModelConfig 数组）              │
└──────────────────┬────────────────────────────┘
                   ▼
┌───────────────────────────────────────────────┐
│  Text Generator × worldSize                   │
│  └─ ATB Models（每个 rank 一份分片）            │
└───────────────────────────────────────────────┘
```

### 三面隔离

MindIE 的 Server 有三个网络面，官方强制要求隔离：

| 面 | 配置项 | 默认 | 用途 |
| :-- | :-- | :-- | :-- |
| 业务面 | `ipAddress` + `port` | 127.0.0.1:1025 | 对外 RESTful |
| 内部面 | `managementIpAddress` + `managementPort` | 127.0.0.2:1026 | 内部管理 |
| 指标面 | `metricsPort` | 1027 | Prometheus |

> **默认禁止绑定 `0.0.0.0`**。官方说明：「全零监管会导致三面隔离失效，不满足安全配置要求」。确需绑定需显式设 `allowAllZeroIpListening: true`，并自行保证安全防护。

### 一次请求的路径

```
① HTTP 接入        业务面 EndPoint
                     ↓  maxLinkNum（最大并发处理数）
② 排队             等待队列（最多 2×maxLinkNum）
                     ↓  maxQueueDelayMicroseconds
③ 组 batch         Scheduler
                     ↓  maxBatchSize / maxPrefillTokens
④ 阶段选择         Standard：PD 分开组批
                    Mix：PD 混合组批
                     ↓  prefillTimeMsPerReq / decodeTimeMsPerReq
⑤ 分块（可选）      SplitFuse 切分
                     ↓  prefillChunkSize
⑥ 前向             ATB Models + 并行通信
                     ↓  tp / dp / sp / cp / moe_ep
⑦ 输出             反分词 → 流式
```

### Standard vs Mix 的行为差异

| | Standard | Mix |
| :-- | :-- | :-- |
| Prefill / Decode | 各自组 batch | 可混合组批 |
| 依赖 plugin | 无 | **必须 `splitfuse`** |
| KV 波动 | 较小 | 更平滑 |
| 适用 | 通用 | 长 prompt + 短 prompt 混合 |

> 官方约束：「若 templateType 为 Mix，则 plugin_params 必须开启 splitfuse」。

---

## 04 核心参数详解

所有参数都在 `config.json` 里。下面按配置层级组织。

### 4.1 ServerConfig（服务端）

| 配置项 | 默认 | 说明 |
| :-- | :-- | :-- |
| `ipAddress` | `127.0.0.1` | 业务面 IP。有 `MIES_CONTAINER_IP` 环境变量时优先取它 |
| `port` | `1025` | 业务面端口，范围 [1024, 65535] |
| `managementIpAddress` | `127.0.0.2` | 内部面 IP |
| `managementPort` | `1026` | 内部面端口 |
| `metricsPort` | `1027` | 指标端口 |
| `allowAllZeroIpListening` | `false` | **建议保持 false** |
| `maxLinkNum` | `1000` | 并发处理数。**推荐 300**。队列容量为 2×，第 3×+1 个请求被拒 |
| `httpsEnabled` | `true` | **建议开启**。关闭有较高网络安全风险 |
| `fullTextEnabled` | `false` | 流式接口是否返回全量历史 |

> **`maxLinkNum` 的取值**：官方说「1000 并发能力受模型性能影响受限支持，一般较小模型、较低序列长度下才可以使用 1000 并发」。默认 1000 偏大，推荐 300。

### 4.2 ModelConfig（模型与并行）

| 配置项 | 默认 | 说明 |
| :-- | :-- | :-- |
| `modelName` | `llama_65b` | 模型名 |
| `modelWeightPath` | — | 权重路径，需与执行用户同属组同权限 |
| `worldSize` | `4` | **必须等于使用的 NPU 数量** |
| `npuMemSize` | `-1` | 单 NPU 的 KV Cache 上限（GB），-1 = 自动 |
| `cpuMemSize` | `5` | 单 CPU 的 KV Cache 上限（GB） |
| `backendType` | `atb` | `atb` / `ms` |
| `trustRemoteCode` | `false` | 信任远程代码 |
| `tp` | `worldSize` | 张量并行数 |
| `dp` | `1` | 数据并行数。`tp × dp` 必须等于 `worldSize` |
| `sp` | `1` | 序列并行数（KV 切分） |
| `cp` | `1` | 上下文并行数 |
| `moe_tp` | 同 `tp` | MoE 的 TP 切分 |
| `moe_ep` | `1` | MoE 的 EP 切分。`moe_ep × moe_tp = worldSize` |
| `plugin_params` | — | JSON 字符串，启用插件特性 |

### 4.3 ScheduleConfig（调度）

| 配置项 | 默认 | 说明 |
| :-- | :-- | :-- |
| `templateType` | `Standard` | `Standard` / `Mix` |
| `templateName` | `Standard_LLM` | 当前只能取这个值 |
| `maxBatchSize` | — | 最大 decode batch |
| `maxPrefillBatchSize` | `50` | 最大 prefill batch。**设为 0 表示取 `maxBatchSize`** |
| `maxPrefillTokens` | `8192` | 单批 prefill 的 token 总数 |
| `maxSeqLen` | `2560` | 最大序列长度 |
| `maxInputTokenLen` | `2048` | 输入 token 最大长度 |
| `maxIterTimes` | `512` | 全局最大输出长度 |
| `cacheBlockSize` | `128` | KV 块大小 |
| `maxQueueDelayMicroseconds` | `5000` | 队列最大等待时间（us），范围 [500, 1000000] |
| `maxFirstTokenWaitTime` | `2500` | 首 token 最长排队时间（ms） |
| `prefillTimeMsPerReq` | `150` | 单请求 prefill 耗时估计 |
| `decodeTimeMsPerReq` | — | 单请求 decode 耗时估计 |
| `supportSelectBatch` | — | 是否启用 PD 选择算法 |
| `maxPreemptCount` | `0` | 每批最大抢占数。>0 时 `cpuMemSize` 不能为 0 |

#### PD 选择算法（`supportSelectBatch: true`）

官方文档给出了完整的判断逻辑：

```
prefillWaitTime = prefillTimeMsPerReq × decodeReqNum
    ↑ 如果选 Prefill，Decode 请求要等多久

accumulatedDecodeWasteTime = decodeTimeMsPerReq × (maxBatchSize − decodeReqNum)
    ↑ 如果连续多次 Decode，浪费多少时间

if prefillWaitTime > accumulatedDecodeWasteTime:
    → Decode 请求积压过多 → 下一次执行 Decode
else:
    → 连续 Decode 浪费过多 → 下一次执行 Prefill
```

这是一个很实用的启发式：**用两个方向的「等待成本」做比较**。

> PD 分离场景下这个参数无效——Prefill 实例优先 Prefill，Decode 实例优先 Decode。

#### SplitFuse 参数（`templateType: Mix`）

| 配置项 | 默认 | 说明 |
| :-- | :-- | :-- |
| `prefillChunkSize` | — | 固定切块长度。不配置则按 `maxPrefillTokens` 和请求数动态计算 |
| `maxNumPartialPrefills` | `64` | 可并行做 partial prefill 的最大请求数 |
| `longPrefillTokenThreshold` | `1024` | 判定为长 prefill 的 token 阈值 |
| `maxLongPartialPrefills` | `8` | batch 中允许的长 prefill 请求个数 |

SplitFuse 的核心行为（官方描述）：

1. 长 prompt 被分解成更小的块，在多个迭代中调度，**只有最后一遍迭代执行输出生成**
2. 短 prompt 也可能切分成小块，以保证计算效率最佳
3. 每个 step 的计算量基本相等 → **平均延迟更稳定**

### 4.4 插件（plugin_params）

| 插件 | 值 | 作用 |
| :-- | :-- | :-- |
| MTP | `{"plugin_type":"mtp","num_speculative_tokens":1}` | 多 token 预测 |
| SplitFuse | `{"plugin_type":"splitfuse"}` | 分块调度 |

> **不需要生效任何插件功能时，请删除该字段**。留空字符串会报错。

### 4.5 MTP

```json
"plugin_params": "{\"plugin_type\":\"mtp\",\"num_speculative_tokens\": 1}"
```

**`num_speculative_tokens` 的建议**（官方）：

- 低时延场景：1 或 2
- 高吞吐场景：**不超过 1**

**支持叠加的特性**：
- prefix cache 和 KV cache 池化
- 异步调度
- kv_cache_int8 量化
- function call
- 思考解析
- PD 分离（P、D 节点需同时配置）

**部分场景可叠加**：context_parallel、sequence_parallel

**限制**：
- 仅 DeepSeek-R1 / V3 的 W8A8 量化模型、KV Cache int8 量化模型
- 支持 W4A8 量化
- **不能与并行解码、Multi-LoRA、SplitFuse 同时使用**
- PD 混部叠加 CP/SP 时，`num_speculative_tokens` 只能为 1
- 大 EP 场景叠加 CP/SP 时，**仅 P 节点支持开启 CP/SP**
- 不支持 `n`、`best_of`、`use_beam_search`、`logprobs` 等多序列后处理
- MTP 惩罚类后处理**仅支持重复惩罚**

### 4.6 PDMIX 量化

这是昇腾比较有特色的一个优化：**Prefill 和 Decode 阶段用不同的量化方式**。

| 阶段 | 量化方式 | 特点 | 适用 |
| :-- | :-- | :-- | :-- |
| Prefill | W8A8 Dynamic (Per-token) | 每个 token 独立 input scale，动态适应激活范围 | **精度优先** |
| Decode | W8A8 Static (Per-tensor) | 整个 tensor 统一 scale，计算开销最小 | **性能优先** |

**原理**：Prefill 阶段激活值分布变化大（长序列、不同 prompt），动态量化能显著减少精度损失；Decode 阶段逐 token 生成，计算访存比低，静态量化能最大化吞吐。

**生成方式**：

```bash
# 使用 msModelSlim 工具
msmodelslim quant \
  --model_path {浮点权重路径} \
  --save_path {W8A8PDMIX量化权重路径} \
  --device npu \
  --model_type Qwen3-14B \
  --quant_type w8a8 \
  --trust_remote_code True
```

**权重描述文件**会多出 `weight_scale` 和 `weight_offset` 字段（用于反量化 matmul 结果），`quant_model_description.json` 里标记为 `W8A8_MIX`。

---

## 05 并行策略选型

<!-- engine-topologies:start -->
### 本引擎的推理拓扑与 KV 存放

> 按当前引用的 3.1 文档：tp×dp=worldSize；moe_tp×moe_ep=worldSize；ep_level=2 要求 moe_tp=1。SP/CP 的硬件、模型、量化及叠加约束需查特性矩阵。

#### MindIE · TP2 × DP2

配置要点：`worldSize:4; tp:2; dp:2`（机制示例，须满足模型与硬件约束）。

![MindIE · TP2 × DP2](assets/topologies/mindie/topology-1.svg)

示例 GQA 有 4 个 KV head；tp×dp 必须等于 worldSize。

#### MindIE · D · attention-DP4 + routed EP4

配置要点：`worldSize:4; tp:1; dp:4; moe_tp:1; moe_ep:4; ep_level:2`（机制示例，须满足模型与硬件约束）。

![MindIE · D · attention-DP4 + routed EP4](assets/topologies/mindie/topology-2.svg)

KV 已明确按 GQA 示例标注：TP4 每卡 2 个 KV head；attention-DP4 每卡保存自己请求的 KV。共享专家布局是图示前提，不是该引擎所有后端的默认承诺。

#### MindIE · SP 的 KV 切分

配置要点：`worldSize:4; tp:2; dp:2; sp:2`（机制示例，须满足模型与硬件约束）。

![MindIE · SP 的 KV 切分](assets/topologies/mindie/topology-3.svg)

仅在特性矩阵支持的 DeepSeek W8A8 等条件下；sp=tp，DP 与 CP 不可同时叠加。

官方依据：[MindIE](https://mindie-llm-doc.readthedocs.io/zh-cn/latest/user_guide/optimization_and_tuning/)。
<!-- engine-topologies:end -->


### 五种并行

| 并行 | 配置项 | 约束 |
| :-- | :-- | :-- |
| **TP** | `tp` | 默认等于 `worldSize` |
| **DP** | `dp` | `tp × dp = worldSize`；**暂不支持与 CP 叠加** |
| **SP** | `sp` | **必须与 tp 相同**；与 DP 或 CP 叠加时 `dp×sp` 或 `cp×sp` = `worldSize` |
| **CP** | `cp` | **目前只支持 2**；`cp × tp = worldSize`；**必须与 SP 同时使用**；不支持与 DP 叠加 |
| **EP** | `moe_ep` + `moe_tp` | `moe_ep × moe_tp = worldSize` |

### 组合约束图

```
                    ┌─────────────┐
                    │  worldSize  │
                    └──────┬──────┘
                           │
          ┌────────────────┼────────────────┐
          ▼                ▼                ▼
      tp × dp          tp × cp          sp × dp
          │                │                │
      合法组合         合法组合         合法组合
          │                │                │
          │          必须 sp=tp        必须 sp=tp
          │                │                │
      ┌───┴───┐       ┌────┴────┐       ┌───┴───┐
      │ TP+DP │       │ TP+CP+SP│       │ DP+SP │
      └───────┘       └─────────┘       └───────┘

  ✗ DP 与 CP 不能叠加
  ✗ SP 必须等于 TP
  ✗ CP 目前只能是 2
```

### 各并行的硬件/模型约束

| 并行 | 支持的模型 | 支持的量化 |
| :-- | :-- | :-- |
| SP（序列并行） | DeepSeek-V3 / R1 / V3.1 | **仅 W8A8** |
| CP（上下文并行） | DeepSeek-V3 / R1 / V3.1 | **仅 W8A8** |
| EP level 1 | MoE 模型 | AllGather 通信 |
| EP level 2 | MoE 模型 | AllToAll + 通算融合；**`moe_tp` 只能为 1** |
| MTP | DeepSeek-R1 / V3 | W8A8 / KV int8 / W4A8 |

> **SP/CP 只支持 DeepSeek 系且只支持 W8A8**，这是 MindIE 在长上下文场景的主要限制。

### DeepSeek-V3 的典型配置

**16 卡，大 EP**：

```json
{
  "worldSize": 16,
  "moe_tp": 1,
  "moe_ep": 16,
  "models": {
    "deepseekv2": {
      "ep_level": 2
    }
  }
}
```

**16 卡，PD 分离（D 节点非分布式）**：

```json
{
  "worldSize": 16,
  "tp": 1,
  "models": {
    "deepseekv2": {
      "lm_head_local_tp": 16,
      "o_proj_local_tp": 2
    }
  }
}
```

> `lm_head_local_tp` 和 `o_proj_local_tp` **仅当 `tp=1` 时能开启**，否则默认与 `tp` 保持一致。这是官方针对 PD 分离 + D 节点非分布式场景的优化，用于减少矩阵计算时间、降低推理时延。

### EP 的两种实现

| level | 通信方式 | 约束 |
| :-- | :-- | :-- |
| `ep_level = 1` | AllGather | 通用 |
| `ep_level = 2` | AllToAll + 通算融合 | `moe_tp` 必须为 1 |

官方推荐：**能用 level 2 就用 level 2**，通算融合能重叠计算和通信。

### PD 分离

MindIE 支持 PD 分离部署：

- Prefill 阶段计算密集 → 少节点、大算力
- Decode 阶段访存密集 → 多节点、大 batch
- 通过调节 PD 节点配比提升整体吞吐
- **Decode 平均低时延约束场景下，PD 分离优势更明显**

> PD 分离场景下：
> - `templateType` 配置不生效
> - `prefillTimeMsPerReq` / `decodeTimeMsPerReq` 无效
> - `worldSize` 需要与下发身份设置的卡数一致
> - 多机场景 `worldSize` 由 ranktable 计算

---

## 06 逐模型实战配置

### 6.1 完整部署流程（以 Qwen2-7B 为例）

这是官方快速入门的标准流程，所有模型都遵循同样的步骤。

#### 步骤 1：环境准备

```bash
# 检查 NPU 驱动
npu-smi info

# 检查 Docker
docker ps
```

#### 步骤 2：获取权重

```bash
# 权重放到任意目录，如 /home/weight/qwen2-7b
chmod -R 755 /home/weight/qwen2-7b
```

#### 步骤 3：启动容器

```bash
docker run -it -d --net=host --shm-size=500g \
  --name mindie-container \
  -w /home \
  --device=/dev/davinci0:rwm \
  --device=/dev/davinci1:rwm \
  --device=/dev/davinci2:rwm \
  --device=/dev/davinci3:rwm \
  --device=/dev/davinci_manager:rwm \
  --device=/dev/hisi_hdc:rwm \
  --device=/dev/devmm_svm:rwm \
  -v /usr/local/Ascend/driver:/usr/local/Ascend/driver:ro \
  -v /usr/local/dcmi:/usr/local/dcmi:ro \
  -v /usr/local/bin/npu-smi:/usr/local/bin/npu-smi:ro \
  -v /usr/local/sbin/:/usr/local/sbin:ro \
  -v /home/weight:/home/weight:ro \
  {IMAGE_ID} bash
```

> **`--device` 必须用 `rwm` 而不是 `rw` 或 `r`**。官方解释了原因：在 Atlas 800I A2 上，若用 `rw`，当挂载的 NPU 上有其它任务占用时，`npu-smi` 会报错，且 MindIE 任务无法运行（`torch.npu.set_device()` 失败）。A3 超节点上 `rw` 直接不可用。

> **`--shm-size` 随 DP 增大**（官方表格）：
> | DP | 最小 shm-size |
> | :-- | :-- |
> | 2 | 2g |
> | 4 | 3g |
> | 8 | 5g |
> | 16 | 9g |

#### 步骤 4：设置环境变量

```bash
source /usr/local/Ascend/ascend-toolkit/set_env.sh
source /usr/local/Ascend/nnal/atb/set_env.sh
source /usr/local/Ascend/atb-models/set_env.sh
source /usr/local/Ascend/mindie/latest/mindie-llm/set_env.sh
source /usr/local/Ascend/mindie/latest/mindie-service/set_env.sh

export MINDIE_LOG_TO_STDOUT="true"
```

#### 步骤 5：配置 config.json

```bash
cd /usr/local/Ascend/mindie/latest/mindie-service/conf
vim config.json
```

最小可用配置：

```json
{
  "ServerConfig": {
    "httpsEnabled": false
  },
  "BackendConfig": {
    "npuDeviceIds": [[0, 1, 2, 3]],
    "ModelDeployConfig": {
      "ModelConfig": [
        {
          "modelName": "qwen2-7b",
          "modelWeightPath": "/home/weight/qwen2-7b",
          "worldSize": 4,
          "trustRemoteCode": false
        }
      ]
    }
  }
}
```

```bash
chmod 640 config.json
```

#### 步骤 6：启动服务

```bash
cd /usr/local/Ascend/mindie/latest/mindie-service

# 方式一（推荐）：后台启动
nohup ./bin/mindieservice_daemon > output.log 2>&1 &

# 方式二：前台启动
./bin/mindieservice_daemon

# 成功标志
# Daemon start success!
```

> **`bin` 目录权限是 550（无写权限）**，但推理时算子会在当前目录生成 `kernel_meta` 文件夹。所以**不能在 `bin` 目录直接启动**，要在有写权限的目录执行。

> **切换用户后要执行 `rm -f /dev/shm/*`**，删除前一个用户创建的共享文件，否则可能因权限问题推理失败。

### 6.2 DeepSeek-V3 / R1（大 EP + MTP）

**硬件**：Atlas 800I A2 16 卡 / A3 8 卡（W8A8）

```json
{
  "ServerConfig": {
    "ipAddress": "127.0.0.1",
    "port": 1025,
    "httpsEnabled": false,
    "maxLinkNum": 300
  },
  "BackendConfig": {
    "npuDeviceIds": [[0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15]],
    "ModelDeployConfig": {
      "maxSeqLen": 65536,
      "maxInputTokenLen": 65536,
      "truncation": 0,
      "ModelConfig": [
        {
          "modelName": "DeepSeek-R1_w8a8",
          "modelWeightPath": "/data/weights/DeepSeek-R1_w8a8",
          "worldSize": 16,
          "cpuMemSize": 5,
          "npuMemSize": -1,
          "backendType": "atb",
          "trustRemoteCode": false,
          "moe_tp": 1,
          "moe_ep": 16,
          "models": {
            "deepseekv2": {
              "ep_level": 2
            }
          },
          "plugin_params": "{\"plugin_type\":\"mtp\",\"num_speculative_tokens\": 1}"
        }
      ]
    }
  },
  "ScheduleConfig": {
    "templateType": "Standard",
    "templateName": "Standard_LLM",
    "cacheBlockSize": 128,
    "maxBatchSize": 128,
    "maxPrefillBatchSize": 64,
    "maxPrefillTokens": 32768,
    "maxIterTimes": 4096,
    "maxQueueDelayMicroseconds": 5000
  }
}
```

**关键点**：

| 配置 | 理由 |
| :-- | :-- |
| `moe_tp: 1, moe_ep: 16` | 大 EP，专家分散到 16 卡 |
| `ep_level: 2` | AllToAll + 通算融合，比 AllGather 快 |
| `plugin_params: mtp` | MTP 投机解码；高吞吐场景建议 `num_speculative_tokens: 1` |
| `npuMemSize: -1` | 自动分配 KV |
| `maxSeqLen: 65536` | DeepSeek-R1 官方支持 128K，按需调整 |

### 6.3 Qwen3-235B-A22B

**硬件**：Atlas 800I A2 16 卡 / A3 8 卡（W8A8）

```json
{
  "BackendConfig": {
    "npuDeviceIds": [[0,1,2,3,4,5,6,7]],
    "ModelDeployConfig": {
      "maxSeqLen": 131072,
      "maxInputTokenLen": 131072,
      "ModelConfig": [
        {
          "modelName": "Qwen3-235B-A22B",
          "modelWeightPath": "/data/weights/Qwen3-235B-A22B",
          "worldSize": 8,
          "cpuMemSize": 5,
          "npuMemSize": -1,
          "moe_tp": 1,
          "moe_ep": 8,
          "models": {
            "qwen3_moe": {
              "ep_level": 2
            }
          }
        }
      ]
    }
  },
  "ScheduleConfig": {
    "templateType": "Standard",
    "maxBatchSize": 256,
    "maxPrefillBatchSize": 128,
    "maxPrefillTokens": 65536,
    "maxIterTimes": 8192
  }
}
```

### 6.4 SplitFuse 配置（长 + 短 prompt 混合）

```json
{
  "ModelDeployConfig": {
    "maxSeqLen": 65536,
    "maxInputTokenLen": 65536,
    "truncation": 0,
    "ModelConfig": [
      {
        "modelInstanceType": "Standard",
        "modelName": "llama3-70b",
        "modelWeightPath": "/home/models/llama3-70b/",
        "worldSize": 8,
        "cpuMemSize": 5,
        "npuMemSize": -1,
        "backendType": "atb",
        "plugin_params": "{\"plugin_type\":\"splitfuse\"}"
      }
    ]
  },
  "ScheduleConfig": {
    "templateType": "Mix",
    "templateName": "Standard_LLM",
    "cacheBlockSize": 128,
    "maxPrefillBatchSize": 40,
    "maxPrefillTokens": 65536,
    "prefillTimeMsPerReq": 600,
    "prefillPolicyType": 0,
    "decodeTimeMsPerReq": 50,
    "decodePolicyType": 0,
    "maxBatchSize": 256,
    "maxIterTimes": 512,
    "maxPreemptCount": 0,
    "supportSelectBatch": false,
    "maxQueueDelayMicroseconds": 5000,
    "prefillChunkSize": 1024,
    "maxNumPartialPrefills": 64,
    "longPrefillTokenThreshold": 1024,
    "maxLongPartialPrefills": 8
  }
}
```

**SplitFuse 的约束**：

- 仅 Atlas 800I A2 / A3
- 仅 LLaMA3.1-70B 浮点、Qwen2、Qwen2.5、Qwen3 系列
- 仅 W8A8 量化
- **不能与 Multi-LoRA、Function Call、并行解码、MTP、长序列同时使用**
- 支持 `n`、`best_of`、`use_beam_search`

### 6.5 2026 旗舰模型：改用 vLLM-Ascend

**这是本章最重要的内容**。如果你要在昇腾上跑 DeepSeek-V4 / Qwen3.5 / GLM-5 / Kimi-K3，应该用 vLLM-Ascend。

#### 环境

```bash
export IMAGE=quay.io/ascend/vllm-ascend:v0.30.0-a5   # 950DT
# 或 v0.30.0-a3  # A3 系列
# 或 v0.30.0     # A2 系列

docker run --rm \
  --name vllm-ascend \
  --net=host \
  --shm-size=512g \
  --device /dev/davinci0 \
  --device /dev/davinci1 \
  --device /dev/davinci2 \
  --device /dev/davinci3 \
  --device /dev/davinci4 \
  --device /dev/davinci5 \
  --device /dev/davinci6 \
  --device /dev/davinci7 \
  --device /dev/davinci_manager \
  --device /dev/hisi_hdc \
  --device /dev/ummu \
  --device /dev/uburma \
  -v /usr/local/Ascend/driver:/usr/local/Ascend/driver \
  -v /etc/ascend_install.info:/etc/ascend_install.info \
  -v /etc/hccl_rootinfo.json:/etc/hccl_rootinfo.json \
  -v /root/.cache:/root/.cache \
  -v /usr/local/sbin:/usr/local/sbin \
  -v /usr/local/dcmi:/usr/local/dcmi \
  -v /usr/local/bin/npu-smi:/usr/local/bin/npu-smi \
  -itd $IMAGE bash
```

#### DeepSeek-V4-Pro（950DT，2 节点 DP2/PCP8）

官方教程的完整配置：

```bash
# 公共环境变量（每个节点都要设）
export HCCL_IF_IP=$local_ip
export GLOO_SOCKET_IFNAME=$nic_name
export TP_SOCKET_IFNAME=$nic_name
export HCCL_SOCKET_IFNAME=$nic_name
export HCCL_BUFFSIZE=1024
export OMP_PROC_BIND=false
export OMP_NUM_THREADS=10
export PYTORCH_NPU_ALLOC_CONF=expandable_segments:True
export HCCL_OP_EXPANSION_MODE=CCU_SCHED
export TASK_QUEUE_ENABLE=1
export VLLM_EXECUTE_MODEL_TIMEOUT_SECONDS=3000
export HCCL_EXEC_TIMEOUT=2040
export HCCL_CONNECT_TIMEOUT=1200
export VLLM_USE_V2_MODEL_RUNNER=1
export VLLM_USE_FASTOKENS=1

# Node 0
vllm serve /root/.cache/DeepSeek-V4-Pro-0813 \
  --host 0.0.0.0 \
  --served-model-name dsv4 \
  --port 8000 \
  --data-parallel-size 2 \
  --data-parallel-size-local 1 \
  --data-parallel-address $node0_ip \
  --data-parallel-rpc-port 6987 \
  --tensor-parallel-size 1 \
  --prefill-context-parallel-size 8 \
  --enable-expert-parallel \
  --seed 1024 \
  --max-model-len 1048576 \
  --max-num-batched-tokens 2048 \
  --max-num-seqs 16 \
  --async-scheduling \
  --no-disable-hybrid-kv-cache-manager \
  --model-loader-extra-config '{"enable_multithread_load":true,"num_threads":128}' \
  --speculative-config '{"num_speculative_tokens":5,"method":"dspark"}' \
  --trust-remote-code \
  --block-size 32 \
  --kv-cache-dtype fp8 \
  --attention_config.indexer_kv_dtype fp8 \
  --tokenizer-mode deepseek_v4 \
  --tool-call-parser deepseek_v4 \
  --enable-auto-tool-choice \
  --reasoning-parser deepseek_v4 \
  --gpu-memory-utilization 0.95 \
  --compilation-config '{"cudagraph_mode":"FULL_DECODE_ONLY"}' \
  --additional-config '{
    "ascend_compilation_config":{
      "enable_npugraph_ex":true,
      "enable_static_kernel":false
    },
    "enable_cpu_binding":true,
    "enable_fused_mc2":0,
    "enable_shared_expert_dp":true,
    "multistream_overlap_shared_expert":true
  }'

# Node 1：同样的环境变量，只改这三处
#   --data-parallel-start-rank 1
#   --data-parallel-size-local 1
#   --headless
```

**架构要点**：每个节点承载 1 个 DP rank，8 个 NPU 做 prefill context parallel（PCP8），所以是 DP2/TP1 + PCP8。

**关键参数解释**：

| 参数 | 作用 |
| :-- | :-- |
| `--prefill-context-parallel-size 8` | 单节点内 8 NPU 做 prefill 上下文并行 |
| `--enable-expert-parallel` | 专家并行；EP 规模 = TP × DP |
| `--no-disable-hybrid-kv-cache-manager` | V4 是混合注意力，需要混合 KV 管理器 |
| `--block-size 32` | 昇腾上的推荐值（比 GPU 的 256 小） |
| `--kv-cache-dtype fp8` | KV 量化 |
| `--attention_config.indexer_kv_dtype fp8` | **索引器 KV 单独设精度**（稀疏注意力特有） |
| `--additional-config` | 昇腾专属：NPU graph、CPU 绑定、共享专家 DP、多流重叠 |

#### 官方给的一个重要提醒

vLLM-Ascend 的 PD 分离教程开头就写了：

> "The 'PD Separation Deployment' mentioned in this document is provided only as an example/reference design to demonstrate the basic process of deploying Prefill and Decode in separated mode. **It is not recommended for use in the production environment.** For the production environment on the customer side, **MindIE Motor + vLLM-Ascend is recommended**."

**翻译**：教程里的手写 PD 分离脚本只用于演示。生产环境应该用 **MindIE Motor（服务编排层）+ vLLM-Ascend（推理引擎）**。

这是理解昇腾 2026 技术路线的关键：**MindIE 的定位正在从「推理引擎」转向「服务编排 + 部分模型的内置引擎」**。

---

## 07 调优方法论

### 7.1 CPU 侧优化（官方推荐，先做）

这三条是免费的收益，部署前就该做。

```bash
# 1) CPU 高性能模式
cpupower -c all frequency-set -g performance

# 2) 透明大页
echo always > /sys/kernel/mm/transparent_hugepage/enabled

# 3) jemalloc
# 编译安装 jemalloc 后
export LD_PRELOAD=${path_to_lib}/libjemalloc.so:$LD_PRELOAD
```

### 7.2 异步调度

**原理**（官方原文）：

> MindIE 推理的过程是同步执行，一次推理分为三个阶段：
> 1. 数据准备阶段（CPU 上执行）
> 2. 模型推理阶段（NPU 上执行）
> 3. 数据返回阶段（CPU 上执行）
>
> 异步调度的原理是**使用模型推理阶段的耗时掩盖数据准备和数据返回阶段的耗时**，即使用 NPU 上执行的时间掩盖 CPU 上执行的时间，以及 Sampling 之外的 CPU 耗时。

**代价**：已经 EOS（终止推理）的请求会被**重复计算一次**，造成 NPU 计算资源和显存资源的部分浪费。

**适用**：`maxBatchSize` 较大，且输入输出长度比较长的场景。

```bash
export MINDIE_ASYNC_SCHEDULING_ENABLE=1
```

### 7.3 调优顺序

**第一步：确定 PD 模式**

- 通用场景：`templateType: Standard`，PD 混部
- 长 + 短 prompt 混合：`templateType: Mix` + SplitFuse
- 低时延约束：PD 分离

**第二步：调 `npuMemSize`**

- 默认 `-1` 自动
- 观察是否频繁重计算（抢占）
- 官方建议：向上调整 + 压力测试

**第三步：调 batch 参数**

- `maxBatchSize`：decode 并发
- `maxPrefillBatchSize` / `maxPrefillTokens`：**谁先达到就完成组批**
- `maxQueueDelayMicroseconds`：默认 5000us，调大可提升 batch 填充率但增加延迟

**第四步：开特性**

- `MINDIE_ASYNC_SCHEDULING_ENABLE=1`
- MTP（DeepSeek 系）
- KV Cache INT8（限定模型）
- SplitFuse（限定模型）

**第五步：并行**

- 大 EP（`moe_ep` 拉满）
- `ep_level: 2`（AllToAll + 通算融合）
- DeepSeek 系可加 SP / CP

### 7.4 按场景的配方

| 场景 | 配置 | 理由 |
| :-- | :-- | :-- |
| **低延迟对话** | `maxBatchSize: 8`<br>MTP `num_speculative_tokens: 2`<br>`maxQueueDelayMicroseconds: 500` | 小 batch 降 ITL；MTP 提升单流速度 |
| **高吞吐批处理** | `maxBatchSize: 512`<br>`maxPrefillTokens: 65536`<br>MTP `num_speculative_tokens: 1` | 大 batch；MTP 在高吞吐下只宜用 1 |
| **长 + 短混合** | `templateType: Mix`<br>SplitFuse<br>`prefillChunkSize: 1024` | 统一每 step 计算量，稳定延迟 |
| **长上下文** | 大 `maxSeqLen`<br>DeepSeek 系用 SP/CP | SP 切 KV；CP 切序列 |
| **多轮对话** | prefix cache + KV 池化 | 复用前缀 |

### 7.5 压测

官方推荐用 **AISBench** 工具：

```bash
# 参考《快速入门》中的"性能测试"章节
```

调优依据：**首 Token 时延和 Decode 时延**。

---

## 08 生产化与排错

### 8.1 安全配置（官方强制项很多）

MindIE 的安全要求比其他框架严格得多。

| 项 | 要求 |
| :-- | :-- |
| `httpsEnabled` | **建议 true**。false 时有较高网络安全风险 |
| `allowAllZeroIpListening` | **保持 false**。全零监听会导致三面隔离失效 |
| 证书私钥长度 | **≥ 3072** |
| `config.json` 权限 | **640** |
| `bin` 目录权限 | 550（只读） |
| 文件大小 | config.json 必须在 (0MB, 10MB] |
| 目录属组 | `modelWeightPath` 需与执行用户同属组同权限 |

官方还提供了一整套加固文档：
- 防火墙配置
- 防 DoS 攻击
- 目录权限安全加固
- 禁用设备 SSH 服务
- 启用 Docker 审计
- 禁止 setUID/setGID 脚本
- 扫描端口
- 镜像漏洞检查
- Kubernetes 安全加固

生产部署前建议逐条核对。

### 8.2 监控

指标端口 `metricsPort`（默认 1027），Prometheus 格式。

```bash
curl http://<ip>:1027/metrics
```

### 8.3 故障排查

| 现象 | 原因 | 处理 |
| :-- | :-- | :-- |
| 进容器后 `npu-smi` 报错 | `--device` 用了 `rw` | 改 `rwm` |
| `torch.npu.set_device()` 失败 | 同上，或 NPU 被占用 | 检查设备占用；改 `rwm` |
| 切换用户后推理失败 | `/dev/shm` 里有前用户的文件 | `rm -f /dev/shm/*` |
| 启动时提示无写权限 | 在 `bin` 目录启动 | 换到有写权限的目录 |
| 权重加载 OOM | 显存不足 | 提高 `NPU_MEMORY_FRACTION`；加卡；换低精度 |
| 运行中频繁重计算 | `npuMemSize` 太小 | 调大；或加卡 |
| `config.json` 读取失败 | 文件大小不在 (0MB, 10MB] | 检查文件 |
| PD 混部 + `backendType: ms` 启动失败 | `npuMemSize: -1` 仅支持 `ParallelLlamaForCausalLM` | 手动指定 `npuMemSize` |
| 多机推理 `worldSize` 无效 | 多机由 ranktable 决定 | 检查 ranktable |
| 特性冲突 | 如 MTP + SplitFuse | 查 04 章的叠加约束表 |

### 8.4 特性叠加冲突速查

这是最容易踩的坑，单独列一张表。

| 特性 A | 特性 B | 能否叠加 |
| :-- | :-- | :-- |
| MTP | SplitFuse | ❌ |
| MTP | 并行解码 | ❌ |
| MTP | Multi-LoRA | ❌ |
| MTP | prefix cache | ✅ |
| MTP | 异步调度 | ✅ |
| MTP | kv_cache_int8 | ✅ |
| MTP | Function Call | ✅ |
| MTP | PD 分离 | ✅（P、D 都需配） |
| MTP | CP / SP | ⚠️ 部分场景 |
| SplitFuse | Multi-LoRA | ❌ |
| SplitFuse | Function Call | ❌ |
| SplitFuse | 长序列 | ❌ |
| DP | CP | ❌ |
| CP | SP | ✅（必须同时用） |
| SP | DP / CP | ✅（二选一叠加） |

---

## 09 附录

### A. config.json 完整骨架

```json
{
  "Version": "1.0.0",
  "ServerConfig": {
    "ipAddress": "127.0.0.1",
    "managementIpAddress": "127.0.0.2",
    "port": 1025,
    "managementPort": 1026,
    "metricsPort": 1027,
    "allowAllZeroIpListening": false,
    "maxLinkNum": 300,
    "httpsEnabled": true,
    "fullTextEnabled": false,
    "tlsCaPath": "security/ca/",
    "tlsCaFile": ["ca.pem"],
    "tlsCert": "security/certs/server.pem",
    "tlsPk": "security/keys/server.key.pem",
    "tlsPkPwd": "security/pass/key_pwd.txt",
    "tlsCrlPath": "security/certs/",
    "tlsCrlFiles": ["server_crl.pem"]
  },
  "BackendConfig": {
    "npuDeviceIds": [[0, 1, 2, 3]],
    "ModelDeployConfig": {
      "maxSeqLen": 65536,
      "maxInputTokenLen": 65536,
      "truncation": 0,
      "ModelConfig": [
        {
          "modelInstanceType": "Standard",
          "modelName": "model-name",
          "modelWeightPath": "/path/to/weights",
          "worldSize": 4,
          "cpuMemSize": 5,
          "npuMemSize": -1,
          "backendType": "atb",
          "trustRemoteCode": false,
          "tp": 4,
          "dp": 1,
          "sp": 4,
          "cp": 1,
          "moe_tp": 1,
          "moe_ep": 4,
          "plugin_params": "{\"plugin_type\":\"mtp\",\"num_speculative_tokens\":1}"
        }
      ]
    },
    "ScheduleConfig": {
      "templateType": "Standard",
      "templateName": "Standard_LLM",
      "cacheBlockSize": 128,
      "maxBatchSize": 128,
      "maxPrefillBatchSize": 64,
      "maxPrefillTokens": 32768,
      "maxIterTimes": 4096,
      "maxPreemptCount": 0,
      "supportSelectBatch": false,
      "maxQueueDelayMicroseconds": 5000,
      "maxFirstTokenWaitTime": 2500,
      "prefillTimeMsPerReq": 150,
      "decodeTimeMsPerReq": 30
    }
  },
  "LogConfig": {},
  "EnableDynamicAdjustTimeoutConfig": false
}
```

### B. 参数速查

| 参数 | 层级 | 一句话 |
| :-- | :-- | :-- |
| `npuMemSize` | ModelConfig | 单 NPU 的 KV 上限（GB），-1 自动 |
| `cpuMemSize` | ModelConfig | 单 CPU 的 KV 上限（GB） |
| `worldSize` | ModelConfig | 必须等于 NPU 数 |
| `tp` / `dp` / `sp` / `cp` | ModelConfig | 并行度 |
| `moe_tp` / `moe_ep` | ModelConfig | MoE 的 TP/EP |
| `ep_level` | models | 1 = AllGather；2 = AllToAll + 通算融合 |
| `plugin_params` | ModelConfig | MTP / SplitFuse 开关 |
| `templateType` | ScheduleConfig | `Standard` / `Mix` |
| `maxBatchSize` | ScheduleConfig | 最大 decode batch |
| `maxPrefillBatchSize` | ScheduleConfig | 最大 prefill batch（0 = 取 maxBatchSize） |
| `maxPrefillTokens` | ScheduleConfig | 单批 prefill token 上限 |
| `maxSeqLen` | ModelDeployConfig | 最大序列长度 |
| `maxInputTokenLen` | ModelDeployConfig | 输入 token 上限 |
| `maxIterTimes` | ScheduleConfig | 全局最大输出长度 |
| `cacheBlockSize` | ScheduleConfig | KV 块大小（默认 128） |
| `maxQueueDelayMicroseconds` | ScheduleConfig | 队列最大等待 |
| `prefillTimeMsPerReq` / `decodeTimeMsPerReq` | ScheduleConfig | PD 选择算法的耗时估计 |
| `maxLinkNum` | ServerConfig | HTTP 并发处理数（推荐 300） |

### C. 环境变量

| 变量 | 作用 |
| :-- | :-- |
| `NPU_MEMORY_FRACTION` | 内存分配比例，默认 0.8 |
| `MINDIE_ASYNC_SCHEDULING_ENABLE` | 开启异步调度 |
| `MINDIE_LOG_TO_STDOUT` | 日志输出到标准输出 |
| `ASCEND_RT_VISIBLE_DEVICES` | 可见 NPU 列表 |
| `MIES_CONTAINER_IP` | 容器 IP，优先级高于 `ipAddress` |
| `MIES_CONTAINER_MANAGEMENT_IP` | 内部面 IP |

### D. 来源

| 来源 | 用途 |
| :-- | :-- |
| mindie-llm-doc.readthedocs.io/zh-cn/latest/ | 官方中文文档总入口 |
| .../user_guide/quick_start/ | 完整部署流程 |
| .../user_guide/user_manual/service_parameter_configuration/ | config.json 全参数 |
| .../user_guide/optimization_and_tuning/ | CPU 优化、异步调度、并行 |
| .../user_guide/feature/* | MTP、SplitFuse、PDMIX、KV INT8 等 |
| .../user_guide/model_support_list/ | 已验证模型列表 |
| .../release_notes/ | 版本配套关系 |
| docs.vllm.ai/projects/ascend | vLLM-Ascend 模型教程（2026 旗舰模型的昇腾路径） |

---

*本文档基于 2026-11-06 可获取的公开资料整理。MindIE 的模型支持列表与 CANN 版本强绑定，部署前务必核对官方支持列表的最新版本。对于本文标注为"未验证"的 2026 旗舰模型，建议优先采用 vLLM-Ascend 路径。*