从1.05M到258K：上下文窗口、Token预算与KV Cache拆解

同一份模型，两个地方写着两个数：一个说一百零五万的上下文窗口，一个说二十五万 token 封顶。第一次看到这个对比的时候我也愣了一下，因为这两个数差的不是一点半点，是整整四倍。后来把请求日志、usage 字段、服务端配置和客户端默认参数逐个翻了一遍，才把这件事捋顺——上下文窗口这个词被用在了至少四个不同的地方，每个地方说的其实不是同一件事，而 token 计量上的进制差异又把水搅得更浑。这篇就把这笔账从头算一遍：两个数字各自从哪来、一次请求真正能用的余量有多少、为什么长上下文不是越大越好、以及在没有一百万 token 的现实里，怎么把活干完。不管你是刚接触代码助手的新手，还是天天跟 token 预算打交道的老手，下面这套拆法应该都能直接用上。

1. 1.05M 和 258K 这两个数字，到底各自在说什么

1.1 同一个模型被套上了四种"上下文"口径

先把最容易混淆的地方摊开。业内说"上下文长度"的时候，实际可能指下面四种东西里的任意一种，它们量级可以差出好几倍：

第一种是训练时的位置编码窗口，也就是模型在预训练阶段见过的最长序列。这个数是模型的物理属性，写在论文或模型卡里，改起来要大动干戈——要么重新训练，要么做位置插值或外推。

第二种是推理服务的单请求上限，通常对应服务端的一个max_model_len之类的配置项。它受显存约束，是一个部署决策，不是模型能力。同一个权重，部署在 A 集群上开 128K，部署在 B 集群上开 32K，完全合法。

第三种是客户端产品的默认值。编辑器插件、命令行工具、网页端，各自有一套自己的默认max_tokens和截断策略。这个数往往最保守，因为它要兼顾延迟、成本和失败率。

第四种是计费与配额口径。有些地方把输入和输出合并算，有些地方对缓存命中的部分打折，还有些地方按"请求数"而不是 token 数限流。

这四个口径混在一起讨论，就会出现"我明明看到写着一百万，怎么二十几万就报错了"这种困惑。我在排查类似问题时养成的第一个习惯，是先问一句：你说的是哪个数？问清楚这一句，后面能省掉一半的沟通成本。

1.2 用进制把两个数字反推一遍

数字对不上，先别急着怀疑人生，做个进制换算往往就有线索。1.05M 这个写法，最自然的来源是 2 的幂：

所以 1.05M 极大概率就是1,048,576，也就是 1024 × 1024，一个标准的 2^20 数。这个量级通常出现在模型卡、技术博客或者"最大支持"这类宣传性表述里。

再看 258K。按十进制 258,000 也说得通，但更可能是258 × 1024 = 264,192。注意 2^18 = 262,144，也就是标准的 256K，258K 和它只差 2,048。这个"差一点点"很关键——它说明 258K 大概率不是从 2 的幂直接来的，而是某个"配置值减去预留"之后的结果。

我做过一个简单的反推：如果服务端把上限设成 262,144（256K），再预留 8,192 token 给输出和内部边距，那么单次请求能塞进去的输入就是 262,144 − 8,192 = 253,952。这个数换成 K（除以 1024）是 248K，和 258K 还是有点距离。

换个算法：如果产品对外承诺的"可用上下文"是 264,192，即 258 × 1024，那它对应的服务端上限可能是 272,384 或者 270,336 这类更整的数。说实话，光靠数字反推只能缩小范围，确定不了唯一答案，但至少能得出一个结论：258K 不像是随手写的，它更像某个整数配置扣掉固定预留后的净值。

提示：以后再看到"X K"和"Y M"对不上的情况，第一步就做两件事——确认是 1000 进制还是 1024 进制，以及算一下两者的差值是不是某个整千或整万。差值往往就是系统提示词、输出预留或者安全边距的位置。

1.3 为什么两个数会同时存在于同一个产品里

最合理的解释是：这两个数描述的是不同层的限制，只是都被叫做"上下文"。

1,048,576 是模型层的能力声明，回答的是"这个权重理论上能吃多长"。258K 是产品层的实际可用额度，回答的是"你在这次请求里最多能塞多少"。中间那一层被砍掉的部分，去向大致有这么几块：

• 输出预留。生成侧要留位置，一般预留 4K 到 32K 不等，取决于任务类型。写代码的场景输出往往很长，预留会更大方一些。
• 固定系统开销。系统提示词、工具调用的 schema 定义、模式说明，这些每次都带，加起来轻松上万 token。
• 并发摊销。服务端不可能给每个请求都按最大窗口分配显存，实际能开多大取决于同时在线多少人。
• 安全边距。留一点余量防止边界情况下截断报错，这属于工程上的保守做法。

这四块加起来把 1M 砍到 258K，比例上是砍掉了约 75%，听起来夸张，但如果并发压力大、输出预留足，这个数字并不离谱。

1.4 判断两个口径是否可比的三步法

遇到"数字对不上"的争论，我现在固定走这三步，基本五分钟内能定性：

1. 看单位。是 token 还是字符？是 1000 进制还是 1024 进制？很多争议在这一步就消解了。
2. 看是全量还是净额。这个数包不包含输出？包不包含系统提示？包不包含工具定义？
3. 看是哪一层报的。是客户端在发请求前就截断了，还是服务端返回了长度超限的错误？这两种情况的现象完全不同——前者通常静默，后者一般有明确报错。

第三步特别重要。静默截断是最坑的，因为你不报错、不中断，只是模型莫名其妙地"忘了"前面说过的话。我在早期项目里被这个坑过两次，都是排查了半天以为是模型能力问题，最后发现是客户端悄悄把历史裁掉了。

2. 一次请求的 token 账本：你以为空的，其实早被吃掉三成

2.1 固定开销：每轮都在付费的那部分

很多人算上下文预算的时候，脑子里想的是"我要塞进去多少代码"，但实际上请求发出去的那一刻，就已经有一大块被占用了。这部分我叫它固定开销，特点是跟你的任务无关，但每轮都在。

代码助手类产品的固定开销主要来自三块：

• 系统提示词。身份设定、行为规范、安全约束、输出格式要求。写得细的产品，这部分轻松到 3K~8K token。
• 工具定义。文件读写、搜索、执行命令、补丁应用……每个工具的 JSON Schema 都要完整描述一遍。工具多的产品，这块能到 5K~15K。
• 对话框架开销。角色标记、分隔符、每轮消息的包装。单条不多，但几十轮累积下来也可观。

我实测过一个中等复杂度的代码助手配置：系统提示 4,200 token，工具定义 11,800 token，框架开销每轮约 60 token。也就是说，在用户打第一个字之前，已经有 16K token 被占用了。如果你的预算是 258K，那实际可用的只剩 242K 左右，占比 94%。看起来还好，但如果预算只有 32K，这 16K 就是一半，问题立刻严重。

2.2 仓库上下文：真正吃掉预算的大头

固定开销还算可控，真正让预算爆炸的是仓库上下文。一个中等规模的代码仓库，光文件树就能到几万 token，把关键文件全文读进来更是轻松几十万。

我做过一个粗略统计，在一次典型的"帮我修个 bug"的会话里，token 消耗大致是这样分布的：

把这张表加起来，一次中等复杂度的请求很容易落到 60K~120K。如果任务涉及跨文件重构，冲到 200K 以上完全不奇怪。这时候 258K 的预算就显得紧张了，而 1.05M 听起来还很宽裕——这就是为什么两个数字会引发争论：它们对应的是完全不同的使用体验。

2.3 输出预留为什么不能省

新手最容易犯的错是把输出预留压到很小，觉得"我只要它改几行代码，留 1K 够了"。这个想法在简单场景下成立，在代码场景下几乎必然翻车。

原因有三：

第一，代码输出密度低。同样表达一个意思，代码的 token 数通常是自然语言的好几倍，因为缩进、括号、换行、标识符都在占位。改一个函数，输出 500~2000 token 很常见。

第二，模型有"解释癖"。就算你只让它输出补丁，它往往还是会带上几句说明。预留不足会导致输出被硬截断，截断在半行代码上，后续解析直接失败。

第三，截断的代价不对称。多留 8K 输出预算，成本是多花一点钱；预留不足导致截断，代价是整个请求白跑一遍，还得重试。这笔账怎么算都是多留划算。

我现在的习惯是按任务类型分档预留：

2.4 一个可以直接用的预算公式

把上面这些整理成一个公式，每次发请求前心算一下，能避免大部分超限问题：

可用输入预算 = 服务端上限 − 固定开销 − 输出预留 − 安全边距

代入一组实测数字：服务端上限 264,192，固定开销 16,000，输出预留 16,384，安全边距 4,096。

264,192 − 16,000 − 16,384 − 4,096 = 227,712。

也就是说，标称 258K 的窗口，真正能用来塞代码和对话的，只有约 227K，也就是 222K 左右。这个数字和"25 万"的直觉又差了一截。

注意：安全边距不要设成 0。我见过因为边距留得太紧，加上中文字符分词后 token 数比预估多 10%，导致请求刚好卡在边界上失败的情况。留 2K~4K 边距，换来的稳定性远超那点成本。

3. 长上下文不是"越大越好"：注意力、KV Cache 与工程侧的取舍

3.1 "看得见"和"用得上"是两件完全不同的事

假设服务端真的把窗口开到了 1M，体验就线性变好吗？不是。这是长上下文领域最反直觉的一点：模型能接收 100 万 token，不代表它能在 100 万 token 里准确找到需要的信息。

业界常用"大海捞针"式的评测来量化这件事：在一段超长文本的某个随机位置埋一句特定信息，然后提问，看模型能不能捞出来。这类测试的结果普遍呈现两个规律：

一是中间塌陷。放在开头和结尾的信息，召回率明显高于放在正中间的信息。序列越长，中间那段"被忽略"的区域越宽。

二是长度衰减。同样是开头位置，序列长度从 8K 涨到 128K 时，召回率也会往下掉，只是掉得比中间慢。

这意味着什么？意味着 1M 窗口的有效利用率可能远低于你的想象。你在第 500K 位置放的那段关键代码，模型可能根本没"注意"到。相比之下，把同样的信息压缩到 30K 以内放在开头，命中率反而是更高的。

我自己做过一个粗略对比：同样是让模型定位一个函数定义，把整个文件（约 80K token）直接丢进去，和先用关键词检索出相关片段（约 6K token）再喂进去，后者的准确率高出不少，而且响应速度快了好几倍。这不是模型不行，是用法不对。

3.2 KV Cache 的显存账：为什么并发一上来窗口就得缩

要理解为什么服务端不肯老老实实开满 1M，得算一笔 KV Cache 的账。

Transformer 推理时，每个生成步骤都要复用之前所有 token 的 Key 和 Value，这些会被缓存下来。缓存大小近似为：

KV Cache 字节数 = 2 × 层数 × KV头数 × 头维度 × 序列长度 × 批大小 × 数据类型字节数

那个 2 是 Key 和 Value 各一份。拿一组常见的量化后配置代入：40 层、8 个 KV 头（已经用了分组查询注意力）、头维度 128、fp16（2 字节）、单请求：

看到问题了吧。单条请求在 1M 长度下要吃掉 170 多 GB 显存，这还没算模型权重本身、激活值、中间缓冲区。一张 80G 的卡连一条都放不下。即使堆到多卡，也只能支撑个位数的并发。

而 258K 对应 43 GB 左右，虽然也不小，但至少在一个可运营的范围内。如果再把 KV 头数从 8 降到 4，缓存直接减半到 21.5 GB，这时候才能谈"支撑一定并发"。

这就解释了那个看似矛盾的现象：模型能力声明 1M，产品实际给 258K，不是产品抠门，是账算不过来。

3.3 服务端为了让窗口开大，都做了哪些取舍

既然显存是硬约束，工程侧就有一堆手段往上挤空间。我梳理了几类常见的：

第一类，结构层面的。分组查询注意力（GQA）和多查询注意力（MQA）通过共享 KV 头来压缩缓存，这是目前最主流的手段。多查询注意力极端到所有头共享一组 KV，压缩比最大，但效果损失也最明显；分组查询是折中方案，一般 4 到 8 组是比较常见的配置。

第二类，缓存管理层面的。分页注意力把 KV Cache 切成固定大小的块来管理，减少显存碎片，提高实际利用率。前缀缓存则把相同的系统提示部分缓存起来复用，多轮对话时能省掉大量重复计算。这两个手段不会增大窗口，但能显著降低成本。

第三类，稀疏化层面的。滑动窗口注意力只保留最近 N 个 token 的完整 KV，更早的用压缩表示或者干脆丢弃。这种做法对"最近上下文"类任务友好，对"回头找很早信息"类任务不友好。

第四类，量化层面的。把 KV Cache 从 fp16 降到 int8 甚至更低，直接省一半以上显存。代价是精度损失，长序列下误差会累积。

第五类，位置外推。训练时只见过 32K，推理时想开到 128K，就得做位置插值或者旋转位置编码的底数调整。这类方法在中等倍数外推下效果还行，倍数一大就明显掉点。

把这些手段组合起来，一个产品从"模型原生 32K"做到"实际可用 258K"，是完全合理甚至偏保守的工程结果。而"1.05M"这个数，更可能是某种极限条件下的理论值，或者特定配置下的宣传口径。

3.4 什么时候该主动选择小窗口

反过来讲，就算服务端给你 258K，也不是所有任务都该塞满。我自己的经验是分场景：

• 单文件修改、函数补全：控制在 16K 以内，把相关文件全文放进去效果最好，比检索片段更准。
• 跨文件重构：32K~64K，用检索缩小范围，配合文件树提供全局视角。
• 全仓库理解、架构梳理：才值得上到 128K 以上，而且必须配合摘要和分层结构，否则模型会迷路。
• 长文档问答：优先切片检索，不要一次性全文丢进去。

窗口大小是预算，不是目标。这句话我贴在工位上贴了很久，因为它纠正了我早期"能塞多少塞多少"的坏习惯。

4. 自己量一遍：把真实可用边界测出来

4.1 测试设计：控制变量比堆参数重要

与其在论坛上跟人对数字，不如自己测一遍。做法不复杂，但要控制好变量，否则测出来的结果没意义。

我的测试设计是这样的：

• 固定随机种子，保证每次生成的填充文本一致，排除内容差异干扰。
• 每次只变一个维度，要么变序列长度，要么变信息位置，不要同时变。
• 每个长度点重复 5 次以上，因为单次结果波动很大，一次成功一次失败说明不了问题。
• 埋点信息要足够独特，用随机生成的无意义字符串，避免模型靠语义猜出来。
• 至少测 6 个长度档位，从明显安全的区间一直加到明显失败的区间，才能画出衰减曲线。

还有一个容易被忽略的点：要区分"输入超限"和"信息丢失"。前者是请求直接被拒，有明确报错；后者是请求成功但答错，这才是真正的有效上下文边界。

4.2 一个能跑起来的探测脚本

下面这段伪代码思路，换成任何 SDK 都能改出来。核心就是把"填充 + 针 + 问题"拼成一个请求，然后看模型能不能把针捞出来。

import random import string import json def make_needle(seed): rng = random.Random(seed) # 生成一个独一无二的标记，避免模型靠语义猜 token = "".join(rng.choices(string.ascii_uppercase + string.digits, k=12)) return f"【记录编号 {token}】", token def build_prompt(filler_text, needle_text, position_ratio, question): # position_ratio: 针插在整体文本的哪个相对位置（0.0 开头, 1.0 结尾） cut = int(len(filler_text) * position_ratio) return filler_text[:cut] + "\n" + needle_text + "\n" + filler_text[cut:] + "\n\n" + question def run_probe(client, target_tokens, position_ratio, repeat=5): hits = 0 for i in range(repeat): needle, token = make_needle(seed=target_tokens * 100 + i) filler = generate_filler(target_tokens) # 按目标 token 数生成填充文本 prompt = build_prompt(filler, needle, position_ratio, "上文里出现的那条记录编号是什么？只回答编号本身。") resp = client.complete(prompt, max_tokens=32, temperature=0) if token in resp.text: hits += 1 return hits / repeat # 主循环：长度 × 位置 双维度扫描 results = {} for length in [8192, 32768, 65536, 131072, 196608, 262144, 524288, 1048576]: for pos in [0.05, 0.3, 0.5, 0.7, 0.95]: try: acc = run_probe(client, length, pos) results[f"{length}_{pos}"] = acc except Exception as e: results[f"{length}_{pos}"] = f"error: {type(e).__name__}" print(json.dumps(results, ensure_ascii=False, indent=2))

几个实操细节要注意：

• generate_filler生成的内容要有一定结构（比如重复的日志行），不要纯随机字符，纯随机会让分母虚高，因为随机字符的 token 效率极低，同样的 token 数对应的字符数少很多。
• max_tokens=32是有意压小的，目的是排除模型长篇解释带来的干扰。
• temperature=0是为了可复现，虽然不完全确定，但能大幅降低方差。
• repeat=5只是个起点，如果某个档位的命中率在 0.4~0.6 之间摇摆，建议加到 20 次。

4.3 结果怎么读：三个关键信号

跑完之后会得到一张表，读这张表主要看三个东西：

第一个信号，首次明显掉点的长度。从 8K 一路扫上去，命中率从 100% 掉到 80% 的那个长度档，就是实际可用的"舒适区"上界。业界经验是，这个值通常在标称窗口的 1/4 到 1/2 之间，具体取决于模型和任务难度。

第二个信号，位置差异的幅度。如果开头命中和中间命中差很多，说明模型有强烈的中间塌陷。这时候用法的调整方向就很明确——重要信息往前放，或者重复关键信息。

第三个信号，报错类型的变化。在某个长度上突然开始大量报长度超限，那就是硬上限到了。这个上限和你拿到的配置值对一对，能反推出预留了多少。

我自己的一个实测结果大致是：标称 128K 的配置，在 32K 以内命中率稳定在 100%，到 64K 掉到 90% 上下，到 96K 掉到 70%，再往上就到硬上限了。这个 32K~64K 就是我实际工作中愿意信任的区间，超出去的部分我只当"有总比没有好"的兜底。

4.4 一个常被忽略的变量：任务难度

同一个模型、同一个长度，换个任务，有效上下文能差出一倍。

举个例子，"从长文里找一个唯一编号"是简单任务，几乎纯检索；"从长文里找编号并和另一处信息做对比再推理"是中等难度；"基于整篇长文做全局总结并指出矛盾"是困难任务。

这三种任务的衰减曲线差别很大。简单任务可能到窗口的 60% 才开始掉点，困难任务可能到 15% 就不行了。所以测的时候，一定要用你真实业务场景的任务类型去测，用别人的 benchmark 分数直接换算成"我能用多少"，误差会非常大。

5. 在两百多 K 的框里干活：把上下文当预算来管

5.1 先把候选集缩小，再谈塞进去

承认现实之后，思路就清晰了：既然窗口有限，那核心工作就变成"在发请求之前，把无关信息筛掉"。

我现在的流程基本固定：

1. 用关键词和符号做第一轮粗筛。函数名、类名、报错信息里的标识符，这些是最高效的检索信号。
2. 用文件树提供全局地图。把目录结构（只保留目录和文件名，不含内容）作为低成本的全局视图，通常几 K token 就够。
3. 按调用关系做扩散。找到入口函数后，顺藤摸瓜把直接调用的下一层带上，但只带签名和一两行注释，不带全文。
4. 最后才决定哪些文件带全文。通常不超过 3 个，且每个文件如果超过 800 行，只带改动区域附近的部分。

这套流程看起来麻烦，但它把"随机塞满窗口"变成了"精准投放"。实测下来，同样的任务，token 消耗能降 40%~60%，准确率反而是上升的。

5.2 把长文件压成"目录 + 摘要 + 片段"三层结构

对于必须带进去但又太长的文件，我用一个三层压缩法：

第一层是骨架。只保留 import、类定义、函数签名、模块级常量，把函数体全部折叠。一个 2000 行的文件，骨架通常 150~300 行，压缩比接近 10:1。

第二层是摘要。每个函数用一句话说明它做什么，这句话可以让模型自己生成，也可以从现有注释里提。几十个函数也就几百 token。

第三层是按需展开的片段。真正需要修改的那几个函数，才展开全文。

拼起来的格式大概是这样：

=== 文件：src/service/order_handler.py（共 1842 行）=== [结构] - class OrderHandler - __init__(self, repo, cache) - create_order(self, payload) -> Order # 创建订单，做参数校验和库存预占 - cancel_order(self, order_id) -> bool # 取消订单，释放库存 - _validate(self, payload) # 校验必填字段和金额合法性 - _reserve_stock(self, items) # 调用库存服务预占 ... [本次相关片段：create_order，第 120-198 行] <此处贴入完整函数体> [调用方参考：api/views.py 第 45 行] result = handler.create_order(request.json)

这个结构比直接丢全文信息密度高得多。模型能看清楚模块全貌，同时把注意力集中在真正要改的地方。我用这个格式处理过好几个上千行的文件，效果比全文塞进去稳定不少。

5.3 长任务拆成接力赛，中间产物落盘

有些任务天然就要跨很多文件，硬塞进一个窗口必然失败。这时候正确做法不是加大窗口，是拆任务。

我的拆法遵循两条原则：

原则一，每个子任务的输出都落盘。不要指望"模型记住了上一轮的分析结果"，把它写成文件。下一步的输入从文件读，而不是从对话历史里翻。这解决了两个问题：历史裁剪导致的信息丢失，以及长对话里注意力稀释。

原则二，子任务之间只传结论，不传过程。比如第一步分析了 50 个文件，产出的结论是一份"模块依赖清单"，那第二步的输入就是这份清单加少量关键文件，而不是把 50 个文件再带一遍。

实际执行的时候，我会建一个临时目录：

work/ ├── 00-task.md # 原始任务描述，每轮都带上 ├── 01-scan-result.md # 第一轮扫描结论 ├── 02-plan.md # 拆解出的修改计划 ├── 03-patch-a.diff # 子任务 A 的产出 └── 04-review.md # 复核结论

每一轮请求的上下文就是"任务描述 + 上一轮结论 + 本轮相关文件"。这个组合通常能控制在 30K 以内，稳定性和速度都很好。而且中途出问题可以单点重跑，不用整个流程重来。

5.4 一份可以直接抄的参数配置

把上面这些落成配置，大概是这个样子的。不同工具字段名不一样，但逻辑是通的：

再补一条经验：把"估算 token 数"做成自动的。每次拼完上下文，先跑一遍 tokenizer 算个数，超过阈值就自动降级（减少召回条数、裁剪片段）。靠人肉估算迟早会翻车，尤其是中英混排和带大量符号的代码场景。

6. 数字对不上时，我是怎么一步步定位的

6.1 先判断是静默截断还是显式报错

排查这类问题，第一步永远是分类。两种现象，排查路径完全不同。

显式报错好办。错误信息里通常带实际 token 数和上限值，直接一减就知道差多少。这时候看的是：是不是输出预留被吃掉了？是不是某条工具返回结果特别大？

静默截断才是真正的坑。表现是模型答非所问、忘记前文、重复提问。我的第一步操作是打开请求体，把实际发出去的 messages 打印出来，跟预期对比。十次里有八次，问题就出在这里——某处代码在发请求前做了裁剪，而裁剪逻辑没打日志。

我踩过一次特别隐蔽的：客户端按"消息条数"裁剪历史（保留最近 20 条），但其中有一条是超大的工具返回结果，占了 80% 的 token。结果就是条数没超，token 严重超，然后被服务端截断，而客户端以为发成功了。按条数裁剪是个坏设计，一定要按 token 数裁。

6.2 看 usage 字段里的三个数

只要服务端返回 usage 信息，问题基本就定性了。我关注三个数：

第一个数特别有用。我曾经遇到"模型总是忘记开头说的话"，一查 usage，输入 token 数比我拼的少了 30%，说明有一层网关在做静默裁剪。找到那一层之后问题十分钟就解决了。

第三个数则关系到成本。如果系统提示很长但缓存一直没命中，说明每次请求的前缀都在变——常见原因是系统提示里拼了时间戳或者随机 ID。把它挪到用户消息里，缓存命中率立刻上去。

6.3 几个高频误判，别在上面浪费时间

下面这些是我和周围人踩过的，列出来省得重复踩：

误判一：把"不同版本"当成"同一版本"。编辑器插件、命令行工具、网页端，三者的默认配置经常不一样。你在 A 里测出 258K，在 B 里测出 32K，很可能只是客户端默认值不同，跟服务端能力无关。先确认客户端版本号。

误判二：把"字符数"当"token 数"。中文、代码、JSON 的 token 密度差别巨大。一段看起来不长的 JSON，token 数可能是同等字符数中文的两倍。用字符数估算窗口占用，误差能到 3 倍以上。

误判三：把"首次请求"和"多轮之后"混着比。首轮请求没有历史，多轮之后历史会占掉一大块。同一个任务，第一轮很顺，第十轮就崩，这不是窗口变小了，是历史在涨。

误判四：忽略工具返回的体积。一次目录遍历返回几千行，一次搜索返回几十个文件的内容，这些都会瞬间吃掉预算。给工具返回加体积上限，超过就截断并提示"结果过多，请缩小范围"。

误判五：把"限流错误"当成"长度错误"。两者在某些网关上报的错很相似。区别方法是看请求本身大小——如果请求才 5K token 也报类似的错，那基本是限流或者配额问题。

6.4 一套五分钟定位流程

最后把我常用的流程固定下来，下次遇到"数字对不上"直接照着走：

1. 打印完整请求体，统计实际 token 数（用对应 tokenizer，不要估算）。
2. 对比 usage 里的输入 token 数，差多少、差在哪一段。
3. 检查输出 token 数是否顶到 max_tokens。
4. 检查客户端版本和默认配置，确认和服务端口径一致。
5. 检查有没有中间层网关做裁剪，看它的日志。
6. 用一个已知长度的最小请求做对照实验，排除偶发因素。

六步走完，百分之九十的问题都能定位。剩下那百分之十，通常是服务端侧的动态调整——这种情况你查不出来，只能通过多测几次、观察不同时段的差异来间接确认。

7. 关于这两个数字，我最后想说的

折腾这一圈下来，我最大的感受是："上下文长度"这个指标，单独拿出来看几乎没有意义。它必须绑定三个限定词才有讨论价值——是谁报的数、包不包含输出、在什么并发条件下。

如果非要给个实用建议，我的做法是：把标称值打个对折当作"舒适区上限"，再打个对折当作"高准确率区"。标称 258K，我就当 128K 用，关键任务控制在 64K 以内。这个经验值不一定适合所有人，但它让我少踩了很多"模型怎么突然变笨了"的坑。

还有个细节值得一提。我在实际项目里发现，把上下文压小之后，响应速度的提升非常明显，尤其是首 token 延迟。同样是改一个函数，塞 100K 上下文和塞 20K 上下文，等待时间能差出好几倍。所以压缩上下文这件事，收益不只是省成本，还直接改善使用体验。

至于到底是一百零五万还是二十五万八，我现在已经不太纠结了。真正该关心的是：你手上的任务，需要模型同时看到多少信息才能做对？把这个数测出来，然后为它留出两倍余量，剩下的窗口大小之争，交给写文档的人去吵就好了。