模型上下文长度输入和输出区别

调 API 时经常遇到两种困惑：一是明明没超「上下文长度」，请求却被拒；二是长文档塞进去了，回答却只吐一半就停。原因在于输入长度和输出长度是两笔账，很多平台的上限口径、计费口径、截断行为都不一样。这篇把两者的边界、限制来源和自查步骤说清楚，帮你先定位问题再动手改代码。

调 API 时经常撞上两种困惑：一是明明觉得自己没超「上下文长度」，请求却被拒；二是长文档明明塞进去了，回答却只吐一半就停。原因不复杂——输入长度和输出长度是两笔账，很多平台的上限口径、计费口径、截断行为都不一样。这篇不讲大道理，只帮你把两者的边界认清，先定位问题出在哪一侧，再动手改代码。

读之前先记住一条：你看到的「上下文长度」通常是个总窗口概念，不是你输入能单独用掉的额度。这条搞混了，后面所有排查都会跑偏。

输入和输出是两个独立的预算

把上下文窗口想成一个固定大小的盒子：你塞进去的输入、模型要吐出来的输出，都得装在同一个盒子里。所以输入不是能独占整个窗口的，你必须给输出留出空间。很多开发者第一次被拒，就是输入本身没超窗口，但没给输出留位置，加一起就爆了。

除了总窗口，输入侧和输出侧还各自有独立上限。单次请求最大输入 token 是一个数，max output 是另一个数，这两个常常比总窗口小。也就是说，即使总窗口还有富余，输入也可能先撞到自己的天花板。具体每个模型这两个数是多少，别背，去 模型资料库（/models） 按当时的资料核对，厂商改口径比你记的速度快。

• 总窗口 = 输入 + 输出，两者共用一块额度，不是输入先花完才轮到输出
• 输入侧通常有独立的单请求上限，可能明显小于总窗口
• 输出侧有独立的 max output 上限，设太大会被服务端压低
• 系统提示、工具定义、历史轮次往往都被算进输入，容易漏算
• 图片、附件这类内容有的平台按 token 折算，有的另有规则，口径要去术语页确认

被截断和被拒绝：先分清是哪种

「输出提前结束」和「请求直接报错」是两类问题，处理思路完全相反。输出提前停，一般是参数或停止条件触发；请求直接报错，多半是输入本身就过不去。先分清是哪一类，能省掉一大半瞎改。

多轮对话里最常见的一种情况：聊到后面回答越来越短。不是模型变懒了，是历史越堆越长，留给本轮输出的空间被一点点挤没了。这时候缩短输入的收益，比调大输出上限更直接。

一套可执行的自查步骤

1. 完整数一遍输入 token把系统提示、工具 schema、全部历史轮次、本轮用户消息序列化后一起数，别只数用户那一句话。漏算的工具定义经常是超限的元凶。
2. 对照接口返回的 usage看返回里的输入、输出用量字段，确认实际消耗和你估算差多少。差得离谱说明有没算进去的内容，或者平台折算口径和你不一样。
3. 用站内工具估一遍成本与用量到 工具目录（/tools） 找换算和估算工具，先算清楚这次调用大概占多少额度，再回文档核对该模型当时的官方上限，不要凭记忆下结论。
4. 按结论选改法输入不够就三选一：裁历史、做摘要压缩、拆分任务多次调用。输出不够就直接调大输出上限，但前提是把输入先缩短，否则总量还是超。

这套步骤的顺序不要跳。先数准输入，再核对官方数字，最后才动手改。反过来先改参数，很容易改了半天发现根本是别的问题。

哪些情况这套判断不成立

上面这套逻辑建立在「文本 token 计费、单次请求独立」的前提上。脱离这个前提，判断就会出错，下面几种情况要换思路。

• 流式输出下「看起来被截断」，可能只是网络抖动或前端缓冲没渲染完，别直接归因到 token 上限，先抓完整响应看
• 带联网、检索或工具调用的接口，实际送进模型的内容可能比你提交的多，按你手上的输入估算会偏小
• 按分钟或按次计费的语音、图片类接口不适用 token 这套口径，得单独看它们的计费规则
• 长上下文模型对中间位置内容的召回不一定稳，额度够不代表内容一定被有效利用，这点和超限是两回事
• 平台调整口径后旧结论会失效，涉及具体数字一律以站内当时的资料为准

一句话：这套自查解决的是「额度算错和参数设错」，解决不了「模型本身能力边界」和「计费模式不同」的问题。分清适用范围，才不会白折腾。