이 사진은 벤치마크 설정을 나타내는 것이 아니라, 3개의 GPU에서 동일한 모델을 실행하는 방법을 알아내던 중 즐겁게 찍은 사진입니다. Halo는 항상 바쁘고, 3090들은 Halo가 자기 일을 하기를 기다리고 있습니다.

요약하자면.

1. Strix Halo 단독 사용 (124GB UMA VRAM)만으로도 이미 훌륭하지만, 1개 또는 2개의 eGPU를 추가하는 것은 최근 인기를 끌고 있는 27B 또는 31B 밀집 모델 (dense models)을 실행하는 데 매우 좋습니다.

2. eGPU의 네이티브 대역폭 (native bandwidth) 제한을 완화할 수 있습니다. 저는 3090에 간단한 쿨링 모딩을 더해 2슬롯 NVLink (3슬롯보다 저렴함) 설정을 구성하기 위해 고군분투했습니다. 상황에 따라 작은 밀집 모델에서 PP/s (prefill tokens per second) 및 TG/s (generation tokens per second)가 최대 몇 배까지 향상되는 것을 경험할 수 있으며, 이는 멀티 코딩 에이전트 (multi coding agents) 시나리오에서 유용할 수 있습니다.

3. 기본적으로 라이저 케이블 (riser cable)을 사용하면 일반적인 메인보드의 PCIe 3090 카드에 작은 모딩을 가하여 2슬롯 NVLink를 맞출 수 있는 eGPU의 슬롯 유연성을 확보할 수 있습니다.

4. vLLM의 KV캐시 (KVcache) 유형에 따라 최대 컨텍스트 길이 (max context length)와 동시 요청 (concurrent requests) 수가 달라질 뿐만 아니라, 긴 컨텍스트에서의 속도도 크게 차이 납니다. 처음에는 좋아 보일 수 있지만, 장기적인 실행 측면에서는 유망하지 않을 수 있습니다.

5. 전력 효율성 측면에서, 27B 밀집 모델은 eGPU에서 와트당 더 나은 PP/s 및 TG/s를 보여줍니다. 하지만 122B 모델의 경우, llama.cpp를 통해 Strix Halo 단독으로 실행하는 것이 3개의 GPU를 결합하여 사용하는 것보다 더 나은 전력 효율을 보여주었습니다.

6. NVLink는 llama.cpp의 레이어 분할 (layer split)에서 아무런 역할을 하지 않습니다. 최근의 -sm 텐서 (tensor) 방식을 시도해 보았을 때, Tg/s는 약 30% 정도 향상되었으나 pp/s 성능 저하가 너무 커서 중단하였고, 듀얼 3090 환경에서 vLLM을 계속 사용하고 있습니다.

저는 제 Bosgame M5 Strix Halo의 27B, 31B 밀집 모델에서의 상대적으로 느린 PP/s 때문에 다소 좌절감을 느끼고 있었고, 이를 극복하기 위해 몇 가지 시도를 해보기로 했습니다. 최근 이러한 밀집 모델들이 70B+ MoE 모델보다 훨씬 더 많은 관심을 받고 있습니다. 이 모델들을 더 잘 실행하기 위해 지역 중고 시장을 통해 단일 3090을 구매했고, 성능 향상을 확인한 후 곧바로 두 개의 NVMe PCIe 4x4를 통한 듀얼 eGPU 설정으로 넘어갔습니다.

제 eGPU 케이스에서 NVLink (NVLink)가 제대로 작동할지 보장할 수 없었고, 3슬롯 NVLink 브릿지는 너무 비쌌기 때문에 (600달러 이상) 시도하기를 망설였습니다. 그럼에도 불구하고 CPU를 거쳐야 하는 eGPU의 PHB (PCIe Host Bridge) 속도를 개선할 수 있을지 확인하고 싶었습니다.

하지만 제 것을 포함한 대부분의 3090 카드는 3슬롯 두께였기에, 결국 관세 등을 포함해 약 250달러에 2슬롯 브릿지를 구매하게 되었습니다.

이를 위해 상단 3090의 3팬 슈라우드 (fan shroud)를 제거하고, 3D 프린팅된 측면 블로우 덕트 (side blow duct)를 사용하여 120mm 팬을 대략적으로 부착해 맞췄습니다. 놀랍게도, 이렇게 개조된 3090의 온도는 하단의 개조되지 않은 카드보다 실제로 더 낮게 유지되었습니다.

테스트 환경 (Test Environment):

• Fedora 43
• llama cpp: Strix halo 성능 전력 모드 (performance power mode), 빌드 9221.
  • 122B 테스트는 rocm 7.2.3 및 cuda를 사용하여 -sm layer로 분할되었습니다.
  • 27B 테스트는 rocm 7.2.3을 기준으로 사용했습니다. (rocm 7.2.3과 vulkan radv를 비교했을 때, rocm은 더 나은 pp/s를 보여주었고 vulkan은 더 나은 tg/s를 보여주었습니다). 벤치마크는 단 2회만 반복되었습니다.
  • 참고: llama cpp 벤치마크에 MTP (Multi-Token Prediction)가 아직 완전히 구현되지 않았기 때문에, 시뮬레이션된 MTP 라인을 그리기 위해 kyuz0의 strix halo 툴박스에서 27B 및 122B(35B A3B MoE 통계 사용)에 대한 code_python MTP 지표(-pp/s% 및 +tg/s%)를 빌려왔습니다. (https://kyuz0.github.io/amd-strix-halo-toolboxes/mtp.html)
• vLLM: Nightly 빌드. 3090은 각각 230W로 전력 제한되었습니다.
• vLLM 벤치마크는 Club 3090의 방향을 따랐습니다:
  • 서사 (Narrative): "Transformer attention을 설명하는 상세한 800단어 에세이를 작성하세요." (max_tokens=1000)
  • 코드 (Code): "각 단계를 설명하는 주석이 포함된 quicksort의 Python 구현을 작성하세요." (max_tokens=800)
  • 샘플링 (Sampling): temp=0.6, top_p=0.95, top_k=20, presence_penalty=0.0, enable_thinking=false. 3회의 웜업 (warmup)과 5회의 측정 실행.
  • Club 3090에는 컨텍스트 깊이 (context depth) 기반의 벤치마크가 없기 때문에, 해당 테스트를 추가했습니다.

벤치마크 대상 vLLM 모델 - Qwen 3.6 27B

벤치마크 대상 vLLM 모델 - Qwen 3.6 27B

결과 (Results):

Triple : dual 3090 + Strix halo

122B Q4 K XL unsloth, q8_0, Strix Halo vs Triple

Strix halo (llama cpp 27B MTP Q6 K XL unsloth, mmproj 포함 25GB)
vs Dual 3090, Qwen3.6-27B-Mixed-AutoRound Minachist 28.9GB)
품질이 상당히 우수하면서도 크기 면에서 유사하기 때문에 이 양자화(quants) 모델들을 선택했습니다.

전력 효율 (Power efficiency)
대략적인 계산이지만, 27B 밀집 모델 (dense models)의 경우 eGPU 설정이 더 나은 전력 효율을 보입니다. 하지만 122B 모델을 실행할 때는 llama cpp로 구동되는 Strix halo 단독 구성이 실제로 더 전력 효율적이었습니다.

NVLink On / Off

NVLink를 켰을 때와 껐을 때를 테스트했습니다. 동시성 (concurrency)과 컨텍스트 (context)가 증가함에 따라, NVLink가 대역폭 병목 현상 (bandwidth bottleneck)을 상당히 잘 방어해 줍니다.

BF16 캐시 시나리오

fp8 캐시 케이스

INT4 양자화의 fp8 시나리오

Gemma4 31B의 케이스
Gemma-4-31B-it-AutoRound-AWQ, mattbucci, BF16 캐시

이는 양자화 및 KV 캐시 유형에 따른 차이를 보여줍니다. 캐시 유형을 변경하는 것만으로 최대 컨텍스트 길이와 속도가 얼마나 변동하는지 확인할 수 있습니다.
Ampere 카드에서 TQ3는 더 많은 컨텍스트 양을 제공할 수 있음에도 불구하고, Tg/s를 유지하는 데 상당히 좋지 않았습니다.

Code vs Narrative MTP

Code vs Narrative MTP

동시성 (Concurrency)이 1일 때는 코드 생성 (Code generation)이 항상 서사 (Narrative)보다 빠릅니다. 하지만 보시는 바와 같이, 동시성이 2이고 더 깊은 컨텍스트 (Context)로 진입하면 코드 속도는 떨어지고 서사 속도가 이를 역전합니다. 동시 요청 (Concurrent requests)과 긴 컨텍스트 (Long context)가 결합될 때 기이한 부하가 발생하는 것으로 보입니다.

다음 분들께 깊은 감사를 드립니다:
Club 3090 (https://github.com/noonghunna/club-3090/tree/master),
kyuz0's toolbox (https://github.com/kyuz0/amd-strix-halo-toolboxes), 그리고 DasDigitaleMomentum's distrobox (https://github.com/DasDigitaleMomentum/strix-halo-cuda-combined-toolbox)