大模型推理从基础到优化，小白也能掌握的实用技术指南！

本文系统讲解大模型推理的基础知识、瓶颈与优化技术。推理核心是"固定参数下高效生成"，主要瓶颈是内存受限，尤其是KV缓存占用大。优化技术分为有损（GQA、量化、剪枝）和无损（推测性采样）两类，结合动态调度技术可解决实际场景中的请求混乱问题。不同场景需选择适合的优化技术组合，平衡精度、速度与内存需求。

网安福宝

438人浏览 · 2025-10-11 07:00:00

网安福宝 · 2025-10-11 07:00:00 发布

预备知识：关键概念与符号理解
在学习推理前，需先明确描述模型“形状”的核心符号含义，以及Transformer推理的核心模块，避免后续理解障碍。

在这里插入图片描述

1. 核心符号的通俗解释
这些符号都是描述模型大小、数据量的正整数或常量，会频繁用到：

符号	通俗含义	实例（Llama 2 13B模型）
B	并发处理的请求数（比如同时给模型发10个提问）	1、64、256
S	输入提示的长度（比如提问有1024个汉字/单词）	1024
T	模型生成的响应长度（通常一次生成1个token）	1
D	模型隐藏层的“宽度”（越大模型越复杂）	5120
F	MLP层的“扩展宽度”（通常是D的4倍）	13824（D=5120的4倍）
N	注意力机制的总头数（头越多，关注角度越广）	40
K	键值（KV）头数（GQA/MLA中会比N少）	40（普通注意力）/8（GQA）
H	单个注意力头的“宽度”（D是N的倍数）	128（D=5120÷N=40）
L	模型的层数（层数越多，模型能力越强）	40
V	模型认识的词汇总数（比如3.2万个常用词）	32000
内存带宽	硬件每秒能传输的内存数据量（越大越快）	H100显卡约3.35万亿字节/秒

2. Transformer推理的核心模块
推理只用到模型的“前向计算”，核心是两个模块，需理解其基本逻辑：

MLP层

把模型的中间结果（比如当前token的表示）先“扩宽”再“缩窄”，让模型学习更复杂的规律（比如“猫”和“狗”的区别）；
注意力层

让模型生成当前token时，“关注”输入提示中相关的部分（比如生成“它会叫”时，关注“狗”这个词），需要存储历史token的“键（K）”和“值（V）”——这就是KV缓存的来源。

第一章推理的基础认知：从定义到核心差异

一、预备知识：推理与训练的本质区别

训练

给模型喂大量数据，调整模型内部的“参数”（类似人脑的神经元连接），让模型学会规律（比如区分猫和狗、理解语言）；
推理

训练完成后，固定参数不变，输入“提问（提示）”让模型生成“回答（响应）”——核心诉求是“又快又准”。

二、核心内容：推理的应用场景与效率价值

1. 推理的4大实际场景
每个场景对“快”和“准”的要求不同，结合实际产品举例：

场景	具体例子	核心需求
实际产品落地	ChatGPT聊天、Cursor代码补全、批量处理文本摘要	低延迟（交互流畅）、高吞吐量
模型性能测试	用MMLU数据集测模型的知识水平	吞吐量优先（批量计算）
模型“思考”过程	让模型分步推理（比如“先算1+2，再乘3”）	低延迟（避免等待过久）
强化学习优化	生成样本让“奖励模型”打分，再调整推理模型	高吞吐量（需大量样本）

2. 为什么效率很重要？——“一次性成本”vs“长期成本”

训练成本

比如训练Llama 2 13B，需要百万美元级的计算资源，但只需要一次；
推理成本

如果每天要处理10亿个token（比如ChatGPT的日常用量），按H100显卡每秒处理100万个token算，需要30多张卡24小时运行——这是长期重复的成本，效率直接决定能不能商业化。

三、案例落地：推理的3个关键性能指标
从用户感知和实际需求出发，定义了3个核心指标，用“日常体验”举例：

指标	通俗理解	用户体验例子	优化方向
TTFT（首token时间）	输入提问后，等多久出第一个字/词	聊天时“发完消息，几秒出第一个字”	预填充阶段用小批次、优化编码
延迟（Latency）	生成一个字/词需要的平均时间	对话时 “后续文字出现速度”	减少 KV 缓存读取、优化生成阶段
吞吐量（Throughput）	每秒能生成的总字/词数	批量处理10万条文本摘要要多久	增大批次、模型并行

四、核心差异：推理与训练的6个关键不同
这是理解推理瓶颈的关键，通过对比让读者明白“为什么推理更难优化”：

对比维度	训练（Training）	推理（Inference）	对推理的影响
数据处理方式	一次处理整个提问+回答的序列（比如同时算100个token）	一个一个token生成（比如先算“我”，再算“是”）	没法用并行计算，速度慢
内存存什么	存参数、梯度（调整参数的依据）、优化器状态（比如Adam）	只存参数和KV缓存（历史token的K和V）	内存主要被KV缓存占满
计算效率	计算多、数据传输少（效率高）	计算少、数据传输多（效率低）	硬件经常“闲着”（等数据传输）
并发请求数	固定一次处理很多请求（比如256个）	请求随机到达（比如1秒来1个，下1秒来10个）	很难凑齐大量请求一起处理
精度要求	要高精度（比如用4字节存储数据，不然调不好参数）	可降精度（比如用1字节存储，参数已经固定）	能通过压缩数据省内存
什么时候停	训练到损失不再下降或达到轮次	生成到最大长度或“结束符”（比如“。”）	要动态管理每个请求的生命周期

五、小结

推理的核心是“固定参数下高效生成”，场景不同，对“快”和“准”的优先级不同；
推理比训练难优化，主要因为“只能逐个生成token”和“内存被KV缓存占满”；
后续所有优化技术，都是围绕“减少KV缓存”“提升计算效率”“适配动态请求”展开的。

这份完整版的大模型 AI 学习和面试资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】

在这里插入图片描述

第二章推理的核心瓶颈：为什么模型跑不快？

一、预备知识：算术强度——判断效率的关键指标
不用公式，用通俗语言解释：

算术强度

就是“每传输1字节数据，能完成多少计算”——比如传输1字节数据，能算295次，强度就是295；
硬件有“算术强度极限”

比如H100显卡，每秒能算989万亿次，内存每秒能传3.35万亿字节，所以它的极限大概是295；
关键结论

如果推理的算术强度超过295：硬件能满负荷计算（高效）；
如果低于295：硬件大部分时间在等数据（低效，叫“内存受限”）——推理基本都处于这个状态。

二、核心内容：推理为什么会“内存受限”？
通过拆解MLP层和注意力层的计算过程，说明瓶颈所在：

1. MLP层的效率问题（以一次生成1个token为例）

计算过程

要读取当前token的中间结果、3个MLP权重（扩宽、门控、缩窄用），算3次矩阵乘法，再写回结果；
数据传输 vs 计算

传输的数据量（比如读权重、读中间结果）远大于计算量——比如传输100字节数据，只算50次；
效率结论

MLP层的算术强度和并发请求数相关，要同时处理590个以上请求才能达到H100的极限，但实际推理时最多同时处理64个，还是“内存受限”。

2. 注意力层的效率问题（最核心的瓶颈）

计算过程

要读取当前token的“查询（Q）”、历史token的“键（K）”和“值（V）”，算相似度、加权求和，再写回结果；
数据传输 vs 计算

历史token越多（比如提问有1024个token），要传的K和V越多，但计算量增长慢——比如传输1000字节数据，只算100次；
效率结论

注意力层的算术强度大概只有1，远低于H100的295，不管同时处理多少请求，都永远是内存受限——这是推理跑不快的根本原因！

三、案例落地：Llama 2 13B的内存占用有多高？
通过实际计算，让读者直观感受“内存都用在哪了”（以并发1个请求、提示长度1024为例）：

1. 模型参数的内存（用2字节存储每个参数，叫bf16精度）

词嵌入层

把词汇转成向量，约占328MB；
MLP层

40层，每层3个权重，约占8.49GB；
注意力层

40层，每层3个权重（Q、K、V），约占3.15GB；
总参数内存

大概12GB。

2. KV缓存的内存（同样用2字节存储）

每个请求的KV缓存

要存1024个token、40个KV头、每个头128维、40层，还要存K和V两份——约占429MB；
如果同时处理64个请求

KV缓存约占27.46GB（64×429MB）；
总内存（64个请求）

12GB+27.46GB≈39.46GB（H100显卡有80GB显存，刚好能装下；如果处理256个请求，就超显存了）。

四、小结

推理的核心瓶颈是“内存受限”，尤其是注意力层，算术强度只有1，硬件大部分时间在等数据；
内存主要用在两部分：模型参数（固定大小） 和 KV缓存（随请求数、提示长度增加而增加）；
要优化推理效率，关键是“减少KV缓存的占用”或“让数据传输更快”。

第三章有损优化技术：用少量精度换大幅效率提升

一、预备知识：有损优化的原则
“有损”不是“不准”，而是允许微小的精度损失（通常比1%还小），但必须满足实际场景需求（比如聊天、代码补全完全看不出差异），核心目标是“减少内存占用”，尤其是KV缓存。

二、核心内容：4类实用的有损优化技术

1. 减少KV缓存：从“头、层、维度”入手
KV缓存的大小和KV头数、层数、单头维度都有关。介绍3种能大幅减少KV缓存的技术：

技术	原理	效果（Llama 2 13B）	精度影响
分组查询注意力（GQA）	普通注意力中，每个“查询头”都配一个“KV头”（比如40个查询头配40个KV头）；GQA把查询头分成几组，每组共享一个KV头（比如40个查询头分成5组，只配8个KV头）	KV缓存能减少5倍（从429MB/请求降到85.8MB/请求）	实验显示，GQA和普通注意力在知识、推理任务上的精度差异不到0.5%，基本看不出来
多头Latent注意力（MLA）	普通注意力中，KV的维度和模型隐藏层一样（比如5120）；MLA把KV的维度压缩到很小（比如512），只保留核心信息，还会额外加64维来补全位置信息	KV缓存能减少约8.9倍（从429MB/请求降到48.2MB/请求）	惊喜 MLA的精度甚至比普通注意力还高——因为压缩过程过滤了“噪声”（无用信息）
跨层注意力（CLA）	普通注意力中，每一层都单独存KV缓存（40层存40份）；CLA让相邻层共享一份（比如层1和层2共享，层3和层4共享）	KV缓存能减少2倍（40层存20份）	额外好处不仅省内存，还能让层与层之间的信息传递更顺畅，部分任务精度还能提升1-2%

2. 替代架构：不用Transformer也能跑快
传统Transformer的“逐个生成token”是速度瓶颈，新架构通过“不逐个生成”或“简化注意力”来突破：

架构	核心创新	速度与精度对比（示例）
状态空间模型（SSM）（如Mamba, Jamba）	不用注意力，改用“线性递归”（类似信号处理），KV缓存不再随提示长度增加而变大（固定大小）	10亿参数模型对比： · Transformer：生成1个token 0.02秒，每秒50个，知识精度65% · Mamba：生成1个token 0.005秒，每秒200个，知识精度64.5% 扩展：Jamba（520亿参数）把Transformer层和Mamba层按1:7混合，精度追上700亿参数的Transformer，速度还快3倍
扩散模型	不逐个生成，而是从“随机乱码”开始，通过多步优化（比如50步）变成正常文本，每一步都能并行计算	速度优势：生成100个token只需0.1秒（Transformer要1秒）小缺点：文本连贯性稍差，可通过增加优化步数来改善（步数越多，越连贯但越慢）

3. 量化：用更少字节存数据
模型参数和KV缓存默认用2字节存储（bf16），量化就是“用1字节甚至0.5字节存储”，核心是“不影响精度的前提下压缩”：

常用精度对比（以Llama 2 13B为例）

精度类型	每个数据占多少字节	内存占用（参数+KV缓存，64请求）	精度损失	适用场景
bf16（默认）	2	39.46GB	0%	高精度场景
fp8	1	19.73GB	＜1%	平衡精度和内存
int8	1	19.73GB	1-3%	内存紧张场景
int4	0.5	9.87GB	3-5%	边缘设备（手机）

重点推荐的2种量化技术

LLM.int8()

解决“异常值”问题——有些参数值特别大（叫异常值，占0.1%），用1字节存会失真，所以异常值用2字节存，其余用1字节，内存减50%，精度损失不到0.5%；
激活感知量化（AWQ）

按“重要性”存精度——根据输入数据的激活情况，选0.1-1%重要的参数用2字节存，其余用0.5字节，内存减75%，速度提升3.2倍，精度损失不到1%。

4. 模型剪枝：删了冗余部分，模型更轻巧
剪枝就是“把模型中没用的部分删掉”，再通过“蒸馏”修复精度，用NVIDIA的方案举例：

步骤1：找“没用的部分”（用1024个样本校准）

要删的部分

模型层（比如40层删到20层）、注意力头（40个头删到20个）、MLP宽度（13824缩到6912）；
判断标准

删掉某部分后，模型在校准样本上的误差增加不到0.1%，就认为这部分“没用”。

步骤2：删完后修复精度（蒸馏）

用原130亿参数模型当“老师”，删后的32.5亿参数模型当“学生”；
让学生模型学老师的输出规律，最小化两者的差异；
结果

学生模型精度达到老师的95%，速度提升4倍，内存减75%。

三、案例落地：Llama 2 13B优化效果对比（64个请求）

优化技术	内存占用	生成1个token的时间	每秒生成token数	知识任务精度
原始模型（bf16）	39.46GB	0.015秒	4200	71.9%
GQA（8个KV头）	17.46GB	0.008秒	7800	71.5%
GQA+LLM.int8()	9.73GB	0.009秒	7100	71.2%
GQA+AWQ（int4）	5.86GB	0.006秒	10500	70.8%
剪枝+蒸馏（32.5亿）	3.12GB	0.003秒	21000	68.3%

四、小结

减少KV缓存的核心是“共享”（头共享GQA、层共享CLA）和“压缩”（维度压缩MLA）；
量化优先选LLM.int8()（精度损失小）或AWQ（效率高），剪枝适合对速度要求极高的场景；
替代架构（Mamba/扩散模型）是未来方向，能突破Transformer的速度瓶颈。

第四章无损优化技术：不丢精度还能跑快

一、预备知识：无损优化的核心逻辑
“无损”指生成的结果和原模型完全一样（数学保证不会变准或变不准），核心思路是“利用预填充的并行性”——模型处理输入提示（预填充）时能批量计算（快），生成token时只能逐个算（慢），所以用“批量验证”减少生成次数。

二、核心内容：推测性采样——“小模型猜，大模型验”

1. 基本流程（以大模型70B、小模型8B为例）
分3步，就像“学生猜答案，老师判对错”：

步骤	操作	为什么快？
1	小模型（8B）根据当前上下文，猜4个token（比如“今天天气”猜“很晴朗，适合”）	小模型简单，猜得快
2	大模型（70B）批量验证这4个token（一次看4个，不是逐个看）	大模型批量处理像预填充，比逐个生成快
3	大模型判断：对的token保留，错的token从错的地方重新生成	保证最终结果和大模型自己生成的一样

2. 为什么结果不会变？——数学保证的通俗解释
用“二选一”例子说明（比如模型只能生成A或B）：

大模型的真实概率

生成A的概率60%，B的40%；
小模型的猜测概率

生成A的概率80%（猜多了），B的20%（猜少了）；
修正逻辑

先算“猜多了多少”：A多猜了20%（80%-60%），B少猜了20%（40%-20%）；
验证时：小模型猜A时，有60%÷80%=75%的概率保留（对应大模型的真实概率）；猜B时，100%保留，再补上少猜的20%；

最终结果

生成A的概率还是60%，B还是40%，和大模型自己生成的完全一样。

3. 怎么让猜测更准？——2个扩展技巧
小模型猜得越准，大模型需要重新生成的次数越少，效率越高：

Medusa（多分支猜测）

小模型不只猜1条序列，而是猜4条（比如“今天天气很晴朗”“今天天气有点阴”等），大模型选最准的一条验证，猜对率从50%升到75%；
EAGLE（借大模型的“思路”）

小模型不单独训练，而是用大模型的中间结果当“提示”（比如用大模型第10层的输出），让小模型的猜测更贴近大模型的逻辑，猜对率从75%升到90%。

三、案例落地：70B大模型+8B小模型的效果

技术	小模型一次猜几个token	猜对率	生成1个token的时间	每秒生成token数	精度（和70B一致）
原始大模型（不猜）	-	-	0.03秒	2100	100%
基础推测性采样	4	50%	0.018秒	3500	100%
加Medusa（多分支）	4	75%	0.012秒	5200	100%
加EAGLE（借思路）	4	90%	0.009秒	6800	100%

四、小结

推测性采样是唯一“不丢精度”的优化技术，适合金融、医疗等对精度要求极高的场景；
效率提升的关键是“小模型猜对率”，Medusa（多猜几条）和EAGLE（借大模型思路）能大幅提高猜对率；
能在不影响结果的前提下，让大模型速度提升2-3倍。

第五章动态工作负载调度：解决实际场景的“乱”

一、预备知识：实际推理场景的3大“乱”象
实验室里“固定批量、固定长度”的推理场景不存在，实际应用中请求是“乱”的：

请求到得乱

比如0.1秒来1个请求，0.3秒来1个，0.5秒来8个，没法等所有请求到齐再处理；
请求长度乱

比如一个请求的提示是128个词，另一个是1024个词，按最长的填充会浪费内存；
请求有共享内容

比如10个请求都用“你是代码助手”当系统提示，重复存这部分的KV缓存会浪费内存。

二、核心内容：2种调度技术，让“乱”变“有序”

1. 连续批处理：不等请求到齐，来了就处理
传统“静态批处理”是“等所有请求到齐→处理完→再收下一批”，连续批处理改成“按步骤处理，动态加请求”：

通俗流程（以3个请求为例）

0.1秒：请求1到（提示128词），加入批次，开始处理提示；
0.3秒：请求2到（提示1024词），加入批次，和请求1一起处理提示；
0.5秒：请求1处理完提示，开始生成token；请求3到（提示512词），加入批次，处理提示；
0.7秒：请求1生成完10个token（完成，移除批次）；请求2和3开始生成token；
核心

：不等待，新请求来了就加，老请求完了就删，始终让硬件“满负荷”。

解决“长度乱”的技巧：选择性批处理

注意力层

不同长度的请求没法一起算，就单独算每个请求的注意力；
MLP层

把所有请求的中间结果拼在一起算（比如128词+1024词+512词，拼成1664词的长度），减少计算次数。

效果

请求平均等待时间减少40%，每秒处理的token数增加50%。

2. 分页注意力：像电脑存文件一样存KV缓存
传统KV缓存是“给每个请求分配一块连续的内存”，就像“给每个文件分配一块连续的硬盘空间”，会导致“碎片”（比如文件删了，留下小块空间用不了）；分页注意力借鉴电脑“分页存文件”的思路：

核心步骤

把KV缓存分成“小块”：比如每个小块存256个token的KV数据；
用“块表”记位置：每个请求的KV缓存不再是连续的，而是由多个小块组成，用“块表”记录这些小块在哪（比如请求2的KV缓存由块1、块3、块5组成）；
共享小块，省内存

如果多个请求共享系统提示（比如“你是代码助手”），就共享这部分的KV小块，要修改时再复制一份（叫“写时复制”）。

解决的问题

内部碎片

请求生成100个token，只用1个小块（256个token），不会浪费156个token的空间；
外部碎片

小块可以灵活组合，不会有“小块用不了”的情况；
共享内容

共享系统提示的KV小块，10个请求能省9份内存。

效果

KV缓存的内存利用率提升3-5倍，vLLM框架用这个技术，吞吐量比传统框架高10倍。

三、案例落地：vLLM的动态调度效果（64个请求）

调度技术	内存碎片率	请求平均等待时间	每秒生成token数	能同时处理的最大请求数
静态批处理+传统KV	50%	1.2秒	1800	32
连续批处理+传统KV	50%	0.72秒	2700	48
连续批处理+分页注意力	10%	0.58秒	5400	128

四、小结

连续批处理解决“请求到得乱”的问题，核心是“动态调整批次，不等待”；
分页注意力解决“内存碎片”和“共享内容”的问题，核心是“小块存储+共享”；
两者结合是工业界的主流方案（比如vLLM、NVIDIA Tensor-RT-LLM），能让推理系统适配实际场景的“乱”。

第六章总结：怎么选优化技术？未来方向是什么？

一、优化技术选择指南（按场景选）

核心需求	推荐技术组合	适用场景例子
高精度（不能错）	推测性采样 + 连续批处理 + 分页注意力	金融分析、医疗诊断
低延迟（要快）	GQA + AWQ + Mamba	实时聊天、语音转文字
省内存（设备差）	剪枝 + 蒸馏 + int4量化	手机APP、嵌入式设备
高并发（多请求）	连续批处理 + 分页注意力 + GQA	API服务（比如给企业提供调用）
长文本（提示长）	MLA + 分页注意力 + 扩散模型	文档摘要、长对话