GLM 5.2: 비용을 결정하는 건 reasoning effort다
목차
GLM 5.2가 이제 Synthorai에 올라왔고, 토큰 단가는 프런티어 모델의 약 6분의 1 수준이다. 오픈 웨이트인 데다 프런티어급 벤치마크를 찍었다는 헤드라인도 사실이다. 하지만 토큰 단가를 기준으로 삼는 건 잘못된 접근이다. GLM 5.2에서 코딩 작업 하나에 실제로 드는 비용은 reasoning effort라는 단 하나의 노브에 따라 한 자릿수 이상 차이가 난다. 그리고 기본값은 이 노브를 최악의 위치에 둔다. 잘 맞춰 두면 쉬운 작업이든 어려운 작업이든 GLM 5.2는 정답을 내면서 프런티어 모델보다 싸다. 반대로 기본값 그대로 두면 똑같은 답을 얻는 데 비용은 20배가 들고 시간도 몇 분씩 걸린다. 우리가 직접 측정했다.
GLM 5.2가 뭔가
GLM 5.2는 Zhipu가 2026-06-13에 공개한 오픈 웨이트 프런티어 모델이다. MoE(mixture-of-experts) 구조로 전체 약 744B, 활성 파라미터 약 40B이며, 실사용 가능한 1M 토큰 컨텍스트와 직접 셀프 호스팅할 수 있는 MIT 라이선스를 갖췄다. 코딩과 에이전트 작업을 겨냥했고, 공개된 벤치마크 성적이 좋다(SWE-bench Pro 62.1, Terminal-Bench 2.1 81.0, AIME 2026 99.2, GPQA Diamond 91.2). Synthorai에서는 glm-5.2로 쓰며, 가격은 입력 토큰 100만 개당 $1.40, 출력 토큰 100만 개당 $4.40이다.
아래 내용을 좌우하는 핵심은 이거다. GLM 5.2는 reasoning 모델이고, 얼마나 추론할지를 직접 설정한다는 점이다.
가격대에서의 위치
토큰 단가만 놓고 보면 GLM 5.2는 서구권 프런티어 모델보다 한참 아래, 저렴한 축에 속하는 중국 모델 사이에 자리한다. 대표적인 모델들에 대한 Synthorai 요금은 다음과 같다.
| 모델 | 입력 ($/M) | 출력 ($/M) | 캐시 읽기 ($/M) |
|---|---|---|---|
deepseek-v4-pro | 0.44 | 0.87 | 0.0036 |
kimi-k2.5 | 0.57 | 3.01 | 0.12 |
glm-5.2 | 1.40 | 4.40 | 0.26 |
qwen3-max | 1.20 | 6.00 | 0.36 |
gemini-3.1-pro | 2.00 | 12.00 | 0.20 |
claude-opus-4-8 | 5.00 | 25.00 | 0.50 |
gpt-5.5 | 5.00 | 30.00 | 0.50 |
출력 단가 $4.40은 gpt-5.5의 약 7분의 1, claude-opus-4-8의 약 6분의 1 수준이다. 다만 deepseek-v4-pro와 kimi-k2.5는 이보다 더 싸다. 정리하면 GLM 5.2는 프런티어급 성능을 대략 중국 모델 가격대에 제공하지만, 절대 최저가는 아니다. 캐시 쓰기에 대한 별도 요금은 없다. 캐시 쓰기는 입력 단가로 과금되고, 위 표의 할인 요금이 적용되는 건 캐시 읽기뿐이다. 할인 폭은 벤더마다 다른데, GLM 5.2의 캐시 읽기는 입력 단가의 약 5분의 1이고, 프런티어 모델들(gpt-5.5, claude-opus-4-8, gemini-3.1-pro)은 읽기를 입력 단가의 약 10분의 1까지 할인한다.
이전 세대와 비교해도 한 단계 올라섰다. 직전 GLM 세대는 유난히 쌌다. GLM 5 라인부터 가격이 올랐고, GLM 5.2는 GLM-4.6 대비 입력 단가가 약 3배다(Zhipu 공식 요금 기준).
| GLM 모델 | 출시 | 입력 ($/M) | 출력 ($/M) |
|---|---|---|---|
| GLM-4.5 | 2025-07 | 0.60 | 2.20 |
| GLM-4.6 | 2025-09 | 0.43 | 1.74 |
| GLM-5 | 2026 | 1.00 | 3.20 |
| GLM-5.2 | 2026-06 | 1.40 | 4.40 |
이 가격에 1M 컨텍스트와 프런티어급 벤치마크가 따라온다. 하지만 토큰 단가는 헤드라인일 뿐이다. 작업당 실제로 내는 비용은 reasoning effort가 결정한다.
reasoning effort 다이얼
GLM 5.2의 추론은 스위치가 아니라 다이얼이다. 끌 수도 있고(enable_thinking: false), reasoning_effort를 low, medium, high로 설정할 수도 있으며, 기본값으로 두면 추론을 무제한으로 돌린다. 이 설정 하나가 비용과 지연 시간을 가격보다 훨씬 크게 바꾼다. 우리는 쉬운 코딩 작업과 어려운 코딩 작업을 각각 하나씩 잡고 여러 설정에서 돌려 봤고, 모든 답을 수백 개의 무작위 케이스에 대해 기준 구현과 대조해 검증했다.
쉬운 작업: reasoning은 비용만 늘릴 뿐
가중 구간 스케줄링(weighted interval scheduling),난이도 중간 정도의 동적 계획법 문제다:
| 모드 | Reasoning 토큰 | 답변 토큰 | 비용 | 지연 시간 | 정답 여부 |
|---|---|---|---|---|---|
glm-5.2, thinking off | 0 | 169 | $0.0008 | ≈5s | yes |
glm-5.2, reasoning_effort: low | 1,563 | 150 | $0.0076 | 39s | yes |
glm-5.2, unbounded default | ≈6,290 | ≈150 | $0.0285 | 137s | yes |
gpt-5.5 (reference) | 59 | 141 | $0.0064 | 4.8s | yes |
claude-opus-4-8 (reference) | 0 | 201 | $0.0057 | 3.3s | yes |
눈에 띄는 점이 두 가지 있다. 우선 thinking off가 정답을 내면서도 표에서 가장 저렴하다. 프런티어 모델보다 약 8배 싼데,다이얼을 한 단계씩 올려봐야 답은 똑같고 비용만 늘어난다. 그리고 청구액은 답변이 아니라 reasoning을 따라간다. GLM이 돌려주는 코드는 매번 150 토큰 정도로 일정하지만,그 앞에 붙는 reasoning은 0에서 약 6,300까지 불어나고,이게 전부 똑같은 $4.40/M output 단가로 청구된다. unbounded default는 thinking off가 reasoning 한 토큰도 없이 도달한 그 답에 이르려고 그만큼의 reasoning을 쓰는 셈이며,이 차이가 곧 비용 차이의 전부다. 여기서 프런티어 모델은 reasoning을 거의 또는 전혀 쓰지 않고 답한다. gpt-5.5는 59 reasoning 토큰을 쓰고,claude-opus-4-8의 usage에는 reasoning이 0으로 보고된다.
어려운 문제: 추론이 제값을 하지만, 기본값은 그렇지 않다
와일드카드 문자열 매칭(? 와 *), 미묘하게 틀리기 쉬운 전형적인 문제다. 여기서는 thinking 을 끄자 실패했다. 메모이제이션을 적용한 재귀를 반환했다:
def is_match(s, p):
memo = {}
def match(i, j):
if (i, j) in memo:
return memo[(i, j)]
if j == len(p):
result = i == len(s)
elif i < len(s) and p[j] in (s[i], '?'):
result = match(i + 1, j + 1)
elif p[j] == '*':
result = match(i + 1, j) or match(i, j + 1)
else:
result = False
memo[(i, j)] = result
return result
return match(0, 0)
겉보기엔 맞아 보이고, 메모까지 써서 나름 신경 쓴 티가 난다. 하지만 * 분기에서 i 에 상한을 두지 않고 match(i + 1, j) 로 재귀한다. 문자열을 다 소비했는데 패턴에는 아직 * 가 남아 있으면 i 가 끝없이 커지면서 스택이 오버플로된다. 빠르고, 싸고, 틀렸다.
다이얼을 올리면 올바른 반복형 투 포인터 알고리즘을 반환한다. 재귀 대신 마지막 * 위치로 백트래킹하는 방식이다:
def is_match(s, p):
s_idx, p_idx, star_idx, match_idx = 0, 0, -1, 0
while s_idx < len(s):
if p_idx < len(p) and (p[p_idx] == '?' or p[p_idx] == s[s_idx]):
s_idx += 1
p_idx += 1
elif p_idx < len(p) and p[p_idx] == '*':
star_idx = p_idx
match_idx = s_idx
p_idx += 1
elif star_idx != -1:
p_idx = star_idx + 1
match_idx += 1
s_idx = match_idx
else:
return False
while p_idx < len(p) and p[p_idx] == '*':
p_idx += 1
return p_idx == len(p)
이 문제에 대해 다이얼을 전부 돌려본 결과:
| GLM 5.2 설정 | 비용 | 지연 시간 | 정답 여부 |
|---|---|---|---|
| thinking off | $0.0007 | 6s | 아니오 (스택 오버플로) |
reasoning_effort: high | $0.0031 | 13s | 예 |
reasoning_effort: medium | $0.0032 | 16s | 예 |
reasoning_effort: low | $0.0068 | 40s | 예 |
| 상한 없는 기본값 | $0.062 | 405s | 예 |
gpt-5.5 (참고) | $0.0064 | 5.4s | 예 |
claude-opus-4-8 (참고) | $0.0069 | 4.6s | 예 |
명시적으로 effort 를 지정한 모든 단계가 문제를 풀었다. reasoning_effort: high 는 $0.0031 에 13초 만에 해냈는데, 같은 답을 내는 데 상한 없는 기본값보다 비용은 약 20배 싸고 속도는 30배 빨랐다. 프론티어 모델보다도 비용이 더 낮았고, 몇 초만 더 느렸을 뿐이다. 알아둘 만한 특이점 하나: GLM 의 low 가 high 보다 더 많은 추론을 만들어냈고, 이 현상은 두 문제 모두에서 일관되게 나타났다. 즉 이름이 토큰 수와 일치하지 않는다. medium 과 high 가 싸고 빠른 설정이었다.
피해야 할 단 하나의 설정은 상한 없는 기본값이다. 양쪽 모두 최악인 경우다. 문제에 필요하지도 않을 추론을 사들이면서, 그걸 하는 데 몇 분씩 걸린다. 그러고도 도달하는 답은 reasoning_effort: high 가 20배 싼 비용으로 내놓은 것과 똑같다.
결정 규칙
핵심 레버는 reasoning effort 이고, 올바른 설정은 모델이 아니라 문제에 달려 있다:
- 정답을 내기 쉬운 단순하거나 대량 처리 작업: thinking off(
enable_thinking: false). 정답을 내면서 프론티어 대비 약 8배 저렴하다. - thinking off 로는 실패하는 더 어려운 문제:
reasoning_effort: medium또는high. 정답을 내고, 작업당 약 $0.003, 프론티어보다 비용이 낮으면서 몇 초만 더 느릴 뿐이다. - 상한 없는 기본값은 절대 쓰지 말 것. effort 상한 없이 추론을 켜두는 것이 $0.003 짜리 답을 $0.06, 7분짜리로 만드는 길이다.
어떤 작업에 추론이 필요한지 미리 판단할 수 없다면 reasoning_effort: high 가 안전한 기본값이다. 싸고, 두 문제를 모두 풀었으며, 한 번도 폭주하지 않았다.
캐싱은 입력에는 도움이 되지만, 추론에는 안 된다
GLM 5.2 는 게이트웨이에서 캐싱을 지원하고, 예상한 대로 캐싱이 도움이 되는 지점에서 실제로 효과를 낸다. 같은 1,494 토큰짜리 prefix(검토 대상 코드 모듈)를 공유한 채로, 서로 다른 질문 몇 개를 보내봤다.
| 호출 | 프롬프트 토큰 | 캐시됨 | 출력 | 비용 | 지연 |
|---|---|---|---|---|---|
| 새 질문, prefix 아직 미캐시 | 1,493 | 0 | 120 | $0.0026 | 6.5s |
| 새 질문, prefix 캐시됨 | 1,494 | 1,472 | 120 | $0.0009 | 5.1s |
| 완전히 동일한 반복(시맨틱 히트) | 1,494 | 1,494 | 120 | $0.0009 | 1.0s |
큰 prefix 가 한 번 들어오면 그때부터 캐시된다. 캐시된 입력 토큰은 일반 입력 단가의 약 5분의 1 수준으로 과금되는데, 그 덕분에 다른 조건이 똑같은 요청 비용이 $0.0026 에서 $0.0009 로, 약 64% 줄었다. 완전히 동일한 반복은 시맨틱 캐시에서 바로 응답한다. 캐시된 호출과 같은 답을 같은 비용에 주지만, 5초가 아니라 약 1초 만에 돌아온다.
함정은 다이얼에서 배운 것과 똑같다. 캐싱이 깎아주는 건 입력이고, 추론이 켜지는 순간 비용과 지연은 추론 출력 쪽에 몰리는데 이건 캐시되지 않는다. 그래서 캐싱은 thinking 을 끈 채 컨텍스트가 큰 작업(매 호출마다 같은 시스템 프롬프트나 코드베이스를 보내는 경우)에서는 확실한 이득이고, 추론을 켜는 순간엔 미미한 이득이 된다.
Synthorai 에서 사용하기
glm-5.2 는 게이트웨이에서 사용 가능하다. 테스트하면서 정리한 실용적인 메모 세 가지다.
- reasoning effort 를 명시적으로 설정하라. 단순한 작업엔
enable_thinking: false, 어려운 문제엔reasoning_effort: medium또는high를 써라. 절대 피해야 할 것 하나는 effort 상한 없이 추론을 켜둔 채로 두는 것(상한 없는 기본값)인데, 이게 바로 $0.06, 7분짜리 함정이다. - 추론이 켜져 있으면 스트리밍을 써라. 추론 응답은 몇 분씩 걸릴 수 있어서, 스트리밍이 아닌 요청은 조용한 커넥션에 오래 매달려 있게 되고, 답이 도착하기 전에 클라이언트가 타임아웃될 가능성이 크다.
stream: true를 쓰면 출력이 점진적으로 들어오고 최종 결과까지 받는다. - 컨텍스트를 재사용하라. 매 호출마다 같은 큰 시스템 프롬프트나 코드베이스를 보낸다면, prefix 캐싱이 입력 비용을 깎아준다. 여기에 thinking 끄기를 같이 쓰면 요청 전체가 저렴해진다.
가격은 100만 토큰당 $1.40 / $4.40 이고, 게이트웨이는 호출마다 cost 필드를 돌려주므로 각 요청이 정확히 얼마였는지 볼 수 있다.
결론
GLM 5.2 는 진짜로 저렴하면서도 쓸만한 코딩 모델이고, 설정을 잘 하면 쉬운 작업이든 어려운 작업이든 최전선 모델 가격을 이긴다. 함정은 그 설정이다. 추론은 다이얼이고 기본값은 상한이 없어서, $0.003 이면 끝날 작업이 $0.06, 7분짜리 호출로 둔갑하는 게 바로 이 때문이다. 단순한 작업엔 enable_thinking: false, 나머지엔 reasoning_effort: medium 또는 high 를 설정하면 GLM 5.2 는 전 범위에서 저렴하고 정확하다. 추론을 기본값 그대로 두면, 고를 수 있는 선택지 중 가장 느리고 가장 비싼 옵션이 된다.
출처
- VentureBeat: Z.ai’s open-weight GLM-5.2 beats GPT-5.5 on long-horizon coding for 1/6 the cost
- eigent.ai: GLM-5.2 specs and overview
- CloudPrice: GLM-5.2 pricing and specs
- Z.ai: official GLM API pricing (GLM-4.5 / 4.6 / 5 generations)
(위에 적힌 Synthorai 가격은 2026-06-24 기준 이 플랫폼의 단가이며, GLM 세대별 단가는 Zhipu 의 공식 목록이다.)
비용은 2026-06-24 에 Synthorai 에서 측정했다(glm-5.2, 100만 토큰당 $1.40 / $4.40). 의존하기 전에 현재 가격을 확인할 것.