GLM-5.3

GLM-5.3

GLM-5.3은 Z.ai의 플래그십 Mixture-of-Experts 모델로, DeepSeek Sparse Attention (DSA) 기반으로 동작해요. 번개처럼 빠른 인덱서가 쿼리당 희소한 키 토큰 세트(top-2048)를 골라내서 컨텍스트가 커져도 어텐션 비용이 거의 일정하게 유지돼요. 같은 기본 구조를 유지하면서 복잡한 코딩과 장기 지평 작업을 위한 사후 학습을 업데이트했어요. FP8(zai-org/GLM-5.3)과 풀 BF16(zai-org/GLM-5.3-BF16) 두 정밀도로 제공되며, 둘 다 78개 transformer 레이어, 256개 라우팅 전문가(토큰당 8개 활성), 1M 토큰 컨텍스트 윈도우, 단일 MTP(Multi-Token Prediction) 레이어를 갖춰요.

FP8 배포가 권장되고, BF16(~1.5 TB)은 8×B300 노드나 멀티노드 구성이 필요해요. Blackwell용으로 RadixArk는 실험적 NVFP4 빌드(RadixArk/GLM-5.3-NVFP4, Model Optimizer)를 제공하는데, 라우팅 전문가의 linear 가중치와 활성화만 4-bit로 양자화하고(어텐션, 공유 전문가, dense 레이어, MTP, 임베딩, LM 헤드) 가중치 풋프린트를 ~0.45 TB로 줄여 4-GPU GB300 노드가 TP4로 서빙할 수 있게 해요.

이 문서는 SGLang으로 GLM-5.3을 배포하는 방법, 구성 팁, 추론·함수 호출·HiCache·Claude Code 통합 같은 고급 사용법을 설명해요.

원문 페이지에는 하드웨어와 배포 전략을 골라 명령을 생성하는 Deploy 패널과 추가 기능 노브를 위한 Playground가 포함되어 있어요. 위키에서는 렌더링되지 않으니 아래 지침을 직접 참고하면 돼요.

출처: 문서

본문

Deployment

설치 방법과 하드웨어 플랫폼은 공식 SGLang 설치 가이드를 참고하세요. 아래 두 경로는 명령 패널의 Python / Docker 토글에 해당해요.

Python (pip / uv):

pip install --upgrade pip
pip install uv
uv pip install --prerelease=allow sglang

그다음 명령 패널의 Python 출력을 해당 환경에서 실행하세요.

Docker:

docker pull lmsysorg/sglang:latest

이미지 실행 방법은 Install → Method 3: Using Docker을 참고하고, 안쪽 sglang serve ...를 아래 명령 생성기가 만들어 주는 것으로 바꿔 끼우세요.

하드웨어와 레시피를 골라 실행 명령을 생성해요. 세 가지 서빙 전략이 일반적인 운영 지점을 다룬답니다:

• Low-Latency — 단일 사용자에게 가장 빠른 응답. 채팅에 적합해요.
• Balanced — 여러 사용자가 동시에 있어도 좋은 속도. 일반적인 멀티 사용자 서빙에 사용해요.
• High-Throughput — 많은 사용자에 걸쳐 초당 최대 토큰 수. 배치 작업에 최적이에요.

여기 모든 레시피는 기본 `--dsa-topk-backend sgl-kernel`에서 DSA 인덱서 top-k를 실행해요. 다른 top-k 백엔드 선택은 GLM-5.3에서 완전히 검증되지 않았어요.

Playground

Playground는 배포 매트릭스를 넘어선 SGLang 기능을 실험하는 곳이에요. Deploy 패널이 현재 보여주는 셀 위에 추가 노브를 켤 수 있어요.

1. 모델 소개

GLM-5.3은 Z.ai의 플래그십 Mixture-of-Experts 모델로, DeepSeek Sparse Attention (DSA) 기반으로 동작해요. 번개처럼 빠른 인덱서가 쿼리당 희소한 키 토큰 세트(top-2048)를 골라내므로 컨텍스트가 커져도 어텐션 비용이 거의 일정하게 유지돼요. 같은 기본 구조를 유지하면서 복잡한 코딩과 장기 지평 작업을 위한 사후 학습을 업데이트했어요. FP8(zai-org/GLM-5.3)과 풀 BF16(zai-org/GLM-5.3-BF16) 두 정밀도로 제공되며, 둘 다 78개 transformer 레이어, 256개 라우팅 전문가(토큰당 8개 활성), 1M 토큰 컨텍스트 윈도우, 단일 MTP(Multi-Token Prediction) 레이어를 갖춰요. FP8 배포가 권장되고, BF16(~1.5 TB)은 8×B300 노드 또는 멀티노드 구성이 필요해요. Blackwell용으로 RadixArk는 실험적 NVFP4 빌드(RadixArk/GLM-5.3-NVFP4, Model Optimizer)를 제공하는데, 라우팅 전문가의 linear 가중치와 활성화만 4-bit로 양자화하고(어텐션, 공유 전문가, dense 레이어, MTP, 임베딩, LM 헤드는 양자화되지 않음) 가중치 풋프린트를 ~0.45 TB로 줄여 4-GPU GB300 노드가 TP4로 서빙할 수 있어요. NVFP4 셀은 실험적이라 벤치마크 데이터(정확도/처리량)가 아직 보류 중이고, 벤치마크 카드가 채워질 때까지 임시로 취급하세요.

모델	구조	컨텍스트
GLM-5.3	MoE · DSA · 256 experts (top-8) · MTP · FP8	1,048,576
GLM-5.3-BF16	MoE · DSA · 256 experts (top-8) · MTP · BF16	1,048,576
GLM-5.3-NVFP4	MoE · DSA · 256 experts (top-8) · MTP · NVFP4	1,048,576

권장 생성 설정: temperature=1.0, top_p=0.95 (체크포인트 generation_config.json 기본값; 참고용이며 하드코딩하지 마세요).

리소스: GLM-5.3 · GLM-5.3-BF16 · GLM-5.3-NVFP4.

2. 구성 팁

• DeepSeek Sparse Attention (DSA). GLM-5.3은 glm_moe_dsa 아키텍처를 사용해요. SGLang은 DSA 어텐션 백엔드(flashmla_sparse prefill, fa3 decode, sgl-kernel 인덱서 topk)를 자동 선택하므로 지원 하드웨어에서는 어텐션 백엔드 플래그가 필요 없어요. SGLang은 DSA 모델의 KV-cache dtype도 자동 선택해요 — Blackwell(B200/GB300/B300, 그러면 DSA를 TensorRT-LLM 백엔드로 라우팅)에서는 fp8_e4m3, Hopper(H200)에서는 bf16 — 그래서 --kv-cache-dtype 플래그가 필요 없어요. Hopper에서 --kv-cache-dtype fp8_e4m3과 --dsa-prefill-backend flashmla_sparse_q8 --dsa-decode-backend flashmla_kv를 짝지으면 네이티브 FP8 희소 prefill 커널을 선택해요(fp8→bf16 역양자화 왕복 없이 fp8 KV 캐시에 직접 계산; GLM-5.3의 64개 query head가 커널 네이티브 타일과 일치) — 커널 세부 정보는 DeepSeek-V3.2 페이지를 참고하세요. 선택적 SGLANG_ENABLE_DSA_Q8KV8_* 성능 환경 변수는 python/sglang/srt/environ.py에 문서화되어 있어요.

• MTP / 추측 디코딩. 체크포인트에는 nextn 레이어가 하나 있어요. 더 낮은 지연 시간을 위해 EAGLE MTP를 활성화하세요(저지연용 --speculative-algorithm EAGLE --speculative-num-steps 5 --speculative-eagle-topk 1 --speculative-num-draft-tokens 6; 균형용 1-1-2). config의 index_share_for_mtp_iteration은 draft 단계 간에 DSA 인덱서 topk를 재사용해요(--speculative-eagle-topk 1에서만 유효). 서버가 보고하는 accept length를 보고 --speculative-num-steps / --speculative-num-draft-tokens을 조정하세요: 거부된 draft 토큰이 과도한 검증 작업을 만들면 draft 길이를 낮추세요.

• DFlash2 (블록 확산 draft). 위 Playground의 Speculative 카드는 DFlash2도 제공하는데, 이는 체크포인트 내 MTP 레이어를 별도 훈련된 블록 확산 drafter incoai/GLM-5.3-DFlash2로 교체해요. 단계당 전체 블록을 제안하고 target이 한 번의 forward pass로 블록을 검증하므로 출력 품질은 target의 것을 유지해요. 블록 크기 — 8, 즉 검증 단계당 draft 토큰 7개 —는 draft 체크포인트 자체의 dflash_config에서 오므로 --speculative-num-draft-tokens을 전달하지 않아요. draft는 작은 dense 모델이며 target의 DSA 백엔드 대신 fa4에서 실행돼요. DFLASH는 CUDA/NPU 전용이며 DP-Attention을 거부하므로, 고처리량 기준선에서 선택하기 전 Attention 카드에서 DP-Attention을 꺼야 해요. draft 저장소는 공개지만 연구·평가용 CC BY-NC-ND 4.0 라이선스예요.

• 메모리. FP8 가중치는 큽니다(MoE 총합이지 활성 파라미터가 아님). H200(TP8)에서는 --mem-fraction-static 0.8 정도에서 시작해 올리며 튜닝하고, 4-GPU GB300 단일 노드 구성(TP4)에서는 더 올리세요.

• DP-Attention + DeepEP은 균형/고처리량 전략을 위해 어텐션을 데이터 병렬 랭크에 퍼뜨리고 MoE를 DeepEP로 라우팅해요.

• BF16 가중치는 더 많은 GPU가 필요해요. 풀 프리시전 빌드(zai-org/GLM-5.3-BF16, ~1.5 TB)는 단일 8×H200 / 8×B200 / 4×GB300 노드에 들어가지 않아요. 8×B300(TP8, ~2.1 TB HBM)에서는 단일 노드로 맞고, 더 작은 GPU에서는 멀티노드 구성이 필요해요(예: TP16에서 2×8×H200 또는 2×8×B200, TP8에서 2×4×GB300). FP8이 권장 배포예요. DSA / MTP / chunked-prefill 안내는 FP8과 동일하게 적용돼요.

• PD Disaggregation (prefill/decode). GLM-5.3은 DSA 모델이며 prefill/decode 분리 하에서 실행돼요 — 위 Playground의 PD Disagg 카드를 켜고(Prefill/Decode 역할 + 전송 백엔드 선택 후 sglang_router.launch_router --pd-disaggregation으로 앞단 구성). Mooncake 백엔드는 InfiniBand HCA를 자동 감지하므로 기본적으로 디바이스 플래그가 필요 없어요. 자동 감지가 잘못된 디바이스를 고르거나 KV 전송 연결이 실패할 때만 --disaggregation-ib-device mlx5_0(자신의 NIC)을 추가하세요. H200 Docker에서 컨테이너에 IB HCA를 노출하세요(--privileged --ulimit memlock=-1, 또는 --device /dev/infiniband:/dev/infiniband --cap-add IPC_LOCK) — IB 미노출 시 Mooncake는 조용히 TCP로 폴백돼요.

• Chunked-prefill 크기는 상황에 따라 달라요. 긴 입력 균형 워크로드에서는 --chunked-prefill-size 32768로 시작하고 입력 길이와 KV 용량에 맞춰 --max-running-requests와 함께 튜닝하세요. 프로파일링에서 prefill이 병목임을 보여주지 않는 한 고처리량 레시피의 기본 chunked-prefill 크기를 유지하세요.

• AMD GPU (MI300X / MI325X / MI355X). FP8(zai-org/GLM-5.3)은 세 플랫폼 모두에서 단일 노드 tp=8로 실행돼요. BF16(zai-org/GLM-5.3-BF16, ~1.51 TB)은 MI325X(2 TB HBM)와 MI355X(2.3 TB)에서만 단일 노드로 맞아요; MI300X(1.5 TB)는 한 노드에 BF16 가중치와 KV 캐시를 함께 담을 수 없으므로 거기서는 FP8을 사용하세요. DSA tilelang 백엔드(--dsa-prefill-backend tilelang --dsa-decode-backend tilelang)를 사용하고 --chunked-prefill-size 131072와 --watchdog-timeout 1200(가중치 로딩 20분)을 추가하세요. GLM-5.3과 DeepSeek-V3.2는 같은 모델 구조를 공유하므로, 다른 DSA / HiSparse 팁은 DeepSeek-V3.2 cookbook을 참고하세요.

• MTP / EAGLE 추측 디코딩은 Deploy 패널에서 AMD에 대해 비활성화되어 있어요. gfx950 spec-decode draft 커널이 이 하드웨어에서 아직 검증되지 않았기 때문이에요(--speculative-num-steps > 3에서는 별도의 빌드 이슈가 발생). gfx950에서 MTP가 검증될 때까지 --speculative-* 플래그를 생략하고 MTP 없이 서빙하세요.

3. 고급 사용법

3.1 추론(reasoning)

GLM-5.3은 추론 모델이며, 생성 명령은 기본적으로 --reasoning-parser auto(GLM-5.3에서 glm45로 해석)를 켜서 thinking이 최종 답변과 분리돼요 — thinking은 message.reasoning_content에, 답변은 message.content에 담겨요. 파서가 없으면 채팅 템플릿이 생성 프롬프트에서 thinking을 여므로, 서버는 thinking과 답변을 사이에 지저분한 response가 끼어든 하나의 content 문자열로 반환해요. 원시 형식이 필요한 통합에서는 위 Playground의 Parsers 카드에서 Reasoning Parser를 비활성화할 수 있어요. 채팅 템플릿은 clear_thinking을 기본 false로 두는데, 멀티 턴 채팅에서는 chat_template_kwargs: {"clear_thinking": True}를 전달해 다음 응답 전에 이전 추론을 지우세요.

추론 노력. chat_template_kwargs: {"reasoning_effort": ...}을 전달해 low, high, max를 선택해요. 생략하거나 다른 값을 주면 템플릿은 max를 사용해요.

reasoning_effort	주입되는 시스템 줄	효과
(전달 안 함 / 미설정), "max"	Reasoning Effort: Max	기본값 — 가장 높은 추론 노력
"high"	Reasoning Effort: High	높은 추론 노력
"low"	Reasoning Effort: Low	낮은 추론 노력
기타 모든 값	Reasoning Effort: Max	기본값으로 폴백

추론 예시 (Python):

from openai import OpenAI

client = OpenAI(base_url="http://localhost:30000/v1", api_key="EMPTY")
resp = client.chat.completions.create(
    model="zai-org/GLM-5.3",
    messages=[{"role": "user", "content": "What is 15% of 240?"}],
    extra_body={"chat_template_kwargs": {"clear_thinking": True, "reasoning_effort": "high"}},
)
msg = resp.choices[0].message
print("Reasoning:", getattr(msg, "reasoning_content", None))
print("Answer:", msg.content)

출력 예시:

Reasoning: 1.  **Identify the core question:** The user wants to find 15% of 240.
2.  **Convert the percentage to a decimal:** 15% = 0.15
3.  **Multiply by the total:** 0.15 * 240 = 36
    (Quick mental math: 10% of 240 = 24; 5% = 12; 24 + 12 = 36.)

Answer: 15% of 240 is **36**.

Here is how you can calculate it:
0.15 × 240 = 36

3.2 함수 호출(Tool Calling)

생성 명령은 기본적으로 --tool-call-parser auto를 켜서 구조화된 호출이 finish_reason: "tool_calls"와 함께 message.tool_calls로 반환돼요. auto는 GLM-5.3에 대해 **glm47**로 해석돼요: 모델이 더 새로운 <tool_call>…<arg_key>…<arg_value>… 형식을 출력하며, 이전 glm45 파서는 이를 파싱하지 못해요(호출이 content에 원시 텍스트로 남음). 함수 호출 파서 없이 실행해도 같은 방식으로 실패하고 finish_reason이 "stop"으로 남아 에이전트 루프가 호출을 전혀 보지 못해요. 함수 호출이 필요 없으면 위 Playground의 Parsers 카드에서 Tool Call Parser를 비활성화할 수 있어요. thinking 모드에서는 턴이 reasoning_content도 채우므로 두 필드를 모두 출력하세요.

함수 호출 예시 (Python):

from openai import OpenAI

client = OpenAI(base_url="http://localhost:30000/v1", api_key="EMPTY")
tools = [{
    "type": "function",
    "function": {
        "name": "get_weather",
        "description": "Get the current weather for a city",
        "parameters": {
            "type": "object",
            "properties": {"city": {"type": "string"}},
            "required": ["city"],
        },
    },
}]
resp = client.chat.completions.create(
    model="zai-org/GLM-5.3",
    messages=[{"role": "user", "content": "What's the weather in Paris?"}],
    tools=tools,
)
msg = resp.choices[0].message
print("Reasoning:", getattr(msg, "reasoning_content", None))
print("Tool calls:", msg.tool_calls)

출력 예시:

Reasoning: The user wants to know the weather in Paris. I'll call the get_weather function with "Paris" as the city.

Tool calls: [
  {
    "id": "call_13fcd52146934b7781d06d4a",
    "type": "function",
    "function": {"name": "get_weather", "arguments": "{\"city\": \"Paris\"}"}
  }
]

3.3 HiCache (계층적 KV 캐싱)

장문·prefix 집약 워크로드에서는 계층적 KV 캐싱을 활성화해 차가운 KV 블록을 호스트 메모리로 넘길 수 있어요(위 Playground의 Hierarchical KV Cache 카드 토글). GLM-5.3의 1M 토큰 윈도우를 고려하면 유용하며, --hicache-ratio을 재사용 패턴에 맞는 쓰기 정책과 짝지어 사용하세요.

3.4 Claude Code 통합

GLM-5.3의 강력한 추론 + 함수 호출 능력은 Anthropic의 에이전틱 CLI인 Claude Code의 좋은 백엔드가 돼요. SGLang은 모든 서버에서 Anthropic 호환 /v1/messages 엔드포인트를 노출하므로, Claude Code는 환경 변수만으로 코드 변경 없이 GLM-5.3 서버와 대화할 수 있어요. 서버를 --reasoning-parser auto --tool-call-parser auto로 시작하고(위 Deployment 패널의 아무 레시피나 동작), 그다음:

export ANTHROPIC_BASE_URL="http://127.0.0.1:30000"
export ANTHROPIC_AUTH_TOKEN="dummy"
export API_TIMEOUT_MS="3000000"
export CLAUDE_CODE_AUTO_COMPACT_WINDOW="1000000"
export CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1
export CLAUDE_CODE_ATTRIBUTION_HEADER=0
export ANTHROPIC_DEFAULT_HAIKU_MODEL="glm-5.3[1m]"
export ANTHROPIC_DEFAULT_SONNET_MODEL="glm-5.3[1m]"
export ANTHROPIC_DEFAULT_OPUS_MODEL="glm-5.3[1m]"
claude

이 중 두 가지가 GLM-5.3에 특히 중요해요:

• CLAUDE_CODE_ATTRIBUTION_HEADER=0 — Claude Code는 시스템 프롬프트 앞에 요청별 attribution 블록을 붙여요. GLM-5.3의 채팅 템플릿은 tools를 system 앞에 렌더링하므로 요청별 해시가 턴 간 첫 토큰이 되어 radix prefix 캐시가 매 턴마다 전체 system + history를 다시 prefill해요. 이 env는 블록을 제거해 prefix 캐시 재사용을 복원해요.
• 모델 이름으로 glm-5.3[1m] — [1m] 접미사는 GLM-5.3의 1,048,576 토큰 윈도우에 맞는 Claude Code의 1M 컨텍스트 베타를 활성화하는 클라이언트 측 힌트예요. 이게 없으면 컨텍스트가 1M보다 훨씬 아래로 제한돼요. SGLang은 model 필드를 검증하지 않으므로 서버 측에서는 어떤 이름이든 허용돼요.

전체 설정(스트리밍, tool-use, count_tokens, ~/.claude/settings.json에 env 저장, 트러블슈팅)은 Anthropic-Compatible API를 참고하세요.

3.5 컨텍스트 병렬 처리(Context Parallelism)

Zigzag prefill CP(`--cp-strategy zigzag`)는 GLM-5.3에서 임시로 사용할 수 없어요. CUDA에서 prefill CP를 쓰려면 아래처럼 `--dp 1`과 함께 `interleave`를 사용하세요.

Prefill 컨텍스트 병렬 처리는 장문 컨텍스트에서 TTFT를 줄이는 데 도움이 돼요. GLM-5.3에서 prefill 컨텍스트 병렬 처리를 활성화하려면 다음 인자를 추가하세요:

--attn-cp-size 8 \
--enable-prefill-cp \
--cp-strategy interleave \

이는 어텐션 forward 중 시퀀스를 --attn-cp-size 랭크에 균등하게 분할해요. prefill CP의 트레이드오프는 인덱서 topk와 어텐션 커널 전에 추가 all-gather 연산이 들어가서 decode(통합 배포) 또는 짧은 prefill의 지연 시간을 늘린다는 점이에요.

PD Disaggregation으로 배포할 때 Mooncake 전송 백엔드를 사용하는 prefill 워커는 LayerSplit 기법을 켤 수 있어요:

--enable-dsa-cache-layer-split \
--enable-prefill-cp \
--attn-cp-size 8 \
--cp-strategy interleave \

LayerSplit을 사용하면 각 랭크의 KV 캐시를 CP 어텐션 그룹에 걸쳐 분할하고 필요할 때 prefetch할 수 있어요. 이렇게 하면 KV 캐시 메모리를 최대 75% 줄여 prefill 쪽 처리량을 높일 수 있어요.

더 알아보기 (Learn more)

• GLM-5.3 · GLM-5.3-BF16 · GLM-5.3-NVFP4
• DeepSeek-V3.2 cookbook (DSA 팁)
• Anthropic-Compatible API
• SGLang 설치 가이드