Zhipu가 GLM 5.2 가중치(weights)를 MIT 라이선스로 HuggingFace에 공개함에 따라, 질문은 "프런티어 코딩 모델을 다운로드할 수 있는가"에서 "내가 이미 보유한 기기에서 실행할 수 있는가"로 바뀌었습니다. 단일 Mac Studio나 하나의 GPU와 많은 RAM을 갖춘 데스크톱의 경우, 답변은 '조건부 예'입니다. 그 조건은 바로 양자화(quant)입니다.

로컬에서 실행 가능한 것 (그리고 불가능한 것)

이 가이드는 양자화된 GGUF 가중치와 llama.cpp, LM Studio 또는 Unsloth Studio를 사용하여 사용자가 소유한 단일 기기에서 GLM 5.2를 실행하는 방법에 관한 것입니다. 이는 GLM 5.2 셀프 호스팅 하드웨어 및 비용 가이드에서 다루는 H200 랙을 통해 팀에게 서비스를 제공하는 작업과는 다르며, GLM 5.2 액세스 가이드에서 다루는 호스팅된 API를 호출하는 작업과는 또 다른 작업입니다.

GLM 5.2는 MIT 라이선스로 출시된 1M 토큰 컨텍스트(context)를 가진 753B 파라미터 모델입니다. 전체 BF16 정밀도(precision)에서 가중치는 약 1.5 TB이며, 이는 어떤 단일 데스크톱에도 들어가지 않습니다. 로컬 추론(inference)은 양자화(quantizing)를 의미합니다. 즉, RAM에 들어갈 수 있는 크기를 확보하기 위해 품질의 일부를 희생하는 것입니다. 어디에 무엇이 들어가는지에 대한 30초 요약입니다.

솔직한 헤드라인을 말씀드리자면, 2-bit 양자화를 실행하는 256 GB Mac Studio가 현실적인 "내 책상 위의 GLM 5.2" 설정입니다. 4-bit 양자화는 품질의 최적 지점(sweet spot)이지만, 512 GB 사양의 기기나 대규모 오프로드(offload)를 필요로 합니다. 256 GB보다 작은 사양은 로컬 작업이 아닌 호스팅된 API를 사용해야 하는 영역입니다.

결정 프레임워크: 로컬 GLM 5.2가 가치 있는 경우 (그리고 그렇지 않은 경우)

올바른 이유로 양자화 모델을 로컬에서 실행하십시오. 잘못된 이유는 비용 절감입니다. 거의 모든 사람에게는 호스팅된 플랜이 더 저렴하기 때문입니다.

로컬에서 실행해야 하는 경우

• 오프라인 또는 에어갭 (air-gapped) 작업. api.z.ai로의 외부 트래픽이 허용되지 않으므로, 모델이 반드시 사용자의 하드웨어에 존재해야 합니다.
• 단일 기기에서의 프라이버시. 프롬프트와 코드가 기기를 절대 벗어나지 않으며, Mac Studio 한 대가 전체 보안 경계가 됩니다.
• 이미 하드웨어를 보유 중인 경우. 영상 편집이나 머신러닝 (ML) 작업을 위해 구매한 256GB 또는 512GB Mac Studio가 밤에 유휴 상태로 있다면, 로컬 양자화 (quant) 모델을 실행하는 데 추가 비용이 들지 않습니다.
• 실험 및 학습. 753B MoE (Mixture of Experts)가 어떻게 작동하는지 체감하고 싶거나, 샘플링 (sampling) 설정을 테스트하고 싶을 때, 또는 속도 제한 (rate limits) 없이 로컬 OpenAI 호환 엔드포인트를 대상으로 구축하고 싶을 때 적합합니다.

로컬에서 실행하지 말아야 할 경우

• 저렴하고 빠른 속도를 원하는 경우. Z.ai 코딩 플랜 (Coding Plan)은 월 약 $30이며 전체 속도로 실행됩니다. 3~9 tok/s 속도의 2-bit 로컬 양자화 모델은 전기 요금만 고려하더라도 그 가격 대비 성능을 따라갈 수 없습니다. 액세스 가이드를 읽어보세요.
• 한 명 이상의 사용자에게 서비스해야 하는 경우. 단일 Mac Studio는 단일 세션용 기기입니다. 두 명의 개발자가 동시에 몰아치면 각자 매우 느린 속도를 느끼게 될 것입니다. 이 경우에는 데이터센터 (datacenter) 경로를 선택해야 합니다.
• 기기 메모리가 256GB 미만인 경우. GLM 5.2를 사용할 만한 품질로 128GB 기기에 맞출 수 있는 양자화 (quant) 방식은 없습니다. 시도하느라 주말을 허비하지 마세요.
• 1M 전체 컨텍스트 (context)가 필요한 경우. 긴 컨텍스트 KV 캐시 (KV cache)는 소비자용 하드웨어에 들어가지 않습니다. 로컬에서는 실제적으로 약 16K~64K 정도가 한계입니다.

중단 규칙 (Stop rule)

통합 메모리 (unified memory) 또는 시스템 RAM이 최소 256GB 이상 확보되지 않았다면, 여기서 멈추고 호스팅 플랜을 사용하십시오. 어떤 양자화 (quantization)를 적용하더라도 이 최소 요구 사양은 변하지 않습니다.

시스템 요구 사항 (System Requirements)

flowchart TD
  A[메모리가 얼마나 필요한가?] -->|512 GB Mac| B[4-bit UD-Q4_K_XL<br/>최상의 로컬 품질]
  A -->|256 GB Mac 또는 DDR5| C[2-bit UD-IQ2_M<br/>일반적인 구성]
...

240GB의 가중치 (weights)를 불러오기 전에, 다음 사항을 확인하십시오:

240GB의 가중치(weights)를 불러오기 전에, 다음 사항을 확인하십시오:

• 메모리 (Memory). 최소 256 GB가 필요합니다 (Apple silicon의 통합 메모리 또는 CUDA 장치의 시스템 DDR5).
  2-bit 양자화(quant)는 약 240 GB이므로, 256 GB 장치에서는 여유 공간이 매우 부족합니다. 다른 앱을 종료하고 macOS에 필요한 통합 메모리를 남겨두지 않으면 스왑(swap)이 발생할 수 있습니다. 4-bit를 편안하게 실행하려면 512 GB가 필요합니다.
• 디스크 (Disk). 양자화된 파일 크기 및 여유 공간: 2-bit의 경우 약 240 GB, 4-bit의 경우 약 376~475 GB의 여유 공간이 필요합니다. 회전식 디스크(spinning disk)가 아닌 SSD를 사용해야 로딩 시간이 원활합니다.
• 실행 환경 (A runner). 최신 커밋으로 빌드된 llama.cpp, LM Studio 또는 Unsloth Studio를 사용하십시오. 아키텍처(GLM MoE DSA)가 비교적 새롭기 때문에 오래된 llama.cpp 빌드는 텐서(tensors) 로드를 실패할 수 있습니다.
• 올바른 저장소 (The right repo). 커뮤니티 GGUF 양자화 파일은 huggingface.co/unsloth/GLM-5.2-GGUF에 있습니다. 공식 zai-org/GLM-5.2 저장소는 BF16 전용이며 로컬 추론(local inference)을 위해 원하는 것이 아닙니다.

단계별 가이드: GLM 5.2를 로컬에서 실행하기

1단계: GGUF 양자화 파일 가져오기 (Pull a GGUF quant)

전체 저장소를 다운로드하지 말고 필요한 양자화 파일만 다운로드하십시오. --include 필터를 사용하면 사용하지 않을 750 GB의 샤드(shards)를 가져오는 것을 방지할 수 있습니다.

# 2-bit (256 GB 장치용, 디스크에서 약 240 GB)
hf download unsloth/GLM-5.2-GGUF \
  --local-dir ~/models/glm-5.2-gguf \
...

~/models/glm-5.2-gguf 폴더에 GLM-5.2-UD-IQ2_M-0000X-of-0000Y.gguf 형태의 샤드 세트가 생성되어야 합니다. 512 GB 장치를 사용하는 경우 필터를 *UD-Q4_K_XL*로 변경하십시오. Unsloth는 동적 양자화(dynamic quants)를 개선함에 따라 양자화 레이블을 수정하므로, 정확한 샤드 이름은 HuggingFace의 실시간

• --ctx-size 32768는 32K 컨텍스트 창 (window)을 설정합니다. 이 값을 높이면 256GB 머신에서도 메모리를 빠르게 소모하므로, 이 값에서 시작하여 요청이 필요한 경우에만 늘리십시오.
• --n-gpu-layers 999는 가능한 모든 레이어 (layer)를 GPU로 오프로딩 (offload) 합니다. Mac에서는 통합 메모리 (unified memory) 덕분에 이 작업이 거의 비용 없이 이루어지며, 4090에서는 24GB에 들어가는 부분만큼 오프로딩하고 나머지는 CPU에 남겨둡니다.
• --temp 1.0 --top-p 0.95 --min-p 0.01은 Zhipu가 권장하는 샘플링 (sampling) 기본값입니다. 이 설정이 잘못되면 "로컬 모델이 호스팅된 모델보다 멍청하다"는 현상이 발생하는 가장 흔한 원인이 됩니다.

모델이 로드되면, llama-server가 레이어 개수를 기록한 후 server listening on http://0.0.0.0:8080을 출력합니다. SSD에서 처음 로드하는 데는 1~2분 정도 소요됩니다.

Step 3: 또는 GUI 사용하기 (LM Studio / Unsloth Studio)

빌드 툴체인 (build toolchain)을 직접 다루고 싶지 않다면, 동일한 GGUF 양자화 (quants) 모델을 로드하는 두 가지 GUI 앱이 있습니다.

LM Studio는 데스크톱 앱에서 동일한 GGUF 양자화 모델을 실행합니다. 앱 내 모델 브라우저에서 unsloth/GLM-5.2-GGUF를 검색하고, 2-bit 또는 4-bit 양자화 버전을 선택하면 다운로드와 서빙 (serving)을 처리하며, 로컬 포트에 동일한 OpenAI 호환 엔드포인트 (endpoint)를 노출합니다.

Unsloth Studio는 자동 메모리 오프로딩 (automatic memory offloading) 기능이 있는 웹 UI로, 한 줄의 명령어로 설치할 수 있습니다.

curl -fsSL https://unsloth.ai/install.sh | sh
unsloth studio -H 0.0.0.0 -p 8888

매번 긴 llama.cpp 명령어를 다시 입력하지 않고 양자화 설정과 파라미터를 교체하고 싶다면 두 방식 모두 더 나은 선택입니다.

Step 4: 스모크 테스트 (Smoke test)

어떤 OpenAI 클라이언트든 로컬 포트로 연결하여 응답이 오는지 확인하십시오.

curl -s http://localhost:8080/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
...

잠시 기다린 후 OK 응답을 받아야 합니다. 만약 응답이 깨지거나 루프 (loop)가 발생한다면 샘플링 파라미터 (sampling params)가 잘못된 것이므로, --temp 1.0 --top-p 0.95 --min-p 0.01 값을 huggingface.co/zai-org/GLM-5.2/generation_config.json에 있는 값과 대조하여 다시 확인하십시오.

실제 초당 토큰 수 (Real Tokens/sec): 티어별 기대 성능

로컬 하드웨어에서의 생성 속도(Generation speed)는 연산 능력(raw compute)이 아니라 메모리 대역폭(memory bandwidth)에 의해 제한됩니다. 이것이 바로 800 GB/s의 통합 메모리(unified memory)를 가진 Mac Studio가 80-100 GB/s에 가까운 RAM 속도를 가진 DDR5 데스크톱보다 뛰어난 이유입니다. 다음 수치들을 바탕으로 계획을 세우십시오.

패턴: 로컬 GLM 5.2는 단일 스트림(single-stream), 단일 개발자용 도구입니다. 속도는 하나의 코딩 에이전트가 작업을 생각하며 진행하기에는 괜찮은 수준입니다. 하지만 공유 엔드포인트(shared endpoint)로 사용하기에는 적합하지 않으며, 어떤 소비자용 양자화(consumer quant)로도 이를 바꿀 수는 없습니다. 팀을 위한 처리량(throughput)이 필요하다면, 자체 호스팅 하드웨어 가이드에서 데이터센터 GPU를 활용한 vLLM 및 SGLang 경로를 확인하십시오.

로컬 설정 중 발생하는 일반적인 오류 (및 해결 방법)

팀 / 다중 개발자: Mac 한 대로 부족할 때

단일 로컬 머신은 한 사람에게만 서비스를 제공합니다. 두 번째 개발자가 동일한 llama-server에 에이전트를 연결하는 순간, 두 세션 모두 속도가 매우 느려집니다. 소비자용 하드웨어에는 대역폭을 나누어 쓸 여유가 없기 때문입니다. 이를 해결할 수 있는 영리한 플래그(flag) 같은 것은 존재하지 않습니다.

로컬 확장이 한계에 다다랐을 때의 두 가지 실제 선택지:

1. 데이터센터 GPU로 이동하십시오. FP8을 서비스하는 8x H200 노드는 각 스트림당 수십 개의 토큰 속도로 많은 동시 스트림을 처리할 수 있습니다. 이는 비용과 운영 측면에서 완전히 다른 이야기이며, 호스팅 플랜 대비 손익분기점 계산을 포함하여 vLLM 및 비용 자체 호스팅 가이드에서 자세히 다루고 있습니다.
2. 호스팅된 엔드포인트를 사용하고 로컬 실행을 중단하십시오. 대부분의 팀에게 데이터 거주성(data residency) 문제를 제외하면 이 방식이 모든 측면에서 승리합니다.

로컬 양자화 (local quant) 모델은 자신의 머신에 모델을 두고자 하는 개별 개발자에게는 적합한 도구입니다. 하지만 공유 서비스(shared service)를 구축하기에는 적합하지 않은 도구입니다.

고급: 긴 컨텍스트 (Long Context) 및 사고 모드 (Thinking Mode)

기본 설정이 완료되었다면 알아두어야 할 두 가지 조절 요소가 있습니다.

KV 캐시 양자화 (KV cache quantization). 아키텍처상 1M 컨텍스트는 실재하지만, 256GB 사양의 시스템에서는 도달할 수 없습니다. KV 캐시만으로도 수백 기가바이트가 필요하기 때문입니다. 양자화를 통해 공간을 확보할 수 있습니다:

./build/bin/llama-server \
  --model ~/models/glm-5.2-gguf/GLM-5.2-UD-IQ2_M-00001-of-00006.gguf \
  --ctx-size 65536 \
...

이 방식은 KV 캐시 메모리를 대략 절반으로 줄여주어, 매우 긴 입력값에 대해 약간의 품질 저하를 감수하는 대신 동일한 하드웨어에서 컨텍스트를 더 확장할 수 있게 해줍니다.

사고 모드 (Thinking mode). GLM 5.2에는 답변하기 전에 토큰을 사용하여 생각하는 추론 모드 (reasoning mode)가 있습니다. 빠른 편집이나 짧은 프롬프트의 경우 원치 않는 지연 시간 (latency)을 추가할 수 있습니다. --chat-template-kwargs '{"enable_thinking":false}'를 사용하여 요청별로 이를 끌 수 있으며, 추가적인 추론이 가치를 발휘하는 복잡한 다단계 문제의 경우에는 이를 켜두십시오.

로컬이 정답이 아닌 경우: 호스팅 및 ofox 대안

256GB라는 최소 사양이나 단일 세션 속도 문제로 인해 로컬 실행이 불가능하다면, GLM 5.2를 완전히 포기할 필요는 없습니다. 동일한 모델이 ofox 카탈로그의 z-ai/glm-5.2에 등록되어 있으며, 가격은 입력 1M당 $1.40, 출력 1M당 $4.40입니다. 따라서 베이스 URL (base URL)과 모델 ID (model ID)만 변경하면 별도의 장비를 구매하거나 관리할 필요 없이 호스팅된 상태로 전체 속도로 실행할 수 있습니다. 로컬 llama-server로 프로토타입을 만든 다음, 동일한 클라이언트를 호스팅된 모델로 연결하면 됩니다:

export OPENAI_BASE_URL="https://api.ofox.ai/v1"
export OPENAI_API_KEY="ofox-..."
export OPENAI_MODEL="z-ai/glm-5.2"   # 동일한 모델이며, 이제 호스팅됨

호스팅 액세스 가이드에서는 동일한 모델에 접근할 수 있는 Z.ai Coding Plan 경로도 다룹니다. 또한, 해당 OpenAI 호환 엔드포인트(endpoint)를 통해 다른 오픈 웨이트 (open-weights) 코딩 모델들을 사용하고 싶다면, ofox는 이 모델들도 출시 당일에 목록에 포함했습니다:

로컬 장비(local rig)를 구축하거나 호스팅 구독(hosted subscription)을 결정하기 전에, GLM과 폐쇄형 모델(closed model) 간의 가격 대비 품질을 확인하려면 GLM 5.2 vs GPT-5.5 비용 비교를 참조하세요.

이번 업데이트를 위해 확인된 출처 (Sources Checked for This Refresh)