본문으로 건너뛰기
r/LLMDevs조회 1회

Strix Halo에서 Qwen3.8-27B 추론 가속

Strix Halo에서 MTP와 ROCmFP4 조합으로 Qwen3.8-27B Decode가 최대 29.9 tok/s를 기록했습니다.

이 요약은 AI가 원문을 분석해 생성했습니다. 정확한 내용은 원문 기준으로 확인하세요.

TL;DR

Strix Halo 노트북의 Radeon 8060S에서 Qwen3.8-27B를 측정한 결과, Q8_0은 MTP 적용으로 Decode 속도가 7.3에서 22.4 tok/s로 증가했고 ROCmFP4 fork는 29.9 tok/s를 기록했습니다. FP4는 모델 메모리를 29 GB에서 14.6 GB로 줄였지만 긴 문맥에서 Prefill 하락이 더 컸으며, MTP의 가속 폭도 KV Cache가 커질수록 감소했습니다. ROCm과 Vulkan의 Decode 차이는 1% 이내였지만 Prefill은 ROCm이 앞섰고, FP4 fork에는 완료 길이 변동과 256k Prefill 충돌이라는 안정성 문제가 남았습니다.

합의점 vs 논쟁점

합의점

  • MTP는 Qwen3.8-27B의 짧은 문맥 Decode를 크게 높였지만 문맥이 길어지면 KV Cache 검증 비용 때문에 가속 폭이 감소했습니다. Q8_0에서는 빈 문맥 기준 3.1배, 128k 기준 2.0배, 256k 기준 1.15배의 차이가 측정됐습니다. 이 결과는 Draft acceptance만으로 실제 장문 처리량을 판단하기 어렵다는 점을 뒷받침합니다.
  • ROCmFP4 FAST는 메모리 사용량과 Decode 속도에서 Q8_0보다 유리했습니다. 다만 긴 문맥의 Prefill 하락과 Greedy 동일성 및 안정성 문제가 함께 기록됐습니다. 따라서 메모리 여유가 부족하거나 출력 생성 속도가 우선인 구성과 긴 입력의 안정적 처리가 우선인 구성을 구분해야 합니다.

논쟁점

  • ROCmFP4 fork의 29.9 tok/s는 가장 높은 수치였지만 완료 길이가 152~160토큰으로 변하고 256k Prefill에서 두 차례 충돌했습니다. 반면 stock llama.cpp는 같은 조건에서 164토큰으로 안정적이었습니다. FP4 수치를 실사용 기본값으로 채택하려면 정확한 Greedy 동일성과 장시간 안정성을 추가로 검증해야 합니다.

실용적 조언

  • Q8_0에서 MTP를 적용할 때 초안 길이 5부터 시험하고, FP4 구성에서는 길이 6을 비교 기준으로 삼는 편이 합리적입니다. 실행 시 `--spec-type draft-mtp`와 `--spec-draft-n-max N`을 사용하면 해당 설정을 재현할 수 있습니다. 측정은 벽시계 시간보다 llama.cpp의 timings block을 사용하고, 각 요청 중 클럭과 package power를 함께 기록해야 실제 Boost 상태를 확인할 수 있습니다.
  • 긴 문맥 서비스에서는 빈 문맥의 MTP 배수를 그대로 기대하지 않아야 합니다. Q8_0의 Prefill은 문맥이 비어 있을 때 277 tok/s였지만 256k에서 75 tok/s로 줄었고, MTP Decode 이득도 22.4 tok/s에서 5.4 tok/s로 축소됐습니다. 128k 이상 입력이 빈번하면 Q8_0과 FP4의 Prefill, 메모리, 안정성을 함께 측정한 뒤 선택해야 합니다.

섹션별 상세

01
Strix Halo 노트북의 Radeon 8060S와 128 GB 통합 메모리에서 Qwen3.8-27B의 Decode 속도를 llama.cpp 타이밍 블록으로 세 번씩 측정했습니다. Q8_0은 MTP를 끄면 7.3 tok/s였지만 초안 길이 5의 MTP를 켜면 22.4 tok/s로 올라갔고, Draft acceptance는 73%였습니다. 동일한 검증 절차가 토큰 품질을 유지하므로 이 결과는 단순한 출력 샘플링 변경이 아니라 추론 반복을 줄인 효과로 해석됩니다.
text
--spec-type draft-mtp
--spec-draft-n-max N
--fit-ctx 16384

llama.cpp에서 MTP를 켜고 초안 길이와 문맥 적합 힌트를 지정하는 실행 플래그입니다.

text
--host 127.0.0.1
--port 41100
-m .gguf
--mmproj mmproj-F16.gguf
--jinja

LlamaStash가 서버 주소, 모델 파일, 멀티모달 보조 파일과 Chat Template 처리를 위해 전달한 기본 플래그입니다.

text
--spec-draft-n-max 5

Q8_0 구성에서 MTP 초안 생성 길이를 5로 설정한 플래그입니다.

text
--spec-draft-n-max 6

ROCmFP4 FAST 구성에서 가장 높은 측정치를 낸 초안 생성 길이 설정입니다.

text
--cache-type-k f16
--flash-attn on
--n_ctx 262144
--n_parallel 4
--n_gpu_layers -1

KV 캐시 형식, Flash Attention, 최대 문맥, 병렬 슬롯과 GPU 레이어 오프로딩에 적용된 실행 설정입니다.

02
MTP의 가속 폭은 문맥이 길어질수록 줄었습니다. Q8_0 Decode는 빈 문맥에서 7.3 / 22.4 tok/s였지만 64k에서는 6.4 / 14.2 tok/s, 128k에서는 5.7 / 11.3 tok/s, 256k에서는 4.7 / 5.4 tok/s로 감소했습니다. KV Cache가 커질수록 초안 토큰을 검증하는 Pass의 비용이 증가하기 때문에 Draft acceptance가 유지돼도 긴 문맥에서는 MTP의 이득이 1.15배까지 축소됐습니다.
03
ROCmFP4 FAST는 메모리 사용량을 Q8_0의 29 GB에서 14.6 GB로 줄이면서 원시 Decode 속도를 13.0 tok/s로 높였습니다. MTP와 초안 길이 6을 함께 적용하면 29.9 tok/s에 도달해 Q8_0 기본 구성의 7.3 tok/s보다 4.1배 빠른 결과가 나왔고, Draft acceptance는 84%였습니다. 다만 FP4의 4k 토큰 Prefill은 빈 문맥에서 283 tok/s였으나 128k에서 70 tok/s로 떨어져 장문 입력 처리보다 Decode 가속에 강점이 집중됐습니다.
04
ROCm과 Vulkan은 Q8_0 Decode에서 각각 22.4 tok/s와 22.6 tok/s로 거의 차이가 없었습니다. 반면 4k 토큰 Prefill은 ROCm 277 tok/s, Vulkan 209 tok/s로 Vulkan이 뒤처졌고, rocWMMA 빌드도 추가 이득을 만들지 못했습니다. 따라서 이 크기의 모델에서는 짧은 출력 생성보다 입력 처리 속도가 중요한 경우 ROCm을 기본 선택으로 삼을 근거가 생겼습니다.
05
초안 길이 5는 Q8_0에서, 6은 FP4에서 가장 높은 처리량을 냈으며 문맥 길이에 따라 최적 길이가 바뀌지는 않았습니다. KV cache q8_0은 초안 길이 3에서는 도움이 됐지만 길이 5에서는 약간 느려졌고, Flash Attention을 끄자 성능이 5% 감소했습니다. ROCmFP4 fork는 같은 프롬프트에서 완료 길이가 152~160토큰으로 흔들렸고 256k Prefill 중 약 30분 뒤 98C 부근에서 두 차례 충돌해, 기본 llama.cpp와 완전히 같은 Greedy 결과로 보기는 어려웠습니다.

용어 해설

MTP
— MTP는 모델이 다음 토큰 후보를 초안으로 여러 개 생성한 뒤 원래 모델이 한 번에 검증하는 추론 방식입니다. 검증된 토큰만 출력하므로 기본 모델의 품질을 유지하면서 Decode 반복 횟수를 줄입니다.
KV 캐시(KV Cache)
— KV Cache는 이전 토큰의 Attention 계산에 필요한 Key와 Value를 저장해 긴 대화에서 같은 계산을 반복하지 않게 하는 메모리 구조입니다. 문맥이 길어지면 저장량과 검증 비용이 커져 MTP의 가속 폭이 줄어듭니다.
FP4 양자화(FP4)
— FP4는 모델 가중치를 4비트 부동소수점 형식으로 저장해 메모리 사용량을 줄이는 양자화 방식입니다. 이 측정에서는 Q8_0보다 모델 메모리는 작았지만 긴 문맥의 Prefill 처리량은 더 빠르게 감소했습니다.
초안 토큰 수용률(Draft acceptance)
— Draft acceptance는 초안 모델이 만든 토큰 가운데 원래 모델의 검증을 통과한 토큰의 비율입니다. 수용률이 높을수록 한 번의 검증에서 더 많은 토큰을 확정할 수 있어 Speculative Decoding의 처리량이 커집니다.
ROCm
— ROCm은 AMD GPU에서 머신러닝 연산을 실행하기 위한 소프트웨어 플랫폼입니다. 이 측정에서는 ROCm과 Vulkan의 짧은 출력 생성 속도는 1% 이내였지만 4k 토큰 Prefill에서는 ROCm이 더 높은 처리량을 냈습니다.

언급된 도구

LlamaStash추천링크

llama.cpp 실행을 관리하고 MTP 플래그와 모델 경로를 전달해 측정 구성을 재현하는 도구입니다.

llama.cpp추천

ROCm 및 Vulkan에서 Qwen3.8-27B를 실행하고 Decode와 Prefill timings를 제공한 추론 엔진입니다.

julianmb/q38rocm중립링크

Qwen3.8-27B의 ROCmFP4 FAST 실행에 사용한 llama.cpp fork입니다.

언급된 리소스

AI 분석 전체 내용 보기

AI 요약 · 북마크 · 개인 피드 설정 — 무료

출처 · 인용 안내

원문 발행 2026. 08. 23.수집 2026. 08. 23.출처 타입 REDDIT

인용 시 "요약 출처: AI Trends (aitrends.kr)"를 표기하고, 사실 확인은 원문 보기 기준으로 진행해 주세요. 자세한 기준은 운영 정책을 참고해 주세요.