GLM-5.3-Flash

GLM-5.3-Flash는 하이브리드 어텐션 아키텍처를 중심으로 한 네이티브 멀티모달 Mixture-of-Experts 모델로, 총 320B 파라미터 중 활성 18B를 사용해요. 45개 텍스트 레이어가 MLA 어텐션, DSA 희소 어텐션, KDA 선형 어텐션을 결합하고, 24개 레이어의 비전 인코더가 이미지와 비디오 입력을 처리해요. 체크포인트는 토큰당 8개 활성인 288개 라우팅 전문가와, 추측 디코딩을 위한 네이티브 MTP draft 레이어를 갖춰요.

FP8 가중치와 1M 토큰 컨텍스트, 텍스트·이미지·비디오 입력을 지원하며, 생성 기본값은 temperature=1.0, top_p=0.95, thinking 활성화예요. GLM-5.3-Flash의 배포, 구성 팁, 고급 사용법(추론, 함수 호출, 멀티모달 서빙, 인코더 분리, PD 분리)을 설명해요.

이 문서는 SGLang v0.5.20 이상을 요구하며, 하드웨어와 전략을 골라 명령을 생성하는 Deploy 패널과 세부 튜닝을 위한 Playground를 포함해요. 위키에서는 렌더링되지 않으니 아래 지침을 직접 참고하면 돼요.

출처: 문서

본문

Deployment

GLM-5.3-Flash 지원을 포함하는 SGLang 빌드(v0.5.20 이상)를 사용하세요.

docker pull lmsysorg/sglang:latest

배포 패널은 선택한 하드웨어와 옵션에 대해 완전한 docker run 명령을 렌더링할 수 있어요. 호스트 설정은 Install SGLang with Docker를 참고하세요.

하드웨어를 선택한 다음 워크로드에 맞는 운영 지점을 고르세요:

Low Latency는 MTP 5/1/6 추측 디코딩과 텐서 병렬로 시작해 대화형 응답을 짧게 만들어요.
High Throughput은 추측 디코딩을 끈 상태로 시작해 지속적 배치에서 draft-and-verify 오버헤드를 피해요.

나열된 모든 하드웨어 플랫폼이 두 전략을 모두 노출해요. Verified 배지는 해당 하드웨어와 명령이 테스트됐다는 뜻이에요. Final Verification In Progress는 레시피가 실행되고 최종 가중치 측정 대기 중임을 의미해요. Not Verified는 명령이 지원되는 시작점이며 여전히 워크로드 검증이 필요하다는 뜻이에요. 선택이 비활성화되는 것은 오직 기본 런타임 조합이 지원되지 않는 것으로 알려진 경우뿐이에요.

권장 선택은 시작점일 뿐이에요. 같은 패널에서 KV/DSA 페어링, 멀티모달 피처 전송, Breakable Cuda Graph, HiCache 계층을 덮어쓸 수도 있어요. 측정된 명령의 일부가 아닌 옵션을 바꾸면 배지가 Not Verified로 바뀌지만 옵션은 숨겨지지 않아요.

Breakable Cuda Graph는 기본 Off예요. On을 선택하면 생성 명령에 --cuda-graph-backend-prefill breakable이 추가돼요. 이 기능에는 PR #38522을 포함한 빌드가 필요해요.

생성된 명령은 `--mamba-full-memory-ratio`를 `0.9` 기본값으로 둬요. 이는 워크로드 튜닝 분할이 아니라 일반적 시작점이에요: 너무 낮으면 KDA 상태 풀을 굶겨 `max_running_requests`를 조이고, 너무 높으면 과잉 공급되어 KV 풀을 줄여요. 평균 요청 길이와 부팅 로그에 출력되는 두 풀 크기에서 균형 잡힌 비율을 계산하려면 리포 로컬 [`compute-mamba-ratio`](https://github.com/sgl-project/sglang/blob/main/.claude/skills/compute-mamba-ratio/SKILL.md) 스킬(또는 대신 쓸 `--max-mamba-cache-size` 핀)을 사용하세요. 각 풀이 무엇을 제한하는지는 [두 메모리 풀 크기 조절](#)을 참고하세요.

Playground

Playground는 어텐션 병렬, MoE 통신, 추측 디코딩, reasoning/tool 파서 같은 저수준 튜닝을 위한 것이라 배포 패널의 모든 선택을 상속하고 명령줄 diff만 보여줘요.

1. 모델 소개

GLM-5.3-Flash는 하이브리드 어텐션 아키텍처를 중심으로 한 네이티브 멀티모달 Mixture-of-Experts 모델로, 총 320B 파라미터 중 활성 18B를 사용해요. 45개 텍스트 레이어가 MLA 어텐션, DSA 희소 어텐션, KDA 선형 어텐션을 결합하고, 24개 레이어 비전 인코더가 이미지와 비디오 입력을 처리해요. 체크포인트는 토큰당 8개 활성인 288개 라우팅 전문가와 네이티브 MTP draft 레이어를 갖춰요. 훈련 세부사항은 GLM-5.3-Flash 블로그와 GLM-5 기술 보고서를 참고하세요.

속성	설명
구조	하이브리드 어텐션(MLA, DSA, KDA), mHC, MTP를 갖춘 MoE — 총 320B / 활성 18B 파라미터
정밀도	FP8 가중치; Blackwell에서는 기본 FP8 KV 캐시, H100과 H200에서는 BF16 KV 캐시
컨텍스트	1M 토큰
입력	텍스트, 이미지, 비디오
생성 기본값	`temperature=1.0`, `top_p=0.95`, thinking 활성화

배포 레시피는 체크포인트의 생성 구성을 사용해요. 앱에 자체적으로 평가된 설정이 있을 때만 샘플링을 오버라이드하세요.

2. 구성 팁

전략 선택

채팅과 에이전트 워크로드에는 Low Latency로 시작하세요. 고정 깊이(5단계, top-k 1, 6 draft 토큰)에서 체크포인트의 MTP 헤드로 draft를 생성하고 자연스러운 acceptance를 사용해요. 추측 디코딩을 끄는 편이 더 효율적인 대량 배치 트래픽에는 High Throughput을 측정하세요. SGLang은 --speculative-algorithm EAGLE을 통해 MTP를 서빙하므로(상류에서 이전 NEXTN 표기를 EAGLE로 접음) 생성 명령은 그 플래그 값을 사용해요.

전략 라벨은 워크로드 목표를 설명하지 하드웨어 제한을 설명하지 않아요. 하드웨어를 바꿔도 두 전략 모두 사용할 수 있고, 검증 배지만 바뀌어요.

추측 알고리즘 변경

Playground의 Speculative 카드는 선택한 전략을 떠나지 않고 알고리즘을 바꿔요:

EAGLE / MTP 5-1-6은 Low Latency가 서빙하는 바로 그 것이므로, Low Latency 기준선은 이 칩에서 시작해요. High Throughput 기준선에서 이것을 골라 그 레시피의 다른 설정을 유지하면서 MTP 헤드를 추가할 수 있어요.
**Off (greedy)**는 --speculative-* 계열 전체를 제거하며, High Throughput이 이미 그것으로 시작해요.
DFlash2는 체크포인트 내 MTP 헤드를 incoai/GLM-5.3-Flash-DFlash2의 훈련된 블록 확산 draft로 교체해요. draft가 단계당 전체 블록을 제안하고 target이 한 번의 forward pass로 검증하므로 출력 품질은 target의 것을 유지해요. 블록 크기는 draft 체크포인트에서 오고, draft는 target의 DSA 백엔드가 아니라 fa4에서 실행돼요. 필요한 hidden-state 캡처(PR #36708)는 GLM-5.3-Flash 지원과 함께 v0.5.20에서 출시되어 위 고정 이미지면 충분해요. draft 저장소는 접근 제한이 있어요: 모델 페이지에서 접근을 요청한 다음 target과 함께 다운로드해 서빙하세요. 이 조합은 cookbook 하드웨어에서 아직 측정되지 않았으므로 시작점으로 취급하세요.

두 알고리즘 모두 DP-Attention과는 실행되지 않으며, 카드는 해당 칩을 비활성화하고 이유를 명시해요.

두 메모리 풀 크기 조절

GLM-5.3-Flash는 어텐션용 페이징 KV 풀과 별도의 KDA 상태 풀을 유지해요. KDA 상태 풀은 KV 풀이 가득 차기 전에 동시성을 제한할 수 있어요. KDA 상태 용량 때문에 시작 시 max_running_requests가 줄어든다면, 예상 동시성에 맞춰 --mamba-full-memory-ratio을 높이거나 --max-mamba-cache-size를 설정한 다음 --max-running-requests를 워크로드에 맞게 튜닝하세요.

모든 전략에서 prefix 캐시를 활성화 상태로 두세요.

체크포인트의 KDA 하한 설정은 그대로 두세요. 특히 --json-model-override-args로 linear_lower_bound을 오버라이드하지 마세요.

KV와 DSA 백엔드를 짝지어 유지

Blackwell에서 레시피는 TRT-LLM DSA와 FP8 KV 캐시를 기본으로 해요: GB300에서 이 페어링은 동일한 풀 바이트에서 처리량 2.9–5.7% 더 높고 KV 토큰 용량은 약 1.8배였으며 GSM8K 정확도는 BF16과 노이즈 이내였어요. BF16 KV + TileLang DSA는 여전히 배포 패널에서 선택 가능하며 H100과 H200에서 기본값인데, 거기서는 FP8 KV + TRT-LLM DSA가 비활성화돼요. dtype과 두 DSA 백엔드를 함께 바꾸세요. TileLang DSA + FP8 KV는 유효한 CUDA 조합이 아니에요.

캐시 계층 확장

GPU 메모리가 충분하면 HiCache를 꺼두세요. L1 + L2를 선택하면 재사용 가능한 캐시 항목을 호스트 메모리로 넘겨요. + L3는 모든 서빙 노드에서 Mooncake를 구성한 후에만 선택하세요. 생성 명령이 필요한 구성 경로를 노출해요. 이 옵션들은 선택 가능하지만 결과 명령이 선택 하드웨어에서 검증되기 전까지 Not Verified로 표시돼요.

멀티모달 메모리

모든 전략이 멀티모달 서빙을 활성화해요. 프로세서는 비디오를 2 FPS로 샘플링하고 비디오 입력을 240,000 시각 토큰으로 제한해요. 비디오 요청 전에 서빙 환경에 torchcodec를 설치하세요. 4x GB300에서 아주 긴 비디오는 인코더 분리를 사용해 비전 인코더의 메모리 스파이크를 언어 디코딩에서 격리하세요.

기본 멀티모달 피처 전송은 자동이며, 단일 CUDA 노드에서는 CPU 전송으로 자동 해석돼요. CUDA IPC는 선택제(opt-in): IPC 풀이 예약하는 GPU 메모리보다 전송 지연 시간이 더 중요할 때 --mm-feature-transport cuda_ipc를 전달하세요. CUDA VMM 전송은 MNNVL 패브릭의 멀티노드 GB200/GB300 시스템에만 적용되며, 거기서 auto가 선택해요.

3. 고급 사용법

3.1 추론(reasoning)

Thinking은 체크포인트의 생성 구성에 의해 활성화되며, 생성 명령은 기본적으로 --reasoning-parser auto(GLM-5.3-Flash에서 glm45로 해석)를 켜요. 그러면 OpenAI 호환 API가 thinking을 message.reasoning_content에, 최종 답변을 message.content에 둬요. 원시 응답 형식이 필요한 통합에서는 Playground에서 Reasoning Parser를 비활성화할 수 있어요.

요청에 대해 thinking을 끄려면 요청 본문에 chat_template_kwargs: {"thinking": false}를 전달하세요.

3.2 함수 호출(Tool calling)

생성 명령은 기본적으로 --tool-call-parser auto(GLM-5.3-Flash에서 glm47로 해석)를 켜므로 구조화된 호출이 message.tool_calls로 반환돼요. 함수 호출이 필요 없으면 Playground에서 Tool Call Parser를 비활성화할 수 있어요. follow-up 턴에서는 thinking 모델이 도구 실행 주변에 어떤 필드든 쓸 수 있으므로 reasoning_content와 content를 모두 읽으세요.

3.3 멀티모달 서빙

기본 레시피는 OpenAI 호환 채팅 API를 통해 이미지와 비디오 콘텐츠를 받아요. 다른 샘플링·리사이즈 정책을 측정하지 않았다면 프로세서 기본값을 유지하세요. 비디오 토큰 예산을 초과하는 입력은 거부되지 않고 프로세서의 한도로 잘려요.

3.4 인코더 분리(Encoder disaggregation)

인코더 분리는 비전 전처리를 언어 추론과 분리해요. 검증된 토폴로지는 port 30001의 인코더 전용 TP4 프로세스와 port 30000의 언어 전용 TP4 프로세스가 공유하는 4x GB300 노드 하나를 사용해요. 인코더를 먼저 시작하세요.

인코더 서버 (GB300):

sglang serve \
  --model-path zai-org/GLM-5.3-Flash \
  --tp-size 4 \
  --encoder-only \
  --host 0.0.0.0 \
  --port 30001

언어 서버 (GB300):

sglang serve \
  --model-path zai-org/GLM-5.3-Flash \
  --tp-size 4 \
  --attention-backend dsa \
  --dsa-prefill-backend tilelang \
  --dsa-decode-backend tilelang \
  --linear-attn-backend triton \
  --kv-cache-dtype bfloat16 \
  --quantization fp8 \
  --moe-runner-backend flashinfer_trtllm \
  --max-running-requests 64 \
  --chunked-prefill-size 8192 \
  --max-prefill-tokens 8192 \
  --disable-prefill-cuda-graph \
  --speculative-algorithm EAGLE \
  --speculative-num-steps 3 \
  --speculative-eagle-topk 1 \
  --speculative-num-draft-tokens 4 \
  --language-only \
  --encoder-urls http://localhost:30001 \
  --mem-fraction-static 0.78 \
  --host 0.0.0.0 \
  --port 30000

이 토폴로지는 최대 238,080 시각 토큰까지의 이미지 요청과 비디오를 서빙했어요. 동시 장문 비디오 워크로드에서 관찰된 가장 큰 decode 갭은 통합 서빙의 5.53초에서 인코더 분리를 쓴 1.79초로 줄었어요. 인코더가 비전 워크스페이스 공간을 확보하도록 언어 프로세스에 --mem-fraction-static 0.78을 유지하세요.

비디오용 torchcodec을 설치하고 일반적인 아키텍처·운영 모델은 encoder disaggregation guide를 참고하세요.

3.5 PD 분리(미리보기)

PD는 prefill과 decode를 라우터 뒤의 별도 서버 그룹으로 분리해요. 이 하이브리드 모델에서는 전송이 페이징된 DSA KV와 KDA 순환 상태를 모두 이동해요.

PD 서빙은 더미 가중치로만 기계적으로 검증됐어요 — 시작, 부트스트랩, 상태 전송, 요청 흐름이 4x GB300에서 모두 동작해요. 부하·정확도 테스트는 되지 않았어요. 실제 가중치 게이트가 완료될 때까지 미리보기로 취급하세요.

4x GB300 (단일 노드)에서 PD 서빙:

sglang serve \
  --model-path zai-org/GLM-5.3-Flash \
  --tp-size 2 \
  --dsa-prefill-backend tilelang \
  --dsa-decode-backend tilelang \
  --kv-cache-dtype bfloat16 \
  --moe-runner-backend triton \
  --disaggregation-mode prefill \
  --disaggregation-bootstrap-port 8998 \
  --disaggregation-transfer-backend nixl \
  --host 0.0.0.0 \
  --port 31000

sglang serve \
  --model-path zai-org/GLM-5.3-Flash \
  --tp-size 2 \
  --base-gpu-id 2 \
  --dsa-prefill-backend tilelang \
  --dsa-decode-backend tilelang \
  --kv-cache-dtype bfloat16 \
  --moe-runner-backend triton \
  --disaggregation-mode decode \
  --disaggregation-transfer-backend nixl \
  --host 0.0.0.0 \
  --port 32000

python -m sglang_router.launch_router \
  --pd-disaggregation \
  --mini-lb \
  --prefill http://127.0.0.1:31000 8998 \
  --decode http://127.0.0.1:32000 \
  --host 0.0.0.0 \
  --port 30000

--prefill 뒤의 위치 인자 8998은 prefill 서버의 --disaggregation-bootstrap-port와 같아야 해요.

운영 참고:

두 역할이 한 노드를 공유할 때 각각 별도의 --nccl-port를 부여하세요.
단일 노드 NIXL은 두 서버 환경 모두에 UCX_NET_DEVICES=lo와 UCX_TLS=tcp,cuda_copy,cuda_ipc,self,sm가 필요해요.
검증된 arm은 triton MoE 러너를 사용했어요. 배포 레시피의 flashinfer_trtllm 러너는 PD 아래에서 테스트되지 않았어요.

알려진 제한:

현재 컷에서 PD 아래에서는 추측 디코딩이 시작되지 않아요(prefill 역할에서 draft-graph 캡처 폭 assert, TP2에서 decode 쪽 메모리 압박). PD는 speculative 플래그 없이 실행하세요.
서로 다른 TP 크기의 prefill과 decode는 slice 경로로 상태를 전송하지만 수치 정확도는 검증되지 않았어요. 두 역할을 같은 TP 크기로 유지하세요.

GLM-5.3-Flash

GLM-5.3-Flash

본문

Deployment

Playground

1. 모델 소개

2. 구성 팁

전략 선택

추측 알고리즘 변경

두 메모리 풀 크기 조절

KV와 DSA 백엔드를 짝지어 유지

캐시 계층 확장

멀티모달 메모리

3. 고급 사용법

3.1 추론(reasoning)

3.2 함수 호출(Tool calling)

3.3 멀티모달 서빙

3.4 인코더 분리(Encoder disaggregation)

3.5 PD 분리(미리보기)

더 알아보기 (Learn more)