Qwen 的阶梯逃逸：32k 红线
多 1k Token 整单翻倍的全量结算逻辑；预算感知截断，别再为 RAG 垃圾付双倍的钱
本页解决的问题
先给结论「Qwen 的阶梯逃逸：32k 红线」要解决的关键问题是什么？
多 1k Token 整单翻倍的全量结算逻辑；预算感知截断，别再为 RAG 垃圾付双倍的钱
把成本看成形状，不是一个数字。 把一次请求拆成输入、输出、重试、工具和等待时间。使用量的形状，通常能告诉你是哪项设计选择最贵、哪里值得先改。
优化想象中的平均值之前，先测一次真实请求。
调用便宜了，却悄悄增加了重试、延迟或人工复核。
| 输入长度（Qwen3-Max） | 单价（元/M，折后） | 相对基准 |
|---|---|---|
| 0 – 32k | 1.6 | 1x |
| 32k – 128k | 3.2 | 2x |
| 128k – 252k | 4.8 | 3x |
假设你的输入是 33,000 个 Token，仅比 32k 多了 1,000。整个请求的全部 33k Token 都按 3.2 元/M 结算——不是前 32k 按 1.6 元、后 1k 按 3.2 元。多出来的这 1k，直接让整单成本翻倍。
拖动输入长度，注意 32k 和 128k 两条红线附近发生了什么。
在 RAG 场景这个问题尤其尖锐。假设检索回来 5 个文档片段，拼起来刚好 33k。这时候需要问一个问题：第 5 个片段对最终回答的贡献有多大？
如果它是核心的法律条款、关键的技术参数，那可能值得。但如果它只是网页页脚、版权声明、重复的段落，甚至只是格式带来的多余换行符呢？一些粗放的 RAG 策略，正在为垃圾付双倍的钱。
解法是把「32k」从一个事后才发现的账单事故，变成一个写进代码的预算约束。拼 Prompt 的逻辑不能是无脑拼接：
✗ 错误做法：无脑拼接| 场景 | 策略 | 说明 |
|---|---|---|
| RAG 检索 | 动态 Top-K | 不固定取 5 个 chunk，而是取到「快到 32k」为止 |
| 多轮对话 | 历史压缩 | 历史接近 30k 时触发 Summarization |
| 长文档处理 | 分段处理 | 不要一次性塞入，采用 Map-Reduce 模式 |
| 厂商 | 跳档类型 | 关键阈值 | 应对策略 |
|---|---|---|---|
| 智谱 GLM-4.6 | 输出长度跳档 | 200 Tokens | 任务拆分，或切换到非输出分档模型 |
| 通义 Qwen | 输入长度跳档 | 32k / 128k | 预算感知截断，动态裁剪上下文 |
| DeepSeek | 思维链累积 | 多轮膨胀 | 上下文清洗，用完即弃 |
Qwen 全量结算：33k 的请求，全部 33k 都按 2 倍价算。多 1k，翻一倍。
问一句「第 5 个片段值不值」：粗放 RAG 正在为页脚、免责声明和换行符付双倍的钱。
把 32k 写成代码里的预算约束：按相关性排序、到预算即停。动态 Top-K 优于固定 Top-K。
内容来源：整理自作者团队内部分享《AI Token 降本增效策略分享》「Qwen 的阶梯逃逸」。RAG 的成本与优化策略在大模型原理 · RAG 的代价与优化策略有另一个角度的展开，可对照阅读。
「现象：多 1k Token，整单翻倍」的完整成本怎么算
「假设你的输入是 33,000 个 Token，仅比 32k 多了 1,000。」提醒我们，AI 成本不是单价乘一次调用这么简单。输入、输出、重试、工具调用、等待时间和人工收尾，会共同决定一次任务到底贵不贵。
先找出账单里不断重复的部分
「在 RAG 场景这个问题尤其尖锐。假设检索回来 5 个文档片段，拼起来刚好 33k。这时候需要问一个问题： 第 5 个片段对最终回答的贡献有多大」对应的关键变量通常是上下文是否每轮重复发送、输出是否过长、失败是否触发重试，以及每次调用是否真的带来有用结果。减少无效 Token 往往同时降低费用、延迟和并发压力。
便宜的单次调用可能换来更贵的全流程
以「把 32k 写成代码里的预算约束： 按相关性排序、到预算即停。动态 Top-K 优于固定 Top-K」为起点做一张小表：输入、输出、重试、工具和人工复核分别花了什么，再比较优化前后的质量，避免只看某一项价格。
从「现象：多 1k Token，整单翻倍」走到「交互演示 · 阶梯上的账单」
「现象：多 1k Token，整单翻倍」先把问题落在「假设你的输入是 33,000 个 Token，仅比 32k 多了 1,000。 整个请求的全部 33k Token 都按 3.2 元/M 结算 ——不是前 32k 按 1.6 元、后 1k 按 3.2 元。多出来的这 1k，直接让整单成本翻倍」上；到了「交互演示 · 阶梯上的账单」，讨论继续推进到「拖动输入长度，注意 32k 和 128k 两条红线附近发生了什么」。两段连起来，重点就不只是记住一个结论，而是看清它成立所依赖的条件。
把这条判断带到下一个场景
分析成本时，先画出完整交互，再找每轮重复的输入、无效输出和失败重试；单次调用便宜，并不代表整个任务便宜。
- 「现象：多 1k Token，整单翻倍」：假设你的输入是 33,000 个 Token，仅比 32k 多了 1,000。 整个请求的全部 33k Token 都按 3.2 元/M 结算 ——不是前 32k 按 1.6 元、后 1k 按 3.2 元。多出来的这 1k，直接让整单成本翻倍
- 「交互演示 · 阶梯上的账单」：拖动输入长度，注意 32k 和 128k 两条红线附近发生了什么
- 「最后的要点」：把 32k 写成代码里的预算约束： 按相关性排序、到预算即停。动态 Top-K 优于固定 Top-K
最后的「最后的要点」把讨论落到「把 32k 写成代码里的预算约束： 按相关性排序、到预算即停。动态 Top-K 优于固定 Top-K」。回看这条线索时，最值得保留的是：当输入、规模或风险改变，哪些判断需要重新做一遍。
我把这篇文章里的一个判断改写成了今天可以验证的小实验。比记住结论更有用的是，知道下一步要观察什么。
读完以后我先回头找它成立的条件，而不是直接把方法搬进项目。这个顺序让后面的取舍清楚很多。
如果把这个判断放到真实工作里，最先需要补的约束是什么？我想知道从阅读到第一次实践之间，哪一步最值得先做。
还没有这篇文章的讨论。