流式聊天的输出预算：用 max_tokens 管住实时回复长度

§1 实时回复里的 max_tokens 是输出上限

聊天界面里的文字逐步出现，很容易让人以为模型会一直写下去。实际上，开发者可以通过 max_tokens 为一次请求设置输出令牌上限，给这条实时回复划定预算。

令牌是模型处理文本时使用的小单位，不等于汉字、单词或字符。中文、英文、数字和代码的切分方式不同，因此不能把“最多二百个令牌”直接理解成“最多二百个汉字”。

max_tokens 是允许生成的最大数量，不是要求模型必须写满的数量。模型可能提前回答完毕，也可能因达到上限而中断。想要简短回答，还应在提示词中明确说明篇幅和格式。

开启流式输出后，服务端通常通过 SSE 等机制持续发送增量内容。前端收到一段就显示一段，用户不用等整篇生成完毕，但这种传输方式本身不会减少生成的令牌数。

也不要把每个流式事件当成一个令牌。一个事件可能携带一小段文字、状态信息或其他数据，事件数量不能直接用来计算账单。

假设某模型每百万输出令牌的价格为二十元，一次请求的上限设为五百，那么这部分输出费用的理论上限约为一分钱。这个例子只用于说明算法，输入令牌、缓存和其他计费项目仍需单独考虑。

上限适合估算最坏情况，实际费用应以服务返回的用量和账单为准。某些推理模型还会消耗不可见的推理令牌，需要先确认其预算与计费规则。

不要给所有功能使用同一个很大的数值。新手可以先设置保守起点，再根据真实请求调整，而不是把下面的范围当成通用标准。

例如，使用 Claude Haiku 4.5 做简短客服回复时，可以先测试三百个输出令牌是否足够。这里的数值只是实验起点，最终应由回答完整度、实际用量和用户反馈决定。

在支持相应字段的聊天补全接口中，通常需要同时设置 stream 为 true，并将 max_tokens 设为目标上限。前者控制回复如何送达，后者控制允许生成多少，两者不能互相替代。

不同接口的参数名称并不完全一致。有些接口使用 max_completion_tokens 或 max_output_tokens，某些模型对推理预算还有特殊定义。接入前应核对具体端点文档，不要只替换模型名称就默认参数通用。

如果希望通过统一入口测试不同模型，Fluxio 适合这类流式应用：它提供按令牌付费的接口中转，并支持兼容的 OpenAI 风格客户端。统一接入可以减少集成工作，但模型之间的预算字段和用量差异仍需验证。

流结束不一定代表回答已经完整。应检查接口提供的结束原因；在部分聊天补全接口中，length 表示触及长度限制，stop 通常表示正常停止，但具体语义应以接口文档为准。

如果回答被截断，界面应明确提示，而不是把半句话包装成完整答案。可以提供“继续生成”操作，但续写是新请求，通常会增加输入和输出费用，还可能产生重复内容。

用户点击停止时，也应取消上游请求，而不只是停止页面渲染。取消能否及时阻止后续生成取决于服务实现，已经生成的内容仍可能计费。

上线后记录每类任务的输出用量、截断比例、响应耗时和平均费用。如果大量回复撞到上限，先判断是预算太小，还是提示词让模型过度展开；如果回复通常很短，则不必仅为“保险”不断调高上限。

单次上限也不等于整个产品的预算。还要限制并发、重试和自动续写次数，并设置用户或每日额度，避免许多小请求叠加成大账单。