# 100 万 token 的窗口，真正能用的有多少？

*从「窗口宣称」到「保留率卡片」，重新理解长上下文能力*

选型会上最容易过关的一句话是：「这个模型支持 1M 上下文，够了。」

听起来没毛病。直到你把两百页合同整份塞进去，问它第 137 页那条免责条款怎么写，它回了一段流畅、自信、条理清楚的错误答案。没有报错，没有超时，接口返回 200，所有监控面板都是绿的。

窗口确实装下了那份合同。只是模型没有可靠地用到它。

![01-cover.png](https://developer.qcloudimg.com/http-save/yehe-1558800/73b5f5268afa83c5ff6283639bf8a523.png)

*图 1｜上面那条是标称窗口，下面那条才是可靠可用区。*

**核心结论：上下文窗口的标称长度只是一个「服务规格」，它告诉你模型最多能「接收」多少 token，却不告诉你它实际能可靠「使用」多少。真正决定长上下文能力的是保留率、有效长度、位置稳定性这些指标——而它们与标称窗口之间的相关性，远比市场宣传暗示的要弱得多。**

## 「能装下」和「能用上」之间的鸿沟

先厘清「标称窗口」到底承诺了什么。它承诺的是接口层面的接收上限：请求不超过这个长度，就不会被拒，不会被截断，不会抛 context length exceeded。它是一份容量规格，类似硬盘标 2TB。至于放进去的内容有多少能被稳定调取，规格里一个字都没写。

一个模型标称支持 100 万 token，并不意味着它能可靠地使用这 100 万 token。NeurIPS 2026 的一项研究直接检验了这一点：在 RULER 基准的 33 个模型上，广告中的上下文长度与「对数积分保留率」（LIR，衡量随长度衰减的能力曲线）的秩相关系数只有 **0.437**——中等相关，远非决定性的。

0.437 读起来有点抽象，换个说法就具体了：秩相关看的是「排名能不能对上」，把这个数粗略平方一下，窗口长度大约只能解释模型保留能力排名差异的两成。剩下八成，取决于训练数据怎么配、位置编码怎么外推、长样本占比多少、注意力预算怎么分配。换句话说，窗口更大的模型，实际保留能力未必更强；好几个大窗口模型在长上下文上的表现，反而不如窗口更小的同类产品。

LIR 这个指标本身也值得停一下。它不是「在 128K 这个点考了多少分」，而是把整条随长度衰减的曲线按对数长度积分：能力从哪一段开始掉、掉得多快、长距离区间还剩多少，全都算进去。用对数刻度是有讲究的，4K 到 8K 与 64K 到 128K 在横轴上占同样权重，长距离那段才不会被少数采样点一带而过。所以 LIR 高，说的是「整段路都走得稳」，不是「终点那一步没摔」。

有效上下文与标称窗口之间的落差，在多项独立测试中反复出现。经验数据显示，模型的**有效上下文通常只有标称值的 25% 到 50%**；如果任务是复杂的多跳推理而非简单检索，这个比例可能进一步收缩到 **10% 到 20%** 的水平。RULER 的早期数据显示，GPT-4 在 4K 上下文时准确率 96.6%，到 128K 时降至 81.2%——这还只是检索类任务，复杂推理的衰减幅度更大。

15 个百分点放在报表里不算刺眼。放在一次真实问答里就不是了：如果一轮回答需要串联 20 个分散在各处的事实点，这个跌幅意味着大约三个点会出错，而模型照样把答案写得完整漂亮。它不会告诉你哪三个。

常见的解释集中在三处。训练语料里长序列本来就稀缺，模型对远距离位置的经验远少于近距离；主流位置编码在超出训练长度后要做外推，两个 token 隔得越远，直接建立联系的强度越弱；再往下一层，同一份注意力预算摊到十倍长的序列上，每个位置分到的权重更薄，干扰项却更多。这三件事都不会因为把窗口参数调大而自动变好，有些反而更糟。

**只看标称窗口，相当于用油箱容量判断一辆车的实际续航，却忽略了油耗和路况。**

所以选型时第一个该问的，不是「能塞多少」，而是「从第几 K 开始不可靠，我这个任务落在哪一段」。

## 指标不是单一的：任务一变，「能力」就变

更麻烦的是，连「从第几 K 开始不可靠」这个问题都不能只问一次。换一套题，答案就变。

上下文指标的重要性，首先体现在它拒绝把「长上下文」当作一个单一维度来对待。

同一组模型、同一个 4K–32K 的长度区间，在 RULER 和 NoLiMa 两个基准上的保留率可以相差 **0.187 到 0.496 个 LIR 点**。模型没换，长度没换，只换了测法，能力读数就拉开这么大。

原因在于两个基准测量的东西不同：RULER 侧重于多针检索、追踪和聚合，NoLiMa 则刻意移除问题与答案之间的字面匹配线索，迫使模型进行语义关联。举个直觉上的例子，前者像问「文档里那串订单号是多少」，关键词就在纸上；后者像问「谁提过那次雨夜改方案」，而原文写的是「周三凌晨的紧急评审」，字面上一个词都对不上，只能靠语义搭桥。在字面线索存在时能捞到「针」的模型，在字面线索消失后可能迅速崩溃——11 个 SOTA 模型在 32K 长度、去除字面匹配线索时，表现跌到短上下文基线的 **50% 以下**。

![02-retention-curves.png](https://developer.qcloudimg.com/http-save/yehe-1558800/c303caac54e153dfbbb9b0cdb7746178.png)

*图 2｜同一个窗口，三条衰减曲线。曲线是机制示意，锚点取自 RULER / NoLiMa 类公开结果。*

更宏观地看，一项覆盖十大上下文基准的元分析发现，各基准排名之间的平均 Spearman 相关系数仅为 **0.55**，属于中等水平；单项基准评测的排名方差，比加权复合评分高出 **47%**。当前基准在聚合、生成和多轮对话等维度上存在严重的覆盖缺口。0.55 的意思是，你在 A 榜上看到的名次顺序，搬到 B 榜会有相当一部分被重新洗牌；而只盯单项榜单，波动比看复合评分大了将近一半。

这也解释了合成 NIAH 测试为什么总显得乐观：针和问题的字面重合度高，答案唯一，干扰项干净，干草堆常常是随机拼的文本。真实文档恰恰相反，段落连贯、主题相近、还带着几个「看起来很像答案」的候选句，这种似是而非的干扰比纯噪声更难扛。合成 NIAH 测试系统性地高估真实世界检索性能 **20% 到 40%**。如果你只用「大海捞针」一个指标来评判模型，你测到的只是一个狭窄的检索切面，而它在真实应用中的预测力是有限的。

给选型的人留一条很实用的规矩：先把自己的任务归类，再去找对应那一类的曲线。合同比对、代码库问答、长文档摘要、多轮 agent，落在图 2 的不同曲线上，甚至一条都不在。拿检索榜单的第二名去推断摘要场景的表现，中间隔着好几个没有证据的假设。

## 被平均分掩盖的失败：位置与轮次

传统指标最危险的地方，不在于它们测错了东西，而在于它们**把不该平均的东西平均掉了**。

「Lost in the Middle」揭示了一个稳定的 U 形曲线：关键信息在开头和结尾时利用率最高，在中间位置则显著下降。中部信息的准确率通常比首尾基线低 **10 到 25 个百分点**，而且这个中部凹陷会随上下文长度增加而**加深**——两跳推理任务中，上下文每翻一倍，准确率大约下降 **0.15**。开头占着首因优势，结尾贴着最新一轮，中间那段既没有位置特权，又要和越来越长的序列抢注意力，塌陷几乎是结构性的。

做个假设算例就明白平均分有多会骗人。把 128K 上下文按深度切成 20 桶，头尾各 3 桶是 95 分，中间 14 桶只有 68 分，加总平均是 76 分。报表上写「长文本任务 76 分」，看着还行；实际上只要关键信息落在中间七成的位置，这次调用就不太可靠。错误不是随机撒的，它们成片堆在同一个深度区间。

一个模型在 128K 上的「平均分」可能看起来体面，但它的错误高度集中在某个深度区间，而平均分把这种系统性偏差抹平了。

多轮对话引入的是另一种被平均掩盖的衰减。单轮任务中表现 90% 的模型，在多轮、信息逐步给出的欠定义对话中，平均任务表现降到约 **65%**，落差 25 个百分点。机制上有个很人性化的毛病：信息还没给全的时候，模型倾向于先把答案定下来，后面补充的条件进来了，它不回头改。于是轮次越多，越像是在跟一个已经拿定主意的人解释。一项覆盖 18 个前沿模型的测试发现，「上下文腐烂」导致中部位置的准确率下降 **30% 以上**。

在生产环境中，这种衰减有非常具体的形态：一个客服 Agent 在 3K token 会话中任务完成分数为 **0.92**，当同一会话拉伸到 32K token 时，同一评分标准下分数降到 **0.71**——提示词没变，模型没变，变的只是会话长度。多出来的那些 token 是历史消息、工具返回、几轮澄清、反复出现的系统提示，每一条单看都合理，堆在一起就把注意力摊薄了。而它跨过了一条没有人监测的保真度阈值。

![03-position-and-turns.png](https://developer.qcloudimg.com/http-save/yehe-1558800/9d3a61c5ea7c0b0b97a8f2721b8447aa.png)

*图 3｜左边是位置，右边是轮次。两端锚点取自客服 Agent 场景，中间点为示意插值。*

这类问题在监控里通常长这样：整体成功率缓慢下滑几个点，客诉里却开始出现「它明明看过我前面说的」这种描述。没有异常日志，没有失败重试，只有一条安静下滑的曲线。想抓住它，报表就得换粒度：按深度分桶报准确率，按轮次分桶报完成率，再单列一个最大局部跌幅。全局平均可以留着做趋势，但不能拿它做验收。

**指标的重要性，恰恰在于它应该监测那条阈值在哪里，而不是只报告一个全局平均。**

## 指标的另一面：成本本身就是一个上下文指标

讨论上下文指标时，容易忽略一个事实：**成本和延迟不是「代价」，它们本身就是能力边界的一部分。**

这句话不是修辞。一个长度在账上跑不通，它在能力上就等于不可用，哪怕准确率还撑得住。

长上下文的 Token 成本不是线性增长的。Self-attention 的平方项意味着，上下文从 1K 到 128K，注意力部分的相对成本增长到约 **16384 倍**：每个 token 要和序列里所有 token 打分，长度翻 128 倍，计算量翻 128 的平方。生成阶段的 KV Cache 则是另一笔独立账，它不跟着计算量走，跟着「这次会话要在显存里常驻多久」走——一个 8B 级别的 GQA 模型，128K 上下文仅 KV Cache 就需要约 **16 GB** 显存。并发一上来，先撞墙的常常是显存，不是算力。在服务层面，256K 上下文相比 16K，每生成一个 Token 的成本高出 **3.6 到 7 倍**。

![04-cost-and-routing.png](https://developer.qcloudimg.com/http-save/yehe-1558800/82ac005a31d3977b24e5a6095d200507.png)

*图 4｜左边是随长度上涨的三笔账，右边是把「长度」变成可决策变量之后的收益。*

于是准确率数字必须和账单一起读。Long Context 在准确率上可以优于 RAG（56.3% 对 49.0%），但单次查询的 Token 成本差距可达 **50 倍**。7.3 个百分点值不值 50 倍？没有通用答案：一次性的招股书精读、低频的法律尽调，多花这笔钱买全量视野很划算；日均百万次调用的客服或推荐链路，同样的 7.3 个百分点会把毛利吃穿。脱离场景谈「Long Context 赢了 RAG」，跟脱离路况谈续航是一回事。

这些数字之所以是「指标」问题而非单纯的「工程」问题，是因为它们决定了**哪些上下文长度在什么场景下才值得被追求**。混合架构的实测给出了一个参照：基于熵的自适应路由在长上下文基准上保留了纯长上下文基线 **97.4%** 的准确率，同时将总 Token 支出降低 **70.7%**，只把 **18.2%** 的查询升级到长上下文处理。

有意思的是最后那个 18.2%。它说明绝大多数请求根本不需要长窗口，真正难的那部分可以被识别出来。而「识别」靠什么？靠一套能判断当前输入是否需要升级的指标，以及一条有依据的阈值。没有一个合理的指标体系，这种「在什么长度上用什么策略」的决策就无从做起，最后只能拍脑袋定个「超过 8K 就走长上下文」，然后为另外 80% 的请求白付钱。

## 结语：从「窗口宣称」转向「保留率卡片」

上下文指标对大模型的重要性，归根结底不在于给出一个更大的数字，而在于**把「长上下文能力」从一个营销标签还原为一个可测量、可比较、有条件的能力剖面**。

NeurIPS 那篇论文的建议值得作为这场讨论的落点：与其报告一个单一的上下文长度宣称，不如报告一张 **Context Retention Card**——包含随长度变化的保留率曲线、基线分数、LIR、一族上下文「半衰期」数值，以及最大局部跌幅。

![05-retention-card.png](https://developer.qcloudimg.com/http-save/yehe-1558800/e4ff994b10ce6c3e6e92c65a62ad6a85.png)

*图 5｜保留率卡片的字段示意，数值为模板示例，不是实测结果。*

这张卡片上的每个字段，都在回答一个原先被含糊过去的问题：

1. **保留率曲线**：能力从哪一段开始掉，掉得是缓是陡。
2. **短上下文基线**：这个模型在不受长度干扰时本来能考多少分，衰减要跟它比，不能跟绝对值比。
3. **LIR**：整段长度区间上的综合能力，用来替代某个长度点的单点分数。
4. **一族「半衰期」**：检索、多跳、语义关联各自掉到基线一半的长度。之所以是一族而不是一个数，正因为第二节说的那件事——任务一变，能力就变。
5. **最大局部跌幅**：最坏的那个深度区间有多坏。它比平均分更能决定一次线上调用会不会翻车。

这张卡片不会告诉你「我们的窗口有 100 万」；它会告诉你，在什么长度上、什么任务下，这个窗口还有多少是真正可用的。

对于使用大模型的人来说，这意味着把评估的重心从「它能装多少」转向「它在多长的时候开始失效、失效发生在什么位置、代价是什么」。落到日常动作上，大概是这样几步：先把自己的真实任务按检索、多跳、生成、多轮分个类；再拿这个类别的样例，在若干个长度点上各测一轮，而不是只在标称上限测一次；把样例按位置打散，看中段有没有塌；最后把 token 账单和延迟一起贴到同一张表上。做完这四步，你手上就有了一张属于自己的、小得多的保留率卡片，比任何榜单都更贴近你的线上表现。

对于构建大模型的人来说，这意味着承认一个根本约束：**上下文指标的价值不在于证明窗口更大，而在于诚实地标出能力的边界在哪里。**

---

**资料备注**：文中涉及的公开研究方向包括 RULER（NVIDIA，2024，多针检索 / 变量追踪 / 聚合）、NoLiMa（Adobe Research，2025，移除字面匹配线索）、Lost in the Middle（Liu et al., 2023 / TACL 2024，位置 U 形曲线）、Context Rot（Chroma，2025，输入变长带来的持续退化），以及 LongMemEval、BABILong 等长程记忆与推理基准。本文具体数值沿用原稿口径，配图中的曲线形状用于说明机制，不作为实测数据引用。



听起来没毛病。直到你把两百页合同整份塞进去，问它第 137 页那条免责条款怎么写，它回了一段流畅、自信、条理清楚的错误答案。没有报错，没有超时，接口返回 200，所有监控面板都是绿的。

你的模型有 100 万上下文，能用的可能只有 10%

100万token的上下文窗口，真正可用的仅25%-50%，复杂任务下甚至不足20%。标称长度仅反映接收上限，实际有效使用受保留率、位置稳定性与任务类型影响极大。多跳推理、长对话中模型易“丢失中间信息”，平均分掩盖系统性衰减。成本亦是关键指标：长上下文计算开销呈平方级增长，单次调用成本可高出50倍。选型应聚焦真实任务场景，结合有效长度、成本与局部表现，而非盲目追求标称窗口。

高级技术架构师、产品售前专家

人工智能

后端

架构设计

100万token标称窗口实际可靠利用率仅25%-50%，复杂任务甚至跌破20%。从RULER到NoLiMa，不同基准排名相关度仅0.55。长文本能力受位置编码、注意力分配和任务类型制约，中段信息准确率骤降10-25%。选型需按任务分桶测试，用保留率卡片替代单一窗口宣称。

路由

Agent

腾讯云双十一大促

tione

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

你的模型有 100 万上下文，能用的可能只有 10%-腾讯云开发者社区-腾讯云

你的模型有 100 万上下文，能用的可能只有 10%

你的模型有 100 万上下文，能用的可能只有 10%

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐