나만의 수치를 확인하고 싶어서 Strix Halo, RTX 3090, 그리고 RTX 5070에서 동일한 모델들을 실행해 보았습니다

이 모델들에 대한 추론 속도(inference-speed) 주장을 계속 접하면서, 제가 실제로 보유한 하드웨어에서 일대일 비교(apples-to-apples comparison)를 해보고 싶었습니다. 그래서 테스트 프레임워크(harness)를 구축하고 모든 실행 결과를 YAML로 덤프하는 공개 페이지를 만들었습니다.

데이터셋: 55회의 실행, 3개의 시스템(rigs), 5개의 백엔드(rocm, vulkan, cpu, cuda, vllm-cuda), 0.35B(LFM2.5)부터 35B-A3B(Qwen3.5 MoE)까지의 모델들. 워크로드(Workloads): 짧은 프롬프트 채팅, 긴 컨텍스트 RAG, 코드 생성(codegen) 긴 출력, 그리고 동시성(concurrency) 1 및 4에서의 에이전트 형태. 한 번의 웜업(warmup) 후 3회의 측정 반복, 온도(temperature) 0, 각 실행 전 VRAM 용량 적합성 확인.

데이터에서 나타난 몇 가지 패턴:

디코딩(decode)에서는 메모리 대역폭(Memory bandwidth)이 핵심입니다. RTX 5070 (12 GiB GDDR7, Vulkan)은 12 GiB에 들어가는 모든 모델에서 실제로 RTX 3090 (24 GiB GDDR6X, CUDA)을 앞섭니다:

Gemma-3-4b      chat:   5070 = 156.6  vs  3090 = 142.0   tok/s
Gemma-4-E4B     chat:   5070 = 124.3  vs  3090 = 118.4   tok/s
LFM2-8B-A1B     chat:   5070 = 336.1  vs  3090 = 318.7   tok/s

모델이 24 GiB에는 들어가지만 12 GiB에는 들어가지 않는 14-31B 대역에서는 3090이 압도적으로 승리합니다:

Gemma-4-26B-A4B chat:   3090 = 100.5  |  Strix ROCm = 43.7  |  Strix Vulkan = 47.7  tok/s
Qwen3.6-27B     chat:   3090 = 21.1   |  Strix ROCm = 11.2  |  Strix Vulkan = 11.6  tok/s

동일한 하드웨어/모델에서 Strix Vulkan이 Strix ROCm보다 종종 아주 약간 더 빠릅니다. 제가 본 가장 큰 차이는 Gemma-4-26B-A4B에서 +9% (43.7 → 47.7)였습니다. 일부 모델은 사실상 동등합니다. 아마도 번들로 제공되는 ROCm 빌드의 gfx1151 커널 튜닝(kernel tuning) 차이 때문일 것이나, 깊이 파고들지는 않았습니다.

Qwen3.6-27B 채팅에 대한 3090의 양자화(Quant) 비용:

Q2_K = 24.0   Q3_K_M = 20.5   Q4_K_M = 21.1   Q5_K_M = 18.6   Q6_K = 15.3   tok/s

Q2에서 Q6까지는 1.6배 범위입니다. Q4가 최적의 지점(sweet spot)입니다. Q2는 품질 저하를 대가로 Q4 대비 약 14%의 속도를 얻을 수 있으며, Q6는 품질 향상을 위해 약 28%의 비용을 지불합니다. 곡선이 이보다 더 가파르지 않다는 점이 놀랍습니다.

추론 모델(Reasoning models)은 출력 토큰/초(tok/s)만 관찰할 경우 실제보다 ~5배 더 느려 보입니다. Qwen3.5/3.6은 대부분의 출력을 디코딩 속도(decode rate)에는 포함되지만 사용자에게 보이는 답변의 일부는 아닌 숨겨진 reasoning_content 채널을 통해 스트리밍합니다. 코딩 어시스턴트(coding assistant)를 선택할 때 알아둘 만한 가치가 있는 정보입니다.

Strix의 CPU는 결코 무시할 수준이 아닙니다. Gemma-4-26B-A4B MoE는 통합 메모리(unified memory)와 활성 파라미터 라우팅(active-param routing) 덕분에 순수 CPU에서 약 5-9 tok/s로 실행됩니다. 빠르지는 않지만 GPU가 필요하지 않은 배치 작업(batch work)에는 사용 가능합니다.

더 자세히 파헤쳐 보고 싶다면 모든 실행 결과와 나머지 모델들이 있는 사이트를 확인하세요: https://calebcoffie.com/benchmarks. 방법론(Methodology) 및 나머지 글의 내용은 다음과 같습니다: https://calebcoffie.com/blog/introducing-open-weight-model-benchmarks.

아직 수행하지 못한 작업들: Strix에서의 vLLM (lemonade의 백엔드 준비 시간 초과로 인해 FP8 오토튜닝(autotune)이 중단됨; 수정 대기 중) 및 70-130B Strix 전용 모델들 (v2를 위해 대기 중). 저는 4090/5080/5090을 소유하고 있지 않으므로 해당 모델들은 포함되지 않았습니다; 글에는 대략적인 대역폭 추정치(back-of-envelope bandwidth extrapolation)가 포함되어 있습니다.

기존의 벤치마크 사이트들을 대체하려는 의도는 아닙니다. 그저 제 자신의 설정에 대한 또 다른 데이터 포인트를 원했을 뿐이며, 동일한 장비 조합이 다른 누군가에게도 유용할 것이라고 생각했습니다. 만약 누군가 결함을 발견한다면 방법론에 대해 틀렸음을 기꺼이 인정하겠습니다.