CMP 170HX 64GB 2개: GLM-5.3-Flash 384K 컨텍스트 / ~90 tok/s (EXL3, HBM 우선 설정) 및 Qwen3.8 비교

k_hcfuse

GLM-5.3-Flash는 총 320B / 활성 파라미터 약 18B인 MoE 모델임.

여기서 중요한 건 타겟 가중치가 HBM에 계속 상주한다는 거다. 디코딩하는 동안 시스템 RAM에서 전문가(expert) 데이터를 계속 불러오는 방식이 아님.

3.05bpw 품질에 대하여

이 부분이 제일 신경 쓰였던 부분임.

처음 보면 “3.05bpw”는 사람들이 흔히 쓰는 UD Q4 변형판들에 비해 꽤 빡센 양자화처럼 들릴 거다.

근데 EXL3는 그냥 “모든 텐서를 3비트로 깎는” 방식이 아님.

텐서마다 비트 할당을 다르게 하는 트렐리스(trellis) 기반 양자화 방식을 쓴다. 3.05bpw라는 숫자는 평균 타겟 비트레이트일 뿐임.

이 모델군에 공개된 양자화 설정들을 보면 민감한 부분은 더 높은 정밀도로 유지한다. 예를 들어, 3.05bpw 브랜치에서도 lm_head는 6비트로 유지됨.

같은 모델군에서 4.05bpw 빌드를 살펴보면 대략 이런 식임:

• 라우팅 전문가(routed experts): K4

• 어텐션(attention): K6

• 공유 전문가(shared experts): K6

• 밀집 MLP(dense MLP): K5

• lm_head: K6

• 임베딩 / 노름(norms) / 라우터: 네이티브

그러니까 핵심은 용량 대부분을 차지하는 라우팅 전문가 부분을 빡세게 압축하고, 작지만 민감한 경로에는 비트를 더 투자하는 거다.

이런 MoE 모델 구조상 아주 합리적인 방식임. 왜냐하면 저장 공간 대부분이 전문가 가중치에 몰려 있으니까.

일반적인 UD 양자화와의 대략적인 비교

참고로, 공개된 GLM-5.3-Flash GGUF 충실도 수치는 대략 이럼:

한 가지 짚고 넘어갈 건 Q4_K_XL 같은 이름이 붙었다고 해서 모델 전체가 “파라미터당 4비트”라는 뜻은 아니라는 거다.

320B 모델 기준으로 약 200GB 정도면, 실제 평균 비트레이트가 4bpw보다 훨씬 높은 혼합 정밀도 양자화임.

51,175개의 검증용 다음 토큰 위치를 사용한 GLM-5.3-Flash EXL3 3.0bpw 충실도 테스트 결과도 있는데:

• Top-1 일치율: ~93.0%

• 평균 KLD: ~0.0505

수치상으로는 공개된 UD-Q4_K_XL 결과와 거의 비슷한 수준임.

그렇다고 해서 이 수치만 보고 “EXL3 3bpw가 UD-Q4_K_XL보다 낫다”고 단정 짓지는 않겠음.

정확히 같은 평가 파이프라인이나 말뭉치로 잰 것도 아니고, 공개된 3.0bpw 아티팩트가 내가 돌리는 거랑 완전히 같은 양자화 버전도 아니니까.

내 결론은 그냥 3bpw급 EXL3가 덩치에 비해 충실도를 놀라울 정도로 잘 보존한다는 거임. 그냥 멍청하게 3비트로 깎아버린 거랑은 차원이 다르다.

내 사용 사례에서는 코딩/에이전트 품질을 유지하면서 타겟 모델을 ~116.6GiB까지 줄이는 게 이 설정을 흥미롭게 만든 주된 이유였어.

DFlash2 6bpw는 드래프터일 뿐이야

혼동하지 말라고 미리 말해두는데:

3.05bpw 모델이 실제 GLM 타겟이야.

6bpw DFlash2 모델은 추론용 드래프터일 뿐이지.

드래프터가 토큰을 제안하면 GLM 타겟이 검증하는 방식이야.

그러니까 이건 "3.05bpw + 6bpw의 평균 품질" 같은 설정이 아니라고.

드래프트 양자화는 주로 드래프트 속도, VRAM 사용량, 그리고 수락 효율에 영향을 줘.

HBM 우선 / "Strata 스타일" 파트

이 부분은 예전에 썼던 Strata 설정에서 아이디어를 좀 빌려왔어.

다시 말하지만, 이건 Strata를 돌리는 게 아니야.

"Strata 스타일"이라는 건 그냥 이런 뜻이야:

모델을 최대한 HBM에 상주시키고, 런타임 중에 CPU↔GPU 사이에서 가중치가 왔다 갔다 하는 걸 피한다.

GLM 타겟 자체가 카드 두 장에 딱 들어가니까, 타겟은 그냥 통째로 상주시켜 놨어.

전문가(expert) 모델을 오프로딩하는 대신, 컨텍스트에 따라 늘어나는 부분인 KV 캐시와 추론용 드래프터가 먹는 메모리를 줄이는 데 집중했지.

이 특정 머신에서는 PCIe로 가중치를 계속 옮기는 것보다 이게 훨씬 합리적이었거든.

DFlash2 + 384K 컨텍스트

원래는 GLM의 MTP d2 경로를 썼었어.

나중에 DFlash2로 갈아탔지.

기존 BF16 incoai/GLM-5.3-Flash-DFlash2 드래프터를 그대로 쓰는 대신, ExLlamaV3 호환 EXL3 6bpw 빌드로 변환했어.

그렇게 나온 드래프트 가중치 용량은 약 0.96GiB야.

긴 컨텍스트에서 더 큰 문제는 사실 드래프트 KV 캐시였어.

타겟이 384K로 돌아가는데 드래프터도 384K KV 캐시를 키우면 VRAM이 순식간에 증발해 버리거든.

그래서 드래프터 쪽은 고정 SWA 윈도우에 GPU 링 캐시를 쓰도록 바꿨어.

타겟은 여전히 전체 384K 컨텍스트를 다 보고 전체 타겟 KV를 유지해.

드래프터의 KV 저장소만 제한된 링 안에 가둬두는 거지.

그 덕분에 지금 설정이 돌아가는 거야:

DFlash2 K7 + Q8 KV + 384K 타겟 컨텍스트

드래프트 캐시를 타겟 전체 길이까지 키우지 않고도 말이지.

구현이랑 검증 테스트는 저장소에 다 올려놨어.

콜드 스타트

API가 실제로 준비될 때까지 콜드 컴파일/시작 시간도 측정해 봤어.

이건 모델 크기 비교라고 보긴 좀 그래.

Qwen vLLM 설정은 시작할 때 할 일이 훨씬 많거든:

• PP 워커

• 분산 런타임

• 모델 배치

• MTP

• PLE

• GDN

• Triton 컴파일

• 메모리 프로파일링

• KV 할당

ExLlamaV3 GLM 경로는 상대적으로 정적이라서 그래.

추론 벤치마크

이건 내 대시보드 워크로드에서 나온 수치들이야.

다시 말하지만, 특히 추론용 디코딩은 이걸 범용적인 모델 속도로 생각하면 안 돼.

수락률이랑 생성된 텍스트 내용이 엄청 중요하거든.

GLM-5.3-Flash / DFlash2 K7 / Q8

이 특정 워크로드에서 DFlash 수락률은 대략 87% 정도였어.

예전 MTP d2 경로를 썼을 때는 같은 대시보드 워크로드에서 보통 ~60 tok/s 정도 나왔거든.

DFlash2 K7으로 바꾸니까 여기선 ~90 tok/s까지 올라갔어.

Qwen3.8 Flash Next / vLLM

Qwen 설정은 이거야:

AWQ INT4 + FP8 PLE / PP2 / MTP3

그러니까 순수 처리량(throughput)만 보면 Qwen이 확실히 빨라.

대략 131K일 때:

• PP: ~5.18K vs ~1.61K

• 디코딩: ~160 vs ~94 tok/s

이건 반박의 여지가 없지.

나한테 흥미로웠던 건 두 모델 다 멀티 스텝 코딩 작업을 시켰을 때 어떤 일이 벌어지느냐였어.

일단 384K에서 멈춘 이유

대략 385K 입력을 테스트해 봤는데 PP는 여전히 1.5K tok/s 정도 나오더라고.

문제는 PP가 무너지는 게 아니었어.

그냥 벽시계 시간(wall-clock time)이 문제였지.

~385K를 처음부터 프리필(prefill)하는 데만 벌써 4분이 걸려.

1M까지 맞출 수 있다 쳐도, 이 속도로 1M 콜드 프리필을 다 하는 건 실사용하기엔 좀 별로잖아.

그래서 지금은 서비스를 384K Q8로 두고 있어.

나중에 기술적인 연습 삼아서라도 1M이 돌아가는지 확인은 해보고 싶네.

소규모 에이전트 테스트

원래는 두 모델 다 테트리스나 만들게 하고 끝내려고 했어.

둘 다 DSH에 연결해서 똑같은 요청을 보냈지.

1. 테트리스

프롬프트:

웹에서 플레이 가능한 테트리스 게임을 만들어줘.

둘 다 작동하는 버전을 뽑아냈고, 솔직히 말해서 차이가 그렇게 드라마틱하게 흥미롭진 않았음.

그래서 과제 두 개를 더 추가해 봤다.

.buffering-track-fill { stroke-dasharray: 100; stroke-dashoffset: 50; }

2. AI 미니 PC 랜딩 페이지

둘 다한테 똑같이 던진 프롬프트:

외부 라이브러리 쓰지 말고, 다크 테마에 스펙, 성능 차트, 가격, FAQ, 부드러운 스크롤 애니메이션이 포함된 AI 미니 PC용 깔끔한 단일 파일 HTML 랜딩 페이지를 만들어줘.

.buffering-track-fill { stroke-dasharray: 100; stroke-dashoffset: 50; }

3. 뱀파이어 서바이버 스타일 게임

똑같은 프롬프트:

외부 라이브러리 쓰지 말고, WASD 이동, 자동 공격, 적 웨이브, 경험치, 3지선다 레벨업 업그레이드, 체력, 게임 오버, 재시작 기능이 있는 뱀파이어 서바이버 스타일의 단일 파일 HTML 게임을 만들어줘.

이건 생각보다 차이가 훨씬 컸음.

한 가지 분명한 주의사항이 있는데:

Qwen 버전은 사운드를 넣었는데 GLM은 안 넣었다는 거임.

프롬프트에 사운드 넣으란 말은 없었으니까, 나중에 GLM한테 추가하라고 다시 시키진 않았음. 그냥 둘 다 똑같은 원샷 프롬프트 결과물로 남겨두고 싶었거든.

.buffering-track-fill { stroke-dasharray: 100; stroke-dashoffset: 50; }

과제 완료 시간

이 예시 세 개만 보고 너무 의미 부여하진 마라.

이게 GLM이 "코딩을 5배 더 잘한다"는 식의 증거는 절대 아님.

내가 흥미로웠던 건 그냥 순수 토큰 속도(tok/s)랑 에이전트가 끝까지 완료하는 시간은 서로 딱 맞아떨어지지 않는다는 점임.

Qwen이 PP랑 디코드 처리량은 훨씬 높은데, 이런 특정 과제들에서는 GLM이 더 빨리 끝내는 경우가 많았거든.

에이전트 작업에서는 계획 짜기, 재시도 횟수, 파일 다시 읽기, 수정, 그리고 첫 번째 구현물이 얼마나 완성도 있게 나오느냐가 다 중요하니까.

그래서 난 순수 추론 속도랑 실제 과제 완료 시간은 따로 떼어놓고 보는 게 맞다고 봄.

현재 상태

지금 내가 쓰고 있는 GLM 서비스는 이거임:

GLM-5.3-Flash EXL3 3.05bpw

• DFlash2 EXL3 6bpw K7

• Q8 KV

• 384K context**

이 구성에서 제일 맘에 드는 건 메모리랑 품질 사이의 타협점임.

목표치가 HBM 약 116.6GiB 안에 딱 들어가서 상주하고, 공개된 3bpw급 EXL3 충실도 결과를 보면 비트레이트만 보고 예상했던 것보다 양자화가 훨씬 잘 버티고 있음.

런타임 쪽은 기본적으로 HBM 우선 세팅임: 타겟 가중치를 상주시키고, 디코드 중에 전문가 모델을 이리저리 옮기는 대신 드래프터(drafter)/KV 쪽에서 메모리를 아끼는 방식이지.

전체 설정, 변환 스크립트, 링 캐시 변경 사항, 벤치마크 코드랑 원본 결과는 여기 있음:

GitHub:
https://github.com/Flun/glm53-flash-cmp170hx-exl3

혹시 다른 이상한 128GB급 GPU 세팅에서 GLM-5.3-Flash 돌리고 있는 사람 있으면, 어떤 수치 나오는지 좀 알려주라. 궁금하네.

다음엔 1M 컨텍스트를 시도해 볼 생각인데, 그쯤 되면 그냥 메모리에 올리는 것보다 프리필(prefill) 시간이 더 큰 문제가 될 것 같긴 함.