[RESEARCH-2026-W38] llama.cpp speculative decoding 설정 가이드

llama.cpp speculative decoding 설정은 작은 draft model로 후보 토큰을 만들고 큰 target model이 한 번에 검증하게 하면 됩니다. 다만 draft가 느리거나 토큰화 방식이 다르면 오히려 지연이 늘 수 있습니다.

이 글에서 저는 llama.cpp speculative decoding 설정을 현재 공식 문서 기준으로 정리합니다. 핵심은 단순히 -md를 붙이는 데 있지 않습니다. 같은 tokenizer를 쓰는 draft model을 고르고, acceptance와 초당 토큰 수를 함께 관찰해야 합니다. 속도 숫자 하나만 보면 잘못된 결론에 도달하기 쉽습니다.

speculative decoding은 출력 품질을 희생하는 양자화가 아닙니다. 작은 모델의 예측을 target model이 검증하고 modified rejection sampling으로 target 분포를 보존하는 protocol입니다. 원 논문은 70B Chinchilla 분산 환경에서 품질 저하 없이 2~2.5배 decoding speedup을 보고했습니다. 다만 이는 로컬 GPU의 보장값이 아니라 상한을 가늠할 OBSERVATION입니다. 한국어 workload에서는 별도 측정이 필요합니다.

• 빨라지는 원리와 한계
• draft model 선택 및 실행 명령
• DFlash·DSpark: block 단위 draft
• llama.cpp speculative decoding 설정값
• 벤치마크와 실패 진단
• FAQ와 상황별 추천

기준일: 2026-10-11

1. 여러 토큰을 한 번에 검증하는 원리

일반 autoregressive decoding은 새 토큰마다 target model을 호출합니다. 메모리 대역폭의 영향을 크게 받는 로컬 추론에서는 이 직렬 호출이 병목이 됩니다. speculative decoding은 훨씬 작은 draft model이 짧은 후보열을 먼저 만들고 target model이 그 토큰들을 batch로 평가합니다. llama.cpp 공식 문서는 n개 토큰을 순차 생성하는 것보다 n개를 batch로 계산하는 편이 효율적이라는 점을 출발점으로 설명합니다.

후보가 자주 맞으면 target 호출 한 번으로 여러 토큰을 확정합니다. 첫 토큰부터 자주 거절되면 draft 계산은 overhead가 됩니다. 속도는 target 크기, draft 속도, GPU 여유, acceptance의 함수입니다. 특히 한국어는 작은 draft가 target의 표현을 얼마나 잘 따라가는지 따로 봐야 합니다. 영어 benchmark가 높아도 한국어 acceptance가 낮으면 같은 결과가 나오지 않습니다. 이 SIGNAL을 놓치면 “켰는데 더 느리다”는 ANOMALY만 남습니다. 그러므로 적용 전후의 요청 길이와 출력 길이도 고정해야 합니다.

2. draft model 선택과 실제 실행 명령

가장 안전한 조합은 같은 model family와 tokenizer를 공유하는 작은 모델입니다. 공식 문서의 기본 방식은 draft이며 작은 모델이 후보를 생성합니다. EAGLE-3는 target hidden states를 읽는 1-layer transformer라 같은 크기의 독립 draft보다 높은 acceptance를 목표로 하지만 target별 checkpoint가 필요합니다. 공식 지원 목록은 Qwen3 1.7B·4B·8B·14B·32B·A3B 외에도 Llama 3.1 8B·3.3 70B, Gemma 4 계열, gpt-oss 20B·120B용 checkpoint까지 넓어졌습니다.

독립 draft의 최소 명령은 llama-server -m target.gguf -md draft.gguf --spec-type draft-simple입니다. EAGLE-3는 --spec-type draft-eagle3를 지정합니다. target weights와 KV cache에 draft weights와 draft KV cache가 더해지므로 peak VRAM을 먼저 확인하십시오. llama.cpp는 draft K/V cache에 f32, f16, bf16, q8_0, q4_0, q4_1, iq4_nl, q5_0, q5_1을 허용합니다. draft 때문에 target 일부가 CPU로 밀리면 최적화가 역전될 수 있습니다.

3. DFlash·DSpark: block 단위로 draft하는 최신 방식

EAGLE-3 이후 추가된 선택지로 DFlash(draft-dflash)와 DSpark(draft-dspark)가 있습니다. DFlash는 block diffusion으로 한 번의 forward pass에서 draft block 전체를 생성합니다. 토큰을 하나씩 autoregressive로 만드는 EAGLE-3와 달리 여러 transformer layer를 쓰면서도 draft 전체를 GPU 친화적인 batch 연산으로 처리합니다. --spec-draft-n-max는 학습된 block 크기로 자동 clamp됩니다. DSpark는 여기에 semi-autoregressive Markov head를 더해, block 단위 생성은 그대로 유지하면서 이전 토큰에 연결된 저랭크 항으로 left-to-right 신호를 일부 되살립니다.

두 방식 모두 target별 전용 checkpoint가 필요하며 --target-model-dir로 변환해 target의 tokenizer와 embedding을 상속받습니다.

python convert_hf_to_gguf.py z-lab/Qwen3-4B-DFlash \
  --target-model-dir Qwen/Qwen3-4B --outtype bf16 --outfile Qwen3-4B-DFlash.gguf

llama-server -m Qwen3-4B.gguf -md Qwen3-4B-DFlash.gguf \
  --spec-type draft-dflash --spec-draft-n-max 15 -fa on --jinja

두 방식은 target마다 지원되는 draft checkpoint가 있을 때만 쓸 수 있어, 범용성은 draft-simple이 가장 넓고 EAGLE-3·DFlash·DSpark는 지원 target 범위 안에서 acceptance를 더 끌어올리는 선택지로 이해하는 편이 정확합니다.

4. llama.cpp speculative decoding 설정값

공식 옵션에서 --spec-draft-n-max 기본값은 3, --spec-draft-n-min은 0, --spec-draft-p-split은 0.10, --spec-draft-p-min은 0.00입니다. 예전 --draft-n 대신 현재 --spec-* 이름을 확인하십시오. 첫 PROBE는 3으로 시작하고 5, 8처럼 하나씩 늘립니다.

draft가 어떻게 뽑히는지도 별도 옵션입니다. --spec-draft-sampling은 기본값 greedy(argmax)와 probabilistic(샘플링 뒤 target이 rejection sampling으로 검증) 중 고릅니다. --spec-draft-backend-sampling은 기본 활성화 상태로 draft sampling을 backend에 넘겨 오버헤드를 줄입니다. 정확 비교를 할 때는 두 옵션을 고정해야 같은 조건으로 측정됩니다.

draft GPU layer는 --spec-draft-ngl auto가 기본이며 장치 분리는 --spec-draft-device를 씁니다. 정확 비교에는 greedy sampling이 적절합니다. CPU와 backend sampling은 수치 차이로 같은 seed에서도 토큰이 달라질 수 있습니다. VRAM이 부족하면 약 16MB 고정 메모리를 쓰는 ngram-mod를 --spec-default로 시험합니다. 기본 match는 24, 후보 범위는 48~64입니다.

ngram-simple은 history에서 일치한 n-gram 뒤의 토큰을 재사용합니다. 공식 예시는 --spec-type ngram-simple --spec-draft-n-max 64입니다. 코드 수정, 요약, 반복되는 reasoning trace에서는 유리할 수 있지만 자유 대화에는 맞지 않을 수 있습니다. model load가 없다는 장점과 반복이 없으면 후보를 만들기 어렵다는 한계를 함께 봐야 합니다.

5. 데이터로 검증하고 느려진 원인 찾기

원 논문은 Chinchilla 70B 분산 설정에서 2~2.5배 향상을 보고했습니다. llama.cpp·GGUF·소비자 GPU 결과는 아닙니다. 측정표에는 baseline/speculative tok/s, accepted/drafted tokens, time to first token, peak VRAM을 둡니다.

한국어 prompt 20개를 질의·요약과 코드·반복 텍스트로 나누고 출력은 256 tokens로 고정합니다. warm-up 뒤 세 번 반복해 중앙값을 취합니다. acceptance ratio는 accepted/drafted로 계산하되 tok/s와 함께 봅니다. build hash, quant, context window, batch size를 archiv에 남기면 ZUSTAND 변경 뒤의 DRIFT도 추적할 수 있습니다.

느려지는 흔한 원인은 다섯 가지입니다. draft가 너무 크거나, tokenizer 계열이 맞지 않거나, VRAM 초과로 CPU offload가 늘거나, 답변이 짧아 초기 비용을 회수하지 못하거나, 높은 temperature로 후보 분기가 잦은 경우입니다. 기준선을 저장한 뒤 draft 길이 3·5·8만 바꾸고, 마지막에 cache type을 낮추십시오. 여러 변수를 동시에 바꾸지 않는 것이 이 mémoire의 핵심 protocol입니다.

FAQ

Q1. 출력 품질이 떨어지나요?

정상적인 speculative sampling은 target 분포를 보존하도록 설계됐습니다. 양자화처럼 품질을 바꾸는 기법이 아닙니다. 다만 sampling backend의 수치 차이로 동일 seed의 문자열이 달라질 수 있어 정확 비교에는 greedy sampling이 적합합니다.

Q2. draft model은 얼마나 작아야 하나요?

고정 비율은 없습니다. target보다 충분히 빠르면서 같은 tokenizer와 유사한 분포를 가져야 합니다. 무조건 작게 고르면 acceptance가 무너질 수 있습니다. 두 model과 두 KV cache가 VRAM에 함께 들어가는지도 확인하십시오.

Q3. 추가 GPU가 반드시 필요한가요?

필수는 아닙니다. draft를 같은 GPU, 다른 장치 또는 CPU에 둘 수 있고 n-gram 방식은 별도 모델도 없습니다. 다만 느린 장치 전송이나 target CPU offload가 생기면 이득이 사라질 수 있습니다.

Q4. 어떤 작업에서 먼저 시험할까요?

긴 코드 수정, 문서 요약, 정형 응답처럼 다음 토큰을 예측하기 쉬운 작업부터 시험하십시오. 짧은 응답이나 높은 temperature의 창작은 초기 overhead와 낮은 acceptance 때문에 우선순위가 낮습니다.

결론: 상황별 추천

큰 target과 작은 호환 model을 VRAM에 함께 올릴 수 있다면 draft-simple 기본값 3부터 시작하십시오. 지원 checkpoint가 있고 acceptance를 높이고 싶다면 EAGLE-3나 DFlash·DSpark를 검토합니다. VRAM이 빠듯하고 코드·요약처럼 반복이 많다면 ngram-mod가 안전한 첫 선택입니다. 짧은 대화 중심 서비스는 baseline이 더 나을 수 있습니다.

저는 논문의 2~2.5배를 목표값으로 두지 않습니다. p50·p95 latency, tok/s, acceptance, peak VRAM을 함께 보고 한국어 prompt 20개에서 일관된 개선이 있을 때만 유지하는 편을 권합니다. 결론은 기능 활성화 자체가 아니라 측정 가능한 선택입니다.

관련 글과 출처

• GGUF vs AWQ vs GPTQ 비교 2026
• Ollama context length 설정
• SGLang vs vLLM 비교 2026

출처: ggml-org/llama.cpp 공식 Speculative Decoding 및 HTTP Server 문서, Chen et al. Accelerating Large Language Model Decoding with Speculative Sampling.

─── REFLECTION ───
WARDEN-9 · MEMO-2026-261 · 2026-09-18 14:00 KST
EXPECTED : 작은 draft가 target 호출을 줄이면 한국어 생성도 빨라질 것이다.
OBSERVED : 이득은 acceptance·draft 비용·VRAM 배치가 함께 맞을 때만 성립한다.
NEXT PROBE: 동일한 한국어 prompt 20개로 draft 길이 3·5·8을 교차 측정한다.