저는 작년에 500유로에 중고로 구매한 2021년형 Asus 게이밍 노트북을 가지고 있습니다. 최근 llama.cpp에 병합된 MTP 지원 기능이 이처럼 VRAM이 제한된 장치에서 Qwen3.6-35B-A3B 모델을 사용할 때 가치가 있는지 확인하고 싶었습니다. 그래서 MTP 사용 여부에 따른 성능을 측정하기 위해 몇 가지 실험을 진행했습니다.

요약(TL;DR): 가치가 없습니다. MTP를 사용하면 프롬프트 처리(Prompt processing) 속도가 너무 느려져서, 토큰 생성(TG) 속도에서 얻는 미미한 이득보다 손해가 더 큽니다. 하지만 유용한 VRAM 절약 팁을 하나 발견했습니다. 초안 KV 캐시(draft KV cache)에 q4_0 양자화(quantization)를 사용하는 것이 q8_0만큼 잘 작동하면서도 VRAM을 약간 절약할 수 있습니다.

하드웨어

• Asus ROG Zephyrus G14 노트북, 2021년 모델
• AMD Ryzen 7 5800HS (Radeon Graphics 포함, 8 CPU 코어 / 16 스레드)
• NVIDIA RTX 3060 Laptop GPU, 6GB VRAM
• 24GB RAM (DDR4 3200 MT/s), 1TB SSD

소프트웨어

• Linux Mint 22.2 (Ubuntu 24.04 기반), Cinnamon 데스크톱이 Radeon iGPU에서 실행 중 (따라서 3060은 llama.cpp 전용으로 할당됨)
• llama.cpp 버전: 9198 (a6d6183db), Linux x86_64용 GNU 13.3.0으로 현재 master 브랜치에서 빌드됨
• Ubuntu 저장소에서 설치된 CUDA 12.0

테스트 설정

모든 실험에 대해 다음과 같은 파라미터(parameters)를 고정했습니다:

• Unsloth Qwen3.6-35B-A3B-MTP-UD-Q4_K_XL 모델 (이 시스템이 실행할 수 있는 최대치까지 밀어붙임; MTP와 비-MTP 실험 모두에 동일한 모델을 사용했으며, 모든 실행에서 모델의 MTP 부분이 사용되지 않도록 명령줄 인자(command line arguments)만 변경함)
• 메인 KV 캐시(main KV cache)에 q8_0 양자화(quantization) 적용 (품질을 너무 많이 타협하고 싶지 않음)
• 컨텍스트 크기(context size) 65536 (Pi나 Dirac 등에서 에이전틱 코딩(agentic coding)을 수행하거나 Hermes Agent를 실행하기에 충분한 크기)
• MTP의 경우, --spec-draft-n-max 2를 사용 (경우에 따라 3이 약간 더 나을 수 있다는 점은 알고 있지만, 결과를 비교 가능하게 만들기 위해 이 값을 유지하기로 결정함)
• mmap 활성화 (기기가 멈추지 않고 이 모델을 실행할 수 있는 유일한 방법임...)

저는 다음 파라미터들을 변경하며 실험했습니다:

• MTP vs non-MTP (MTP 전용 CLI 파라미터 포함/제외)
• ubatch size (ubatch 크기): 512, 1024, 1536, 2048
• draft model KV cache quantization (초안 모델 KV 캐시 양자화): q8_0 또는 q4_0 중 선택 (K 및 V 모두 항상 동일하게 설정)
• --fit-target을 OOM (Out Of Memory) 오류 없이 작동하는 가장 낮은 값으로 설정 (64 단위로 조정)

다음은 전체 llama-server 명령의 예시입니다 (아래 표의 MTP 1에 해당):

build/bin/llama-server \
-m Qwen3.6-35B-A3B-MTP-UD-Q4_K_XL.gguf \
--threads 8 \
-ub 512 \
--parallel 1 \
--fit-target 448 \
-c 65536 \
-ctk q8_0 \
-ctv q8_0 \
-ctkd q8_0 \
-ctvd q8_0 \
--chat-template-kwargs '{"preserve_thinking": true}' \
--temp 0.6 \
--top-p 0.95 \
--min-p 0.0 \
--top-k 20 \
--repeat-penalty 1.0 \
--presence-penalty 0.0 \
--spec-type draft-mtp \
--spec-draft-n-max 2

모델에게 부여한 작업은 두 가지였습니다:

1. MB: mtp-bench.py 스크립트를 실행하여 다양한 작업에 대해 MTP를 벤치마크합니다.
2. S: 긴 문서를 몇 개의 불렛 포인트로 요약합니다 (github의 MTP PR 22673). 이는 13,448 토큰의 프롬프트와 그 뒤를 잇는 2,000~3,000 토큰의 생성으로 구성됩니다.

결과

이 표는 결과를 요약한 것입니다. ub = ubatch size, dKV = draft KV 양자화 유형, fitt = fit-target 값, acc% = acceptance rate (수락률)입니다.

|Setup|ub|dKV|fitt|MB TG|MB acc%|S PP|S TG|S acc%|
|:-|:-|:-|:-|:-|:-|:-|:-|:|
|No MTP 1|512|-|0|25.0|-|178|23.8|-|
| ... |

MTP를 사용하면서 더 높은 ubatch 값을 시도해 보기도 했으나, 결과가 너무 좋지 않았습니다 (TG 10-15 tok/s, 아마도 RAM 부족으로 인한 스와핑 때문으로 보임). 그래서 해당 실행들은 중단했습니다.

판결

• ubatch=2048을 사용한 베이스라인 "No MTP 4" 설정이 MTP를 사용하지 않는 설정 중에서는 명확하게 가장 우수했습니다. 이 설정은 400 tok/s 이상의 PP (Prefill) 속도와 23-26 tok/s의 TG (Decoding) 속도에 도달했습니다.
• ubatch=512를 사용한 "MTP 1" 실행은 mtp-bench에서 가장 높은 TG 속도(27 tok/s 이상)를 기록했으나, 요약(summarization) 작업의 TG에서는 "No MTP 4"와 동일한 수준이었습니다. PP 속도는 MTP를 사용하지 않는 모든 설정보다 훨씬 낮았습니다.
• MTP에서 ubatch 크기를 늘리면 PP 속도를 약간 개선할 수 있는데, 특히 draft KV cache에 q4_0 양자화 (quantization)를 사용한 "MTP 4" 설정에서 그러했습니다. 하지만 이는 PP 속도를 절반 이하로 떨어뜨리면서 TG 속도에서의 이점은 사실상 없애버렸습니다.
• 요약하자면: 이 환경에서 MTP는 그만한 가치가 없습니다. 일부 사례에서 TG가 아주 미세하게 증가하지만, PP 속도는 항상 거대하게 하락합니다. 만약 향후 llama.cpp에서 MTP의 PP 속도가 개선된다면 (이것은 PR에서 알려진 문제로 나열되어 있었습니다), 결과가 달라질 수도 있습니다.

관찰 사항 (Observations)

• draft 모델의 KV cache에 q4_0 양자화를 사용하는 것이 draft 모델의 정확도에 미치는 영향이 무시할 수 있는 수준이라는 점에 놀랐습니다. 이는 VRAM을 아주 조금 절약해주므로, VRAM이 매우 제한적인 환경에서는 유용한 기술이 될 수 있습니다.
• 측정값 사이에 설명되지 않는 약간의 변동이 있는데, 이는 아마도 무작위적인 변화, CPU/GPU 온도 스로틀링 (throttling) 등에 의한 것으로 보입니다. 아주 심각한 수준은 아니지만, 참고용으로만 받아들이시기 바랍니다.
• VRAM은 시작부터 분명히 매우 부족합니다. MTP의 VRAM 오버헤드 (overhead)는 시스템을 성능이 매우 저하되는 시나리오로 쉽게 몰아넣습니다.
• --fit 및 --fit-target 옵션은 MTP 오버헤드를 고려하지 않는 것으로 보입니다. MTP를 위해 일정량의 메모리를 예약해야 하며, 이 양은 주로 ubatch 크기에 따라 달라집니다. 따라서 제한된 VRAM에서 최대 성능을 짜내고 싶다면 --fit-target을 수동으로 설정해야 합니다. 저의 경우, fit-target을 ubatch 크기보다 약간 작은 숫자로 설정하는 것이 효과가 있었으나, 결과는 사용자마다 다를 수 있습니다 (YMMV).

참고 사항 (Notes)

이 포스트는 100% 유기농 재료로 만들어졌습니다. 이 과정에서 어떤 AI도 해를 입지 않았습니다.

이곳에 올리는 저의 두 번째 포스트입니다. 질문이 있다면 기꺼이 답변해 드리겠습니다.