编程基础篇 · 复杂度：一眼看穿代码值不值
为什么上下文越长越贵？O(n²) 的账单
上一课你拿到了 Big-O 这把尺子，还记得那条起飞的红线吗？今天带你去看大模型里最有名的一个 O(n²)——注意力机制。学完你会突然理解一堆老问题：为什么长对话越来越卡、为什么上下文窗口是「窗口」不是「仓库」、为什么大家拼命做上下文压缩。
先回忆一下 · 注意力在干嘛
前面的课程讲过：大模型生成每个新词元（token）时，都要「回头看」前面所有的词元，给每个词分配注意力权重，才知道接下来该接什么。一个 token 看一遍所有 token——这句话用上一课的语言翻译一下：n 个 token，每个都要看 n 个，总共 n × n 次「对视」。这就是一张 n×n 的表格。拖滑块画给你看。
交互一 · 注意力矩阵：n² 长什么样
下面每一行代表「一个 token 要看所有 token」，深色对角线是它看自己。留意右边的格子总数：滑块只是匀速往右拖，数字却越跳越猛——这就是「平方增长」的手感。
每行 = 一个 token 要看所有 token
TOKEN 数 n
8
对视次数 n²
64
= 注意力矩阵的格子总数
n 从 4 拖到 48，只翻了 12 倍；格子却从 16 涨到 2304，翻了 144 倍。真实对话动辄几万 token——把这张图在脑子里放大一千倍，你就明白 GPU 在替你算什么了。
交互二 · 同一个问题，两种上下文
同样问一句「帮我总结一下重点」，一个人先把历史精简到 1 万 token，另一个人把 10 万 token 的完整记录原样塞进去。token 只差 10 倍，看看账单差多少。留意「注意力计算量」那一行：它不是 ×10，是 ×100。
精简派 1 万 token
只保留和问题相关的段落再提问
注意力计算量1 份
首字延迟（示意）≈ 1 秒
本次输入费用（示意）≈ ¥0.1
全塞派 10 万 token
整个历史记录一股脑丢进上下文
注意力计算量100 份
首字延迟（示意）≈ 几十秒
本次输入费用（示意）≈ ¥1+
※ 延迟与费用为量级示意，非精确报价；不同模型、不同档位差异很大
核心结论一句话：上下文翻 10 倍，注意力计算翻 100 倍。费用大体跟 token 数走（×10 起步，长上下文档位往往还要加价），而延迟和显存压力跟着计算量走——所以「多塞点总没坏处」在大模型这里不成立，塞进去的每一个 token 都要被后面所有 token 反复回头看。
知识串联 · 这解释了前面课程的三件事
① 为什么长对话越来越卡
聊得越久，n 越大，每生成一个新 token 要做的「回头看」就越多。卡顿不是网络问题，是 n² 在后台滚雪球。
② 为什么要做上下文压缩
Compaction 把旧对话摘要成一小段再继续聊。牺牲一点细节，换 n 大幅变小——n 砍一半，计算量砍四分之三，划算。
③ 为什么 KV Cache 能省钱
前缀部分算过的注意力结果缓存下来、下轮不重算（姊妹篇 ds-6 讲过）。正因为原始计算是 O(n²) 的贵，缓存的折扣才这么值钱。
把这课带进日常。下次和 AI 长聊卡了、账单高了，你知道该做什么：开新对话、让它先总结再继续、RAG 里只召回相关段落。这些技巧背后是同一条数学：让 n 小一点，n² 就小很多。
✅ 这一课想和你分享的
- 注意力是 O(n²)：每个 token 都要回头看所有 token，n×n 张表逃不掉
- 上下文不是免费的仓库：塞进去的每个 token 都会被后面所有 token 反复看
- 翻 10 倍 = 贵 100 倍：计算量按平方涨，这是长对话变卡变贵的根源
- 精简上下文 = 省钱省时间：压缩、摘要、KV Cache 全是在和这个 n² 搏斗