저는 2× RTX 5090에서 DFlash 투기적 디코딩 (Speculative Decoding)을 사용하여 Laguna S 2.1 (118B MoE, 71 GB Q4)을 실행했습니다. 모델이 다 들어가지 않아 전문가 (Experts) 모델들이 CPU RAM으로 넘쳐흐릅니다. • 기본 플래그 (Default flags): 23 tok/s vs 초안 (Draft) 미사용 시 58 tok/s. 2.5배 느림 • 튜닝 후: 64 tok/s vs 기준점(Baseline) 62 tok/s • 단일 5090 사용 시: 33 vs 30. 실제로 사용 가능한 수준입니다. https://preview.redd.it/gqkq9ceqwzeh1.png?width=3200&format=png&auto=webp&s=1f54d41ea3603320b0b9f8d443c8cefc9d1d4f42

설정 (The setup)
• Laguna S 2.1: 118B 파라미터 MoE, 토큰당 8B 활성화 (256개의 라우팅된 전문가 + 1개의 공유 전문가, top-10 라우팅), Q4_K_M 기준 71 GB
• 2× RTX 5090 (각 32 GB) + Xeon w5-3423, 256 GB RAM
• DFlash를 적용한 llama.cpp: 큰 모델이 검증할 수 있도록 토큰 블록을 예측하는 작은 블록 확산 (Block-diffusion) 초안 모델 (2.1 GB)
• 문제점: 71 GB는 64 GB의 VRAM에 들어가지 않으므로, 전문가 모델의 일부는 시스템 RAM에 상주합니다.

1단계: 실패 (Pass 1: The failure)
"당연해 보이는" 플래그로 첫 실행: --spec-type draft-dflash --spec-draft-n-max 15
결과: 23 tok/s vs 기준점 58 tok/s. 2.5배 느림. 초안 수락률 (Draft acceptance): 10.5%. 아픕니다.
파헤쳐 보니 하나의 버그가 아니라, 세 가지 기본 설정이 조용히 쌓여 있었습니다: --spec-draft-p-min이 기본값 0.00으로 설정되어 있었습니다. 0입니다. 그래서 초안 생성기 (Drafter)는 확신 여부와 상관없이 매 라운드마다 15개의 토큰을 모두 내보냈습니다. 그중 검증을 통과한 것은 약 1.6개뿐이었습니다. 초안 생성기 자체는 나쁘지 않았습니다. 과도한 약속을 하도록 강요받고 있었을 뿐입니다.
세밀한 MoE (Fine-grained MoE)는 큰 검증 배치 (Verify batches)에 취약합니다. 하나의 토큰은 레이어당 10개의 전문가로 라우팅됩니다 (256개 중 top-10). 16개 토큰의 검증 배치라면? 레이어당 최대 160개의 서로 다른 전문가가 필요합니다. CPU에 상주하는 모든 전문가들은 RAM에서 스트리밍되어야 합니다. 추가 검증 토큰당 약 6.8 ms를 측정했습니다. "검증은 기본적으로 비용이 들지 않는다"는 가정은 이 아키텍처에서는 통하지 않습니다. BF16 초안 생성기와 과도한 메모리 마진은 전문가를 담을 수 있었던 약 3 GB의 VRAM을 낭비했습니다.

2단계: 해결 (Pass 2: The fix)
세 가지 변경 사항: --spec-draft-n-max 7, --spec-draft-p-min 0.6 → 초안을 짧게 가져가고, 초안 생성기가 실제로 확신할 때만 생성하도록 함. 수락률이 10.5%에서 약 73%로 급증했습니다.

llama-quantize DFlash-BF16.gguf DFlash-Q8_0.gguf Q8_0 → 수락률(acceptance)은 동일하고, 1 GB가 뒤로 밀렸으며, 이제 전체 시스템이 기본 메모리 마진(memory margin)에서 부팅됩니다. 약 3 GB의 전문가(experts)가 다시 GPU로 이동했습니다. 결과: 63tok/s vs 기준점 62tok/s. 2.5배 느렸던 상태에서 실제로 승리하는 상태로 변했습니다. p_min이 결정적인 역할을 했습니다. 아무도 설정하지 않는 노브(knob)였죠.

Pass 3: 단일 GPU
단일 5090 환경에서 동일한 레시피를 적용했습니다 (따라서 이제 약 40 GB의 전문가가 RAM에 있음). 두 가지 수정 사항: --fit-target 2048 (fit 엔진이 drafter를 미리 측정할 수 없으므로, 문을 열어두어야 합니다) 그리고 더 엄격한 --spec-draft-p-min 0.75. 검증 토큰(verify tokens)의 비용이 더 비쌀 때는 훨씬 더 선택적으로 초안을 작성(draft)해야 하기 때문입니다. 31 vs 30 tok/s, 모든 프롬프트에서 더 빨라졌습니다. 재미있는 반전: 여기서는 Speculative Decoding (spec decode)이 더 도움이 됩니다. 기준점(baseline)의 단계가 더 느리기 때문에 drafter의 고정 오버헤드(fixed overhead)가 상대적으로 더 저렴해지기 때문입니다.

Pass 4: 실제 프롬프트
직접 고른 프롬프트는 쉬운 모드이므로, 표준 Speculative Decoding 벤치마크인 Spec-Bench에서 모든 것을 다시 실행했습니다: 대화(conversation), 번역(translation), 요약(summarization), 질의응답(QA), 수학(math), RAG. 카테고리당 12개의 샘플 프롬프트, temperature 0, 동시성(concurrency) 1, Greedy decoding, 256 tokens.

전반적으로 성능을 유지했습니다:
• Dual GPU: 64.1 vs 62.4 (+2.7%), 6개 카테고리 중 3개 승리
• Single GPU: 32.8 vs 30.3 (+8.3%), 6개 카테고리 중 4개 승리, 1개는 동점
• 참고로, 동일한 프롬프트에 대해 고장 난 기본 설정(broken default config)을 사용했을 때는: 여전히 모든 곳에서 2.3배 느렸습니다.

하지만 카테고리별 세부 분석이 실제 핵심입니다:
• 수학(math): +20 ~ +25%
• 번역(translation): +18 ~ +20%
• 대화(conversation): +5 ~ +9%
• RAG / QA / 요약(summarization): 비슷하거나 -9%

요약과 RAG가 압도할 것이라고 예상했습니다. 근거가 있고, 복사 가능한(copyable) 텍스트이니 초안 작성이 쉽지 않을까요? 아닙니다. 수락률(Acceptance)은 괜찮았지만(65–82%), drafter가 거의 나타나지 않았습니다: 수학에서의 라운드당 약 3.6개 초안 토큰 대비 약 1.5개 초안 토큰.
자신의 오버헤드를 감당하기에 충분하지 않았습니다. 교훈: "복사 가능함(copyable)" ≠ "초안 작성 가능함(draftable)". 복사는 n-gram 또는 프롬프트 조회(prompt-lookup) 방식이 하는 일입니다. 학습된 drafter는 복사 메커니즘이 없으므로, 대신 공식적인 텍스트(formulaic text)인 수학, 번역, 상용구(boilerplate)에서 승리합니다. 모든 Speculative Decoding 계열은 각자 고유한 카테고리 프로필을 가집니다. 여러분의 워크로드(workload)로 직접 벤치마크를 수행하세요.

(현재까지의) 결론: DFlash는 보통 2배 이상의 성능 향상을 가져오는 레버(lever)이지만, 이는 모든 것이 VRAM에 들어가는 설정에서만 해당됩니다. 여기서는 겨우 본전치기(break even)를 했을 뿐입니다. CPU로 오프로드(offload)된 전문가(experts)들이 모든 검증 배치(verification batch)를 비싸게 만들기 때문에, 일반적인 Speculative Decoding (Spec-decode) 계산식이 성립하지 않습니다. 이번 실행의 진짜 승리는 다른 곳에 있습니다. 단일 32 GB GPU에서 약 30 tok/s의 속도로 일상적인 에이전트(agentic) 작업을 수행할 수 있다는 점입니다. 한 가지 더 솔직하게 말씀드리자면, 지금까지는 속도에 대해서만 다루었습니다. 에이전트 작업 시 Q4 양자화(Quantization)의 품질은 이야기의 나머지 절반이며, 그 확인 작업은 여전히 계획 목록에 있습니다.

요약 (TL;DR):
• 부분 오프로드(partial offload)가 포함된 미세한 MoE (Mixture of Experts) 환경에서 Speculative Decoding (Spec-decode)은 공짜가 아닙니다: 검증 비용이 배치 크기(batch size)에 따라 증가합니다.
• --spec-draft-p-min을 설정하세요. 기본값인 0.00은 실수하기 쉬운 설정(footgun)입니다.
• Drafter를 Q8_0로 양자화하세요. 비용이 들지 않습니다.
• 튜닝을 통해 재앙적인 상황을 해결(23 → 64 tok/s)했지만, 이는 초안(draft) 없이 실행하는 것과 거의 비슷한 속도이므로 건너뛰셔도 됩니다.

/u/luke_pacman이 r/LocalLLaMA에 제출함 [link] [comments]