上下文超限的报错是怎么触发的？

大模型的上下文窗口是一堵有形的墙，输入加输出塞超了就会收到明确报错。这堵墙的刻度按标记算，不按字数算。报错在哪一步被拦下、怎么计数、触发后怎么处理，值得拆开讲。

报错是在哪一步拦下的

拦截发生在请求进入模型之前：服务端先做预检，把系统设定、历史消息、本次输入加起来估算总长，再给输出预留额度，超过窗口就拒绝。进来的是完整请求，发生的是长度预检，出去的是放行或超限报错。

在进模型前拦下而非算到一半才失败，是有意的安排：模型算到第几千个标记才崩，浪费的是真金白银的算力，提前拦下只花一次清点的时间。预检的账要算全：系统设定、示例、检索注入的资料都在占用窗口，只数用户输入会漏算。

预检失败和执行失败要分开报：前者改一改请求就能重发，后者可能要查服务状态，错误码混在一起会把人引向错误的排查方向。

计数是怎么算的

标记化是计数的基础：同一段中文、英文、代码切出的标记数差别很大，凭字符数估容易失手。精确计数要用模型配套的分词器跑一遍，各家的切法不同，跨平台迁移时要重新数。

预留额度常被忽略：窗口是输入输出共享的，输入塞满就轮不到输出，报错信息里通常会给超了多少，照着删最直接。同一个超长的提问，不同模型的接受度不同，窗口大小以各产品官方说明为准。你在 DeepSeek、通义千问里贴超长文档被拒收时，提示里带的数字就是预检的账。标记数还有版本差异：同一段话逐次切分基本一致，但版本升级后切法可能微调，老请求重放时计数会漂移，严格的调用方要按当时的版本号对账。对账还有个实用技巧：把上次通过预检的请求留档，窗口升级后先拿旧请求试一遍，漂移多少一目了然。

触顶前后的处理路径

触顶之后有三条常用路：截断，砍掉最旧的历史只留近期；压缩，把长历史摘要成短摘要再放回去；外置，把全文放检索库，用到哪段查哪段。进来的是超限请求，发生的是裁剪或摘要，出去的是能过预检的新请求。

三条路各有代价：截断丢细节，压缩丢原文口吻，外置多一套检索设施。选哪条看场景：闲聊对话截断就够，助手类长任务压缩更合适，知识库问答走外置检索。长对话产品普遍是压缩加外置组合，代价换来的是窗口看似够用不完的使用感。压缩本身也要花一次模型调用，用小模型做摘要更省，摘要的质量决定压缩的损耗，关键事实漏了比超限更麻烦。三条路的选择也能组合：先截断救急，后台慢慢做压缩，两头兼顾。外置检索的路还能反哺质量：答案附上出处，可信度反而比全文塞进去更高。

三条路各自丢什么、适合谁，对照一遍。

• 速查：预检在进模型前拦下；计数按标记不按字符；窗口输入输出共享；触顶走截断、压缩、外置三条路；按场景选路。

窗口管理和服务端其他机制相邻：异步调用是怎么通知完成的？回调与轮询承接长任务，推理结果的日志怎么记？排查的第一手资料记下每次预检的账，一次请求的显存峰值出现在哪？内部门道在这是窗口之外的另一道硬约束，吞吐和延迟为什么互相牵制？过程拆开看则是容量层面的取舍。

上下文超限快问快答三则

• 报错里的数字单位是什么？：通常是标记数而非常规字数，同一段话两种数法差得不少。
• 历史消息删多少才够？：按报错提示的超额删，再留一成余量防输出超出预留，删完重发前先本地数一遍。
• 摘要压缩会丢关键信息吗？：可能丢，关键约束尽量在摘要时显式保留下来，保留方式是把关键句原文放进摘要。