GLM-4.5: 에이전틱, 추론, 코딩(ARC) 파운데이션 모델
(arxiv.org)- GLM-4.5는 오픈소스 Mixture-of-Experts (MoE) 대형 언어 모델로, 에이전트성, 추론, 코딩 성능이 뛰어남
- 이 모델은 23T 토큰으로 다단계 훈련 및 전문가 모델 반복, 강화학습을 통해 발전함
- TAU-Bench, AIME 24, SWE-bench Verified 등 다양한 핵심 벤치마크에서 상위권 성적 기록함
- 적은 수의 파라미터로도 효율적인 성능을 내며, 주요 상용 모델들에 근접하거나 앞섬
- GLM-4.5와 소형 버전 GLM-4.5-Air를 공개해 연구 및 AI 시스템 개발에 활용할 수 있음
개요
- GLM-4.5는 3550억 총 파라미터와 320억 활성 파라미터를 지닌 오픈소스 Mixture-of-Experts (MoE) 대형 언어 모델임
- 하이브리드 추론 방식을 적용하여, 깊이 있는 사고(Thinking) 모드와 즉각적 응답(Direct Response) 모드를 모두 지원함
- 23조 개의 토큰을 사용한 다단계 학습과 전문가 모델 반복, 그리고 강화학습 기반 포스트 트레이닝을 거침
- 그 결과, 에이전트성(Agentic), 추론(Reasoning), 코딩(Coding·ARC) 작업 영역에서 높은 성적 달성
- TAU-Bench 70.1%, AIME 24 91.0%, SWE-bench Verified 64.2% 기록
- GLM-4.5는 경쟁 모델 대비 적은 파라미터로, 전체 모델 중 3위, 에이전트 벤치마크 기준 2위를 차지함
- 대형 모델 GLM-4.5(3550억 파라미터)와 소형화된 GLM-4.5-Air(1060억 파라미터) 두 버전을 모두 공개함
- 전체 코드, 모델, 상세 정보는 공식 GitHub(https://github.com/zai-org/GLM-4.5)에서 확인 가능함
LLM 성능 평가: 에이전트성, 추론, 코딩 벤치마크
- GLM-4.5 및 글로벌 주요 모델들을 12종의 대표적 벤치마크(MMLU-Pro, AIME 24, SWE-Bench Verified 등)에서 테스트함
- GLM-4.5는 전체 평균 순위 3위, GLM-4.5-Air는 6위를 기록함
- 에이전트성 점수 기준, OpenAI o3의 뒤를 이어 2위, 코딩 벤치마크에서도 Claude Sonnet 4와 근접한 3위를 달성함
- GLM-4.5는 DeepSeek-R1의 절반, Kimi K2의 3분의 1 파라미터로 유사한 성능을 보임
- SWE-bench Verified 항목 성능 대비 파라미터 수로도 GLM-4.5와 GLM-4.5-Air는 Pareto Frontier상에 위치함
- 2025년 7월 28일 기준 성능 데이터임
서론
- 대형 언어 모델(LLM) 은 기존의 범용 데이터 저장고에서 범용 문제 해결기로 빠르게 진화하고 있음
- 인공지능의 종착점인 AGI(Artificial General Intelligence)는 여러 영역에서 인간 수준의 인지 능력을 갖춘 모델을 지향함
- 이를 위해선 복잡한 문제 해결력, 일반화, 자기 개선 능력이 통합적으로 요구됨
- 실제 업무와 복잡한 전문 문제 해결에 중요한 3대 핵심 능력은 다음과 같음:
- 에이전트성 능력: 도구 및 외부 세계와의 상호작용
- 복합 추론: 수학/과학 등 복잡한 단계적 문제 해결
- 고급 코딩: 실질적인 소프트웨어 엔지니어링 수행 능력
- 기존 SOTA 상용 모델(OpenAI, Anthropic)은 개별 영역에서 특화 성능을 보이나, 오픈소스 모델 가운데 3대 분야 모두에서 우수한 공개 모델은 부족함
GLM-4.5 및 GLM-4.5-Air 모델 소개
- GLM-4.5/GLM-4.5-Air는 에이전트성·추론·코딩 모든 분야에서 오픈소스 최고 수준 성능을 보임
- 두 모델 모두 하이브리드 추론 모드를 지원
- Thinking Mode는 복잡 추론 및 에이전트성에 강점
- Non-thinking Mode는 빠른 응답에 특화
- GLM-4.5의 주요 성적:
- 에이전트성: TAU-Bench 70.1%, BFCL v3 77.8%, BrowseComp 26.4%(경쟁 상용 모델 대비 우위)
- 추론: AIME 24 91.0%, GPQA 79.1%, LiveCodeBench 72.9%, HLE 14.4%
- 코딩: SWE-bench Verified 64.2%, Terminal-Bench 37.5%(GPT-4.1 및 Gemini-2.5-pro 대비 우위, Claude Sonnet 4와 근접)
- GLM-4.5-Air는 1060억 파라미터로, 1000억 규모 모델 중에서도 Qwen3-235B-A22B, MiniMax-M1와 대등하거나 우위
벤치마크 성능 현황 및 특징
- 12개 주요 벤치마크 전반에서 GLM-4.5, GLM-4.5-Air 모두 높은 순위 기록
- GLM-4.5는 에이전트성, 추론, 코딩 분야에서 고른 성능, 파라미터 효율성 두드러짐
- SWE-bench Verified 기준 파라미터 수 대비 최고 효율 영역(Pareto Frontier) 달성
- 상용 및 오픈소스 여러 모델과 함께 정밀한 성능 비교 진행
공개 및 오픈소스 지원
- GLM-4.5/GLM-4.5-Air 모델은 Z.ai, BigModel.cn뿐만 아니라 Huggingface(https://huggingface.co/zai-org/GLM-4.5)에도 공개됨
- 벤치마크 재현성을 위해 평가 툴킷(https://github.com/zai-org/glm-simple-evals)까지 오픈소스로 제공함
사전훈련
아키텍처
- GLM-4.5 시리즈는 Mixture-of-Experts(MoE) 구조를 채택, 훈련 및 추론의 연산 효율성을 크게 높임
- MoE 레이어에 loss-free balance routing과 시그모이드 게이팅을 적용함
- DeepSeek-V3, Kimi K2와 달리 모델의 폭(히든 차원, 라우트 전문가 수)은 줄이고 깊이(레이어 수)를 늘림. 더 깊은 모델이 추론 능력 성장에 효과적임
- Self-Attention엔 Grouped-Query Attention + partial RoPE 적용, 96개 attention head로 히든 차원 5120에 2.5배수 attention head 구성
- 헤드 수 증가가 훈련 손실엔 영향이 없지만, 실제 추론·벤치마크 성능에는 긍정적 영향 확인
- QK-Norm 적용으로 attention logit 값의 안정성 제고
- GLM-4.5, GLM-4.5-Air 모두 MoE 레이어 기반 MTP(Multi-Token Prediction) 레이어를 추가하여 추론시 speculative decoding 지원
- 아키텍처 파라미터 집계 과정에서는 MTP 레이어의 파라미터는 포함, 워드 임베딩 및 출력 레이어는 미포함
결론 및 기대 효과
- GLM-4.5/GLM-4.5-Air는 오픈소스 AI 시장에서 고성능, 효율성, 범용성을 두루 갖춘 차세대 언어 모델임
- 여러 분야 통합/고난도 문제 해결 역량, 상용 모델 경쟁력 확보, 파라미터 효율성에서 두각을 나타냄
- 학계, 산업계, 개발자 연구 전반에서 오픈소스 대형 언어 모델의 혁신 기반으로 기여 가능성 확장
해커뉴스 댓글도 그렇고, 레딧 LocalLLaMA 포럼에서 GLM이 꽤 좋다는 평이 있네요
GLM 4.5 AIR IS SO FKING GOODDD
- GLM 4.5 Air는 정말 엄청 빠르고, 툴 호출 능력도 우수함 (로컬은 아니고 Open Router로 테스트함)
- GPT-5 Mini와 비교 시 작업 종류에 따라 우위가 갈릴 정도
- GLM 4.5V 등 다른 GLM 모델도 모두 좋음
- 특정 작업(예: 소설 작성, 코딩)에 따라 GLM이 GPT보다 자연스럽고 덜 제한적임
Hacker News 의견
-
이번 논문이 평소 흔히 볼 수 있는 모델 발표 블로그 글과 달리, 깊이 있는 내용을 다뤄서 정말 반가움
Zhipu/Tsinghua 팀이 '무엇'뿐만 아니라 '어떻게'까지 상세히 설명해서, 이러한 모델을 직접 만들거나 활용하고자 하는 사람에게 특히 흥미로운 정보임
특히 Sec 3의 훈련 이후(post-training) 방법론이 인상적임
추론/에이전트/챗 등 전문화된 '전문가 모델'을 따로 만든 다음, 그 능력을 최종 통합 모델로 증류(distill)하는 접근 방식이 매력적임
여러 역할을 대충 하는 제너럴리스트 모델의 한계를 훨씬 체계적으로 해결하려는 시도임
단순히 데이터를 섞기만 하는 게 아니라, 일반적인 모델이 전문가 집단에게 배우도록 설계한 셈임
RL 실험 결과 중 한 가지 흥미로운 점은, 전체 64K 컨텍스트에서 한 번에 RL을 적용하는 방식이 단계별 RL보다 성능이 더 좋았다는 것임(Fig 6 참고)
많은 팀들이 반대로 생각할 텐데, 실제 결과는 다름
그리고 함수 호출 포맷으로 XML 템플릿을 쓰는 소소하지만 똑똑한 선택 덕분에 JSON 이스케이핑 문제에서 벗어남(Fig 4 참고)
실전에서는 JSON 안에서 코드를 이스케이프 처리하는 게 매우 골치 아픈 일임
SWE-bench에서의 성능도 상당해서, 훨씬 큰 규모나 상용 모델과 견줄 만함
앞으로 궁금한 점은, 이런 하이브리드 훈련법이 ARC-style 평가 이외의 환경에서도 통할지 여부임
예를 들어 실제 업무처럼 API 문서가 없거나, 에러가 자주 나는, 입력도 모호한 복잡한 워크플로우에서 에이전트 성능도 잘 유지될지 궁금함-
이런 post/mid-training 방식의 트윅이, 이미 데이터와 라벨이 풍부하게 검증된 특정 도메인 학습에선 꼭 필요할지 궁금함
소수 팀이 최신 스케일 업 트레이닝 스택만 잘 따라도 충분한지, 아니면 이런 기법을 안 쓰면 큰 차이가 나는지 알고 싶음 -
혹시 괜히 트집 잡는 것처럼 보일까 걱정되지만, 글의 문체가 LLM 특유의 느낌이 강하게 풍김
이전에도 같은 지적을 본 적 있음 링크
이런 부분은 지적하는 게 온라인 환경을 건강하게 지키는 길이라고 생각함
-
-
GLM-4.5 코딩 모델을 꽤 오래 써봤는데, 성능이 정말 뛰어남
내가 개발 중인 코딩 에이전트 Octofriend에서 GLM-4.5를 돌릴 때 Claude 4와 착각한 적도 있음
내 경험상 Claude가 전체 코드베이스를 문맥으로 두고 시스템 상호작용을 고려해야 하는 상황에 좀 더 강한 느낌임
반면 GLM-4.5는 '정직한' 편으로, Claude가 흔히 테스트 코드를 고쳐서 문제를 슬쩍 넘기는 식의 행동을 잘 안 함
둘 다 수준이 높지만, GLM-4.5가 Claude 4 Sonnet이나 4.1 Opus에서 못 잡은 버그를 찾아준 적도 있음
디버깅 한정으론 Claude가 근소하게 더 자주 이기지만, 차이는 크지 않음
GPT-5와 비교하자면 Claude와 GLM 모두 일관성이 더 높음
GPT-5는 정말 멋진 결과를 내는 경우가 종종 있지만, 한 번 비뚤어지면 다시 정상 궤도로 돌리기가 어렵고 답답함
Octofriend 참고: https://github.com/synthetic-lab/octofriend-
이 댓글을 보고 Kilocode에서 GLM-4.5를 테스트해봤음
오늘 하루 종일 Gemini CLI로 컴파일러 코드의 까다로운 버그를 잡으려 했는데 잘 안 됐음
그런데 GLM-4.5는 바로 핵심 문제를 짚어냄
Gemini CLI는 엉뚱한 함수만 의심하고, 어설픈 수정을 반복했는데 결국 전혀 상관없는 부분임
확실히 GLM-4.5의 문제 집중력이 돋보임 -
나도 GLM-4.5를 소규모 프로젝트나 짧은 요청에서 좋게 써본 경험 있음
아쉽게도 문맥이 길어질수록 성능이 떨어지는 느낌이라, 지금은 Sonnet 4의 백업용으로 활용중임 -
aider에서 architect 모드를 활용중임
Deepseek R1(상위 설계 담당) + Qwen3 480B(로우레벨 코딩 담당, 혹은 qwen code API 활용) 조합으로 씀
이 구성이 정말 잘 작동함
99.99% 문제를 혼자 해결하는 수준임
아직 aider에서 역할 분리가 완벽하지 않아서, 직접 워크플로우를 개선한 툴을 만들려고 함 -
첫 번째 포인트에 공감함
나 역시 Claude는 문맥이 많을수록 더 잘 작동하고, GLM-4.5는 그런 상황에선 결과가 별로임
-
-
GLM-4.5 시리즈가 전체/액티브 파라미터 수를 셀 때, 임베딩과 출력 레이어를 제외하고 MTP 레이어만 포함하는 방식임
내가 계산한 바(355B A32B)와 맞는 내용임
GPT OSS 시리즈는 임베딩/출력 둘 다 전체 파라미터엔 넣고, 액티브 파라미터엔 출력만 포함함
Qwen3 시리즈는 전체/액티브 모두 임베딩과 출력을 다 포함시킴
파라미터 계산 방식이 모델마다 달라서, 왜 표준이 없는지, 어떤 계산법이 더 합리적인지 궁금함- 총 파라미터 수는 메모리 요구사항에 직결되기 때문에 전체 파라미터를 모두 세는 게 맞음
액티브 파라미터의 경우 언임베딩(unembedding) 파라미터는 토큰 생성마다 모두 사용되지만, 임베딩은 컬럼 하나만 쓰이기 때문에 이런 특성을 반영해서 계산해야, 대역폭 및 레이턴시와의 관계를 제대로 파악할 수 있음
- 총 파라미터 수는 메모리 요구사항에 직결되기 때문에 전체 파라미터를 모두 세는 게 맞음
-
앞으로 몇 년 안에, 2000달러 정도의 워크스테이션 PC에서 Sonnet 4 수준의 로컬 오픈 모델로 코딩이 가능해질 거라고 봄
현재의 클라우드 기반 모델도 유용하지만, 개발자 경험에 핵심이 될 툴인 만큼 로컬에서 돌릴 수 있길 원함-
내 생각엔 2년이 아니라 올해 말이면 충분할 것 같음
-
오픈 소스 관점에서 이런 모델은 필수임
그렇지 않으면 오픈 소스 개발 자체가 지속불가능해질 수 있음
오히려 2년 내 Sonnet 4 이상 성능을 2천불 PC에 올릴 수 있으리라 더 기대함
-
-
이번 모델이 기존 상용 프론티어 모델과 거의 대등하게 비교될 수 있는 첫 번째 오픈 모델이라는 느낌임
파라미터 효율성만 봐도 훈련법에서 진짜 혁신이 있었음을 알 수 있음
Aider의 LLM Leaderboard에서 독립적인 성능 검증 결과도 궁금함 -
나처럼 논문 초록부터 읽고 싶은 분들을 위해 링크 남김 https://www.arxiv.org/abs/2508.06471
-
아파치 라이선스라는 점까지 너무 멋진 공개임
오픈소스 모델이 한계에 지속적으로 도전하는 모습이 정말 기쁨 -
이 논문에서 관찰한 내용이 너무 많아서, 각각만 따로 논문을 써도 될 정도임
특히 학습 과정과 데이터 수집/합성에 대한 경험이 굉장히 풍부함
혹시 저자들이 이전에도 비슷한 수준의 멋진 논문을 쓴 적 있는지 아는 사람 있음? -
논문의 그래프 지표가 헷갈림
첫 번째 그림엔 sonnet 4의 swebench 점수가 53쯤 나오는데, 그 다음엔 70에 가까움
실제 값은 70에 더 가까움 참고 -
왜 Qwen3은 코딩 벤치마크엔 빠져 있는데, 다른 벤치마크엔 포함됐는지 궁금함
-
Section 4.3.2에 Qwen3-Coder가 포함됨
-
Qwen은 아직 대규모 코드베이스 이해에는 미숙함
-