"1M 上下文上限"与"实际可用 500K"可以同真——RULER 与 NoLiMa 在 200K 之外与营销页有 30–60 分的分歧，这就是如今诚实的规划数字。
Gemini 3.5 Pro 报的 ceiling 是 2M。Claude Opus 4.7 报 1M。都是真实数字，也都会误导规划——RULER 说 200K 以外的有效可用上下文约为 ceiling 的 55%，NoLiMa 一致，MRCR v2 更低。给提示词的预算按有效值，而不是广告值。这篇讲三份基准、它们与营销数字为何不同，以及三种能挽回部分差距的提示形状。
三份与营销页不合的基准，以及它们各自到底测的是什么。
广告标称的 token 上限只测一件事：模型不截断能接受多少。这是一个真实的数字，但不是你该拿来规划的那个。2025–2026 年间有三份基准变得承重，因为它们测的是你该拿来规划的那个——一份长提示里，模型能用多少。RULER（NVIDIA 推出，2026 年被扩展）是一套多任务的检索与推理套件，用大海捞针、多跳、聚合等子任务在每个上下文长度上给模型施压。NoLiMa 是长上下文下的纯字面检索测度：把一条事实埋在噪声里、要求取出、打分。MRCR v2（多轮上下文回忆，v2）是多轮变体——把事实撒在若干回合里，问一个需要同时回忆其中数条的问题，打分。
三者在具体百分数上不一定一致，但在形状上一致：曲线在大约 100K–200K 之前几乎贴着模型短上下文的分数走，之后向下弯。营销页上显示"1M tokens"处是一条水平线；诚实的规划曲线在 500K 时约为短上下文分数的 50%–70%，再往后更差。上下文窗口这一概念把 ceiling 引作硬上限；这一篇补的是：ceiling 之内还有一道更软的上限，它可测量、也是预算决策真正生长的地方。
Effective-context comparison, RULER + NoLiMa + MRCR v2 (2026 refresh) Model / benchmark | 4K | 32K | 200K | 500K | 1M | Advertised ----------------------|-------|-------|-------|-------|-------|----------- Gemini 3.5 Pro / RULER| 96.4 | 93.1 | 78.2 | 61.7 | 48.3 | 2M Gemini 3.5 Pro / NLM | 95.0 | 90.8 | 74.5 | 55.9 | 40.2 | 2M Claude Opus 4.7 / RULR| 97.2 | 94.6 | 82.4 | 65.8 | n/a | 1M Claude Opus 4.7 / NLM | 95.5 | 91.3 | 77.1 | 58.4 | n/a | 1M GPT-5.1 / RULER | 96.8 | 93.9 | 79.6 | 62.0 | n/a | 512K GPT-5.1 / MRCR v2 | 92.4 | 87.6 | 68.3 | 47.9 | n/a | 512K Read: past ~200K, effective-context scores drop 30-60 points from short-context. Numbers illustrative of the shape; check the live leaderboards before planning.
差距：200K 之外的 30–60 分，以及它对规划意味着什么。
短上下文准确率与长上下文准确率之间的差距，就是团队围绕广告 ceiling 做规划时会踩错的地方。一个模型在 4K 提示上打 95 分、同类任务在 500K 上打 55 分，对这个任务它就不是"1M 上下文"工具；它是"200K 上下文、以后逐步退化"的工具。落到规划上的后果是具体的。如果你的智能体的活儿是与检索相邻的——从上传的 PDF 里抓一条事实、在长对话历史里作答——那么控制通过率的是"有效上下文"这个数字，不是 ceiling。如果你的智能体跑多轮流程、第 3 回合埋下的事实要活到第 40 回合，那么该看的是 MRCR 式的指标，其数字比只做检索的那些更低，因为状态在累积。
上下文预算那一篇讲了分类别的令牌预算纪律；这一篇是把预算逼小于 ceiling 的力。如果诚实的可用数字是 500K，那么你的分类别预算之和就必须落进 500K——而不是 1M——并且对准确率最要紧的类别（近期回合、当前任务指令、刚检索来的证据）要放在注意力仍能落到的位置，而不是尾部。你据以做规划的那篇稿子，不是营销页写的那篇。
差距为何真实、并非基准伪影。
团队对这道差距的第一反应是"基准不公——真实提示不长得像 RULER 的干草堆"。这话对了一半、错了大半。原因是 RULER、NoLiMa、MRCR 测的不是"模型多擅长它们那些具体任务形状"，测的是长度之下底层的注意力行为，而这份行为会泛化到"必须在长提示里找出并使用一小片"的任何任务。机制被研究得很清楚：注意力权重在整条提示上分布，长上下文极端下，分给任一具体承载事实的 token 的质量会跌到噪声底之下——除非周围结构给了模型重新定位的方法。位置编码、KV 缓存招数、2026 年的稀疏注意力变体把这个数字往上推，但没有一个能把曲线弄平。
第二反应是"我们微调一下"。微调会改善任务专属基线，但不改变"有效上下文"曲线的形状——微调过的模型仍会随长度下降，只是起点更高。真正管用的是重塑提示，让模型一开始就不必去解那个长上下文难题，这是下一步的主题。
三种提示形状的挽回：锚定、分块召回、问题在前。
在一个固定的有效上下文上限下，三种提示形状能不换模型就挽回可观的准确率。第一是位置锚定：不要把检索得到的证据丢到提示中间，把它放到靠近问题的、命名过的、结构化的锚点——一个标注的 <evidence> 块、一份反向目录、一段显式的"下面三段就是你需要的"前言。锚定不是越狱、不是花招；它是给注意力头一个靠近查询的地标可看。仅靠锚定，200K 处的 RULER 提升往往是 5–15 分。
第二种是分块召回：需要跨长段推理的任务，不要把整段拷进一条提示。把源分块，让模型逐块产出带显式引用的摘要，再把摘要喂回做推理那一轮。这是拿一次昂贵的长上下文调用换若干条更短的调用，有效上下文曲线会奖励你这么做。上下文压缩阶梯那一篇把这当作通用模式；在长上下文这里的结果是，分块召回能把检索形任务的成绩挽回到接近营销页数字的位置。
第三种是问题在前、上下文在后。查询写在提示顶部（长文之前）比写在底部锚定注意力的方式不同。有些模型家族对此更敏感——Gemini 与 Claude 在长上下文下"问题在前"都有可测提升，GPT 则差一些——但即便只挪 3–5 分的模型也是白捡的分。
# A position-anchored prompt template that recovers ~10 pts at 200K. <query> {question} </query> <evidence anchor="primary"> {top_k_retrieved_passages} # landed near the query, named, structured </evidence> <context source="session-history"> {summarized_prior_turns} # compacted, not verbatim </context> <instructions> Answer the <query> using only <evidence>. Cite by anchor id. If <evidence> is insufficient, say so; do not answer from <context>. </instructions>
规划规则：把 ceiling 的 60% 当作可存活预算。
从三份基准与那些挽回手段一起浮出的可存活规划规则是：对"模型必须从长上下文里检出并使用内容"的任务，把广告 ceiling 的 60% 当作实操数字来做预算。对能被锚定、分块召回、问题在前所结构化的任务，可以推到 ceiling 的 70%–75%、准确率损失还能接受。再往后，即便准确率曲线没赢，成本曲线也会赢——长上下文调用更慢更贵，且让它们负担得起的缓存策略假设"你不会把提示尾巴填成模型反正也不看的内容"。
规则按任务类别是非对称的。纯检索（找一条事实）比"跨很多事实做推理"能承受更高的填充比。"早期回合日后仍重要"的多轮流程能承受的最低——MRCR v2 的数字是要看的、也是营销页最少提的。如果一份工作负载诚实的规划数字是 200K，但它的便利数字是 1M，那么正确的架构是：一套让 200K 保持新鲜、把其余按需从外部存储中检回的记忆系统——正是本组记忆与上下文系列一路建向的那种架构。