[LLM] R9700에서 Qwen3.6-27B 벤치마크

최근에 엔비디아의 4060ti에서 r9700으로 그래픽카드를 바꿨다.

 

vram이 너무 작기도 했고 조금 더 큰 모델을 돌려보고 정말 SOTA 모델들과 비슷한지 확인해보고 싶었다.

 

그래서 r9700으로 바꾸었고 소비자용 그래픽카드에서 돌릴 수 있는 모델 중 끝판왕이라는 qwen3.6 27b를 돌려보았다.

 

각설하고 결론부터 말하자면 아래와 같다.

 

용도	양자화	mtp	백엔드	속도
짧은 코딩 (≤8k)	Q6_K	n2	Vulkan b9430	48t/s
긴 코딩 (16k+)	Q6_K	n3	ROCm b1283	37t/s
긴 코드 한 방 생성	Q6_K	n3	Vulkan b9430	~60t/s
품질 최우선	UD-Q6_K_XL	n3	Vulkan/ROCm	42t/s
No MTP	Q6_K	off	ROCm	24t/s

 

---

어느정도 속도까지 나올까?

R9700은 메모리 대역폭이 640GB/s다.

 

Qwen3.6-27B Q6_K 모델을 올리면 vram을 22.5GB쯤 먹는다.

 

디코딩은 매 토큰마다 vram에 올린 가중치 전체를 한 번씩 읽어야 하니까, 단순 계산으로만 해보면 640 / 22.5 ≈ 28토큰/초 정도다.

 

실제로 MTP를 끈 상태에서 24t/s가 나왔다.

 

24t/s는 쓸 수는 있는데,, 음,, 뭐랄까 약간 애매한 느낌이다.

 

엄청 느린것도 그렇다고 실제 답답하지 않게 쓸 수 있도록 빠른것도 아니다.

 

중요한 건 28t/s는 현재 대역폭의 최대 한계라 아무리 튜닝을 잘 해도 넘을 수 없는 값이다.

 

퀄리티를 포기하면서 양자화를 더 줄이거나 토큰당 읽는 양 자체를 줄이지 않는 한 넘을 수 없다.

 

그래서 이걸 넘기는 유일한 방법이 spec decoding이다.

 

spec decoding은 작은 draft 모델이 여러 토큰을 미리 추측하고 본 모델이 한 번에 검증하는 방식이라, 검증 한 번에 토큰을 여러 개 건지면 토큰당 평균 대역폭 비용이 깎인다.

 

Qwen3.6은 MTP(Multi-Token Prediction) head가 모델에 내장돼 있어서 별도 draft 모델 없이 이게 된다.

 

24t/s의 한계를 뛰어넘을 수 있게 해준건 MTP를 사용해서 그렇고 앞으로의 내용은 모조리 MTP를 사용한 환경이다.

 

측정 환경

• HW: AMD R9700 (gfx1201 / RDNA4, 32GB), i7-10700 시스템에 단독 장착
• 엔진: llama.cpp
  • ROCm 빌드(b1283)
  • Vulkan 빌드(b9430·b9265)
• 모델: Qwen3.6-27B (Q6_K / Q8_0 / UD-Q6_K_XL)
• 워크로드: 실제 코딩 프롬프트 + depth(누적 컨텍스트)별 sweep
• 샘플링(non-thinking): temp 0.6 / top-k 20 / top-p 0.95 / min-p 0 / presence-penalty 1.5

ROCm 쪽은 ROCBLAS_USE_HIPBLASLT=0 환경변수가 없으면 제대로 돌지 않아서 추가해줬다.

 

그리고 Windows ROCm은 idle 상태에서 GPU 점유율이 100%로 박히는 버그가 있어서 이것도 감안해야 한다.

 

벤치마크 결과

 

벤치마크하는데 있어서 시간이 꽤 걸렸다.

 

1. 밤샘 벤치: "ROCm이 디코딩 우위, 코딩은 Q6_K + MTP n3 = 45t/s." 그럴듯했는데, 알고 보니 비교 기준이 No MTP라서 부분적으로 틀린 결론이었다.
2. 커뮤니티 설정을 여러 각도로 조사: 비대칭 KV 캐시(K는 q8, V는 q4)가 AMD의 fused flash attention을 깨뜨린다는 단서가 나왔다. 그리고 Vulkan이 긴 컨텍스트에서 유리할 수 있다는 정황.
3. 재측정: Vulkan MTP가 ROCm보다 빨랐다(46.7 vs 42.3t/s). "ROCm 우위"라던 첫 결론이 여기서 뒤집혔다. 비대칭 KV는 실제로 1.56배 느렸다.
4. draft-p-min 재검토: 내가 임의로 0.5로 올려놨던 값을 0으로 내리니 +5%. 괜히 손해 보고 있었던 거다.
5. acceptance(채택률) 측정: n3 → n2. Vulkan에 p-min 0 조합에서는 채택률 높은 n2가 더 안정적으로 빨랐다. 그리고 양자화마다 최적 mtp 깊이가 다르다는 걸 알게 됐다.
6. 종합 매트릭스: 마지막엔 백엔드가 컨텍스트에 따라 갈린다는 결론. 짧으면 Vulkan, 길면 ROCm.

 

핵심 발견 1 - 양자화마다 최적 MTP 깊이가 다르다

MTP는 한 번에 몇 토큰을 미리 추측할지(n)를 정한다.

 

깊게 추측할수록 맞으면 이득이 크지만 틀리면 그만큼 버린다.

 

그래서 무작정 깊게 한다고 빨라지지 않는다.

 

양자화	mtp	tg(짧은 ctx)	채택률	tg(8k)	비고
Q6_K	n2	46.2	78%	46.2	전체 최고
Q6_K	n3	45.6	71%	38.3	8k서 떨어짐
Q6_K	n4	32.3	54%	42.0	채택률 폭락
Q8_0	n2	37.1	75%	36.5
Q8_0	n4	41.2	59%	43.0	Q8은 깊게가 이득
Q6_K_XL	n3	35.0	53%	42.4	품질↑ ~12% 느림

 

왜 이렇게 갈리냐면, MTP 속도는 대충 (1 + n×채택률) / (검증비용 + n×draft비용)으로 움직인다.

 

검증은 대역폭 바운드라 토큰 수와 상관없이 비용이 거의 일정하다.

 

그래서

• 무거운 양자화(Q8)는 검증이 비싼 대신 깊게 가도 채택률이 버텨주니까(n4도 68%), n을 키워서 비싼 검증을 여러 토큰에 나눠 먹는 게 이득이다.
• 가벼운 양자화(Q6_K)는 검증이 싼 대신 n4에서 채택률이 54%로 폭락하니까, 작은 n2가 최적이다.

다만 절대 속도로는 Q6_K n2(46t/s)가 1등이다.

 

R9700은 어차피 대역폭 바운드라, Q8이 채택률에서 버는 이득이 메모리에서 보는 손해를 못 이긴다.

 

듀얼 3090(48GB) 같은 환경이면 여기서 결론이 갈릴 텐데, 단일 32GB에서는 Q6_K가 답이다.

핵심 발견 2 - 백엔드는 컨텍스트 길이에 따라 갈린다

이게 제일 헷갈렸던 부분이다.

 

ROCm vs Vulkan 둘 중 뭐가 빠른가에 단일 정답이 없었다.

• 짧은 컨텍스트(≤8k): Vulkan b9430이 압도적. Q6_K n2 + Vulkan = 48t/s.
• 긴 컨텍스트(16k+): Vulkan은 KV 캐시가 커지면 디코딩이 급락한다(48 → 31). ROCm은 완만하게 떨어진다(41 → 36). 그래서 16k 넘어가면 ROCm n3 = 37t/s가 낫다.

OpenCode 같은 에이전트로 코딩하면 컨텍스트가 길게 쌓이니까 ROCm이 유리하고, 짧은 단발 질의는 Vulkan이 유리한 셈이다.

 

하지만 이게 끝이 아니다.

 

위 수치는 순간 토큰 속도이고, 긴 코드를 한 번에 길게 뽑을 때의 누적 속도는 또 다르다.

 

누적 tg 기준으로는 Vulkan n3가 ROCm(~53)보다 높은 ~60t/s까지 나왔다.

 

커뮤니티에서 27B로 60t/s가 나온다는 얘기가 바로 이것이었다.

 

양자화·온도·전용 mtp gguf를 다 확인해봤지만 결국 백엔드(Vulkan n3)가 유일한 변수였다.

 

긴 코드를 뽑는 작업이라면 Vulkan n3가 맞다.

핵심 발견 3 - 하지 말아야 할 것들

빠르게 만드는 것보다 느려지는 함정을 피하는 게 체감상 더 컸다.

• 비대칭 KV 캐시 금지
  • K를 q8, V를 q4로 섞으면 AMD fused FA가 깨져서 1.56배 느려진다.
  • q8/q8이든 q4/q4든 대칭으로 맞춰야 한다.
  • 참고로 Qwen3.6은 32레이어 중 8개만 KV를 쓰는 hybrid라 q4/q4로 내려도 거의 무손실이다.
• Q4 + MTP 금물
  • 코딩에서 Q4에 MTP를 켜면 tool-call JSON 경계 같은 데서 draft가 자꾸 거부당해서 속도도 품질도 손해다.
  • 코딩은 Q5/Q6 이상에 MTP를 붙여야 한다.
• Q8은 16k 넘으면 VRAM이 넘친다
  • Q8_0이 27GB나 먹어서, 8k 컨텍스트에서 이미 VRAM 28.6GB + spill 1.4GB = 30GB/32GB다.
  • q8 KV로는 컨텍스트 32k가 사실상 한계다.
• Windows Vulkan은 --no-mmap 필수
  • mmap을 켜두면 가중치랑 KV가 시스템 RAM으로 새서 VRAM은 절반(15GB)만 차고 RAM은 31.9GB까지 차지한다.
  • 처음에 이거 모르고 왜 이렇게 느린지 찾느라 한참 헤맸다.
  • --no-mmap 붙이면 VRAM 28.5GB로 정상이다.
• Ollama 금지
  • 그냥 llama.cpp 직접 돌리는 것 대비 -56%. 편한 만큼 절반을 버린다.

그래서 결론

b9430-vulkan\llama-server.exe -m Qwen3.6-27B-Q6_K.gguf --device Vulkan1 -ngl 99 -fa on \
  -b 2048 -ub 512 -ctk q8_0 -ctv q8_0 --split-mode none --main-gpu 0 -c 16384 --no-mmap \
  --spec-type draft-mtp --spec-draft-n-max 2 --draft-p-min 0 \
  -np 1 --temp 0.6 --top-k 20 --top-p 0.95 --min-p 0 --presence-penalty 1.5 \
  --host 0.0.0.0 --port 8080

 

정밀함과 긴 컨텍스트를 동시에 챙기고 싶으면 UD-Q6_K_XL + q8 KV + 96k 컨텍스트 + MTP n3 조합이 vram 32GB에 딱 들어맞는다.

 

(UD-Q6_K_XL이 Q8과 크게 차이가 안났던걸로 알고 있다. 물론 정밀한 작업에서는 무조건 차이가 나겠지만)

 

q8 KV면 110k까지, q4로 내리면 160k 이상까지 여유가 있다.

 

RDNA4(gfx1201)는 아직 추론 소프트웨어 생태계가 무르익지 않아서, NVIDIA처럼 그냥 켜면 빠른 단계가 아니다.

 

백엔드 두 개를 컨텍스트에 따라 바꿔 끼우고, KV 대칭 맞추고, mmap 끄고... 손이 좀 많이 간다.

 

다만 한 번 세팅해두면 32GB짜리 카드로 27B를 50t/s 가까이 굴릴 수 있으니, 가격 생각하면 충분히 할 만한 것 같다.

 

그래서 나는 위의 세팅으로 사용하며 보통 초당 35~45 토큰으로 사용하고 있으며 생각보다 쓸만하게 사용하고 있다.

 

R9700 구매하고Qwen3.6-27b를 어떻게하면 가장 효율적으로 빠르게 가동할 수 있는지 고민하는분들께 이 글이 도움이 되었으면 한다.

 

 

 

PS. R9700에서 Qwen3.6-35b-a3b는 100~110t/s정도 나오니 참고하길 바란다.