ModelDock
中
EnglishEN简体中文中日本語日

更大，但更慢：LLM 智能体的最优上下文窗口

摘要

长上下文大语言模型通常以其支持的最大上下文长度和 decode 吞吐量来评估。但对交互式智能体而言，这些指标并不能完整说明系统性能。随着智能体会话增长，越来越长的上下文必须在 prefill 阶段处理，而实测的 prefill 吞吐量往往会随上下文长度恶化。让智能体在模型或硬件所支持的最大上下文上运行，因此可能增加而非减少总任务完成时间。压缩看似提供了解法，但压缩本身也有成本：上下文需要被总结或以其他方式缩减，而缩减后的工作上下文随后仍必须被 prefill，以重建模型的推理状态。这两种相反成本意味着存在一个使时间最优的工作上下文阈值。

本文为长时程 LLM 智能体建立这一权衡的简单模型。对于固定工作量，提高压缩阈值会减少压缩和上下文重建的频率，却会增加在退化的长上下文 prefill 吞吐量下完成的计算量。在常见的 prefill 退化形式下，总任务完成时间因而与工作上下文阈值呈 U 形关系。我们还提出一种被动估计方法：智能体 harness 从日常使用遥测中学习其硬件、模型、量化和后端特定的 prefill 退化函数。无需专门 benchmark，所得函数即可用来估计使时间最小的压缩阈值。该框架区分最大上下文容量与最优工作上下文，并说明上下文管理应被视为运行时调度问题，而非模型标称上下文窗口的固定百分比。

1. 引言

上下文窗口的迅速扩大已成为大语言模型进步的重要维度。当代模型日益支持数十万、乃至数百万 token 的上下文窗口。因此，智能体 harness 往往把更大的可用上下文视为无条件的好事。常见策略是允许对话历史增长到模型最大上下文窗口的某个固定比例（例如 80%），之后才压缩或总结历史。

这种做法隐含地把上下文容量等同于上下文效率。

对于长时间运行的本地智能体，这两者可能显著背离。

智能体并不只是存储上下文；它必须处理上下文。随着工作上下文增长，prefill 会成为端到端延迟中越来越重要的组成部分。更重要的是，prefill 吞吐量本身可能随上下文增长而下降。因此，在 100,000 token 上运行的智能体，处理每一单位新增工作所花的时间可能远多于在 30,000 或 50,000 token 上运行的同一智能体。

仅看 decode 吞吐量无法捕捉这一影响。一台本地模型即使能以每秒 50 token 生成，也可能在长智能体会话中让人感觉越来越慢：越来越大的执行时间份额消耗在生成开始前处理上下文上。

显而易见的回应是更频繁地压缩。然而压缩并非免费。常规的基于模型的压缩过程本身可能需要大量推理。即便压缩采用廉价的确定性或 CPU 方法，压缩后的工作上下文仍必须重新处理，才能重建模型的推理状态。过于频繁的压缩会因此反复重建最小可用工作上下文，浪费大量计算。

这产生了两股相反的力量。

提高工作上下文阈值会减少压缩和重建的频率：

\[ H \uparrow \quad\Rightarrow\quad \text{更少的压缩和重建}. \]

同时，它迫使模型在更长、更慢的上下文上度过更大比例的工作时间：

\[ H \uparrow \quad\Rightarrow\quad \text{更高的长上下文 prefill 成本}. \]

我们认为，这两股相反力量会产生内部最优点。对于给定的模型、硬件配置、推理后端和压缩策略，存在一个工作上下文阈值，使预期任务完成时间最小。

我们将该量称为 最优工作上下文。

关键区分是：

\[ C_{\max} \neq C_{\mathrm{optimal}}. \]

最大上下文 \(C_{\max}\) 描述系统能够容纳什么；最优工作上下文描述系统应当在什么位置运行。

本文给出估计这一点的简单解析框架，并提出一种实用机制，使智能体 harness 能从日常使用中被动学习它。

2. 上下文长度作为运行时成本

考虑一个在执行工作时不断积累上下文的长时程智能体。令 \(c\) 为当前工作上下文长度，并令

\[ S(c) \]

表示上下文长度 \(c\) 下的 prefill 吞吐量，单位为每秒 token 数。

一个有用的一阶经验模型为

\[ S(c) = \frac{S_0}{1+c/K}, \]

其中 \(S_0\) 表示短上下文 prefill 吞吐量，\(K\) 控制吞吐量随上下文长度退化的速率。

参数 \(K\) 可理解为上下文长度退化尺度。当

\[ c=K, \]

模型预测

\[ S(K)=\frac{S_0}{2}. \]

因此，较大的 \(K\) 描述在上下文增长时更能保持 prefill 吞吐量的系统。

这一函数形式并非论证所必需。实践中，\(S(c)\) 可由观测到的运行时数据以非参数方式估计。我们使用解析形式，是因为它使底层优化过程透明可见。

处理无穷小上下文增量 \(dc\) 所需的时间为

\[ dt=\frac{dc}{S(c)}. \]

因此，从空推理状态构建长度为 \(H\) 的上下文所需时间为

\[ I(H) = \int_0^H\frac{dc}{S(c)}. \]

在上述退化模型下，

\[ I(H) = \frac{1}{S_0} \left( H+\frac{H^2}{2K} \right). \]

二次项很重要。尽管上下文本身线性增长，累计处理成本仍可能超线性增长，因为后面的 token 是在逐步变差的 prefill 条件下处理的。

3. 采用压缩的稳定智能体运行

接下来考虑一个运行足够久、已进入稳定压缩机制的智能体。

令

\[ R \]

表示压缩后保留的上下文。\(R\) 是维持持续运行所必需的最小可用工作上下文：它保存指令、任务状态、近期交互历史、相关工具状态及其他信息。

令

\[ H>R \]

表示压缩阈值。

因此，稳定运行周期为

\[ R \rightarrow H \rightarrow \text{压缩} \rightarrow R. \]

在每个周期中，智能体在需要再次压缩前完成

\[ H-R \]

个 token 的新增有效工作。

但压缩之后，得到的上下文必须再次处理。因此，系统会反复支付重建约 \(R\) 个 token 工作状态的成本。

这一重建成本是优化问题的核心。若它为零，时间最优策略就是持续压缩，并维持尽可能小的上下文。一旦把重建包含进来，过小的上下文阈值就会变得低效。

4. 每单位有效工作的时间

先假设生成压缩表示本身的计算成本可忽略。这近似于运行时间相对于 GPU 推理很小的确定性或 CPU 压缩。

一个完整周期从空推理状态处理上下文直到 \(H\)，成本为

\[ T_{\mathrm{cycle}}(H) = = I(H) \frac{1}{S_0} \left( H+\frac{H^2}{2K} \right). \]

但该周期只产生

\[ H-R \]

个 token 的新增有效工作。

所以，每个新增工作单位的平均 prefill 时间为

\[ J(H;R,K) = \frac{ H+\frac{H^2}{2K} }{ S_0(H-R) }. \]

这是核心目标函数。

当

\[ H\rightarrow R, \]

分母趋近于零。系统反复重建巨大的保留上下文，却几乎不完成新的工作。因此平均成本会非常高。

在另一极端，提高 \(H\) 会让重建成本分摊到更多新增工作上，但周期中越来越大的部分会在 prefill 吞吐量退化的上下文长度下发生。

得到的目标函数呈 U 形。

最优压缩阈值为

\[ H^* = \arg\min_{H>R}J(H;R,K). \]

求导可得

\[ H^* = R+\sqrt{R^2+2KR}. \]

可以立即得到若干含义。

第一，最优阈值并不是最大上下文容量的固定比例。

第二，最优阈值取决于最小保留工作上下文 \(R\)。

第三，它取决于机器特定的退化参数 \(K\)。

第四，短上下文吞吐量 \(S_0\) 会缩放总执行时间，但在这个简化模型中不决定最优点。若两个系统的相对退化函数相同，即使它们的绝对 prefill 速度不同，也可能共享同一最优上下文阈值。

5. 一般形式

上述解析退化函数有助于说明，但对实现并非必需。

令观测到的经验 prefill 函数为

\[ \hat S(c). \]

令

\[ B(R) \]

表示重建大小为 \(R\) 的压缩后上下文所需的观测时间，并令

\[ F \]

表示压缩本身的计算成本。

则每个有效工作单位的平均时间成本为

\[ J(H) = \frac{ B(R) + F + \int_R^H\frac{dc}{\hat S(c)} }{ H-R }. \]

最优阈值就是

\[ H^* = \arg\min_{R<H\leq C_{\max}}J(H). \]

该表述不要求对 prefill 退化的数学形状作任何假设。

它还会通过观测函数 \(\hat S(c)\)，自动容纳硬件影响、推理引擎行为、量化 KV cache、模型架构及其他实现特定因素。

6. 从使用中学习最优上下文

并不需要专门 benchmark。

智能体 harness 在正常运行期间已观测到估计优化函数所需的信息。每个推理请求都可生成一个观测：

\[ (c_i,s_i), \]

其中 \(c_i\) 是上下文长度，\(s_i\) 是观测到的 prefill 吞吐量。

随着时间推移，这些观测会形成对

\[ \hat S(c). \]

的经验估计。

测量应关联到特定运行时配置，因为 prefill 行为不只是 GPU 的属性。一个有用的配置标识符包含

\[ \text{硬件} + \text{模型} + \text{权重量化} + \text{KV 配置} + \text{推理后端}. \]

例如，从 Q3 权重与 Q4 KV cache 改为 Q4 权重与 Q8 KV cache，通常应当形成不同的配置。

观测值可聚合到上下文分桶中，例如 5K 或 10K token 区间。中位数等稳健统计量可减少瞬时系统负载、异常工具输出、cache 效应或并发进程的污染。也可采用指数加权估计，使配置随软件或运行时变化逐步适应。

harness 同样可以观测压缩后的实际重建延迟，并估计 \(B(R)\)。

在关闭时、执行中定期进行，或在观测积累到足够数量后，这些统计量可以持久化。

在下一次启动时，harness 在可行的 \(H\) 取值上评估

\[ J(H) \]

并选择

\[ H^*. \]

该阈值在随后的运行时会话中保持固定，从而避免不稳定的在线策略变化，同时仍允许系统跨会话持续学习。

7. 从容量感知到吞吐感知的压缩

许多现有上下文管理策略可被描述为容量感知：

\[ H=\alpha C_{\max}, \]

其中 \(\alpha\) 例如可以等于 0.8。

这种规则回答的问题是：

在模型达到容量上限前，可以安全使用多少上下文？

它没有回答：

在什么上下文长度上，继续累积会比压缩并重建工作状态更慢？

这是不同的优化目标。

因此，我们区分三个量：

\[ C_{\max} = \text{最大上下文容量}, \]
\[ R = \text{最小可用工作上下文}, \]

以及

\[ H^* = \text{时间最优压缩阈值}. \]

一台模型可能支持 128K token，而某台特定机器上观测到的吞吐最优阈值可能是 82K。剩余容量仍可作为异常请求的余量而有价值，但日常运行不必消耗它。

这一区分对于本地推理尤为重要：硬件配置差异很大，且 prefill 退化可能在不同 GPU、统一内存系统、量化策略和推理后端之间显著不同。

8. 评估

该假设可用固定工作负载的长时程智能体任务来检验。

对于每个硬件和模型配置，实验应固定总有效工作负载和输出要求，同时改变压缩阈值 \(H\)。

例如，可要求一个智能体处理固定的累计工作负载，同时独立设置以下阈值：

\[ 60K,\ 70K,\ 80K,\ 100K,\ 120K,\ 140K. \]

对每种条件，测量：

  1. 总墙钟完成时间；
  2. 累计 prefill 时间；
  3. 累计 decode 时间；
  4. 压缩事件数量；
  5. 累计上下文重建时间；
  6. 随上下文长度变化的有效 prefill 吞吐量；
  7. 任务完成质量。

核心预测是：压缩阈值与总完成时间之间存在 U 形关系。

第二项测试将经验观察到的最小值与从被动学习的历史遥测所预测的阈值进行比较。

第三项测试将吞吐感知压缩与固定百分比基线进行比较，例如最大上下文的 50%、70% 和 80%。

关键结果不在于系统技术上能否支持更大的上下文，而在于在该上下文上运行是否提升总任务生产率。

9. 对本地 LLM benchmark 的含义

本地 LLM 性能通常用 decode 吞吐量概括。该指标有用，但对智能体工作负载而言正变得越来越不完整。

交互式智能体会反复执行 prefill、工具执行、上下文累积、状态重建与 decode。随着会话变长，即使 decode 保持很快，prefill 也可能成为延迟的主导来源。

因此，一张 GPU 即使每秒能生成 60 个输出 token，也可能比另一张每秒生成 45 个 token 的 GPU 更慢地完成长时程智能体任务，若后者能保持显著更高的长上下文 prefill 吞吐量。

最大上下文容量带来类似的测量问题。一个能够容纳 150K token 的系统，不一定在 150K token 上运行时更有生产率。

因此，我们提出 时间最优工作上下文，作为本地和智能体推理的附加系统指标。

更广泛地说，对 LLM 智能体的硬件评估应考虑完整工作负载：

\[ T_{\mathrm{task}} = T_{\mathrm{prefill}} + T_{\mathrm{decode}} + T_{\mathrm{tools}} + T_{\mathrm{compaction}} + T_{\mathrm{reconstruction}}. \]

最终相关的性能问题不是模型输出 token 有多快，而是系统完成有用工作的速度有多快。

10. 讨论

该框架得出一个反直觉结论：即使可用内存充足，更大的上下文窗口仍可能降低智能体生产率。

这并不意味着大上下文容量没有价值。更大容量提供灵活性，支持真正需要大段连续上下文的工作负载，也为溢出提供安全余量。相反，容量与运行点应被分开对待。

这一类比与其他计算资源相似。处理器最高时钟频率不一定是它最有效的持续运行点，可分配的最大内存量也不一定是应用应持续占用的内存量。

上下文同样应被视为受管理的运行时资源。

这一视角也改变了压缩的角色。压缩不只是模型接近上下文上限时启动的紧急机制；它可以是刻意用于将推理维持在有利性能区域内的日常调度操作。

最优策略同时取决于计算和信息。激进压缩可以改善运行时，却可能通过丢弃后续需要的信息而降低任务质量。因此，完整的优化目标最终应纳入信息损失惩罚：

\[ J_{\mathrm{full}}(H) = J_{\mathrm{time}}(H) + \lambda L_{\mathrm{information}}(H), \]

其中 \(L_{\mathrm{information}}\) 表示因压缩丢失信息所造成的预期下游成本。

本文得到的纯时间最优阈值，因此是上下文管理最终目标之前的必要第一步。

11. 结论

更长的上下文并非免费。

对于长时程 LLM 智能体，允许工作上下文增长会减少压缩频率，却可能逐步降低 prefill 吞吐量。压缩得过于积极则产生相反问题：系统会反复重建相当大的最小工作上下文。

这些相反成本意味着存在时间最优的工作上下文阈值。

与其把压缩阈值选为最大模型上下文的固定百分比，智能体 harness 可以从日常推理遥测中学习相关的 prefill 退化函数和重建成本。所得阈值针对实际模型、硬件、量化配置、后端和工作负载。

核心区分很简单：

\[ \boxed{ \text{最大上下文是容量属性。最优上下文是性能属性。} } \]

对于长时程 LLM 智能体，更大并不总是更快。