16GB GPU에서 Qwen 3.6 27B 및 35B의 MTP vs 표준 방식 테스트

저는 RTX 4080(16GB VRAM) 환경에서 Qwen 3.6 27B 및 35B 모델의 추측적 디코딩 (Speculative decoding, Multi-Token Prediction, MTP) 성능을 테스트했습니다. 동일한 하드웨어에서 더 많은 모델에 대한 토큰 속도와 VRAM 트레이드오프(trade-offs)를 폭넓게 확인하려면, llama.cpp를 이용한 16GB VRAM LLM 벤치마크를 참조하십시오.

MTP (Multi-Token Prediction)란 무엇인가

Multi-Token Prediction은 특정 모델 체크포인트에 직접 내장된 추측적 디코딩 (Speculative decoding)의 한 형태입니다. 모델이 한 번의 순전파 (forward pass) 당 하나의 토큰을 예측하는 대신, 한 번의 단계에서 여러 개의 미래 토큰을 제안하는 추가적인 "MTP 헤드 (MTP heads)"를 탑재하여 이를 병렬로 검증합니다. 예측이 수락되면 출력 품질을 변경하지 않고도 유효 처리량 (throughput)이 상승합니다. Qwen 3.6 제품군은 표준 GGUF 파일과 MTP가 활성화된 변형 모델을 모두 제공합니다. llama.cpp에서 MTP는 다음 명령어를 통해 활성화됩니다:

--spec-type draft-mtp --spec-draft-n-max 3

--spec-draft-n-max는 핵심적인 튜닝 노브 (tuning knob)입니다. 이는 MTP 헤드가 각 단계에서 제안할 추측 토큰의 수를 설정합니다. 값이 높을수록 잠재적인 속도 향상을 얻을 수 있지만, 초안 버퍼 (draft buffers)를 위한 추가 VRAM 비용이 발생하며, 이는 16GB 그래픽 카드에서 실제적인 제약 사항이 됩니다.

테스트 내용 및 방법

저는 16GB VRAM을 가진 GPU (RTX 4080)에서 두 Qwen 3.6 모델이 MTP를 활성화했을 때와 표준 디코딩 (standard decoding)을 사용할 때 어떻게 동작하는지 테스트했습니다. 모델 가중치와 KV 캐시 (KV cache)를 VRAM에 맞추기 위해 다음과 같이 고도로 양자화된 (quantised) 변형 모델을 사용했습니다:

• Qwen3.6-27B-UD-IQ3_XXS 및 Qwen3.6-27B-UD-IQ3_XXS-MTP
• Qwen3.6-35B-A3B-UD-IQ3_S 및 Qwen3.6-35B-A3B-UD-IQ3_S-MTP

각 실행마다 두 가지 컨텍스트 예산 (context budgets)을 추적했습니다:

• Avg Ctx (평균 컨텍스트) — llama.cpp가 약 14.8 GB의 VRAM을 점유하여 다른 앱(Xorg, GNOME Shell, Cursor)이 약 500 MB의 여유 버퍼를 가질 수 있는 컨텍스트 크기입니다.
• Max Ctx (최대 컨텍스트) — 동일한 데스크톱 앱들이 이미 약 500 MB의 VRAM을 점유하고 있다는 가정하에 llama.cpp가 할당할 수 있는 가장 큰 컨텍스트 크기입니다.

평균 컨텍스트를 실용적인 목표로 유지한 주요 이유는 제가 이 기기에서 llama.cpp에 연결하는 기본 AI 어시스턴트로 사용하는 Hermes Agent가 기본적으로 최소 64K 컨텍스트를 요구하며, 시작 시 컨텍스트 윈도우 (window)가 더 작은 모델은 거부하기 때문입니다.

해당 임계값 미만의 모델은 다단계 도구 호출 (multi-step tool-calling) 워크플로우를 위한 충분한 작업 메모리 (working memory)를 유지할 수 없습니다. llama.cpp의 경우, 이는 --ctx-size 65536 이상의 값을 전달해야 함을 의미합니다. 따라서 평균 가용 컨텍스트 (average usable context)를 64K 미만으로 크게 압축하는 모든 MTP 설정은 일상적인 Hermes 워크로드에 부적합합니다. 이것이 아래 표에서 평균 컨텍스트 (Avg Ctx) 수치가 의사 결정에 가장 관련성이 높은 이유입니다. 두 가지 KV 캐시 양자화 (KV cache quantisation) 수준을 모두 테스트했습니다: q8 (높은 품질, 더 많은 VRAM 사용) 및 q5 (더 적은 VRAM 사용, 더 긴 컨텍스트). q8에서 q5 KV 캐시로 전환하면 눈에 띄는 품질 저하가 발생할 수 있음에 유의하십시오. 제 테스트 결과, 성능 저하가 상당히 심각하여 q5를 제 워크로드에 사용하기에는 부적합했습니다. q5의 속도 및 컨텍스트 수치는 완전성을 위해 포함되었으나, q5를 확정하기 전에 본인의 작업에서 응답 품질을 직접 테스트해야 합니다.

Qwen 3.6 27B MTP vs 표준 KV 캐시 q8

	MTP max 1	MTP max 2	MTP max 3	MTP max 4	Standard (IQ3_XXS)
Prompt Speed	148 t/s	151 t/s	148 t/s	147 t/s	200 t/s
Gen Speed	65 t/s	75 t/s	73 t/s	75 t/s	45 t/s
Avg Ctx	40 K	40 K	40 K	30 K	80 K
Max Ctx	60 K	60 K	60 K	50 K	100 K

q8 KV 캐시를 사용할 경우, --spec-draft-n-max 2 설정의 MTP는 평균 컨텍스트 윈도우 (context window)가 80K에서 40K로 절반 줄어드는 대신, 약 67% 더 빠른 생성 속도(75 vs 45 t/s)를 제공합니다. MTP는 프리필 (prefill) 단계 동안 디바이스-호스트 간 전송 (device-to-host transfers)을 요구하기 때문에 프롬프트 인제스션 (Prompt ingestion) 속도는 200에서 약 150 t/s로 떨어집니다.

KV 캐시 q5

	MTP max 1	MTP max 2	MTP max 3	MTP max 4	Standard (IQ3_XXS)
Prompt Speed	145 t/s	144 t/s	141 t/s	139 t/s	191 t/s
Gen Speed	57 t/s	62 t/s	67 t/s	66 t/s	41 t/s
Avg Ctx	70 K	60 K	60 K	50 K	130 K
Max Ctx	100 K	100 K	90 K	80 K	160 K

q5 KV 캐시로 전환하면 유의미한 컨텍스트를 회복할 수 있습니다: --spec-draft-n-max 1은 57 t/s의 속도에서 70K의 평균 컨텍스트를 제공하며, 이는 컨텍스트 윈도우를 유용한 크기로 유지하면서도 표준 디코딩 (standard decoding) 대비 39%의 생성 속도 향상을 보여줍니다. --spec-draft-n-max 3에서는 컨텍스트가 60K로 떨어지지만 생성 속도는 67 t/s(+63%)에 도달합니다.

Qwen 3.6 27B 시사점

MTP는 27B 밀집 모델 (Dense Model)에서 진정으로 유용합니다. 16GB VRAM에서의 최적 지점(Sweet spot)은 다음과 같습니다:

• q8 KV + --spec-draft-n-max 2: 최고의 순수 속도 (75 t/s), 컨텍스트는 40–60K로 감소
• q5 KV + --spec-draft-n-max 1: 최고의 속도 대비 컨텍스트 균형 (57 t/s, 평균 컨텍스트 70K)

Qwen 3.6 35B MTP vs 표준 방식

35B 모델은 전문가 혼합 (Mixture-of-Experts, MoE) 아키텍처입니다 (35B-A3B는 총 파라미터 35B, 토큰당 활성 파라미터 약 3B를 의미합니다). MoE 모델은 일반적으로 MTP로부터 더 많은 이득을 얻는데, 이는 희소 라우팅 (Sparse routing) 덕분에 MTP 헤드가 전체 순방향 패스 (Forward pass)에 비해 계산 비용이 저렴하기 때문입니다.

KV Cache	q8	MTP max 1	MTP max 2	MTP max 3	MTP max 4	표준 (IQ3_S)
Prompt Speed	277 t/s	277 t/s	265 t/s	275 t/s	368 t/s
Gen Speed	186 t/s	189 t/s	180 t/s	171 t/s	146 t/s
Avg Ctx	15 K	10 K	—	—	80 K
Max Ctx	80 K	70 K	60 K	50 K	150 K

MoE 아키텍처는 MTP를 통해 인상적인 순수 생성 속도를 제공합니다 (표준 146 t/s 대비 max 1에서 +27%, max 2에서 +29%). 하지만 실제적인 문제는 평균 컨텍스트입니다. q8 KV 캐시를 사용할 경우, --spec-draft-n-max 1조차 평균 컨텍스트를 15K밖에 제공하지 못하며, 이는 적당한 작업을 수행하기에도 간신히 턱걸이하는 수준입니다. 더 높은 초안 깊이 (Draft depths)를 사용하면 16GB 카드에서는 실행 가능한 평균 컨텍스트가 아예 존재하지 않습니다. 이것이 소비자용 하드웨어에서 MTP를 사용할 때 발생하는 핵심적인 VRAM 비용 문제입니다. 추가적인 초안 버퍼 (Draft buffers)가 남은 VRAM 예산을 직접적으로 잠식하며, q8 KV 캐시를 사용하는 35B-A3B 모델은 여유 공간 (Headroom)이 거의 남지 않습니다.

KV Cache	q5	MTP max 1	MTP max 2	MTP max 3	MTP max 4	표준 (IQ3_S)
Prompt Speed	264 t/s	266 t/s	270 t/s	264 t/s	343 t/s
Gen Speed	151 t/s	147 t/s	137 t/s	131 t/s	122 t/s
Avg Ctx	10 K	—	—	—	120 K
Max Ctx	120 K	110 K	110 K	80 K	200 K

q5 KV 캐시는 평균 컨텍스트 상황을 아주 미미하게만 개선합니다. --spec-draft-n-max 1은 151 t/s의 속도에서 10K의 평균 컨텍스트를 제공합니다. q5에서의 표준 디코딩 (Standard decoding)은 120K의 평균 컨텍스트와 함께 122 t/s를 제공합니다.

Qwen 3.6 35B 시사점

16GB GPU에서 MTP를 사용하는 35B MoE 모델은 거대한 벽에 부딪힙니다. 사용 가능한 평균 컨텍스트가 10–15K 토큰으로 급격히 무너지며, 이는 실제 워크로드에 적용하기에는 비실용적입니다.

80–120K 컨텍스트(Context)에서 122–146 t/s의 속도를 내는 표준 디코딩(Standard decoding) 방식이 훨씬 더 유용합니다. 만약 24 GB 이상의 VRAM을 보유하고 있다면, 35B + MTP 조합이 훨씬 더 매력적이 됩니다. 컨텍스트 윈도우(Context window) 문제가 사라지면서도 속도 이점을 유지할 수 있기 때문입니다.

올바른 --spec-draft-n-max 값 선택하기
단계당 제안할 투기적 토큰(Speculative tokens)의 개수(--spec-draft-n-max)에 대한 단 하나의 정답은 없습니다. 이는 모델 아키텍처와 사용 가능한 VRAM 모두에 따라 달라집니다.

• 16 GB 환경에서 27B Dense 모델 사용 시: q8 KV를 사용한 --spec-draft-n-max 2가 가장 빠르며, q5 KV를 사용한 --spec-draft-n-max 1이 컨텍스트 활용에 가장 유리합니다.
• 16 GB 환경에서 35B MoE 모델 사용 시: --spec-draft-n-max 1이 사용 가능한 컨텍스트를 유지할 수 있는 유일한 옵션이며, 이마저도 아주 미미한 수준입니다. 더 높은 값(3, 4)은 속도 향상이 비례하지 않으면서 VRAM 압박만 가중시킵니다. 최대값인 4를 설정하면 최대값 2를 설정했을 때와 거의 비슷한 추가 VRAM을 소모하지만, 생성 속도는 그에 맞춰 따라오지 못합니다.

lama.cpp에서 MTP 활성화하는 방법
MTP가 활성화된 GGUF 파일(파일명에 MTP가 포함됨)을 사용해야 합니다. llama.cpp 플래그(Flags)가 처음이라면, CLI 및 서버를 이용한 llama.cpp Quickstart에서 모든 기초를 다룰 수 있습니다. 그 다음 아래 명령어로 llama-server 또는 llama-cli를 실행하세요:

llama-server \ --model Qwen3.6-27B-UD-IQ3_XXS-MTP.gguf \ --ctx-size 40000 \ -ngl 99 --flash-attn on \ --cache-type-k q8_0 --cache-type-v q8_0 \ --spec-type draft-mtp \ --spec-draft-n-max 2

q5 KV 캐시를 사용하려면 q8_0을 q5_1 또는 q5_0으로 교체하고 --ctx-size를 상향 조정하세요:

llama-server \ --model Qwen3.6-27B-UD-IQ3_XXS-MTP.gguf \ --ctx-size 80000 \ -ngl 99 --flash-attn on \ --cache-type-k q5_1 --cache-type-v q5_1 \ --spec-type draft-mtp \ --spec-draft-n-max 1

lama.cpp가 GGUF 파일 내에서 MTP 헤드(MTP heads)를 감지하고 --spec-type draft-mtp가 설정되면 MTP는 자동으로 활성화됩니다. 따라서 표준 Qwen3.6-27B-UD-IQ3_XXS.gguf는 MTP 모드에서 작동하지 않으며, 반드시 Qwen3.6-27B-UD-IQ3_XXS-MTP.gguf가 필요합니다. 하지만 Qwen3.6-27B-UD-IQ3_XXS-MTP.gguf는 투기적 디코딩(Speculative decoding) 모드와 자기회귀(Autoregressive) 모드 모두에서 작동할 수 있습니다.

결론

16GB GPU (RTX 4080) 환경에서 이러한 양자화(Quantization) 모델들을 사용했을 때, llama.cpp의 MTP는 Qwen 3.6 27B에게는 명확한 승리이며, Qwen 3.6 35B의 실제 사용 측면에서는 오히려 마이너스 요소입니다.

Qwen 3.6 27B (IQ3_XXS) — MTP를 사용할 가치가 있음:

• q8 KV + MTP max 2 → 생성 속도 약 67% 향상, 컨텍스트(Context) 40–60 K (MTP 미사용 시 80–100 K)
• q5 KV + MTP max 1 → 생성 속도 약 39% 향상, 컨텍스트 70–100 K (MTP 미사용 시 130–160 K)
• --spec-draft-n-max 2 설정 시 속도와 VRAM 효율성 사이의 좋은 균형을 보여줌

Qwen 3.6 35B (IQ3_S) — 16GB 환경에서 MTP는 실용적이지 않음:

• 생성 속도는 27–29% 더 빠르지만, 평균 컨텍스트가 q8에서 10–15 K, q5에서 10 K로 급격히 감소함
• 80–120 K 컨텍스트를 유지하며 122–146 t/s를 기록하는 표준 디코딩(Standard decoding) 방식이 실제 작업에는 더 유용함

24GB 이상의 VRAM 환경에서는 상황이 상당히 개선됩니다.

이론적으로는 MTP의 속도 이점을 유지하면서 컨텍스트 창(Context window)을 극대화하기 위해 q5 KV 캐시(KV cache)가 명확한 정답이지만, 실제로 q8에서 q5로 넘어갈 때 발생하는 품질 저하는 상당할 수 있습니다. q5를 채택하기 전에 본인의 작업에 직접 테스트해 보십시오. 저의 워크로드에서는 성능 저하가 수용 불가능한 수준이었으며, 컨텍스트 예산을 더 타이트하게 잡더라도 q8을 사용하는 것이 더 나은 절충안(Trade-off)으로 남았습니다.

LLM 서빙 옵션과 인프라 트레이드오프에 대한 더 넓은 관점은 '2026년 LLM 호스팅(LLM Hosting in 2026)' 및 '2026년 LLM 성능(LLM Performance in 2026)' 칼럼을 참조하십시오. 만약 MTP와 함께 Qwen 3.6의 샘플러(Sampler) 설정을 조정하고 있다면, 'Qwen 3.6 및 Gemma 4를 위한 에이전틱 LLM 추론 파라미터 참조(Agentic LLM Inference Parameters Reference for Qwen 3.6 and Gemma 4)'가 유용한 참고 자료가 될 것입니다.