GLM 5.2 Reasoning Effort: 비용을 20배 줄이는 설정, 직접 측정해 봤다

GLM 5.2가 Synthorai에 추가됐다. token당 가격은 frontier 모델의 약 6분의 1이며, open-weight 모델로 frontier급 benchmark를 달성했다는 평가도 과장이 아니다. 하지만 기준으로 삼아야 할 수치는 token당 가격이 아니다. GLM 5.2의 실제 코딩 작업 비용은 reasoning effort 설정 하나에 따라 10배 이상 차이 난다. 기본값은 이 설정이 최악의 위치에 놓여 있다. 제대로 설정하면 쉬운 작업과 어려운 작업 모두 정확하게 처리하면서 frontier 모델보다 저렴하다. 기본값을 그대로 두면 같은 답변에 20배의 비용이 들고 몇 분씩 기다려야 한다. 직접 측정한 결과다.

TL;DR

• Synthorai의 GLM 5.2 가격은 입력 $1.40/M, 출력 $4.40/M이다. claude-opus-4-8 출력 요금의 약 6분의 1이다.
• 쉬운 코딩 작업에서는 thinking을 끈 GLM 5.2가 5초 만에 $0.0008로 정답을 냈다. 무제한 기본값도 같은 답을 냈지만 $0.0285와 137초가 들었다.
• 어려운 작업에서는 reasoning_effort: high가 13초 만에 $0.0031로 정답을 냈다. 무제한 기본값보다 약 20배 저렴하고 30배 빨랐다. 기본값은 $0.062와 405초가 들었다.
• 두 작업 모두 GLM의 low effort가 high보다 reasoning token을 더 많이 생성했다. effort 이름과 token 수는 일치하지 않는다.

GLM 5.2란

GLM 5.2는 Zhipu가 2026-06-13에 공개한 open-weight frontier 모델이다. 전체 parameter는 약 744B, 활성 parameter는 약 40B인 mixture-of-experts 구조다. 실사용 가능한 1M-token context를 제공하며, MIT license로 self-hosting할 수 있다. 코딩과 agentic 작업을 주 대상으로 하며, 공개 benchmark도 높다. SWE-bench Pro 62.1, Terminal-Bench 2.1 81.0, AIME 2026 99.2, GPQA Diamond 91.2를 기록했다. Synthorai에서는 glm-5.2로 제공되며, 가격은 입력 token 100만 개당 $1.40, 출력 token 100만 개당 $4.40이다.

아래 결과를 좌우하는 핵심은 하나다. GLM 5.2는 reasoning 모델이며, reasoning 수준을 직접 설정할 수 있다.

가격대

Token당 표시 가격만 보면 GLM 5.2는 서구권 frontier 모델보다 훨씬 저렴하고, 중국 모델 중에서도 저렴한 편이다. 대표 모델의 Synthorai 요금은 다음과 같다.

출력 요금 $4.40은 gpt-5.5의 약 7분의 1, claude-opus-4-8의 약 6분의 1이다. 다만 deepseek-v4-pro와 kimi-k2.5는 이보다 더 저렴하다. GLM 5.2는 최저가 모델이라기보다 중국 모델에 가까운 가격으로 frontier급 성능을 제공하는 모델이다. 별도의 cache write 요금은 없다. Cache write에는 입력 요금이 적용되고, cache read에만 위 표의 할인 요금이 적용된다. 할인 폭은 vendor마다 다르다. GLM 5.2의 cache read 요금은 입력 요금의 약 5분의 1이며, frontier 모델인 gpt-5.5, claude-opus-4-8, gemini-3.1-pro는 약 10분의 1이다.

이전 세대와 비교해도 한 단계 올라갔다. 이전 GLM 세대는 매우 저렴했지만, GLM 5 계열부터 가격이 인상됐다. GLM 5.2의 입력 요금은 GLM-4.6의 약 3배다. 아래는 Zhipu 공식 요금이다.

인상된 가격으로 1M context와 frontier급 benchmark 성능을 제공한다. 하지만 token당 요금은 표면적인 수치일 뿐이다. 작업당 실제 비용은 reasoning effort가 결정한다.

Reasoning effort 설정

GLM 5.2의 reasoning은 단순한 on/off가 아니라 단계별로 조절할 수 있다. 완전히 끄거나(enable_thinking: false), reasoning_effort를 low, medium, high로 설정할 수 있다. 설정하지 않으면 reasoning을 제한 없이 수행하는 기본값이 적용된다. 이 설정에 따른 비용과 latency 차이는 모델 가격 차이보다 훨씬 크다. 쉬운 코딩 작업과 어려운 코딩 작업을 각 설정으로 실행한 뒤, 수백 개의 무작위 test case를 reference와 비교해 모든 답변을 검증했다.

쉬운 작업: reasoning은 비용만 늘린다

중간 난도의 dynamic programming 문제인 weighted interval scheduling을 사용했다.

두 가지가 눈에 띈다. Thinking을 꺼도 정답이 나왔으며, 전체 결과 중 가장 저렴했다. Frontier 모델보다 약 8배 저렴하다. Reasoning 단계를 높일수록 같은 답변에 비용만 추가됐다. 비용은 답변이 아니라 reasoning에 비례했다. GLM이 반환한 코드는 매번 약 150 token이었지만, 그 앞에 붙는 reasoning은 0에서 약 6,300 token까지 늘어났다. 이 token에도 동일한 $4.40/M 출력 요금이 부과된다. 무제한 기본값은 thinking을 껐을 때 reasoning 없이 얻은 것과 같은 답을 내기 위해 이 token을 모두 사용했다. 비용 차이는 전부 reasoning에서 발생했다. Frontier 모델은 여기서 reasoning을 거의 또는 전혀 사용하지 않았다. gpt-5.5는 reasoning token 59개를 사용했고, claude-opus-4-8의 usage에는 reasoning token이 기록되지 않았다.

어려운 작업: reasoning은 필요하지만 기본값은 아니다

?와 *를 지원하는 wildcard 문자열 matching 문제를 사용했다. 미묘한 오류를 내기 쉬운 고전적인 문제다. Thinking을 끄자 실패했다. 다음과 같은 memoization recursion을 반환했다.

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)

겉보기에는 맞아 보이고, memo까지 사용해 신경 써서 작성한 코드처럼 보인다. 하지만 * 분기에서 i의 범위를 제한하지 않고 match(i + 1, j)를 재귀 호출한다. 문자열을 모두 소비한 뒤에도 pattern에 *가 남아 있으면 i가 끝없이 증가하면서 stack overflow가 발생한다. 빠르고 저렴하지만 오답이다.

Reasoning 단계를 높이면 올바른 iterative two-pointer algorithm을 반환한다. 재귀 호출 대신 마지막 * 위치로 backtracking하는 방식이다.

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)

이 작업에서 각 설정의 전체 결과는 다음과 같다.

명시적으로 effort를 설정한 모든 단계가 문제를 해결했다. reasoning_effort: high는 13초 만에 $0.0031로 정답을 냈다. 같은 답변을 생성한 무제한 기본값보다 약 20배 저렴하고 30배 빨랐다. Frontier 모델보다 몇 초 느렸지만 비용은 더 낮았다. 한 가지 특이점도 있다. 두 작업 모두 GLM의 low가 high보다 reasoning을 더 많이 생성했다. 따라서 단계 이름과 token 수는 일치하지 않는다. Medium과 high가 저렴하고 빨랐다.

피해야 할 설정은 무제한 기본값이다. 작업에 필요하지 않을 수 있는 reasoning에 비용을 쓰고, 처리에도 몇 분이 걸린다. reasoning_effort: high와 같은 답을 내면서 비용은 20배 더 든다.

설정 기준

핵심 변수는 reasoning effort다. 적절한 설정은 모델이 아니라 작업에 따라 결정해야 한다.

• 정확성을 쉽게 확인할 수 있는 단순 작업이나 대량 작업: thinking을 끈다(enable_thinking: false). 정답을 내면서 frontier 모델보다 약 8배 저렴했다.
• Thinking을 끄면 실패하는 어려운 문제: reasoning_effort: medium 또는 high를 사용한다. 작업당 약 $0.003로 정답을 냈고, frontier 모델보다 저렴하면서 몇 초 정도만 느렸다.
• 무제한 기본값은 사용하지 않는다. Effort 제한 없이 reasoning을 켜 두면 $0.003로 끝날 답변이 $0.06와 7분짜리 요청으로 바뀐다.

작업에 reasoning이 필요한지 미리 판단하기 어렵다면 reasoning_effort: high가 안전한 기본값이다. 비용이 낮았고 두 작업을 모두 해결했으며, 무제한으로 늘어나지도 않았다.

Caching은 입력 비용을 줄이지만 reasoning에는 효과가 없다

GLM 5.2는 gateway caching을 지원하며, 예상대로 입력 비용을 줄여 준다. 1,494-token짜리 공통 prefix인 review 대상 code module을 여러 질문과 함께 전송했다.

큰 prefix는 한 번 처리된 뒤 cache된다. Cache된 입력 token에는 일반 입력 요금의 약 5분의 1이 부과됐다. 동일한 요청의 비용이 $0.0026에서 $0.0009로 약 64% 줄었다. 완전히 같은 요청은 semantic cache에서 바로 처리된다. Cache된 호출과 같은 비용으로 같은 답변을 반환하지만, 약 5초가 아니라 1초 만에 완료됐다.

문제는 reasoning effort에서 확인한 것과 같다. Caching은 입력 비용만 할인한다. Reasoning을 켜는 순간 비용과 latency의 대부분은 cache되지 않는 reasoning 출력에서 발생한다. Thinking을 끄고 큰 context를 사용하는 작업, 예를 들어 모든 호출에 같은 system prompt나 codebase를 보내는 경우에는 caching 효과가 크다. Reasoning을 켜면 효과는 작아진다.

Synthorai에서 사용하는 방법

glm-5.2는 현재 gateway에서 사용할 수 있다. Test 결과를 바탕으로 실무에서 주의할 점은 세 가지다.

• Reasoning effort를 명시적으로 설정한다. 단순 작업에는 enable_thinking: false, 어려운 문제에는 reasoning_effort: medium 또는 high를 사용한다. 피해야 할 설정은 effort 제한 없이 reasoning을 켜 두는 무제한 기본값이다. 이 설정은 요청 하나를 $0.06와 7분짜리 작업으로 만든다.
• Reasoning을 켰다면 streaming을 사용한다. Reasoning 응답은 몇 분간 이어질 수 있다. Non-streaming 요청은 오랫동안 아무 데이터도 오지 않아, 답변을 받기 전에 client timeout이 발생할 가능성이 높다. stream: true를 사용하면 출력을 순차적으로 받으면서 전체 결과도 얻을 수 있다.
• Context를 재사용한다. 모든 호출에 같은 대형 system prompt나 codebase를 보낸다면 prefix caching으로 입력 비용을 줄일 수 있다. 여기에 thinking off를 함께 적용하면 전체 요청 비용도 낮아진다.

요금은 token 100만 개당 입력 $1.40, 출력 $4.40이다. Gateway는 호출마다 cost field를 반환하므로 각 요청의 정확한 비용을 확인할 수 있다.

결론

GLM 5.2는 저렴하면서 성능이 좋은 코딩 모델이다. 제대로 설정하면 쉬운 작업과 어려운 작업 모두 frontier 모델보다 낮은 비용으로 처리한다. 관건은 설정이다. Reasoning은 단계별로 조절할 수 있지만 기본값은 무제한이다. 이 때문에 $0.003면 끝날 작업이 $0.06와 7분짜리 호출이 된다. 단순 작업에는 enable_thinking: false, 나머지에는 reasoning_effort: medium 또는 high를 설정하면 저렴하면서도 정확하다. Reasoning을 기본값으로 두면 선택 가능한 설정 중 가장 느리고 비싼 결과가 나온다.

출처

• VentureBeat: Z.ai의 open-weight GLM-5.2, 장시간 코딩 작업에서 6분의 1 비용으로 GPT-5.5를 앞서다
• eigent.ai: GLM-5.2 사양 및 개요
• CloudPrice: GLM-5.2 가격 및 사양
• Z.ai: 공식 GLM API 요금제 (GLM-4.5 / 4.6 / 5 세대)

이 시리즈의 다른 비용 측정 가이드: 7개 ASR 모델의 음성 인식 비용과 이미지 생성 비용.

(위 Synthorai 표시 가격은 2026-06-24 기준 이 platform의 요금이며, GLM 세대별 요금은 Zhipu 공식 가격이다.)

비용은 2026-06-24에 Synthorai에서 측정했다(glm-5.2, token 100만 개당 $1.40 / $4.40). 실제 적용 전 현재 요금을 확인해야 한다.

← 블로그로 돌아가기