输出 token 为什么更贵
输出 token 的单价通常高于输入数倍（具体倍率以厂商官网为准），原因是输出必须逐 token 自回归生成，每一步都要跑一次前向计算，而输入部分只需预填充一次。因此控制输出长度是性价比最高的降本手段：设最大输出上限、用提示词约束输出格式、禁止客套话与复述问题。可观测量是响应里 usage 的输出 token 数，按日统计中位数与 P95，才能判断限制是否真的落地。
基本信息
| 为什么贵 | 逐 token 自回归生成，算力成本高于预填充 |
|---|---|
| 三大抓手 | 输出上限、提示词约束格式、禁止无关展开 |
| 隐性浪费 | 寒暄、复述问题、重复抄写上下文 |
| 可观测量 | usage 中输出 token 数，按日看 P50 与 P95 |
| 设置原则 | 先测量必要输出长度，再设上限 |
| 影响面 | 长回复会同时推高成本与首字延迟 |
典型使用场景
- 结构化抽取：只输出 JSON 字段，避免解释文字
- 问答与客服：限定回答长度与格式，减少客套
- 批量任务：输出长度直接决定批处理账单
- 流式交互：限制长度同时改善响应时长体验
- 成本治理：定位哪些功能因输出过长导致账单偏高
提示词里的输出约束
提示词里的输出约束
输出要求：
- 只输出 JSON，不要任何解释文字；
- 字段固定为 conclusion 与 reason，reason 不超过 50 字；
- 不确定时用 null，不要编造内容；
- 不要复述用户输入，不要写问候语。
# 配合接口层设置 max_tokens 作为硬上限，双保险
# 上线前统计一周输出 token 分布，再据此校准上限
# 截断会破坏 JSON：把 finish_reason 为长度的情况当异常处理输出浪费的常见形态
| 形态 | 表现 | 处理方向 |
|---|---|---|
| 客套与铺垫 | 开头一段礼貌话 | 提示词明确只输出结果 |
| 复述问题 | 把用户输入重述一遍 | 要求不要重复输入内容 |
| 抄写上下文 | 把资料原文再输出一遍 | 只输出结论与依据编号 |
| 过度解释 | 给出不需要的推导过程 | 按场景限制理由长度 |
| 格式冗余 | 多余标点与分隔线 | 规定输出为 JSON 或固定表格式 |
对固定任务先测量「必要输出长度」，再把上限设为其一点五倍左右：既挡住废话，又给长尾样本留出空间，避免频繁截断。
输出长度也影响延迟：生成是串行的，字数减半通常能让首字到完整响应的时间明显缩短，质量治理和体验优化在这一点上是同向的。