大模型推理知识点总结

一、大模型推理的基本概念

先明确一个核心问题：什么是大模型推理？
简单来说，推理就是给定一个输入（比如一段文字指令），让训练完成的大模型通过前向计算，输出符合预期结果的过程。这个过程和模型训练有着本质区别：

训练是双向计算：不仅要做前向计算得到预测结果，还要通过反向传播计算梯度，不断更新模型参数，目的是让模型“记住”数据中的规律和知识。
推理是单向计算：只进行前向传播，模型参数是固定不变的，目的是用已有的参数，快速、准确地对新输入做出响应。

举个形象的例子：训练就像学生在课堂上听课、做习题、记知识点；推理就像学生走进考场，用记住的知识点答题——考场里不能翻书（参数固定），只能靠已有的储备解题，而且还要追求答题速度（低延迟）和正确率（高精度）。

大模型推理的核心目标很明确：在保证输出结果质量的前提下，最大化推理速度、最小化资源消耗。这两个目标直接决定了一个大模型应用的用户体验和部署成本。

二、大模型推理的核心流程

大模型推理的流程并不复杂，我们以最常见的Transformer架构模型为例，拆解成四个关键步骤，循序渐进理解：

1. 输入处理：把自然语言转成模型能懂的“语言”

模型无法直接理解人类的自然语言，第一步要做的就是输入编码，分为两个子步骤：

分词（Tokenization）：把输入的文本拆分成一个个模型预训练时约定好的“最小单位”，也就是Token。比如“大模型推理很有趣”，可能会被拆成“大模型”“推理”“很”“有趣”这几个Token（具体拆分规则由模型的分词器决定）。
向量化：把每个Token转换成对应的向量（Embedding）。这个向量是模型预训练阶段就学习好的，每个Token都有唯一的向量表示，这样模型才能对输入进行后续的数学计算。

2. 前向计算：模型的“思考”过程

这是推理的核心环节，也是计算量最大的一步。以Transformer的Decoder-only架构（比如GPT系列）为例，输入向量会依次经过多层Transformer Block的计算，每一层Block又包含两个核心模块：

多头注意力机制：这是模型的“理解核心”，它会计算输入Token之间的关联关系。比如输入“帮我写一篇关于大模型推理的短文”，注意力机制会让模型关注“大模型推理”这个核心关键词，忽略无关冗余信息。
前馈神经网络（FFN）：在注意力机制的基础上，对向量进行进一步的线性变换和非线性激活，让模型学习更复杂的特征。

需要注意的是，前向计算的过程是逐层递进的，输入向量会从第一层Transformer Block流到最后一层，每一层的输出都会作为下一层的输入，最终得到一个隐藏状态向量。

3. 输出解码：把模型的“思考结果”转成自然语言

经过前向计算得到的隐藏状态向量，依然是模型能懂的“机器语言”，需要通过解码转换成人类能理解的文本，常见的解码策略有两种：

贪心解码：每一步都选择概率最高的Token作为输出，优点是速度快，缺点是容易生成重复、单调的文本。
束搜索（Beam Search）：每一步会保留概率最高的k个候选Token（k就是束宽），最终从这些候选中选出最优的序列，优点是生成的文本质量更高，缺点是计算量比贪心解码大。

4. 后处理：让输出更“干净”

解码得到的Token序列，还需要做一些收尾工作，比如去掉特殊Token（比如分隔符、结束符）、修正语法错误、格式化输出格式（比如把列表型的输出整理成有序列表），最终得到符合用户需求的结果。

三、大模型推理的核心挑战

为什么大模型推理需要专门的技术优化？因为它面临着三个绕不开的核心挑战：

1. 计算量巨大

Transformer架构的计算复杂度和三个因素成正比：模型层数（L）、隐藏层维度（d）、输入输出的Token数（n）。对于千亿参数的大模型来说，一次简单的对话推理，可能就要进行数万亿次的浮点运算，普通的硬件根本无法承载。

2. 内存瓶颈突出

大模型的参数数量是天文数字，比如一个千亿参数的模型，若用FP32（32位浮点型）存储，单模型就需要约400GB的内存（1个FP32参数占4字节，1000亿×4字节=4000亿字节≈400GB）。而推理过程中，除了要存储模型参数，还要存储中间计算结果（比如每一层的隐藏状态、注意力的Key和Value），这进一步加剧了内存压力。

3. 延迟与吞吐量的平衡难题

不同的应用场景，对推理的要求截然不同：

实时场景（比如智能客服、语音助手）：要求低延迟，用户输入后要在几百毫秒内得到响应，这时候就需要牺牲一定的吞吐量，优先保证单条请求的处理速度。
批量场景（比如文档批量总结、数据批量处理）：要求高吞吐量，希望在单位时间内处理更多的请求，这时候可以通过批量处理来提升效率，但会增加单条请求的延迟。

如何在延迟和吞吐量之间找到最优解，是推理优化的核心命题。

四、大模型推理的关键优化技术

针对上述挑战，业界已经形成了一套从模型到工程的全链路优化方案，我们可以把这些技术分成三大类：

1. 模型层面优化：让模型“变小变轻”

这类优化的核心思路是，在尽量不损失模型性能的前提下，减少模型的参数数量或计算量。

量化：这是最常用的优化手段。它的原理是把模型参数的存储精度从高到低转换，比如从FP32降到INT8（8位整型）、甚至INT4。以INT8为例，参数存储体积直接减少为原来的1/4，计算量也大幅降低，同时内存占用也会显著减少。目前主流的推理框架都支持量化，而且很多场景下量化后的模型性能下降几乎可以忽略。
蒸馏：可以理解为“大模型教小模型”。用一个性能强大的大模型作为“教师模型”，一个体量较小的模型作为“学生模型”，让学生模型学习教师模型的输出分布，最终得到一个性能接近大模型、但体积和计算量小得多的模型。
剪枝：模型中存在很多“冗余参数”，这些参数对模型输出的贡献很小。剪枝就是把这些冗余参数去掉，比如去掉权重接近0的参数，从而减少模型的参数数量和计算量。

2. 计算层面优化：让硬件“物尽其用”

这类优化的核心是提升硬件的计算效率，让硬件的算力得到充分发挥。

算子融合：Transformer模型的前向计算包含大量的小算子（比如矩阵乘法、激活函数、归一化），这些小算子的调度会带来额外的开销。算子融合就是把多个相关的小算子合并成一个大算子，减少调度次数，提升计算效率。
并行推理：这是应对超大模型推理的核心手段，主要分为三种：
- 张量并行：把模型的同一层参数拆分到多个GPU上，每个GPU负责一部分参数的计算，最后汇总结果。适合解决单GPU内存不足的问题。
- 流水线并行：把模型的不同层拆分到多个GPU上，输入数据像流水线一样依次经过各个GPU的计算，提升计算的并行度。
- 数据并行：把多个输入请求分配到不同的GPU上，每个GPU运行完整的模型，同时处理不同的请求，提升吞吐量。

3. 工程层面优化：让推理“更省更快”

这类优化更偏向工程实践，是落地过程中不可或缺的环节。

KV Cache优化：在生成式大模型的推理中，每生成一个新的Token，都需要用到之前所有Token的Key和Value向量。如果每次都重新计算这些向量，会造成大量的重复计算。KV Cache的思路是，把已经计算过的Key和Value向量缓存起来，后续生成Token时直接调用，从而大幅减少计算量。目前主流的推理框架（比如vLLM）还引入了PagedAttention技术，进一步提升KV Cache的内存利用率。
批处理优化：合理设置批处理大小（Batch Size），让硬件在单位时间内处理更多的请求。比如在批量总结文档时，把多个文档打包成一个批次进行推理，能显著提升吞吐量。但批处理大小也不是越大越好，超过硬件的承载能力反而会导致内存溢出。

五、主流推理框架简介

想要快速落地大模型推理，不需要从零开始写代码，借助成熟的推理框架就能事半功倍。目前主流的推理框架有这几个：

TensorRT：NVIDIA推出的高性能推理框架，支持量化、算子融合等多种优化手段，对NVIDIA GPU的适配性最好，能显著提升推理速度。
vLLM：主打高吞吐量的开源推理框架，核心亮点是PagedAttention技术，能高效管理KV Cache，在大批次请求下的表现尤为出色。
Text Generation Inference（TGI）：Hugging Face推出的推理框架，专门针对生成式大模型优化，支持多种解码策略和并行推理，集成简单，易于部署。