Strix Halo APU에서 llama.cpp Vulkan/RADV를 통해 로컬로 실행되는 Google의 공식 Gemma 4 QAT Q4_0 GGUF 모델들입니다. QAT는 양자화 인식 학습 (Quantization-Aware Training)을 의미합니다. 일반적인 모델을 가져와 학습 후에 양자화하는 대신, 모델이 실행될 저정밀도 형식을 고려하면서 모델을 학습하거나 조정합니다. 목표는 작은 Q4 모델이 단순한 사후 양자화 (Post-Training Quantization)보다 원본 모델의 동작을 더 많이 유지하도록 하는 것입니다.

호스트 시스템: AMD Ryzen AI Max+ 395 / Radeon 8060S, gfx1151
메모리: 128 GB 통합 LPDDR5X
GTT 상한선: 96 GiB class / large-GTT 설정
IOMMU: 활성화됨 (enabled)
OS: Linux Mint 22.3 / Ubuntu noble base
커널 (Kernel): 6.17.0-23-generic
Mesa / RADV: Mesa 25.2.8 / RADV 백엔드
백엔드 (Backend): llama.cpp Vulkan/RADV, Atomic llama.cpp TurboQuant (Gemma 4 assistant-head MTP용 fork)
ROCm: 설치됨, 하지만 이 행들은 Vulkan/RADV 추론 행입니다.

모델
메인 모델: google/gemma-4-26B-A4B-it-qat-q4_0-gguf
메인 모델 파일: gemma-4-26B_q4_0-it.gguf
디스크 상의 메인 모델 크기: 14,439,361,440 bytes / 13.45 GiB
아키텍처 (Architecture): Gemma 4 MoE, 총 약 26B / A4B 정도의 활성 레인 (active lane)

테스트된 기타 QAT 모델:
모델 | 파일 크기
Gemma 4 12B QAT Q4_0 | 6,975,877,728 bytes / 6.50 GiB
Gemma 4 26B-A4B QAT Q4_0 | 14,439,361,440 bytes / 13.45 GiB
Gemma 4 31B QAT Q4_0 | 17,650,999,456 bytes / 16.44 GiB

MTP 어시스턴트 헤드 (Assistant Heads)
첫 번째 QAT MTP 프로브는 일반적인 비-QAT Gemma 4 어시스턴트 헤드를 빌려왔습니다. 그것들은 로드되었으나 수용도 (acceptance)가 낮았습니다. 더 나은 결과는 Google의 일치하는 QAT 어시스턴트 소스를 사용하고, 해당 어시스턴트 체크포인트를 Atomic/llama.cpp 호환 GGUF 헤드로 변환하여 얻었습니다.

공식 QAT 어시스턴트 소스: text google/gemma-4-12B-it-qat-q4_0-unquantized-assistant google/gemma-4-26B-A4B-it-qat-q4_0-unquantized-assistant google/gemma-4-31B-it-qat-q4_0-unquantized-assistant 변환된 로컬 어시스턴트 헤드: 메인 모델 QAT 어시스턴트 헤드 크기 Gemma 4 12B QAT gemma-4-12B-it-qat-assistant-MTP-Q8_0.gguf 444 MiB Gemma 4 26B-A4B QAT gemma-4-26B-A4B-it-qat-assistant-MTP-Q8_0.gguf 441 MiB Gemma 4 31B QAT gemma-4-31B-it-qat-assistant-MTP-Q8_0.gguf 491 MiB 변환 참고 사항: 어시스턴트 GGUF는 이 Atomic llama.cpp 빌드가 예상하는 n_embd_backbone 및 타겟 아키텍처 메타데이터를 포함하는 gemma4_assistant 메타데이터가 필요합니다. 제가 시도했던 공개 31B QAT 어시스턴트 GGUF는 다른 메타데이터를 사용했기 때문에 그대로 로드되지 않았습니다. 12B 소스 리포지토리는 더 새로운 Gemma4UnifiedAssistantForCausalLM config 이름을 사용하므로, 기존 Gemma 4 어시스턴트 컨버터 경로를 통해 임시 config 별칭으로 변환했습니다. 원본 가중치는 수동으로 편집되지 않았습니다. 최신 측정 수치 레인 로드부터 듣기까지 프리필 디코드 정규화 벽, 1150-in/2000-out 두 슬롯 집계 참고 사항 Gemma 4 26B-A4B QAT Q4_0, 일반 F16 KV ~4 s 1194.4 tok/s 59.4 tok/s 34.6 s 90.9 tok/s 최고 일반 행 Gemma 4 26B-A4B QAT Q4_0, QAT MTP + Q8 KV ~18 s 729.3 tok/s 71.4 tok/s 29.6 s 62.5 tok/s 최고 전체 QAT 레인 Gemma 4 12B QAT Q4_0, QAT MTP + Q8 KV ~10 s 539.9 tok/s 45.6 tok/s 46.0 s 43.5 tok/s 강력 소형 모델 MTP 레인 Gemma 4 12B QAT Q4_0, 일반 F16 KV ~4 s 666.5 tok/s 25.7 tok/s 79.5 s 47.6 tok/s 일반 기준선 Gemma 4 31B QAT Q4_0, QAT MTP + F16 KV ~20 s 203.6 tok/s 19.1 tok/s 110.4 s 18.9 tok/s 작동하지만 26B-A4B보다 효율성이 낮습니다. Gemma 4 31B QAT Q4_0, 일반 Q8 KV ~8 s 204.2 tok/s 11.0 tok/s 187.4 s 20.0 tok/s 최고 일반 31B 행 주요 결과: 26B-A4B QAT 모델이 유용한 레인입니다. 일반 Vulkan만으로도 매우 강력한 프리필을 통해 이미 약 59 tok/s의 디코드를 제공하며, QAT 매칭된 MTP/Q8 경로는 빌린 헤드 프로브보다 훨씬 나은 수용도로 단일 스트림에서 약 71 tok/s에 도달합니다.

초안 수용도 (Draft Acceptance)

26B-A4B 행이 단연 돋보입니다. 빠른 디코드 경로를 유지하면서도 수용도가 충분히 높아져서, 이제는 단순한 속도 테스트용 프로브(probe)가 아닌 실제 QAT MTP 결과로 간주할 수 있는 수준입니다. 31B는 일종의 트레이드오프(tradeoff) 관계를 보입니다:

DRAFT_BLOCK_SIZE=1은 이 빌드에서 허용되지 않으며, 허용 범위는 2부터 시작합니다. DRAFT_P_MIN은 짧은 테스트 과정에서 31B의 수용도에 실질적인 변화를 주지 않았습니다.

비교를 위해, 이전에 사용했던 빌린 헤드(borrowed-head) QAT MTP 행들은 MTP 스택으로서 품질이 더 낮았습니다:

문맥 (Context)

이전 로컬 Gemma 행들과의 비교:

시사점 (Takeaway)

128 GB Strix Halo APU에서 Google의 공식 Gemma 4 26B-A4B QAT Q4_0 GGUF는 매우 강력한 로컬 경로를 제공합니다. 일반적인 경우 약 59 tok/s, QAT 매칭된 MTP/Q8 설정을 사용할 경우 약 71 tok/s를 기록합니다. 중요한 업데이트 사항은 QAT 매칭된 어시스턴트 헤드(assistant heads)가 매우 중요하다는 점입니다. 일반적인 non-QAT 어시스턴트 헤드를 빌려 쓰는 것은 MTP가 로드될 수 있음을 증명하는 데는 유용했지만, 매칭된 QAT 헤드는 특히 26B-A4B 행에서 수용도를 실질적으로 개선했습니다.

저는 이러한 QAT MTP 행들을 순정(stock) upstream llama.cpp나 vLLM에서 로컬로 검증하지는 않았습니다. 여기서 측정된 주장은 /u/westsunset이 r/LocalLLaMA [link] [comments]에 제출한 Vulkan/RADV 기반의 Atomic llama.cpp TurboQuant 포크(fork)에 대한 것입니다.