Qwen3.8-Flash-Next용 비균일 GGUF 양자화 — GSQ와 RCO로 텐서별 정밀도 배분

AI 요약

ISTA-DASLab이 Qwen3.8-Flash-Next를 대상으로 제작한 비균일(non-uniform) GGUF 양자화 모델 3종을 공개했습니다. 이 저장소는 512-expert sparse Mixture-of-Experts(MoE) 모델의 각 텐서에 서로 다른 GGUF 양자화 타입을 배정한 결과물과, 멀티모달 입력을 위한 vision projector(mmproj)를 함께 제공합니다. 모든 파일은 표준 GGUF 형식이며 별도 수정 없이 llama.cpp, Ollama, LM Studio에서 실행할 수 있습니다.

■ 모델 구조와 비균일 양자화

Flash-Next는 48개 레이어마다 512개의 routed expert를 두고, 토큰마다 10개의 expert를 활성화하는 구조입니다. 전체 검색 대상 가중치의 95%가 routed expert 행렬에 집중되어 있으므로, 제한된 크기 예산 안에서 정밀도를 배분하는 검색도 주로 expert 경로에 자원을 사용합니다. 다만 GGUF 형식은 expert별 양자화 타입을 표현할 수 없기 때문에, routed expert는 expert 단위가 아니라 레이어 단위로 하나의 양자화 타입을 배정합니다.

일반적인 uniform quantization은 모든 weight tensor에 같은 양자화 타입을 적용하지만, 이 저장소의 방식은 텐서별 민감도에 따라 서로 다른 타입을 선택합니다. 먼저 GSQ(Gumbel-Softmax Quantization)가 각 텐서를 여러 후보 타입으로 양자화해 데이터베이스를 만들고, RCO(Riemannian Constrained Optimization)가 전체 파일 크기 또는 평균 bit-width 예산을 정확히 지키면서 각 텐서에 최적의 후보 타입을 할당합니다. GSQ는 Gumbel-Softmax relaxation을 사용해 각 좌표의 grid assignment와 group scale을 함께 학습하며, 2~3비트 영역에서 scalar quantization과 vector quantization 사이의 품질 격차를 줄이는 것을 목표로 합니다. RCO는 양자화 타입 선택 문제의 예산 제약을 logit 공간의 매끄러운 Riemannian manifold로 재구성해, 별도의 제약 하이퍼파라미터 조정 없이 task loss를 기준으로 gradient-based optimization을 수행합니다.

■ 공개 파일과 메모리 구성

제공되는 모델은 평균 transformer weight bit-width 기준으로 Q2_0 2.40 bpw, IQ2_XS 2.50 bpw, IQ3_XXS 3.00 bpw입니다. 전체 다운로드 크기는 각각 66.4GB, 68.0GB, 75.8GB입니다. 첫 번째 shard에는 transformer weights가 들어 있으며 Q2_0은 37.6GB, IQ2_XS는 39.2GB, IQ3_XXS는 47.0GB입니다. 두 번째 shard는 세 변형에서 동일한 28.8GB 파일이며, 512억 개 파라미터의 per-layer n-gram embedding table이 IQ4_NL로 저장됩니다.

n-gram table은 행 단위 lookup이며 matrix multiplication weight가 아니므로, 모든 빌드에서 고정된 4.5 bpw로 양자화되고 RCO 검색 대상에서는 제외됩니다. 이 table은 토큰마다 필요한 행만 드문드문 읽기 때문에 SSD에 memory-map한 상태로 둘 수 있습니다. 따라서 전체 모델을 VRAM에 올릴 필요는 없으며, 첫 번째 shard를 VRAM에 상주시킨 뒤 두 번째 shard는 SSD에 두는 구성이 가능합니다. llama.cpp 실행 시 `-lm mmap --lazy-mode on`을 사용하면 n-gram table의 28.8GB를 resident memory에서 제외할 수 있습니다. 다만 KV cache와 멀티모달 사용 시 필요한 0.91GB의 BF16 vision projector를 위한 여유 공간은 별도로 확보해야 합니다.

vision projector 파일인 `mmproj-Qwen3.8-Flash-Next-BF16.gguf`는 0.91GB이며, vision encoder와 projector를 BF16으로 담고 있습니다. 이 파일 하나를 세 양자화 모델이 공유합니다.

■ 속도 측정과 양자화 타입의 차이

속도는 llama.cpp로 11개 범주, 55개 프롬프트를 사용해 측정했습니다. 범주는 coding, humanities, math, QA, RAG, reasoning, STEM, writing, multilingual, summarization, roleplay입니다. Q2_0은 prompt 처리량 367.49 token/s, decode 속도 93.79 token/s, 평균 지연시간 6.70초를 기록했습니다. IQ2_XS는 각각 108.19 token/s, 70.30 token/s, 12.68초였습니다.

두 파일의 크기 차이는 1.6GB에 불과하고 Q2_0이 더 작지만, Q2_0의 prompt throughput은 IQ2_XS보다 3.4배 높고 end-to-end latency는 1.9배 낮았습니다. Q2_0은 lookup table을 크게 사용하는 양자화 형식을 피하기 때문에, 콘텐츠에 따른 decode 속도 변화도 작았습니다. Q2_0의 범주별 decode 속도는 92.5~94.5 token/s로 2.0 token/s 차이에 그쳤지만, IQ2_XS는 49.4~94.5 token/s로 45.1 token/s 차이를 보였습니다. 원문은 이 차이가 모델 크기보다 lookup 기반 양자화 형식의 decoding 비용에서 발생한다고 설명합니다.

프롬프트가 긴 작업에서 Q2_0의 prefill 이점이 특히 컸습니다. RAG에서는 9.6배, writing에서는 6.8배, coding에서는 6.2배의 차이가 측정됐습니다. 반대로 STEM, math, reasoning처럼 짧은 프롬프트와 추론 중심인 범주에서는 prefill 구간이 짧아 decoding 비용의 영향이 커지지 않았으며, Q2_0이 0.8~0.9배 수준으로 비슷하거나 약간 뒤처졌습니다. 따라서 원문은 처리량이 가장 중요할 때 Q2_0을 선택하고, 품질과 크기의 균형에는 IQ3_XXS를 권장합니다.

■ 품질 평가

세 모델은 BF16 base model과 비교됐습니다. 평가는 arc_easy, arc_challenge, hellaswag, winogrande, piqa의 zero-shot 평균, 그리고 AIME25, GPQA-Diamond, LiveCodeBench v6를 사용했습니다. 추론 결과는 주로 xhigh reasoning effort에서 최적화됐으며, 낮은 reasoning-effort 설정에서는 양자화로 인한 품질 저하가 더 커질 수 있다고 명시되어 있습니다.

BF16 기준 모델은 354GB, zero-shot 평균 76.94, AIME25 100.00, GPQA-Diamond 91.92, LiveCodeBench v6 87.43, 세 벤치마크의 task average 93.12를 기록했습니다. Q2_0은 66.4GB에서 zero-shot 평균 78.00, AIME25 96.67, GPQA-Diamond 89.39, LiveCodeBench v6 81.14, task average 89.07입니다. IQ2_XS는 68.0GB에서 각각 77.16, 96.67, 87.37, 83.43, 89.16을 기록합니다. IQ3_XXS는 75.8GB에서 zero-shot 평균 77.23, AIME25 100.00, GPQA-Diamond 91.41, LiveCodeBench v6 86.29, task average 92.57입니다.

IQ3_XXS는 BF16의 354GB에서 75.8GB로 줄어 약 4.7배 작아졌으며, task average는 BF16의 93.12 대비 92.57로 99.4% 수준입니다. AIME25에서는 BF16과 동일한 100.00을 기록했고, GPQA-Diamond는 0.51점, LiveCodeBench v6는 1.14점 낮았습니다. Q2_0과 IQ2_XS는 task average에서 각각 89.07과 89.16으로 0.1점 이내였지만, Q2_0은 GPQA-Diamond에서 더 높고 IQ2_XS는 LiveCodeBench v6에서 더 높았습니다. 세 모델의 zero-shot 평균이 BF16을 소폭 넘었지만, 원문은 이 차이가 대략 한 표준오차 안에 있으므로 개선이라기보다 parity로 해석해야 한다고 설명합니다.

■ 실행 방법과 재현 가능한 구성

예를 들어 IQ3_XXS를 다운로드하려면 `huggingface_hub` CLI를 설치한 뒤 `hf download <this-repo> --include "IQ3_XXS/*" --local-dir .`를 실행합니다. 이후 `llama-cli`에서 첫 번째 shard를 모델 경로로 지정하고 `-lm mmap --lazy-mode on -ngl 99`를 사용하면 두 번째 shard가 자동으로 연결되면서 n-gram table을 디스크에 memory-map할 수 있습니다. 멀티모달 실행에서는 `llama-mtmd-cli`에 BF16 mmproj 파일을 `--mmproj`로 지정하고 이미지 경로를 `--image`로 전달합니다. Ollama에서는 저장소 이름을 검색한 뒤 메모리 예산에 맞는 GSQ-RCO 빌드를 선택할 수 있습니다.

검색 과정은 352개 텐서를 대상으로 합니다. 여기에는 attention, SSM projection, shared expert, embedding, output head에 해당하는 304개 dense tensor와 레이어별로 합쳐진 48개 routed-expert matrix가 포함됩니다. routed expert와 dense path는 동일한 예산에서도 사용하는 양자화 사다리가 다릅니다. `ffn_down_exps`는 640개 행이 block-256 K/I 형식의 조건을 만족하지 못하기 때문에 검색에서 제외되고 Q2_0으로 고정됩니다. 각 GGUF에는 `tensor-allocation/<model>.rco-allocation.txt`가 포함되어 있어 텐서별 양자화 타입 배정, quant-type histogram, 목표 bit-width를 확인할 수 있습니다. GSQ와 RCO의 구현 및 관련 논문도 각각 IST-DASLab/GSQ와 IST-DASLab/RCO에서 공개하고 있습니다.

원문: Hugging Face / 번역·요약: Trawling