文档(金鹏): 2026-08-06 章节 48 篇文章摘要归档
- 46 篇原文+摘要双文件归档（按 来源/作者 分层，复用本地归档 20 篇+新抓取 26 篇） - 即梦生成 9 组主题配图（大图+列表缩略图）存入 知识/金鹏/20260806/ - 章节重组为 9 个主题分组并挂接摘要引用
This commit is contained in:
@@ -0,0 +1,155 @@
|
||||
# 【昇腾大规模专家并行技术解码】PD分离，让推理性能再提速30%！
|
||||
|
||||
> **来源**：昇腾社区（技术干货）
|
||||
> **作者**：未知（昇腾官方，未署名）
|
||||
> **发布日期**：2025-04-23
|
||||
> **原文链接**：https://www.hiascend.com/developer/techArticles/20250423-1
|
||||
|
||||
---
|
||||
|
||||
随着大语言模型（LLM）的快速发展，提升用户体验、增加吞吐和并发成为关键。昇腾推出大规模专家并行推理方案，通过优化专家分布、通信计算加速，将单卡吞吐提升了3倍以上。然而，LLM的Prefill和Decode阶段"混合部署"在吞吐和时延上仍存在瓶颈，针对这一问题，昇腾使用PD分离技术，进一步将吞吐量提升了30%以上，取得性能&效率的双提升。
|
||||
|
||||
## 大模型推理的趋势和挑战
|
||||
|
||||
生成式人工智能的核心 —— 大规模语言模型推理，其推理过程通常分为两个阶段：Prefill阶段和Decode阶段。Prefill阶段负责处理用户的输入生成初始KV缓存，并生成第一个Token（字），而Decode阶段则负责后续Token的生成。如下图：
|
||||
|
||||
*文本经过Prefill计算和Decode解码*
|
||||
|
||||
一方面，随着AI大模型的发展，数百GB模型权重文件、千亿参数模型更加常见。在"尝鲜"时，数百GB的MoE模型加载使推理效率降低，因此，通过集群化部署，将**MoE模型专家拆分到多张NPU卡上进行专家并行（EP）成为趋势**。
|
||||
|
||||
另一方面，在传统部署方案中，Prefill和Decode这两个阶段往往运行在同一个计算节点上，导致传统部署方案存在如下问题：
|
||||
|
||||
- **1.PD时延互相干扰**：Prefill和Decode阶段互相等待，用户需要增加等待时延，为了保证用户体验（时延小于100ms)，必须牺牲并发，降低吞吐率。
|
||||
- **2.计算与访存冲突**：Prefill阶段是计算密集型任务，Decode阶段是访存密集型任务，混合在同一节点上的运行，会导致算力和显存资源的竞争冲突。
|
||||
- **3.资源利用不足**：两阶段硬件需求差异较大，为保证效果需要算力、显存资源过配置，混合部署难以充分利用资源，存在资源利用不足的问题。
|
||||
|
||||
### 1. 昇腾大规模专家并行方案
|
||||
|
||||
本方案是将数百个专家（Expert）离散地分布到更多的卡上。
|
||||
|
||||
*大规模专家并行专家分配示意图*
|
||||
|
||||
这个方案可以做到：
|
||||
|
||||
- **1.权重加载更快**：每张卡只需要加载部分专家权重，整体时延降低；
|
||||
- **2.并行路数更多**：单卡专家少，空闲显存更多，显著提升并行的路数；
|
||||
- **3.资源利用率更高**：专家可以充分利用单卡上的资源，整体提高效率；
|
||||
|
||||
因此，大规模专家并行方案可以实现更大的吞吐和更低的时延。
|
||||
|
||||
### 2. 昇腾PD实例分离方案
|
||||
|
||||
结合大规模专家并行方案，昇腾进一步通过MindIE推理引擎的调度，将Prefill和Decode阶段分别部署到不同的服务器上，分别作为P实例和D实例：
|
||||
|
||||
*将服务器做PD实例分离示意图*
|
||||
|
||||
通过PD分离，可以达到：
|
||||
|
||||
- **1.消除PD间时延干扰**：Decode可以使用更大的BatchSize，计算效率更高。
|
||||
- **2.PD灵活配比调节**：可以根据PD需要的计算资源，独立地调整资源的比例，资源利用更充分。
|
||||
- **3.PD资源解耦**： P实例和D实例使用不同的硬件资源，避免资源的冲突。
|
||||
|
||||
## 快速部署
|
||||
|
||||
### 1. 环境准备
|
||||
|
||||
**硬件需求：**
|
||||
|
||||
以16台昇腾服务器为例，8台组成4个P实例，8台作为1个D实例。服务器需具备高算力和大显存（推荐使用昇腾Atlas 800系列）。同时，确保服务器之间网络带宽充足（建议200Gbps或以上）。
|
||||
|
||||
**软件环境：**
|
||||
|
||||
- **1.安装k8s环境；**
|
||||
- **2.集群节点安装MindCluster调度组件；**
|
||||
- **3.安装MindIE镜像，支持大规模专家并行调度、PD分离功能。**
|
||||
|
||||
**准备权重：**
|
||||
|
||||
可从"魔乐社区"准备DeepSeek-R1 INT8量化版模型权重文件。
|
||||
|
||||
### 2.配置和启动服务
|
||||
|
||||
**准备配置文件**
|
||||
|
||||
从"昇腾社区"获取最新版本的MindIE软件包文件Ascend-mindie_2.0.RC1_linux-aarch64.run，拷贝到Linux本地，并执行如下命令：
|
||||
|
||||
```
|
||||
chmod +x Ascend-mindie_2.0.RC1_linux-aarch64.run
|
||||
./Ascend-mindie_2.0.RC1_linux-aarch64.run --extract=mindie
|
||||
/mindie/Ascend-mindie-service_2.0.RC1_py311_linux-aarch64.run
|
||||
--extract=mindie-service
|
||||
cd mindie-service/examples/kubernetes_deploy_scripts
|
||||
cp ../../conf/config.json ./conf/config_p.json
|
||||
cp ../../conf/config.json ./conf/config_d.json
|
||||
cp ../../conf/http_client_ctl.json ./conf
|
||||
cp ../../conf/ms_controller.json ./conf
|
||||
cp ../../conf/ms_coordinator.json ./conf
|
||||
```
|
||||
|
||||
根据业务需求，执行命令修改当前目录下的配置文件"user_config.json"
|
||||
|
||||
```
|
||||
vim user_config.json
|
||||
```
|
||||
|
||||
**PD分离部署参数配置：**
|
||||
|
||||
设置 Prefill 和 Decode 阶段的实例数量 ，保持两者处理速度匹配，如下配置为4个Prefill实例，每个实例2台服务器，1个Decode实例，每个实例8台服务器。
|
||||
|
||||
```
|
||||
"p_instances_num": 4, // 配置4个Prefill实例
|
||||
"d_instances_num": 1, // 配置2个Decode实例
|
||||
"single_p_instance_pod_num": 2, // 单个Prefill实例使用2个服务器
|
||||
"single_d_instance_pod_num": 8, // 单个Decode实例使用8个服务器
|
||||
```
|
||||
|
||||
可根据实际业务负载，调整实例数量和实例服务器配置。
|
||||
|
||||
**大规模专家并行部署配置：**
|
||||
|
||||
将模型拆分为多个 Expert 实例，分别部署到不同的 NPU卡上。
|
||||
|
||||
```
|
||||
"moe_ep": 4, // Prefill实例或Decode实例的MOE EP配置
|
||||
"moe_tp": 4, // Prefill实例或Decode实例的MOE 配置
|
||||
```
|
||||
|
||||
**调度与资源管理：**
|
||||
|
||||
使用 MindIE 的调度器协调Prefill和Decode阶段的任务分配。根据负载变化自动调整批处理大小（Batch Size），提升吞吐量。
|
||||
|
||||
```
|
||||
"maxPrefillBatchSize": 4, // Prefill实例一个batch中包含请求个数的上限
|
||||
"maxPrefillTokens": 4096, // Prefill实例一个batch中包含input token总数的上限
|
||||
```
|
||||
|
||||
**拉起服务：**
|
||||
|
||||
在当前目录执行如下命令拉起服务。观察服务日志 。
|
||||
|
||||
```
|
||||
python3 deploy_ac_job.py
|
||||
bash log.sh
|
||||
```
|
||||
|
||||
当MS Coordinator中出现"MindIE-MS coordinator is ready!!!"时，表示服务拉起成功。
|
||||
|
||||
### 3.性能监控与优化
|
||||
|
||||
使用 MindIE 的性能分析组件，实时监控各节点的负载、时延和吞吐量。
|
||||
|
||||
```
|
||||
benchmark --DatasetPath $dataset_path
|
||||
--ModelName dsv3_w8a8 --ModelPath $weight_path --TestType openai --Http http://$ip:$port
|
||||
--Tokenizer True --MaxOutputLen 2048 --DatasetType gsm8k --WarmupSize 0
|
||||
--RequestRate 12 --Concurrency 2048 --SamplingParams
|
||||
'{"ignore_eos":true}' --WorkersNum 4 --TaskKind text --WarmupSize 0
|
||||
```
|
||||
|
||||
可观察到如下的回显。
|
||||
|
||||
## 结语
|
||||
|
||||
昇腾PD分离技术通过对LLM推理过程中的计算密集型和访存密集型任务进行解耦，结合大规模专家并行方案，显著提升了系统性能和资源利用率，为用户实实在在地节约了成本，提升了业务的质量。这一技术不仅为大规模语言模型的高效推理提供了新的解决方案，也为AI算力的高效利用开辟了新方向。
|
||||
|
||||
未来，随着昇腾处理器在更多场景中的应用，PD分离技术将进一步释放LLM的潜力，为各行业带来更智能化、高效的AI体验。
|
||||
@@ -0,0 +1,79 @@
|
||||
# 📊 文章摘要：【昇腾大规模专家并行技术解码】PD 分离，让推理性能再提速 30%！
|
||||
|
||||
> **原文**：[2025-04-23_昇腾大规模专家并行技术解码_PD分离_让推理性能再提速30%.md](./2025-04-23_昇腾大规模专家并行技术解码_PD分离_让推理性能再提速30%.md)
|
||||
> **原文链接**：https://www.hiascend.com/developer/techArticles/20250423-1
|
||||
> **来源**：昇腾社区
|
||||
> **作者**：未知（昇腾官方，未署名）
|
||||
> **发布日期**：2025-04-23
|
||||
> **摘要日期**：2026-08-06
|
||||
> **价值评级**：⭐⭐ 中
|
||||
|
||||
---
|
||||
|
||||
## 核心命题
|
||||
|
||||
> **双技术叠加** — "大规模专家并行 × PD 分离"组合是昇腾 NPU 上吞吐"3 倍 + 30%"的实现路径，且给出 MindIE 上的可复现部署配置。
|
||||
|
||||
---
|
||||
|
||||
## 文章概要
|
||||
|
||||
本文是昇腾官方技术稿，介绍其大规模专家并行推理方案（将数百个专家离散分布到多张 NPU 卡：权重加载更快、并行路数更多、资源利用率更高，单卡吞吐提升 3 倍以上），并指出 P/D 混合部署仍有"时延互相干扰、计算访存冲突、资源利用不足"三痛点，因此通过 MindIE 引擎把 prefill/decode 分离为 P 实例与 D 实例，吞吐量再提升 30% 以上。价值在于它是少见的"EP + PD 组合"实操文：给出 k8s + MindCluster + MindIE 2.0.RC1 环境、魔乐社区 DeepSeek-R1 INT8 权重、实例数与 EP/TP/batch 配置参数、benchmark 验证命令，可直接照做。局限：性能数字无测试条件与基线说明，宣传性质明显。
|
||||
|
||||
---
|
||||
|
||||
## 关键要点
|
||||
|
||||
1. **混合部署三痛点** — PD 时延互相干扰（为保证时延小于 100ms 须牺牲并发）、计算与访存冲突、为保证效果需算力显存过配置导致利用不足 `[分类: 共识]`
|
||||
2. **大规模专家并行三收益** — 每卡只加载部分专家权重（加载更快）、单卡专家少空闲显存多（并行路数更多）、专家充分利用单卡资源（利用率更高） `[分类: 共识]`
|
||||
3. **PD 分离三收益** — 消除阶段间时延干扰（decode 可用更大 BatchSize）、PD 配比独立调节、P/D 使用不同硬件资源实现资源解耦 `[分类: 共识]`
|
||||
4. **可复现部署路径** — 16 台服务器（4 个 P 实例×2 台 + 1 个 D 实例×8 台）、网络建议 200Gbps 以上；MindIE 配置 p_instances_num/d_instances_num/moe_ep/moe_tp/maxPrefillBatchSize 等参数 `[分类: 共识]`（实操）
|
||||
5. **性能验证手段** — MindIE benchmark 命令（gsm8k 数据集、并发 2048、RequestRate 12）与各节点负载、时延、吞吐监控 `[分类: 共识]`（实操）
|
||||
|
||||
---
|
||||
|
||||
## 批判性分析
|
||||
|
||||
### 假设前提
|
||||
|
||||
假设用户具备昇腾 Atlas 800 系列硬件与 MindIE 生态（魔乐社区权重）；假设服务器间 200Gbps 以上网络带宽可保证 KV 传输效率；假设其性能声称（3 倍、30%）在类似环境中可复现。
|
||||
|
||||
### 论据与逻辑
|
||||
|
||||
性能数字（单卡吞吐提升 3 倍、PD 分离再提升 30% 以上）未给出测试负载、模型规格与对比基线，作为官方宣传文无法独立验证；但部署指南步骤完整、参数明确，可执行性强。
|
||||
|
||||
### 边界与局限
|
||||
|
||||
仅适用于昇腾 NPU + MindIE 技术栈，跨厂商迁移需重做；未讨论 KV 传输机制细节与调度复杂度；P/D 配比 4P:1D 仅以"保持两者处理速度匹配"概括，缺乏量化依据。
|
||||
|
||||
---
|
||||
|
||||
## 可引用金句
|
||||
|
||||
> "昇腾使用PD分离技术，进一步将吞吐量提升了30%以上，取得性能&效率的双提升。"
|
||||
|
||||
> "将数百个专家（Expert）离散地分布到更多的卡上。"
|
||||
|
||||
---
|
||||
|
||||
## 总体评价
|
||||
|
||||
**亮点**：
|
||||
- "EP + PD 分离"组合与国产 NPU 生态（MindIE、魔乐社区权重）结合，信息稀缺
|
||||
- 部署配置参数具体可复现，含 benchmark 验证命令
|
||||
- 给出网络带宽（200Gbps）与实例配比等可参考基线
|
||||
|
||||
**不足**：
|
||||
- 性能数据无测试条件与基线，难以独立验证
|
||||
- 偏官方宣传口径，未讨论局限与失败场景
|
||||
- 仅覆盖昇腾栈，通用性有限
|
||||
|
||||
**适用场景**：昇腾 NPU 集群的推理部署工程师；想评估国产算力上 PD 分离方案的团队。
|
||||
|
||||
**关联建议**：对照昇腾 MindIE 官方文档核对配置项；与 NVIDIA Dynamo/vLLM 的 PD 分离部署做横向对比。
|
||||
|
||||
---
|
||||
|
||||
## 配图
|
||||
|
||||
|
||||
Reference in New Issue
Block a user