GLM 的短输出博弈：200 Token 断崖
输出 199 和 201 是两种价格，连输入都回溯涨价；拖动滑块看账单跳变，四种应对策略
本页解决的问题
先给结论「GLM 的短输出博弈：200 Token 断崖」要解决的关键问题是什么？
输出 199 和 201 是两种价格，连输入都回溯涨价；拖动滑块看账单跳变，四种应对策略
把成本看成形状，不是一个数字。 把一次请求拆成输入、输出、重试、工具和等待时间。使用量的形状，通常能告诉你是哪项设计选择最贵、哪里值得先改。
优化想象中的平均值之前，先测一次真实请求。
调用便宜了，却悄悄增加了重试、延迟或人工复核。
| 指标 | Output ≤ 200 | Output > 200 | 变化幅度 |
|---|---|---|---|
| 输出单价 | 4 元/M | 7 元/M | +75% |
| 输入单价 | 1 元/M | 1.5 元/M | +50% |
最容易被忽略的一点：只要输出超过 200 Token，前面传入的几千个 Token 的输入也要按更高的价格重新结算。输出多写两个字，整单回溯涨价。
这反映了推理算力的边际成本曲线。短输出（<200 Token）非常轻量：Decode 阶段压力小、KV Cache 占用有限，可能几十毫秒就完成了。但输出一旦变长，每多生成一个 Token，KV Cache 就多占一份显存，Attention 就多算一轮——成本非线性增长。
场景：从用户评论中提取结构化 JSON（sentiment / aspects / pain_points / suggestions）。Prompt 已经很规范，但你无法预知每条评论会提取出多少内容——简单评论 150 Token，用户多吐槽两个点就变 230。拖动滑块感受这个「结构性冲突」。
| 策略 | 做法 | 代价 |
|---|---|---|
| 任务拆分 | 把提取任务拆成多次调用，每次只提取 1–2 个字段 | 调用次数增加，延迟上升 |
| 字段分级 | 核心字段实时提取，次要字段异步补充或后处理 | 架构复杂度增加 |
| 接受波动 + 监控 | 允许偶发跳档，但建立监控看整体分布 | 成本可控但非最优 |
| 模型降级 | 价格敏感的高频任务切到 Qwen-Flash 等走量模型 | 可能牺牲少量精度 |
核心判断点是：这个任务的输出，天然落在哪个区间？如果大部分请求在 100–150、偶发超 200，可以接受。如果分布中位数就在 180–220，说明任务天然踩在断崖上——必须重新设计任务粒度，或者干脆换一个不按输出分档的模型。类似的情况也出现在代码生成场景：一个 20 行的函数就能轻松占用 100+ Token，稍复杂的修改建议就会突破 200。
GLM-4.6 按输出长度分档，200 是断崖：输出 +75%，输入回溯 +50%。
定价结构反映算力成本：长输出的 KV Cache 与 Attention 开销非线性增长，厂商在用价格赶你走短平快路线。
先看任务的输出分布，再选策略。中位数踩在断崖上的任务，要么重切粒度，要么换计费模式不同的模型。
内容来源：整理自作者团队内部分享《AI Token 降本增效策略分享》「GLM-4.6 的短输出博弈」。价格为作者当时折后价，请以智谱开放平台实时报价为准。
「现象：不仅输出涨价，输入也回溯涨价」的完整成本怎么算
「最容易被忽略的一点： 只要输出超过 200 Token，前面传入的几千个 Token 的输入也要按更高的价格重新结算 。输出多写两个字，整单回溯涨价」提醒我们，AI 成本不是单价乘一次调用这么简单。输入、输出、重试、工具调用、等待时间和人工收尾，会共同决定一次任务到底贵不贵。
先找出账单里不断重复的部分
「这反映了推理算力的边际成本曲线。短输出（<200 Token）非常轻量：Decode 阶段压力小、KV Cache 占用有限，可能几十毫秒就完成了。但输出一旦变长， 每多生成一个 Token，KV Cache 就多占一份显存，Attention 就多算一轮 ——成本非线性增长」对应的关键变量通常是上下文是否每轮重复发送、输出是否过长、失败是否触发重试，以及每次调用是否真的带来有用结果。减少无效 Token 往往同时降低费用、延迟和并发压力。
便宜的单次调用可能换来更贵的全流程
以「先看任务的输出分布，再选策略。」为起点做一张小表：输入、输出、重试、工具和人工复核分别花了什么，再比较优化前后的质量，避免只看某一项价格。
从「现象：不仅输出涨价，输入也回溯涨价」走到「智谱为什么这么定价」
「现象：不仅输出涨价，输入也回溯涨价」先把问题落在「最容易被忽略的一点： 只要输出超过 200 Token，前面传入的几千个 Token 的输入也要按更高的价格重新结算 。输出多写两个字，整单回溯涨价」上；到了「智谱为什么这么定价」，讨论继续推进到「这反映了推理算力的边际成本曲线。短输出（<200 Token）非常轻量：Decode 阶段压力小、KV Cache 占用有限，可能几十毫秒就完成了。但输出一旦变长， 每多生成一个 Token，KV Cache 就多占一份显存，Attention 就多算一轮 ——成本非线性增长」。两段连起来，重点就不只是记住一个结论，而是看清它成立所依赖的条件。
把这条判断带到下一个场景
分析成本时，先画出完整交互，再找每轮重复的输入、无效输出和失败重试；单次调用便宜，并不代表整个任务便宜。
- 「现象：不仅输出涨价，输入也回溯涨价」：最容易被忽略的一点： 只要输出超过 200 Token，前面传入的几千个 Token 的输入也要按更高的价格重新结算 。输出多写两个字，整单回溯涨价
- 「智谱为什么这么定价」：这反映了推理算力的边际成本曲线。短输出（<200 Token）非常轻量：Decode 阶段压力小、KV Cache 占用有限，可能几十毫秒就完成了。但输出一旦变长， 每多生成一个 Token，KV Cache 就多占一份显存，Attention 就多算一轮 ——成本非线性增长
- 「最后的要点」：先看任务的输出分布，再选策略。 中位数踩在断崖上的任务，要么重切粒度，要么换计费模式不同的模型
最后的「最后的要点」把讨论落到「先看任务的输出分布，再选策略。 中位数踩在断崖上的任务，要么重切粒度，要么换计费模式不同的模型」。回看这条线索时，最值得保留的是：当输入、规模或风险改变，哪些判断需要重新做一遍。
我把这篇文章里的一个判断改写成了今天可以验证的小实验。比记住结论更有用的是，知道下一步要观察什么。
读完以后我先回头找它成立的条件，而不是直接把方法搬进项目。这个顺序让后面的取舍清楚很多。
如果把这个判断放到真实工作里，最先需要补的约束是什么？我想知道从阅读到第一次实践之间，哪一步最值得先做。
还没有这篇文章的讨论。