Token 비용 엔지니어링 · 5 / 13

Qwen의 구간 탈출: 32k 레드라인

Qwen 시리즈의 구간 로직은 Zhipu와 완전히 달라요. 입력 길이로 과금하고, 경계선은 32k와 128k. 가장 놓치기 쉬운 과금 디테일—선을 넘으면 “초과분만 가산”이 아니라, 전체 요청을 높은 구간 요금으로 정산해요.

입력 구간전체 정산RAG 비용예산 인지 절단

현상: Token 1k만 더 써도, 전체 청구서가 두 배

입력 길이 (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

32k128k200k

적용 단가

호출당 입력 비용

일 10만 회 기준 월 청구서

RAG 시나리오: 쓰레기 때문에 두 배를 내고 있어요

RAG에서는 이 문제가 특히 날카로워요. 검색으로 문서 조각 5개가 돌아와 합치면 딱 33k라고 해 봐요. 이때 물어야 할 질문: 다섯 번째 조각이 최종 답에 얼마나 기여하나요?

핵심 법률 조항이나 중요한 기술 파라미터라면 가치 있을 수 있어요. 하지만 웹 페이지 푸터, 저작권 고지, 중복 문단, 심지어 포맷 때문에 남은 줄바꿈이라면? 거친 RAG 전략은 쓰레기 때문에 두 배를 내고 있어요.

Token 1k만 더 있어도 전체 33k가 2배 요금으로 정산돼요. RAG 검색의 다섯 번째 조각이 정말 두 배 값을 하나요? (그림: 저자 내부 공유 원본)

전략: 예산 인지의 동적 절단

해법은 “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	chunk를 고정 5개 가져오지 말고, “거의 32k”까지 가져와요
멀티턴 대화	히스토리 압축	히스토리가 30k에 가까워지면 Summarization을 트리거
긴 문서 처리	구간 처리	한 번에 넣지 말고 Map-Reduce 모드를 쓰세요

비즈니스에 레드라인을 그을 수 있어요: 32k는 예산 상한—극히 강한 비즈니스 이유가 없으면 고가 구간에 절대 발을 들이지 마세요.

세 가지 가격 전략 대조

벤더	구간 점프 유형	핵심 임계값	대응 전략
Zhipu GLM-4.6	출력 길이 구간 점프	200 Tokens	작업 분할, 또는 출력 구간이 없는 모델로 전환
Qwen	입력 길이 구간 점프	32k / 128k	예산 인지 절단, 컨텍스트를 동적으로 잘라요
DeepSeek	사고 사슬 누적	멀티턴 팽창	컨텍스트 세척, 쓰면 바로 버림

핵심 요점

✓

Qwen 전체 정산: 33k 요청은 전체 33k가 2배 요금. 1k만 더 써도 두 배.

✓

“다섯 번째 조각 값 있나?”를 한 번 물으세요: 거친 RAG는 푸터·면책·줄바꿈 때문에 두 배를 내고 있어요.

✓

32k를 코드의 예산 제약으로 쓰세요: 관련성 순으로 정렬하고, 예산에 닿으면 멈춤. 동적 Top-K가 고정 Top-K보다 나아요.

출처: 저자 팀 내부 공유 《AI Token 비용 엔지니어링 전략 공유》「Qwen의 구간 탈출」에서 정리했어요. RAG 비용과 최적화 전략은 대규모 언어 모델 원리 · RAG의 대가와 최적화 전략에서 다른 각도로도 다루니 대조해 읽어 보세요.