Quantization on ICE-ICE-BEAR-BLOG

DGX Spark에서 Qwen3.5-122B를 28.3에서 51 tok/s로 끌어올린 추론 최적화 레시피

Thu, 07 May 2026 00:00:00 +0900

개요

albond/DGX_Spark_Qwen3.5-122B-A10B-AR-INT4는 NVIDIA DGX Spark 단일 박스에서 Qwen3.5-122B-A10B를 28.3에서 51 tok/s까지 80퍼센트 끌어올린 레시피다. INT4 양자화, FP8 dense layer hybrid, MTP-2 speculative decoding, INT8 LM head, TurboQuant KV cache까지 다섯 가지 기법을 차례로 쌓았고 256K context도 유지된다. Apache 2.0, GitHub 별 171개. “단일 워크스테이션에서 100B급 MoE 모델을 production 수준으로 돌릴 수 있는가” 라는 질문에 대한 강한 긍정 답이다.

flowchart LR
 Base["Baseline <br/> 28.3 tok/s"] --> S1["+ Hybrid INT4+FP8 <br/> 30.8 tok/s"]
 S1 --> S2["+ MTP-2 Speculative <br/> 38.4 tok/s"]
 S2 --> V2["v2: + INT8 LM Head <br/> 51 tok/s"]
 V2 --> TQ["v2-tq: + TurboQuant KV <br/> 39 tok/s <br/> 1.4M KV"]

결과 표

구성	tok/s	향상	빌드
Baseline (vLLM 0.19 + AutoRound INT4 + FlashInfer)	28.3	—	—
+ Hybrid INT4+FP8 dense layers	30.8	+8.8%	step 1
+ MTP-2 Speculative Decoding	38.4	+35.7%	step 2
v2 (+ INT8 LM Head v2)	51	+80%	`Dockerfile.v2`
v2-tq (+ TurboQuant KV Cache)	39	+38%	`Dockerfile.v2-tq`

같은 최적화로 Qwen3.5-35B-A3B (작은 형제) 는 112 tok/s까지 올라간다.

256K Context

설정	KV Cache	256K 동시 사용자
v2 (standard)	355K tokens	1
v2-tq (TurboQuant)	1.4M tokens	5

모델 한 줄

Qwen3.5-122B-A10B는 122B 총 파라미터 중 10B만 활성화하는 hybrid MoE다. 256개 expert 중 8 routed + 1 shared, Gated DeltaNet과 Gated Attention이 12:1 비율로 교차하는 48 레이어 구조에 native 262K context (YaRN 확장 시 1M)까지 지원한다. Apache 2.0. 이 모델을 Intel AutoRound로 INT4 양자화한 Intel/Qwen3.5-122B-A10B-int4-AutoRound (group size 128, shared_expert는 ignore) 가 출발점이다.

핵심 기법

1. Hybrid INT4 + FP8 Dense Layers (+9%)

AutoRound INT4 모델의 BF16 shared expert weights를 official Qwen 체크포인트의 FP8 weights로 교체한다. 즉 expert 레이어만 INT4, dense는 FP8. 정확도를 보존하면서 메모리와 연산량을 동시에 줄인다.

2. MTP-2 Speculative Decoding (+36%)

Multi-Token Prediction 방식으로 한 번에 2 토큰을 예측한다. accept rate가 약 80퍼센트로 매우 높아 디코드 throughput이 가장 크게 점프하는 단계다. 작은 draft 모델을 따로 돌리지 않고 메인 모델 자체가 multi-head 예측을 한다는 점이 주목할 만하다.

3. INT8 LM Head v2 (Triton 커널)

LM head, 즉 최종 token vocabulary projection 레이어를 INT8로 양자화한다. Triton 커스텀 커널로 구현되며 v2 빌드에서 가장 큰 점프 (38.4 → 51 tok/s) 를 만든다. LM head는 보통 양자화 대상에서 빠지지만 vocabulary가 큰 모델일수록 영향력이 크다는 게 다시 확인됐다.

4. TurboQuant KV Cache (선택)

TurboQuant로 KV cache를 4배 압축한다. 절대 throughput은 v2 대비 약간 떨어지지만 256K context 동시 사용자가 1명에서 5명으로 늘어난다. Long-context multi-tenant 시나리오에서 의미 있는 트레이드오프다.

환경

vLLM 0.19.1, CUDA 13.0, Docker 기반
추론 엔진: vLLM 0.19 + FlashInfer
모델: Intel/Qwen3.5-122B-A10B-int4-AutoRound
./install.sh 한 번으로 Step 0~4 자동 (idempotent)

인사이트

100B급 모델을 단일 워크스테이션에서 51 tok/s로 돌린다는 건 production 응답 속도 (60 tok/s 근처) 에 거의 닿았다는 뜻이다. 별 171개 짜리 레시피 치고는 짜임새가 단단해서 벤치 표, 단계별 Docker, install.sh, vLLM/CUDA 버전 호환성까지 모두 갖췄고 그대로 따라 돌릴 수 있다. 흥미로운 건 다섯 기법이 직교한다는 점이다. Hybrid quant은 메모리/정확도, MTP는 디코딩 병렬성, INT8 LM head는 컴퓨트, TurboQuant은 KV 메모리를 각각 친다. 한 곳을 짠 게 아니라 병목을 차례로 옮기면서 합산한 결과가 80퍼센트다. 그리고 v2-tq에서 보이듯 throughput과 동시 사용자 수는 다른 축이라 워크로드에 따라 다른 빌드를 골라야 한다. 다음 분기쯤이면 이런 hybrid quant + speculative + custom kernel 스택이 vLLM/SGLang에 표준으로 들어올 가능성이 높고, “100B 모델을 한 박스에서” 가 점점 demo가 아니라 default로 바뀐다.

참고

Repo and model cards

albond/DGX_Spark_Qwen3.5-122B-A10B-AR-INT4 — 별 171, Apache 2.0
Qwen/Qwen3.5-122B-A10B — 122B/10B hybrid MoE, 262K context
Intel/Qwen3.5-122B-A10B-int4-AutoRound — INT4 group128 quantized
NVIDIA DGX Spark

Inference frameworks

Optimization techniques

Simon Willison의 Granite 4.1 3B 펠리컨 갤러리 — 양자화 21종이 똑같이 망한 이유

Mon, 04 May 2026 00:00:00 +0900

개요

Simon Willison이 IBM Granite 4.1 3B 양자화 21종(1.2GB ~ 6.34GB, 합계 51.3GB)에 자기 시그니처 프롬프트인 “Generate an SVG of a pelican riding a bicycle"를 던졌다. 결론은 한 줄: “There’s no distinguishable pattern relating quality to size — they’re all pretty terrible!”. 이번 글은 그 갤러리를 출발점으로, 비공식 벤치마크가 공식 점수판이 못 잡는 무엇을 잡아내는지, 그리고 양자화-품질 곡선을 측정하려면 어디서부터 봐야 하는지를 정리한다.

flowchart LR
 P["프롬프트 <br/> pelican on a bicycle"] --> Q["Granite 4.1 3B <br/> 21 quant variants"]
 Q --> S1["1.2GB ~ 6.34GB"]
 S1 --> O["SVG 출력 21장"]
 O --> J["Simon의 눈 판정"]
 J --> R["크기-품질 상관 없음 <br/> 전부 추상 도형"]

“SVG 펠리컨” 이 뭐길래

Simon Willison의 pelican-riding-a-bicycle 시리즈는 새 LLM이 나올 때마다 그가 고정으로 돌리는 비공식 평가다. 프롬프트는 단 한 줄.

“Generate an SVG of a pelican riding a bicycle.”

SVG는 텍스트 모델이 좌표·path·viewBox를 직접 출력해야 하는 양식이라 시각적 사고를 강제한다. 더 중요한 건 결과가 즉시 그림으로 렌더링 되어 모델 간 비교가 직관적이라는 점이다. LMArena 의 익명 페어 비교나 MMLU 의 객관식 점수에는 잡히지 않는 실패 모드 — 비례, 선의 연속성, 부품 배치 — 가 한 장의 SVG에서 드러난다.

이번 실험

항목	내용
대상	IBM Granite 4.1 3B Instruct
변형	양자화 21종 (1.2GB ~ 6.34GB, 합 51.3GB)
프롬프트	“Generate an SVG of a pelican riding a bicycle”
출력	SVG 21장, 한 페이지 갤러리
판정자	Simon Willison 본인 (눈)

원본 갤러리 글에 21장이 그대로 펼쳐져 있다.

결과 — Simon의 평가

“There’s no distinguishable pattern relating quality to size — they’re all pretty terrible!”

모델 크기와 품질 사이에 구별 가능한 패턴이 없다. 1.2GB와 6.34GB가 사실상 같은 줄에 선다.
21장 모두 추상 도형 덩어리. 펠리컨도, 자전거도 명확히 식별되지 않는다.
흥미롭게도 가장 작은 모델이 자전거를 가장 잘 표현했고, 가장 큰 모델이 펠리컨에 가까운 형태를 그렸다 — 크기-품질 관계가 단조 증가가 아닐 수 있다는 작은 단서.
Simon 본인은 “기대보다 덜 흥미롭다”, “더 잘 그리는 모델로 다시 해보겠다"고 마무리.

의미 — 무엇을 측정한 것인가

1. 양자화 곡선은 본판 capability ceiling에 막힌다

5배 메모리 차이(1.2GB → 6.34GB)에도 출력 품질에 의미 있는 차이가 없었다. 그러나 결론은 “양자화가 무해하다” 가 아니다. “이 모델 자체가 SVG 펠리컨에서 약하다” 가 더 정확한 해석이다.

양자화 영향을 깔끔하게 측정하려면 본판이 그 과제에서 충분히 강해야 한다. 본판이 이미 floor 근처면 AutoRound·GGUF·AWQ 어떤 방식으로 누르든 변별이 안 나온다. 즉 양자화 벤치를 설계할 때는 모델의 capability ceiling을 먼저 확인 해야 한다는 교훈.

2. 비공식 벤치마크가 공식 점수판을 보완한다

LMArena 의 페어 비교나 MMLU 같은 표준 벤치는 텍스트 토큰의 정답률·선호도를 잡는다. 하지만 “이 모델이 좌표 평면에 부품을 배치할 줄 아는가” 같은 질문은 잘 안 잡힌다. SVG 펠리컨은 그 갭에 정확히 들어간다 — 공식 벤치엔 없지만 모두가 동의하는 빠른 sanity check.

3. Granite 패밀리에 대한 시사

IBM Granite / watsonx Granite 라인업은 엔터프라이즈 RAG·도구 호출·코드 작업을 타깃으로 잡혀 있다. 그 좌표계에서 보면 SVG 펠리컨은 분포 밖 과제라 약한 게 어쩌면 당연하다. 다만 같은 시기 풀린 Google Gemma + LiteRT MTP 같은 모바일 친화 small model 흐름과 나란히 두면, 3B 클래스 small open model의 실용성은 모델 패밀리/제조사가 어디에 capability를 몰아넣었는지에 따라 크게 갈린다.

인사이트

비공식 벤치마크가 살아남는 이유는 점수판이 못 잡는 결함을 한 장의 그림으로 보여주기 때문이다. SVG 펠리컨은 MMLU·LMArena 의 보완재이지 대체재가 아니다 — 둘이 같이 있어야 모델의 강점·약점이 드러난다. 양자화-품질 곡선은 본판 capability에 강하게 의존하므로, 양자화 벤치를 설계할 때는 본판이 그 과제에서 충분히 위에 있는지를 먼저 본다. AutoRound 같은 방식으로 압축률을 더 짜내도 floor 근처 모델에서는 변별이 안 난다. 21장 갤러리에서 가장 작은 모델이 자전거를 가장 잘 그렸다는 디테일은 단조 관계 가정 자체를 의심하게 만든다 — 양자화 비교는 단일 점수가 아니라 분포로 봐야 한다는 뜻. IBM Granite가 엔터프라이즈 좌표계를 정조준하는 동안 시각적 추론 같은 분포 밖 과제가 약한 건 당연한 결과이고, 그래서 small open model을 고를 때는 “어느 패밀리가 어디에 capability를 몰아넣었나"를 봐야 한다. Simon 같은 외부 관찰자가 21종을 한 페이지에 깔아주는 건 결국 모두를 위한 빠른 모델 카드 역할 — 공식 벤치 결과가 풀리기 전에 한 장으로 감을 잡게 해준다.

참고

Original gallery post

IBM Granite

Related benchmark refs