GLM-5 딥다이브
— Apache-2.0로 풀린 프론티어급 '에이전트 엔지니어링' MoE

1프로젝트 한줄 요약

한 문장으로 이 프로젝트가 뭘 하는지부터.

GLM-5 = "거대한 두뇌(744B)를 통째로 켜지 않고, 질문마다 필요한 전문가 40B만 깨워 쓰는, 코딩·에이전트 특화 오픈 LLM." 중국 Zhipu AI가 공개한 이 모델은 덩치(총 파라미터)와 비용(활성 파라미터)을 분리한 게 핵심이다. 그리고 단순 채팅 모델이 아니라, "오래 돌릴수록 결과가 좋아진다"는 장기 자율 작업(agentic)에 무게를 뒀다.

한 가지 먼저 짚을 것 — 이 GitHub 저장소(zai-org/GLM-5)는 코드가 거의 없는 '런치 허브(모델 카드)'다. 파일이 16개뿐이고, 실제 모델 가중치와 설정(config.json 등)은 전부 Hugging Face에 있다. 그래서 이 문서는 "코드를 한 줄씩 읽는" 공부가 아니라, "프론티어 LLM 한 대가 어떤 설계로, 어떻게 배포·서빙되는지"를 해부하는 공부다 — 그게 이 레포가 진짜 가르쳐 주는 것이다.

정리하면 GLM-5가 한 저장소에서 보여주는 것은 셋이다: ① 거대 MoE를 싸게 굴리는 아키텍처 트릭(희소 어텐션·IndexShare·MTP), ② 1M(100만) 토큰 장문맥, ③ 장기 자율 작업에 맞춘 후처리(RL) 설계. 그리고 이 모든 걸 Apache-2.0으로 풀었다.

2왜 주목받는가

TrendShift 일간 20위 — 프론티어를 향해 달려드는 오픈 모델.

2026년의 LLM 판은 "닫힌 프론티어(Claude·GPT·Gemini) vs 빠르게 추격하는 오픈웨이트(DeepSeek·Qwen·GLM)"의 구도다. GLM-5가 시선을 끄는 건, 그 격차를 '코딩·에이전트'라는 가장 실전적인 전장에서, 제약 없는 라이선스로 좁혔다고 주장하기 때문이다. 이유를 다섯으로 정리한다.

① Apache-2.0 오픈웨이트인데 프론티어에 근접

가장 큰 화제. README에 따르면 GLM-5.2는 터미널에서 실제 작업을 시키는 Terminal-Bench 2.1에서 81.0점을 기록 — Claude Opus 4.8(85.0)에 불과 몇 점 차이고 Gemini 3.1 Pro는 앞선다고 밝힌다. "닫힌 최상위 모델 바로 아래"를, 그것도 상업적 사용까지 자유로운 Apache-2.0으로 받을 수 있다는 게 핵심 매력이다.

② "바이브 코딩"을 넘어 "에이전트 엔지니어링"

대부분의 코딩 모델은 한두 번에 그럴듯한 코드를 뱉지만, 길게 끌면 금세 밑천이 떨어져 정체한다. GLM-5.1의 핵심 주장은 그 반대 — 수백 라운드·수천 번의 도구 호출에 걸친 최적화를 끈질기게 이어가고, "오래 돌릴수록 결과가 좋아진다"는 것. 복잡한 문제를 쪼개고, 실험을 돌려 결과를 읽고, 막힌 지점을 정확히 짚어 전략을 수정하는 '엔지니어처럼 일하는' 능력을 내세운다.

③ 1M 토큰 장문맥을 '싸게' 해내는 아키텍처

GLM-5.2는 견고한 100만 토큰 컨텍스트를 표방한다. 단순히 길게 늘린 게 아니라, DeepSeek Sparse Attention(DSA)로 어텐션 비용을 줄이고, 새 기법 IndexShare로 1M 문맥에서 토큰당 연산량(FLOPs)을 2.9배 절감했다. "긴 문맥 = 비싼 문맥"이라는 통념을 설계로 깬 게 기술적으로 흥미롭다.

④ 빠른 출시 케이던스 + 당일 생태계 지원

GLM-5 → 5.1 → 5.2가 짧은 간격으로 쏟아졌고(저장소 최종 갱신 2026-06-17), 공개와 동시에 vLLM·SGLang·Transformers·KTransformers + 화웨이 Ascend NPU까지 추론 레시피가 붙어 나왔다. "공개됐는데 돌릴 방법이 없다"가 아니라, 첫날부터 서빙 가능한 상태로 던진다.

⑤ 후처리 RL 인프라(slime)까지 함께 공개

모델만 던지는 게 아니라, 이를 만든 비동기 강화학습(RL) 인프라 slime(THUDM/slime)도 오픈소스로 공개했다. "어떻게 이만큼 끌어올렸나"의 레시피 일부를 함께 푼 셈이라, 연구·재현 가치가 크다.

3기술 스택 전체 지도

README · requirements.txt · Ascend 배포 문서에서 직접 확인한 실제 구성.

이 저장소는 코드가 아니라 '모델 카드'라서, 여기서 말하는 '기술 스택'은 두 층으로 나뉜다 — (가) 모델 그 자체를 구성하는 부품과 (나) 그 모델을 실제로 돌리는 추론·서빙 생태계. 둘을 나눠서 본다.

ⓐ 모델 본체 — 4가지 핵심 부품

ⓑ 모델 라인업 — 한 저장소, 3세대 × 2정밀도

흥미롭게도 세 세대(5/5.1/5.2)가 모두 같은 사이즈 744B-A40B다. 커진 건 파라미터가 아니라 '학습·후처리의 질'이다. 각 세대마다 BF16(원본)과 FP8(경량) 두 정밀도가 Hugging Face에 올라와 있다.

ⓒ 추론·서빙 런타임 — 첫날부터 붙은 생태계

ⓓ 저장소 자체의 의존성 — 딱 세 줄

코드가 없으니 requirements.txt도 단출하다. 모델을 직접 구현한 게 아니라 표준 도구를 가리킬 뿐이다.

# requirements.txt — 저장소 전체의 파이썬 의존성
transformers>=5.12.0   # 모델 로딩/추론 (glm_moe_dsa 지원 버전)
accelerate>=1.14.0     # 멀티-GPU 분산 배치
pre-commit>=4.6.0      # 문서 저장소용 린트 훅(공백/yaml/대용량 파일 차단)

4아키텍처 심화 분석

토큰 하나가 거대 MoE를 통과해 답이 되기까지 — 그리고 비용을 줄인 네 가지 트릭.

GLM-5의 설계 철학은 한 문장이다 — "성능은 프론티어급으로, 그러나 매 토큰의 계산은 최대한 아끼게." 그 절약을 네 군데에서 한다: ① 어떤 전문가를 켤지(MoE 라우팅), ② 어떤 과거를 볼지(DSA 희소 어텐션), ③ 인덱싱을 얼마나 재활용할지(IndexShare), ④ 토큰을 몇 개씩 뽑을지(MTP). 먼저 전체 그림을 보고, 하나씩 따라간다.

먼저 전체 그림 한 장 (개념도)

핵심 설계 패턴 ① — MoE 라우팅: 큰 머리, 가벼운 발놀림

블록마다 수많은 '전문가' FFN(작은 신경망)이 대기하고, 라우터가 토큰을 보고 그중 소수에게만 일을 맡긴다. 그래서 총 744B의 지식을 품되 매 토큰엔 40B만 계산한다. 이전 세대(GLM-4.5: 355B/32B)보다 총량을 2배 키우면서도 활성은 40B로 묶어, "지식은 늘리되 추론비용 증가는 최소화"한 게 5세대의 스케일링 방향이다. (사전학습 데이터도 23T → 28.5T 토큰으로 늘었다.)

핵심 설계 패턴 ② — DSA(희소 어텐션): 다 보지 않고 골라 본다

일반 어텐션은 토큰 수가 N이면 비용이 N²로 폭증한다 — 1M 토큰이면 감당 불가. DeepSeek Sparse Attention은 '인덱서'가 각 토큰이 정말 봐야 할 과거 토큰만 추려서 거기에만 어텐션을 건다. 덕분에 1M 문맥에서도 비용이 현실적으로 떨어진다. README의 표현은 "배포 비용을 크게 줄이면서 장문맥 능력을 보존". Transformers의 모델 타입 이름 glm_moe_dsa에 'moe + dsa'가 박혀 있는 이유다.

핵심 설계 패턴 ③ — IndexShare: 인덱싱을 4겹마다 한 번만

DSA가 "어디를 볼지" 고르려면 매 층마다 인덱서를 돌려야 하는데, 이게 또 비용이다. GLM-5.2의 IndexShare(arXiv 2603.12201)는 희소 어텐션 4개 층이 같은 인덱서 결과를 공유하게 만들어, 인덱싱을 4번이 아니라 1번만 하게 한다. 그 결과가 "1M 문맥에서 토큰당 FLOPs 2.9배 절감". 1M 컨텍스트를 '말은 되는데 비싼 기능'이 아니라 '실제로 쓸 만한 기능'으로 바꾼 핵심 한 수다.

핵심 설계 패턴 ④ — MTP: 토큰을 한 개씩 말고 여러 개씩

보통 LLM은 토큰을 한 번에 하나씩 뽑아 느리다. MTP(다중 토큰 예측) 헤드는 다음 토큰 여러 개를 미리 추측하고, 메인 모델이 그 추측을 한꺼번에 검증해 맞은 만큼 건너뛴다(=투기적 디코딩). GLM-5.2는 이 MTP 헤드를 개선해 한 번에 받아들여지는 길이를 최대 20% 늘렸다. 서빙 시 vLLM은 --speculative-config.method mtp, SGLang은 EAGLE 경로로 이 헤드를 활용한다.

핵심 설계 패턴 ⑤ — '생각의 양'을 조절하는 추론 모드

GLM-5는 답하기 전에 속으로 추론을 펼치는 thinking 모드를 켜고 끌 수 있다. 파라미터 reasoning_effort로 max(기본)·high를 고르고, 아예 끄려면 enable_thinking=false. GLM-5.2는 여기에 '유연한 노력(flexible effort)'을 더해 여러 단계로 성능 ↔ 지연시간을 거래하게 했다. (벤치마크 재현은 Max 기준이라고 문서가 명시.)

# vLLM 서빙 예시 (문서의 GLM-5.1-FP8 기준) — MTP·툴콜·추론 파서가 한 줄에
vllm serve zai-org/GLM-5.1-FP8 \
  --tensor-parallel-size 8            # GPU 8장에 모델을 쪼개 올림
  --gpu-memory-utilization 0.85 \
  --speculative-config.method mtp \    # MTP 투기적 디코딩 켜기
  --speculative-config.num_speculative_tokens 3 \
  --tool-call-parser glm47 \           # 네이티브 도구 호출 파싱
  --reasoning-parser glm45 \           # thinking 출력 파싱
  --enable-auto-tool-choice

5디렉토리(저장소) 구조 해부

파일 16개가 전부 — '코드 저장소'가 아니라 '런치 허브'다.

저장소를 열면 가장 먼저 놀라는 점 — 추론 코드도, 모델 설정 파일도, 가중치도 없다. 전부 합쳐 16개 파일이고, 대부분 문서(README·배포 가이드·라이선스)와 벤치마크 이미지다. 모델의 '실체'는 Hugging Face/ModelScope에 있고, 이 저장소는 "여기 모델 나왔으니 이렇게 받아서 이렇게 돌려라"를 안내하는 관문이다.

6학습 포인트 (기술별)

이 레포에서 실제로 무엇을 배울 수 있는가 — 기술별 + 실습 아이디어.

7하드웨어 / 시스템 요구사항

내 손으로 돌릴 수 있나? — 솔직히 말하면 '노트북은 불가'.

냉정하게 시작하자. 744B는 FP8로도 가중치만 약 750GB, BF16면 약 1.5TB다. 단일 GPU엔 절대 안 들어간다. README의 서빙 명령이 모두 --tensor-parallel-size 8인 것에서 보듯, 현실적 최소선은 고용량 GPU 8장짜리 노드다. (저장소가 정확한 VRAM 수치를 못박진 않았으므로 아래는 가중치 크기로부터의 합리적 추정이다.)

8직접 해볼 수 있는 실습 과제

난이도별로 — 가중치가 없어도 대부분 손으로 해볼 수 있다.

대부분의 서빙 엔진과 Z.ai API는 OpenAI 호환 인터페이스를 제공한다. 즉 모델만 바꾸면 익숙한 코드로 GLM-5를 부를 수 있다. 아래는 추론 모드를 켠 호출의 골격이다(엔드포인트·키는 환경에 맞게).

# OpenAI 호환 클라이언트로 GLM-5 호출 (개념 예시)
from openai import OpenAI
client = OpenAI(base_url="https://api.z.ai/v1", api_key="...")

resp = client.chat.completions.create(
    model="glm-5.2",
    messages=[{"role":"user","content":"이 레포의 버그를 찾아 고쳐줘 ..."}],
    extra_body={"reasoning_effort":"high"}  # 생각 더 깊게 (끄려면 enable_thinking=false)
)
print(resp.choices[0].message.content)

9관련 기술 심화 학습 로드맵

GLM-5를 발판으로 '거대 MoE LLM의 설계·서빙'을 제대로 — 6주 계획.

10핵심 키워드 사전

문서·코드에 자주 나오는 용어 — 한 줄 정의.

11참고 링크

원문으로 더 깊이 — 공식 소스 위주.

• GitHub 저장소: github.com/zai-org/GLM-5
• 기술보고서(GLM-5): arXiv 2602.15763 — From Vibe Coding to Agentic Engineering
• IndexShare 논문: arXiv 2603.12201
• 공식 블로그: z.ai/blog/glm-5 · glm-5.2
• 모델 가중치(HuggingFace): huggingface.co/zai-org (GLM-5 / 5.1 / 5.2, 각 BF16·FP8)
• 후처리 RL 인프라: github.com/THUDM/slime
• 웹챗 / API: chat.z.ai · docs.z.ai · bigmodel.cn
• TrendShift 페이지: trendshift.io/repositories/22855