当前位置：首页 > news >正文

LLM 长上下文的工程陷阱：百万 Token 窗口不是白给的

news 2026/7/14 16:03:03

Claude 的 200K、Gemini 的 1M、GPT-4 的 128K——模型厂商在长上下文上的军备竞赛已经持续了一年多。每次新模型发布，"百万级上下文"几乎成了标配宣传词。

但把长上下文接进生产系统的团队会发现一个让人困惑的现象：256K 的上下文窗口打开后，成本并没有线性增长，而是跳了一个数量级；延迟不再是首 Token 时间变长这么简单，而是整个响应的稳定性都变了；有些场景下塞进完整文档反而比用 RAG 分片检索效果更差。

这不是模型不行，是工程侧的上下文管理和打开窗口不是一回事。

长上下文的成本不是线性的

先说最容易算的一笔账。模型 API 按 Token 计费，128K 的输入比 32K 贵几倍，这大家都理解。但做了预填（Prefill）优化的模型，长上下文的实际成本曲线比 Token 单价反映的更陡。

原因在于计算成本结构。模型的 Prefill 阶段需要对整个输入序列做并行注意力计算——输入越长，这一步的计算量按 O(n²) 增长（准确说是 Prefill 的计算量约等于 n × d × L，其中 L 是层数，n 是序列长度）。这意味着把上下文从 32K 翻到 64K，Prefill 阶段的算力消耗不是翻倍，而是接近 4 倍。虽然推理引擎和硬件在做优化（Flash Attention、PagedAttention），但这个增长曲线是底层注意力机制的数学约束，优化只能降低斜率，不能变成线性。

解码（Decode）阶段的成本也同样受影响。生成长文本时，每一步都要与全部历史 KV Cache 做注意力。KV Cache 的大小与上下文长度成正比——128K 上下文的 KV Cache 是 32K 的 4 倍，意味着每生成一个 Token，GPU 显存的读取压力和访存延迟都显著增加。

所以你会看到这样一个现象：同样是输出 500 Token，上下文 32K 的请求可能 1-2 秒完成，而上下文 128K 的请求可能要 5-8 秒。大量团队在迁移到长上下文模型后发现，P99 延迟曲线出现了"翘尾"——小部分请求因为上下文特别长，延迟拖到了不可接受的范围。

厂商给的 Cache 机制不能解决所有问题

Anthropic 和 OpenAI 都提供了 Prompt Caching——对重复的上下文前缀做缓存，命中后 Prefill 阶段成本大幅降低。这是个好功能，但工程上不是万能药。

第一个限制是缓存只在精确匹配前缀时才生效。很多实际场景中，每次请求的上下文都有动态变化——用户输入不同、检索结果不同、Agent 的执行历史不同。如果你的系统提示 + 固定文档能被缓存，但动态插入的内容变一下，缓存就断了。

第二个限制是缓存的生命周期。Anthropic 的 Prompt Caching 在最后一次使用后 5 分钟过期。如果请求间隔大于这个时间，下次请求又要重新计算 Prefill。对于低频但上下文很大的查询（比如批量文档分析），缓存几乎不生效。

第三个限制被很多人忽略：即使缓存命中率很高，长上下文的解码成本还是没有降低。Cache 只省了 Prefill，Decode 阶段的 KV Cache 依然随着上下文长度增长。你省了一半的 Prefill 钱，但 Decode 的延迟和成本还是 4 倍于短上下文。

长上下文不能替代检索

长上下文最常被拿来和 RAG 做比较。一种流行观点是"既然模型能看百万 Token，为什么还要费劲做 RAG？"这个观点在演示场景里成立——把整本书塞进去让模型总结，效果确实好。

但在生产系统里，长上下文和 RAG 面对的是不同的问题。

RAG 的核心优势不是"模型看不到完整信息"，而是它通过检索引入了选择性——系统决定哪些信息对当前任务有用，而不是把所有信息都交给模型去过滤。这个选择过程本身就是质量保障。当上下文里塞进大量不相关内容时，模型在注意力分配上会出现所谓"大海捞针"问题：相关信息被淹没在无关信息中，导致回答质量下降。

OpenAI 和 Anthropic 自己的评测都显示，在一些检索类型的任务上，RAG + 短上下文的组合效果优于纯长上下文。原因很直观：检索先做了一道信息筛选，模型只需要在筛选后的高密度相关信息上做推理。

工程上的合理做法是两者的结合，不是替代。大多数生产案例走的是"检索精化 + 长上下文兜底"的路线。先用检索把候选信息压缩到合理长度（比如几千 Token），扔进模型；如果模型判断信息不够，再触发第二阶段的完整文档加载。

上下文窗口的分层管理

生产系统中，一个 Token 不是平等的。用同一个上下文窗口装所有内容，既浪费又危险。好的做法是把上下文分成几个层级：

系统层——指令、安全约束、输出格式定义。这部分在整个服务周期内几乎不变，最适合利用 Prompt Caching。

会话层——用户的多轮对话历史、当前会话的 Agent 执行轨迹。这部分的增长需要做截断或摘要，不能无限累积。

知识层——从外部检索来的文档、数据库查询结果、工具调用返回。这部分应该是最动态的，也是最需要做质量控制的。

工具层——工具的描述、参数 schema、当前可用的工具列表。这部分长度相对固定。

理解了分层之后，长上下文的工程问题就变成了"哪一层需要长上下文"。大多数情况下，真正需要长上下文的是"知识层"——检索系统找到的相关文档需要更大的窗口来承载。而"会话层"做长上下文通常只有副作用：模型会从早期对话中找到已经过时的上下文来干扰当前判断。

落地时应该怎么评估

如果你的团队正在用或者计划用长上下文模型，有几个可以量化的检查点：

第一，计算你的有效成本。打开长上下文后，不要只看 Token 单价，要看"单次查询的实际费用"。加上缓存命中率、平均上下文长度、输出 Token 数，算出真实的每查询成本。你会发现大上下文请求的实际成本比 API 定价牌上看上去高得多。

第二，测量延迟的分布。不要只测平均延迟，看 P95 和 P99。长上下文请求的延迟方差很大，这会影响超时设置和用户体验。一个 Agent 工作流里如果有多个长上下文步骤，每一步的 P99 延迟累加起来可能超出用户的承受范围。

第三，做上下文长度的消融实验。同样的任务，用 8K、16K、32K、64K 各跑一遍，看质量曲线的拐点在哪里。很多任务在 16K 之后质量提升就很有限了，这时多花的钱就是浪费。

第四，对比 RAG + 短上下文和纯长上下文。用同样的任务评估集，对比两套方案的准确率、延迟、成本和故障率。据我所知，大多数内部评测的结果是 RAG 方案在成本和延迟上占优，质量打平或略优。

边界和风险

长上下文在两类场景下是真正的利器：一是需要对完整内容做全局理解的推理任务（比如长文档的对比分析、代码库级别的重构），二是信息密度高、检索难以精化的场景（比如密集的法律条文、科学论文中的细节引用）。

但它不适用的场景也很清楚：高并发低延迟的在线服务、频繁调用的 Agent 工具步骤、以及大量无关信息混入时。

如果团队已经部署了长上下文模型，建议在生产环境里做上下文长度的上限收敛——不要让开发者无限制地往上下文里塞东西。设定一个团队内部认可的合理上限（比如大多数请求不超过 32K），超过上限的请求必须经过评估并记录原因。这个约束听起来简单，但在实际生产中是最容易被忽视的。开发者给 Agent 加上"读取全部文档"的能力后，系统很快就会变得又慢又贵，而问题根源往往不是模型不够好，而是工程上没有一个上下文的"预算管理"机制。