大模型基础扫盲------从文本到 Token、Embedding、QKV 与 Transformer 大模型处理文本的全流程解析（一）-CSDN博客

大模型基础扫盲------从文本到 Token、Embedding、QKV 与 Transformer（不定期优化修改）大模型处理文本的全流程解析（二）-CSDN博客

大模型基础扫盲------从文本到 Token、Embedding、QKV 与 Transformer（不定期优化修改）大模型处理文本的全流程解析（三）-CSDN博客

17. 推理优化：KV Cache、Prefill、Decode

17.1 推理的两个阶段

自回归推理通常分为两个阶段。

MLOps 视角：

优化 Prefill 主要靠：

GPU 算力，FLOPS

优化 Decode 主要靠：

显存带宽，memory bandwidth

这也是为什么 Decode 阶段经常是推理服务瓶颈。

17.2 KV Cache 的原理

没有 KV Cache 时：

生成第 1000 个 token 时， 需要重新计算 token 1~999 的 K、V。

有 KV Cache 时：

把前面 token 的 K、V 缓存起来。 生成第 1000 个 token 时， 只计算 token 1000 的 Q、K、V， 然后让新的 Q 去和缓存中的 K、V 做注意力。

收益：

大幅减少重复计算，提高生成速度。

代价：

占用额外显存。

17.3 KV Cache 显存估算

通用公式：

KV Cache 显存 = 2 × num_layers × num_kv_heads × head_dim × seq_len × bytes_per_param × batch_size

其中：

2 代表 K 和 V 两份。 num_kv_heads 是 KV 头数，不是 Q 头数。 bytes_per_param 通常是 2，对应 FP16/BF16。

示例：Mistral-7B 风格配置

假设：

num_layers = 32 num_kv_heads = 8 head_dim = 128 seq_len = 4096 dtype = BF16，每参数 2 bytes

单条序列：

2 × 32 × 8 × 128 × 4096 × 2 = 536,870,912 bytes ≈ 0.5 GB

如果：

batch_size = 32

则：

0.5 × 32 = 16 GB

如果某个模型是 4 个 KV heads，那么同样条件下大约是：

0.25 GB / 单条序列

注意：

不同模型的 KV 头数差异很大。
做容量规划时，务必以目标模型config.json中的：

num_key_value_heads

为准，不要凭记忆估算。

17.4 vLLM 的 PagedAttention

传统方式：

为每个请求预分配最大长度的连续 KV Cache 显存。

问题：

大量显存被浪费。

PagedAttention：

把 KV Cache 切成固定大小的“页”，按需分配。

类似操作系统的虚拟内存分页。

你做过容器，对“分页”概念不会陌生。
PagedAttention 就是把 OS 虚拟内存思想用到 GPU 显存管理上。

17.5 连续批处理，Continuous Batching

传统批处理：

等一批请求全到齐。 一起推理。 一起返回。

问题：

短请求要等长请求，浪费吞吐。

连续批处理：

某个请求生成完毕就立刻移出。 新请求立刻插入。

好处：

GPU 利用率更高。 在线服务吞吐更好。

17.6 KV Cache 的更精确估算方式

KV Cache 的通用估算公式是：

KV Cache 显存 = 2 × num_layers × num_kv_heads × head_dim × cached_tokens × bytes_per_element

其中：

2 表示 K 和 V 两份。 num_layers 是 Transformer 层数。 num_kv_heads 是 KV 头数，不是 Q 头数。 head_dim 是每个注意力头的维度。 cached_tokens 是当前已经缓存的 token 数量。 bytes_per_element 是每个元素占用的字节数。

常见精度：

FP16 / BF16：2 bytes FP8：1 byte INT8：1 byte，具体取决于实现

如果是 batch 推理：

cached_tokens不应该简单理解成：

batch_size × max_seq_len

更准确地说，应该是所有请求当前已缓存 token 数的总和：

cached_tokens = sum( prompt_len_i + generated_len_i )

也就是：

KV Cache 显存 = 2 × num_layers × num_kv_heads × head_dim × sum(prompt_len_i + generated_len_i) × bytes_per_element

举例：

假设：

num_layers = 32 num_kv_heads = 8 head_dim = 128 dtype = BF16，每个元素 2 bytes

一条请求缓存 4096 个 token：

2 × 32 × 8 × 128 × 4096 × 2 = 536,870,912 bytes ≈ 0.5 GB

如果有 32 条请求，每条都缓存 4096 个 token：

0.5 GB × 32 = 16 GB

但如果这些请求共享相同 system prompt，并且推理框架支持 prefix caching，那么公共前缀的 KV Cache 可以共享。

例如 32 条请求都有 2048 个 token 的相同 system prompt。
这部分理论上可以只存一份，或者通过页表共享。

MLOps 视角：
KV Cache 是推理显存的大头之一。
尤其是在长上下文和高并发场景下，KV Cache 往往比模型权重更容易成为瓶颈。

所以部署时要重点关注：

num_key_value_heads max_model_len batch size prompt 长度 输出长度 是否开启 prefix caching 是否使用 FP8 KV Cache 是否使用 PagedAttention

17.7 PagedAttention 和操作系统分页的关系

你做过容器和运维，对虚拟内存、分页、按需分配这些概念不会陌生。

传统 KV Cache 分配方式类似：

给每个请求预分配一段连续显存。 即使这个请求最后只用了一半长度， 剩下的显存也可能被浪费。

这很像早期连续内存分配的问题：

内存碎片严重 利用率低 无法灵活扩容

PagedAttention 的做法类似操作系统虚拟内存分页：

把 KV Cache 切成固定大小的 block。 每个 block 可以存固定数量 token 的 K、V。 请求需要多少 block，就分配多少 block。 不要求物理显存连续。 通过页表或 block table 管理逻辑块和物理块的映射。

好处：

减少显存碎片。 提高 batch size。 提升 GPU 吞吐。 更容易实现 prefix caching。

在 vLLM 中，你会经常看到类似概念：

block_size block table physical block logical block copy-on-write prefix caching

这些本质上都是显存管理优化。

MLOps 视角：
如果你要部署高并发 LLM 服务，PagedAttention 几乎是必学内容。
因为它直接影响：

吞吐 显存利用率 首 token 延迟 长文本支持能力

18. 显存估算：从原理到工程

18.1 推理显存估算公式

推理时的显存消耗通常包括四部分：

1. 模型权重 2. KV Cache 3. 激活值 4. 临时缓冲和碎片

粗略公式：

推理显存 ≈ 模型权重 + KV Cache + 激活值 + 临时缓冲

模型权重估算：

weights_memory ≈ param_count × bytes_per_param

例如：

7B 模型，BF16： 7,000,000,000 × 2 bytes ≈ 14 GB

KV Cache 估算：

kv_memory = 2 × num_layers × num_kv_heads × head_dim × cached_tokens × bytes_per_element

激活值：

激活值和以下因素强相关：

batch_size seq_len hidden_size 推理框架的算子实现 是否使用 CUDA Graph 是否使用算子融合

临时缓冲：

通常建议预留 10%~20% 的额外空间。

所以在生产环境中，不能只算模型权重。

例如一张 24GB 显卡：

能装下 14GB 的 7B BF16 权重， 不代表能稳定跑 7B 长上下文服务。

因为 KV Cache 和激活值还会继续吃显存。

18.2 训练显存估算

训练显存比推理复杂得多。

全参数训练时，通常要考虑：

1. 模型权重 2. 梯度 3. 优化器状态 4. 激活值 5. 通信缓冲区 6. 临时 buffer

以常见的 BF16 训练 + AdamW 为例：

模型权重：BF16，约 2 bytes/param 梯度：BF16，约 2 bytes/param AdamW 优化器状态： FP32 master weights：4 bytes/param FP32 first moment：4 bytes/param FP32 second moment：4 bytes/param

合计：

2 + 2 + 4 + 4 + 4 = 16 bytes/param

所以：

全参数训练显存粗略估算 ≈ param_count × 16 bytes + 激活值 + 通信缓冲区 + 临时 buffer

例如：

7B 模型： 7,000,000,000 × 16 bytes ≈ 112 GB

这还没有算激活值。

所以朴素单卡全参数训练 7B，经常会超过 100GB 显存。

这就是为什么实际工程中经常使用：

ZeRO FSDP DeepSpeed activation checkpointing 8-bit Adam LoRA QLoRA 参数高效微调

MLOps 视角：
如果你要做微调平台，不能只问用户“模型多大”。
还要问：

是否全参数训练 是否使用 LoRA 序列长度多少 batch size 多少 是否开启 gradient checkpointing 优化器是什么 精度是什么 是否多机多卡 通信后端是 NCCL 还是其他

这些都会直接影响显存和集群资源规划。

另外，16 bytes/param是常见混合精度 AdamW 的粗略估算，具体框架和实现可能略有差异。

19. Padding Mask 与特殊 Token

19.1 Padding Mask

训练时多个句子组成 batch，长度可能不一样。

为了组成矩阵，需要补齐。

例如：

seq1: 我 吃 鱼 seq2: 你 看 [PAD]

对应 attention mask 可能写成：

[ [1, 1, 1], [1, 1, 0] ]

其中：

1 表示可以关注 0 表示屏蔽

[PAD]位置不应被关注，所以需要 padding mask 屏蔽。

19.2 特殊 Token

常见特殊 token：

注意：

采用字节级分词的模型通常能表示任意 UTF-8 文本， 所以通常不会因为罕见字符直接失败。 但具体是否保留 <unk>，以及有哪些 special token， 要以模型 tokenizer 配置为准。

19.3 chat template 必须正确

现在大量开源模型都是 chat 模型。
chat 模型通常有自己的对话模板。

例如：

system user assistant

不同模型的模板可能完全不同。

正确做法是：

tokenizer.apply_chat_template()

而不是自己手拼字符串。

例如伪代码：

messages = [ {"role": "system", "content": "你是一个运维专家。"}, {"role": "user", "content": "请解释 KV Cache。"} ] prompt = tokenizer.apply_chat_template( messages, tokenize=False, add_generation_prompt=True )

MLOps 视角：
chat template 错误是非常常见的生产事故。

可能导致：

模型角色混乱 输出格式错误 无法正常停止 重复输出 user prompt 工具调用失败 多轮对话上下文错乱

部署前一定要检查：

tokenizer_config.json

重点关注：

chat_template eos_token bos_token pad_token additional_special_tokens

如果模型支持 tool calling，还要检查 tool 相关 token 和格式说明。

20. 常见误解

21. 全文总结

21.1 核心概念速查表

21.2 最简流程图

原始文本 ↓ Tokenizer ↓ tokens ↓ token ids ↓ Embedding ↓ 位置信息注入 ├── 绝对位置编码：加到 embedding └── RoPE：在 Attention 内旋转 Q/K ↓ Transformer Block × N ├── RMSNorm ├── Attention │ ├── Q/K/V 投影 │ ├── QK^T / sqrt(d_k) │ ├── causal mask │ ├── softmax │ └── 加权 V ├── 残差连接 ├── RMSNorm ├── FFN / SwiGLU └── 残差连接 ↓ 最后一个位置的 hidden state ↓ LM Head ↓ logits ↓ softmax ↓ 下一个 token 概率分布 ↓ 采样 / greedy / top-k / top-p ↓ 生成下一个 token

21.3 一句话总结增强版

如果用一句话概括现代 LLM：

Tokenizer 把文本变成 token， Embedding 给 token 一个初始语义坐标， 位置编码告诉模型 token 的顺序， Transformer 通过 Attention 和 FFN 逐层构造上下文语义， LM Head 最终输出下一个 token 的概率分布。

也就是说：

模型不是简单查表。 模型是在海量文本上训练出来的、 能够根据上下文预测下一个 token 的概率函数。

22. 完整例子：从“我吃鱼”到模型输出

假设输入：

我吃鱼

第一步：分词器切分

可能切成：

我 / 吃 / 鱼

第二步：查 token id

得到：

[2513, 1892, 3765]

注意：这些 id 只是示例。

第三步：查 embedding

得到：

X = [A, B, C]

第四步：位置信息

如果是绝对位置编码：

我：A + position_1 吃：B + position_2 鱼：C + position_3

如果是 RoPE：

此时不直接加位置向量。 后面 Attention 中会对 Q/K 做旋转。

第五步：生成 Q、K、V

每个 token 向量都会经过三副“滤镜”：

Q = X W_Q K = X W_K V = X W_V

得到：

第六步：计算注意力分数

如果是自回归模型，需要加因果掩码。

处理“吃”时，它只能看到：

我、吃

不能看到后面的：

鱼

所以“吃”的 Query：

q^(2)

只能和：

k^(1), k^(2)

计算注意力，不能和：

k^(3)

计算。

这一点很重要：

在自回归模型中， “吃”在这个位置还不知道后面是“鱼”。 它只知道前面是“我”。

第七步：softmax 变权重

假设在自回归模型中，处理“吃”时得到：

第八步：加权 V

“吃”的新向量：

output^(2) = 0.60 · v^(1) + 0.40 · v^(2) + 0.00 · v^(3)

这样，“吃”融合了前文信息：

谁在吃：我

但此时它还不知道吃的是什么，因为在自回归模型中它不能看到后面的“鱼”。

第九步：多头输出经过 W_O

如果有多个头，每个头都会得到一个输出。

这些输出会被拼接，然后经过输出投影矩阵W_O映射回模型主维度。

例如：

[head_1, head_2, ..., head_32] → concat → W_O → 4096 维

第十步：残差连接和归一化

注意力输出通常会和原始输入做残差连接，再进行归一化。

以 Pre-LN 风格为例：

X_1 = X + Attention(RMSNorm(X))

以 Post-LN 风格为例：

X_1 = LayerNorm(X + Attention(X))

具体顺序因模型而异。

第十一步：进入 FFN

然后进入 FFN：

X_2 = X_1 + FFN(RMSNorm(X_1))

FFN 会对每个 token 的表示做进一步非线性加工。

可以理解为：

Attention 像查资料。 FFN 像自己消化总结。

第十二步：经过多层 Transformer

注意力、FFN、残差、归一化组成一个 Transformer block。

实际模型会堆叠很多层，比如：

32 层 40 层 80 层

经过多层之后，每个位置的向量都会包含更丰富的上下文信息。

第十三步：模型预测下一个 token

最后一层输出的向量经过 LM Head：

logits = h_last · W_LM_Head

再经过 softmax：

probs = softmax(logits)

如果输入是：

我 吃

模型需要预测下一个 token。

它可能输出：

如果生成策略选择概率最高的 token，就会输出：

鱼

最终得到：

我吃鱼

23. 给 MLOps 学习者的下一步

23.1 主流推理框架选型指南

学习原理之后，最终要落到部署和优化。

常见主流推理框架包括：

vLLM TGI，Text Generation Inference SGLang TensorRT-LLM

它们的侧重点不同。

vLLM

核心优势：

PagedAttention 高吞吐 显存利用率高 适合通用在线推理服务

适合场景：

高并发 chat 服务 通用文本生成 对吞吐要求高的场景

TGI

核心优势：

生产功能完整 监控和部署生态成熟 支持多种量化和 LoRA 适合企业级部署

适合场景：

企业生产环境 需要较完整服务能力 需要 HuggingFace 生态集成

SGLang

核心优势：

结构化输出强 适合 Agent、tool calling、JSON schema RadixAttention 对共享前缀和多轮对话友好

适合场景：

Agent 系统 工具调用 结构化生成 复杂 prompt 复用

TensorRT-LLM

核心优势：

NVIDIA GPU 上深度优化 kernel 级别优化多 适合追求极致性能

适合场景：

对延迟和吞吐要求非常高 团队具备较强 CUDA / 推理引擎能力

MLOps 视角：
不要只问“哪个框架最快”。
要结合业务场景看：

是否需要长上下文 是否需要高并发 是否需要结构化输出 是否需要 tool calling 是否需要多 LoRA 热切换 是否需要 prefix caching GPU 型号是什么 显存大小是多少 延迟指标是 TTFT 还是 TPOT 运维团队是否能维护复杂引擎

选型不是技术炫技，而是业务约束下的工程折中。

另外，推理框架生态更新很快，最终以当前版本功能和实测 benchmark 为准。

23.2 实战实验室：从原理到工程

建议你按顺序做下面几个实验。

实验 1：读取模型配置，理解模型结构

目标：

学会看 config.json。

任务：

找一个开源模型，例如 Qwen、LLaMA、Mistral 系列。
找出以下字段：

hidden_size num_hidden_layers num_attention_heads num_key_value_heads intermediate_size vocab_size max_position_embeddings rope_theta rope_scaling tie_word_embeddings torch_dtype

然后回答：

这个模型有多少层？ 主维度是多少？ 每个 head 维度是多少？ KV Cache 用几个 head？ FFN 中间维度是多少？ 词表大小是多少？ 是否绑定 embedding 和 LM Head？

实验 2：手工估算 KV Cache

目标：

掌握推理显存大头。

任务：

假设：

num_layers = 32 num_kv_heads = 8 head_dim = 128 seq_len = 8192 dtype = BF16

计算单条请求的 KV Cache 显存。

公式：

KV Cache = 2 × num_layers × num_kv_heads × head_dim × seq_len × bytes

然后把seq_len改成：

4096 8192 32768 131072

观察显存变化。

参考结果：

4096 ≈ 0.5 GB 8192 ≈ 1 GB 32768 ≈ 4 GB 131072 ≈ 16 GB

实验 3：用 vLLM 部署一个模型

目标：

理解推理服务启动参数。

重点观察：

max_model_len tensor_parallel_size gpu_memory_utilization max_num_seqs enable_prefix_caching dtype quantization

记录：

启动显存占用 首 token 延迟 TTFT 生成速度 tokens/s 并发增加时吞吐变化

实验 4：对比 Prefill 和 Decode

目标：

理解推理两阶段瓶颈。

方法：

构造不同 prompt 长度：

短 prompt，长输出 长 prompt，短输出 长 prompt，长输出

观察：

TTFT 是否明显变长？ TPOT 是否稳定？ GPU 利用率如何？ 显存占用如何变化？

实验 5：LoRA 微调显存对比

目标：

理解参数高效微调。

任务：

用同一模型分别做：

全参数训练 LoRA QLoRA

对比：

显存占用 训练速度 可训练参数量 checkpoint 大小 部署复杂度

这些实验做完后，你会从“知道原理”进入“能做工程落地”。

24. MLOps 部署前检查清单

24.1 模型配置检查

hidden_size num_hidden_layers num_attention_heads num_key_value_heads head_dim intermediate_size vocab_size max_position_embeddings rope_scaling tie_word_embeddings

24.2 显存检查

模型权重显存 KV Cache 显存 激活值显存 临时缓冲 并发请求下的峰值显存 长上下文下的峰值显存

24.3 推理服务检查

TTFT TPOT tokens/s max_batch_size max_model_len gpu_memory_utilization 是否开启 prefix caching 是否开启 continuous batching 是否使用 PagedAttention 是否使用量化

24.4 Tokenizer 检查

vocab_size special tokens chat_template stop tokens 是否支持 tool calling 是否支持多语言 是否支持代码

24.5 长文本检查

训练长度是多少 推理长度是多少 是否配置 rope_scaling 是否做过长文本评测 是否存在注意力退化

24.6 训练 / 微调检查

是否全参数训练 是否 LoRA 是否 QLoRA 优化器状态显存 激活值显存 梯度累积 序列长度 batch size 是否 gradient checkpointing

只要每次部署模型前过一遍这个清单，很多显存 OOM、效果异常、无法停止、长文本退化问题，都可以提前发现。

最后一句话

大模型就是一个“预测下一个 token”的函数：

把文本变成向量， 经过几十层注意力和前馈网络加工， 输出词表上的概率分布， 再选出或采样出最可能的下一个 token。

所有参数，包括：

embedding Q/K/V W_O FFN 归一化参数 LM Head

都是通过海量文本上的“预测下一个 token”任务训练出来的。