模型的上下文到底由什么决定：从自注意力、KV Cache 到 1M 窗口

先放一句结论：上下文不是模型的记忆，是一次请求的输入。

模型没有会话、没有状态，两次请求之间它什么都不记得。你感觉它在「记住」，是因为客户端每轮把历史重新拼进去，再发一遍。

这篇从面试里最常见的一个追问倒着讲：既然上下文这么贵，为什么旗舰模型的窗口偏偏停在 1M？

适合谁读：准备初级 Agent / AI 应用岗面试，不要求手推公式，但要能把「上下文 — 自注意力 — KV cache — 窗口」这条因果链讲清楚。

目录

• 一、先从一个面试题开始：为什么旗舰模型停在 1M？
• 二、上下文是什么：内容、容量、计算
• 三、自注意力：模型怎么「读」上下文
• 四、KV cache：模型怎么「复用」上下文
• 五、一次生成的完整过程：prefill 与 decode
• 六、为什么停在 1M：三条硬约束
• 七、他们是怎么把窗口推到 1M 的
• 八、厂商到底怎么决定窗口大小
• 九、面试怎么答：六个高频问题
• 十、自检清单
• 附：本文的核查方式
• 附：延伸阅读

一、先从一个面试题开始：为什么旗舰模型停在 1M？

2024 年 2 月，Gemini 1.5 Pro 把 1M 窗口摆上台面。之后两年，1M 从「演示参数」变成了「旗舰档位」：

（这张表只用来建立时间感。具体型号的窗口参数半年就会变，面试时以官方文档为准；本文重点讲机制，不死记数字。）

还要先纠正一个常见口径：不是所有模型都 1M，是「旗舰档位」普遍 1M。 开源小模型的主流仍在 32K–256K；你看到的 1M，是头部几家在竞争里推上去的档位。这个差别本身就说明：窗口是成本和定位的函数，不是模型能力的自然属性。

但为什么不是 100K，也不是 10M？

因为窗口大小不是「想设多大就多大」，它同时被三件事拽着：

1. KV cache 线性涨：1M token 的 KV cache 是百 GB 级，再往上，单请求的显存成本会压垮并发。
2. 注意力计算二次涨：prefill 的注意力部分是 O(n²)。1M 相对 32K，序列长 32 倍，注意力计算量约 1000 倍。
3. 有效利用率下降：窗口 1M ≠ 有效 1M。lost in the middle、context rot、训练数据里的长距离依赖有限，都会让「塞进去」不等于「用得上」。

这三条不是三个独立的 bug，是同一个东西的三个成本项。要把它们讲清楚，得先回答一个更基础的问题：

上下文到底是什么？

二、上下文是什么：内容、容量、计算

面试里常见的两个答案：

• 「上下文就是对话历史。」——只说了内容。
• 「上下文就是上下文窗口。」——只说了容量。

都不完整。把「上下文」拆成三层，因果链就清楚了：

2.1 一次请求走一遍

你写一句「北京在哪」，到模型看见它，中间发生了这些事：

你写的 messages（JSON）
  ↓ chat template：加角色标记和特殊 token
<|system|>你是一个助手<|user|>北京在哪<|assistant|>
  ↓ tokenizer：切成 token ID
[101, 872, 1962, 102, 101, 2345, 678, 102, ...]   ← 假设 37 个 token
  ↓ 加位置
位置 0, 1, 2, ..., 36

（具体 ID 因模型而异，这里只示意形状。）

到这一步，上下文已经敲定了。模型收到的不是「北京在哪」四个字，是这 37 个 ID 和它们的位置。它不能要求再看一个文件，不能回退，不能自己扩大范围。它只能在这 37 个位置里算。

所以最准确的说法是：

上下文 = 你递给它的内容，和它最多能接的容量，先取交集。 内容由你敲定，容量由训练敲定。模型自己不参与敲定。

模型只敲定一件事：下一个 token。

2.2 权重和上下文，是两种不同的东西

• 权重：模型长期学到的东西，决定「它是谁」。
• 上下文：这次临时看到的东西，决定「它此刻看到了什么」。

模型回答 = f(权重, 上下文)。没有第三个输入。

窗口外的事实，模型只能靠权重里的记忆；权重里没有、上下文里也没有，它就是不知道，或者编一个。所以「上下文」的边界不是「模型知道什么」的边界，是「模型这次被允许看什么」的边界。

打个比方：你带进会议室的资料。桌子大小决定你能带多少（容量），带什么由你决定（内容），怎么讨论由会议规则决定（计算）。模型就是那个只能看桌上资料、不能自己回办公室翻柜子的人。

2.3 再说清楚一点：模型没有「记住」

API 通常是无状态的。你感觉它在「记住」，是因为客户端每轮把历史重新拼进去，再发一遍。

有些产品提供「会话对象」「previous_response_id」这类封装，但底层仍然是：把之前的上下文重新送进模型。那是工程封装，不是模型内部记住了。

这就是为什么「模型失忆」和「上下文变贵」是同一个原因：历史必须重发。

三、自注意力：模型怎么「读」上下文

现在看「计算」层。

3.1 一个会议室

把上下文里的每个 token 想成会议室里的一个人。每个人发言前，先做三件事：

发言前，你拿自己的提问卡（Q）去和全场每个人的名片（K）比对，算出「我该听谁的」；然后按这个权重，把大家的资料袋（V）内容加权加起来。

写成公式：

Attention(Q, K, V) = softmax(QKᵀ / √d) V

拆开看：

1. QKᵀ：每个 token 的 Q 和所有可见位置的 K 点乘，得到一组相关性分数。
2. 除以 √d：防止分数太大，softmax 之后变成 0/1 的极端值。
3. softmax：把分数变成权重，加起来等于 1。
4. 乘以 V：按权重把所有人的资料袋内容加权求和，得到这个 token 的新表示。

3.2 因果掩码：只能看前面

生成是自回归的：第 n 个 token 只能依赖前 n-1 个 token，不能看后面还没生成的内容。

所以 attention 里有一个 causal mask：位置 i 只能看 ≤ i 的位置。

打个比方：开会时按座位顺序发言，你只能听已经讲过的人，不能偷看后面还没发言的人的稿子。训练时也一样——否则模型就学会「偷看答案」了。

3.3 拿 [北京, 在, 哪] 走一遍

假设上下文是 [北京, 在, 哪]，模型要生成下一个 token。

• 「哪」用自己的 Q 去点乘「北京」「在」「哪」的 K。如果「北京」的 K 和「哪」的 Q 最匹配，「北京」的 V 就会拿到最大的权重。
• 「在」也做同样的事，只是它关注的重点可能不同。
• 每个 token 都算一遍，每层都重算一遍。

这就是「哪」通过自注意力读到了「北京」和「在」。

3.4 多头：同时问不同的问题

一个 head 可能关注「谁修饰谁」，另一个关注「谁和谁是同一个东西」，还有一个关注「事实是否一致」。

打个比方：会议室里同时坐着几个提问者，一个问语法，一个问指代，一个问事实。每个人得到一份笔记，最后拼在一起。

3.5 最关键的一句

相关性不是标出来的，是算出来的。

上下文里没有任何 token 被标记为「重要」。重要性是每一层、每个 head 用 Q 和 K 现算的。

所以：

• 同一段上下文，换个问题，attend 的地方就变了。
• 同一层不同 head，看的也不一样。
• 「把重要信息放开头」不是一条规则，是训练分布造成的偏置。
• lost in the middle 不是 bug，是这种计算方式在长序列上的自然结果。

3.6 代价：O(n²)

n 个 token，每个都要和 n 个 token 比对，计算量是 n×n。

打个比方：10 个人开会，每个人和其余 9 个人交流，大约 100 次；1000 个人开会，大约 100 万次。长上下文不是「多几个人」，是「人人都要互相认识」。

1M 相对 32K，序列长 32 倍，注意力计算量约 1000 倍。这就是三条硬约束里的第二条。

四、KV cache：模型怎么「复用」上下文

4.1 问题：每生成一个 token，都要重算前面吗？

生成是一个 token 一个 token 来的。如果每生成一个新 token，都把前面所有 token 的 K/V 重新算一遍，太浪费。

4.2 解法：把 K/V 存下来

KV cache 就是：每层、每个 token 的 K 和 V，算过一次就存起来，下次直接用。

• Prefill：prompt 的全部 token 一起进去，并行算出每层的 K/V，写进 cache。
• Decode：新 token 只算自己的 Q/K/V；它的 Q 去查 cache 里所有历史 K；输出下一个 token；再把新 token 的 K/V 写回 cache。

打个比方：开会时每个人先自我介绍一遍（prefill），把名片和资料袋留在桌上；后面每来一个人，只介绍自己，然后翻桌上的名片（decode），不用让所有人重新介绍。

4.3 它不改变结果，只改变成本

数学上，带 cache 和不带 cache 算出来的东西是一样的（忽略浮点误差）。cache 只是把「重复计算前缀」省掉了。

所以：

KV cache 不改变上下文，只改变算上下文的速度和显存。

它是拿显存换时间。

4.4 它有多大？

公式：

每 token 的 KV = 2 × 层数 × KV 头数 × head_dim × 字节数

（前面的 2 是 K 和 V 各一份。）

按 FP16（2 字节）估算，几个真实配置：

单位说明：这里按 1M = 10⁶ 个 token、FP16、十进制 GB（10⁹ 字节）计算，和显卡标称显存的口径一致。如果按 1M = 2²⁰ 算，8B 那行正好是 128 GiB——所以你会看到「128」和「131」两种说法，差的是单位，不是算错。

注意：这只是 KV cache，不含权重和激活；实际占用还要再加。MLA 存的是压缩后的 latent，不是完整 K/V，这里按公开结构估算。

这张表就是第一条硬约束的来源：1M token 的 KV cache 是百 GB 级。 一个请求也许放得下，十个并发就是 TB 级。

4.5 前缀缓存：为什么压缩会让缓存失效

KV cache 能跨请求复用，但有一个条件：前缀必须逐 token 相同，位置也必须相同。

因为 K/V 是由「token + 位置 + 前面所有 token」共同决定的。前缀一变，后面所有 token 的 K/V 都变了。

这解释了一个很实际的坑：

• 你压缩了历史 → 前缀变了 → 后面所有 K/V 失效 → 下一次请求要重新 prefill。
• 省下的 token 钱，可能还不够赔缓存失效的钱。

这也是 《Agent 实战（四）：上下文管理》 里那个「意外发现」的底层原因。想看各家怎么处理，可以接着读 《compaction 参考篇》。

五、一次生成的完整过程：prefill 与 decode

把前面的东西串起来，一次生成是这样的：

1. tokenize prompt
   "北京在哪" → 37 个 token

2. prefill
   37 个 token 并行过模型
   每层写入 K/V
   最后一个位置输出第 1 个 token 的概率分布
   ← 这一步是 O(n²)，决定首字延迟（TTFT）

3. sample 一个 token，追加到序列

4. decode
   新 token 只算自己的 Q/K/V
   读 cache 里的历史 K/V
   输出下一个 token
   把新 K/V 写回 cache
   ← 每一步的 attention 是 O(n)，但 n 是当前序列长度

5. 重复，直到 EOS 或 max_tokens

两个直觉：

• 首字为什么慢？ 因为 prefill 要把整个 prompt 过一遍，prompt 越长，O(n²) 越明显。
• 后面的字为什么也慢？ 因为每生成一个 token，都要把越来越长的 KV cache 读一遍；decode 是访存密集（memory-bound），GPU 算力用不满。

打个比方：prefill 像开场全体自我介绍，可以并行；decode 像点名发言，只能一个一个来，但每个人发言前都要翻一遍桌上越堆越多的名片。

这也解释了为什么输出 token 通常比输入 token 贵：输入可以并行 prefill，输出只能一个接一个 decode。

六、为什么停在 1M：三条硬约束

现在回到开头那个面试题。

6.1 第一条：KV cache 线性涨

1M token 的 KV cache 是百 GB 级（见上面的表）。再往上：

• 单请求显存线性涨；
• 并发数上不去；
• 单价降不下来。

长上下文不是「一个请求贵」，是「并发上不去」。对厂商来说，这直接决定了这张卡能服务多少用户。

6.2 第二条：注意力计算二次涨

prefill 的注意力部分是 O(n²)。1M 相对 32K，注意力计算量约 1000 倍。

FlashAttention 省的是显存和搬运，不是那 O(n²) 的乘加。所以它能让你「放得下」，但不能让长上下文「算得快到免费」。

6.3 第三条：有效利用率下降

这是最容易被忽略的一条。窗口 1M ≠ 有效 1M：

• Lost in the middle：放在中间位置的信息，召回率明显低于开头和结尾，呈 U 形。
• Context rot：输入越长，模型在简单任务上的表现也会退化，不只是「找不到中间」。
• 训练数据：真正需要跨 1M token 推理的任务很少，模型没在那么多长距离依赖上训练过。

所以「标称 1M」和「能把 1M 用明白」是两件事。面试时如果只答「窗口大所以强」，会被追问「那为什么很多团队还是用 RAG」。

6.4 一句话收束

1M 不是物理极限，是「KV 显存、注意力算力、有效利用率」三条线的交点。

打个比方：一张会议桌。桌子越大，椅子越多（KV cache），每个人要认识的人越多（O(n²)），坐在中间的人越容易被忽略（lost in the middle）。三个成本一起涨，1M 是当前「还开得起」的上限。

七、他们是怎么把窗口推到 1M 的

既然有三条硬约束，为什么还能做到 1M？因为四道门槛同时被跨过去了。

7.1 位置编码能外推

模型训练时只见过 8K 或 32K 的位置。直接喂 1M，位置编号远超训练分布，attention 会崩——它不是「装不下」，是「没见过这么远的位置」。

所以有了 RoPE 外推：

• Position Interpolation：把位置线性压回训练范围。
• NTK-aware：调整 RoPE 的 base。
• YaRN：再配合注意力温度缩放。

再加上少量长上下文继续预训练，模型就能在没重新训一遍的前提下，把窗口从 32K 拉到 128K、1M。

关键：窗口不是配置出来的，是训练出来的。 改 max_position_embeddings 只是改了个数；模型没在长序列上训过，那个数就是假的。

打个比方：一张地图，比例尺没变，但你把远处的地形按比例缩进已知坐标里。缩得对不对，得靠实地走一遍（长上下文训练）来校准。

7.2 长上下文能训练

1M token 的序列，一张卡放不下 activation。训练侧要靠：

• 序列并行：把一条长序列摊到多张卡上。
• Ring Attention：让多张卡首尾相接，分块算 attention。
• Activation checkpointing：用时间换显存，不存全部中间结果。

同时，训练数据里要有足够多的长文档、长代码、长对话，让模型真的见过远距离依赖。

打个比方：一张桌子放不下，就拼几张桌子；但拼桌子的人得知道怎么把一份文件摊开、怎么传阅。

7.3 KV cache 能瘦身

这是最硬的一关。几个主流手段：

GQA 和 MLA 是这一轮 1M 窗口的关键。没有它们，1M 的 KV cache 在显存上根本不成立。

7.4 推理工程能扛

模型能算，不等于线上能用。还需要：

• PagedAttention：像操作系统分页一样管理 KV cache，减少显存碎片。
• Chunked prefill：把长 prompt 拆块算，避免首字延迟爆炸。
• Prefix caching：相同前缀不重算。
• Prefill / decode 分离部署：两种负载特征不同，分开调度。

打个比方：图书馆不是「书多就能开」，还要有借阅规则、分页目录、排队叫号。推理工程就是这套规则。

7.5 为什么偏偏是 1M？

需求侧刚好卡在一个甜点：

• 1M token ≈ 70–80 万英文单词，或 100 多万汉字；
• 差不多是一个中型代码库、几本长篇小说、几十小时会议转录；
• 刚好够支撑「把整个资料集塞进去，别做 RAG 了」的叙事。

再往上，价格和延迟会让绝大多数请求不划算；再往下，又不够讲「长上下文」的故事。

1M 是当前「能演示、能定价、能承受」的拐点，不是物理极限。

八、厂商到底怎么决定窗口大小

面试里如果再追一层：「那厂商是怎么定这个数的？」

答案是：窗口大小不是一个纯技术参数，是厂商在「能力、成本、质量」之间做的产品决策。

所以：

• 架构决定上限（位置编码、注意力结构）。
• 训练决定能不能达到（长上下文继续预训练）。
• 显存和算力决定敢不敢卖（每请求成本 × 并发）。
• 质量评估决定卖了之后会不会被骂（RULER、lost in the middle、真实任务）。

面试时能把这句话说出来，比背「某某模型支持 1M」更有价值：

窗口是产品决策，不是模型架构的自然属性。

8.1 一张图记住

messages / 历史 / 工具 / 检索
        ↓ 拼接 + 模板 + tokenizer
上下文：token 序列 + 位置
        ↓ 自注意力（怎么读，O(n²)）
每层 hidden state
        ↓ KV cache（怎么复用，百 GB 级）
prefill（并行，首字延迟）/ decode（逐个，访存密集）
        ↓
窗口 = min(训练长度, 位置编码, 显存, 算力)

九、面试怎么答：六个高频问题

Q1：模型的上下文是什么？

30 秒版：

上下文是模型在一次前向传播里能看见的 token 序列。内容由调用方拼（system、历史、工具、检索），容量由训练和位置编码决定。模型没有会话状态，你感觉它「记住」，是因为客户端每轮把历史重新发一遍。

追问加分：

• 上下文 ≠ 记忆；KV cache 是计算复用，不是模型记忆。
• 上下文窗口 ≠ 有效上下文；标称 1M 不代表 1M 都能用好。
• 回答 = f(权重, 上下文)；权重是长期知识，上下文是这次看到的东西。

Q2：自注意力怎么处理上下文？

答题框架：

1. 每个 token 算出 Q、K、V。
2. Q 和所有可见位置的 K 点乘，softmax 得到权重。
3. 按权重加权求和 V，得到新表示。
4. causal mask 保证只能看前面。
5. 多头从不同角度并行做这件事。

加分项：

• 相关性是算出来的，不是标出来的。
• 计算复杂度 O(n²)；长上下文的主要成本之一。

Q3：KV cache 是什么？为什么能加速？

答题框架：

1. 生成是自回归的，每步只新增一个 token。
2. 把每层每个 token 的 K/V 存下来，decode 时直接查，不重算前缀。
3. 数学结果等价，是拿显存换时间。

加分项：

• 每 token KV = 2 × 层数 × KV 头数 × head_dim × 字节数。
• 1M token 的 KV cache 是百 GB 级。
• GQA / MLA 用来瘦身。
• prefix cache 要求前缀逐 token 相同；压缩历史会让缓存失效。

Q4：为什么旗舰模型是 1M？为什么不是 10M？

答题框架：

1. 三条硬约束：KV 显存线性涨、attention 计算二次涨、有效利用率下降。
2. 四道门槛被跨过：位置外推、长上下文训练、KV 瘦身、推理工程。
3. 1M 是需求甜点 + 商业档位 + 成本拐点。

加分项：

• 标称 1M ≠ 有效 1M；lost in the middle、context rot。
• 窗口是产品决策，不是架构的自然属性。

Q5：长上下文和 RAG 怎么选？

答题框架：

加分项：

• 长上下文的劣势：成本高、首字延迟高、中间信息易丢。
• RAG 的劣势：分块丢上下文、检索有上限、工程复杂。
• 别把它们对立；它们是同一条链上的两个位置。

（更完整的辨析可以看 《AI 应用开发面试笔记》 的 Q3.11。）

Q6：为什么模型会「忘」？

答题框架：

1. 模型无状态，请求之间不保留任何东西。
2. 所谓「记住」是客户端每轮重发历史。
3. 历史被压缩、被截断、被挤出窗口，就会忘。
4. 窗口外的事实，只能靠权重里的记忆；权重里没有，就编。

一句话：

它不是记性差，是根本没有记性；是你在替它记。

如果只记一句

上下文是一次请求的输入，不是模型的记忆；自注意力决定怎么读，KV cache 决定怎么复用，训练和显存决定能读多长。

十、自检清单

读完这篇，如果下面每一条你都能答上来，说明这条因果链接上了：

• 上下文窗口和上下文内容，分别由谁决定？
• 为什么说「模型没有记忆」？那它为什么看起来能记住上一轮？
• 一次请求从 messages 到模型看见，中间经过哪几步？到哪一步上下文就敲定了？
• Q、K、V 分别是什么？用会议室的类比讲一遍。
• causal mask 解决什么问题？训练时为什么也需要它？
• 自注意力的计算复杂度是多少？1M 相对 32K 大约多少倍？
• KV cache 存的是什么？为什么它能加速 decode？
• 1M token 的 KV cache 大概多大？为什么 GQA / MLA 能省？
• 为什么上下文越长越贵、越慢？
• 为什么标称 1M ≠ 有效 1M？lost in the middle 和 context rot 分别指什么？
• 厂商决定窗口大小时，要权衡哪几件事？
• 长上下文和 RAG，各自适合什么场景？

附：本文的核查方式

数字来源：

关于模型时间线：2024–2025 的窗口发布是公开信息；2026 年 Claude 原生 1M 的档位来自本号 《compaction 参考篇》 的版本记录。本文不把具体型号的窗口参数当作选型依据——这类数字半年就会变，面试时以官方文档为准。

本文不涉及（有意略过）：RoPE 的旋转矩阵推导、FlashAttention 的 tiling 细节、MoE 路由、长上下文训练的完整配方。它们的定位是「知道为什么」，不是「手推公式」。

附：延伸阅读

本号相关：

• 《大模型训练笔记（一）：模型下载下来到底是什么》 —— 权重、token、显存的基础
• 《大模型训练笔记（二）：预训练与 SFT》 —— 模型怎么被训出来
• 《大模型训练笔记（三）：LoRA、蒸馏与强化学习》 —— 后训练
• 《Agent 实战（四）：上下文管理》 —— 上下文预算与压缩
• 《Agent 实战（参考篇）：五套 CLI 是怎么 compact 的》 —— 压缩的工程实现
• 《Agent 的缓存保温多花了 8 倍的钱》 —— prefix cache 的经济学
• 《AI 应用开发面试笔记》 —— 更完整的面试地图

论文 / 报告：

• RoFormer / RoPE：RoFormer: Enhanced Transformer with Rotary Position Embedding（arXiv:2104.09864）
• Lost in the Middle：Lost in the Middle: How Language Models Use Long Contexts（arXiv:2307.03172）
• GQA：GQA: Training Generalized Multi-Query Transformer Models from Multi-Head Checkpoints（arXiv:2305.13245）
• PagedAttention / vLLM：Efficient Memory Management for Large Language Model Serving with PagedAttention（arXiv:2309.06180）
• FlashAttention：FlashAttention: Fast and Memory-Efficient Exact Attention with IO-Awareness（arXiv:2205.14135）
• DeepSeek-V2 / MLA：DeepSeek-V2: A Strong, Economical, and Efficient Mixture-of-Experts Language Model（arXiv:2405.04434）
• RULER：RULER: What’s the Real Context Size of Your Long-Context Language Models?（arXiv:2404.06654）
• YaRN：YaRN: Efficient Context Window Extension of Large Language Models（arXiv:2309.00071）
• Position Interpolation：Extending Context Window of Large Language Models via Positional Interpolation（arXiv:2306.15595）
• Context Rot：Chroma 的 Context Rot: How Increasing Input Tokens Impacts LLM Performance（2025）

下一篇（如果这个系列继续）：从「上下文」到「上下文工程」——预算怎么分、什么该压、什么该检索、什么该外挂。