Token 降本增效 · 5 / 13 Qwen 的阶梯逃逸：32k 红线 Qwen 系列的分档逻辑和智谱完全不同：按输入长度计费，分界线在 32k 和 128k。最容易被忽略的计费细节是——越线后不是「超出部分加价」，而是整个请求全量按高价档结算。 输入分档 全量结算 RAG 成本 预算感知截断 一句话速览 多 1k Token 整单翻倍的全量结算逻辑；预算感知截断，别再为 RAG 垃圾付双倍的钱 现象：多 1k Token，整单翻倍

输入长度（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 两条红线附近发生了什么。

输入长度

28k Tokens

32k 128k 200k

适用单价 单次输入成本 日均 10 万次的月账单

RAG 场景：在为垃圾付双倍的钱 在 RAG 场景这个问题尤其尖锐。假设检索回来 5 个文档片段，拼起来刚好 33k。这时候需要问一个问题： 第 5 个片段对最终回答的贡献有多大？ 如果它是核心的法律条款、关键的技术参数，那可能值得。但如果它只是网页页脚、版权声明、重复的段落，甚至只是格式带来的多余换行符呢？ 一些粗放的 RAG 策略，正在为垃圾付双倍的钱。

仅多出 1k Token，全部 33k 都按 2 倍价结算。RAG 检索的第 5 个片段，真的值一倍的价钱吗？（图：作者分享原稿）

策略：预算感知的动态裁剪 解法是把「32k」从一个事后才发现的账单事故，变成一个 写进代码的预算约束 。拼 Prompt 的逻辑不能是无脑拼接： ✗ 错误做法：无脑拼接 prompt = system_prompt + context + user_query ✓ 正确做法：预算感知 def build_prompt_within_budget(system_prompt, context_chunks, user_query, budget=32000): prompt = system_prompt + user_query current_tokens = count_tokens(prompt)

selected_chunks = [] for chunk in sort_by_relevance(context_chunks): # 按相关性排序 chunk_tokens = count_tokens(chunk) if current_tokens + chunk_tokens > budget: break # 到达预算上限，停止添加 selected_chunks.append(chunk) current_tokens += chunk_tokens

return system_prompt + ''.join(selected_chunks) + user_query

场景 策略 说明 RAG 检索 动态 Top-K 不固定取 5 个 chunk，而是取到「快到 32k」为止 多轮对话 历史压缩 历史接近 30k 时触发 Summarization 长文档处理 分段处理 不要一次性塞入，采用 Map-Reduce 模式

可以在业务里画一条红线： 32k 是预算上限，除非有极强的业务理由，否则绝不踏入高价区。

三大定价策略对照

厂商 跳档类型 关键阈值 应对策略 智谱 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 的代价与优化策略 有另一个角度的展开，可对照阅读。