저는 llama.cpp Kubuntu와 Vulkan 백엔드를 사용하여 새로운 Gemma 4 및 Qwen 3.6 MoE 모델이 제 미니 PC 설정(AMD Ryzen 7 6800H)에서 어떻게 작동하는지 확인하기 위해 벤치마킹을 진행해 왔습니다. 이것은 APU이기 때문에, 저는 전적으로 공유 시스템 메모리 (Shared System Memory, UMA)와 Radeon 680M iGPU에 의존하고 있습니다. 여기에는 전용 VRAM이 없으며, iGPU가 시스템 RAM에서 데이터를 가져올 뿐입니다. 메모리 할당량을 1GB에서 16GB까지 다양하게 조절해 보았으나 추론(inference)에는 영향을 미치지 않았습니다. 성능 대 지능의 '스윗 스팟(sweet spot)'이 어디인지 확인하기 위해 여러 양자화(quantization) 유형(NVFP4, Q4_K, Q8_0)을 실행했습니다. 결과는 다음과 같습니다:

벤치마크 결과 (t/s) 모델 크기 순 정렬

주요 관찰 사항:

1. "MoE"의 이점 (Qwen 3.6 35B): Qwen 3.6 35B MoE 모델은 총 파라미터 수(35.51B) 측면에서 가장 크지만, 디코딩 속도(15.05 t/s 대 2.30 t/s)에서 31B Q8_0 모델을 크게 앞질렀습니다. 이는 iGPU/APU 사용자에게 전문가 혼합 (Mixture of Experts, MoE) 방식이 정답임을 증명합니다. 훨씬 더 작은 모델의 추론 속도로 대형 모델의 "지식"을 얻을 수 있습니다.

2. 양자화(Quantization) 및 메모리 대역폭: Q4_0에서 Q8_0로 넘어갈 때의 성능 저하는 엄청납니다. Q4_0는 매우 사용 가능한 수준인 약 18 t/s를 제공하는 반면, 31B 모델의 Q8_0는 매우 느려집니다 (2.3 t/s). 우리는 시스템 메모리 대역폭 (DDR5/LPDDR5)에 의해 제한을 받기 때문에, 모델의 점유 공간(footprint)을 작게 유지하는 것이 매우 중요합니다.

3. NVFP4/MXFP4 성능: 새로운 FP4 형식들은 흥미롭습니다. 제 테스트에서 gemma4 26B NVFP4는 실제로 표준 Q4_0보다 느렸습니다.

이러한 특정 형식들이 진정한 효율성 이득을 보여주기 위해서는 Vulkan/AMD 드라이버 스택에서 여전히 추가적인 최적화 작업이 필요한 것으로 보입니다. 4. APU 사용자들을 위한 요약: 만약 6800H 또는 유사한 사양에서 실행 중이라면: 20B 파라미터(params)를 초과하는 모델에 대해서는 Q8 양자화(quantization)를 피하십시오. 높은 파라미터 지능을 사용 가능한 속도로 얻으려면 MoE 모델을 목표로 하십시오. 디코딩 속도(decoding speed)를 "읽기 속도" 임계값 이상으로 유지하려면 4비트(Q4_K 또는 Q4_0)를 고수하십시오. 시스템 사양: CPU/iGPU: AMD Ryzen 7 6800H (Radeon 680M) 백엔드(Backend): llama.cpp (Vulkan) OS: Linux/Kubuntu 26.04 https://preview.redd.it/j0mbrwo5ptfh1.png?width=720&format=png&auto=webp&s=ef6e600ba8d84604a91c7 submitted by /u/tabletuser_blogspot [link] [comments]