2x CMP 170HX 64GB 환경에서 GLM-5.3-Flash (384K 컨텍스트) 성능 비교: ExL3 및 HBM 우선 설정 +

저는 오랫동안 두 개의 64GB CMP 170HX 카드에 걸쳐 GLM-5.3-Flash를 만져왔고, 이제 이 설정이 충분히 안정화되어 공유하고자 합니다. 또한 같은 장비에서 사용하고 있는 Qwen3.8-Flash-Next 설정과 비교해 보았습니다. vLLM을 사용하여 AWQ INT4 + FP8 PLE로 구동했습니다. PP/TG 벤치마크 외에도, 두 모델 모두 DSH에 연결하여 동일한 소규모 코딩/에이전트 작업을 수행하게 하여 순수 추론 속도가 실제 작업 완료 시간에 어떻게 반영되는지 확인해 보았습니다. 몇 가지 주의사항을 먼저 말씀드립니다: 이것은 사과와 사과를 비교하는 양자화(quant) 비교가 아닙니다. GLM과 Qwen은 서로 다른 엔진과 다른 추측 디코딩(speculative decoding) 설정을 사용합니다. 추측 디코드 속도는 수용률(acceptance rate)과 생성된 텍스트에 크게 좌우됩니다. 코딩 작업들은 심각한 벤치마크 스위트가 아니라 몇 가지 실질적인 예시일 뿐입니다. 아래에서 'Strata-style'을 언급할 때, 제가 의미하는 것은 이전에 Strata와 함께 사용했던 HBM 우선/전체 레지던시(full-residency) 접근 방식이며, 실제로 Strata를 구동한다는 의미는 아닙니다.

Repo 및 플레이 가능한 데모:
GitHub: https://github.com/Flun/glm53-flash-cmp170hx-exl3

하드웨어 사양:
CPU Ryzen 5 5600X
RAM 80GB DDR4
GPU 2x CMP 170HX 64GB
GPU 아키텍처 SM80 PCIe Gen2 x8
GPU P2P 사용 불가
OS Ubuntu 24.04

두 모델 모두 동일한 장비에서 테스트되었습니다. 에이전트 테스트에는 DSH를 하네스로 사용했습니다.

GLM-5.3-Flash 설정:
대상 모델: turboderp/GLM-5.3-Flash-exl3
엔진: ExLlamaV3 1.5.4
현재 설정: GLM-5.3-Flash EXL3 3.05bpw ~125.2GB / 116.6GiB (대상 가중치)
대상 가중치는 두 개의 64GB 카드 전체에 상주(fully resident)합니다.
k_hcfuse DFlash2 EXL3 6bpw DFlash2 K7 Q8
KV 캐시 384K 컨텍스트 (실제 사용 시 최대 요청 예산은 약 392,960 토큰)
GLM-5.3-Flash 자체는 총 320B / 활성 18B의 MoE 모델입니다. 여기서 중요한 부분은 대상 가중치가 HBM에 상주한다는 것입니다. 디코드 과정 중 시스템 RAM에서 전문가(experts)를 지속적으로 스트리밍하지 않습니다.

3.05bpw 품질에 대하여
이것이 아마 제가 가장 신경 쓴 부분이었습니다. 언뜻 보기에는 '3.05bpw'가 매우 공격적인 양자화처럼 들립니다. 특히 사람들이 흔히 사용하는 UD Q4 변형과 비교했을 때 더욱 그렇습니다.

하지만 EXL3는 단순히 '모든 텐서를 3비트로 만드는' 방식이 아닙니다. 이는 트렐리스 기반 양자화(trellis-based quantization) 방식을 사용하며, 텐서마다 다른 비트 할당을 적용합니다. 3.05bpw라는 수치는 평균 목표 비트 전송률(average target bitrate)입니다. 이 계열에 대해 발표된 양자화 설정들은 또한 더 민감한 부분들을 더 높은 정밀도로 유지합니다. 예를 들어, lm_head는 3.05bpw 분기에서도 6비트를 유지합니다. 같은 모델 계열을 살펴보면, 4.05bpw 빌드는 대략 다음과 같은 방식으로 검사되었습니다: 라우팅된 전문가(routed experts): K4, 어텐션(attention): K6, 공유 전문가(shared experts): K6, 밀집 MLP(dense MLP): K5, lm_head: K6, 임베딩/정규화/라우터(embedding / norms / router): 네이티브 따라서 일반적인 아이디어는 거대한 라우팅된 전문가 부분을 더 공격적으로 압축하는 동시에, 작거나 더 민감한 경로에 더 많은 비트를 할당하는 것입니다. 이는 저장 공간의 대부분이 전문가 가중치(expert weights)에 있는 MoE와 같은 모델에게 상당히 타당합니다. 일반적인 UD 양자화 방식과의 대략적인 비교는 다음과 같습니다.

참고로, 공개된 GLM-5.3-Flash GGUF 충실도 수치는 대략 다음과 같습니다: 주목할 만한 점은 Q4_K_XL이라는 것이 문자 그대로 '전체 모델에 걸친 파라미터당 4비트'를 의미하지 않는다는 것입니다. 320B 모델의 경우 약 200GB에서, 이는 4bpw보다 훨씬 높은 유효 평균 비트 전송률을 가진 혼합 정밀도 양자화(mixed-precision quant)입니다. 또한 발표된 GLM-5.3-Flash EXL3 3.0bpw 충실도 테스트는 51,175개의 보류된 다음 토큰 위치를 사용하여 다음과 같은 결과를 보고했습니다: Top-1 agreement: ~93.0%, Mean KLD: ~0.0505 수치적으로 이는 발표된 UD-Q4_K_XL 결과와 대략 비슷한 영역에 있습니다. 그렇다고 해서 저는 이 수치만으로

이들은 정확히 동일한 평가 파이프라인/코퍼스로 측정된 것이 아니며, 공개된 3.0bpw 아티팩트 역시 제가 구동하는 양자화(quant)와는 다릅니다. 제가 얻은 결론은 단순히 3bpw급 EXL3가 크기에 비해 놀라울 정도로 많은 충실도(fidelity)를 유지할 수 있으며, 단순한 3비트 양자화처럼 작동하지 않는다는 것입니다. 제 사용 사례에서는 목표치를 ~116.6GiB로 낮추면서도 여전히 활용 가능한 코딩/에이전트 품질을 유지하는 것이 이 설정이 흥미로운 주된 이유였습니다. DFlash2 6bpw는 단지 초안 작성기(drafter)일 뿐입니다. 혼동을 피하기 위해 말씀드리자면: 3.05bpw 모델이 실제 GLM 목표치(target)입니다. 6bpw DFlash2 모델은 오직 추측성 초안 작성기(speculative drafter)입니다. 초안 작성기는 토큰을 제안하고, GLM 목표치가 이를 검증합니다. 따라서 이것은 어떤 종류의 “3.05bpw + 6bpw 평균 품질” 설정이 아닙니다. 초안 양자화는 주로 초안 속도, VRAM 사용량 및 수용 효율성에 영향을 미칩니다.

HBM 우선 / “Strata 스타일” 부분
여기에 저는 이전에 사용했던 Strata 설정에서 아이디어를 가져왔습니다. 다시 말하지만, 이것은 Strata를 구동하는 것은 아닙니다. 제가 말하는 “Strata 스타일”이란 단순히 가능한 한 많은 모델을 HBM에 영구적으로 상주시키고 런타임 CPU↔GPU 가중치 트래픽을 피한다는 의미입니다.

GLM 목표치 자체는 두 카드에 걸쳐 적합하므로, 저는 목표치를 완전히 상주시킵니다. 전문가(experts)를 오프로드하는 대신, 컨텍스트에 따라 확장되는 부분, 즉 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(Sliding Window Attention) 창과 GPU 링 캐시를 사용하도록 변경했습니다.

대상은 여전히 전체 384K 컨텍스트를 보고 전체 대상 KV를 유지합니다. 드래프터의 KV 저장소만 제한된 링 안에 보관됩니다. 이것이 현재 설정(DFlash2 K7 + Q8 KV + 전체 대상 길이까지 드래프트 캐시를 늘리지 않고 384K 대상 컨텍스트)으로 구동할 수 있게 합니다. 구현 및 검증 테스트는 레포지토리에서 확인할 수 있습니다. 또한 콜드 스타트 시간도 측정했습니다. API가 실제로 준비될 때까지의 콜드 컴파일/스타트 시간이 다음과 같습니다.

모델 준비 시간 (Model Ready time)
GLM-5.3-Flash EXL3: ~1분 04초
Qwen3.8 Flash Next / vLLM: ~3분 50초

이것은 실제로 모델 크기 비교가 아닙니다. Qwen vLLM 설정에는 시작 작업(startup work)이 상당히 많습니다. PP 워커 분산 실행 시간, 모델 배치, MTP PLE GDN Triton 컴파일, 메모리 프로파일링, KV 할당 등이 포함됩니다. ExLlamaV3 GLM 경로는 비교적 정적입니다.

추론 벤치마크 (Inference benchmarks)
다음은 제 대시보드 워크로드에서 얻은 수치들입니다. 다시 말씀드리지만, 특히 추측 디코드(speculative decode)의 경우 이를 보편적인 모델 속도로 간주해서는 안 됩니다. 수용률(Acceptance rate)과 생성된 텍스트가 매우 중요합니다.

GLM-5.3-Flash / DFlash2 K7 / Q8 (입력, PP, 디코드)
8K: 1,529 tok/s | 95.6 tok/s | 40K: 1,624 | 90.7 | 73K: 1,647 | 90.6 | 106K: 1,650 | 91.0 | 131K: 1,611 | 94.4 | 385K: 1,535 | 90.1
DFlash가 이 특정 워크로드에서 수용된 비율은 주로 약 87%였습니다. 이전 MTP d2 경로를 사용했을 때는 같은 대시보드 워크로드가 일반적으로 ~60 tok/s 범위에 머물렀습니다. DFlash2 K7로 전환하면서 여기서는 약 ~90 tok/s까지 끌어올렸습니다.

Qwen3.8 Flash Next / vLLM (입력, PP, 디코드)
Qwen 설정은 AWQ INT4 + FP8 PLE / PP2 / MTP3입니다. 8K: 5,513 tok/s | 129.5 tok/s | 40K: 5,628 | 123.6 | 73K: 5,466 | 141.9 | 106K: 5,307 | 141.5 | 131K: 5,183 | 159.9 | 252K: 4,706 | 149.4

따라서 순수 처리량(raw 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를 프리필링(Prefilling)하는 것만으로도 이미 약 4분이 걸립니다.

만약 제가 1M을 구현할 수 있다 하더라도, 이 속도로 전체 1M의 콜드 프리필(cold prefill)을 수행하는 것은 일반적인 사용에는 그다지 매력적이지 않습니다. 그래서 현재는 서비스에서 384K Q8로 설정하고 있습니다. 결국 1M이 작동하는 것을 보고 싶지만, 주로 기술적인 연습 목적입니다. 작은 에이전트 테스트
원래는 두 모델 모두 테트리스 게임을 만들게 하고 거기서 끝낼 생각이었습니다. 둘 다 DSH에 연결되어 동일한 요청을 받았습니다.

1. 테트리스 프롬프트: 웹용 플레이 가능한 테트리스 게임을 구축하세요. 모델 완료 시간 GLM-5.3 4분 40초 Qwen3.8 5분 30초
   둘 다 작동하는 버전을 만들었지만, 솔직히 그 차이가 그다지 극적이지 않아 흥미롭지 않았습니다. 그래서 작업을 두 가지 더 추가했습니다.
   https://reddit.com/link/1x0b1ws/video/1sn8netal4uh1/player
2. AI 미니 PC 랜딩 페이지
   두 모델에 제공된 정확한 프롬프트: 외부 라이브러리를 사용하지 않고, 다크 테마의 사양, 성능 차트, 가격 책정, FAQ 및 부드러운 스크롤 애니메이션이 포함된 AI 미니 PC용 세련된 단일 파일 HTML 랜딩 페이지를 구축하세요. 모델 완료 시간 GLM-5.3 10분 05초 Qwen3.8 14분 40초
   https://reddit.com/link/1x0b1ws/video/pdglw7kbl4uh1/player
   3.뱀파이어 서바이버스 스타일 게임
   정확한 프롬프트: 외부 라이브러리를 사용하지 않고, WASD 이동, 자동 공격, 적 웨이브, XP, 3가지 선택 레벨업 업그레이드, HP, 게임 오버 및 재시작 기능이 포함된 단일 파일 HTML 뱀파이어 서바이버스 스타일 게임을 구축하세요. 모델 완료 시간 GLM-5.3 4분 40초 Qwen3.8 24분 10초
   이것은 예상했던 것보다 훨씬 큰 차이를 보였습니다. 한 가지 명백한 주의사항이 있습니다. Qwen 버전은 사운드를 추가했지만, GLM 버전은 그렇지 않았습니다. 프롬프트에서 사운드를 요청하지 않았기 때문에, 나중에 GLM에게 그것을 추가해달라고 다시 요청하지 않았습니다. 두 실행 모두 동일한 원샷(one-shot) 프롬프트의 결과로 남기고 싶었습니다.
   https://reddit.com/link/1x0b1ws/video/4hl6g2bcl4uh1/player
   작업 완료 시간표
   작업 GLM-5.3 Qwen3.8
   테트리스 4분 40초 5분 30초
   랜딩 페이지 10분 05초 14분 40초
   뱀파이어 스타일 게임 4분 40초 24분 10초
   이 세 가지 예시만으로 너무 많은 것을 읽지는 않으셨으면 합니다. 이것은 GLM이 코딩에

흥미로운 점은 단순히 raw tok/s와 end-to-end 에이전트 완료 시간이 서로 잘 연관되지 않는다는 것입니다. Qwen이 훨씬 높은 PP 및 디코드 처리량을 가지고 있지만, 이 특정 작업에서는 GLM이 더 빨리 끝내는 경우가 많았습니다. 에이전트 작업의 경우 계획 수립(planning), 재시도 횟수(number of retries), 파일 재읽기(file rereads), 수정(edits), 그리고 첫 번째 구현체가 작동하는 것과 얼마나 가까운지 등 모든 것이 중요합니다. 따라서 저는 raw 추론 속도와 실제 작업 완료 시간을 별도로 살펴볼 가치가 있다고 생각합니다. 현재 상태: 제가 사용하고 있는 GLM 서비스는 다음과 같습니다: GLM-5.3-Flash EXL3 3.05bpw DFlash2 EXL3 6bpw K7 Q8 KV 384K 컨텍스트** 이 구성에서 마음에 드는 가장 큰 점은 메모리/품질 트레이드오프입니다. 목표 모델이 ~116.6GiB의 HBM에 들어맞고, 상주하며, 공개된 3bpw급 EXL3 충실도 결과는 양자화(quant)가 비트레이트만으로 예상했던 것보다 훨씬 잘 유지되고 있음을 시사합니다. 실행 시간 측면은 기본적으로 HBM 우선 설정입니다: 목표 가중치(target weights)를 상주 상태로 유지하고, 디코드 과정에서 전문가들(experts)을 왔다 갔다 이동시키는 대신 drafter/KV 측에서 메모리를 절약하는 방식입니다. 전체 구성, 변환 스크립트, 링 캐시 변경 사항, 벤치마크 코드 및 원본 결과는 여기에 있습니다: GitHub: https://github.com/Flun/glm53-flash-cmp170hx-exl3 만약 다른 특이한 128GB급 GPU 환경에서 GLM-5.3-Flash를 실행하고 있는 분이 있다면, 어떤 수치를 얻고 계신지 보고 싶습니다. 다음에 시도해보고 싶은 것은 1M 컨텍스트인데, 그 지점에서는 프리필 시간(prefill time) 자체가 단순히 모델을 맞추는 것보다 더 큰 문제가 될 가능성이 높습니다.