GLM-5.3-Flash 로컬 실행 방법

GLM-5.3-Flash는 MIT 라이선스로 출시된 3,200억 개의 매개변수 모델입니다. 이 두 가지 사실은 서로 반대 방향으로 작용합니다. 라이선스는 원하는 대로 실행할 수 있다고 말하지만, 매개변수 개수는 이를 위해 심각한 하드웨어가 필요하다고 말합니다.

흥미로운 부분은 3,200억 개의 매개변수 중 180억 개만이 토큰당 활성화되며, 양자화된 빌드도 존재한다는 점입니다. 이러한 조합 덕분에 이 모델은 대부분의 가이드에서 가정하는 8x H200 노드보다 훨씬 작은 설정에서도 접근 가능합니다.

이 게시물은 풀 정밀도 프로덕션 노드부터 워크스테이션의 양자화된 빌드에 이르기까지 하드웨어 계층을 솔직하게 설명하고, 직접 실행하는 것이 합리적인 경우를 다룹니다.

실제로 로드하는 것

속성	값
총 매개변수	320B
토큰당 활성	18B
아키텍처	MoE, 하이브리드 선형 및 희소 어텐션
컨텍스트	1,048,576 토큰
라이선스	MIT
가중치	`zai-org/GLM-5.3-Flash`
GGUF 양자화	`unsloth/GLM-5.3-Flash-GGUF`

전문가 혼합(MoE) 설계가 이를 실현 가능하게 만듭니다. 320B의 모든 매개변수가 메모리에 상주해야 하지만, 주어진 토큰에는 18B만 참여하므로, 총량에 비해 컴퓨팅 요구 사항은 훨씬 낮습니다. 따라서 메모리가 제약 조건이지, FLOPs가 아닙니다.

Z.ai는 또한 GLM-5.3보다 약 4.4배 작은 KV 캐시를 보고했는데, 이는 긴 컨텍스트 작업에 엄청나게 중요합니다. KV 캐시는 컨텍스트가 채워질 때 메모리를 소비하며, 1M 토큰 창에서는 일반적으로 이 부분이 문제가 됩니다.

계층 1: 프로덕션 노드에서 풀 정밀도

실제 동시성으로 전체 품질을 제공하기 위한 참조 구성은 **8x H200 노드** (각 141GB, 총 약 1,128GB)입니다. 8x H20 노드도 마찬가지로 작동합니다.

대략적인 수치: 가중치만으로 정밀도에 따라 700~800GB 정도가 필요하며, KV 캐시 및 런타임 오버헤드를 위한 여유 공간이 필요합니다. 이러한 노드의 클라우드 용량 임대는 하루에 약 $24~$48 정도입니다.

vLLM

vLLM은 일반적인 기본값이며 가장 폭넓은 생태계 지원을 제공합니다. 텐서 병렬 크기는 2의 거듭제곱이어야 합니다:

vllm serve zai-org/GLM-5.3-Flash \
  --tensor-parallel-size 8 \
  --max-model-len 1048576 \
  --trust-remote-code

설정을 검증하는 동안 더 작은 --max-model-len으로 시작하세요. 즉시 전체 백만 토큰 창을 요청하는 것은 KV 캐시를 할당하는 것을 의미하며, 이 경우 실패는 구성 문제가 아니라 메모리 부족 오류처럼 보입니다.

SGLang

SGLang은 이 모델에 대해 출시 당일부터 지원을 제공했으며, H100, H200, B200, B300, GB200, GB300에 대한 공개된 레시피와 다중 모달 서빙을 포함합니다. Z.ai는 자체 사전 출시 서빙에 SGLang 기반 스택을 사용했습니다.

python -m sglang.launch_server \
  --model-path zai-org/GLM-5.3-Flash \
  --tp 8 \
  --context-length 1048576

SGLang은 구조화된 출력 및 고동시성 에이전트 작업 부하에서 강점을 보입니다. 채팅 인터페이스가 아닌 코딩 에이전트를 서비스하는 경우, vLLM을 기본으로 사용하는 대신 벤치마킹하는 것이 좋습니다.

두 스택 모두 함수 호출이 제대로 작동하려면 도구 호출 파서를 구성해야 합니다. 파서 이름은 릴리스마다 변경되므로 각 프로젝트의 설명서에서 현재 플래그를 확인하세요.

계층 2: 더 작은 하드웨어에서 양자화

이 계층은 대부분의 보도에서 건너뛰는 부분이지만, 데이터 센터가 없는 모든 사람에게는 중요한 부분입니다.

양자화된 GGUF 빌드는 unsloth/GLM-5.3-Flash-GGUF에서 게시되며, IQ1_S 및 IQ2_XXS와 같은 공격적인 1비트 및 2비트 형식까지 지원합니다. 320B 모델의 2비트 양자화는 특히 CPU 오프로드를 통해 고용량 메모리 워크스테이션이나 다중 GPU 소비자용 장비가 처리할 수 있는 범위로 가중치를 가져옵니다.

두 가지 솔직한 주의사항:

공격적인 양자화는 품질 저하를 수반합니다. IQ1_S는 풀 정밀도와는 거리가 멉니다. 320B MoE에서는 동일한 처리를 밀집 모델에 적용했을 때보다 저하가 더 완만한 경향이 있는데, 이는 손실될 수 있는 중복성이 더 많기 때문입니다. 그러나 "실행된다"와 "잘 실행된다"는 다른 주장입니다. 어떤 결론을 내리기 전에 자신의 작업에 대해 테스트해 보세요.

이 모델에 대한 Unsloth의 문서는 아직 작업 중으로 표시되어 있습니다. 양자화 가용성 및 권장 설정은 여전히 변경될 수 있습니다. 특정 형식을 중심으로 빌드를 계획하기 전에 실제로 게시된 내용을 확인하세요.

CPU 중심 및 하이브리드 설정의 경우, **KTransformers**는 MoE 전문가를 시스템 RAM에 유지하고 필요한 부분만 GPU로 이동시키는 방식으로 정확히 이 경우를 위해 설계되었습니다. 18B 활성 매개변수를 가진 MoE 모델에서 이 아키텍처는 유난히 잘 맞습니다. **TokenSpeed**도 지원되는 런타임 목록에 있습니다.

GLM-4.7-Flash 로컬 실행 가이드는 이 워크플로우의 소규모 모델 버전을 다루고, GLM-5를 로컬에서 무료로 실행하기는 일반적인 로컬 GLM 설정을 다룹니다.

메모리 예산 계산

두 가지 숫자가 구성 적합성을 결정합니다.

가중치. BF16에서 매개변수당 약 2바이트를 기준으로 320B 매개변수는 오버헤드 전 약 640GB입니다. FP8은 이를 대략 절반으로 줄입니다. 4비트 양자화는 이를 약 160GB로 만들고, 공격적인 2비트 형식은 품질에 상당한 대가를 치르면서 더 낮아집니다.

KV 캐시. 이는 컨텍스트 길이와 동시성에 따라 확장되며, 사람들이 놀라는 부분입니다. 8K 컨텍스트에서 잘 로드되는 구성이 128K에서 실패할 수 있는데, 이는 가중치가 아닌 캐시가 증가했기 때문입니다. Z.ai가 보고한 GLM-5.3 대비 4.4배 감소는 여기서 많은 도움이 되지만, 확장은 여전히 토큰에 대해 선형적입니다.

실질적인 의미는 모델이 광고하는 최대값이 아닌 실제 컨텍스트 길이에 맞춰 크기를 정해야 한다는 것입니다. 전체 백만 토큰이 필요한 애플리케이션은 거의 없으며, 사용하지 않는 창을 프로비저닝하는 것이 이 모델을 비싸게 보이게 만드는 가장 일반적인 방법입니다.

이 계열의 초기 오픈 가중치 스토리를 따르고 계셨다면, 저희 GLM-5.3 자체 호스팅 게시물은 출시 전에 작성되었습니다. 이제 Flash의 가중치가 MIT 라이선스 하에 공개되었으므로, 여기의 지침이 우선합니다.

미세 조정

MIT 라이선스는 미세 조정 및 재배포를 허용하며, 이는 이러한 수준의 기능에서는 드문 일이고 가중치를 직접 보유하는 가장 강력한 이유입니다.

비용에 대해 현실적으로 생각하세요. 320B 모델의 전체 미세 조정은 대부분의 팀에게는 불가능합니다. LoRA와 같은 매개변수 효율적인 방법이 실용적인 경로이며, 전문가 혼합 모델에서는 라우터, 전문가 또는 어텐션 계층을 조정할 것인지에 대한 추가적인 설계 질문이 있습니다. 이는 밀집 모델보다 확립된 지침이 적은 활발한 연구 분야입니다.

새로운 기능보다는 도메인 적응이 목표라면, 먼저 기본 모델에 대해 프롬프팅 및 검색을 테스트해 보세요. 1M 토큰 컨텍스트 창이 있는 모델에서는 프롬프트에 도메인 지식을 넣는 것이 훈련시키는 것보다 종종 더 저렴하고 좋습니다.

샘플링 설정

Z.ai는 작업별로 다른 권장 사항을 게시합니다:

사용 사례	온도(temperature)	top_p
일반	1.0	0.95
코딩	0.95	1.0

이 모델은 또한 `reasoning_effort`를 통해 `low`, `high`, `max` 값을 사용하여 세 가지 추론 모드를 지원합니다. **Max가 기본값입니다.** 로컬 하드웨어에서는 API에서보다 이것이 더 중요합니다. 왜냐하면 추론 토큰은 돈이 아니라 실제 시간으로 지불하는 생성이기 때문입니다. 장비가 느리게 생성된다면 `low`는 사용 가능한 것과 그렇지 않은 것의 차이가 될 수 있습니다.

자체 호스팅이 경제적인가?

대부분의 경우 그렇지 않으며, API 가격이 그 이유입니다.

정가 기준으로 GLM-5.3-Flash는 백만 입력 토큰당 $0.15입니다. 한 달에 약 $1,000인 임대 8x H200 노드는 약 67억 입력 토큰의 API 사용량을 제공합니다. 그 이상의 볼륨을 지속적으로 유지하는 것은 대규모 운영입니다.

또한 노드는 사용량이 많든 유휴 상태든 비용이 동일한 반면, API는 사용량에 따라만 청구됩니다. 24시간 내내 활용률이 정말 높지 않다면, 고정 비용은 손해입니다.

따라서 자체 호스팅의 이유는 비용이 아닙니다:

데이터 보존 및 프라이버시. 인프라 외부로 나가는 것이 없습니다.
속도 제한 없음. 귀하의 용량이 귀하의 용량입니다.
가용성 보장. 공급업체의 가동 시간이나 가격 결정에 의존하지 않습니다.
MIT 라이선스. 수정, 미세 조정 및 재배포가 가능합니다. 이는 이 수준의 기능 모델에서는 이례적인 일이며 목록에서 가장 강력한 주장입니다.
이미 소유한 하드웨어. GPU가 구매되어 유휴 상태라면, 한계 비용은 전기료이며, 전체 계산이 역전됩니다.

저희 가격 분석은 이 비교의 API 측면을 더 자세히 다룹니다.

배포 검증

vLLM과 SGLang 모두 OpenAI 호환 엔드포인트를 노출하므로, 동일한 요청 형태가 로컬 서버와 Z.ai 모두에서 작동합니다:

curl http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "zai-org/GLM-5.3-Flash",
    "messages": [{"role": "user", "content": "reply with OK"}]
  }'

단순 기능 확인 이상으로 테스트할 가치가 있는 것: 실제로 필요한 길이에서의 긴 컨텍스트 동작, 다중 모달을 제공하는 경우 이미지 입력, 실제 스키마를 사용한 도구 호출, 단일 요청 대기 시간이 아닌 동시성 하에서의 처리량.

이것이 저장된 테스트 컬렉션이 제 역할을 하는 부분입니다. 기본 URL을 환경 변수로 사용하여 Apidog를 로컬 서버와 Z.ai 엔드포인트 모두에 연결하고, 각 대상에 대해 동일한 스위트를 실행한 다음 비교해 보세요. 양자화된 빌드가 애플리케이션이 의존하는 도구 스키마를 여전히 처리하는지 빠르게 알아낼 수 있을 것입니다. 이는 사람들이 프로덕션에서 발견하는 실패 모드입니다.

자주 묻는 질문

최소 하드웨어는 무엇인가요? 풀 정밀도의 경우, 8x H200급 노드입니다. 양자화된 GGUF 빌드의 경우, 품질이 양자화 수준에 따라 저하되지만 훨씬 적게 필요합니다.

320B 매개변수 전부를 메모리에 로드해야 하나요? 네. 토큰당 18B만 활성화되지만, 전체 세트는 상주해야 합니다. 메모리가 제약 조건이지, 컴퓨팅이 아닙니다.

vLLM과 SGLang 중 어느 것이 더 좋나요? SGLang은 게시된 다중 모달 레시피와 함께 출시 당일부터 지원을 제공했으며, 종종 동시성 및 구조화된 출력에서 강점을 보입니다. vLLM은 더 폭넓은 생태계 지원을 제공합니다. 워크로드에 대해 둘 다 벤치마킹하세요.

단일 GPU에서 실행할 수 있나요? 풀 정밀도로는 불가능합니다. KTransformers를 통한 공격적인 양자화 및 CPU 오프로드를 사용하면, 고용량 메모리 단일 GPU 시스템과 많은 시스템 RAM을 사용하는 것이 가능합니다. 생성 속도는 느릴 것입니다.

라이선스는 정말 MIT인가요? 네. 가중치는 상업적 사용, 수정 및 재배포를 허용하는 MIT 라이선스로 게시됩니다.