Token Cost Engineering · 5 / 13

Qwen's Tier Escape: the 32k Red Line

Qwen's tiering logic is the opposite of Zhipu's: bill by input length, with boundaries at 32k and 128k. The detail people miss—crossing the line doesn't surcharge the overflow; it bills the whole request at the higher tier.

Input tieringFull-request billingRAG costBudget-aware truncation

The pattern: 1k more Tokens, whole bill doubles

Input length (Qwen3-Max)	Unit price (¥/M, discounted)	vs baseline
0 – 32k	1.6	1x
32k – 128k	3.2	2x
128k – 252k	4.8	3x

Say your input is 33,000 Tokens—only 1,000 over 32k. All 33k Tokens on the request bill at 3.2 ¥/M—not the first 32k at 1.6 and the last 1k at 3.2. That extra 1k doubles the whole request.

Interactive Demo · The bill on the ladder

Drag input length and watch what happens near the 32k and 128k red lines.

Input length 28k Tokens

32k128k200k

Applicable unit price

Input cost per call

Monthly bill @ 100k calls/day

RAG: paying double for junk

This gets especially sharp in RAG. Suppose retrieval returns 5 chunks that stitch to exactly 33k. Ask yourself: how much does the 5th chunk actually help the final answer?

If it's a core legal clause or a critical tech parameter, maybe it's worth it. But if it's a page footer, copyright notice, a duplicated paragraph, or even leftover newlines from formatting? Sloppy RAG strategies are paying double for junk.

Qwen billing logic: input length sets the multiplier; full-request risk

Just 1k extra Tokens, and all 33k bill at 2×. Is RAG's 5th chunk really worth doubling the price? (Figure: from the author's internal share deck)

Strategy: budget-aware truncation

The fix: turn “32k” from a bill shock you discover after the fact into a budget constraint written into code. Prompt assembly can't be mindless concat:

✗ Wrong: mindless concat

prompt = system_prompt + context + user_query

✓ Right: budget-aware

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

Scenario	Strategy	Notes
RAG retrieval	Dynamic Top-K	Don't always take 5 chunks—take until you're “about to hit 32k”
Multi-turn chat	History compression	Trigger Summarization when history nears 30k
Long-doc processing	Segmented processing	Don't stuff it all at once—use Map-Reduce

Draw a red line in the product: 32k is the budget cap—unless the business case is extremely strong, never step into the expensive band.

Three pricing strategies side by side

Vendor	Tier-jump type	Key threshold	Counter-strategy
Zhipu GLM-4.6	Output-length tier jump	200 Tokens	Task splitting, or switch to a non-output-tiered model
Qwen	Input-length tier jump	32k / 128k	Budget-aware truncation; dynamically trim context
DeepSeek	Chain-of-thought buildup	Multi-turn inflation	Context scrubbing; discard when done

Key Takeaways

✓

Qwen bills the whole request at the higher tier: a 33k request prices all 33k at 2×. 1k more, bill doubles.

✓

Ask “is the 5th chunk worth it?”: sloppy RAG pays double for footers, disclaimers, and newlines.

✓

Encode 32k as a budget constraint in code: sort by relevance, stop at budget. Dynamic Top-K beats fixed Top-K.

Source: Adapted from the author's internal team share “AI Token Cost Engineering Strategies,” section “Qwen's Tier Escape.” RAG cost and optimization also appear from another angle in LLM Fundamentals · RAG Costs & Optimization Strategies—worth reading side by side.