MindIE 2026 前沿大模型部署手册

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	✅

本文的定位：

完整讲清 MindIE LLM 本身的部署、参数、调优（这是它擅长的、已验证的部分）
对 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 配置文件驱动：

CODE

{
  "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 池化/换出）

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

CODE

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

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

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

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

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

012026 的部署格局

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

四层架构

CODE

┌──────────────────────────────────────────────────┐
│  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 计算

显存划分

CODE

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

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

自动分配的快速公式

官方给出：

CODE

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：

CODE

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 系）

CODE

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架构与参数作用点

服务化进程

CODE

┌───────────────────────────────────────────────┐
│  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，并自行保证安全防护。

一次请求的路径

CODE

① 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.1ServerConfig（服务端）

配置项	默认	说明
`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.2ModelConfig（模型与并行）

配置项	默认	说明
`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.3ScheduleConfig（调度）

配置项	默认	说明
`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`）

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

CODE

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 的核心行为（官方描述）：

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

4.4插件（plugin_params）

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

不需要生效任何插件功能时，请删除该字段

。留空字符串会报错。

4.5MTP

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.6PDMIX 量化

这是昇腾比较有特色的一个优化：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并行策略选型

本引擎的推理拓扑与 KV 存放

为便于阅读，下图使用小规模设备组解释机制，不代表旗舰模型能装入这些设备。

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

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

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

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

官方依据：MindIE 并行与配置文档。图示策略存在不代表某个模型、精度、硬件组合已实测。

五种并行

并行	配置项	约束
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`

组合约束图

CODE

                    ┌─────────────┐
                    │  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.2DeepSeek-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.3Qwen3-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.4SplitFuse 配置（长 + 短 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.52026 旗舰模型：改用 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.1CPU 侧优化（官方推荐，先做）

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

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 路径。

00导读

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

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

数据基准

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

012026 的部署格局

MindIE 的能力矩阵

四层架构

硬件矩阵

2026 前沿模型的昇腾路径

02显存预算与 KV 计算

显存划分

自动分配的快速公式

何时该手动设置

KV Cache 计算

MHA / GQA / MQA（统一公式）

MLA（DeepSeek 系）

KV Cache INT8 的收益

cacheBlockSize 与碎片

03架构与参数作用点

服务化进程

三面隔离

一次请求的路径

Standard vs Mix 的行为差异

04核心参数详解

4.1ServerConfig（服务端）

4.2ModelConfig（模型与并行）

4.3ScheduleConfig（调度）

PD 选择算法（supportSelectBatch: true）

SplitFuse 参数（templateType: Mix）

4.4插件（plugin_params）

4.5MTP

4.6PDMIX 量化

05并行策略选型

本引擎的推理拓扑与 KV 存放

五种并行

组合约束图

各并行的硬件/模型约束

DeepSeek-V3 的典型配置

EP 的两种实现

PD 分离

06逐模型实战配置

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

步骤 1：环境准备

步骤 2：获取权重

步骤 3：启动容器

步骤 4：设置环境变量

步骤 5：配置 config.json

步骤 6：启动服务

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

6.3Qwen3-235B-A22B

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

6.52026 旗舰模型：改用 vLLM-Ascend

环境

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

官方给的一个重要提醒

07调优方法论

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

7.2异步调度

7.3调优顺序

7.4按场景的配方

7.5压测

08生产化与排错

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

8.2监控

8.3故障排查

8.4特性叠加冲突速查

09附录

A. config.json 完整骨架

B. 参数速查

C. 环境变量

D. 来源

`cacheBlockSize` 与碎片

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

SplitFuse 参数（`templateType: Mix`）