增长账单：上下文为什么会失控

6、17、33、54、80。一个每轮净增 5K token 的 Agent 循环，五次调用就把累计 input 推到 80K。

这本账怎么涨、钱花在哪，讲次页没有展开。本篇逐段算清，也替 2a 后续详解搭好坐标系。

一本增长账：每轮加 5K，五轮欠 80K

Agent 循环的结构性代价在于：每一轮调用，模型收到的不只是新消息，而是固定前缀加上此前的全部历史（L3 p.3）：

input_t = fixed prefix + history before call t

slides 的演算如下：

每轮净新增恒定 5K，单轮增长是线性的；累计却近似 5K × n (n+1)/2 的二次曲线。单轮还好，累计才是要害。

五次调用只是开场。按同样斜率演算到第 50 次，累计约 6.4M token。问题从来不在窗口大小上，这种增长方式本身不可持续。

更糟的是，这份二次账单不只是 API 计费口径，它逐字压在服务端的计算上。压在哪，下文会看到。

钱花在哪：77,922 tokens 的解剖

上一节看增速，这一节看构成。OpenHands 团队对 1,500 个真实 session 做了实测（L3 p.4）：平均每个 session 消耗 77,922 tokens，构成如下。

用户输入只占 9%。上下文的大头，是工具返回的内容。

工具调用加工具结果合计 57%，工具结果独占最大单项。所以 slides 把管理重点钉在工具结果而非对话本身。

这也预告了后续详解的下刀处：压缩优先处理工具结果，外置优先搬走证据原文。对话历史反而是最不用先动的部分。

Capacity 还是 Efficiency：先把两问分开

账单算清之后，slides 立起一张总地图（L3 p.5）：长上下文的全部难题挂在两问上，本讲后面的每一种技术都能对号入座。

本讲后续的详解页就挂在这两问的枝干上：

服务端视角：长为什么等于慢、又等于贵

一个请求进入推理服务后要走完这条栈（L3 p.7-9）：Scheduler 负责排队、批处理、路由，然后是预填充 / 解码两阶段，之间靠 KV cache 衔接。

KV cache 是每个请求一份的持久状态。两个阶段性格截然不同：

为什么预填充的计算量随长度平方涨？复习一眼标准注意力（L3 p.10）：

Attention(Q, K, V) = softmax((QK^T + M) / √d_k) · V

Q、K、V 由输入序列投影而来，QK^T 是 n×n 的矩阵：每个 token 都要与此前所有 token 两两比较，因果掩码 M 只是把未来遮掉。全序列两两比较，就是二次代价的根源（L3 p.10）。

80K 的历史每轮都要重新过一遍这样的比较，除非命中缓存。

系统研究就沿这个问题展开：

• Prompt Cache (MLSys 2024, arXiv:2311.04934)：把重复提示段的 attention 状态预计算、跨请求复用，GPU 首 token 延迟降低 8 倍。
• DistServe (OSDI 2024, arXiv:2401.09670)：把预填充与解码拆到不同的卡上消除相互干扰，同等服务目标下多服务 7.4 倍请求。
• Can I Buy Your KV Cache? (arXiv:2606.13361)：2026 年把问题推成经济问题，追问一份文档的 KV 为什么不能由出版方算一次、全世界付费加载。作者在 Qwen3-4B 上实测，复用相比重算省 9-50 倍计算。

落到你的账单上，就是 input + cached input + output 三段计费里的 cached input 一档（L3 p.9）。这段价差怎么吃满，是 context-economy 一篇的主题。

与本讲的连接

本篇是 2a 的总账本，后续每一篇详解都放得回这张地图。资料卡从 Prompt Cache、DistServe、KV 缓存管理综述三张入手。增长的账躲不开，能省的都在 cached input 一档的价差里，context-economy 一篇接着算。