---
tags: [大模型, 推理优化, CANN]
doc_type: knowledge-note
abstract: "通过瓶颈分析理解算子融合、图模式、KV分页、张量并行和计算通信重叠。"
creation: 2026-10-15
返回目录: "[[计算机系/昇腾与CANN/大模型与算子专题学习导航|大模型与算子专题学习导航]]"
上一篇: "[[计算机系/昇腾与CANN/大语言模型与推理系统|大语言模型与推理系统]]"
下一篇: "[[计算机系/昇腾与CANN/大模型量化原理与部署|大模型量化原理与部署]]"
---

# 大模型推理优化

前置：[大语言模型与推理系统](大语言模型与推理系统.md) · 量化专题：[量化原理与部署](大模型量化原理与部署.md)

## 1. 优化先确定瓶颈

一次推理同时涉及 Host 调度、设备计算、内存访问，多卡时还增加通信。只有知道主要开销在哪里，才能选择有效优化。

| 现象或瓶颈 | 主要方向 | 需要观察 |
| --- | --- | --- |
| 小算子很多，中间数据频繁写回 | 算子融合 | kernel 数量、内存读写、执行时间 |
| Host 下发间隙明显 | 图模式或图捕获复用 | CPU/NPU 时间线和设备空闲 |
| KV 占用限制并发 | 分页、共享、压缩 | 缓存占用与有效请求容量 |
| 权重带宽或容量受限 | 权重量化 | 数据量、低精度算子效率及质量 |
| 单卡容量或吞吐不足 | 多卡并行 | 每卡负载、通信量、扩展效率 |

单卡内部通常经历 GM/HBM 数据读取、核内计算、结果写回。优化可以减少搬运、减少中间写回、提升计算效率，或让搬运与计算重叠。增加设备数量无法自动修复单卡调度与算子效率问题。

可以用四句话记住优化方向：**少搬一点、少写一次、边搬边算、少等下发**。量化缩小数据，融合减少中间写回，流水重叠隐藏部分搬运时间，图模式减少重复调度。这些方向分别对应不同瓶颈，不是同一种“让算力更大”的方法。

## 2. 融合算子减少什么开销

### Add 与 RMSNorm

先计算残差相加 $z=x+r$，再归一化：

$$
y_i=\frac{z_i}{\sqrt{\frac1d\sum_{j=1}^{d}z_j^2+\epsilon}}w_i
$$

基础操作包括 Add、平方、均值、开方、除法和乘权重。

算子描述逻辑运算，Kernel 是设备执行的具体实现。一个算子可以启动多个 Kernel，多个算子也可以融合成更少的 Kernel。因此不能仅根据公式里有几个符号，推断一定启动几次设备任务。

| 实现方式 | 调度关系 | 中间结果 |
| --- | --- | --- |
| 分别调用基础操作 | 多次 kernel 启动 | 可能多次写入和读出全局内存 |
| Add + 已融合的 RMSNorm | 两个主要 kernel | Add 结果仍需跨 kernel 传递 |
| AddRMSNorm 融合 | 将两者合并 | 可在片上复用更多中间数据 |

![Add与RMSNorm融合](.assets/大模型与算子专题/Add-RMSNorm融合.png)

融合主要节省 kernel 启动、调度与中间读写，而不必减少数学公式中的运算数量。图中的“一次往返”表示输入到输出的融合路径，实际字节数还取决于分块、输出数量以及是否需要保留残差结果，不能直接当作精确访存计数。

CANN 提供 `npu_rms_norm`、`npu_add_rms_norm` 等接口。调用时应检查参数顺序、输出数量、类型与布局，不能只按函数名替换。

### Attention 融合

Attention 包含 QK 矩阵乘、缩放与掩码、Softmax、乘 V。融合可以减少中间分数矩阵写回，提高数据复用。较长序列通常需要分块和在线归一化，并不要求将整个注意力矩阵都装入 UB。

推理融合接口示例为 `torch_npu.npu_fused_infer_attention_score`。具体支持的 shape、布局、缓存模式和精度由接口版本决定。

融合也有代价：片上存储压力、寄存器占用或复杂同步可能降低并行度，所以融合程度越深不一定越快。内存与流水线细节见 [SIMD 硬件内存与同步](Ascend%20C%20SIMD硬件内存与同步.md)。

## 3. 图模式优化执行调度

Eager 模式按程序动态执行算子，便于调试和表达动态逻辑。图模式先捕获或编译可复用的计算路径，再优化并重放执行，减少重复的 Python、框架和下发开销。

**算子融合改变计算粒度，图模式改变整体执行与调度方式。**二者可以配合，但进入图模式不等于整网必然只有一个 kernel。

![Eager与图模式时间线](.assets/大模型与算子专题/Eager与图模式对照.png)

对时间线应关注 Host 下发间隙、NPU 空闲与连续执行区间。上图展示 Qwen3-8B Decode 的一次对照，不应脱离输入、配置与硬件据此推导通用加速倍数。

| 路径 | 主要思路 | 适用条件与成本 |
| --- | --- | --- |
| `ge_graph` | 图编译与执行计划优化 | 较稳定的结构与 shape，有首次编译开销 |
| `npugraph_ex` | 捕获、缓存与重放执行 | 高频重复路径；变化的 shape 可能需要新捕获或额外适配 |

动态 shape 的支持范围、缓存键和重编译策略需要结合具体实现。图缓存命中时的性能不能直接等同于所有新请求的性能。

部署时用典型输入预热，分别记录冷启动与稳定运行耗时。Eager 也能异步下发，不能把它理解成每个算子都必然要求 Host 同步等待。

`torch.npu.synchronize()` 用于等待设备工作完成，例如划定计时边界或确保结果可用。它不会提高 Host 下发速度；在每个小算子后都同步，反而可能破坏异步重叠。发现设备空闲时，应先分析空隙是调度、依赖还是数据传输造成，再选择图模式、融合或流水优化。

## 4. KV Cache：分页管理与压缩

![KV分页与压缩](.assets/大模型与算子专题/KV分页与压缩.png)

### 分页解决空间如何分配

如果为每个请求预留最大长度的连续缓存，短请求会浪费空间，长请求与动态批处理又难以安排。

分页方式将 KV 切成固定大小的物理块，用映射表将请求的逻辑位置对应到这些块。逻辑连续不要求物理连续，可以按需分配和回收，提高显存利用率与并发容量。

分页主要改善管理、碎片和复用，**不会凭空减少保存同样数量 K/V 元素所需的有效数据字节数**，还会产生映射和末块空闲等开销。

### 量化解决每个元素占多少空间

将 FP16 KV 改为 INT8，在不计缩放参数等开销时，数据本体字节数约减半。实际还需考虑量化、反量化及长文本质量变化。

分页与量化可以组合：一个优化分配方式，一个优化数值表示。具体量化算法统一见 [大模型量化原理与部署](大模型量化原理与部署.md)。

## 5. 多卡并行的切分对象

| 并行方式 | 切什么 | 主要用途与限制 |
| --- | --- | --- |
| DP，数据并行 | 不同请求或 batch | 各副本保存模型，提高总吞吐，不能直接解决单副本权重过大 |
| TP，张量并行 | 层内权重与计算 | 分摊层的存储与计算，增加层内通信 |
| PP，流水线并行 | 不同层或阶段 | 分摊模型深度，需考虑阶段均衡和流水线气泡 |
| SP，序列并行 | 序列维数据或部分算子 | 减少部分激活负担，具体语义取决于框架 |
| EP，专家并行 | MoE 专家 | 分散专家权重与计算，关注路由通信和负载不均 |

并行策略依据模型、上下文、并发、设备内存和互联选择。不能仅凭“模型超过多少参数”确定是否需要多卡。

### 张量并行的矩阵原理

设 $Y=XW$，$X\in\mathbb{R}^{B\times K}$，$W\in\mathbb{R}^{K\times N}$。

![张量并行切分](.assets/大模型与算子专题/张量并行矩阵切分.png)

**按输出维度 N 切 W：**每卡使用相同 X，计算不同输出列。

$$
W=[W_0\ W_1],\qquad Y=[XW_0\ XW_1]
$$

需要完整 Y 时沿列拼接；如果后续层可以直接消费分片，则不必立即聚合。

**按归约维度 K 切分：**X 的列与 W 的行对应切分，各卡得到部分和。

$$
X=[X_0\ X_1],\qquad
W=\begin{bmatrix}W_0\\W_1\end{bmatrix},\qquad
Y=X_0W_0+X_1W_1
$$

此时需要求和归约，不能用拼接代替。数学关系保持一致，浮点计算顺序改变仍可能带来小的数值差异。

MLP 可以将前一层的列切分与后一层的行切分搭配，Attention 可以按头切分，但具体通信点取决于实现。

## 6. 计算与通信重叠

![计算通信重叠](.assets/大模型与算子专题/计算通信重叠.png)

在依赖允许时，让一部分计算与另一部分通信同时进行，可以缩短关键路径。理想的独立片段耗时从两者之和接近两者最大值，但启动、同步和资源竞争仍会产生额外成本。

HCCL 是通信库，不是名为“HCCL”的单个硬件计算单元。图中将它画成独立泳道，是为了表示通信工作与计算工作的重叠。

两条 Stream 不保证并行。要检查任务是否有数据依赖、是否争用硬件与带宽，以及等待事件是否放在真正需要数据的位置。

## 7. 一次可解释的优化实验

1. 固定模型、权重精度、输入输出长度、并发与采样方式，保存基线质量和性能。
2. 预热后观察 profiler，区分算子耗时、调度间隙、带宽和通信问题。
3. 每次改变一个主要因素，例如将 Add+RMSNorm 替换为融合实现。
4. 检查输出误差和任务质量，再比较 TTFT、TPOT、吞吐及显存。
5. 记录冷启动成本与不同 shape 下的结果，避免只报告一个有利样本。

实践入口：[融合算子与 NPU 优化](https://gitcode.com/cann/cann-learning-hub/blob/master/tutorials/llm_inference/qwen3_8b/04_npu_optimization.ipynb)。

复习时应能解释：为什么融合减少读写、为什么图模式需要预热、为什么分页不等于量化、为什么 TP 的两种矩阵切分分别需要拼接与求和。
