1조 파라미터 LLM을 로컬에서 돌린다고? AMD Ryzen AI Max+ 클러스터 분석

최근 엔지니어링 커뮤니티에서 가장 뜨거운 감자는 단연 Local LLM 입니다. 다들 H100 클러스터를 집에 들여놓고 싶겠지만, 현실은 RTX 4090 한 장 가격에도 손이 떨리죠. 그런데 어제 AMD에서 꽤 도발적인 테크 블로그를 하나 공개했습니다. 바로 AMD Ryzen AI Max+ (코드명 Strix Halo) 4대를 묶어서 1조(Trillion) 파라미터 모델을 돌리는 실험 입니다.

솔직히 제목만 보고 “또 마케팅용 벤치마크겠지”라고 생각했습니다. 하지만 내용을 뜯어보고, Hacker News의 반응을 살펴보니 이건 단순한 마케팅 이상의 엔지니어링적 함의 가 있습니다. 오늘은 이 실험이 왜 중요하고, 동시에 어떤 치명적인 한계가 있는지 Principal Engineer의 시각에서 딥다이브 해보겠습니다.

1. 하드웨어 구성: “VRAM이 깡패다”

LLM 추론의 핵심은 결국 메모리 대역폭과 용량입니다. 이번 실험의 주인공인 Ryzen AI Max+ 395 는 통합 메모리 아키텍처를 사용합니다. Apple Silicon의 M 시리즈와 비슷한 접근이죠.

  • Node: 4x Framework Desktop (Ryzen AI Max+ 395)
  • RAM: 각 노드당 128GB (총 512GB)
  • Model: Kimi K2.5 (1 Trillion Parameters, Q2_K_XL 양자화)

여기서 재미있는 점은 리눅스 커널을 건드려 시스템 메모리를 강제로 VRAM처럼 쓰게 만드는 TTM(Translation Table Manager) 설정입니다. BIOS에서는 96GB까지만 할당되지만, 리눅스 커널 파라미터를 수정해 노드당 120GB를 GPU가 쓸 수 있게 만들었습니다.

# GRUB 설정 예시
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash ttm.pages_limit=30720000 amdgpu.gttsize=120000"

이 설정이 없었다면 1조 파라미터 모델은 로딩조차 불가능했을 겁니다. AMD가 하드웨어 스펙을 소프트웨어적으로 극한까지 쥐어짜는 모습을 보여주는 대목입니다.

2. 소프트웨어 스택: Llama.cpp와 RPC의 승리

과거 AMD의 ROCm은 엔지니어들에게 “고통의 동의어”였습니다. 하지만 이번 데모는 llama.cpp 생태계가 얼마나 성숙했는지 보여줍니다. 무거운 MPI(Message Passing Interface) 대신, llama.cpp에 내장된 RPC(Remote Procedure Call) 기능을 사용했습니다.

이 구조가 왜 영리하냐면:

  1. Main Node: 토크나이징과 스케줄링 담당.
  2. Worker Nodes: 단순히 VRAM과 연산 자원만 빌려줌.
  3. Result: 마치 하나의 거대한 480GB VRAM을 가진 단일 GPU처럼 동작.

복잡한 클러스터링 설정 없이 바이너리 몇 개만 실행하면 분산 추론 환경이 구축됩니다. lemonade-sdk 같은 툴을 쓰면 빌드 과정도 생략할 수 있죠. 이건 확실히 진입 장벽을 낮추는 요소입니다.

3. 성능 분석: 현실과 이상의 괴리

이제 불편한 진실을 이야기할 시간입니다. “돌아간다”와 “쓸만하다”는 완전히 다른 이야기니까요.

8.3 Tokens/s의 의미

AMD가 공개한 데이터에 따르면, Flash Attention을 켰을 때 초당 약 8.3 토큰 의 생성 속도를 보여줍니다. (Context 8192 기준)

  • 긍정적 해석: 1조 파라미터 모델을 로컬에서, 그것도 소비자용 하드웨어(비록 4대지만)에서 이 속도로 돌리는 건 기술적 성취입니다. 읽을 수 있는 속도죠.
  • 부정적 해석: ChatGPT나 Claude 같은 상용 서비스에 익숙한 사용자에게는 답답할 수 있습니다. 특히 TTFT(Time To First Token), 즉 첫 단어가 나올 때까지 걸리는 시간이 문제입니다.

치명적인 병목: 네트워크와 TTFT

데이터를 보면 8192 토큰 컨텍스트에서 첫 토큰이 나올 때까지 90.5초 가 걸립니다. 질문 하나 던지고 라면 물 올리고 와야 한다는 소리입니다.

가장 큰 원인은 네트워크 인터페이스 입니다. 이 실험에서는 고작 5Gbps Ethernet 을 사용했습니다. 분산 추론에서 노드 간 텐서(Tensor) 전송은 엄청난 대역폭을 요구합니다. Hacker News에서도 이 부분을 맹렬히 비판하더군요.

“Only 5gig Ethernet? Can’t they do usb-c / thunderbolt 40 Gb/s connections like Macs?”

맞습니다. 만약 Thunderbolt 4나 10GbE 이상의 인터커넥트를 썼다면 TTFT를 획기적으로 줄일 수 있었을 겁니다. 5Gbps로 1T 모델을 샤딩해서 돌리는 건, 페라리 엔진에 자전거 체인을 건 격입니다.

4. Hacker News와 커뮤니티의 반응

Hacker News의 반응은 “신기하다”와 “실용성은 없다”로 나뉩니다.

  1. 비용 문제: 이 셋업을 구성하려면 대략 $10k(약 1,300만 원) 정도가 듭니다. 이 돈이면 클라우드 API를 몇 년 쓰는 게 낫지 않냐는 의견이 지배적입니다.
  2. 전력 효율: 4대의 데스크탑을 돌리는 전력 소모도 무시할 수 없습니다.
  3. Flash Attention의 중요성: FA를 끄면 8192 컨텍스트에서 바로 OOM(Out of Memory)이 터집니다. AMD GPU에서의 rocWMMA 최적화가 필수적임을 보여줍니다.

5. 결론: 아직은 ‘장난감’이지만, 미래가 보인다

엔지니어로서 제 결론은 다음과 같습니다.

“이건 Production용 아키텍처가 아닙니다. 하지만 R&D용 샌드박스로서는 매력적입니다.”

  1. 데이터 프라이버시: 민감한 데이터를 클라우드에 올릴 수 없는 기업 연구소라면, 1조 파라미터 모델을 사내망(On-premise)에서 돌려볼 수 있는 가장 저렴한 방법 중 하나입니다.
  2. 통합 메모리의 잠재력: Strix Halo와 같은 고용량 통합 메모리 APU가 보편화되면, 개인 개발자도 70B, 100B 모델을 랩탑에서 파인튜닝하는 시대가 올 겁니다.

AMD의 이번 포스팅은 “우리 하드웨어 성능이 이만큼 좋다”를 자랑하기보다, “오픈소스 생태계(Llama.cpp)와 결합하면 이런 미친 짓도 가능하다” 는 가능성을 보여준 데에 의의가 있습니다. 다만, 다음번에 이런 글을 쓸 때는 제발 40Gbps Thunderbolt 연결로 벤치마크를 다시 해줬으면 좋겠군요. 90초 대기는 선 넘었으니까요.