모든 자기회귀(Autoregressive) LLM은 동일한 병목 현상을 겪습니다. 하나의 순전파(forward pass)에 하나의 토큰만 생성한다는 점입니다. 270억 개 파라미터(27B) 모델의 경우, 100개의 토큰을 생성하려면 VRAM에서 전체 가중치 행렬을 100번이나 로드해야 합니다. 그리고 다음 토큰이 뻔히 예측 가능한 접속사든, 복잡한 논리적 전개든 상관없이 모든 개별 패스는 거의 동일한 양의 연산 작업을 수행합니다.

이때 GPU는 연산 능력의 한계(Compute-bound)에 부딪힌 것이 아닙니다. 바로 **메모리 대역폭의 한계(Memory-bandwidth-bound)**에 갇혀 있는 것입니다. GPU는 연산을 수행하는 시간보다 HBM(고대역폭 메모리) 또는 VRAM에서 연산 유닛으로 파라미터를 실어 나르는 데 대부분의 시간을 소비합니다. RTX 3090이 35.6 TFLOPS에 달하는 FP32 연산 성능을 갖추고 있음에도 27B 모델에서 초당 약 38토큰(~38 tok/s)만 생성할 수 있는 이유가 바로 여기에 있습니다. 메모리 버스가 데이터를 따라잡는 동안 산술 연산 장치는 유휴 상태로 대기하고 있습니다.

멀티 토큰 예측(MTP, Multi-Token Prediction)은 한 번의 순전파에서 단 하나의 토큰 대신 여러 개의 토큰을 동시에 예측함으로써 이 문제를 해결합니다. MTP는 모델을 더 똑똑하게 만드는 것이 아닙니다. 모델의 연산 낭비를 줄여주는 기술입니다. 그리고 메모리 대역폭이 가장 결정적인 제약 조건으로 작용하는 로컬 추론 환경에서, 이 차이는 엄청난 성능 변화를 만들어냅니다.

MTP의 실제 동작 원리

표준적인 디코딩은 엄격하게 순차적으로 진행됩니다.

Prompt: "The capital of France is"
     ↓
Predict → " Paris"     ← 1 forward pass
Append → "The capital of France is Paris"
     ↓
Predict → "."           ← 1 forward pass
Append → "The capital of France is Paris."
     ↓
Predict → " It"         ← 1 forward pass

각 토큰마다 모델 전체의 순전파가 필요합니다. 27B 모델의 경우 토큰당 270억 번의 곱셈-누적(multiply-add) 연산이 발생하며, 그중 대부분은 동일한 가중치를 다시 로드하는 작업에 불과합니다.

MTP는 예측 헤드(prediction head) 레벨에서 아키텍처를 변경합니다.

Hidden State
     ↓
┌────────────────────────────────────────────┐
│  Head 0 (main) → Token +1                  │
│  Head 1 (MTP)  → Token +2                  │
│  Head 2 (MTP)  → Token +3                  │
│  Head 3 (MTP)  → Token +4                  │
└────────────────────────────────────────────┘

메인 트랜스포머는 은닉 상태(hidden state)를 생성합니다. 하나의 출력 헤드가 해당 상태를 다음 토큰 확률 분포로 매핑하는 대신, 서로 다른 미래 위치를 예측하도록 학습된 여러 개의 헤드가 존재합니다. MTP 헤드는 매우 가볍기 때문에(트랜스포머 전체 파라미터의 극히 일부) 추가적인 오버헤드가 매우 적습니다. 최종 검증은 여전히 메인 모델이 담당합니다.

추론 중의 진행 프로세스는 다음과 같습니다.

1. 메인 모델이 토큰 N을 생성합니다.
2. MTP 헤드가 토큰 N+1, N+2, ..., N+k를 초안(draft)으로 생성합니다. (비용이 매우 저렴한 패스)
3. 메인 모델이 단 한 번의 순전파로 k개의 모든 초안을 검증합니다.
4. 올바른 접두사(prefix)는 채택하고, 첫 번째 불일치 토큰부터는 기각합니다.
5. 마지막으로 채택된 토큰부터 생성을 이어갑니다.

검증 과정이 엄밀하게 이루어지기 때문에, 출력 결과는 일반적인 바닐라(vanilla) 디코딩과 비트 단위까지 완벽히 동일합니다. 품질 저하나 근사치 계산에 따른 오차가 전혀 없습니다. 그저 비용이 많이 드는 순전파 횟수를 획기적으로 줄일 뿐입니다.

이것이 바로 **자체 투기적 디코딩(Self-speculative decoding)**입니다. 별도의 소형 모델을 사용하는 대신 자체적인 경량 헤드를 통해 초안을 생성합니다. 로드해야 할 두 번째 모델도 없고, 메모리 요구량이 두 배로 늘어나지도 않으며, 관리 복잡성도 발생하지 않습니다.

Qwen3.6이 특별한 이유

MTP는 모델 학습이 끝난 뒤 임의로 덧붙일 수 있는 기능이 아닙니다. 사전 학습(pre-training) 단계에서 예측 헤드를 함께 학습시켜야 합니다. 손실 함수 자체가 토큰 $t+1$ 하나만 예측하던 것에서 $t+1, t+2, t+3, t+4$를 동시에 예측하도록 변경됩니다. 모든 학습 샘플이 미래의 여러 위치를 동시에 예측하도록 유도하므로, 모델 내부 표현(representation)을 개선할 수 있는 더 풍부한 그래디언트 신호를 제공하기도 합니다.

Qwen3.6과 Qwen3.5 계열은 처음부터 MTP를 적용하여 사전 학습되었습니다. 헤드가 체크포인트 안에 기본적으로 내장되어 있습니다. Unsloth에서는 메인 모델과 MTP 모듈이 단일 파일에 모두 포함된 전용 MTP GGUF 파일을 배포하므로, 사용자가 두 개의 모델을 따로 관리할 필요가 없습니다.

이것이 바로 이전 세대 모델(Llama 3, Mistral 등)에서 MTP를 사용할 수 없는 이유입니다. 해당 모델들에는 예측 헤드가 아예 존재하지 않습니다. 별도의 드래프트 모델을 사용하는 전통적인 투기적 디코딩은 여전히 가능하지만, 오버헤드가 훨씬 더 큽니다.

실제 벤치마크 결과: 기대할 수 있는 성능

속도 향상 폭은 대략 1.4~2.2배에 달합니다. 이러한 편차가 나타나는 이유는 하드웨어, 프롬프트 유형, 그리고 --spec-draft-n-max 설정값에 따라 초안 채택률(acceptance rate)이 달라지기 때문입니다. 독립적인 출처에서 측정한 실제 벤치마크 수치는 다음과 같습니다.

RTX 3090 — Qwen3.6 27B Q4_K_M

단일 RTX 3090 24GB 환경에서 9개의 혼합 프롬프트(n_predict=192)로 테스트한 결과입니다.

구성 평균 tok/s 총 소요 시간(Wall time) 속도 향상 채택률
기준선 (MTP 미적용) 38.3 50.6초 1.00x —
MTP n=2 63.8 34.4초 1.47x (총 소요 시간) / 1.67x (평균) 80.5%
MTP n=3 61.4 27.2초 1.86x (총 소요 시간) / 1.60x (평균) 71.1%

두 가지 속도 향상 지표를 측정한 이유는 서로 다른 측면을 반영하기 때문입니다. 평균 tok/s는 각 프롬프트의 개별 생성 속도를 평균한 것으로, 토큰이 스트리밍될 때 체감하는 속도입니다. 반면 총 소요 시간(Wall-clock time)은 사용자가 프롬프트를 제출한 시점부터 모든 응답이 완료될 때까지 걸린 전체 시간으로, 사용자가 실제로 체감하는 지연 시간입니다. 에이전트 워크플로우나 챗봇 환경에서는 총 소요 시간이 훨씬 중요합니다.

여기서 흥미로운 점이 있습니다. 9개 프롬프트 중 8개에서는 프롬프트별 처리량(throughput) 기준으로 n=2가 우세했지만, 전체 소요 시간 기준으로는 n=3이 승리했습니다. 긴 입력 프롬프트에 대한 프리필(prefill) 처리 시간을 덜 소모했기 때문입니다. 이 차이는 n=3이 5.8초 만에 완료된 반면 n=2는 13.3초가 걸렸던 단 하나의 프롬프트(긴 코드 리뷰 작업)에서 비롯되었습니다.

Apple Silicon — Qwen3.6 27B Q8_0

통합 메모리를 탑재한 M 시리즈 Mac에서의 결과입니다.

구성 tok/s 채택률
기준선 ~7 —
MTP n=2 ~16 82%
MTP n=3 ~18–21 72%

n=2 설정에서 무려 2.3배의 속도 향상을 보여줍니다. 재학습이 전혀 필요 없고 별도의 모델도 추가되지 않는다는 점을 감안하면 놀라운 수치입니다.

RTX 6000 Ada — Unsloth 공식 보고 수치

  • Qwen3.6 27B MTP: 160 tok/s
  • Qwen3.6 35B-A3B MTP: 240 tok/s

RTX PRO 6000

  • Qwen3.6 27B: 기준선 45.76 → MTP 79.37 tok/s = 1.73배
  • Qwen3.6 35B-A3B MoE: 기준선 193.36 → MTP 225.48 tok/s = 1.17배

MoE 모델의 혜택이 상대적으로 적은 이유

35B-A3B 모델은 전문가 혼합(MoE, Mixture-of-Experts) 아키텍처입니다. 총 파라미터는 35B이지만 토큰당 활성화되는 파라미터는 3B에 불과합니다. 순전파당 로드하는 가중치의 양이 극히 일부이므로 기준선 디코딩 자체가 이미 매우 저렴합니다. 투기적 디코딩은 타깃 모델의 순전파 횟수를 절감해 주는 기법인데, 원래 순전파 비용이 낮다면 절감할 수 있는 절대적인 여지도 줄어듭니다. 절대적인 성능 개선은 여전히 존재하지만, 상대적인 속도 향상 폭은 밀집(Dense) 모델의 1.72.2배에서 MoE 모델의 1.11.2배 수준으로 축소됩니다.

RTX 3090 + MoE 조합에서의 주의사항

19개 구성으로 진행된 엄밀한 벤치마크에서 단일 RTX 3090 환경에 llama.cpp의 초안 투기 기법을 적용하여 Qwen3.6-35B-A3B를 테스트했습니다. 그 결과, 어떤 구성에서도 기준선 대비 순 속도 향상을 달성하지 못했습니다. MoE 전문가 라우팅이 컨슈머용 암페어(Ampere) 아키텍처의 메모리 대역폭을 포화시키는 방식으로 동작하여 llama.cpp 상에서 초안 투기가 역효과를 낳았기 때문입니다.

그러나 동일한 하드웨어에서 네이티브 MTP(method=mtp, num_speculative_tokens=1)를 적용한 vLLM을 구동했을 때는 디코딩 속도가 +27.5% 빨라졌습니다. 즉, 성능 저하는 하드웨어 자체의 한계가 아니라 추론 엔진 구현에 따른 차이입니다. MoE 모델을 구동할 계획이라면 llama.cpp의 초안 투기가 도움이 될 것이라 지레짐작하지 말고, vLLM의 MTP를 우선적으로 테스트해 보아야 합니다.

초안 채택률 패턴

초안 채택률(acceptance rate)은 실질적인 속도 향상을 결정짓는 핵심 요인입니다. 채택률이 높을수록 단일 검증 주기당 더 많은 토큰이 확정됩니다. 관찰된 패턴은 다음과 같습니다.

콘텐츠 유형 일반적인 채택률
코드 / 구조화된 출력 80–86%
일반 텍스트 대상 밀집(Dense) 모델 (27B) 65–82%
MoE 모델 (35B-A3B) 55–76%
개방형 창의적 글쓰기 상대적으로 낮음

코드와 구조화된 프롬프트는 예측 가능성이 매우 높기 때문에 최적의 효과를 발휘합니다. def calculate_ 다음 토큰은 거의 확실하게 함수 이름이 뒤따릅니다. 반면 창의적인 글쓰기는 문맥의 분기 가능성이 훨씬 넓기 때문에 MTP 헤드의 예측이 빗나갈 확률이 더 높습니다.

하드웨어 요구사항

MTP는 일반적인 GGUF 대비 약 1~2.5GB의 메모리를 추가로 소비합니다. 이 오버헤드는 MTP 헤드 가중치와 해당 헤드의 KV 캐시에서 발생합니다. 전체적인 요구사항은 다음과 같습니다.

Qwen3.6 3-bit 4-bit 6-bit 8-bit BF16
27B 16 GB 19 GB 25 GB 31 GB 56 GB
35B-A3B 18 GB 24 GB 31 GB 39 GB 71 GB

단위: 총 메모리 (RAM + VRAM, 또는 Mac의 통합 메모리).

실무적인 환경별 적합성:

  • RTX 3090/4090 (24 GB): 27B Q4_K_M이 여유 있게 구동됩니다. 적당한 컨텍스트 크기 기준으로 모델 + MTP + KV 캐시를 합쳐 약 20GB 정도로 예산을 책정하십시오.
  • RTX 6000 Ada (48 GB): 35B-A3B 6-bit 또는 8-bit 모델을 거대한 컨텍스트와 함께 구동하기에 충분합니다.
  • Mac M 시리즈 (32+ GB): 27B Q4 또는 Q6이 원활히 동작합니다. 최고의 결과를 위해서는 M4/M5 Max를 권장합니다.
  • 16 GB GPU: 매우 빠듯합니다. 적절한 컨텍스트 크기에서는 MTP 오버헤드로 인해 메모리 한계를 초과할 수 있습니다. 모델 로드 시 nvidia-smi로 반드시 확인하십시오.
  • 12 GB GPU: vLLM + FP8 양자화를 적용한 35B-A3B 구동이 가능하지만(보고된 VRAM 점유율 9.5GB), 적극적인 양자화와 제한된 컨텍스트 크기에서만 실용적입니다.

실행 방법

방법 1: llama.cpp (가장 정밀한 제어)

MTP는 2026년 5월 16일에 병합(merged)된 PR #22673을 통해 mainline llama.cpp에 정식 탑재되었습니다. 별도의 포크(fork)가 필요 없으며 최신 마스터 브랜치의 표준 빌드로 바로 사용할 수 있습니다.

빌드:

git clone https://github.com/ggml-org/llama.cpp.git
cd llama.cpp
cmake -B build -DGGML_CUDA=ON -DCMAKE_BUILD_TYPE=Release
cmake --build build --config Release --target llama-server -j

실행:

./build/bin/llama-server \
  -m Qwen3.6-27B-MTP-Q4_K_M.gguf \
  -ngl 99 -c 10000 -fa on -np 1 \
  --spec-type draft-mtp \
  --spec-draft-n-max 2 \
  --cache-type-k q8_0 \
  --cache-type-v q8_0

핵심 플래그 설명:

플래그 기능 설명
--spec-type draft-mtp MTP 투기적 디코딩 활성화
--spec-draft-n-max 2 주기당 최대 2개 토큰을 미리 초안으로 작성
-np 1 필수 항목. MTP는 아직 병렬 슬롯을 지원하지 않습니다.
-fa on Flash Attention 활성화. 상당한 속도 향상 제공.
--cache-type-k q8_0 양자화된 KV 캐시 적용. 품질 저하 없이 RAM 절약.
--cache-type-v q8_0 Value 캐시 대상 동일 양자화 적용.

HuggingFace에서 자동 다운로드 (수동 GGUF 다운로드 불필요):

./build/bin/llama-server \
  -hf unsloth/Qwen3.6-27B-MTP-GGUF:Q4_K_S \
  -ngl 99 --spec-type draft-mtp --spec-draft-n-max 2 \
  -c 8192 -fa on -np 1

중요 플래그 명칭 변경 사항: PR이 병합되면서 플래그 이름이 --spec-type mtp에서 --spec-type draft-mtp로 변경되었습니다. Unsloth 공식 문서와 다수의 튜토리얼에서 여전히 이전 이름을 언급하고 있습니다. 현재 빌드에서 --spec-type mtp를 사용하면 아무런 경고 없이 조용히 무시됩니다. 반드시 draft-mtp를 사용해야 합니다.

방법 2: Unsloth Studio (가장 간편한 방법)

  1. Unsloth Studio를 설치하고 실행합니다.
  2. “Qwen3.6 MTP”를 검색하여 원하는 양자화 버전을 다운로드합니다.
  3. 사용자의 하드웨어(Mac, CPU, GPU)에 맞춰 MTP 설정이 자동으로 감지됩니다.
  4. --spec-draft-n-max를 미세 조정하고 싶다면 사이드바에서 재정의할 수 있습니다.

가장 진입 장벽이 낮은 경로입니다. Unsloth Studio가 플래그 명칭, 하드웨어 감지, 최적 기본값 설정을 모두 자동으로 처리합니다.

방법 3: vLLM (높은 처리량 환경)

vllm serve unsloth/Qwen3.6-27B-NVFP4 \
  --speculative-config '{"method": "mtp", "num_speculative_tokens": 2}'

35B-A3B MoE 모델의 경우:

vllm serve unsloth/Qwen3.6-35B-A3B-NVFP4-Fast \
  --speculative-config '{"method": "mtp", "num_speculative_tokens": 2}'

vLLM의 MTP 구현은 컨슈머용 암페어 GPU에서 llama.cpp의 초안 투기가 실패했던 MoE 모델에 대해 +27.5%의 속도 향상을 보여준 검증된 경로입니다. vLLM을 사용하는 환경이라면 이 방식을 추천합니다.

방법 4: Ollama

Ollama의 지원 여부는 내부에서 사용하는 llama.cpp 통합 버전에 따라 달라집니다. MTP가 2026년 5월에 병합되었으므로, 백엔드가 업데이트됨에 따라 Ollama에도 반영될 예정입니다. 설치된 버전을 확인하십시오.

–spec-draft-n-max 매개변수 튜닝

이 옵션은 MTP에서 가장 중요한 단일 매개변수입니다. 메인 모델이 검증하기 전에 초안 헤드가 미리 제안할 토큰 수를 제어합니다.

통상적인 조언은 “2로 시작해서 1부터 6까지 테스트해 보라”는 것입니다. 맞는 말이긴 하지만 충분하지 않습니다. 다음과 같은 미묘한 차이를 이해해야 합니다.

숫자가 클수록 항상 좋은 것이 아닌 이유:

초안 1개 제안  → 98% 채택률 → 빠른 검증
초안 6개 제안  → 20% 채택률 → 대부분의 작업 결과물 폐기

채택률이 급감하면 결국 버려질 토큰을 미리 만드느라 연산 리소스를 낭비하게 됩니다. 검증 패스가 가볍다고 해도 공짜는 아닙니다. 거부된 토큰이라 하더라도 버리기 전에 순전파를 거쳐 검증해야 하기 때문입니다.

하드웨어별 최적 구간:

하드웨어 클래스 최적 범위 이유
Mac M 시리즈 1–2 외장 GPU에 비해 낮은 메모리 대역폭
컨슈머 GPU (3090/4090) 2–3 우수한 연산 성능, 준수한 대역폭
데이터센터 GPU (A100/H100/RTX 6000) 3–6 높은 대역폭, 강력한 병렬 처리 능력
CPU 전용 1 매우 제한적인 성능

총 소요 시간(Wall-clock)과 처리량(Throughput) 간의 트레이드오프:

n=2는 프롬프트당 더 높은 채택률(~80%)을 제공하지만 프리필에 더 많은 시간을 씁니다. n=3은 프롬프트당 채택률은 다소 낮지만(~71%), 긴 프롬프트를 더 효율적으로 처리하여 전체 작업 소요 시간을 단축시킵니다. 짧은 호출이 잦은 코딩 에이전트 작업에는 n=2가 유리하고, 장문의 글 생성이나 분석 작업에는 n=3이 유리합니다.

실무적인 벤치마킹 루프:

for n in 1 2 3 4 5 6; do
  ./llama-server -m model.gguf \
    --spec-type draft-mtp --spec-draft-n-max $n \
    -ngl 99 -fa on -np 1 --metrics
done

llama.cpp 로그에서 draft_tokens_accepted / draft_tokens를 확인하여 각 설정별 채택률을 파악하십시오. 최적의 n은 채택률 × n의 값이 최대화되는 지점입니다.

프리필 오버헤드 (The Prefill Tax)

MTP를 활성화하면 동일 하드웨어 기준으로 프롬프트 처리(prefill) 속도가 약 17% 느려집니다. 즉, 첫 번째 토큰이 나오기까지의 시간(Time-to-first-token, TTFT)이 늘어납니다. 짧은 대화 메시지에서는 몇 밀리초 차이에 불과하므로 체감하기 어렵지만, 8K 이상의 긴 컨텍스트를 처리하는 RAG 파이프라인에서는 무시할 수 없는 비용이 됩니다.

손익분기점은 대략 50개의 생성 토큰입니다. 요청당 생성되는 토큰이 50개 미만이라면 프리필 오버헤드가 생성 단계에서의 이득을 상쇄할 수 있습니다. 반면 코드 생성, 문서 작성, 심층 분석 등 그보다 긴 출력을 요구하는 모든 작업에서는 MTP가 제공하는 이점이 오버헤드를 압도합니다.

피해야 할 사항 (흔한 실수)

n=2가 어디서나 최적일 것이라 단정하지 마십시오. Unsloth 문서에서는 시작 지점으로 n=2를 권장하지만, 커뮤니티 벤치마크에 따르면 긴 프롬프트에서는 총 소요 시간 기준으로 n=3이 더 우수했습니다. 실제 작업 워크로드에서 직접 측정해 보아야 합니다.

구버전 플래그 이름을 사용하지 마십시오. --spec-type mtp는 --spec-type draft-mtp로 변경되었습니다. 최신 빌드에서 구버전 명칭을 사용하면 아무 동작도 하지 않습니다. 많은 기술 문서들이 아직 업데이트되지 않아 혼란을 초래하는 부분입니다.

병렬 슬롯을 활성화하지 마십시오. -np 1은 필수입니다. MTP는 아직 멀티 슬롯 동시 추론을 지원하지 않습니다. 동시 사용자가 필요하다면 별도의 모델 인스턴스를 실행해야 합니다.

llama.cpp에서 MTP와 멀티모달을 함께 사용하지 마십시오. 현재는 텍스트 전용입니다. 비전 인코더(mmproj)가 활성화되어야 하는 환경이라면 현재 llama.cpp 빌드에서 MTP와 호환되지 않습니다.

llama.cpp 환경의 MoE 모델에서 큰 속도 향상을 기대하지 마십시오. 커뮤니티에서 검증되었듯, 컨슈머용 암페어 GPU에서 llama.cpp의 초안 투기를 적용한 35B-A3B는 순 속도 향상이 나타나지 않았습니다. MoE 모델의 경우 vLLM의 MTP를 사용하십시오.

평균 tok/s 지표만 측정하지 마십시오. 특히 에이전트 기반 워크플로우에서는 실제 총 소요 시간(Wall-clock time)과 첫 토큰 생성 시간(TTFT)이 똑같이 중요합니다. 평균 tok/s가 10% 빠르더라도 프리필 단계에서 30% 느려진다면 특정 유스케이스에서는 오히려 손해일 수 있습니다.

전체 추론 최적화 스택 관점에서의 MTP

MTP는 더 큰 최적화 스택을 구성하는 하나의 핵심 요소입니다. 각 기술은 서로 다른 병목 지점을 공략합니다.

기술 공략하는 병목 오버헤드
양자화 (GGUF, NVFP4) 메모리 점유율 극미한 품질 손실
Flash Attention 어텐션 연산 복잡도 없음
Paged KV Cache 긴 컨텍스트 메모리 극미함
MTP / 투기적 디코딩 순전파(Forward pass) 횟수 약 1~2.5 GB VRAM
Prefix Caching 반복되는 프롬프트 캐시 메모리
Continuous Batching 요청 간 GPU 활용률 시스템 복잡도

MTP는 로컬 추론에서 가장 큰 비용이 발생하는 **생성 병목(generation bottleneck)**을 직접 해결합니다. 양자화가 모델을 메모리에 ’적재’할 수 있게 해준다면, MTP는 모델을 ‘빠르게’ 만들어 줍니다.

오늘 바로 시작할 수 있는 설정

24GB GPU를 보유하고 있고 로컬에서 Qwen3.6을 구동하고 싶다면, 다음 절차를 그대로 실행해 보십시오.

# llama.cpp 다운로드 및 빌드
git clone https://github.com/ggml-org/llama.cpp.git
cd llama.cpp
cmake -B build -DGGML_CUDA=ON -DCMAKE_BUILD_TYPE=Release
cmake --build build --config Release --target llama-server -j

# MTP를 적용하여 실행
./build/bin/llama-server \
  -hf unsloth/Qwen3.6-27B-MTP-GGUF:Q4_K_S \
  -ngl 99 -c 8192 -fa on -np 1 \
  --spec-type draft-mtp --spec-draft-n-max 2 \
  --cache-type-k q8_0 --cache-type-v q8_0

브라우저에서 http://localhost:8080에 접속합니다. 정확도 손실도 없고, 별도의 드래프트 모델도 없으며, 품질 저하에 대한 타협도 없이 컨슈머 GPU에서 27B 모델을 초당 60토큰 이상의 생성 속도로 온전히 구동할 수 있습니다.

불과 6개월 전만 해도 불가능했던 일입니다.

llama.cpp의 MTP 지원: PR #22673 (2026년 5월 16일 병합). MTP GGUF 체크포인트: unsloth/Qwen3.6-27B-MTP-GGUF 및 unsloth/Qwen3.6-35B-A3B-MTP-GGUF. 전체 MTP 연구 노트: [[MTP-Multi-Token-Prediction-Speculative-Decoding-Deep-Dive-2026]].