-->

루빅스 큐브 하나를 풀게 하는 데 모델이 22만 토큰을 생각한다면, 그 비용은 누가 냅니까. 개발자 도구를 만드는 Matt Pocock(@mattpocockuk)이 자신의 /teach 스킬과 pi로 GLM-5.2에 루빅스 큐브 풀이를 시키면서 남긴 첫인상이 바로 이 질문을 던집니다. 가장 낮은 effort 설정(High)에서도 3턴에 약 22만 토큰의 사고 트레이스가 쌓였다는 관찰입니다. 추론 모델이 강해진다는 말은 곧 토큰을 많이 쓴다는 말이고, 토큰을 많이 쓴다는 말은 누군가 그만큼의 청구서를 받는다는 뜻입니다.

이 글은 GLM-5.2라는 모델 자체의 소개글이 아닙니다. 가중치를 1비트로 줄여 작은 하드웨어에 올리는 양자화 이야기는 별도 글에서 이미 다뤘습니다. 이 글이 보려는 것은 한 단계 위입니다. 장황하게 생각하는 오픈웨이트 추론 모델이 등장했을 때, 토큰당 과금하는 클라우드 API와 GPU 시간을 상각하는 온프레미스 자가호스팅의 비용 셈법이 어떻게 갈라지는가입니다. 결론을 먼저 말하면, 추론이 길어질수록 자가호스팅 쪽이 유리해지는 구간이 분명히 존재하며, 이 지점이 ThakiCloud가 K8s 기반 멀티테넌트 플랫폼에서 주목하는 곳입니다.

본문의 모든 수치는 Z.ai와 여러 매체가 공개한 측정치이거나, 공개 파라미터 수에서 도출한 산수입니다. 744B 모델은 본 분석 환경에서 직접 실행할 수 없어 자체 벤치마크 대신 공개 수치를 인용하며, 산수로 도출한 추정치는 모두 [추정]으로 표시합니다.

루빅스 큐브 한 문제에 22만 토큰을 생각하는 추론 모델, 토큰당 청구되는 비용 구조

개요

GLM-5.2는 Z.ai(옛 Zhipu AI, 2019년 칭화대 지식공학연구실에서 분사한 베이징 소재 기업)가 2026년 6월 13일 공개한 오픈웨이트 대형 언어 모델입니다. 약 744B 총 파라미터의 Mixture-of-Experts(MoE) 구조에 토큰당 약 40B 파라미터만 활성화하며, 최대 100만 토큰 컨텍스트와 최대 12만 8천 토큰 출력을 지원합니다. 가중치는 MIT 라이선스로 공개되어, 누구나 내려받아 자체 인프라에서 상업적으로 돌릴 수 있습니다.

타이밍이 의미심장합니다. 여러 매체는 GLM-5.2가 미국이 Anthropic에 Fable 5와 Mythos 5 모델의 해외 접근을 차단하라고 명령한 지 이틀 뒤에 공개됐다고 보도합니다. 즉 폐쇄형 프런티어 모델이 수출통제로 막히는 흐름과, MIT 라이선스로 자가호스팅이 가능한 강한 오픈 모델이 등장하는 흐름이 같은 주에 겹친 셈입니다. 데이터 주권과 모델 주권을 함께 고민하는 조직에게 이 대비는 추상적인 정책 이슈가 아니라 당장의 아키텍처 선택입니다.

성능도 평가가 좋습니다. The Decoder 등이 인용한 독립 벤치마크와 Z.ai 기술 카드에 따르면, GLM-5.2는 장기 코딩 과제에서 폐쇄형 선두권과 한 점 차까지 좁혔습니다.

벤치마크 GLM-5.2 Claude Opus 4.8 GPT-5.5 GLM-5.1
SWE-bench Pro (코딩) 62.1 69.2 58.6 58.4
Terminal-Bench 2.1 (에이전트) 81.0 ~84 n/a 63.5
FrontierSWE (장기 코딩) 74.4% 75.4% ~73% n/a
AIME 2026 (수학) 99.2% - - -

SWE-bench Pro에서 62.1로 GPT-5.5(58.6)와 전 세대 GLM-5.1(58.4)을 앞서고, Terminal-Bench 2.1은 GLM-5.1의 63.5에서 81.0으로 뛰었습니다. 모든 항목에서 공개 모델 중 최상위입니다. (출처별로 FrontierSWE 수치가 73~75% 사이에서 조금씩 다르게 인용됩니다.)

GLM-5.2는 어떻게 토큰을 적게 쓰려 하는가

흥미로운 점은, GLM-5.2 설계 자체가 “긴 컨텍스트와 많은 토큰을 어떻게 싸게 처리할 것인가”라는 문제를 정면으로 다룬다는 데 있습니다. 100만 토큰 컨텍스트를 내세우는 모든 모델은 같은 공학적 벽에 부딪힙니다. 컨텍스트가 길어지면 병목이 순수 연산에서 KV 캐시 용량과 커널 오버헤드로 옮겨갑니다. Z.ai는 두 가지 구조로 이를 완화합니다.

첫째는 IndexShare입니다. 표준 DeepSeek Sparse Attention(DSA)에서는 모든 트랜스포머 레이어가 자기만의 indexer를 돌려 어떤 토큰에 주의를 줄지 고릅니다. 규모가 커지면 이 비용이 큽니다. IndexShare는 네 레이어마다 첫 레이어에서만 indexer를 돌리고, 그 top-k 인덱스를 다음 세 레이어가 재사용합니다. 그 결과 해당 레이어들의 내적 인덱싱 비용이 75% 줄고, 100만 토큰 길이에서 토큰당 FLOPs가 2.9배 감소합니다. 둘째는 KVShare를 결합한 다중 토큰 예측(MTP)으로, 한 번의 순전파에서 여러 토큰을 동시에 예측해 디코딩 속도를 높입니다.

그리고 사용자에게 직접 노출되는 레버가 effort 설정입니다. GLM-5.2는 High와 Max 두 단계의 effort를 제공하고, Z.ai는 코딩 과제에 Max를 권합니다. 새 세션의 기본값은 High입니다. 공개된 측정에 따르면 Max effort는 과제당 약 8만 5천 출력 토큰까지 쓰며 최고 지능을 끌어내고, High effort는 성능을 몇 점만 양보하는 대신 출력 토큰을 사실상 절반으로 줄입니다. 다시 말해, 토큰 사용량이 모델 내부에서 자동으로 결정되는 것이 아니라 운영자가 명시적으로 조절할 수 있는 손잡이라는 뜻입니다. 이 손잡이가 뒤에서 다룰 비용 셈법의 핵심 변수입니다.

폐쇄형 클라우드 API 경로와 ThakiCloud 온프레미스 자가호스팅 경로의 비용 구조 대비

/teach가 드러낸 것: 추론은 토큰을 먹는다

Matt Pocock의 관찰로 돌아가 봅니다. 가장 낮은 effort에서도 루빅스 큐브 한 문제에 3턴, 약 22만 토큰입니다. effort 손잡이를 Max로 올렸다면 더 길어졌을 것입니다. 이것은 결함이 아니라 추론 모델의 본질입니다. 모델이 답에 도달하기 전에 더 많이 “생각”할수록 품질이 오르고, 그 생각은 모두 출력 토큰으로 청구됩니다.

문제는 이 토큰이 어디서 정산되느냐입니다. 같은 22만 토큰 트레이스라도 정산 구조가 다르면 단가가 완전히 달라집니다. Z.ai API 출력 단가는 100만 토큰당 4.40달러입니다(입력 1.40달러, 캐시 입력 0.26달러). 폐쇄형 미국 프런티어 모델은 출력이 100만 토큰당 50달러 수준입니다. 이 두 단가를 effort별·과제별로 환산하면 차이가 선명해집니다.

과제당 출력 트레이스 GLM-5.2 API ($4.40/1M) 폐쇄형 모델 ($50/1M)
약 8.5k (짧은 과제) $0.037 $0.425
약 42k (High 추정 [추정]) $0.185 $2.10
85k (Max effort) $0.374 $4.25
220k (/teach 관찰) $0.968 $11.00

오픈웨이트 모델이 API로도 6분의 1 수준으로 싸다는 점이 먼저 눈에 들어옵니다. 하지만 진짜 시사점은 따로 있습니다. 어느 쪽이든 토큰당 과금이라는 점은 같다는 것입니다. 추론이 길어질수록 청구서는 선형으로 늘어납니다. 에이전트 한 번 호출에 22만 토큰을 쓰는 워크로드를 하루 수만 번 돌린다면, API 단가가 아무리 낮아도 토큰량 자체가 비용을 지배합니다. 바로 이 지점에서 자가호스팅이 다른 곡선을 그립니다.

서빙 비용 모델: 자가호스팅이 셈법을 뒤집는다

자가호스팅에서는 비용 구조가 토큰당이 아니라 시간당입니다. GPU 노드를 확보한 순간부터 비용은 토큰을 한 개도 안 쓰든 수십억 개를 쓰든 거의 고정입니다. 그래서 장황한 추론 트레이스는 “토큰 청구”의 문제가 아니라 “처리량과 지연”의 문제로 성격이 바뀝니다. 같은 GPU 시간 안에 더 많은 추론을 욱여넣을 수 있느냐의 엔지니어링 문제가 되는 것입니다.

물론 자가호스팅에는 진입 장벽이 있습니다. 744B 가중치를 어딘가에 올려야 합니다. 공개 파라미터 수에서 도출한 가중치 메모리는 다음과 같습니다(KV 캐시 제외, 순수 산수 [추정]).

744B 가중치의 정밀도별 메모리 풋프린트와 과제당 출력 비용 곡선

BF16 기준 약 1,488GB, FP8 약 744GB, FP4/NVFP4 약 372GB입니다. 8장의 H100(80GB)을 묶으면 640GB, 8장의 H200(141GB)을 묶으면 1,128GB이므로, FP8 양자화 가중치는 H200 한 노드에 충분히 들어가고 H100 노드에는 KV 캐시 여유를 보면 빠듯합니다. FP4까지 내리면 H100 한 노드에도 여유가 생깁니다. 즉 프런티어급 추론 모델을 단일 GPU 노드에서 자가호스팅하는 것이 더 이상 비현실적이지 않습니다.

여기서 셈법이 뒤집힙니다. 노드를 확보해 vLLM으로 서빙하고 GPU 시간을 상각하면, 22만 토큰을 생각하는 워크로드의 한계 비용은 토큰당이 아니라 “그 노드의 처리량을 얼마나 채우느냐”로 정해집니다. 추론이 장황한 워크로드일수록, 그리고 호출 빈도가 높을수록, 고정비 상각의 분모가 커져 토큰당 실효 단가가 떨어집니다. 토큰당 과금 API가 가장 불리해지는 바로 그 구간(긴 트레이스 × 높은 빈도)이 자가호스팅이 가장 유리해지는 구간입니다. effort 손잡이까지 운영자가 직접 쥐고 있으니, 품질이 덜 중요한 워크로드는 High로 토큰을 절반으로 줄이고 중요한 워크로드만 Max로 올리는 식의 세밀한 비용·품질 조절도 가능합니다.

ThakiCloud K8s AI/ML SaaS 플랫폼 적용 및 시사점

ThakiCloud는 K8s 기반 멀티테넌트 AI/ML SaaS 플랫폼을 운영하면서, 고객 데이터를 외부로 내보내지 않는 온프레미스·VPC 서빙을 다룹니다. GLM-5.2 같은 강한 오픈웨이트 추론 모델은 우리 플랫폼의 가치 제안과 정확히 맞물립니다.

Kueue 기반 GPU 큐잉으로 effort 단계와 큐 우선순위를 연동하고, 데이터·모델 주권과 vLLM 서빙 통합을 함께 제공하는 구조

첫째, 수출통제 회피가 아니라 주권 확보의 문제입니다. 폐쇄형 미국 모델의 해외 접근이 정책으로 막히는 상황에서, MIT 라이선스 가중치를 고객 클러스터 안에서 직접 서빙하면 외부 정책 변화에 흔들리지 않는 모델 주권을 확보합니다. 데이터도, 모델도 테넌트 경계를 벗어나지 않습니다.

둘째, Kueue 기반 GPU 큐잉이 토큰 경제와 만납니다. 우리는 멀티테넌트 GPU 워크로드를 Kueue로 큐잉하고 우선순위를 조정합니다. 추론 트레이스가 긴 워크로드일수록 노드 점유 시간이 길어지므로, effort 단계와 큐 우선순위를 연동하면 같은 GPU 풀에서 비용 효율과 지연 목표를 동시에 잡을 수 있습니다. 품질이 중요한 테넌트의 과제는 Max effort + 우선 큐로, 배치성 워크로드는 High effort로 처리량을 늘리는 식입니다.

셋째, vLLM 서빙 스택에 자연스럽게 얹힙니다. GLM-5.2는 Anthropic 호환 엔드포인트(https://api.z.ai/api/coding/paas/v4)를 제공해 Claude Code·OpenClaw·Cline 같은 도구가 즉시 붙지만, 그보다 중요한 것은 가중치를 직접 받아 vLLM의 FP8 텐서 병렬로 서빙할 수 있다는 점입니다. 우리 플랫폼이 다른 오픈 모델에 이미 적용하는 패턴을 그대로 재사용할 수 있습니다.

성숙 단계에 따라서는, 도메인 특화 에이전트를 GLM-5.2 수준의 오픈 추론 모델로 자가호스팅해 낮은 서빙 단가와 데이터 비이탈을 함께 제공하는 그림이 가능합니다. 토큰당 청구서가 아니라 GPU 상각으로 추론 비용을 통제한다는 메시지는, 비용과 규제를 동시에 신경 쓰는 엔터프라이즈 고객에게 분명한 차별점입니다.

한계 및 반론

이 분석에는 정직하게 밝혀야 할 약점이 있습니다.

자가호스팅이 유리한 성공 조건(긴 추론 트레이스·높은 호출 빈도·24시간 가동)과 불리한 실패 조건(간헐적 소규모 호출·유휴 방치)

자가호스팅이 항상 싼 것은 아닙니다. 비용 셈법이 뒤집히는 구간은 “긴 트레이스 × 높은 빈도”이지, 가끔 호출하는 소규모 워크로드가 아닙니다. 호출 빈도가 낮으면 GPU 노드의 고정비를 상각할 분모가 작아, 토큰당 과금 API가 오히려 쌉니다. 8장 GPU 노드를 유휴 상태로 두는 것만큼 비싼 일도 없습니다. 손익분기는 워크로드 프로파일에 전적으로 달려 있습니다.

위 메모리 수치는 순수 파라미터 산수이며 KV 캐시를 제외했습니다. 100만 토큰 컨텍스트를 실제로 채우면 KV 캐시가 수십에서 수백 GB를 추가로 먹어, 단일 노드 여유가 빠르게 사라질 수 있습니다. 실제 서빙 가능 동시성은 공개 수치만으로 단정할 수 없으며, 본 환경에서 744B 모델을 직접 띄워 측정하지 못했습니다. 처리량·동시성 수치는 실측이 필요합니다.

벤치마크 점수도 맥락이 필요합니다. 출처마다 FrontierSWE 같은 항목이 73~75% 사이에서 다르게 인용되고, 벤치마크 우위가 곧 특정 도메인 과제의 우위를 보장하지도 않습니다. 마지막으로 effort별 토큰 사용량(8.5k·85k 등)은 과제 유형에 크게 좌우되므로, 비용 표의 절대값보다 “추론이 길어질수록 토큰당 과금이 불리해진다”는 곡선의 방향을 읽는 것이 옳습니다.

그럼에도 핵심 논지는 견고합니다. 강한 오픈웨이트 추론 모델이 토큰을 많이 쓰는 시대에, 비용 통제의 레버는 단가 협상이 아니라 정산 구조의 선택으로 옮겨가고 있습니다. 토큰당이냐 시간당이냐, 그리고 그 결정을 내릴 인프라를 가졌느냐가 갈림길입니다.

출처(Sources)

참고

루프를 돌리기 전에 설계합니다: 토큰을 태우지 않는 에이전트 루프 엔지니어링

 

프롬프트를 잘 쓰는 시대에서 루프를 잘 설계하는 시대로 넘어가고 있습니다. 설계 없이 돌린 에이전트 루프는 토큰을 태우고 쓸 만하지 않은 결과물을 안깁니다. 일을 찾고 나눠주고 검증하고 기록하고 다음을 정하는 작은 시스템을 먼저 설계하는 방법, 그리고 ThakiCloud가 하루 7...