이번 논문이 평소 흔히 볼 수 있는 모델 발표 블로그 글과 달리, 깊이 있는 내용을 다뤄서 정말 반가움
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에서 독립적인 성능 검증 결과도 궁금함
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은 아직 대규모 코드베이스 이해에는 미숙함