GLM-5.2를 DGX Spark 두 대로 돌려보기

DGX Spark 두 대를 QSFP/CX7 케이블로 직결한 뒤, Unsloth의 GLM-5.2-GGUF를 llama.cpp RPC로 돌려봤다. 목표는 단순했다. 1-bit와 2-bit 양자화 모델이 실제로 로드되는지, 속도는 어느 정도인지, 품질은 쓸 만한지, 긴 컨텍스트는 어디까지 버티는지 확인하는 것이었다.

며칠 동안 실제 장비에서 삽질하면서 확인한 운영 기록에 가깝다. 특히 1-bit는 벤치마크 숫자만 보면 그럴듯하지만 실제 응답 품질에서는 제대로 답하지 못했고, 2-bit는 생각보다 긴 컨텍스트까지 버텼다.

실험 환경

• 장비: DGX Spark 두 대. 이 글에서는 호스트 이름을 각각 spark, spark2라고 부른다.
• 연결: QSFP/CX7 직결망
• RPC 주소: spark2의 10.222.0.2:50052
• 런타임: llama.cpp CUDA + RPC
• 모델: Unsloth GLM-5.2-GGUF
• 비교 대상: UD-IQ1_M(1-bit 양자화), UD-IQ2_M(2-bit 양자화)

두 Spark를 케이블로 연결한다고 자동으로 한 대처럼 합쳐지는 것은 아니다. OS, 프로세스, 메모리, GPU는 여전히 따로 있다. 이번 실험에서는 spark에서 llama.cpp를 실행하고, spark2에는 llama.cpp rpc-server를 띄워서 두 노드를 함께 사용했다.

QSFP/CX7 링크는 200GbE로 올라왔고, RDMA smoke test도 통과했다. llama.cpp 벤치 로그에서도 RDMA activated가 찍혔다.

다운로드와 빌드

모델	총 크기
UD-IQ1_M	약 213G
UD-IQ2_M	약 223G

다운로드 시간은 로그 기준으로 UD-IQ1_M이 02:24:45부터 04:23:05까지 약 1시간 58분, UD-IQ2_M이 04:41:49부터 09:29:52까지 약 4시간 48분 걸렸다.

llama.cpp는 CUDA와 RPC를 켜서 빌드했다.

cmake -B build \
  -DBUILD_SHARED_LIBS=OFF \
  -DGGML_CUDA=ON \
  -DGGML_RPC=ON \
  -DCMAKE_CUDA_COMPILER=/usr/local/cuda/bin/nvcc \
  -DCMAKE_CUDA_ARCHITECTURES=native
cmake --build build --config Release -j$(nproc) --target llama-cli llama-server llama-bench rpc-server

llama-bench, llama-server, rpc-server가 필요했다. 처음에는 기존 Docker 이미지에 필요한 바이너리가 다 있을 것이라 생각했지만, 실제로는 직접 빌드하는 편이 빠르고 확실했다.

속도 벤치마크

먼저 아주 짧은 llama-bench를 돌렸다.

llama-bench \
  -m <first-shard.gguf> \
  -rpc 10.222.0.2:50052 \
  -ngl 999 \
  -sm layer \
  -p 64 \
  -n 32 \
  -r 1

결과는 다음과 같았다.

항목	1-bit UD-IQ1_M	2-bit UD-IQ2_M
model size	212.79 GiB	222.18 GiB
bpw 🛈bits per weight. weight 하나를 평균 몇 비트로 저장하는지 나타내는 양자화 밀도.	1.75	2.7
params	753.86B	753.86B
backend	CUDA,RPC	CUDA,RPC
RDMA	activated	activated
pp64 🛈prompt processing 64. 64토큰 프롬프트를 처리하는 prefill 속도.	130.96 tok/s	56.46 tok/s
tg32 🛈token generation 32. 새 토큰 32개를 생성하는 decode 속도.	8.22 tok/s	7.99 tok/s
wall time 🛈명령 전체가 끝나기까지 걸린 실제 경과 시간.	14:28.14	14:24.53
max RSS 🛈Maximum Resident Set Size. 프로세스가 사용한 최대 상주 메모리.	약 120GB	약 120GB
swap 🛈실행 중 swap 사용 횟수. 0이면 swap 없이 끝났다는 뜻.	0	0

표 읽는 법: 표의 🛈에 마우스를 올리면 각 항목의 뜻을 바로 볼 수 있다.

1-bit는 prompt processing, 즉 prefill이 훨씬 빨랐다. 반면 generation 속도는 거의 비슷했다. 이 숫자만 보면 1-bit도 꽤 쓸 수 있을 것처럼 보인다. 하지만 실제 응답 품질을 보니 이야기가 달라졌다.

품질 테스트: 1-bit는 제대로 답하지 못했다

처음에는 한국어, 중국어, 영어 번역으로 품질을 보려고 했다. 그런데 1-bit는 번역뿐 아니라 아주 간단한 지시에서도 ?를 반복했다.

테스트한 요청은 이런 것들이었다.

Reply exactly: OK
Say hello in Korean.
다음 단어를 그대로 출력: 테스트
What color is the sky on a clear day?
고양이를 영어로 뭐라고 해? 한 단어로만 답해.

결과는 모두 이런 식이었다.

???????????????????????????????????????????????????????????????????????????????

처음에는 raw completion이나 chat template 문제일 수 있다고 생각했다. 그래서 llama-cli, llama-completion, llama-server의 OpenAI 호환 /v1/chat/completions까지 바꿔가며 확인했다. 2-bit는 llama-server chat endpoint에서 정상 번역을 했지만, 1-bit는 같은 방식에서도 ? 반복이 나왔다.

따라서 이번 환경에서는 UD-IQ1_M을 실사용 후보로 보기 어렵다. 로딩과 벤치는 되지만 instruction output이 제대로 나오지 않는다.

2-bit는 번역이 됐다

2-bit는 llama-server와 /v1/chat/completions 조합에서 정상적으로 답했다. 예를 들어 다음 두 문장 번역을 시켰다.

1. Korean to English:
DGX Spark 두 대를 QSFP 케이블로 직결했지만, 자동으로 한 대처럼 합쳐지는 것은 아니다.

2. English to Korean:
The download resumed from the previous byte offset and completed without using swap.

2-bit 출력은 다음과 같았다.

1. Two DGX Spark units were directly connected with a QSFP cable, but they do not automatically combine as one.
2. 다운로드는 이전 바이트 오프셋에서 재개되었으며, 스왑을 사용하지 않고 완료되었다.

완벽한 번역 평가 벤치라고 할 수는 없지만, 최소한 기술 용어와 의미는 잘 보존했다. 이 지점에서 1-bit와 2-bit의 차이는 꽤 분명했다.

RSS/커뮤니티 제목 번역 벤치마크

짧은 예문 번역만으로는 실사용 품질을 판단하기 어렵다. 그래서 평소 모델 번역 비교에 쓰던 RSS/커뮤니티 게시글 제목 30개를 다시 사용했다. 일본어 10개, 영어 10개, 중국어 10개로 구성했고, 기술 뉴스와 커뮤니티 게시글 제목을 한국어 한 줄 제목으로 번역하게 했다.

비교 대상은 다음 두 가지였다.

모델	실행 설정
GLM-5.2 UD-IQ2_M	llama.cpp CUDA/RPC, -c 65536, --reasoning off, --reasoning-budget 0
Gemma4 31B Dense Q8	llama.cpp CUDA, MTP drafter 사용, --reasoning off, --reasoning-budget 0

처음 Gemma4 31B Dense MTP를 그냥 띄웠을 때는 content가 비고 reasoning_content만 길게 나오는 문제가 있었다. 그래서 GLM과 마찬가지로 reasoning을 꺼서 다시 실행했다. 또한 제목 번역 벤치이므로 출력은 max_tokens=128로 제한했다.

속도는 Gemma4 31B Dense MTP가 확실히 빨랐다.

모델	총 시간	평균 시간/제목	median	평균 생성 속도	비고
GLM-5.2 2-bit	135.70s	4.52s	3.83s	8.58 tok/s	30개 모두 정상 종료
Gemma4 31B Dense MTP	50.24s	1.67s	1.40s	20.54 tok/s	MTP draft accept 58.2%

품질 비교는 GPT-5.5 judge로 수행했다. 동급이면 동점으로 두고, 지명/고유명사 오류와 의미 왜곡은 크게 감점했다. 결과는 다음과 같았다.

언어	GLM-5.2 2-bit	Gemma4 31B Dense MTP	동점
일본어 10개	3.0	7.0	4
영어 10개	5.0	5.0	8
중국어 10개	3.5	6.5	3
전체	11.5	18.5	15

예를 들어 일본어 阿波銀行은 아와은행으로 옮겨야 하는데 GLM은 아보은행이라고 했다. 이런 고유명사 오류는 작지 않다. 반대로 戒名 같은 항목에서는 GLM의 법명이 Gemma의 계명보다 문맥상 나았다. 중국어에서는 yyds를 GLM이 그대로 남긴 반면, Gemma는 “진짜 최고입니다”로 풀어내는 등 커뮤니티 표현 처리에서 더 나았다.

이 제목 번역 벤치에서는 Gemma4 31B Dense MTP가 GLM-5.2 2-bit보다 낫다. GLM은 거대한 753B 모델을 2-bit로 압축해 긴 컨텍스트까지 다룰 수 있다는 점이 흥미롭지만, 짧은 RSS/커뮤니티 제목 번역에서는 31B Dense MTP 쪽이 더 빠르고 더 안정적이었다.

긴 컨텍스트 테스트

다음은 2-bit만 가지고 긴 컨텍스트 QA를 했다. 긴 filler context 안에 핵심 사실 네 개를 넣고, 나중에 정확히 회수하는지 확인했다.

질문은 항상 비슷했다.

1. RPC 주소는 무엇인가?
2. 2-bit 모델 품질에 대한 핵심 관찰은 무엇인가?
3. benchmark는 어떤 방식으로 실행되었고 swap은 사용했는가?
4. 1-bit와 2-bit 생성 속도 수치를 그대로 적어라.

정답에는 다음 값들이 포함되어야 했다.

10.222.0.2:50052
2-bit UD-IQ2_M 모델은 1-bit보다 안정적
llama.cpp RPC, RDMA activated, swap 없음
1-bit 8.22 tok/s, 2-bit 7.99 tok/s

8K, 16K, 32K ctx

ctx	성공한 입력	실패한 입력
8K	12K chars	24K chars, 약 11.3K tokens로 context 초과
16K	24K chars	미확인
32K	72K chars	96K chars, 약 37.8K tokens로 context 초과

성공한 케이스는 모두 5/5로 핵심 사실을 회수했다.

65K ctx, cache off

더 현실적인 속도를 보려고 prompt cache를 껐다.

--cache-ram 0
--no-cache-prompt
--no-cache-idle-slots
--cache-reuse 0

입력	실제 prompt tokens	결과	wall time
24K chars	12.7K tokens	성공	89.5s
48K chars	25.1K tokens	성공	241.7s
72K chars	35.9K tokens	성공	513.3s
96K chars	48.6K tokens	성공	765.8s
128K chars	65.9K tokens	context 초과	-

96K chars, 약 48.6K tokens까지는 품질 5/5로 성공했다.

131K ctx, -np 1, cache off

다음은 context를 131K로 올리고 parallel slot을 하나로 줄였다.

-c 131072
-np 1

입력	실제 prompt tokens	결과	wall time
128K chars	68.4K tokens	성공	746.9s
160K chars	84.1K tokens	성공	1033.4s

160K chars, 약 84K tokens에서도 5/5로 핵심 사실을 회수했다. 다만 prefill에 17분 넘게 걸렸다. 이 정도부터는 “가능하다”와 “쾌적하다”를 분리해서 봐야 한다.

262K ctx는 어디까지 갔나

욕심을 내서 -c 262144도 시도했다.

기본 KV cache에서는 서버가 뜨기 전에 OOM이 났다.

failed to allocate buffer for kv cache

KV cache를 q8로 줄이면 서버는 뜨게 만들 수 있었다.

-ctk q8_0
-ctv q8_0
-b 512
-ub 128
-fa on

하지만 200K chars 요청에서 prefill 속도가 1 tok/s도 나오지 않았다.

25 tokens     259.43s   0.10 tok/s
537 tokens   1056.14s  0.51 tok/s
1049 tokens  1809.72s  0.58 tok/s
3097 tokens  4313.34s  0.72 tok/s

결국 timeout으로 실패했다. 262K ctx는 “서버를 띄워볼 수는 있다”와 “실제로 쓸 수 있다” 사이의 차이를 잘 보여줬다.

`-c`를 명시해야 하는 이유

GLM-5.2 로그에는 n_ctx_train = 1048576이 나온다. 모델 메타데이터상 훈련 컨텍스트는 1M tokens다. 그래서 -c를 생략하고 자동에 맡기면 너무 큰 context를 잡으려 하거나, 자동 fit이 예상과 다르게 동작할 수 있다.

-c는 단순히 “긴 입력을 허용할지 말지”만 정하는 옵션이 아니다. KV cache 크기와 compute buffer, 서버 시작 안정성에도 영향을 준다.

이번 실험에서는 다음 정도가 현실적인 선택으로 보였다.

짧은 요청/번역/일반 QA: -c 65536
긴 문서 QA까지 열어두기: -c 131072 -np 1
262K ctx: 비추천

추천 실행 형태

2-bit를 실사용 후보로 띄운다면 나는 우선 이렇게 둘 것 같다.

llama-server \
  -m ~/models/unsloth/GLM-5.2-GGUF/UD-IQ2_M/GLM-5.2-UD-IQ2_M-00001-of-00006.gguf \
  --rpc 10.222.0.2:50052 \
  -ngl 999 \
  -sm layer \
  -c 131072 \
  -np 1 \
  --jinja \
  --reasoning off \
  --reasoning-budget 0

짧은 요청 위주라면 -c 65536이 더 가볍다. 131K는 긴 문서를 넣을 수 있게 열어두는 설정이고, 긴 입력이 들어오면 prefill 시간이 길어지는 것을 감수해야 한다.

남는 의문

이번 결과를 그대로 받아들이기에는 아직 찜찜한 부분도 있다.

첫째, 1-bit에서 ?만 반복해서 나온 것이 정말 모델 자체의 한계인지 확신하기 어렵다. 다른 사람들은 같은 양자화 모델을 정상적으로 돌렸을 가능성이 크고, 내가 llama.cpp 옵션이나 chat template, reasoning 설정, tokenizer/EOG 처리 중 무언가를 놓쳤을 수도 있다. 다만 이 실험에서 확인한 범위에서는 llama-cli, llama-completion, llama-server의 OpenAI 호환 chat endpoint까지 바꿔도 결과가 같았다.

둘째, 2-bit 품질을 어떻게 봐야 할지도 애매하다. 긴 컨텍스트 QA는 꽤 잘 됐지만, 짧은 RSS/커뮤니티 제목 번역에서는 Gemma4 31B Dense MTP보다 부족했다. 이게 2-bit 저비트 양자화 때문에 생긴 품질 저하인지, GLM-5.2 자체가 해당 작업에 덜 맞는 것인지, 혹은 실행 설정의 문제인지는 여기서 단정하기 어렵다.

그래서 이 글의 결론은 “GLM-5.2가 안 된다”가 아니다. 이 환경과 설정에서는 실행은 됐지만, 내가 당장 계속 쓰고 싶은 정도의 품질과 속도는 아니었다는 쪽에 가깝다.

정리

이번 실험으로 확인한 것은 다음 정도다.

1. DGX Spark 두 대를 QSFP/CX7로 묶고 llama.cpp RPC를 쓰면 GLM-5.2 753B GGUF를 실제로 로드하고 실행해볼 수 있다.
2. 1-bit UD-IQ1_M은 응답이 의미 없는 ? 반복뿐이었다. 이 결과만으로도 실사용 후보로 볼 수 없고, 속도 숫자도 의미가 없다.
3. 2-bit UD-IQ2_M은 짧은 번역과 긴 컨텍스트 QA에서 정상 동작했고, 84K tokens 컨텍스트 QA까지 성공했다.
4. 다만 RSS/커뮤니티 제목 번역 벤치에서는 Gemma4 31B Dense MTP가 GLM-5.2 2-bit보다 더 빠르고 품질도 좋았다.
5. 262K ctx는 메모리와 속도 면에서 실사용 불가였다.

내 결론은 간단하다.

DGX Spark 두 대에서 GLM-5.2를 실제로 실행해봤다는 점은 의미가 있었다. 하지만 1-bit는 의미 있는 출력을 만들지 못했고, 2-bit도 실행은 되지만 짧은 번역 품질과 속도에서는 Gemma4 31B Dense MTP보다 부족했다. 그래서 이 환경에서 GLM-5.2를 굳이 계속 사용할 것 같지는 않다.

Thu, 25 Jun 2026 23:10:00 +0900