1.05M还是258K？上下文窗口与Token计数实测

上周有个做代码助手的朋友甩给我两张截图一张写着 1.05M一张写着 258K问同一个模型怎么会有两个上下文长度。我第一反应是这俩数字根本不在一个维度上——1.05M 落在 1,048,576 附近258K 落在 262,144 附近两个都是 2 的幂附近的整数这说明它们是按不同“档位”分别配置出来的而不是同一个量被量了两次。把 GPT-5.6 Sol 的上下文窗口和 Codex 入口的上下文窗口当成同一个东西去比本身就已经比错了对象。这篇东西想解决的就是这类困惑为什么你在文档页、控制台、代码专用入口、SDK 返回值里看到的上下文上限对不上1.05M 和 258K 这两个数字各自意味着什么以及最关键的——你自己动手怎么在半小时内把真实可用长度测出来而不是靠猜。写给我这种天天要往请求里塞长文件、长日志、整仓代码的人看也写给刚接触 API、被 token 计数搞晕的新手。不需要你懂模型内部结构会跑 Python、会看返回的 usage 字段就够了。1. 先把“上下文窗口”拆开一个词背了三个量的锅1.1 总窗口、输入上限、输出上限从来不是同一个数绝大多数关于上下文长度的争论都死在把三个不同的量混着叫“上下文”。第一个量是总窗口context window指的是单次请求里“输入 token 输出 token”加起来的天花板它是模型结构决定的硬边界超了直接拒绝。第二个量是最大输入max input也就是你能塞进去的提示词部分它等于总窗口减去给输出预留的预算。第三个量是最大输出max output是你通过参数显式声明的生成长度上限同时也被服务端再削一刀。举个具体例子你就明白了。假设某档配置的总窗口是 262,144服务端给输出预留 4,096工具定义和系统提示再吃掉一点那你能用的输入就在 258K 附近——258K 这个数字本身就带着“从 256K 里扣出来”的味道。反过来1,048,576 是 2 的 20 次方这个数字太规整了规整到不像实测值更像是一个标称档位。两个数差 4 倍正好是 2 的 2 次方这种整数倍关系几乎可以断定它们来自两套不同的配置表而不是同一套配置的两个测量结果。所以看到“到底是 1.05M 还是 258K”这种问法正确的回应不是二选一而是先反问这个数字是在哪个界面看到的、它标注的单位是 token 还是字符、它是输入上限还是总窗口。这三个问题问完一半的争论自动消失。概念含义典型来源常见误区总窗口输入 输出的硬上限模型规格页被当成“我能塞多少 prompt”最大输入总窗口减去输出预留控制台参数说明被当成总窗口最大输出单次生成 token 上限请求参数max_tokens以为不占窗口有效上下文性能不明显退化的长度评测报告被当成标称上限计费上下文实际被计费的 token 数返回的 usage 字段被忽略其实最可信这张表建议存下来。后面所有排查我都按这五行的顺序往下对账。1.2 为什么偏偏是 1.05M 和 258K 这两个奇怪的数1,048,576 这个值任何人写过几年底层代码都会有生理反应——它是 1MiB是 2 的 20 次方。把它写成“1.05M”是一种十进制近似方便人类阅读但技术含义上它是二进制对齐的。同理 262,144 是 2 的 18 次方也就是 256KiB 那个位置258K 比 256K 多出一点点很可能是 262,144 减去固定预留后再加上某个零头或者是把 258,048、258,400 这类数字四舍五入后的口语说法。这个观察的价值在于只要数字贴着 2 的幂它就不是测出来的是配出来的。配置出来的数字意味着两件事。第一它可能只是“这一档允许的最大值”不代表模型在这个长度上还能好好干活。第二同一个模型可以同时存在多个档位不同入口按自己的产品定位选不同的档——面向长文档分析的入口选大档面向实时代码补全的入口选小档因为补全场景对首字延迟极度敏感塞 100 万 token 进去等 40 秒才出第一个字产品上根本没法用。我自己踩过的一个坑早期我以为某个入口给的上下文小是“阉割”后来把同样的长文档分别喂给两个入口发现小档那个不仅快答案质量还更稳。大档把整本手册塞进去之后模型开始在中段丢细节。这不是模型不行是我把“能塞进去”和“能处理明白”当成了同一件事。1.3 tokenizer 不同同一段文本在两边的计数可以差出三成这一点最容易被忽略但它是“同一段代码A 入口说没超B 入口说超了”的头号原因。token 不是字符切词规则由 tokenizer 决定而不同版本、不同入口的 tokenizer 完全可能不一样。同一份 10 万行的日志文件在旧切词器下可能算出 21 万 token在新切词器下算出 26 万 token差距 20% 以上很常见。代码场景下这个偏差更夸张。代码里有大量缩进、重复的标点、长变量名、base64 串、哈希值。一段 64 位十六进制哈希在字符层面是 64 个字符某些切词器会把它切成 30 多个 token另一些可能有专门的合并规则切成十几个。如果你的仓库里全是 lock 文件、压缩过的 JSON、内嵌的 SVG那实际 token 数和你用“字符数除以 4”估出来的值能差出一倍。我在实测里固定用一条规则永远相信服务端返回的 usage 里的 prompt_tokens不要相信自己估的数。这个字段是服务端按它自己的切词器算出来的真实计费值它才是唯一有法律效力的数字。你在客户端估 250K服务端返回 300K那超限的就是你跟文档写多少无关。注意用字符数除以 4 估算 token只适用于纯英文散文。中文按 1 到 1.5 字一个 token 估代码按 2.5 到 3.5 字符一个 token 估带大量哈希和压缩数据的按 1.5 字符一个 token 估。三种场景混在一起的文件估出来的误差能到 40%。2. 数字打架的五种成因挨个对账2.1 同一个名字底下挂着不同的模型快照模型标识不是不可变对象。一个看起来稳定的名字背后可能指向不同时间点的权重快照也可能按流量比例分流到不同版本。快照一换上下文支持长度、切词器、甚至对超长输入的处理策略都可能变。你上周测出 1.05M 能过这周同样的请求报错不是你写错了是背后的东西换了。应对办法很朴素把模型标识和测试时间一起记下来。我的测试记录里永远有三列——完整模型标识、请求时间戳、服务端返回的实际 token 数。三列放在一起才能判断“这次失败”是新配置导致的还是自己代码的问题。只记一个“Sol”是没用的名字太粗。另外有些入口会在请求里静默带上版本后缀你在界面上看不到。想确认自己到底打到了哪个快照最直接的方式是发一个固定的探测请求看返回体里的模型字段回显什么。回显和请求不一致的情况我遇到过不止一次。2.2 输出预留和思考 token正在偷偷吃掉你的输入空间这是 258K 这个数字最可能的来源。总窗口 262,144如果服务端默认给输出留 4,096那输入上限就是 258,048四舍五入就是 258K。数字对上了逻辑也通。但麻烦在于现在的模型越来越多的会在输出里产生“思考过程”或中间推理这部分内容同样算在输出预算里。你设max_tokens为 4,096结果模型思考了 3,000 token只留了 1,000 给正式答案答案被硬生生截断finish_reason显示长度超限。你以为是上下文不够其实是输出预算不够这两件事的修法完全相反前者要缩输入后者要加输出预算或者减少思考开销。我做过一次对照同样的长文档问答输出预算给 2K 的时候三题里有两题被截断给到 16K 之后全部完整。输入一个字没改。如果你正在做长上下文任务先把输出预算放大到你能接受的成本上限再去调输入顺序反了会浪费很多时间。2.3 名义容量和有效容量之间隔着一条性能断崖文档写的上限是“允许你塞这么多”不是“塞这么多还能答对”。长上下文评测里反复出现的现象是长度超过某个点之后模型对中段信息的召回率断崖式下跌而且这个点往往远小于标称上限。有些评测里标称 128K 的模型在 32K 之后中段召回就开始明显掉了。所以“1.05M 还是 258K”这个问题还有第三种答案两个都是标称值实际好用长度可能都在几十万以内。我在做长文档摘要时有个土办法——把文档按 1/4、1/2、3/4 的位置各埋一个只有看过原文才知道答案的问题三个都答对才算这个长度可用。经常是 1/4 和 3/4 都对了1/2 那个答错或者答得含糊说明中段是盲区。这个测试不用写代码手工做三次就够。做完你会对“上下文长度”这个词有完全不同的理解——它不是一个数是一条随长度下降的曲线。2.4 客户端和服务端的截断策略不一致最坑人有些客户端在发现你的请求超过上限时不是报错而是静默截断——从中间砍一刀或者保留头尾扔掉中间然后把残缺的请求发出去。服务端老老实实处理了返回一个看起来正常的回答。你以为模型读完了全文其实它只看到一半。这种情况最难查因为没有任何错误提示。唯一的破绽在usage.prompt_tokens你明明塞了 40 万 token 的内容返回的 prompt_tokens 只有 25 万差值就是被砍掉的部分。我现在养成一个习惯任何长上下文请求发出后第一件事就是把这个字段和自己估算的值对一下差超过 5% 就说明中间有东西动了手脚。网关层也可能做手脚。有些中间层会把超长请求直接拒掉有些会给一个截断后的版本还有些会排队重试。表现出来就是“有时候能过有时候不能过”其实取决于这次请求被路由到了哪台机器。2.5 社区探针测试本身的误差比你想的大网上流传的各种“实测上下文长度”绝大多数用的是“大海捞针”那套在长文本里埋一句特定的话问模型那句话是什么。这个方法本身没问题但实现细节上的漏洞很多。常见的几个漏洞一是针太有特征埋的是一句语义上极其突兀的话模型即使没认真读全文也能靠注意力分布猜出来二是位置单一只在开头或结尾埋而这两个位置恰好是所有模型表现最好的位置三是长度没对齐切词器用字符数估算长度实际 token 数早就超了客户端静默截断测试者却以为模型“读到了 1M”四是答案可被字符串匹配判分脚本用了模糊匹配模型输出里恰好包含那几个关键词就算过。还有个更隐蔽的缓存。长前缀被服务端缓存之后第二次请求的延迟断崖式下降测试者会误以为“这个长度下性能很好”。延迟低不代表读全了只代表没重新算。提示如果你要引用别人的实测数据先问三个问题——针埋在什么位置、长度怎么数出来的、判分标准是什么。三个都答不上来的数据当参考不当依据。3. 手把手复现一套能落地的上下文实测方案3.1 测试前的准备把变量摁死先做三件事不做完不要开始测。第一固定模型标识把完整名字写进脚本常量不要靠界面里选的那个“默认”。第二关掉所有会影响判断的东西——温度设 0虽然 0 也不是完全确定但能减少方差关掉缓存相关的选项如果有把系统提示清空或固定成最短的一句。第三准备一份“填充文本”要求语义中性、无重复模式、无特殊字符我一般用程序生成的多段说明文字每段带编号方便定位。填充文本为什么不能用重复的aaa或者公开数据集里的文本重复字符串会让切词器产生特殊的合并token 数完全失真公开文本可能被模型见过测出来的是记忆不是召回。我吃过这个亏用了一段网上随处可见的说明文做填充结果模型答对了我埋的问题后来发现它答的是原文里本来就有的内容跟我的针没关系。预算也要提前算清楚。一次 25 万 token 的请求如果单价是每百万 token 几块钱到几十块钱单次成本就是几块到十几块做一轮二分测试要发十几次请求成本能到几十上百。建议先用小长度摸清规律再往大长度推或者用最便宜的模型档位做方法论验证确认脚本没问题再换目标模型。3.2 二分探测脚本从 4K 一路顶到上限核心思路很简单把长度当作一个单调变量从肯定能过的小长度开始翻倍一旦失败就在区间内二分。每一步记录服务端返回的 prompt_tokens 和 finish_reason这两个字段是判定的硬证据。import uuid, json, time FILLER_UNIT 这是第{n}段用于填充的中性说明文字内容不携带任何需要记忆的信息。 def build_filler(n_chars): 按目标字符数生成中性填充文本保持段落编号便于定位 parts, total, i [], 0, 0 while total n_chars: s FILLER_UNIT.format(ni) parts.append(s) total len(s) i 1 return .join(parts) def plant_needles(filler, positions(0.0, 0.25, 0.5, 0.75, 0.97)): 在指定相对位置埋入不可猜测的随机标记 marks {} step max(1, len(filler) // 200) for p in positions: token MARK- uuid.uuid4().hex[:12] idx min(int(len(filler) * p), len(filler) - 1) # 就近找一个段落边界插入避免把句子劈断 cut filler.rfind(。, 0, idx) cut cut 1 if cut 0 else idx filler filler[:cut] f [{token}] filler[cut:] marks[token] round(p, 2) return filler, marks def probe(client, model, target_chars, marks, max_out512): 发一次探测请求返回实际用量与是否命中全部标记 question ( 请只输出文本中出现的所有 MARK- 开头的标记 每行一个不要解释不要补充。若没有则输出 NONE。 ) t0 time.time() resp client.complete( modelmodel, messages[ {role: user, content: 以下是一段长文本\n marks[text] \n\n question} ], max_tokensmax_out, temperature0, ) cost time.time() - t0 usage resp.get(usage, {}) out resp.get(choices, [{}])[0].get(message, {}).get(content, ) found {m: (m in out) for m in marks[tokens]} return { target_chars: target_chars, prompt_tokens: usage.get(prompt_tokens), completion_tokens: usage.get(completion_tokens), finish_reason: resp.get(choices, [{}])[0].get(finish_reason), hit: found, all_hit: all(found.values()), latency_s: round(cost, 2), model_echo: resp.get(model), }这段代码里有两个设计值得说。client.complete是我在脚本里包的一层统一入口你换成自己用的 SDK 调用即可注意别把端点写死在业务代码里。标记用uuid4().hex[:12]生成是为了保证它绝对不可能被模型猜中——如果你用的是“苹果”“蓝色”这类词模型在没读到的情况下也可能蒙对测试就废了。还有一个细节插入标记时我用rfind(。)向前找段落边界。直接把标记插在句子中间某些切词器会把标记和相邻汉字合并成一个 token导致标记在模型眼里“变形”答不出来不是因为它没读到是因为它读到的是一堆碎片。这个坑我在中文语料上踩过英文标点场景不明显中文特别明显。3.3 判定标准怎么才算“真的读到了”判定不能只看“答出了几个字”。我的标准分三层。第一层五个位置的标记全部原样输出这是及格线。第二层输出里没有编造出不存在的标记幻觉检测有编造的直接判负。第三层finish_reason必须是正常结束如果显示长度超限说明输出预算不够这一轮结果作废重测。为什么第二层这么重要因为长上下文场景下模型有一种典型失败模式没读到但根据你的问题格式推测“应该有这么个东西”然后编一个格式类似的出来。用随机 hex 标记可以有效防这个编不出 12 位随机串。但如果你用的是有语义的标记幻觉就会伪装成成功。prompt_tokens的核对是第四层也是最硬的一层。把返回的 prompt_tokens 和你本地估算值对比偏差超过 10% 就说明有一方出问题了——要么你的估算方法错了要么请求被中间层截断了。这个字段比任何行为测试都可靠因为它是计费依据。3.4 记录表怎么做才方便事后复盘测试记录不要只记“成功/失败”要记全。我的表长这样轮次目标字符实测 prompt_tokensfinish_reason5 点全中延迟(秒)模型回显备注140,00011,842stop是6.1与请求一致基线2160,00047,310stop是18.4一致延迟线性增长3640,000189,220stop4/541.7一致中段漏41,280,000252,900stop3/552.3一致prompt_tokens 未达预期疑似截断52,560,000258,048length2/558.9一致输入顶到上限第 4 轮是典型情况我把字符数翻倍了prompt_tokens 却没翻倍只从 189K 涨到 253K。这说明客户端或网关做了截断。这个证据比“答对了几题”有力得多因为它直接暴露了管线上的行为。第 5 轮的 258,048 这个数字正好印证了前面推的“262,144 减去 4,096 输出预留”。当我看到这个精确值时关于“到底 1.05M 还是 258K”的疑问基本就解开了这个入口的输入上限就是 258K 量级1.05M 是另一套配置或者另一个计量维度的数。4. 实测数据怎么用把长上下文真正榨出价值4.1 位置偏差是真的中段就是盲区不管标称多少我测下来最稳的结论是开头和结尾的信息召回率最高中段最差。这个规律在不同长度、不同任务上都成立长度越长越明显。所以别把关键指令放在中间这不是玄学是可复现的现象。工程上的对策很直接。第一把最重要的约束放在提示词最前面和最末尾各说一遍尤其“不要做什么”这类限制放末尾效果最好。第二如果必须塞长文档把你要问的问题紧跟在文档后面别让问题和文档之间隔着一大堆工具定义。第三多个关键信息不要均匀分布尽量前置。我处理一份超长技术文档的标准姿势是开头一段说明“你将读到一份 N 页文档任务是 X”然后文档正文然后“以上是全文现在回答X 的三个关键点是什么”。同样的内容把问题放最前面和放最后面答对率能差出两成。4.2 全塞 vs 检索 vs 分块摘要三条路的取舍能塞满不等于该塞满。我一般的判断标准是看三个变量文档总量、问答次数、延迟容忍度。如果文档总量在有效上下文的 50% 以内、只问一两次直接全塞最省事效果也最好因为模型能看到完整上下文不会丢跨段落的关系。如果文档总量远超有效上下文或者要问几十个问题那就上检索把文档切块、建索引、每次只取最相关的几块塞进去。检索的代价是可能漏掉跨块的信息好处是成本可控、延迟稳定。中间还有一条路是分块摘要先把每块压成摘要再把摘要拼起来做二次问答。这条路适合“整体把握”类任务比如“这份合同的主要风险点有哪些”不适合“精确查找”类任务因为摘要把细节磨掉了。我做过一次对比同一个 30 万字的技术规范全塞进去问细节准确率最高但成本也最高检索方案成本降到十分之一但跨章节的问题答错率明显上升。方案适用场景成本主要风险全量塞入文档小于有效上下文一半、问次少高中段信息丢失检索增强文档超大、问答频繁低跨块关联断裂分块摘要整体把握类任务中细节被压缩掉分层处理超长 需精确中高实现复杂度高4.3 成本与延迟的换算比你想的更陡长上下文的成本不是线性的。单次请求的输入 token 数翻倍费用就翻倍这很好算。但延迟的增长更麻烦它通常也接近线性而且在高长度段会出现额外的排队和超时风险。我实测过同样的模型4 万 token 的请求首字延迟在 6 秒左右25 万 token 的请求能到 50 秒以上中间还遇到过两次网关超时。所以我的建议是别把长上下文的余量当成免费资源。设计系统时按“有效上下文的一半”来规划留出缓冲。比如实测 258K 可用那就按 128K 来设计单次请求的内容量剩下的留给系统提示、工具定义、对话历史和输出预留。这个比例看着保守但能省掉大量超时重试的麻烦。还有一个省钱技巧长前缀在多次请求之间尽量保持完全一致包括空格和标点。有些服务端对相同前缀有缓存机制命中之后成本和延迟都会降。我做过一个客服问答的场景把固定的产品文档放在最前面后面的问题变化第二次之后的请求延迟降了一半多。这个优化的前提是前缀一个字符都不能动多一个空格就失效。5. 常见问题与排查清单5.1 现象对照表报错和静默失败怎么区分长上下文出问题表现分两类一类是明确报错一类是静默失败。明确报错好办看错误信息里的字段名基本能定位静默失败才是真正的时间黑洞因为没有提示你只能靠数据反推。现象最可能的原因验证方法处理请求直接 400提示长度超限输入超过该入口上限看错误里的最大允许值缩输入或换入口不报错但 prompt_tokens 明显小于估算客户端或网关静默截断对比估算值与返回值检查中间层配置答对开头和结尾、中段答错长上下文位置偏差多点埋针测试关键信息前置finish_reason 为 length输出预算不足看 completion_tokens加大 max_tokens同一请求时好时坏多快照分流或网关重试记录模型回显与时间固定快照标识延迟突然大幅下降前缀缓存命中对比首次与后续延迟无问题可主动利用模型编造不存在的引用幻觉非召回失败用随机串做标记换判分标准这张表里最值得盯的是第二行和第五行。第二行是所有“我明明塞进去了”类困惑的根源第五行是所有“测试结果不稳定”类困惑的根源。其他的都相对好定位。5.2 踩过的坑几个不值钱但很浪费时间的教训第一个坑用中文标点做分隔符。我一开始用中文句号把填充文本分段结果切词器把句号和前面的字合并处理实际 token 数比我估的少了将近 15%导致我一直以为还有余量直到撞上硬墙。后来改成中英文混排估算误差才降下来。这个教训是估算方法的误差要小于你的安全边际否则估算就是自欺欺人。第二个坑把系统提示的长度忘了。我做代码助手的时候系统提示里塞了一大段编码规范加上工具定义固定开销就有 8K 多 token。我一直按“输入上限 258K”来算可用空间实际能塞的文件只有 250K。差这 8K 在临界点上就是过和不过的区别。现在我的脚本里第一件事就是发一个只有系统提示、没有用户内容的请求把固定开销测出来记成常量。第三个坑以为 temperature0 就完全确定。同一个请求发三次有两次答对一次答错前两次输出一字不差第三次莫名其妙变了。后来查出来是负载均衡到了不同机器底层推理实现有细微差别。所以关键测试我至少跑三次取多数单次结果不作数。第四个坑忽略了工具定义的计数方式。带函数调用的请求里工具 schema 本身也占 token而且不同实现对它的计数方式不一样有的算进 prompt_tokens有的单独列。我做多工具场景时光工具定义就吃了 12K。这个数不算不知道一算吓一跳。注意每次换模型标识、换入口、换 SDK 版本之前测出来的所有常量都要重测一遍。上下文相关的数字没有“一次测定终身有效”这回事它的有效期可能只有几天。最后分享一个我现在常用的快速判断法三十秒能出结论。发一个明显超出上限的请求比如按目标上限的 1.5 倍塞看返回什么直接报错说明这个入口有硬校验不报错但 prompt_tokens 停在上限附近说明有静默截断不报错且 prompt_tokens 远超你预期的上限说明这个入口的真实上限比你查到的大。三种结果对应三种完全不同的处理路径比翻文档快得多。我个人的体会是上下文长度这个指标被讨论得太多了但它其实是个很粗的指标。真正决定你能不能把活干成的是有效长度、位置偏差、输出预算和成本这四条线交织出来的那个可行域。1.05M 和 258K 哪个是真的取决于你问的是哪条线——想清楚这一点后面所有的测试和调优才有意义。