GPT-5.5를 1/6 비용으로 따라잡은 오픈웨이트: GLM-5.2를 자체 호스팅 관점에서 뜯어봤습니다
개요
오픈웨이트 모델이 프런티어 코딩 능력을 따라잡는 흐름은 지난 1년간 계속됐지만, 2026년 6월의 GLM-5.2는 그 흐름에 분명한 변곡점을 찍었습니다. Vercel의 CEO인 기예르모 라우흐가 Z.ai의 GLM-5.2 코딩 능력에 거의 충격에 가까운 감탄을 공개적으로 표하면서 개발자 타임라인이 들썩였고, 곧이어 독립 벤치마크에서 여러 장기 호흡 코딩 과제에 대해 GPT-5.5를 앞섰다는 보도가 이어졌습니다. 더 중요한 사실은 가격입니다. 같은 능력을 약 1/6 비용으로 낸다는 점, 그리고 가중치가 MIT 라이선스로 완전히 공개됐다는 점이 결합되면서, 이 모델은 단순한 벤치마크 뉴스가 아니라 인프라 의사결정의 변수가 됐습니다.
ThakiCloud처럼 쿠버네티스 기반으로 AI/ML SaaS 플랫폼을 운영하는 입장에서 이 조합은 그냥 지나칠 수 없습니다. 폐쇄형 API에 종속되지 않고, 고객의 데이터 경계 안에서, 통제된 비용으로 프런티어급 코딩 모델을 띄울 수 있다면, 그것은 온프렘과 소버린 AI를 요구하는 고객에게 곧바로 팔 수 있는 제품이 됩니다. 이 글에서는 GLM-5.2의 공개된 사실을 먼저 확인하고, 실제로 자체 호스팅하려면 무엇이 필요한지, 그리고 우리 플랫폼 관점에서 어떤 의미가 있는지를 차례로 정리합니다. 모델 자체를 8장의 H200 위에 띄우는 것은 이 글의 범위를 벗어나므로, 수치는 모두 공개 문서와 보도에서 확인한 값만 인용하고 직접 재현하지 못한 부분은 명확히 구분했습니다.
이 모델은 무엇인가
GLM-5.2는 중국의 Z.ai(zai-org)가 2026년 6월 13일 공개한 대규모 Mixture-of-Experts 모델입니다. 전체 파라미터는 744B 규모이고, 토큰마다 활성화되는 파라미터는 약 40B로 직전 세대인 GLM-5.1과 비슷한 수준을 유지합니다. MoE 구조의 핵심이 바로 여기에 있습니다. 전체 용량은 거대하게 키우되, 한 번의 추론에서 실제로 계산에 참여하는 전문가(expert)는 일부만 활성화해 추론 비용을 억제하는 방식입니다. 744B라는 숫자에 겁먹기 전에, 실효 연산량은 40B급이라는 점을 먼저 이해해야 자체 호스팅 비용을 올바르게 가늠할 수 있습니다.
가장 눈에 띄는 변화는 컨텍스트 윈도우입니다. GLM-5.2는 100만(1M) 토큰 컨텍스트를 지원하며, 이는 GLM-5.1의 약 20만 토큰 한계에서 다섯 배가량 늘어난 수치입니다. 출력은 최대 131,072 토큰까지 가능합니다. 장기 호흡 코딩, 즉 거대한 코드베이스 전체를 컨텍스트에 올려 두고 여러 파일에 걸친 리팩터링이나 버그 추적을 수행하는 작업에서 이 컨텍스트 크기는 결정적입니다. 그리고 코딩 우선으로 훈련 초점을 맞췄다는 점이 벤치마크 결과로 드러납니다.
라이선스는 MIT입니다. 상업적 사용에 제약이 거의 없는 가장 관대한 오픈소스 라이선스 중 하나이며, 이는 비상업 조항이 붙은 일부 오픈웨이트 모델과 결정적으로 다른 지점입니다. 가중치는 허깅페이스에 공개돼 있고(zai-org/GLM-5.2-FP8), 소스와 레시피는 깃허브 저장소(zai-org/GLM-5)에서, 간편 실행은 Ollama 라이브러리(glm-5.2)를 통해 받을 수 있습니다.
GLM-5.2 (744B 전체 파라미터, MoE)
│
▼
MoE 라우팅 ── 토큰당 활성 약 40B 전문가만 계산
│
├── 1M 토큰 컨텍스트 (GLM-5.1 대비 약 5배)
└── 코딩 우선 학습
│
▼
장기 호흡 코딩 워크로드
│
▼
SWE-bench Pro 62.1 · Terminal-Bench 2.1 81.0
라이선스: MIT 오픈웨이트 · 자체 호스팅: FP8 · 8x H200 · vLLM / SGLang
전체 744B 용량 중 토큰당 약 40B만 활성화하는 MoE 라우팅과, 1M 컨텍스트·코딩 특화 학습이 장기 호흡 코딩 성능으로 연결되는 구조입니다.
벤치마크: GPT-5.5를 어디서 앞섰나
화제의 핵심인 벤치마크부터 사실 확인을 했습니다. 독립 벤치마크 기준으로 GLM-5.2는 현재 최상위 오픈웨이트 코딩 모델로 평가됩니다. 구체적인 수치는 다음과 같습니다.
| 벤치마크 | GLM-5.2 | GPT-5.5 | Claude Opus 4.8 |
|---|---|---|---|
| SWE-bench Pro | 62.1 | 58.6 | 69.2 |
| Terminal-Bench 2.1 | 81.0 | (비교 수치 미확인) | GLM-5.2보다 소폭 우위 |
읽는 법은 이렇습니다. SWE-bench Pro에서 GLM-5.2의 62.1은 GPT-5.5의 58.6을 앞섭니다. 다만 Claude Opus 4.8의 69.2에는 미치지 못합니다. Terminal-Bench 2.1에서는 81.0을 기록하며 Claude Opus 4.8에 근소한 차이로 따라붙은 2위권으로 보도됐습니다. 즉 “모든 프런티어 모델을 이겼다”가 아니라, “최상위 폐쇄형 모델 바로 아래에 붙으면서, 같은 체급의 폐쇄형 API인 GPT-5.5는 여러 장기 호흡 코딩 과제에서 앞섰다”가 정확한 요약입니다.
여기에 비용이 결합됩니다. 보도에 따르면 GLM-5.2는 이 수준의 성능을 GPT-5.5 대비 약 1/6 비용으로 냅니다. 성능에서 한두 점 차이는 실무에서 충분히 감내할 수 있지만, 6배의 비용 차이는 인프라 전략을 바꾸는 크기입니다. 참고로 Z.ai가 직접 제공하는 관리형 GLM Coding Plan은 라이트가 월 10달러, 프로가 월 30달러, 맥스가 월 80달러 수준으로 책정돼 있습니다. 자체 호스팅 대신 관리형으로 시작해 보고 싶은 팀에게는 진입 비용이 낮은 편입니다.
자체 호스팅: 744B를 실제로 띄우려면
가중치가 공개됐다고 해서 노트북에서 돌아가는 것은 아닙니다. 744B MoE를 자체 호스팅하려면 무엇이 필요한지, 공개된 배포 가이드와 vLLM 공식 레시피에서 확인한 요구사항을 정리합니다. 아래 수치는 직접 8장의 H200을 띄워 재현한 것이 아니라 공개 문서에서 인용한 값이며, 실제 환경에서는 검증이 필요합니다.
FP8 양자화 버전의 가중치는 약 750GB 규모입니다. 한 보도는 FP8 변형이 가중치만으로 약 753GB의 GPU 메모리를 요구한다고 정리했습니다. FP8의 장점은 BF16 대비 메모리 요구량을 절반으로 줄인다는 점입니다. 8장의 H200으로 구성한 서버는 약 1,128GB의 총 VRAM을 제공하므로, FP8 가중치를 올리고도 KV 캐시를 위한 여유가 남습니다. 다만 1M 컨텍스트 워크로드에서는 FP8 KV 캐시를 켜야 하고, 그래도 8x H200에서는 여유가 빠듯해집니다.
서빙 프레임워크는 두 갈래가 일반적입니다. vLLM은 v0.23.0 이상을 최소 버전으로 요구하며, 8장의 GPU에 걸쳐 텐서 병렬(tensor-parallel-size 8)로 샤딩해 배포합니다.
# vLLM 기준 개념 예시 (실제 플래그·버전은 공식 레시피로 확인 필요)
vllm serve zai-org/GLM-5.2-FP8 \
--tensor-parallel-size 8 \
--kv-cache-dtype fp8 \
--max-model-len 1000000
또 다른 선택지인 SGLang은 배치·동시 요청을 중심으로 설계된 구조화 생성 서빙 계층입니다. 제약 디코딩을 기본 지원하고, RadixAttention으로 KV 캐시를 공유하기 때문에 동시 클라이언트가 많은 워크로드에 자연스러운 출발점입니다. 전문가 병렬(--enable-moe-ep)과 FP8 KV 캐시(fp8_e5m2) 같은 옵션을 함께 씁니다.
핵심 운영 포인트는 분명합니다. FP8 KV 캐시는 KV 메모리를 절반으로 줄이면서 품질 영향이 미미하고, 1M 컨텍스트에서는 선택이 아니라 필수입니다. 대부분의 팀이 초기 자체 호스팅 평가를 시작할 때 FP8가 현실적인 출발점이라는 것이 공통된 권고입니다.
ThakiCloud K8s AI/ML SaaS 플랫폼 적용 및 시사점
ThakiCloud의 AI 플랫폼은 쿠버네티스 위에서 Kueue로 GPU 워크로드를 스케줄링하고, vLLM 기반으로 모델을 서빙하며, 멀티테넌트 환경에서 여러 고객의 추론을 격리해 운영하는 구조입니다. GLM-5.2는 이 스택에 거의 그대로 들어맞습니다.
첫째, 온프렘과 소버린 AI 수요에 대한 직접적인 답입니다. 금융, 공공, 국방처럼 데이터가 외부 API로 나가는 것 자체가 금지되는 환경에서는, 능력이 아무리 좋아도 폐쇄형 클라우드 API를 쓸 수 없습니다. MIT 라이선스 오픈웨이트인 GLM-5.2는 고객의 데이터 경계 안에서 프런티어급 코딩 모델을 돌릴 수 있게 합니다. 8x H200 한 노드를 Kueue 큐에 등록하고 vLLM로 띄우면, 외부로 한 바이트도 나가지 않는 코딩 어시스턴트가 만들어집니다. 이는 ThakiCloud가 강조해 온 온프렘·자체 호스팅 가치 제안과 정확히 같은 방향입니다.
둘째, 비용 구조입니다. 약 1/6 비용이라는 보도가 사실이라면, 고객에게 폐쇄형 API 재판매가 아니라 자체 호스팅 기반의 예측 가능한 정액 인프라를 제안할 수 있습니다. MoE의 활성 40B 특성 덕분에 744B라는 규모에도 추론 단가는 통제 가능한 범위에 들어옵니다. 멀티테넌트로 GPU를 공유하고 SGLang의 RadixAttention으로 KV 캐시를 재활용하면, 노드당 처리량을 끌어올려 단가를 더 낮출 여지가 있습니다.
셋째, 1M 컨텍스트는 우리 플랫폼이 지향하는 에이전트 워크로드와 맞물립니다. 거대한 사내 코드베이스나 문서를 통째로 컨텍스트에 올려 두고 장기 호흡으로 작업하는 도메인 코딩 에이전트는, 짧은 컨텍스트 모델로는 불가능한 제품입니다. 다만 1M 컨텍스트는 KV 캐시 메모리를 크게 잡아먹으므로, 멀티테넌트 환경에서는 테넌트별 최대 컨텍스트 길이를 정책으로 통제하는 설계가 필요합니다.
한계 및 반론
기대를 키우기 전에 반대편도 분명히 짚어야 합니다. 우선 GLM-5.2는 모든 면에서 최강이 아닙니다. SWE-bench Pro 62.1은 Claude Opus 4.8의 69.2에 7점 이상 뒤집니다. 절대적인 코딩 품질이 최우선이고 데이터 외부 반출이 허용되는 환경이라면, 여전히 최상위 폐쇄형 모델이 합리적인 선택입니다. GLM-5.2의 가치는 “최강”이 아니라 “자체 호스팅 가능한 범위에서 최강에 가장 근접”이라는 점에 있습니다.
벤치마크 수치 자체도 보수적으로 받아들여야 합니다. 이 글의 모든 수치는 독립 보도와 공개 문서에서 인용한 것이지, 우리가 직접 동일 조건으로 재현한 값이 아닙니다. 벤치마크 점수는 평가 하니스, 프롬프트, 샘플링 설정에 따라 달라질 수 있으므로, 실제 도입 전에는 자사의 대표 과제로 재측정하는 절차가 반드시 필요합니다.
자체 호스팅의 진입 장벽도 현실적입니다. 8x H200급 노드는 도입과 운영 모두 만만치 않은 비용이며, 1M 컨텍스트를 실제로 활용하면 KV 캐시 압박으로 동시 처리 가능한 요청 수가 빠르게 줄어듭니다. “1M 컨텍스트 지원”과 “1M 컨텍스트를 멀티테넌트로 동시 서빙”은 전혀 다른 난이도의 문제입니다. 또한 중국 연구소가 공개한 모델이라는 점에서, 일부 고객은 공급망과 거버넌스 관점의 검토를 요구할 수 있습니다. 오픈웨이트라 가중치를 직접 검증하고 격리 환경에서 운영할 수 있다는 점이 이 우려를 상당 부분 완화하지만, 도입 의사결정에서 명시적으로 다뤄야 할 항목입니다.
결론적으로 GLM-5.2는 “폐쇄형을 무조건 대체한다”가 아니라, “온프렘·소버린·비용 통제가 중요한 워크로드에서 폐쇄형 API의 강력한 대안이 생겼다”로 읽는 것이 정확합니다. 그리고 그 워크로드야말로 ThakiCloud가 가장 잘하는 영역입니다.
출처
- Z.ai’s open-weights GLM-5.2 beats GPT-5.5 on multiple long-horizon coding benchmarks for 1/6th the cost (VentureBeat)
- GLM-5.2: Features, Setup, Benchmarks, and Model Switching Guide (DataCamp)
- zai-org/GLM-5 (GitHub)
- zai-org/GLM-5.2-FP8 (Hugging Face)
- GLM-5 and GLM-5.1 Series Usage (vLLM Recipes)
- Deploy GLM-5.2 on GPU Cloud (Spheron)
- Running GLM-5.2 at Home: SGLang, vLLM, Transformers, KTransformers (Groundy)