GLM-5.2 셀프호스팅 실전 가이드: MIT 라이선스로 프런티어급 코딩모델 직접 돌리기

"MIT 라이선스니까 그냥 다운받아서 돌리면 되지 않나" 싶겠지만, 753B 파라미터 모델을 실제로 띄우려면 최소 8장짜리 GPU 클러스터부터 필요합니다. 이번 글은 GLM-5.2를 실제로 자기 인프라에 올리려는 사람을 위해, 하드웨어 산정부터 프레임워크 선택, 실제 서빙 명령까지 순서대로 정리했습니다.

 

GLM-5.2는 6월 13일 Zhipu AI(Z.ai)가 공개한 753B 파라미터 MoE 모델로, 활성 파라미터는 약 40B입니다. 가중치는 Hugging Face의 zai-org/GLM-5.2 저장소에 MIT 라이선스로 지역 제한 없이 공개돼 있어서, 다운로드·수정·재배포·상업적 이용까지 자유롭게 허용됩니다. 다만 한 가지 헷갈리기 쉬운 부분이 있는데, GitHub의 추론 코드 저장소는 Apache 2.0이고 Hugging Face에 올라온 가중치 파일 자체만 별도로 MIT 라이선스가 적용된다는 점입니다.

 

셀프호스팅 권리는 가중치에 붙어 있는 라이선스이지 코드 저장소 라이선스가 아니라는 걸 헷갈리지 말아야 합니다. 컨텍스트 윈도우는 1M 토큰이고, IndexShare라는 희소 어텐션 기법으로 128K~1M 구간에서 어텐션 연산량을 약 98% 줄였다는 게 Zhipu의 설명입니다. 지원 프레임워크는 vLLM, SGLang, Transformers, KTransformers, Unsloth로 다양하고, 양자화 버전도 32종이 공개돼 있어 llama.cpp·LM Studio·Jan·Ollama 같은 경량 런타임에서도 돌릴 수 있습니다.

실전 1: 하드웨어부터 산정하기 — FP8이냐 4비트냐

셀프호스팅에서 가장 먼저 넘어야 할 벽은 코드가 아니라 GPU 메모리입니다. GLM-5.2는 MoE(Mixture-of-Experts) 구조라 추론 시 실제로 계산에 관여하는 파라미터는 약 40B뿐이지만, 이건 연산량 이야기고 메모리 이야기는 다릅니다. 어떤 토큰이 어떤 전문가로 라우팅될지 매 순간 달라지기 때문에, 753B 파라미터 전체가 항상 GPU 메모리 어딘가에 올라와 있어야 합니다. 이 차이를 모르고 "활성 파라미터가 40B니까 작은 GPU로도 되겠지"라고 생각하면 첫 시도부터 OOM(메모리 부족) 에러를 만나게 됩니다.

 

양자화 수준을 정하는 게 그래서 첫 결정입니다. FP8(8비트 부동소수점) 버전은 가중치만으로 약 750GB의 GPU 메모리가 필요한데, 이건 H200 8장(총 1.13TB HBM)이 있어야 KV 캐시까지 감안해서 여유 있게 돌아가는 크기입니다. BF16 원본은 정밀도가 두 배라 메모리도 그만큼 커져서 16장짜리 구성이 필요하기 때문에, 실무에서는 정확도 손실이 미미한 FP8이 사실상 표준 경로로 자리잡았습니다. 실제로 커뮤니티 다운로드 통계를 보면 FP8 버전이 BF16 대비 약 8배 더 많이 받힌 것으로 나타나, 대부분의 사용자가 이미 FP8을 기본값으로 택하고 있다는 걸 확인할 수 있습니다.

 

GPU 8장이 부담스러운 개인·소규모 팀이라면 4비트 GGUF 양자화로 llama.cpp에서 돌리는 경로가 유일한 대안입니다. 다만 4비트로 내려가면 정밀도 손실이 눈에 띄게 커지는데, 특히 복잡한 다단계 추론이나 긴 코드 리팩터링같이 "정확히 맞아야 하는" 작업에서 품질 저하가 두드러질 수 있습니다. 이 경우 실제 작업에 투입하기 전에 반드시 자신의 워크로드로 먼저 검증해보는 과정이 필요하고, 프로덕션에 바로 넣는 건 권장되지 않습니다.

 

# FP8 가중치 다운로드 (약 750GB)
huggingface-cli download zai-org/GLM-5.2-FP8 \
  --local-dir /models/glm-5.2-fp8 \
  --local-dir-use-symlinks False

# 다운로드가 제대로 됐는지 확인 - 두 파일이 반드시 있어야 함
du -sh /models/glm-5.2-fp8
ls /models/glm-5.2-fp8 | grep -E "config.json|safetensors.index.json"

 

config.json이 없으면 모델 아키텍처 정보가 누락된 것이고, safetensors.index.json이 없으면 샤드로 쪼개진 가중치 파일들을 어떻게 조합해야 하는지 알 수 없어서 서버 실행 단계에서 바로 실패합니다. 750GB짜리 다운로드는 중간에 끊기는 경우가 흔하기 때문에, 서버를 띄우기 전에 이 두 파일의 존재를 먼저 확인하는 습관이 나중에 디버깅 시간을 크게 줄여줍니다.

경량 환경을 위한 4비트 경로는 아래처럼 준비합니다. 이 경우 컨텍스트도 32K 수준으로 제한해야 단일 노드에서 안정적으로 돌아갑니다.

# 4비트 GGUF 양자화 다운로드
huggingface-cli download unsloth/GLM-5.2-GGUF \
  GLM-5.2-Q4_K_M.gguf \
  --local-dir /models/glm-5.2-gguf

cmake -B llama.cpp/build -DGGML_CUDA=ON
cmake --build llama.cpp/build --config Release -j

./llama.cpp/build/bin/llama-server \
  --model /models/glm-5.2-gguf/GLM-5.2-Q4_K_M.gguf \
  --ctx-size 32768 \
  --n-gpu-layers 999 \
  --host 0.0.0.0

 

--n-gpu-layers 999는 사실상 모델 전체 레이어를 GPU에 올리라는 뜻인데, 보유한 VRAM이 이를 감당하지 못하면 자동으로 일부 레이어가 CPU로 넘어가면서 속도가 급격히 느려집니다. 이 경우 숫자를 낮춰가며 자신의 하드웨어에 맞는 최댓값을 직접 찾아야 하는데, 보통 GPU 메모리 사용량을 모니터링하면서 OOM이 나기 직전 값으로 조정하는 게 일반적인 튜닝 방식입니다.

실전 2: vLLM로 프로덕션 서빙 띄우기

FP8로 8×H200 구성이 갖춰졌다면 vLLM이 가장 안정적인 선택입니다. vLLM이 널리 쓰이는 이유는 PagedAttention이라는 메모리 관리 기법 덕분인데, 이건 KV 캐시를 고정 크기로 미리 할당하지 않고 필요한 만큼 동적으로 페이지 단위로 나눠 쓰는 방식이라, 요청마다 입력 길이가 들쭉날쭉한 실서비스 환경에서 메모리 낭비를 크게 줄여줍니다. 커뮤니티 규모도 크고 다른 MoE 대형 모델에서도 충분히 검증된 프레임워크라, 이미 다른 모델을 vLLM으로 서빙하고 있는 팀이라면 운영 방식을 그대로 이어갈 수 있다는 것도 실질적인 장점입니다.

vllm serve "zai-org/GLM-5.2-FP8" \
  --tensor-parallel-size 8
  --max-model-len 262144
  --kv-cache-dtype fp8
  --enable-prefix-caching
  --tool-call-parser glm47
  --reasoning-parser glm45
  --enable-auto-tool-choice
  --port 8000

 

--tensor-parallel-size 8은 753B 가중치를 GPU 8장에 균등하게 쪼개서 로딩하는 옵션으로, 이 숫자는 실제 보유한 GPU 수와 정확히 일치해야 합니다.

--kv-cache-dtype fp8은 KV 캐시 자체도 8비트로 압축하는 옵션인데, 1M 토큰까지 컨텍스트를 확장하려면 이 압축이 사실상 필수입니다. KV 캐시를 압축하지 않고 긴 컨텍스트를 그대로 열면 가중치보다 KV 캐시가 메모리를 더 많이 잡아먹는 역전 현상이 벌어질 수 있기 때문입니다.

--tool-call-parser glm47과 --reasoning-parser glm45는 GLM 계열 전용 파서인데, 이걸 빼먹으면 모델이 함수 호출이나 추론 블록을 뱉어도 vLLM이 이걸 일반 텍스트로만 인식해서 에이전트 프레임워크(LangGraph, PydanticAI 등)와 연동할 때 파싱 오류가 발생합니다. 이 두 옵션은 이름 그대로 GLM 모델 특유의 출력 포맷을 해석하는 어댑터라고 생각하면 됩니다.

--enable-prefix-caching은 같은 시스템 프롬프트나 코드베이스 컨텍스트를 반복 호출할 때 이미 계산된 부분을 재사용하는 옵션이라, 에이전틱 코딩처럼 컨텍스트 재사용이 많은 워크로드에서는 체감 지연시간 차이가 상당히 큽니다.

서버가 뜨면 http://localhost:8000/v1로 OpenAI SDK와 동일한 방식으로 호출할 수 있어서, 기존에 OpenAI나 Claude API로 짜둔 코드가 있다면 base_url만 바꿔서 그대로 재사용할 수 있습니다.

실전 3: SGLang로 장시간 에이전트 세션 최적화하기

vLLM이 범용적으로 안정적이라면, SGLang은 특히 멀티턴 에이전트 워크플로우에서 강점을 보입니다. 핵심은 RadixAttention이라는 캐싱 구조인데, 일반적인 KV 캐시가 요청 단위로 독립적으로 관리되는 것과 달리 RadixAttention은 여러 요청이 공유하는 프리픽스(공통 접두사)를 트리 구조로 관리해서 겹치는 부분을 한 번만 계산합니다.

에이전트가 매 스텝마다 전체 코드베이스 컨텍스트나 긴 시스템 프롬프트를 반복해서 보내는 상황을 떠올려보면, 매번 100K 토큰짜리 컨텍스트를 처음부터 다시 계산하는 것과, 이미 계산된 부분을 캐시에서 불러오고 새로 추가된 부분만 계산하는 것 사이에는 응답 속도 차이가 클 수밖에 없습니다. 실측 보고에 따르면 이 구조 덕분에 같은 하드웨어에서 vLLM 대비 초당 요청 처리량이 약 3배까지 늘어난다고 합니다.

python -m sglang.launch_server \
  --model-path /models/glm-5.2-fp8 \
  --tp 8 \
  --quantization fp8 \
  --enable-moe-ep \
  --context-length 131072 \
  --tool-call-parser glm47 \
  --reasoning-parser glm45 \
  --port 30000

 

--enable-moe-ep는 MoE 전문가 병렬화(Expert Parallelism) 플래그입니다. 이 옵션 없이 텐서 병렬화만 쓰면 GPU마다 모든 전문가 가중치의 사본을 갖고 있게 되는데, GLM-5.2처럼 활성 파라미터 대비 전체 파라미터가 훨씬 큰 MoE 모델에서는 이게 메모리를 크게 낭비합니다. 전문가 병렬화를 켜면 각 GPU가 서로 다른 전문가 집합만 담당하고, 토큰이 라우팅될 때 필요한 GPU끼리만 통신하는 방식으로 바뀌어서 같은 하드웨어로 더 큰 배치를 처리할 수 있게 됩니다. NVLink나 NVSwitch로 GPU 간 대역폭이 충분히 확보된 환경이어야 이 이점을 제대로 살릴 수 있다는 점도 감안해야 합니다.

 

실제 코딩 에이전트에 투입할 때는 1M 전체 컨텍스트를 상시 열어둘 필요는 없고, 32K~131K 구간이 실제 작업 범위로 충분하다는 게 배포 가이드들의 공통된 권장 값입니다. 컨텍스트 길이를 키워둘수록 KV 캐시가 잡아먹는 메모리도 같이 늘어나기 때문에, 필요 이상으로 큰 값을 기본 설정으로 두면 동시에 처리할 수 있는 요청 수(동시성)가 오히려 줄어드는 역효과가 납니다. 1M 컨텍스트는 코드베이스를 통째로 흡수해야 하는 특수 작업, 예를 들어 대규모 마이그레이션이나 전체 저장소 감사 같은 작업에만 예외적으로 그때그때 열어두는 게 메모리 관리 측면에서 합리적입니다.

셀프호스팅 전 체크리스트

항목	권장값/주의사항
최소 GPU 구성	8×H200 (FP8 기준, 총 1.13TB HBM)
최소 프레임워크 버전	vLLM ≥ 0.23.0, SGLang ≥ 0.5.13.post1
라이선스	가중치 MIT(Hugging Face) / 코드 Apache 2.0(GitHub), 별도 적용
MoE 메모리 특성	활성 파라미터 40B와 무관하게 전체 753B가 항상 메모리에 상주
실전 컨텍스트 범위	코딩 에이전트: 32K~131K / 코드베이스 통째 흡수: 1M(예외적)
필수 플래그	--tool-call-parser glm47, --reasoning-parser glm45
경량 대안	4비트 GGUF + llama.cpp (품질 저하 감수, 컨텍스트 32K 권장)
셀프호스팅 손익분기	하루 100건 미만 호출이면 API가 더 저렴, 고빈도·데이터 통제 필요시 셀프호스팅

결론

GLM-5.2 셀프호스팅은 기술적으로는 명확한 경로가 있지만, 진입장벽은 라이선스가 아니라 하드웨어와 MoE 구조에 대한 이해입니다. 활성 파라미터가 40B라는 숫자만 보고 작은 GPU로도 될 거라 오해하면 첫 시도부터 막히고, FP8 기준 8×H200이라는 구성 자체가 소규모 팀에게는 상당한 투자입니다.

vLLM과 SGLang 중 어느 걸 고를지는 단발성 요청이 많은지 장시간 에이전트 세션이 많은지에 따라 갈리는데, 코드베이스를 반복 참조하는 에이전틱 워크플로우라면 SGLang의 RadixAttention이 주는 이점이 확실합니다.

MIT 라이선스가 주는 진짜 가치는 무료라는 점보다, 데이터가 외부로 나가지 않아도 되고 인프라를 직접 통제할 수 있다는 점입니다. 다만 이 가치를 누리려면 최소 몇 분기치 엔지니어링 리소스를 투입할 각오가 필요하고, 호출량이 하루 100건 미만인 소규모 워크로드라면 셀프호스팅보다 API를 쓰는 쪽이 훨씬 합리적인 선택입니다.