AMD Says 2 Ryzen AI Halos Can Run a 400B Model... I Tested It

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

두 대의 Ryzen AI Halo는 10GbE 기반 모델 분할로 400B급 AI 모델을 실제 구동할 수 있지만, 실용성은 메모리 용량보다 추론 방식과 동시 요청 처리 성능에 좌우된다.

📌 핵심 요점

1. Ryzen AI Halo 두 대를 묶으면 GPU에 이론상 약 240GB를 할당할 수 있어, 단일 128GB 장비에는 들어가지 않는 GLM 4.7 358B와 Qwen 3.5 397B급 양자화 모델을 로컬에서 실행할 수 있다.
2. 두 장비의 메모리는 자동으로 합쳐지지 않는다. 모델을 나누어 적재하고 생성 과정에서 지속적으로 데이터를 교환해야 하므로, 실측 9.41~9.44Gbps인 10GbE 네트워크가 전체 성능을 좌우한다.
3. llama.cpp RPC는 Halo 2의 GPU 메모리를 Halo 1이 원격으로 사용하는 단순한 구조다. GLM 4.7에서 단일 요청은 약 7.6~8.2토큰/초, 짧은 프롬프트의 동시 요청 네 개는 약 13~13.5토큰/초를 기록했다.
4. RPC에서 동시 요청 네 개의 프롬프트를 2,048토큰으로 늘리자 처리량은 5.5토큰/초로 하락했다. 따라서 거대한 모델을 이용한 한두 개의 대화에는 적합하지만, 다중 사용자나 멀티에이전트 환경에는 동시성 병목이 생길 수 있다.
5. vLLM·Ray·RCCL 텐서 병렬화는 설정과 기동이 더 복잡하지만, Qwen 3.5 397B에서 단일 요청 약 7.81토큰/초와 동시 요청 네 개 최대 약 18토큰/초를 기록해 RPC보다 높은 동시 처리 확장성을 보였다.

🧩 배경과 문제 정의

• Ryzen AI Halo는 CPU·GPU가 최대 128GB 메모리를 공유하는 소형 APU 시스템이며, 두 대를 묶으면 단일 장비에 담기 어려운 400B급 모델까지 구동할 가능성이 생긴다.
• 두 장비의 메모리는 자동으로 합쳐지지 않으며, 모델 분할과 지속적인 GPU 간 통신이 필요하다. 유일한 연결 수단인 10GbE가 병목이 되면 대형 모델을 실행해도 실용적인 생성 속도를 확보하기 어렵다.
• 단순한 단일 사용자 추론에는 llama.cpp RPC가 적합하지만, 동시 요청과 다중 사용자 환경에서는 vLLM·Ray·RCCL 기반 텐서 병렬화가 더 복잡한 대신 확장성에서 유리하다.

🕒 시간순 섹션별 상세정리

1. 두 대의 Ryzen AI Halo로 400B급 모델에 도전

• Ryzen AI Halo 한 대는 CPU와 GPU가 약 128GB 메모리를 공유하며, AMD 기준으로 최대 200B급 모델을 로컬에서 실행할 수 있다. 두 대를 클러스터링하면 총 256GB에 가까운 메모리로 약 400B급 모델까지 범위가 넓어진다. [00:09]
• 모델을 두 장비에 분할하면 생성 과정 내내 GPU 간 데이터 교환이 필요하고, 이 장비에서는 10GbE만 사용할 수 있어 네트워크 성능이 전체 구성을 좌우한다. [00:59]

2. RPC와 RCCL, 두 가지 클러스터링 방식

• llama.cpp RPC는 한 장비가 루트 노드가 되고 다른 장비의 GPU 메모리를 원격으로 빌리는 단순한 구조다. vLLM·Ray·RCCL 방식은 텐서 병렬화로 모델 연산을 분할해 동시 처리 확장성을 높인다. [01:25]
• 두 방식 모두 128GB 장비 두 대의 메모리를 합쳐 사용하지만 운영체제 몫을 제외해야 하며, 장비를 직접 연결하는 대신 중간에 10GbE 스위치가 필요하다. [02:07]

3. 동일한 Linux 환경과 10GbE 네트워크 준비

• 클러스터링 플레이북은 Linux만 지원하므로 Windows 장비의 SSD에 기존 Linux 설치를 복제했다. 두 장비는 드라이버와 AMD 소프트웨어 구성이 같아졌지만, 복제된 호스트 이름은 Halo 1과 Halo 2로 분리해야 했다. [04:35]
• 장비 상단과 측면의 통풍구를 막지 않도록 간격을 두고 배치했으며, iperf3 측정값은 9.41~9.44Gbps로 10GbE의 실효 한계에 가까웠다. [05:48]

4. GPU 공유 메모리 120GB 확보와 숨은 제한

• Linux에서는 장비당 약 125GB의 시스템 메모리 중 최대 120GB를 GPU에 배정할 수 있어, 두 대에서 이론적으로 약 240GB 크기의 모델을 적재할 수 있다. Windows의 최대치는 96GB이며 Linux도 별도 명령 없이는 120GB가 활성화되지 않는다. [06:42]
• Windows에서 설정된 64GB GPU 메모리 제한은 Linux 설치 후에도 남았고 BIOS나 AMD TTM 명령으로 바뀌지 않았다. 이 상태에서는 llama.cpp RPC도 해당 장비의 메모리를 64GB로만 인식했다. [07:30]

5. GLM 4.7과 동적 4비트 양자화 선택

• llama.cpp는 Lemonade SDK나 수동 소스 빌드로 설치할 수 있으며, 플레이북의 대상 모델은 358B 파라미터를 가진 GLM 4.7의 UD-Q4_K_XL 양자화 버전이다. [08:34]
• UD 양자화는 모든 텐서에 동일한 4비트를 적용하지 않고 attention·router·embedding처럼 중요한 텐서에는 더 많은 비트를, 거대한 MoE 계층에는 더 적은 비트를 배분해 바이트당 품질을 높인다. [10:11]

6. llama.cpp RPC의 구조와 단일 요청 성능

• Halo 2가 GPU를 RPC 작업자로 노출하고 Halo 1이 루트 노드로 이를 사용하는 구조라 설정이 비교적 단순하며, GLM 4.7의 텍스트 생성 속도는 초당 약 8.2토큰에 도달했다. [11:31]
• 생성 과정에서 GPU 사용률은 처리 단계에 따라 약 50%와 100% 사이를 오갔고, 단일 동시 요청의 반복 측정값은 초당 약 7.6~7.93토큰이었다. [11:57]

7. 긴 프롬프트에서 드러난 RPC의 동시성 한계

• 동시 요청 네 개에서 프롬프트 길이를 2,048토큰으로 늘리자 처리량이 초당 5.5토큰으로 떨어졌다. 다중 사용자 워크스페이스나 멀티에이전트 시스템처럼 여러 요청이 겹치는 환경에서는 이 하락이 직접적인 병목이 된다. [13:02]
• RPC는 거대한 모델을 적재해 한두 개 대화를 처리하는 용도에는 충분하지만, 요청 수가 늘어날수록 llama.cpp에 별도의 동시성 최적화가 필요하다. [13:17]

8. vLLM·Ray·RCCL 클러스터 구성

• vLLM 방식은 RCCL 통신과 텐서 병렬화를 이용해 두 장비에서 Qwen 3.5 397B를 실행하며, Podman 컨테이너와 Ray가 각각 실행 환경과 다중 노드 통신을 담당한다. [14:23]
• 397B 모델은 시작에 약 15분이 걸리고 플래그 하나가 잘못돼도 처음부터 다시 기다려야 한다. 같은 MoE 구조의 작은 Qwen 3.5 모델로 명령과 구성을 먼저 검증하는 편이 실패 비용을 줄인다. [15:01]

9. Qwen 3.5 397B 실측과 활용 범위

• Qwen 3.5 397B 실행 중 두 장비는 각각 약 110GB, 총 220GB를 사용했고 GPU 사용률은 100%에 도달했다. 한 장비의 측정값은 VRAM 36%, 전력 60W, 온도 52°C였다. [15:59]
• RCCL이 10GbE 링크로 통신하는 텐서 병렬화 구성에서 단일 동시 요청은 초당 약 7.81토큰, 동시 요청 네 개는 최대 약 18토큰을 기록해 RPC보다 높은 동시 처리 확장성을 보였다. [16:38]

🧾 결론

• AMD의 주장은 조건부로 실현됐다. 두 대의 Ryzen AI Halo는 약 220GB를 사용하는 Qwen 3.5 397B를 적재하고 실제 텍스트를 생성했다.
• 핵심 가치는 단순히 400B급 모델이 실행된다는 사실보다, 출력 품질 저하가 큰 초저비트 양자화로 내려가지 않고 더 높은 품질의 대형 모델을 로컬에서 운용할 수 있다는 데 있다.
• 단일 사용자 중심이면 llama.cpp RPC의 단순성이 유리하고, 여러 요청이 겹치는 서비스라면 설정 비용을 감수하더라도 vLLM·Ray·RCCL 구성이 더 적합하다.
• 이 구성의 실제 한계는 메모리 총량만이 아니라 10GbE 통신, 긴 프롬프트, 동시 요청 수, 초기 기동 시간의 결합으로 결정된다.

📈 투자·시사 포인트

• 대용량 공유 메모리를 갖춘 APU는 데이터센터 GPU를 완전히 대체하기보다, 고성능 로컬 추론과 소형 AI 클러스터라는 새로운 하드웨어 수요를 만들 가능성을 보여준다.
• 로컬 AI 시장의 경쟁 기준은 단일 장비의 연산 성능에서 메모리 용량, 네트워크, 양자화 품질, 분산 추론 소프트웨어를 결합한 시스템 효율로 확대될 수 있다.
• llama.cpp처럼 접근성이 높은 도구와 vLLM·Ray·RCCL처럼 동시 처리에 유리한 스택이 서로 다른 사용자층을 형성할 가능성이 있다.
• AMD가 언급한 동일 칩 기반 4노드 구성이 발전하려면 10GbE 병목, 복잡한 초기 설정, 긴 모델 기동 시간을 줄이는 소프트웨어와 네트워크 개선이 중요하다.

⚠️ 불확실하거나 확인이 필요한 부분

• 측정 결과는 특정 Linux·드라이버·AMD 소프트웨어 구성과 특정 양자화 모델에 기반하므로, 다른 버전이나 모델에서도 동일한 처리량이 재현되는지는 확인이 필요하다.
• 제목의 400B는 정확히 400B인 모델의 실측이 아니라 358B GLM 4.7과 397B Qwen 3.5를 통해 검증한 400B급 범위를 의미한다.
• 동시 요청 네 개에서 기록한 최대 약 18토큰/초는 전체 처리량에 가까운 지표로 보이며, 각 사용자가 체감하는 개별 응답 속도와는 구분해서 해석해야 한다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 구축 전에 두 장비의 Linux·드라이버·AMD 소프트웨어 버전을 맞추고, 호스트 이름과 10GbE 인터페이스를 각각 확인한다.
• AMD Ryzen AI Developer Center에서 장비당 GPU 공유 메모리가 120GB로 설정됐는지 검증하고, llama.cpp가 실제 할당량을 인식하는지 확인한다.
• iperf3로 장비 간 처리량이 10GbE의 실효 한계에 가까운지 측정한 뒤 모델을 적재한다.
• 397B 모델을 바로 기동하기 전에 같은 MoE 구조의 작은 Qwen 3.5 모델로 Podman·Ray·RCCL 명령과 플래그를 검증한다.

❓ 열린 질문

• 4노드 Ryzen AI Halo 클러스터에서도 10GbE 기반 RCCL 텐서 병렬화가 처리량을 유의미하게 높일 수 있는가?
• 더 빠른 네트워크를 사용할 수 있다면 긴 프롬프트와 다중 요청에서 나타난 처리량 하락을 얼마나 줄일 수 있는가?
• llama.cpp의 동시성 최적화가 개선되면 RPC의 단순성을 유지하면서 vLLM·RCCL에 가까운 다중 요청 처리량을 달성할 수 있는가?