# 10.1 推理瓶颈分析：计算密集还是访存密集

理解推理优化的第一步，是弄清楚大语言模型推理的**瓶颈到底在哪里**。

## 10.1.1 两个阶段的不同特性

LLM 推理可分为两个截然不同的阶段：

**预填充阶段**（Prefill）：处理用户输入的所有词元，一次性计算它们之间的注意力。这个阶段是**计算密集型**的——GPU 的算力是瓶颈，类似训练中的前向传播。

**生成阶段**（Decode/Generation）：逐个生成新的词元，每次只计算一个新词元与之前所有词元的注意力。这个阶段是**访存密集型**（Memory-Bound）的——每生成一个词元，都需要从 GPU 显存中加载完整的模型权重和 KV 缓存，但实际计算量很小。

## 10.1.2 访存瓶颈的数学解释

在生成阶段，每个词元的计算涉及：

* 加载所有层的权重矩阵（总大小 = 模型参数量 × 字节数/参数）
* 加载 KV 缓存（总大小随已生成序列长度线性增长）
* 实际的矩阵-向量乘法运算

以一个 70B 参数的 FP16 模型为例：完整权重约 140 GB，而单张 H100 SXM 只有 80 GB 显存，因此这个模型不能在单张 80 GB H100 上以 FP16 完整驻留。若把 140 GB ÷ 3.35 TB/s 作为**理论下界**，纯权重读取也约需 42 毫秒；真实部署通常需要多卡张量并行、H100 NVL/H200/B200 级别显存、量化或分层卸载，并且还要计入 KV 缓存读取、跨卡通信和 batch 形状。这个例子的重点不是推荐单卡部署，而是说明 decode 阶段对显存带宽极其敏感。

这就是为什么生成阶段的**算术强度**（每字节访存对应的浮点运算数）极低，GPU 的计算单元大部分时间在等待数据加载。

## 10.1.3 优化方向

基于这一分析，推理优化技术大致可分为三类：

1. **减少访存量**：量化（用更少的位数存储权重）、剪枝（减少参数数量）
2. **减少重复计算**：KV 缓存（避免重新计算之前词元的注意力）
3. **提高并行度**：投机解码（一次验证多个词元）、连续批处理（更好地利用 GPU 计算资源）


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://yeasy.gitbook.io/llm_internals/di-san-bu-fen-tui-li-yu-bu-shu-pian/10_inference_optimization/10.1_bottleneck.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.