📌 待查★ 重要
FDE Day 1 学习手册 · 大模型核心基础
W1 Day1 · A 级(必须掌握,面试核心)· 4h · 学完能讲透"一次模型请求的来龙去脉"
本日定位:这是整个 8 周的地基。后面 RAG、Agent、模型网关、Trace 成本,全部建立在这些概念之上。面试官考察"你是不是真懂大模型",第一刀就砍在这里。
学完能回答:① 一次 API 请求从发出到返回 token 的完整过程;② 上下文长度、延迟、成本三者关系;③ 为什么长上下文贵、为什么 Decode 慢、推理模型和普通模型怎么选。
使用方法:先通读理解原理 → 重点看每节「面试话术」和「易错点」→ 做末尾自测清单 → 配合《Day1 评测题.md》自测。
一、Transformer 总体架构
1.1 为什么会有 Transformer
在 Transformer 之前,序列建模主要靠 RNN/LSTM。RNN 的致命问题有两个:
- 串行计算:第 t 步依赖第 t-1 步的隐状态,无法并行,训练慢。
- 长距离依赖弱:信息要一步步传递,远处的信号会被稀释或遗忘。
Transformer(2017,《Attention is All You Need》)用 Self-Attention 替代循环结构:任意两个 token 之间一步直达,距离为 O(1),且整个序列可以并行计算。这是大模型能训到千亿参数的技术前提。
1.2 整体结构:Encoder-Decoder → Decoder-only
原始 Transformer 是 Encoder-Decoder 结构(用于翻译)。但 GPT 之后,主流大模型(Qwen、DeepSeek、LLaMA、Claude)几乎都采用 Decoder-only 结构。
| 结构 | 代表 | 特点 |
| Encoder-only | BERT | 双向注意力,适合理解任务(分类、检索),不擅长生成 |
| Encoder-Decoder | T5、原始 Transformer | 编码器理解输入,解码器生成输出,适合翻译/摘要 |
| Decoder-only | GPT / Qwen / DeepSeek / LLaMA | 单向因果注意力,统一"接龙"范式,生成+理解通吃 |
1.3 Decoder-only 为什么成为主流
- 统一范式:所有任务都归约为"给定上文,预测下一个 token",一个架构通吃翻译、问答、写代码、Agent。
- 训练效率高:因果注意力 + teacher forcing,每个位置都能提供监督信号,样本利用率高。
- Scaling Law 友好:参数和数据规模上去后,能力持续提升,没有明显的架构瓶颈。
- 推理简单:自回归生成,KV Cache 加速天然契合。
1.4 一个 token 在 Transformer 里经历了什么
一个 token 进入模型后,要穿过 N 个相同的 Transformer Block(N 叫层数/depth,如 32 层)。每个 Block 包含:
输入 token 向量→
LayerNorm→
Self-Attention→
残差相加→
LayerNorm→
FFN 前馈网络→
残差相加→
输出给下一层
关键细节:
- 残差连接(Residual):输入直接加到输出上,缓解深层网络梯度消失,让模型可以训得很深。
- LayerNorm:对每个 token 的向量做归一化,稳定训练。现代模型多用 Pre-Norm(先归一化再进 Attention/FFN)。
- FFN(前馈网络):两层全连接 + 激活(如 SwiGLU),是模型"记忆知识"的主要载体,参数量占整个模型约 2/3。
- Attention 负责"信息混合"(token 之间交流),FFN 负责"知识变换"(每个 token 独立加工)。
Decoder-only 用"预测下一个 token"这一个目标,就把理解、生成、推理全学会了。架构统一带来工程红利:一套推理引擎、一套 KV Cache、一套 Scaling Law,适用于所有任务。面试时如果被问"为什么不用 Encoder-Decoder",核心答"统一范式 + 训练效率 + Scaling"。
不要把"Attention 就是模型全部"。Attention 只占参数量约 1/3,FFN 占 2/3。Attention 负责 token 间信息流动,FFN 才是知识存储。很多人误以为大模型全靠 Attention,这是错的。
二、Self-Attention 机制
2.1 直觉:每个 token "看" 所有其他 token
在处理"医疗保险理赔"时,"理赔"这个 token 要理解自己的含义,需要知道前面是"医疗保险"而不是"车辆保险"。Self-Attention 让序列中每个 token 直接和所有 token 计算相关性,加权聚合信息,生成一个"融入了上下文"的新表示。
2.2 Q / K / V 的物理含义
每个 token 的向量通过三个不同的权重矩阵投影成三个向量:
- Q(Query,查询):当前 token 想找什么样的信息。相当于"我在找什么"。
- K(Key,键):当前 token 能提供什么样的信息。相当于"我有什么"。
- V(Value,值):当前 token 实际提供的内容。
类比检索:Q 是搜索词,K 是文档标题/关键词,V 是文档正文。用 Q 去和所有 K 算相似度,得到权重,再对 V 加权求和,就得到了"最相关的信息聚合"。
2.3 计算公式
Attention(Q, K, V) = softmax( Q · KT / √dk ) · V
步骤拆解:
Q · KT:每个 token 的 Q 和所有 token 的 K 做点积,得到 n×n 的注意力分数矩阵(n 是序列长度)。
/ √dk:缩放,除以 Key 向量维度的平方根。
softmax:对每一行归一化,变成概率分布(加起来为 1),表示当前 token 对其他 token 的关注度。
· V:用这个注意力权重对 V 加权求和,得到每个 token 的新表示。
2.4 为什么要除以 √dk(缩放)
这是高频面试题。当 dk 较大时,Q·KT 的点积值会变大(点积是 dk 个乘积之和,方差随 dk 线性增长)。点积过大会让 softmax 进入饱和区——输出接近 one-hot(一个接近 1,其余接近 0),导致:
- 梯度几乎为 0,训练停滞。
- 注意力过度集中在单个 token 上,失去"软"加权的能力。
除以 √dk 把点积的方差控制在 1 左右,让 softmax 工作在敏感区间。一句话:缩放是为了稳定训练,防止 softmax 饱和。
2.5 Causal Mask(因果掩码)
Decoder-only 是自回归生成,当前 token 只能看它前面的 token,不能看后面的(否则就"偷看答案"了)。实现方式是在注意力分数矩阵上加一个下三角掩码:把上三角(未来位置)置为 -∞,softmax 后这些位置变成 0。
Mask = [
0 -∞ -∞ -∞
0 0 -∞ -∞
0 0 0 -∞
0 0 0 0
]
这就是"因果注意力"(Causal Attention),也叫单向注意力。它是 Decoder 能自回归生成的根本保证。
Q 是"我要找什么",K 是"我能提供什么",V 是"我实际的内容"。Q·KT 算相关性,softmax 变权重,乘 V 做加权聚合。除以 √dk 是为了防止点积过大让 softmax 饱和、梯度消失。Decoder-only 还要加因果掩码,让每个 token 看不到未来的 token。
① Q、K、V 不是模型自带的,而是同一个输入向量经三个不同的可学习权重矩阵投影得到的,所以同一个 token 作为 Query 和作为 Key 时的"身份"不同。② "Self-Attention"的"Self"指 Q/K/V 来自同一个序列,不是来自外部。Cross-Attention(Encoder-Decoder 里)才是 Q 来自一个序列、K/V 来自另一个序列。
三、Multi-Head Attention 与 MQA/GQA
3.1 为什么要多头
单头 Attention 只能学一种关注模式。但语言里关系是多样的:一个 token 可能同时要关注"语法主谓宾"、"指代消解"、"语义相似"、"位置相邻"等不同关系。Multi-Head 把这能力拆成多个"头",每个头在不同的子空间学习不同的关注模式,最后拼回来。
3.2 多头怎么算
把 dmodel 维向量拆成 h 个头,每个头维度 dhead = dmodel / h。每个头独立做 Attention,最后 concat 后再过一个线性层融合。
MultiHead(Q,K,V) = Concat(head1, ..., headh) · WO
其中 headi = Attention(Q·WiQ, K·WiK, V·WiV)
注意:多头不是把计算量乘以 h,而是把 dmodel 拆开,总计算量基本不变(略有投影开销)。这是"用同样的算力换更强的表达力"。
3.3 头数的影响
- 头多:能学更多样的关系模式,但每个头维度变小,单头表达能力下降;投影参数增加。
- 头少:每个头维度大,表达强,但关系模式种类受限。
- 实践中 dhead 常取 64 或 128,是经验上的甜点。
3.4 MQA 与 GQA:现代模型省显存的关键
这是 2023 年后的重要演进,直接影响 KV Cache 显存和推理成本,面试加分项。
| 变体 | Q 头数 | K/V 头数 | KV Cache 显存 | 代表 |
| MHA(标准多头) | h | h | 基准 | 原始 Transformer |
| MQA(多查询注意力) | h | 1 | 1/h | PaLM、StarCoder |
| GQA(分组查询注意力) | h | g(中间值) | g/h | LLaMA-2/3、Qwen2 |
核心思想:Q 保持多头(保证表达力),但多个 Q 头共享同一组 K/V。因为 KV Cache 存的是 K 和 V,减少 K/V 头数就能直接减少缓存显存,让同样显存能支撑更大的 batch 和更长的上下文。GQA 是 MHA 和 MQA 的折中,效果接近 MHA、显存接近 MQA,成为主流。
你在做模型网关、选 vLLM 部署时,GQA 模型(如 Qwen2、LLaMA-3)的 KV Cache 显存只有 MHA 模型的 1/4 ~ 1/8,同样 GPU 能服务更多并发、更长上下文。这是选型时要看的硬指标——看模型的 n_kv_heads(K/V 头数)而不是只看总参数量。
多头是为了让模型在不同子空间学习不同的关注关系。现代模型用 GQA(Q 多头、K/V 分组共享),在几乎不损失效果的情况下大幅减少 KV Cache 显存。面试说到这层会显得你懂最新工程趋势。
不要说"多头就是多个 Attention 叠加"。多头是并行拆分,不是串行叠加;总维度守恒,计算量基本不变。另外 GQA 不是"随便共享",而是相邻的几个 Q 头共享一组 K/V,是有分组的。
四、Token / Tokenizer / Embedding / 位置编码
4.1 Token 是什么
Token 是模型处理文本的最小单位,既不是"词"也不是"字",而是介于两者之间的"子词"(subword)。比如 "unhappiness" 可能被切成 ["un", "happiness"] 或 ["un", "happ", "iness"]。中文"医疗保险"可能被切成 ["医疗", "保险"] 或 ["医", "疗", "保", "险"],具体看 tokenizer。
为什么用子词而不是词/字:
- 用词:词表巨大(几十万),且无法处理新词、拼写错误。
- 用字/字符:序列太长,且单字缺少语义。
- 子词(BPE 等):高频词整体保留,低频/新词拆成子词,词表适中(3万-15万),兼顾效率和泛化。
4.2 主流 Tokenizer
| 算法 | 原理 | 代表 |
| BPE(Byte Pair Encoding) | 从字符级开始,反复合并语料中出现频率最高的相邻字节对 | GPT 系列、Qwen、LLaMA |
| WordPiece | 类似 BPE,但合并依据是似然增益而非频率 | BERT |
| SentencePiece | 把文本当原始字节流处理,不依赖空格分词,对中日韩友好 | LLaMA、T5 |
| Tiktoken | OpenAI 的高效 BPE 实现(cl100k_base 等) | GPT-3.5/4 |
注意:不同模型的 tokenizer 不通用,token 数不能跨模型直接换算。"医疗保险理赔"在 Qwen、DeepSeek、Claude 上的 token 数可能都不一样。这也是为什么调用不同 API 要用各自的 tokenizer 计费。
4.3 BPE 工作原理(简版)
- 初始词表 = 所有单字符(或字节)。
- 统计语料中所有相邻 token 对的出现频率。
- 把频率最高的对合并成一个新 token,加入词表。
- 重复 2-3,直到词表达到目标大小(如 5 万)。
编码新文本时,按学到的合并规则贪心地切分。高频词会作为整体保留,低频/未见词被拆成已知子词,永远不会出现"无法表示"的词(OOV 问题被解决)。
4.4 Embedding:从 token id 到语义向量
tokenizer 把文本变成一串整数 id(如 [1234, 5678, ...]),但整数没有语义。Embedding 层是一个查找表(矩阵),把每个 id 映射成一个 dmodel 维向量(如 4096 维)。这个向量在训练中学习,最终让语义相近的 token 在向量空间里距离也近。
Embedding 是模型"理解语言"的起点——后面所有 Attention、FFN 都在这个向量空间里操作。可以说大模型的所有能力,都建立在这个学到的语义空间之上。
4.5 位置编码:为什么 Transformer 需要它
Self-Attention 本身是顺序无关的——打乱 token 顺序,Attention 结果只是重新排列,不会"知道"顺序错了。但语言顺序至关重要("狗咬人" vs "人咬狗")。所以必须额外把位置信息注入 token 向量,这就是位置编码。
- 绝对位置编码(原始 Transformer、GPT-2):用 sin/cos 函数生成固定位置向量,加到 embedding 上。
- 可学习位置编码(BERT、早期 GPT):位置向量也是可学习参数。
- RoPE 旋转位置编码(LLaMA、Qwen、DeepSeek,当前主流):不直接加到向量上,而是在 Q 和 K 上施加旋转,让 Q·KT 的结果只依赖两个 token 的相对距离。好处是天然支持相对位置、易于长度外推(用 YaRN 等技术可扩展到更长上下文)。
RoPE 是现代大模型的标配。理解它能解释"为什么有的模型能扩到 128K/1M 上下文"——通过 RoPE 插值/外推。面试若被问"长上下文怎么做出来的",要提到位置编码外推(NTK-aware、YaRN)+ KV Cache 优化,而不是只说"训练数据变长"。
4.6 中英文 token 差异(实操)
同样意思的文本,英文比中文省 token(因为 BPE 对英文训练数据多,合并得更整)。粗略经验:
- 英文:1 token ≈ 4 个字符 ≈ 0.75 个单词。
- 中文:1 个汉字常占 1-2 个 token(看模型,Qwen 对中文优化较好,可能 1 字 ≈ 0.6-1 token)。
结论:中文场景的 token 成本和上下文消耗比英文高,做 RAG 时 chunk 大小、prompt 长度都要按实际 tokenizer 实测,不能照搬英文经验值。估算要用对应模型的 tokenizer(如 tiktoken 对 OpenAI,Qwen 用自己的),不能用字符数 ÷ 4 去套。
Token 是子词单元,不是词不是字;不同模型 tokenizer 不通用,token 数不能跨模型换算。Embedding 把 id 变成语义向量,是模型理解语言的起点。Transformer 本身不感知顺序,靠位置编码注入顺序信息,现代模型主流用 RoPE(旋转位置编码),支持相对位置和长度外推。
① 不要说"1 个汉字 = 1 个 token"或"1 个英文单词 = 1 个 token",必须实测。② token 数直接影响 API 计费和上下文占用,做成本估算和 RAG chunk 切分时一定要用目标模型的 tokenizer 实测,否则预算和效果都会偏。③ 位置编码不是"可有可无",没有它 Transformer 会把"狗咬人"和"人咬狗"当一回事。
五、上下文窗口
5.1 定义
上下文窗口(Context Window)是模型一次能处理的输入 + 输出 token 总上限。例如 Qwen2-72B 上下文 128K,意味着 prompt + 生成内容合计不能超过 128K token。超出会报错或被截断。
5.2 为什么有上限
- 计算量 O(n²):Self-Attention 的注意力矩阵是 n×n,序列翻倍计算量变 4 倍。长上下文 Prefill 计算量爆炸。
- KV Cache 显存:序列越长,缓存的 K/V 越多,显存线性增长(详见第六节)。
- 训练长度限制:模型训练时见过的最长序列有限,超出后效果会下降(虽然 RoPE 外推能缓解,但有上限)。
5.3 长上下文的三个代价
① 计算代价(Prefill):Attention 是 O(n²),prompt 从 4K 涨到 128K,Prefill 计算量涨 1024 倍。这是长上下文 TTFT(首 token 延迟)高的根本原因。
② 显存代价(KV Cache):每多 1K token,KV Cache 多占一份显存。128K 上下文单请求的 KV Cache 可能几 GB,导致单卡能并发的请求数大幅下降。
③ 效果代价(Lost in the Middle):研究表明模型对超长上下文中间的信息利用率低——开头和结尾记得清楚,中间容易"看不到"。这是 RAG 仍要做的理由:把相关内容精准放到开头,比塞满长上下文更有效。
5.4 超出窗口怎么办
- 截断:扔掉超出部分(早期 API 默认行为,会丢信息)。
- 报错:直接拒绝请求(多数现代 API)。
- 滑窗 / 压缩:自己实现摘要、滑窗、检索,只把相关内容放进窗口——这正是 RAG 的价值。
5.5 长上下文 vs RAG(关键选型判断)
| 维度 | 长上下文(塞满 128K) | RAG(检索后喂小窗口) |
| 成本 | 高(每次都付 128K input 费) | 低(只付检索到的几 K) |
| 延迟 | 高(Prefill 慢) | 低 |
| 知识量 | 受窗口限制 | 几乎无限(知识库可很大) |
| 准确性 | 中间易丢信息 | 精准定位(有引用) |
| 更新 | 每次重传全部 | 改知识库即可 |
结论:长上下文不是 RAG 的替代,而是补充。企业知识库该用 RAG(可更新、可引用、可控成本),长上下文适合"一次性分析单个长文档"场景。
上下文窗口是输入+输出的 token 总上限,受 O(n²) 计算量、KV Cache 显存、训练长度三重限制。长上下文贵且慢,还有"中间迷失"问题,所以企业场景该用 RAG 而不是堆上下文。面试被问"为什么不直接用长上下文代替 RAG",答成本/延迟/可更新性/可引用性。
六、KV Cache
6.1 问题:Decode 阶段的重复计算
自回归生成时,每生成一个新 token,它要和所有历史 token 算 Attention。如果不缓存,生成第 100 个 token 时,前 99 个 token 的 K/V 要重新算一遍;生成第 101 个时又算一遍……计算量是 O(n²) 级的浪费。
6.2 解决:缓存历史 K/V
既然历史 token 的 K/V 在每步都不变,那就把它们算一次、缓存起来。每生成新 token 时,只算新 token 自己的 Q/K/V,把新 K/V 追加到缓存,然后用新 Q 和缓存里所有 K 算注意力。每步计算量从 O(n) 降到 O(1)(只算新 token 与历史的关系),整体生成成本从 O(n²) 降到 O(n)。
第1步: 算全部 token 的 K/V,缓存→
第2步: 只算新 token 的 Q/K/V,追加 K/V 到缓存→
用新 Q × 缓存所有 K→
加权聚合缓存所有 V→
输出新 token
6.3 显存占用估算(重要)
KV Cache 显存 = 2 × nlayers × seq_len × nkv_heads × dhead × dtype_bytes
其中:2 = K 和 V 两份;nlayers = 层数;seq_len = 序列长度;nkv_heads = K/V 头数(GQA 下远小于 Q 头数);dhead = 每个头维度;dtype_bytes = 数据类型字节数(fp16=2,int8=1)。
实操估算:7B 模型、32K 上下文、fp16
假设 32 层,GQA 下 nkv_heads=8,dhead=128:
2 × 32 × 32768 × 8 × 128 × 2 bytes
= 4,294,967,296 bytes ≈ 4 GB(单请求!)
而 7B 模型参数本身 fp16 才约 14 GB。一个 32K 请求的 KV Cache 就占了模型参数的近 30%。这就是为什么长上下文服务并发上不去——显存被 KV Cache 吃光了。
6.4 KV Cache 的工程影响
- 多轮对话:每轮把历史 K/V 留在缓存,下一轮不用重算历史,所以多轮对话比每次重传全文快得多。但缓存要常驻显存,并发用户多时显存压力大。
- Batch:多个请求的 KV Cache 共占显存,能 batch 多少取决于剩余显存。GQA 模型省缓存 → 同卡能 batch 更多 → 吞吐高。
- vLLM 的 PagedAttention:把 KV Cache 像虚拟内存一样分页管理,减少显存碎片,让 batch 吞吐提升 2-4 倍。这是 vLLM 快的核心原因之一。
- 量化 KV Cache:把缓存存成 int8/int4,显存减半甚至 1/4,代价是精度略降。长上下文服务常用。
KV Cache 缓存历史 token 的 K/V,避免每生成一个 token 就重算全部历史,把生成成本从 O(n²) 降到 O(n)。代价是吃显存,长上下文单请求的 KV Cache 可能几 GB,直接限制并发。这也是 GQA、PagedAttention、KV 量化这些技术存在的理由。面试算一道"7B/32K 多少显存"能直接证明你懂工程。
① KV Cache 只在 Decode 阶段用,Prefill 阶段是第一次算、要填满缓存。② 不要把 KV Cache 和"上下文窗口"混为一谈——窗口是 token 数上限,KV Cache 是存这些 token 的 K/V 占的显存。③ 多轮对话里,如果用无状态 API(每次重传全部历史),KV Cache 每轮都要重算 Prefill,并不会自动复用——是否复用取决于推理引擎是否支持前缀缓存(prefix caching)。
七、Prefill 与 Decode
7.1 两个阶段
一次生成请求在推理引擎里分两个阶段:
| 阶段 | 做什么 | 计算特征 | GPU 利用率 |
| Prefill(预填充) | 一次性处理整个 prompt,算出所有 prompt token 的 K/V 填入缓存 | 计算密集(大批矩阵乘) | 高 |
| Decode(解码) | 逐个生成输出 token,每步只处理 1 个新 token | 访存密集(每步要读全部权重+缓存) | 低 |
7.2 三个延迟指标(必背)
- TTFT(Time To First Token):首 token 延迟 = Prefill 时间。prompt 越长,TTFT 越高(O(n²))。
- TPOT(Time Per Output Token):每个输出 token 的平均生成时间,反映 Decode 速度。受 batch 大小、模型大小影响。
- ITL(Inter-Token Latency):相邻 token 间的延迟,体感"卡顿"的来源。
端到端延迟 ≈ TTFT + (输出 token 数 × TPOT)。用户体感"快不快"主要看 TTFT(多久出第一个字)和 TPOT(出字速度)。
7.3 为什么 Decode 慢且 GPU 利用率低
Decode 每步只处理 1 个 token,却要把整个模型权重 + 全部 KV Cache 从显存读到计算单元。计算量极小(1 个 token 的矩阵向量乘),但访存量巨大(读几十 GB 权重)。这就是访存瓶颈——GPU 算力闲置,大部分时间在等数据从显存搬过来。
而 Prefill 一次处理几百上千 token,是大矩阵乘,计算量大、能喂满 GPU,所以利用率高。
7.4 怎么缓解 Decode 瓶颈
- Continuous Batching(连续批处理):不同请求的 Decode 步动态拼成 batch,把多个"1 token"凑成大矩阵,提高利用率。vLLM 的核心特性。
- Speculative Decoding(投机解码):用小模型先猜几个 token,大模型一次验证多个,减少大模型的前向次数。
- Chunked Prefill:把长 prompt 切块 prefill,和 decode 交错执行,避免长 prefill 阻塞其他请求。
你做模型网关和 vLLM 部署时,TTFT 和 TPOT 是两个核心 SLA 指标。RAG 场景 prompt 长 → TTFT 高,要控制检索召回的 chunk 数量;Agent 多轮 → 累计输出 token 多,TPOT 影响大。容量规划时,长 prefill 请求会占满 GPU 拖慢其他人,需要 Continuous Batching + 限流。
Prefill 一次处理整个 prompt,计算密集、GPU 满载,决定 TTFT;Decode 逐 token 生成,访存密集、GPU 闲置,决定 TPOT。长 prompt 让 TTFT 高,多轮生成让 TPOT 累计明显。Continuous Batching 和投机解码是缓解 Decode 瓶颈的主流手段。
不要说"Decode 慢是因为模型大"。Decode 慢的本质是访存瓶颈——每步算 1 个 token 却要读全部权重,算力闲置。这也是为什么 batch 越大 Decode 反而越高效(把多个 1 token 拼成大矩阵,摊薄访存)。
八、推理模型 vs 普通对话模型
8.1 区别
| 维度 | 普通对话模型(如 Qwen-Plus、DeepSeek-V3) | 推理模型(如 DeepSeek-R1、o1 类) |
| 行为 | 直接生成答案 | 先产生长思维链(CoT)推理,再给答案 |
| 训练 | SFT + RLHF 对齐 | 在基础模型上用 RL(强化学习)训练推理能力,加冷启动 SFT |
| 延迟 | 低(答案 token 少) | 高(思考 token 可能几千) |
| 成本 | 低 | 高(思考 token 也计费) |
| 擅长 | 日常对话、分类、抽取、写代码 | 数学、逻辑、复杂规划、多步推理 |
| 不擅长 | 复杂多步推理 | 简单任务(杀鸡用牛刀,慢且贵) |
8.2 API 调用差异
- 推理模型返回里通常多一个
reasoning_content 字段,是模型的思考过程;content 才是最终答案。
- 思考 token 计费,且通常不展示给用户,但会占上下文和延迟。
- 部分推理模型不支持 function calling 或支持有限,做 Agent 时要注意兼容性。
8.3 在你的「特药理赔 Agent」里怎么选
- 用推理模型:规则校验后的风险等级判断(需要综合多条款推理)、复杂拒赔理由生成(要引用多条规则串联)。
- 用普通模型:OCR 字段抽取、意图分类、简单的材料完整性检查、结论模板填充——这些是分类/抽取任务,推理模型反而又慢又贵。
- 混合策略:Agent 主流程用普通模型保证速度,只在关键决策节点(高风险判断)调用推理模型。这正符合 v4 里"规则/RAG/Agent/人工职责划分"的思路。
推理模型先思考再答,擅长复杂推理但慢且贵;普通模型直接答,适合分类/抽取/对话。关键决策用推理模型,常规步骤用普通模型,这是 Agent 里降本提速的实战思路。调用时注意 reasoning_content 字段和思考 token 计费。
① 不是所有任务都该用推理模型——简单分类用它,又慢又贵还可能过度思考。② 推理模型的思考内容默认不返回给用户,做 Trace 时要单独记录 reasoning_content 用于调试。③ 部分推理模型 function calling 支持不完整,做 Agent 前要验证。
九、面试达标线①:一次 API 请求的完整过程
这是 Day 1 最核心的面试题,必须能流畅讲完整条链路。
1.客户端发 HTTP 请求→
2.网关鉴权/限流/路由→
3.Tokenizer 切分→
4.Embedding+位置编码→
5.Prefill(填 KV Cache)→
6.Decode 循环(采样)→
7.反 Tokenize→
8.SSE 流式返回
- 客户端发请求:把 prompt、模型名、参数(temperature、max_tokens 等)打包成 JSON,POST 到 API 端点。
- 网关层:鉴权(API Key)、限流、配额检查、模型路由(决定转发到哪个模型实例)、记录 Trace ID。
- Tokenizer 切分:用该模型的 tokenizer 把 prompt 文本切成 token id 序列。这一步决定了输入 token 数(计费依据)。
- Embedding + 位置编码:每个 token id 查表得到向量,加上(或旋转注入)位置编码,得到初始输入向量序列。
- Prefill 阶段:整个 prompt 序列一次性过 N 层 Transformer Block,每层算 Attention(带因果掩码)和 FFN,把每层的 K/V 存入 KV Cache。最后一层输出 logits。这一步计算密集,决定 TTFT。
- Decode 循环:取最后位置 logits 经 softmax 得到下一个 token 的概率分布 → 按采样策略(temperature/top_p/top_k)采样出下一个 token → 把新 token 的 K/V 追加到缓存 → 重复直到遇到 stop token 或达 max_tokens。每步访存密集,决定 TPOT。
- 反 Tokenize:把生成的 token id 序列用 tokenizer 解码回文本。
- 流式返回:每生成一个 token 就通过 SSE(Server-Sent Events)推给客户端,实现"打字机"效果。非流式则等全部生成完一次性返回。
讲这道题的层次:① 能讲清 8 个步骤的顺序和每步做什么(及格);② 能点出 Prefill/Decode 的计算特征差异和 TTFT/TPOT 来源(良好);③ 能结合网关、KV Cache、采样、流式说出工程细节(优秀)。建议背下这条链路,面试时从头讲到尾 2 分钟。
十、面试达标线②:上下文长度 / 延迟 / 成本三者关系
10.1 三者关系总览
| 因素 | 对延迟的影响 | 对成本的影响 | 原因 |
| 上下文变长 | TTFT ↑↑(Prefill O(n²)) | Input 费用 ↑(按 token 计) | 注意力矩阵 n×n,计算量平方增长;KV Cache 显存线性增长压低并发 |
| 输出变长 | 端到端 ↑(TPOT × n) | Output 费用 ↑(输出单价更高) | 逐 token 生成,每步访存瓶颈 |
| 批并发增大 | 单请求 TPOT 可能略 ↑ | 单请求成本 ↓(摊薄) | Continuous Batching 提高利用率 |
10.2 为什么长上下文又贵又慢
- 计算量:Self-Attention 对 n 个 token 要算 n×n 注意力矩阵,prompt 翻倍计算量变 4 倍。128K 比 4K 的 Prefill 计算量大约 1024 倍。
- 显存:KV Cache 随序列线性增长,128K 单请求缓存几 GB,单卡并发请求数骤降,单请求分摊的固定成本上升。
- 计费:API 按输入 token 计费,长 prompt 直接贵;部分长上下文模型输入单价本身就更高。
10.3 工程取舍:RAG vs 长上下文
正因为长上下文又贵又慢,企业场景不该"全塞进去",而要用 RAG 把相关内容精准检索出来、只喂几 K。这是 RAG 在长上下文时代依然核心的原因——不是模型不能长,而是用长上下文不划算。
上下文越长,Prefill 计算量平方增长(TTFT 高)、KV Cache 显存线性增长(并发低)、Input 费用线性增长。所以长上下文又贵又慢,企业知识场景该用 RAG 精准喂小窗口,而不是堆满长上下文。输出 token 比输入贵(单价高 + 逐 token 生成慢),所以控制 prompt 长度和输出长度都能省钱。
十一、Day 1 自测清单
逐条勾选,全部能自信说出才算 Day 1 过关:
- 能解释 Self-Attention 的 Q/K/V 含义和计算公式,说清为什么除以 √dk。
- 能解释 Multi-Head 为什么要多头,以及 GQA 如何省 KV Cache 显存。
- 能说清 Decoder-only 为何成为主流(统一范式 + 训练效率 + Scaling)。
- 知道 token 是子词单元,不同模型 tokenizer 不通用,能用目标模型估算中文 token 数。
- 能解释 Embedding 的作用,以及为什么 Transformer 需要位置编码(RoPE 是什么)。
- 能说清上下文窗口的限制因素(O(n²)、KV Cache 显存、训练长度)。
- 能解释 KV Cache 原理,并估算 7B/32K 的 KV Cache 显存(约 4GB)。
- 能区分 Prefill 和 Decode 的计算特征,说清 TTFT/TPOT 来源。
- 能区分推理模型和普通模型,判断特药理赔 Agent 各步骤该用哪种。
- 能从头到尾讲完一次 API 请求的 8 个步骤。
- 能说清上下文长度/延迟/成本三者关系,解释为什么用 RAG 而非堆长上下文。
十二、高频面试题速记卡
Q:为什么 Self-Attention 要除以 √dk?
防止点积过大让 softmax 饱和、梯度消失,把方差控制在敏感区间以稳定训练。
Q:KV Cache 为什么能加速?
缓存历史 token 的 K/V,每步只算新 token,把生成成本从 O(n²) 降到 O(n)。
Q:Prefill 和 Decode 哪个是访存瓶颈?
Decode。每步只算 1 个 token 却要读全部权重和缓存,算力闲置在等数据。
Q:为什么长上下文又贵又慢?
Attention 是 O(n²),Prefill 计算量平方增长;KV Cache 线性吃显存压低并发;input token 按量计费。
Q:Decoder-only 为什么是主流?
统一"预测下一个 token"范式通吃所有任务,训练效率高,Scaling Law 友好,推理与 KV Cache 契合。
Q:GQA 是什么,为什么重要?
多个 Q 头共享一组 K/V,在几乎不损效果下大幅减少 KV Cache 显存,让同卡并发和上下文长度翻倍。
Q:token 和词一样吗?
不一样,token 是子词单元;不同模型 tokenizer 不通用,token 数必须用目标模型实测,不能按字符数估算。
Q:推理模型和普通模型怎么选?
复杂多步推理用推理模型,分类/抽取/对话用普通模型;Agent 里关键决策用推理、常规步骤用普通以降本提速。
Q:Transformer 为什么需要位置编码?
Self-Attention 本身顺序无关,打乱 token 顺序结果只是重排;位置编码注入顺序信息,现代模型用 RoPE 支持相对位置和长度外推。
Q:TTFT 和 TPOT 分别由什么决定?
TTFT 由 Prefill 决定(prompt 越长越高);TPOT 由 Decode 决定(受 batch 和模型大小影响)。
FDE Day1 学习手册 · 大模型核心基础(面试级)· 配合《Day1 评测题.md》自测使用