Mac Studio 512GB에서 GLM-5.2 실행해보기
GLM-5.2는 Hugging Face 모델 카드 기준 753B parameters로 표시되는 MoE 모델이다. 다만 매 토큰마다 전체가 모두 활성화되는 dense 모델은 아니고, GLM-5 계열 설명처럼 대략 40B 안팎의 active parameters를 쓰는 구조로 보는 편이 맞다. 숫자만 보면 개인 장비에서 건드릴 대상이 아닌 것처럼 보이지만, Unsloth가 공개한 GLM-5.2-GGUF와 MLX 커뮤니티 변환본을 이용하면 이야기가 조금 달라진다. 이번 글의 중심은 512GB 메모리를 가진 Mac Studio 한 대에서 GLM-5.2를 어디까지 실행할 수 있는지 확인하는 것이다.
처음 목표는 사실 Mac Studio가 아니었다. 원래는 DGX Spark만 가지고 GLM-5.2를 어디까지 돌릴 수 있는지 보려고 했다. 다만 DGX Spark에서 현실적으로 시도할 수 있는 753B급 MoE의 1-bit, 2-bit 양자화만으로는 품질이나 활용 폭이 아쉬울 것 같았다. 그래서 실험을 시작하면서 동시에 512GB 메모리를 가진 Mac Studio를 중고로 살지, 잠깐 임대할 수 있는 방법이 있을지 미리 찾아보고 있었다.
그때 nacyot 님이 본인 집에 있는 Mac Studio를 원격으로 쓸 수 있게 열어주셨다. 덕분에 MLX 변환본과 GGUF Metal 조합을 하나씩 내려받아 실행했고, 마지막에는 평소 쓰던 RSS/커뮤니티 제목 번역 벤치로 비교할 수 있었다. 문제는 다운로드 양이었다. Mac Studio에서 받은 모델만 MLX mxfp4 368G, MLX 4bit 401G, MLX DQ4plus-q8 433G, GGUF UD-IQ1_M 213G, GGUF UD-IQ2_M 222G로, 합치면 약 1.64TB였다. MLX 4-bit 계열만 평균을 내도 모델 하나가 약 401GB다.
1Gbps급 KT 회선이라고 보면 일 QoS 기준은 자료와 시점에 따라 대략 100GB 또는 150GB로 언급된다. 어느 쪽으로 잡아도 이번에 받은 1.64TB는 10일치가 훌쩍 넘는 양이다.
다운로드를 반복하는 동안 nacyot 님 집 인터넷 대역폭을 거의 다 써버렸고, 제한에 계속 걸려서 며칠 동안 집에서 넷플릭스는 물론 이미지 하나 뜨는 것도 느려지는 상황이 생겼다. 실험은 재미있었지만, 그 부분은 정말 미안했다.
DGX Spark 두 대의 결과와 Gemma4 31B Dense MTP는 기준점을 잡기 위한 보조 비교로 붙였다. 메인은 Mac Studio다.
실험에 쓴 장비와 모델
장비는 Mac Studio를 중심으로 두 종류를 썼다.
| 장비 | 역할 |
|---|---|
| Mac Studio 512GB | MLX 변환본, GGUF Metal 실행 |
DGX Spark spark, spark2 |
보조 비교: GLM-5.2 GGUF 2-bit 65K context, Gemma4 31B Dense MTP |
DGX Spark 두 대는 QSFP/CX7 직결망으로 연결했다. spark에서 llama.cpp 서버를 띄우고, spark2에는 rpc-server를 띄워 10.222.0.2:50052로 붙였다. 이 구성은 이전 글인 GLM-5.2를 DGX Spark 두 대로 돌려보기에서 먼저 확인했던 방식이다.
이번에 Mac Studio에서 확인한 모델은 다음과 같다.
| 계열 | 모델/양자화 | 대략 크기 | 실행 방식 |
|---|---|---|---|
| MLX | mlx-community/GLM-5.2-mxfp4 |
368G | mlx_lm.server |
| MLX | mlx-community/GLM-5.2-4bit |
401G | mlx_lm.server |
| MLX | mlx-community/GLM-5.2-DQ4plus-q8 |
433G | mlx_lm.server |
| GGUF | Unsloth UD-IQ1_M |
213G | llama.cpp Metal |
| GGUF | Unsloth UD-IQ2_M |
222G | llama.cpp Metal |
Mac Studio에서 새로 받은 모델 파일만 합치면 약 1.64TB다. 그중 MLX 4-bit 계열 세 개(mxfp4, 4bit, DQ4plus-q8)의 평균 크기는 약 401GB였다. “모델 하나가 수백 GB”라는 표현이 과장이 아니라 실제 다운로드 단위가 그랬다.
DGX Spark에서는 다음 두 가지를 추가로 비교했다.
| 계열 | 모델/양자화 | 실행 방식 |
|---|---|---|
| GLM-5.2 GGUF | UD-IQ2_M |
llama.cpp CUDA/RPC, -c 65536 |
| Gemma4 | 31B Dense Q8 + MTP draft | llama.cpp CUDA, reasoning off |
여기서 UD-IQ1_M은 1-bit 근처, UD-IQ2_M은 2-bit 근처 양자화다. mxfp4, 4bit, DQ4plus-q8은 MLX 쪽에서 더 큰 용량을 쓰는 대신 품질을 기대할 수 있는 후보로 봤다.
Mac Studio에서 MLX 모델 실행
MLX 계열은 파일 크기가 크다. mxfp4가 약 368G, 4bit가 약 401G, DQ4plus-q8이 약 433G였다. 다운로드 자체가 꽤 오래 걸렸고, 그래서 한 번에 다 받지 않고 하나씩 다운로드한 뒤 실행과 벤치를 확인했다.
GLM-5.2는 thinking/reasoning 성향이 있어서, 제목 번역처럼 짧은 작업에서는 생각 과정을 끄는 것이 중요했다. MLX server에서는 다음처럼 chat template 설정을 줬다.
mlx_lm.server --model <model-dir> --host 127.0.0.1 --port <port> --chat-template-config '{"enable_thinking": false}'
이전 단문 생성 벤치에서는 mlx_lm.generate 기준으로 mxfp4가 꽤 좋은 균형을 보였다. 다만 이번 글의 최종 비교는 모두 OpenAI-compatible server를 통해 같은 제목 번역 벤치를 돌린 값이다. 그래서 이전 단문 generate 속도와 숫자를 직접 비교하면 안 된다.
Mac Studio에서 GGUF Metal 실행
GGUF 쪽은 Unsloth GLM-5.2-GGUF의 UD-IQ1_M, UD-IQ2_M을 사용했다. 둘 다 여러 shard로 되어 있지만 llama.cpp에서는 첫 번째 shard를 모델로 지정하면 된다.
llama-server -m GLM-5.2-UD-IQ2_M-00001-of-00006.gguf -ngl 999 -c 32768 --host 127.0.0.1 --port 18222 --reasoning off --reasoning-budget 0
흥미로웠던 점은 Mac Studio의 GGUF Metal 조합이 MLX server 조합보다 제목 번역 벤치에서는 빨랐다는 것이다. 특히 UD-IQ1_M과 UD-IQ2_M은 모두 30개 제목 전체를 88초 안팎에 끝냈다. 다만 품질에서는 차이가 있었다. UD-IQ1_M은 1-bit치고는 번역이 되지만, 몇몇 항목에서 한중일 문자가 섞이는 출력 결함이 나왔다.
DGX Spark 두 대에서 GLM-5.2 2-bit 65K context
DGX Spark 쪽은 UD-IQ2_M을 65K context로 띄웠다.
llama-server -m GLM-5.2-UD-IQ2_M-00001-of-00006.gguf --rpc 10.222.0.2:50052 -ngl 999 -sm layer -c 65536 -np 1 --reasoning off --reasoning-budget 0
이 조합의 의미는 짧은 번역 속도보다는 “DGX Spark 두 대로 총 파라미터 기준 753B급 MoE의 2-bit 모델을 실제로 긴 컨텍스트로 띄울 수 있는가”에 있다. 이전 테스트에서 65K context는 48.6K tokens 정도까지, 131K context는 약 84K tokens까지 핵심 사실 회수 QA가 성공했다. 반면 262K context는 서버를 억지로 띄울 수는 있어도 prefill 속도가 너무 느려 실사용 후보로 보기는 어려웠다.
같은 벤치셋으로 다시 비교하기
마지막에는 평소 번역 비교에 쓰던 RSS/커뮤니티 게시글 제목 30개를 다시 사용했다. 구성은 일본어 10개, 영어 10개, 중국어 10개다. 모두 한국어 제목 한 줄로 번역하게 했고, max_tokens=128, reasoning off 또는 no-think 계열 설정을 사용했다.
비교 대상은 다음 7개였다.
- Gemma4 31B Dense Q8 + MTP, DGX Spark
- GLM-5.2 GGUF
UD-IQ1_M, Mac Studio Metal - GLM-5.2 GGUF
UD-IQ2_M, Mac Studio Metal - GLM-5.2 MLX
mxfp4, Mac Studio - GLM-5.2 GGUF
UD-IQ2_M, DGX Spark 2대 RPC, 65K context - GLM-5.2 MLX
4bit, Mac Studio - GLM-5.2 MLX
DQ4plus-q8, Mac Studio
속도 결과는 다음과 같았다.
| 모델/조합 | 실행 위치 | 총 시간 | 평균/제목 | median | wall tok/s | 비고 |
|---|---|---|---|---|---|---|
| Gemma4 31B Dense Q8 + MTP | DGX Spark | 50.08s | 1.67s | 1.39s | 12.52 | draft accept 58.0% |
GLM-5.2 GGUF UD-IQ1_M |
Mac Studio Metal | 87.19s | 2.91s | 2.53s | 9.37 | 1-bit 근처 |
GLM-5.2 GGUF UD-IQ2_M |
Mac Studio Metal | 87.62s | 2.92s | 2.65s | 9.59 | 2-bit 근처 |
GLM-5.2 MLX mxfp4 |
Mac Studio MLX | 140.81s | 4.69s | 2.66s | 5.67 | MLX server 기준 |
GLM-5.2 GGUF UD-IQ2_M 65K |
DGX Spark 2대 RPC | 144.19s | 4.81s | 4.10s | 5.70 | 긴 컨텍스트 후보 |
GLM-5.2 MLX 4bit |
Mac Studio MLX | 148.92s | 4.96s | 2.70s | 5.51 | 품질 안정적 |
GLM-5.2 MLX DQ4plus-q8 |
Mac Studio MLX | 170.26s | 5.68s | 3.17s | 4.78 | 가장 무겁고 느림 |
여기서 wall tok/s는 전체 wall time 기준으로 completion token만 나눈 값이다. llama.cpp 서버는 별도의 predicted/generation 속도도 주지만, MLX server와 같은 표에서 맞추기 위해 전체 벤치 기준 값을 같이 봤다.
번역 품질은 Gemma4 31B Dense MTP가 가장 안정적이었다
품질 비교는 GPT-5.5 judge로 수행했다. 단순히 한국어가 자연스러운지만 보지 않고, 고유명사, 커뮤니티 은어, 원문 의미 보존을 함께 봤다. 기존 번역 벤치처럼 100점 만점의 주관 점수도 함께 붙였다.
| 품질 순위 | 모델/조합 | GPT-5.5 judge 점수 | 판단 |
|---|---|---|---|
| 1 | Gemma4 31B Dense Q8 + MTP | 92 | 가장 안정적. 고유명사, 커뮤니티 표현, 제목체에서 우세 |
| 2 | GLM-5.2 MLX 4bit |
86 | GLM 계열 중 품질 상위. 다만 일부 은어와 구어체 처리 약점 |
| 3 | GLM-5.2 MLX DQ4plus-q8 |
85 | 4bit와 거의 동급. 속도·용량 비용 대비 품질 이점은 작음 |
| 4 | GLM-5.2 MLX mxfp4 |
83 | 실용 균형은 좋지만 직역/잔류 표현이 조금 있음 |
| 5 | GLM-5.2 GGUF UD-IQ2_M Metal |
80 | 작은 용량 대비 괜찮지만 고유명사와 자연스러움 이슈가 있음 |
| 6 | GLM-5.2 UD-IQ2_M 65K RPC |
77 | 긴 컨텍스트 가능성이 장점. 짧은 제목 번역은 Mac GGUF/MLX보다 낫지 않음 |
| 7 | GLM-5.2 GGUF UD-IQ1_M Metal |
68 | 1-bit치고는 번역이 되지만 혼합 문자/깨짐이 있어 신뢰도 낮음 |
점수는 30개 제목 전체를 대상으로 한 절대 벤치마크 점수가 아니라, 이 벤치셋 안에서의 상대 평가다. 90점대는 바로 써도 큰 불안이 적은 수준, 80점대는 후편집하면 충분히 쓸 만한 수준, 70점대 이하는 특정 언어·표현에서 재검수가 필요한 수준으로 봤다.
대표적인 차이는 이런 식이었다.
お化けローカルLLM
Gemma4는 “또 하나의 괴물 로컬 LLM”으로 옮겼다. 반면 GLM 일부는 “요괴 로컬 LLM”이라고 했다. 일본어 お化け를 문자 그대로 살리기보다 한국어 기술 뉴스 제목으로 자연스럽게 바꾸는 쪽에서는 Gemma가 나았다.
阿波銀行
阿波銀行은 아와은행으로 옮기는 것이 맞다. Gemma와 MLX 일부는 이를 잘 처리했지만, DGX의 GLM-5.2 2-bit는 “아보은행”이라고 했다. 짧은 제목 번역에서 이런 고유명사 오류는 꽤 크게 보인다.
yyds
중국어 커뮤니티 표현 yyds는 Gemma가 “진짜 최고입니다”로 풀었다. 반면 GLM 계열 대부분은 yyds를 그대로 남겼다. 커뮤니티 게시글 제목 번역에서는 이런 은어 처리 차이가 꽤 체감된다.
GLM이 더 나았던 항목도 있었다
일본어 戒名은 Gemma와 MLX 일부가 “계명”으로 옮겼지만, GLM 일부는 “법명”이라고 했다. 사찰 맥락에서는 “법명”이 더 자연스럽다. 중국어 兄弟们도 Gemma의 “여러분”보다 GLM의 “형들” 쪽이 원문 커뮤니티 말투에 더 가까운 경우가 있었다.
Mac Studio에서는 무엇이 실용적인가
Mac Studio 512GB만 놓고 보면 결론은 조금 갈린다.
속도와 용량만 보면 GGUF UD-IQ2_M Metal이 꽤 매력적이다. 222G 정도로 MLX 계열보다 훨씬 작고, 이번 제목 번역 벤치에서는 30개를 87.62초에 끝냈다. UD-IQ1_M도 비슷하게 빨랐지만, 출력 결함 때문에 신뢰하기 어렵다.
반대로 품질 안정성을 조금 더 본다면 MLX 4bit나 mxfp4 쪽이 낫다. 다만 OpenAI-compatible server로 돌린 이번 벤치에서는 MLX 계열이 GGUF Metal보다 느렸다. DQ4plus-q8은 가장 크고 가장 느렸고, 이번 작업에서는 그 비용을 정당화할 만큼 품질 차이가 뚜렷하지 않았다.
정리하면 내 기준은 이렇다.
| 목적 | 후보 |
|---|---|
| Mac Studio에서 작고 빠르게 GLM-5.2 맛보기 | GGUF UD-IQ2_M Metal |
| Mac Studio에서 GLM 품질/안정성 위주 | MLX 4bit 또는 mxfp4 |
| 1-bit 극한 압축 실험 | GGUF UD-IQ1_M, 단 실사용 신뢰도 낮음 |
| 무거운 고품질 후보 실험 | MLX DQ4plus-q8, 이번 벤치에서는 이점 작음 |
결론
이번 실험으로 확인한 것은 다음이다.
- Mac Studio 512GB에서는 GLM-5.2 MLX 4bit 계열과 GGUF 1/2-bit 계열을 실제로 실행할 수 있다.
- Mac Studio의 GGUF
UD-IQ2_MMetal은 용량과 속도 면에서 꽤 매력적이다. UD-IQ1_M은 빠르지만 출력 결함이 보여 실사용 후보로 보기 어렵다.- MLX
4bit와mxfp4는 품질 안정성 후보지만, 이번 OpenAI-compatible server 제목 벤치에서는 GGUF Metal보다 느렸다. - DGX Spark 두 대의 GLM-5.2
UD-IQ2_M65K context 실행은 가능했고, 긴 컨텍스트 실험 가치가 있다. - 하지만 짧은 RSS/커뮤니티 제목 번역 실사용에서는 Gemma4 31B Dense Q8 + MTP가 가장 빠르고 품질도 가장 안정적이었다.
그래서 이 실험의 결론은 “GLM-5.2가 안 된다”가 아니다. 오히려 Mac Studio와 DGX Spark 조합으로 이런 급의 모델을 실제로 여러 방식으로 돌려볼 수 있다는 점은 꽤 재미있었다. 다만 지금 당장 RSS/커뮤니티 제목 번역 같은 실사용 작업에 넣는다면, 나는 GLM-5.2보다 Gemma4 31B Dense MTP를 먼저 고를 것 같다. GLM-5.2는 짧은 번역보다 긴 컨텍스트와 거대 모델을 직접 다뤄보는 실험 쪽에서 더 의미가 있었다.
Fri, 26 Jun 2026 00:30:00 +0900