max_tokens 该设多大？输出长度控制的成本与体验平衡
max_tokens 是最容易被忽略的成本开关。它不改变模型能力，只决定「最多让它写多长」——而输出单价通常是输入的几倍，写多长就是花多少钱。
这篇讲怎么按场景定这个值。整体的降本顺序见大模型 API 降本十招。
先分清两件事：上限和实际长度
max_tokens 设的是上限，不是目标。模型正常写完会自己停下，这时候实际输出可能远小于上限，你按实际长度付费。
那为什么还要认真设？两个原因：
一是兜底。 模型偶尔会陷入重复或啰嗦，一路写到上限才停。上限设得越大，这种意外的代价越高。
二是模型会参考它。 部分场景下，宽松的上限会让模型倾向于写得更长。给一个贴合场景的上限，配合提示里的简洁要求，实际输出长度通常会下来。
按场景给个起点
分类、判断、抽取类：输出就是一个标签或一小段 JSON，上限给几十到一两百 token 足矣。设成几千是纯粹的风险敞口。
问答类：几百 token 通常够。要更长的话，先问自己用户是不是真的想读那么多。
摘要类：按目标长度的一点五倍给，留一点余量。
写作、代码生成类：这类天然需要长输出，上限要给足，否则频繁被截断反而更亏——截断的内容照样收费，还得续写。
Agent 的中间步骤：规划、工具参数生成这些中间产物通常很短，但很多实现直接沿用了全局默认值。逐个检查一遍，这里常有立竿见影的收益。
被截断了怎么办
先确认是不是截断：看响应里的 finish_reason，因为达到上限而停的会有明确标识，和网络中断是两回事。
处理办法有三种：
一、调大上限重来。 简单，但两次都要付费，且不知道调多大才够。
二、续写。 把已生成内容作为上下文，让模型接着写。省钱，但接缝处要处理。做法见流式输出中断了怎么办。
三、改需求。 频繁截断说明任务本身需要长输出，与其反复截断续写，不如把任务拆小：一次生成一节，而不是一次生成整篇。拆小之后每次都在舒适区，质量也更稳。
第三种通常是最好的答案，但最容易被忽略。
用提示控制长度，比硬截断好
硬截断的问题是内容戛然而止，用户看到半句话。更好的做法是让模型主动收尾：
在提示里给出明确的长度期望。 「用三到五句话回答」「不超过两百字」这类指令比单纯设 max_tokens 有效——模型会规划结构，写出一个完整的短回答，而不是一个被砍断的长回答。
给结构约束。 「先给结论，再给两条理由」这种结构本身就限制了长度，而且输出质量更高。
用示例定调。 给一个长度合适的示例，模型会模仿。
max_tokens 仍然要设，但它的角色变成了兜底，而不是主要手段。
一个容易漏的成本项：推理内容
带显式推理过程的模型，中间的推理内容有的计入输出 token。这部分长度不可控，是预算里最容易失控的一项。
如果你用的是这类模型，做两件事：一是确认厂商的计费口径（推理内容是否计费、是否单独计价），二是在监控里把它单独统计，别和最终输出混在一起——否则你会以为是回答变长了。
各家计费口径的读法见输入价、输出价、缓存价怎么读。
长输出场景的三种拆分方式
有些任务天然需要长输出，硬压上限只会导致反复截断。这时候更好的思路是拆。
按结构拆。 生成一篇长文时，先让模型给出大纲，再逐节生成。每次调用的输出都在舒适区，质量更稳，还能在中途调整方向。代价是总调用次数增加，输入侧要重复带上下文——不过输入价通常远低于输出价，总账多数时候是赚的。
按批次拆。 要生成一百条数据时，分成十次每次十条，而不是一次一百条。一次性生成大批量内容时，模型往往越到后面质量越飘，拆开反而更好。
按需生成。 先返回摘要或前几条，用户想看更多再继续生成。很多场景下用户根本不会看完全部内容，提前生成的部分就是纯浪费。
三种方式的共同点是：把不可控的长输出，变成多次可控的短输出。除了省钱，可控性和质量通常也一起改善。
和其他参数的配合
和 temperature 的配合。 温度高时输出更发散，也更容易写长。需要简洁稳定输出的场景，适当降低温度配合明确的长度指令，效果比单纯压上限好。
和 stop 序列的配合。 如果你的输出有明确的结束标记，用 stop 参数让模型遇到就停，比等它写到上限更精准，也更省。
和流式输出的配合。 流式下你可以在客户端提前中断——发现内容已经够了就断开。不过要注意，已生成的部分照样计费，所以这只是体验优化，不是成本优化。
完整的成本优化路线见大模型 API 降本十招。
上线前检查一遍所有调用点
实践中最常见的浪费不是某个值设错了，而是很多调用点根本没设，全用了 SDK 的默认值。而默认值通常很宽松。
建议在代码里搜一遍所有模型调用，逐个确认：这个调用的合理输出长度是多少？设了吗？
这件事一次性做完，收益按调用量持续兑现。做完之后用月成本估算器重算一遍，把节省量记下来——这是最容易向上汇报的优化成果。
三个高频问题
问：max_tokens 设小了会怎样？ 输出被硬截断，用户看到半句话。所以要配合提示里的长度要求，让模型主动写短，而不是被砍断。
问：设大了会自动多花钱吗？ 不会直接多花——按实际输出计费。但它是风险敞口：模型偶尔跑偏时，上限越高损失越大。
问：推理型模型的思考过程算输出吗？ 各家计费口径不同，务必确认。这部分长度不可控，是预算里最容易失控的一项。
一句话记住
max_tokens 是兜底，提示词才是主控。让模型主动写出一个完整的短回答，永远好过让它写长然后被硬砍。前者用户读到的是完整内容，后者用户读到的是半句话——而两者花的钱可能一样多。
接着往下看
输出长度只是成本结构里的一环。完整的优化顺序（砍输入、开缓存、控输出、模型分流、批处理）见大模型 API 降本十招；想知道输出被截断后怎么优雅地续写而不是整体重发，见流式输出中断了怎么办；把改动前后的效果量化，用月成本估算器。