Solar-Open-100B 무결성 검증 및 GLM-4.5 트러블슈팅
Solar-Open-100B 무결성 검증 및 GLM-4.5 트러블슈팅: 기술적 포스트모템
1. 서론: "국가대표 AI"를 직접 테스트하며 마주한 의문들
2026년 1월, 대한민국 AI 산업은 정부 주도의 '국가대표 AI' 프로젝트와 관련한 뜨거운 기술적 논쟁에 휩싸였습니다. 국내 스타트업 업스테이지(Upstage)가 야심 차게 공개한 Solar-Open-100B 모델이 중국 Zhipu AI의 GLM-4.5-Air 를 무단 복제했다는 의혹은 엔지니어인 필자에게도 단순한 가십거리가 아니었습니다. 필자는 해당 모델을 직접 로컬 서버에 배포하여 테스트하던 중, 심각한 응답 품질 저하와 알 수 없는 출력 오류를 경험했기 때문입니다.
당시 필자가 겪은 문제는 단순한 모델의 지능 부족으로 치부하기엔 석연치 않았습니다. 모델은 답변 중간에 멈추거나, <think> 와 같은 생소한 태그를 뱉어내며 혼잣말을 중얼거렸고, 템플릿은 엉망이 되기 일쑤였습니다. 이 현상은 모델 자체의 결함이라기보다는, 추론 엔진(Inference Engine)과 모델 아키텍처 간의 구조적 불일치(Structural Incompatibility) 에서 오는 전형적인 증상이었습니다.
본 포스트는 필자가 직접 경험한 성능 저하 이슈의 원인을 파헤치기 위해 수행한 기술적 포스트모템(Post-mortem) 기록입니다. 업스테이지의 기술 보고서, GLM 아키텍처 문서, 그리고 llama.cpp 소스 코드를 뜯어보며 확인한 사실들을 바탕으로, Solar-Open-100B의 정체성을 규명하고 필자가 겪은 문제를 해결한 과정을 공유하고자 합니다.
1.1 배경: '프롬 스크래치' 논란과 나의 테스트 환경
정부의 '소버린 AI' 프로젝트는 해외 모델의 가중치를 가져다 튜닝한 것이 아닌, 바닥부터(From Scratch) 만든 독자 모델을 요구했습니다. 업스테이지는 이에 맞춰 Solar-Open-100B를 내놓았지만, 경쟁사로부터 "구조가 96.8% 똑같다"는 표절 의혹을 받았습니다. 필자는 이 논란의 진위를 떠나, 당장 내 서버에서 돌아가는 이 모델이 왜 Llama 3 템플릿에서 오작동하는지 기술적으로 이해해야만 했습니다.
1.2 이 글의 목표
모델 무결성 검증: 필자가 사용 중인 이 모델이 정말 '복붙' 모델인가? (LayerNorm 파라미터 및 학습 로그 분석)
아키텍처 해부: 필자의 추론 서버를 괴롭힌 GLM-4.5 기반의 MoE 구조 분석.
트러블슈팅: llama.cpp에서 발생한 호환성 문제의 원인(Thinking Token, Chat Template) 규명.
최적화 가이드: 필자가 적용하여 성능을 정상화시킨 구체적인 해결책 공유.
2. Solar-Open-100B와 GLM-4.5-Air: 쌍둥이인가, 이복형제인가?
필자는 먼저 두 모델의 기술적 사양(Spec)을 정밀 대조해 보았습니다. MoE(Mixture-of-Experts) 모델은 파라미터 수와 전문가 배치 방식에서 고유한 지문을 가지기 때문입니다.
2.1 아키텍처 정밀 비교
특성 (Feature)
Upstage Solar-Open-100B
Zhipu AI GLM-4.5-Air
필자의 분석 (Technical Note)
아키텍처 유형
MoE Transformer
MoE Transformer
동일. 희소(Sparse) 모델 구조.
활성 파라미터
12 Billion (per token)
12 Billion
완전 일치. 추론 시 메모리 대역폭 요구량이 똑같음.
전문가 구성
129 Experts (Routed + Shared)
(유사 구조 추정)
128+1 구조. 이는 DeepSeek-V3나 GLM-4 계열 특유의 설계임.
라우팅 방식
Top-8 selection
(비공개)
128개 중 8개를 고르는 방식 또한 매우 유사함.
컨텍스트 길이
128k Tokens
128k Tokens
동일.
2.2 '생태계 호환성'의 함정
분석 결과, 두 모델은 12B Active Parameters와 129개 전문가 구성이라는 점에서 구조적으로 쌍둥이에 가까웠습니다. 업스테이지가 GLM-4.5-Air의 설계도(Blueprint) 를 채택했다는 것은 자명해 보였습니다. 이는 껍데기(아키텍처)가 GLM이라면, 그 안에서 돌아가는 추론 로직 또한 GLM의 문법을 따라야 함을 의미합니다. 필자가 관성적으로 Llama 계열의 템플릿을 적용한 것이 오류의 시작이었습니다.
3. 표절 의혹 검증: 내 모델은 '짝퉁'이었나?
서버에서 모델이 이상하게 동작하자 "혹시 진짜로 짝퉁 모델이라서 성능이 떨어지는 건가?"라는 의심이 들었습니다. 이를 검증하기 위해 Sionic AI가 제기한 'LayerNorm 파라미터 유사도 96.8%' 이슈를 파헤쳤습니다.
3.1 코사인 유사도의 함정과 피어슨 상관계수
LayerNorm 파라미터는 모델 전체의 0.0004%에 불과합니다.
코사인 유사도(96.8%): 벡터의 '방향'을 봅니다. 같은 아키텍처라면 학습 데이터가 달라도 정규화 방향은 비슷할 수 있습니다.
피어슨 상관계수(-0.01): 이것이 핵심이었습니다. 두 모델 파라미터 값의 분포는 통계적으로 전혀 상관관계가 없었습니다. 만약 복제해서 미세 조정했다면 이 값도 높아야 정상입니다.
3.2 학습 로그(WandB)가 말해주는 것
업스테이지가 공개한 학습 로그를 확인해 보니, 학습 초기에 손실(Loss) 값이 치솟았다가 떨어지는 'Initial Loss Spike' 가 선명했습니다. 이는 백지상태(Random Initialization)에서 학습을 시작했다는 강력한 증거입니다. 결론적으로, 필자가 돌리고 있는 모델은 '짝퉁'이 아니라, GLM 아키텍처를 차용하여 한국어 위주의 자체 데이터로 처음부터 학습시킨 독자 모델이었습니다.
4. 트러블슈팅: 내가 겪은 오류의 기술적 원인
필자의 서버에서 발생한 문제들은 범용 추론 엔진(llama.cpp, vLLM)이 GLM 아키텍처 특유의 'Thinking Process'를 소화하지 못해 발생한 호환성 이슈였습니다.
4.1 "모델이 혼잣말을 해요" - Hybrid Reasoning의 역습
원인: GLM-4.5 기반 모델은 'Thinking Mode' 와 'Direct Mode' 를 하이브리드로 지원합니다. 하지만 일반적인 Llama 3 템플릿은 <think> 태그를 특수 토큰으로 인식하지 못하고 일반 텍스트로 렌더링해 버립니다. 결과적으로 사용자의 눈에는 모델의 내부 추론 과정이 노출되는 버그처럼 보였고, 중요한 답변은 생성 길이 제한에 걸려 잘리는 현상이 발생했습니다.
4.2 토크나이저와 특수 토큰(Special Tokens)의 불일치
필자가 사용하던 구버전 llama.cpp는 GLM 전용 특수 토큰들( <sop> , <|user|> , <span> 등)을 제대로 처리하지 못했습니다. 엔진이 EOS(End of Sentence) 토큰을 인식하지 못해 무한 생성 루프에 빠지거나 횡설수설하는 결과를 낳았습니다.
5. 해결: 내 서버를 정상화시킨 조치들
5.1 업데이트 및 코드 수정
최신 빌드 적용: GLM-4.5 지원이 추가된 PR #14939가 병합된 최신 llama.cpp 빌드(b4600 이상)로 업데이트했습니다.
소스 코드 확인: common/chat.cpp 내의 함수가 GLM-4.5의 독특한 도구 호출 스키마를 처리할 수 있는지 점검했습니다.
5.2 Chat Template의 명시적 재정의
모델 실행 시 GLM-4.5 표준에 맞는 Jinja 템플릿을 명시적으로 주입했습니다.
Thinking 끄기: 시스템 프롬프트 끝에 /nothink 를 추가하거나, 템플릿 변수에서 enable_thinking=false 로 강제 설정했습니다.
태그 파싱: 프론트엔드 파서에서 정규식(Regex)을 사용하여 <think> 태그를 필터링했습니다.
5.3 결과: 성능의 재발견
조치 후, Solar-Open-100B는 응답 속도가 체감상 2배 이상 빨라졌으며, 한국어 뉘앙스 처리와 복잡한 지시 이행 능력에서 원본 GLM-4.5-Air를 상회하는 성능을 보여주었습니다.
6. 결론: "아는 만큼 보인다"
Solar-Open-100B는 표절 논란이라는 홍역을 치렀지만, 기술적으로는 '검증된 글로벌 아키텍처(GLM)' 에 '우리만의 데이터(Korean Tokens)' 를 담아낸 영리한 모델이었습니다. 이 모델의 잠재력을 100% 끌어내기 위해서는 개발자들이 그 아키텍처의 특성을 이해하고 파이프라인을 최적화하는 노력이 반드시 필요합니다.
[참고] 용어 설명
From Scratch: 남의 모델 가중치를 가져다 쓰는 게 아니라, 맨바닥에서부터 직접 학습시킨 모델.
MoE (Mixture-of-Experts): 여러 전문가 모델 중 필요한 부분만 활성화하여 사용하는 효율적인 아키텍처.
Thinking Token: 모델이 최종 답변을 내기 전 추론 과정을 수행할 때 생성하는 특수 문자열.