Gemma 4 QAT MTP 어시스턴트 헤드 HuggingFace 공개 + PARALLEL=2 충돌 수정 + 12B 2-slot 벤치마크

제목: Gemma 4 QAT MTP 어시스턴트 헤드 HuggingFace 공개 + PARALLEL=2 충돌 수정 + 12B 2-slot 벤치마크 (Strix Halo / Vulkan)

한 번의 업데이트에 세 가지 소식이 있습니다: 변환된 QAT 매칭(QAT-matched) 초안 헤드(draft heads)가 누구나 사용할 수 있도록 업로드되었으며, Atomic 포크(fork)와 네이티브 llama.cpp PR 모두에서 발견된 PARALLEL=2 충돌(crash) 문제를 수정하고 동일한 버그를 llama.cpp에 보고했습니다. 그리고 수정 후의 첫 번째 12B 2-slot 수치를 공개합니다.

1. QAT 매칭 MTP 헤드가 HuggingFace에 업로드되었습니다
   boxwrench/gemma-4-qat-mtp-assistant-heads
   공식 Gemma 4 QAT Q4_0 모델과 함께 추측적 디코딩 (Speculative Decoding, MTP)을 위한 세 가지 초안 헤드(draft heads):

파일 쌍 및 크기

gemma-4-12B-it-qat-assistant-MTP-Q8_0.gguf google/gemma-4-12B-it-qat-q4_0 444 MiB
gemma-4-26B-A4B-it-qat-assistant-MTP-Q8_0.gguf google/gemma-4-26B-A4B-it-qat-q4_0 441 MiB
gemma-4-31B-it-qat-assistant-MTP-Q8_0.gguf google/gemma-4-31B-it-qat-q4_0 491 MiB

Google의 공식 비양자화(unquantized) QAT 어시스턴트 체크포인트(google/gemma-4-{12B,26B-A4B,31B}-it-qat-q4_0-unquantized-assistant)에서 gemma4_assistant GGUF Q8_0로 변환되었습니다.
QAT 매칭 헤드가 중요한 이유: 초안 헤드(draft head)는 메인 모델보다 앞서 토큰을 예측합니다. 만약 헤드가 전체 정밀도(full-precision) 가중치를 대상으로 학습되었는데 메인 모델이 QAT 양자화(quantization) 모델이라면, 두 모델의 분포가 어긋나게 됩니다. 즉, 헤드는 전체 정밀도 모델이 말했을 법한 것을 예측하지만, QAT 모델은 그 결과에 더 자주 동의하지 않게 됩니다. 동일한 QAT 체크포인트를 대상으로 학습된 헤드를 사용하면 이 격차를 상당히 줄일 수 있습니다:

모델 | 비-QAT 헤드 (Non-QAT head) | QAT 매칭 헤드 (QAT-matched head) | 변화

12B QAT Q4_0 | 71.3% | 78.4% | +7 pp
26B-A4B QAT Q4_0 | 56.9% | 91.8% | +35 pp
31B QAT Q4_0 | 42.5% | 60.4% | +18 pp

26B-A4B의 격차는 특히 극명했습니다. 수락률(acceptance rate)의 거의 35%포인트가 순수하게 헤드 불일치로 인해 손실되고 있었습니다.
호환성: 이들은 gemma4_assistant 아키텍처를 사용합니다. 현재 Atomic TurboQuant 포크에서 로드할 수 있으며, PR #23398이 병합되면 순정 llama.cpp에서도 로드할 수 있습니다 (동일한 아키텍처 구조를 사용합니다).

이들은 ik_llama 변형 헤드(gemma4_mtp 형식)와는 호환되지 않습니다.

2. PARALLEL=2 충돌 — 근본 원인 발견 및 수정
   이러한 헤드 중 어느 것을 사용하든 --n-parallel 2를 실행하면 다음과 같은 어설션 실패(assertion failure)와 함께 충돌이 발생했습니다:
   GGML_ASSERT(ggml_nelements(a) == ne0ne1ne2)
   llm_build_gemma4_mtp에서 호출된 ggml_reshape_3d 내에서 발생.

근본 원인은 gemma4-assistant.cpp의 단 한 줄에 있었습니다:

// 수정 후: Qcur = ggml_reshape_3d(ctx0, Qcur, n_embd_head, n_head, 1); ```

MTP 초안 단계(draft step)는 활성화된 서버 슬롯(server slots)의 수와 관계없이 항상 정확히 하나의 토큰 열(token column)을 처리합니다. 메인 순전파(forward pass)의 n_tokens를 사용하는 방식은 슬롯이 하나일 때(어차피 n_tokens=1인 경우)는 잘 작동했지만, 두 번째 슬롯이 첫 번째 초안 단계를 실행하자마자(n_tokens=2, 요소 개수 불일치) 충돌이 발생했습니다.

또한, 두 개의 슬롯이 동시에 활성화될 때 스레드 큐 데드락(thread queue deadlocks)을 방지하려면 Vulkan 환경에서 환경 변수로 LLAMA_PIPELINE_DEPTH2=0을 설정해야 합니다.

수정 사항은 Atomic 포크에 제출되었습니다: AtomicBot-ai/atomic-llama-cpp-turboquant#26.
동일한 버그가 네이티브 llama.cpp PR #23398에도 존재하며, 동일한 라인에 동일한 수정이 필요합니다. 병합 전에 패치될 수 있도록 해당 PR에 댓글을 남겼습니다.

또한 언급할 만한 점은, u/janvitos가 순정 llama.cpp를 위해 독립적으로 동일한 작업을 수행했다는 것입니다 — PR #23398은 네이티브 빌드에 Gemma 4 MTP 지원을 추가합니다. 위대한 정신은 서로 통하는 법입니다. 해당 PR이 병합되면, 여기의 헤드들은 Atomic 포크 없이도 순정 llama.cpp에서 로드될 수 있습니다.

3. 첫 12B PARALLEL=2 벤치마크 (수정 후, Strix Halo / Vulkan)
하드웨어: AMD Ryzen AI Max+ 395, 128 GB LPDDR5X 통합 메모리, Vulkan/RADV (Mesa 25.2.8)

| 지표 | 12B plain 2-slot | 12B MTP PARALLEL=1 | 12B MTP PARALLEL=2 |
| :--- | :--- | :--- | :--- |
| 2-slot 합계 | 47.6 tok/s | 43.5 tok/s | 62.5 tok/s |
| 단일 스트림 디코딩 (Single-stream decode) | — | 45.6 tok/s | 38.6 tok/s (48.6 eff.) |
| MTP 수락률 (MTP acceptance) | N/A | 78.4% | 88.6% |
| 실제 소요 시간 (Wall time) (1150-in/2000-out) | 79.5 s | 46.0 s | 53.9 s |

MTP PARALLEL=2는 plain 2-slot 대비 합계 +31% 성능 향상을 보였습니다.

슬롯당 디코딩 (Per-slot decode) 속도는 하락하지만 (두 슬롯이 동일한 대역폭을 공유하기 때문), 전체 출력 처리량 (total output throughput)은 향상되었으며 수락률 (acceptance) 또한 단일 슬롯 대비 실제로 상승했습니다. 이는 모델이 두 개의 요청을 인터리빙 (interleave)할 수 있을 때, 한 번의 패스(pass)당 더 유용한 추측 (speculation)을 수행함을 의미합니다.

26B-A4B PARALLEL=2 벤치마크는 아직 실행 중입니다. 26B-A4B는 시작 시점의 수락률 (acceptance)이 더 높기 때문에, 일반적인 2-slot의 90.9 tok/s 수치에 근접하거나 이를 능가할 것으로 예상됩니다.

전체 수치 및 컨텍스트
- 이전 QAT 수치 게시물 (plain + single-slot MTP): Gemma 4 QAT Q4_0 Strix Halo 벤치마크
- 전체 벤치마크 데이터, 재현성 매트릭스 (reproducibility matrix), 서빙 스크립트: boxwrench/tesla_agent
- HF 모델 카드는 이 수치들을 도출해낸 LLAMA_PIPELINE_DEPTH2=0 플래그 및 --mtp-draft-n 3 --draft-p-min 0.75 설정을 포함한 사용 예시를 제공합니다.

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