大模型的回答写到一半突然没了下文，最常见的元凶是 max_tokens——这次请求允许生成的字数天花板，也就是输出上限。它管的是"最多写多少"，与模型聪明与否无关，纯粹是接口层的一道闸门。顺带一个判断：同样是"回答变短"，参数层的截断和模型层的偷懒，排查方向完全不同，先看结束原因再动手。
这道闸门只拦出口，不管入口
它限定的只是模型本次新生成的内容，你发过去的提问、附带的文档都不在统计之内。一个常见误解是"回答被截断，是不是我的问题太长"，其实两者各管一头：入口的账挂在上下文预算上，出口的账才归 max_tokens 管，别把两笔账混在一起算。也就是说，同一道题问两遍，一次带文档一次不带，输出上限的含义不变，变的只是入口那笔账；入口决定模型看得见多少，出口决定它写得出多少，是两个独立的旋钮。
| 这一头 | 管的是什么 | 决定什么 |
|---|---|---|
| 入口（上下文预算） | 提问、文档、历史对话 | 模型看得见多少 |
| 出口（max_tokens） | 本次新生成的内容 | 模型写得出多少 |
| 思考草稿 | 推理类模型作答前的中间步骤 | 挤占同一份输出额度 |
截断发生时接口会给出什么信号
正规接口不会悄悄吞掉后半截，而是返回一个明确的结束原因。按常见约定，正常写完返回 stop，撞到上限返回 length。看到 length 就该明白：模型当时还想往下写，是你把水龙头关了。在 Kimi、文心一言这类产品的网页版里，截断往往表现为回复末尾的"继续生成"按钮，本质是同一件事换了张脸。拿到 length 别急着重发，先看答案断在哪：句子中间被截多半该调大额度，列表刚好停在下一项之前，说明模型还想继续列下去。
刹车与油箱：和停止序列的分工
同样是"让输出停下来"，两者机制完全不同。停止序列是看见指定字符串就踩刹车，属于主动停靠；输出上限是油箱烧干被迫熄火，写到第几字都得断。想让答案停在语义完整的位置，靠停止序列；只想控制成本、防止超长灌水，靠这道闸门。两者可以同时生效，谁先触发听谁的：刹车先被看见就提前停靠，额度先用完就在半路熄火。消息列表里带着多少历史，是另一个维度的预算，见消息列表。
设多大：一个可操作的估法
先想清楚任务需要什么形态的答案：一行标题、一段摘要还是一篇长文，再按"中文字数乘以二、另留三成余量"粗估 token 数。做推理类任务要特别留意，模型的思考草稿可能挤占同一份额度，细节见思考 token。估算拿不准就先设一个宽松值试跑，再按实际用量回调；分档计费场景下这一步直接影响开销，规则见计费梯度。中英文混排时估算误差更大，英文一个单词可能占好几个 token，宽裕度要再放宽一点。
输出上限对照表
- 想控成本：设一个略高于预期的值，靠用量账单回调。
- 想防灌水：盯着结束原因 length，判断是否被截。
- 想让答案停在固定位置：这道闸门不管语义，交给停止序列。
- 逐篇收尾：上限是保险丝，不是节拍器，它防事故，不负责卡点。
关于输出上限的三个常问问题
- 被截断的回答还能续上吗？：多数产品提供"继续生成"，它是把上文重新发给模型接着写，前后衔接未必严丝合缝，重要内容要人工核对。
- 设小一点会更省钱吗？：会，没生成出来的 token 不计费，但截断可能让答案失去可用性，省下的钱要和重试成本放在一起算。
- 调大会影响质量吗？：不会，它只是天花板，模型写到句号照样停，"给得多就写得水"这种说法站不住脚。
