上下文长度与截断：中转站为什么比你想象的更早报错

先分清三个数

「上下文长度」这个说法混了三个不同的量：

1. 输入上限：一次请求里 messages 能有多少 token；
2. 输出上限（max_tokens）：本次生成最多多少 token；
3. 总窗口：输入 + 输出不超过的那个数。

官方文档通常给的是「总窗口」，比如 200K。但输入上限通常小于总窗口（要给输出留空间）。很多中转站在这一层就出现第一个问题：它按总窗口宣传，实际输入一超就报错。

中转站限制上下文的五种做法

一、渠道上限（合理）

每个上游渠道有自己的真实上限。网关按渠道配置做限制，这是正确做法 —— 超了就报错，你能知道原因。

二、静默截断（危险）

请求超出限制时，网关自动丢弃最早的消息，让请求能过。

表现是：不报错，但模型「忘了」对话开头的内容。长对话中段开始出现「你刚才说的那个」之类的失忆。

这是最难发现的一类问题，因为没有错误信号。判断方法：在对话的最开头埋一个只有它知道的信息（比如一个随机数字），经过若干轮后让它复述。复述不出来的位置，就是截断点。

三、把 max_tokens 计入输入上限判断（常见错误）

有些实现会算错：把「输入 token + max_tokens」当成输入去比对上限制，导致输入还没到上限就报错。如果你发现某家站报错时的实际输入量明显小于标称，可以怀疑这一条。

验证方法：固定输入长度，只调大 max_tokens，看是否报错。如果报错随 max_tokens 增大而出现，就是这类问题。

四、网关超时（间接限制）

长上下文处理慢。如果网关的超时设置比上游的响应时间短，长请求会 504 —— 表现为「长上下文不支持」，实际是超时。

验证方法：同样长的输入，换个简单问题（减少输出）看是否成功。

五、中间层缓冲限制

网关或反代（nginx）的 client_max_body_size、proxy_read_timeout 等设置会间接限制请求体大小。这类限制通常在 1MB 量级 —— 而 200K token 的文本远超 1MB。

这是最容易被忽略的一条。自建网关时尤其常见：程序本身支持 200K，但 nginx 默认 client_max_body_size 1m 直接返回 413。

怎么测出真实可用长度

不要信任标称值，做一次阶梯测试。

准备：一段可精确控制长度的填充文本（用重复的英文句子最方便，token 密度稳定）。

方法：从 10K token 开始，每次增加 10K，提交同一个简单问题（max_tokens 固定为 100），记录：

关键：记录错误码。

• 400 + 明确的 token 超限文案 → 渠道上限，正常
• 413 → 请求体过大，是反代层限制
• 504 / 超时 → 网关超时，不是长度限制
• 一直 200 但回答丢内容 → 静默截断

四种结果对应四种完全不同的处置方式。

为什么这件事值得做

因为「超长上下文」是最不该只看标称值的指标，而且它恰好是很多场景的关键：

• 代码库分析：一次喂入多个文件；
• 长文档处理：合同、报告、论文；
• RAG 的上下文拼装：检索结果拼接后很容易超；
• 长对话 Agent：会话历史累积。

这些场景一旦依赖了错误的长度假设，会在生产环境里以「偶发失败」的形式出现 —— 而偶发失败是最贵的故障类型。

三条实用结论

1. 标称的上下文长度只当作上限参考，实际可用的长度要自己测，且测出的是「在你这个网关 + 这条链路上的可用长度」，换一家站要重测。
2. 优先选错误信息清晰的站。明确告诉你「超出 X token」的站，比静默截断的站可靠得多 —— 前者你能处理，后者你只能踩坑。
3. 如果你的场景真的需要长上下文，把这一项提到「价格」之前。价格可以商量，长度不行就不行。

本站的详情页会标注「接口探测到的模型数」与核验状态，但不包含上下文长度实测 —— 因为这项强依赖调用方的具体形态（消息结构、是否含图片），统一测量反而会误导。这一项建议按上面的方法自己测。