왜 GLM-5.2가 주목받는가
2026년 6월 13일, Zhipu AI(Z.ai)는 GLM-5.2를 오픈 소스(MIT 라이선스)로 공개했다. 총 파라미터 744B, 활성 파라미터 40B의 Mixture-of-Experts 모델로, 가장 중요한 특징은 두 가지다.
첫째, 1M 토큰 컨텍스트를 MIT 라이선스로 운영할 수 있다는 점이다. 동급의 대형 오픈 모델 대부분이 256K~512K 컨텍스트에 머무는 상황에서 1M은 실질적인 차별점이다.
둘째, IndexShare라는 희소 어텐션 기법을 새로 도입해 1M 토큰 추론 시 기존 방식 대비 FLOPs를 2.9배 낮췄다. 성능은 낮추지 않으면서 긴 컨텍스트 서빙 비용 구조를 바꾸는 것이 목표다.
벤치마크 결과도 인상적이다. SWE-bench Pro에서 62.1로 GPT-5.5(58.6)를 앞서고, 에이전트 평가인 MCP-Atlas에서 77.0(Claude Opus 4.8은 77.8)으로 사실상 동점이다. 오픈 소스이면서도 프런티어 수준에 근접했다는 평가를 받는다.
이 챕터는 Zhipu AI의 GLM-5.2 공식 블로그, NVIDIA NeMo AutoModel 문서, Hugging Face 모델 카드, 그리고 커뮤니티 벤치마크(emergent.sh, technology.org)를 기준으로 한다. IndexShare의 내부 구현은 완전 공개되지 않았으므로 관련 서술은 공개된 기술 설명을 근거로 한다.
아키텍처: MLA + DSA + IndexShare의 조합
GLM-5.2의 아키텍처는 세 가지 핵심 기법이 계층적으로 쌓인 구조다.
Multi-head Latent Attention (MLA)
DeepSeek V2/V3에서 먼저 등장한 MLA는 KV(Key-Value) 캐시를 저차원 잠재 벡터로 압축한다. 일반 MHA(Multi-Head Attention)는 모든 레이어의 KV를 메모리에 유지하는 반면, MLA는 KV를 작은 잠재 공간으로 인코딩해 저장하고 필요할 때 복원한다. 메모리 대역폭 요구량이 크게 줄어 긴 컨텍스트에서 유리하다.
DeepSeek Sparse Attention (DSA)
DSA는 전체 시퀀스에 어텐션을 걸지 않고 헤드별로 가장 중요한 상위 2,048개 토큰에만 집중한다. 1M 토큰 컨텍스트에서 전체에 어텐션을 계산하면 $O(N^2)$ 연산이 필요하지만, 2,048개 희소 집합만 선택하면 연산량이 대폭 줄어든다.
문제는 각 레이어에서 "어느 2,048개를 선택할 것인가"를 결정하는 top-k 인덱서(indexer) 연산 비용이다. 레이어마다 인덱서를 실행하면 전체 추론에서 무시할 수 없는 오버헤드가 생긴다.
IndexShare: 핵심 혁신
IndexShare는 이 문제를 해결한다. 핵심 아이디어는 단순하다: 매 4개 레이어마다 한 번만 top-k 인덱서를 실행하고, 이후 3개 레이어는 앞서 계산한 인덱스를 재사용(share) 한다.
이것이 가능한 이유는, 인접한 레이어에서 어텐션이 필요한 토큰 집합이 크게 달라지지 않기 때문이다. 어텐션 패턴은 레이어 간에 어느 정도 지속성을 보인다.
결과적으로 인덱서 실행 횟수는 레이어 수의 1/4로 줄고, 1M 토큰 컨텍스트에서 전체 FLOPs가 2.9배 감소한다. 모델 품질 손실은 공개 벤치마크 기준 무시할 수 있는 수준이다.
IndexShare의 작동 원리 심화
왜 인접 레이어 간에 어텐션 인덱스를 재사용해도 품질이 유지될까?
직관적인 설명은 어텐션 패턴의 안정성이다. 트랜스포머 레이어에서 어텐션 헤드가 집중하는 토큰 집합은 레이어마다 완전히 바뀌지 않는다. 특히 장문 컨텍스트에서 "중요한 정보를 담고 있는 토큰"의 분포는 인접 레이어 사이에 높은 상관관계를 보인다.
DSA top-k 인덱서는 현재 쿼리 벡터와 키 벡터의 유사도를 기반으로 상위 2,048개 토큰을 선택한다. IndexShare는 4개 레이어 묶음 중 첫 번째 레이어만 이 인덱서를 실행하고, 나머지 세 레이어는 동일한 인덱스 집합을 사용한다. 쿼리와 키 자체는 레이어마다 다르게 계산되므로 어텐션 가중치 값은 달라지지만, 어느 토큰을 볼지의 결정만 공유한다.
내부 ablation 기준으로는 인덱스 교체 주기(4레이어)가 너무 길어지면 품질 손실이 생기기 시작한다고 한다. 4레이어는 비용과 품질의 균형점으로 선택되었다.
MoE 구조: 256 전문가와 40B 활성 파라미터
GLM-5.2의 피드포워드 레이어는 MoE로 구성된다.
- 전문가 수: 256개
- 활성 전문가: 토큰당 8개(라우터 선택) + 1개(공유 전문가, 항상 활성)
- 활성 파라미터: 총 40B (토큰당 연산에 참여하는 실제 파라미터)
- 활성 비율: 전체 744B 중 약 5.4%만 토큰당 활성화
이 구조는 DeepSeek V2/V3와 유사하지만 전문가 수(256개)가 더 많다. 전문가 수가 많을수록 전문화(specialization) 가능성이 높아지지만, 라우팅 오버헤드와 로드 밸런싱 복잡도도 증가한다. GLM-5.2는 공유 전문가(shared expert)를 추가해 모든 토큰이 기본 지식을 항상 처리하도록 설계했다.
벤치마크: 코딩과 에이전트 평가
| 벤치마크 | GLM-5.2 | GPT-5.5 | Claude Opus 4.8 | GLM-5.1 |
|---|---|---|---|---|
| SWE-bench Pro | 62.1 | 58.6 | — | 58.4 |
| FrontierSWE | 74.4 | 72.6 | 75.1 | — |
| MCP-Atlas | 77.0 | 75.3 | 77.8 | — |
| Terminal-Bench 2.1 | 81.0 | 84.0 | 85.0 | 63.5 |
GLM-5.2는 오픈 소스 모델 중에서 코딩·에이전트 평가에서 최상위권이다. 특히 SWE-bench Pro에서 독점 모델인 GPT-5.5를 앞섰다는 점이 주목받는다. Terminal-Bench 2.1에서는 Claude Opus 4.8(85.0)에 4점 차이로 뒤진다.
코딩 외 일반 벤치마크는 공개된 공식 수치가 제한적이다. 코딩과 장문 컨텍스트 작업에 강점이 있으며 일반 지식 평가(MMLU 등)에 대한 공식 결과는 Open question이다.
하드웨어 요구사항과 서빙 가이드
메모리 요구량
| 정밀도 | 가중치 메모리 | 권장 구성 |
|---|---|---|
| BF16 | ~1.5TB | 20× H100 80GB |
| FP8 | ~750GB | 8× H100/A100 80GB |
| 4bit 양자화(GPTQ/AWQ) | ~375GB | 4× A100 80GB |
FP8이 서빙 비용과 품질의 균형점으로 권장된다. 단일 8× H100 노드에서 동작하므로 상용 클라우드 GPU 인스턴스 한 대로 처리 가능하다.
서빙 프레임워크 지원
- NVIDIA NeMo AutoModel:
glm_moe_dsa아키텍처로 공식 지원. IndexShare DSA, optional TileLang 희소 커널, packed-sequence 훈련 포함. - vLLM: 0.26 이상에서 MoE+DSA 아키텍처 지원 확인. PagedAttention과 DSA 통합 여부는 버전별 확인 필요.
- SGLang: MLA+DSA 아키텍처 지원 이후 GLM-5.2 호환 가능. IndexShare 관련 최적화는 진행 중.
주의: IndexShare 희소 커널(TileLang 기반)이 지원되는 프레임워크에서만 2.9배 FLOPs 감소 효과를 실제로 누릴 수 있다. 미지원 시 DSA만 적용되어 효과가 부분적이다.
도입 전 확인사항
정리
GLM-5.2의 핵심 기여는 세 가지다.
첫째, IndexShare: DSA top-k 인덱스를 4레이어마다 한 번만 계산해 1M 토큰 추론의 FLOPs를 2.9배 줄였다. 긴 컨텍스트 서빙을 경제적으로 만드는 실용적인 아이디어다.
둘째, 오픈 소스 프런티어: SWE-bench Pro 62.1로 GPT-5.5(58.6)를 넘어섰고, MCP-Atlas에서 Claude Opus 4.8과 사실상 동점이다. MIT 라이선스로 배포되므로 상업적 자체 호스팅이 자유롭다.
셋째, MoE 효율: 744B 파라미터 중 40B(5.4%)만 토큰당 활성화해 동급 dense 모델보다 훨씬 낮은 연산 비용으로 대형 모델의 품질을 낸다.
운영자의 핵심 판단은 두 가지다. "코딩·에이전트 워크로드에서 상용 모델 대비 충분한 품질인가?"와 "IndexShare 커널을 지원하는 서빙 스택을 구성할 수 있는가?" — 두 조건이 맞으면 GLM-5.2는 비용 구조를 바꿀 선택지가 된다.
References
- GLM-5.2: Built for Long-Horizon Tasks — Zhipu AI HuggingFace Blog (2026-06-13)
- GLM-5.2: 753B Open-Weight Coding Model, 1M Context — MorphLLM
- GLM-5 / GLM-5.1 / GLM-5.2 (MoE + DSA) — NVIDIA NeMo AutoModel Documentation
- What Is Index Share? How GLM 5.2 Achieves 2.9x Fewer Compute Operations — MindStudio
- GLM 5.2 Architecture Deep Dive: Index Share, Sparse Attention, MTP — MindStudio
- GLM-5.2 Coding: How Good Is It, Really? 2026 Benchmarks — Technology.org
- GLM 5.2 Benchmark: Every Score Explained — emergent.sh
- DeepSeek Sparse Attention — Sebastian Raschka, PhD
- GLM 5.2 Fast is live on Fireworks AI